배경
MS Windows Platform 기반으로 개발을 한다면 필연적으로 Visual Studio라는 제품을 사용하게 된다. 이 제품으로 개발할 때 사용되는 언어는 C/C++, Visual Basic, C# 등 다양하게 사용할 수 있다. 또 Windows Platform에 맞게 Native 한 어셈블리 계열에서 부터 .NET Framework 까지 다양한 기반 기술 및 API를 쉽게 사용할 수 있다. 또 Visual이라는 이름에 걸맞게 GUI 기반의 IDE 도구이다. 그래서 자체적으로 소스 에디터를 보유하고 있으며, 간단한 조작만으로 만들어진 소스를 빌드 하고, 디버깅 까지 복합적인 모든 형태의 기능을 하나의 도구로 만들었다.
이 Visual Studio는 Windows Platform의 변화에 맞추어 변화해 왔고, 발전하여, 현재 2010 버전까지 나왔다.
도구와 Platform의 발전도 발전이지만, 진정 발전을 한 것은 소프트웨어 개발 자체이다. 처음에는 까만 도스창에 실행파일 몇개와 동적 라이브러리 몇개로 구성된 단순한 Application 만으로도 충분히 동작하고, 사용했지만, 지금은 상당히 많은 기능과 동작하고, 크기 조차 엄청나게 커버렸다. 이처럼 단순한 Application 에서부터 서버 레벨의 비지니스 개발까지, 그 개발의 범위와 폭은 너무 커져갔고, 개발의 양 역시 상상의 범위를 넘을 정도로 개발됐다.
그러다 보니, 홀로 일당백 개발하는 시대는 저물고, 어느새 여러 사람이 협업을 하면서 개발해야 하는 단계에 이르게 되었다. 여러 사람이 하나의 목표(소프트웨어 제품)를 두고, 작은 조직을 만들어 꾸리게 되는데, 보통 이런 단위를 팀이라고 부르고, 자연스럽게 개발자들의 작은 그룹이 팀이 되어 그 팀 단위 개발을 수행하게 되었다.
공장에서야 컨베인벨트 위의 작업 형태와 작업 양에 맞춰 반복적인 작업을 위한 최초 교육을 거친 뒤, 원하는 인원을 투입해 생산 공정을 구성한다. 물론 인력 비용이라는 부분도 있기는 하지만, 최소한 인력 비용을 무시한다면, 확실히 인력 투입대비 생산량이 거의 동일하게 나오게 된다. 인력 투입 대비 생산력이 나온다는 이야기는 바로 인력을 최대한 투입하면, 투입된 만큼 제품이 나올 수 있다는 의미다.
하지만, 소프트웨어 개발은 단순 공장 노무와는 다르게 사람을 무작정 투입한다고 되지 않는다. 단순히 몇가지 반복적인 작업을 교육한 뒤 투입한다고 바로 무언가를 만들 수 있는 것이 아니기 때문이다. 위의 컨베인 벨트를 기준으로 이야기 한다면, 이 소프트웨어 개발이라는 것은 그 컨베인 벨트 자체를 만드는 공정이기 때문에 그게 쉽지만은 않다. 어떻게 컨베인벨트를 배치해야 최소 인력으로 최대의 효과로 제품을 생산할 수 있을까? 와 같은 고민을 소프트웨어 개발에서 수행하는 것이다. 이렇다보니, 무작정 인력만 우겨넣는다고 그 답이 나올리가 없다.
또 예전 같이 규모라도 작고 변수라도 적으면, 똑똑한 사람 몇명이면 그만이였지만, 규모가 규모인 만큼, 똑똑한 사람 몇 사람으로 해결 할 수 조차 없다. 자연스럽게 사람들은 건축, 공장화 그 모든 것들을 소프트웨어 개발에 맞춰보려 노력했지만, 그 결과가 그리 좋지 않았고, 결론적으로는 소프트웨어 개발은 다른 식으로 접근해야 되겠다고 생각하였으며, 그 결과 작은 생산 조직의 형태가 되었고, 이 역시 팀이 만들어지게 된다.
팀이라는 조직을 이용해 과연 어떻게 명확한 목표와 서로간의 협력을 만들어야 할까?
이 부분에 대한 많은 의견이 분분했다. 앞서 이야기 한 것 처럼, 건축 방법론을 가져와 설명하고 적용해보기도 했다. 그 덕에 건축에서 사용되는 개념의 일부를 소프트웨어 개발과정에서도 활용된다. 하지만, 무언가 어색한 옷인 마냥 잘 맞지 않았다. 그를 대체할 것 처럼 나타는 공장형태도 자연스럽게 등장했다. 공장에서 처럼 표준화된 부품을 통해 생산된다면 어떨까? 물론 개념도 훌륭했으며, 많은 소프트웨어들이 그에 맞게 해보려 했지만, 사람 생각이 100이면 100 틀리다 보니, 이 역시 어색한 옷이 되어버렸다. 그러다 보니, 요즘은 누가 옳다 그르다를 따지기 자연스럽게 스스로의 맞는 스타일을 찾아 가기 시작했고, 자연스럽게 Agile에서 제시하는 실천 방법과 같은 형태를 갖추기 시작했다.
Agile에 대한 이야기는 다른 Agile 관련 서적이나, 사이트 등에서 참고하면 된다.
이와 같은 복잡다단한 소프트웨어 개발 환경이라는 배경 속에서 MS는 Visual Studio를 제시했고, 그 제품을 이용해 팀 단위 업무를 원활하게 수행할 수 있는 환경을 제공했다. 개발자들 각자에게 제공되는 Visual Studio와 바로 연결될 수 있는 팀 협업 환경 - 서버 -를 또 하나의 제품으로 제시하였고, 그 환경이 바로 Team Foundation Server 라는 제품이다.
왜?
그럼 왜 Team Foundation Server 일까?
사실 이 부분의 당위성은 위의 배경에서 어느 정도 설명하기는 했다. 그렇지만 꼭 Team Foundation Server를 쓸 필요는 없다. 이미 위의 배경과 같은 문제점을 해결하기 위해 많은 소프트웨어 개발자와 설계자들은 고민했고, 그에 맞는 솔루션들을 다양하게 만들어 제시했고, Open Source로 공개적으로 제공하는 무료 솔루션도 다양하다.소스 버젼 관리라면, Subversion 이나, CVS 정도, 요구사항 및 형상관리레벨 이라면 Redmine 도 좋다. 자동 빌드라면 Hudson 정도 써주면 딱 일듯 싶다. 가격도 없다. 원하는 대로 쓰고 수정하고, 제안만 하면 된다.
그런데 굳이 왜 Team Foundation Server 일까? 구구절절한 당위성에 대해서는 MS에서 제시하는 개발 방법론이나, 다양한 보고서, 광고 만으로도 충분히 나온다. 그런 구차한 변명을 걷어낸다면, 그 모든 것의 결론은 MS Platform 기반으로 개발하고, Visual Studio를 쓰기 때문일 것이다. Visual Studio에 딱 달라 붙어서 아주 유연하게 쓸 수 있다는 것! 바로 그 점일 것이다.
또 전산 관리자 측면을 바라본다면, 유지보수를 위해서라도, 역시 한 벤더에서 그냥 한번에 모든 연계 제품을 묶는게 더 편하지 않나 싶다.
무엇을 할 수 있나?
팀 협력 작업이라면 대부분의 작업을 할 수 있다.
버전 관리
과거 SourceSafe 라는 약간은 원시적인 동작을 했지만, 그럭저럭 쓸만했던 제품이 있다. Visual Studio에 딱하니 붙기도 하고, 소스 DB도 단순한 형태라 백업하기도 그만이였다. 이 TFS에는 그 원시적인 도구를 조금 더 세련된 UI와 내부적인 DB를 MS SQL이라는 DBMS에 담고, Brench 같은 다른 버전관리도구에서나 제공했던 기능들도 넣었다. 애초 TFS를 쓰는 대부분의 사용자는 바로 이 소스 버전관리 하나만으로도 모든 것을 만족한다.
작업 관리
어설프지만, Redmind 같은 요구사항 관리나, 형상관리를 처리할 수 있는 기능이 있다. 요청 사항들을 관리하기도 하고, 작업을 관리하며, 버그 이력을 남길 수 있다. 이 모든 작업을 Visual Studio 안에서 처리할 수 있다. 입력을 Form에서 하고, 그 결과 값을 Grid 형태로 보기도 하고, Excel로 뽑아볼 수 있으며, MS Project를 통해서 관리 할 수 있다.
자동 빌드
자체적으로 빌드 서버를 구축할 수 있다. 자동으로 최신 소스를 받아 사용자의 별다른 도움 없이 자동으로 빌드 결과물을 만들어 낼 수 있다. MS Build를 사용하는 솔루션 파일만 있으면, 그 솔루션 파일에 설정된 내용대로 자동으로 빌드하게 된다. 최초 구축이 힘들어서 그렇지 한번 구성하면 나름 쓸만한 도구 이다. 내부적으로 Test DLL이 있으면, Test까지 수행해준다.
그 외의 기능
SharePoint와 연동해 문서들을 올리고 관리할 수 있으며, 다양한 형태의 프로젝트 관련 Report 들을 만들어 주기도 한다. 생산성이나, 버그 경향 등을 일목 요연하게 볼 수 있다.
여기서는?
현재 저 위의 기능을 100% 완벽하게 구축해서 다 사용해 본 적은 없다. 하지만, 회사에서 사용되는 목적에 맞는 기능들을 어떻게 구축하고 사용하는지를 정리하기 위해 여기다가, 키보드로 끄적여 본다.
방향
시간이 허락되는데 까지, 서버의 구축에서부터 사용법까지만 나열할 예정이다. 예전에 SourceSafe에 대한 어설픈 글 올린 것처럼 완결될 것 같지는 않지만, 기록이나마 남기기 위해서 적어본다. 회사의 환경을 그대로 소개하면서 설명하면 쉽겠지만, 내부 보안이라는 부분도 있으므로 별도 Virtual Machine에 구축하면서 설명할 것이다.