팀 파운데이션 서버(Team Foundation Server) 를 쓰지 말아야 하는 진짜 이유 #2

팀 파운데이션 서버(Team Foundation Server) 는 2005년 처음 시장에 공개되었다. 이 시기에 많은 버그와 설치 자체가 매우 난이도가 높아서 많은 사람들의 원망을 샀다.

참고 - TFS를 쓰지 말아야 하는 진짜 이유 #1 (링크)

TFS를 쓰지 말아야 하는 진짜 이유 #1을 정리해 본다.

  • 통합? 모든 것을 만족할 수 있지만, 어느 것도 만족할 수 없다.
  • 특정 제품(Visual Studio)에 완벽하게 통합되어 외부와 완벽하게 격리된 솔루션이다
  • 우리나라에는 전문가가 없다
  • 전문가적인 서비스를 제공하는 업체도 없다
  • 마이크로소프트 제품으로 발라야 한다
  • 예측할 수 없는 잦은 장애, MS 제품에 잔지식이 많아야 한다
  • 제대로 된 기능이 하나도 없다

TFS를 쓰지 말아야 하는 이유 중 기능적인 요소로는 다음과 같다. (차후에 자세히 다루겠다)

  • 데이터베이스에 소스 코드가 저장되다보니 DB 로그 사이즈는 DB 용량(데이터)의 수십 배가 넘어간다
  • 모든 서버 통신은 SOAP 프로토콜을 사용하므로 매우 느리다
  • 작업 항목(WorkItem) 관리, 이슈/버그/개발 등을 관리하기에 매우 비효율적이고 쓰는 것 자체가 스트레스로 발전할 수 있다. (다른 이슈 관리 툴에 비해)
  • 모든 기능에 제한이 너무 많다

1. 팀 파운데이션 서버(Team Foundation Server)[1]

구글 트랜드(Google Trends)는 아래의 그래프와 같이 새로운 버전이 나올 때 조금씩 치고 올라가는 것을 알 수 있다. 하지만, 시간이 지날수록 이탈하는 사용자가 많을 것이고, 현재는 엉망으로 만들었던 TFS 2005 버전보다 더 관심이 줄어든 것으로 보인다.



2. TFS vs SVN

필자도 사실 이걸 보고는 깜짝 놀랬다. SVN(아파치 서브버전)이 알려진 시기는 TFS 2005와 몇 년 차이가 나지 않지만, SVN은 그야말로 LTE처럼 뻥 뚫린 고속도로처럼 고속으로 성장을 했다. 반면에 Team Foundation Server는 바닥에서 지렁이 기듯이 기어다닌다.



3. TFS vs SVN vs GIT

SVN과 GIT이 끼니 더이상 TFS에 대해서 할말을 잃게 만든다. 이쯔음 되면 TFS를 쓰는 사람들은 분명 M빠거나 멋모르고 쓰는 것이 분명하다.



4. TFS vs SVN vs GIT vs Mercurial

따로 TFS는 해설이 없어도 될 것 같다. 아래의 그래프가 여실히 보여주고 있으니 말이다.



결론

99% 중에 1%라면 매우 희소성이 있고 가치가 있어 보일 수도 있다. 필자가 그랬다. 스스로 가치 있다고 판단한다면 분명 그것은 가치가 있는 것이다.

하지만 소스 제어를 비롯한 ALM은 혼자만 가치를 느껴서는 절대로 공존할 수 없는 도구의 집합이다. 통합이 완벽해서 완전히 격리된 ALM 제품은 소프트웨어에 생명을 불어 넣기에 바라보는 안목을 작아지게 만든다. 툴에 종속되어 생각을 제한해서는 안된다.

100명 중 99명이 No 라고 말할 땐 그만한 이유가 있다. TFS는 2005년부터 시작되었고 현재 2013년이다. 횟수로 8년이 되었지만, TFS는 여전히 고질적인 문제를 해결하고자 하는 노력을 하지 않는 것 같다. 현재의 TFS 2012/2013 은 TFS 2005 초기 버전 그 이상을 아직도 뛰어 넘지 못했고, 앞으로도 뛰어 넘지 못할 것이다.

  • 성능
    점점 느려진다. 28GB 넘는 바이너리가 없는 소스코드를 인트라넷 네트워크에서 10시간 넘게 받은 적이 여러번이다.

  • 확장성
    SDK로 깨잘되는 것 말고 할 수 있는 확장 포인트가 거의 없다.

  • 사용성
    애자일보드/칸반(Kanban), 드래그&드롭, 이런거 보여주면서 사용성이 좋다고 하면 오류다. 실무에서 거의 쓸 일도 없고 더 불편하다.

  • 크로스플랫폼
    Team Explorer EveryWhere 가 크로스플랫폼을 지원한다고? 만약 이클립스를 안쓰면 어쩔건데…? 답이 없다. 다양한 개발툴 대부분이 TFS를 지원해 주는 플러그인이 없고, 지원이 된다고 해도 소스 제어 수준에서만 지원을 한다. 그러므로 통합의 의미 자체가 희석되어 버린다.


  1. ‘TFS’ 트랜드 검색 시 merida/matts 등의 통계에 방해되는 데이터가 포함되어 Team Foundation Server 로 탐색을 하였음.  ↩


저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 조경민 2014.05.14 18:36 신고 Address Modify/Delete Reply

    참 안타까운 현실이네요.. 안타까운 마음에 글 남겨봅니다..
    저희 회사에서는 아직도 TFS 2010을 사용하고 있습니다. 물론 제가 서버 구축(MOSS연동까지..)부터 관리까지 다 하고 있는 상태이구요. 용도는 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청) 관리 위주로 사용하고 있습니다. 소스관리는 시도를 했다 결구 SVN으로 갈아탔지요.. 요즘 SVN은 AD와 연동이 되서 그나마 다행이었네요.
    제가 기존 TFS에 매력을 크게 느꼈던 부분은 양식의 커스터마이즈와 한글화 때문이었습니다.
    위에 언급한 이슈(요구사항, 버그) 및 개발작업(릴리즈, 로드맵, 사이트모듈, 회의록, QA요청)모두 양식을 커스터마이즈 해서 사용하고 있습니다. 필드까지 싹 변경 할 수 있기 때문에 저에게는 엄청난 강점으로 느껴졌었습니다. 아주 심플한 혹은 강제화 할 수 있는 양식으로 탈바꿈할 수 있다는 부분은 큰 매력이였네요. 지금도 물론 잘 사용하고는 있지만 근래 JIRA 등의 동향을 보고 싶어 검색하다 여기까지 오게 됬네요.
    지금으로써 제일 불편한점은 간트차트를 사용하지 못한다는 것 외에는 크게 없는데.. JIRA를 데모해보면 또 어떻게 바뀔지 모르겠네요.
    환경적인 내용 외에 위 언급드린 내용 기준으로 비교되는 글이 더 있음 정말 좋을 듯 합니다. ^^

    아 그리고 한글화는 아직도 TFS가 최고라고 생각되네요 ㅋㅋ이넘의 짧은 영어는 언제나 발목이..

    좋은 글 잘 읽었습니다. 앞으로도 좋은 정보 부탁드립니다.
    감사합니다.

  2. 남뉴 2014.07.02 11:21 신고 Address Modify/Delete Reply

    재밌는 글 감사합니다. 전 오히려 개발소스버젼관리시스템 자체에 회의감이 듭니다. 여러 사람이 쉽게 소스를 관리하는건 장점이고 권한에 따른 제한도 있어서 장점일 것 같지만, 오히려 잘못된 버젼 관리로 인한 문제가 더 많아 질때가 있습니다.(이건 직급이 높아도 경험이 많아도 문제가 발생합니다. )
    덕분에 압축과 시스템을 병행하고 있습니다. 마치 종이로 인쇄하고 다시 PDF나 문서파일로 웹에도 올리는
    형상이죠

  3. 지나가는이 2015.04.20 16:06 신고 Address Modify/Delete Reply

    훌륭한 정보 잘보고 갑니다. 감사합니다.