[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [1/2]

[TFS] 어떤 개발자의 외침. "왜 TFS를 쓰기 싫을까? - TFS is suck." [2/2]

 

예전에 인터넷에서 자료를 찾는 중에 Team Foundation Server를 무척 혐오한다는 사람의 글을 읽게 되었다. 매우 잘못된 정보로 Team Foundation Server와 Visual Studio를 바라보는 것을 매우 안타깝게 생각한다. 이 글을 작성된 지 1년 정도 되었는데, 필자는 오늘에야 비로서 이 내용을 바로 잡고자 한다.

필자는 Microsoft 제품과 직접적으로 관련되지도 않았고, 더 이상 Microsoft MVP도 아니다. 그러므로 필자의 답변은 최대한 중립적인 입장에서 작성하였다. 물론, 필자는 Team Foundation Server를 사용한다. 하지만, 반드시 Team Foundation Server만 사용하지는 않는다.

그리고 글의 작성자는 Team Foundation Server의 기능과 Visual Studio IDE 기능을 모두 Team Foundation Server의 문제로 지적하고 있다. 이런 툴의 기능에 대한 혼돈이 있어 필자의 답변 또한 편의상 글 작성자의 의도에 맞게 Team Foundation Server로 통일하였다.

아래의 원문의 글을 작성하신 분의 글은 검은색이고,
필자가 답변한 글은 어두운 붉은 색으로 표시하였다.




원문 : http://imjuni.tistory.com/464 

---

 

단순한 거부 반응이 아니라 왜 TFS를 쓰기 싫을까? 개인적으로 TFS를 정말 오랫동안 써보고 또 TFS를 이용하여 공동 작업을 해보기도 한 결과 TFS는 정말 사용해서는 안될 도구라는 사실을 지속적으로 느꼈고, TFS를 제발 쓰지 않았으면 하는 생각을 계속 하게 되었다. 하지만 TFS는 생각보다 사용되는 곳이 많다. 그 이유는 가장 적은 비용으로 ALM 도구를 도입할 수 있다는 것 때문에 TFS를 도입하게 된다. 그런데, 가장 큰 문제는 ALM을 위해서 TFS를 도입하면 반대 급부로 TFS 때문에 개발자의 생산성이 저하되어 TFS를 도입한 비용만큼 개발자의 생산성이 저하된다. 그리고 제발 TFS가 가지는 ALM 기능이 VCS에 포함된다는 착각은 하지말자. Work item을 생성하거나 체인지 셋을 묶거나 추적하는 등의 기능은 ALM이면서 Issue Tracker이기 때문에 가능한 기능들이다. 이러한 기능은 Jira 또는 Code Beamer, Trac, Launchpad 와 같은 도구에서 제공하는 기능이지 SVN이나 Mercurial에서 제공하는 기능이 아니다. 정말 이런 대착각은 하지말자. 또한 Martin Fowler가 조사한 Vcs Survey에 따르면 TFS의 인지도는 0%다. 정말로 0%다. 링크를 따라가면 확인할 수 있다. 설마 Martin Fowler가 이름 없는 사람이고 그래서 그 조사를 믿을 수 없다는 이야기는 하지말자. Martin Fowler는 그 유명한 Refactoring의 저자이자, 애자일과 관련하여 아주 유명하신 분이다.

왜 TFS를 쓰면 안될까? 번역과 경험을 토대로 이 글을 써보자.

1. 크기: 이 부분은 MS가 참 미쳤다. SVN은 TortoiseSVN을 쓰면 15MB 많아야 20MB면 충분하다. 심지어 자체 웹서버가 내장된 tortoiseHg도 24MB면 충분하다. 웹서버도 없고 아무것도 없는 TFS는 Visual Studio Extension이라는 이유로 VS 필수 구성요소를 모두 설치해야 되기 때문에 200MB가 넘는다. 솔직히 요새 200MB면 껌이기 때문에 그리 부담도 되지 않지만 타 시스템과 비교하였을 때 10배 이상 크기가 큰 것은 확실하다. 넷북이나 가벼운 시스템에서 구동시키는 것은 확실히 부담되는 크기임이 자명하고, 부인해서도 안될 것이다. 뿐만 아니라 덩치가 크다는 것은 그만큼 메모리를 많이 소비한다는 뜻과 동일하다. TFS는 그만큼 가볍지도 않고, 용량도 많이 차지하는 거대 도구라는 것을 인정해야 한다.

SVN의 용량과 TFS의 설치 용량을 비교하는 것은 의미가 없다.

 
Team Foundation Server(이하 TFS)는 설치 시에 소스제어 기능만 선택적으로 설치할 수 없다. 그래서 설치 시에 모든 기능이 포함하여 설치하게 되는데, 이 중에는 소스제어, 작업항목, 빌드, 팀 탐색기(소스제어 클라이언트) 등이 모두 포함된다. 그리고 이 기능이 원활하게 동작하기 위해서 VC++ 재배포 패키지, .NET Framework 재배포 패키지 등이 설치 파일에 모두 포함이 된다.

 
마찬가지로 SVN을 소스제어로 이용하고, 그 외에 빌드, 이슈 트래킹 툴  등을 모두 갖추고 설치한다면 TFS보다 설치 용량이 더 많아질 지도 모른다.

그래서 용량이 크다는 이유로 TFS가 싫다는 이야기는 이야기의 논재에 벗어난 것 같다.

---

2. 읽기 전용 파일: 왜 이런 구조로 개발 되었는지 이해할 수 없지만 TFS에서 관리하는 모든 파일은 읽기 전용이다. 파일을 고쳤다고 하더라도 실제로 체크 아웃을 한 것이 아니라면 전혀 반영되지 않으며 이를 알 수 있는 방법은 Visual Studio 탭에 표시된 잠금 표시와 저장할 때가 되어서야 나오는 읽기 전용이므로 이를 해제해 달라는 말을 보았을 때다. 이 경우 일단 저장을 하고 다시 체크인을 한 뒤 다시 또 저장을 해야 한다. 만약 이 와중에 충돌이 발생하면 끔찍한 결과를 초래 한다. 읽기 전용 파일이 문제가 되지 않는다고 주장하는 사람은 빈번하게 충돌이 발생하는 환경에서 개발을 해보지 않은 것으로 판단 된다.

TFS의 소스를 파일을 내려받은 클라이언트의 파일은 읽기 전용이라는 점은 필자로 여러모로 불편한 점이 있다고 생각한다. SVN과 비교하자면 불편한 점이 확실히 맞다. 

 
TFS는 윈도우 탐색기나 커맨드 라인을 통해 파일을 수정하려 한다면 읽기 전용 파일이기 때문에 수정하여 저장할 수 없다. 이 경우 읽기 전용 파일 속성을 해제해 주어야 한다. 하지만, 수정하려는 파일을 체크인 하려고 한다면, 먼저 체크아웃을 해 주어야 한다. 체크 아웃을 하지 않으면 체크인 시에 수정된 파일로 간주하지 않기 때문에 변경 집합에서 제외되므로 체크인을 할 수 없다.

반면, SVN또는 기타 소스제어에서는 윈도우 탐색기 등에서 파일을 수정하면 알아서 체크아웃을 시키거나 체크아웃 과정을 자연스럽게 유도한다. 

이 부분에서 불만을 주장하신 분은 '일단 저장을 하고 다시 체크인을 한 뒤에 다시 저장을 해야 한다'는 방법은 잘 이해하기도 어렵거니와 잘못된 방법이다. 이 경우 필자가 이야기 한 것처럼 강제로 수정한 파일은 언제든지 다시 체크아웃을 한 후에 체크인을 하면 된다. 단, 특정 버전 받기를 하게 되면 모든 파일을 덮어씌우기 떄문에(Overwrite) 체크인 전에 특정 버전 받기를 실행하면 안된다. 물론 이런 경우는 극히 드물겟다. (최신 버전 받기는 변경된 파일만 덮어씌우므로 최신 버전 받기는 강제로 수정한 파일이 안전하게 수정된 내용으로 보존된다.)

하지만, 불만을 주장하신 분의 이야기 처럼 빈번하게 충돌이 발생하는 환경이라면 어떤 소스제어 솔루션을 사용하더라도 빈번하게 충돌이 발생하게 되어있다. 이런 충돌 상황을 빈번하게 겪어 충돌을 피할 수 있는 경험적인 감각을 익힐 수 있을 정도의 지능을 가진 사람이라면 대부분의 충돌이 발생하는 상황을 최대한으로 피할 수 있다.

---

3. 솔루션 파일 수정 무한 반복: 몇 가지 상황이 되면 이 경우를 만나게 된다. 예를 들면 VPN으로 사내 망에 접근할 때 TFS 서버 이름이 변경되는 경우 이다. 이 때 VPN으로 접근한 사람이 솔루션 파일에 TFS 이름을 바꾸면 나머지 사람은 그 솔루션 파일을 받은 뒤 다시 바꿔야 하고, VPN 작업자는 또 바꾸고, 이러한 무한 반복이 실행 된다. 또 다른 경우로는 솔루션 파일이 바인딩 되지 않은 경우 솔루션 파일을 바인딩 하기 위해서 솔루션 파일을 변경하고 다른 사람은 그 바인딩 정보를 솔루션 파일에 기록하기 위해서 변경하고 그러면서 자신에게 바인딩 하는 과정을 또 거치는 등 역시 무한 반복이 실행 된다. 발생하는 일 자체는 그리 짜증나지 않지만 무한한 반복으로 인해서 체인지셋 관리에 어려움을 겪게 된다. Subversion 또는 Mercurial은 근본적으로 이러한 일이 발생하지 않는다. 두 VCS에서 프로젝트 파일이란 단순히 관리가 필요한 텍스트 파일에 불과하기 때문이다.

이 부분은 글을 작성하신 분의 의견에 공감한다.

다만, SVN의 경우는 소스제어 바인딩 정보가 .svn 숨김 폴더에 저장되기 때문에 이런 문제가 발생하지 않지만, 폴더마다 .svn 숨김 폴더에 캐시된 데이터가 쌓이는 문제도 함께 가지고 있다. SVN 최신 버전에서는 폴더마다 .svn 숨길 폴더가 만들어 지는 문제를 최상의 폴더 한 곳에만 생기게 하도록 수정되었다고 한다.

---

4. .net 안쓰는 사람: Java 또는 PHP, Ruby, Python 등을 이용하여 개발할 경우 TFS로 인해서 얻는 반사 이익이 급격히 줄어든다. 솔루션 파일을 통한 간편한 프로젝트 추가 기능을 사용할 수 없고 디렉토리를 통채로 삽입할 경우 바이너리 파일이나 의미 없는 파일을 일일히 GUI로 제거해 주어야 한다. 반면 TortoiseSVN 또는 TortoiseHg는 Ignore list를 편집하여 간편하게 복수 파일을 관리하지 않을 수 있다. 또한 다른 도구와 다르게 비교 도구를 자체적으로 지정할 수 없고, 체인지셋 간 비교가 원활하지 않다. 이와 같은 단점으로 인해서 생산성이 저하 된다. 또한 Maven, Ant와 같은 오픈 소스 빌드 도구를 사용할 수 없고 MSBuild와 같은 도구만 사용가능하여 TFS 장점을 취하기 힘들다. 만약 Eclipse, Aptina 등과 같은 도구를 사용할 때는 2개의 IDE를 사용하거나 Teamprise를 사용해야 하는데 Teamprise는 MSDN Account가 있을 때 무료이다. Visual Studio Ultimate with MSDN 라이센스가 필요하다. 따라서 .net을 사용하지 않는 사람은 추가 비용이 발생할 수 있다는 것을 확실히 인지해야 한다.

필요 없는 파일의 확장자를 필터링하여 통채로 소스제어에 바인딩 또는 체크인할 수 있는 기능은 예전부터 TFS에 있는 기능이다. 그리고 비교 도구로 파일이나 체인지 셋, 폴더 등 비교하는 기능도 사용자가 별도로 설정할 수 있는 기능이 예전부터 존재한다.

그리고 라이센스 부분에서 TFS가 상용 솔루션인 점을 감안하면 당연히 클라이언트 라이센스 정책이 있다는 점은 당연하지 않을까?

이 부분도 다시 확인해 보시길...

---

5. Same Directory Archive: 사용자 디렉토리 경로와 TFS 경로를 일치 시키는 일을 한다. 사실 SVN과 Mecurial, Git와 같은 도구는 Point to Point, Central Repository의 특정 지점과 지점을 프로젝트로 연결함으로서, TFS 처럼 경로를 강제하지 않는다. TFS가 경로를 강제한다는 말은, Repository에 만들어진 Directory structure가 실제 사용자 Directory structure와 일치시킨다는 것이다. 일반적인 VCS에서는 프로젝트 단위로 연결하기 때문에 프로젝트 하위 Directory structure는 관리되지만 프로젝트 상위 Directory structure는 따로 관리하지 않는다. 관리하지 않더라도, VCS 자체에서 branch 별로 Directory를 만들거나 구조적인 관리가 가능하지만 사용자는 최종적으로는 프로젝트와 프로젝트가 연결되는데 반해 TFS는 프로젝트 상위, 하위 모든 Directory structure를 일치 시킴으로서 불편을 유발한다. 예를 들면, A, A', A'' 프로젝트가 있다고 가정하면 A'와 A''는 A 프로젝트 branch일 때 TFS는 관리자가 만든 구조로 세 프로젝트를 관리해야 하지만 SVN 또는 Mercurial은 A와 branch내부에 A'와 A''를 둘 수 있다. 개발자가 원하는 방식으로 프로젝트를 관리할 수 있다.

말씀하신 것처럼 소스제어의 폴더 구조를 반드시 따를 필요가 없다. 사용자가 작업영역(Workspace)를 이용하여 폴더 구조를 정의할 수 있다. 그리고 유용한 것 중, 공개 작업영역을 이용하면 누군가가 정의해 놓은 구조를 모든 사람이 공개 작업영역을 이용하여 같은 개발 구조를 가져갈 수도 있다.

이 부분도 다시 확인해 보시길...

---

6. 충돌 처리 미흡: 충돌이 일어날 때 TFS는 일반적으로 3가지 선택지를 준다. 다른 사람의 소스를 원복 하는 것, 내 소스를 원복하는 것, 자동으로 머지를 하는 것 3가지 선택지가 있다. 일반적으로 어떠한 도구라도 자동 머지는 믿을 수가 없고, 나 살자고 다른 사람이 작업한 결과물을 버리게 할 수 없기 때문에 내 소스를 버리게 된다. 이 경우 지금까지 작업한 것이 모두 사라지게 되는데 이를 방지하기 위해서는 Local Workspace를 제외한 또 다른 사본이 필요하게 된다. 이는 이중으로 머지를 하게 만드는 수고를 하게 함으로서 정말 고통 스러운 작업을 지속적으로 유발한다. 정말 이 과정에서 수없이 많은 충돌과 누락을 발생시키는데 도저히 이 방식을 용납하기 힘든 정도이다.

이렇게 고생하면서 충돌 처리를 하시는 점이 이해가 가지 않는다. 이런 소스의 버저닝 문제로 소스 제어를 사용하는데, 그 자체가 용납하기 힘들 정도이면 소스제어 기능을 충분히 활용하지 못하는 것 같다.

---

7. offline 상태에서 완벽한 무력화: 일반적으로 오프라인 상태에서 유효한 SCM은 분산 SCM인 Git, Mecurial을 제외하면 SVN도 유효하다고 보기는 힘들다. 다만, TFS와 SVN이 근본적으로 다른 점이라면, TortosieSVN을 이용한다면 어떤 파일이 수정되었는지 알 수 있다. 또한 작업 이전에 프로젝트를 모두 복사한 뒤 자유롭게 작업하고 그 결과물이 마음에 든다면 그 소스를 바로 커밋할 수 있다. 커밋한다면 실제 Repository에 반영된다. TFS로 동일작업을 해야 한다면 일단 사본을 만들고, 그 사본으로 작업한 뒤 원래 Local Workspace에서 수정한 파일을 "기억을 더듬어서" 일일히 Check out을 한 뒤 하나씩 복사해야 한다. 완벽하게 Check out이 끝난 뒤라면 통채로 복사해도 상관은 없지만 중요한 것은 Check out을 한 뒤 해야 하는 것이다. 만약 당신이 30개의 파일을 수정했다면 30번 Check out을 해야 한다. 만약 Git, Mercurial을 사용한다면 Local Repository에서 revision을 관리하며 작업을 지속하는 것이 가능하다.

TFS와 Visual Studio에서 온라인 상태로 바인딩된 소스제어가 오프라인으로 변경이 되고, 코드 변경 작업이 완료된 후 다시 온라인 상태로 전환이 되면 변경된 파일은 체크 아웃 상태를 유지한다. 그리므로 일일이 기억을 더듬어서 작업할 필요는 없다.

이 부분도 다시 확인해 보시길...

---

8. 비용: TFS는 단점만 가진 SCM이지만, 자체적으로 ALM 기능을 포함하고 있기 때문에 비용이 수반된다. ALM이 반드시 필요한 경우라면 가장 저렴한 비용으로 구축할 수 있지만 TFS를 사용함으로서 얻는 불이익이 ALM 도입 비용을 상회할 지 모른다. 또한 TFS 사용을 위해서 VS가 전혀 필요하지 않는 사람도 VS를 TFS 라이센스로 모두 구입해야 하므로 사실 비용이 썩 저렴하다고 보기 힘들다. 만약 Issue Tracker 또는 ALM이 필요하다면 Jira와 같은 도구를 도입하고 SCM을 따로 구축하거나 Trac + Mercurial, Launchpad + Mecurial 같은 솔루션을 사용하는 것이 현명한 방법이라 생각한다. 이를 통해서 VS가 필요없는 사람에게 TFS VS를 구입 해줄 필요가 없으므로 비용을 절감할 수 있고, 또한 VS 역시 TFS 버전으로 구매할 필요가 없으므로 비용을 절감할 수 있다. 심지어 SCM 서버도 리눅스 등을 이용하여 구축할 수 있으므로 서버 비용도 절감할 수 있다. (다만 리눅스 엔지니어를 채용하는 비용이 추가적으로 발생할 수 있습니다)

TFS 라이센스 부분에서 TFS를 사용하려는 사용자가 모두 Visual Studio를 구매할 필요가 없다. CAL(Client Access License)만 구입하면 된다.

그리고 오픈 소스를 이용하여 ALM 환경을 구성하는 것은 그 조직이나 그 사람의 자유이다. 그것이 관리하기 편하고, 사용자가 원한다면 오픈 소스를 사용하는 것도 좋은 방법이다. 다만, 오픈 소스를 이용하여 모든 ALM 환경이 구성된 경우, JRE 버전, 새로운 버전으로 업그레이드와 데이터 마이그레이션, 오류 등으로 자유 소프트웨어 진영에서 어떠한 지원도 받을 수 없을 것이다. 이런 점에서 상용 솔루션은 어떤 지원을 받거나, 책임의 소지를 확실히 구분할 수 있다.

이 부분도 다시 확인해 보시길...

---