최근 Git이나 Mercurial 과 같은 분산제어 방식의 소스 제어 제품을 무조건 맹신하고 찬양하거나 분산제어 방식보다 중앙집중형 소스제어 방식을 무조건 배척하는 현상이 일부 나타나고 있다.

리누스 토발즈(Linus Tovalds)와 같은 공산주의(Communism) 사상의 이상을 강조하는 철학이 담긴 Git은 GitHub.com을 통해 소스 코드를 공유함으로서 오픈 소스 진영에 매우 발전적인 기여를 하고 있음은 확실하다. 리누스 토발즈(Linus Tovalds)가 만든 것이라 그런지 훨씬 더 주목받고 있는 것 같다.

중앙집중 소스제어와 분산제어 소스제어 방식은 그 원칙과 근본적인 가치에 차이가 있는, 방법론으로 접근해야 할 것이다. 따라서 각 소스 제어의 방식마다 특징과 장단점이 있으며 ‘좋은 게 좋은 것 아닌가~’ 라는 간단한 답을 얻길 바란다.

필자는 중앙집중 소스제어와 분산제어 소스제어 방식의 장단점을 5가지의 관점에서 살펴보자. 중앙집중 소스제어(이하 중앙제어 방식)은 분산제어 소스제어 방식을 사용하는 몇 가지 소프트웨어를 제외한 대부분으로 보면 된다.

  • 중앙통제력
  • 정책주입력
  • 분기용이성
  • 사용편의성
  • 성능

그 외에 도움이 될만한 위키피디아(Wikipedia) 링크를 참고하기 바란다.

내용상 비교하는 대상은 중앙제어 방식은 ‘팀 파운데이션 서버(Team Foundation Server)’와 SVN을 많이 참조하였고, 분산제어 방식은 ‘Git’을 많이 참조하였다.

중립적인 관점에서 글을 작성하였으나 어느 한 쪽으로 편향이 되었다면 미리 그 점에 대해 양해를 구하는 바이다.

중앙통제력

이름에서도 알 수 있는 것 처럼 중앙집중적인 통제력은 기존의 중앙집중 방식이 분산제어 방식보다 유리한 점이 많다. 분산제어 방식은 자신이 서버로의 통제를 받는 동시에 제 3자에게 있어 자기 자신이 서버가 된다. 반면, 중앙집중 방식에서는 서버가 오직 물리적인 한 곳에 위치해 있다.

때문에 중앙집중 방식은 조직에 있어 정책적인 부분을 클라이언트에게 강제로 주입할 수 있는 여지가 많다. (물론 분산제어 방식도 가능하다) 중앙 서버 한 곳의 설정만으로 많은 클라이언트를 통제할 수 있다.


이미지 참조

그리고 모든 히스토리는 중앙 서버의 데이터베이스에 저장이 되기 때문에 클라이언트에게는 단지 소스 밖에 없지만, 분산제어 방식은 그렇지가 않다. Git의 스테이징 스토리지가 바로 클라이언트가 가지고 있는 데이터를 저장하는 (임시?)스토리지다.

조직에서 소스코드가 변경되는 주요 변경 이력은 매우 민감한 부분이고, 영업비밀과 직결되는 요소들이 많다. 응용프로그램이 연결되는 데이터베이스의 컬럼이나 테이블의 사소한 변경에도 응용프로그램은 수정되어야 할 수 있고, 이것이 응용프로그램의 소스코드에 반영이 되면서 소스제어에 이력을 남기게 된다.

정책주입력

정책적인 주입력은 중앙통제력과 유사한 부분이 많다. 중앙통제력이 크면 클수록 정책주임력은 향상된다. 중앙 서버의 정책적인 설정만으로 여러 클라이언트는 중앙 서버에 의해 통제받을 수 있다.

특히 ALM(Application Lifecycle Mamangement) 제품과 개발 IDE 제품간에 얼마나 긴밀하게 잘 통합이 되었느냐에 따라 정책주입력에 영향을 미친다. 통합이란 것이 양날의 검과 같아서 좋게 말하면 ‘All in One’이라 표현할 수 있겠고, 나쁘게 말하면 구성요소간에 강한 응집력으로 인해 제한된 확장이라 말할 수 있겠다.

ALM 통합의 장점

  1. 한 번의 구성으로 모든 것을 사용할 수 있다.
  2. 새로운 업그레이드도 한 번의 구성으로 모든 것을 구성할 수 있다.
  3. 개발툴과 통합되어 사용하기 쉽다.

ALM 통합의 단점

  1. 설치/구성 환경은 벤더에 의해 결정된다.
  2. 기능이 하나 하나가 완성도가 높지 않아 기업 및 도메인 환경에서는 추가 개발이 필요한 경우가 많다. (범용성을 위해…)
  3. 오픈 소스 ALM 도구보다 쓸 수 있는 도구들이 적다. (애드인/플러그인)
  4. 다양한 외부 도구와 연동이 제한된다.

분기용이성

분기(Branch)는 나무에서 여러 가지(Branch)로 뻗어 나가는 것을 일컬어, 하나의 소스 코드에서 여러 가지(Branch)로 소스 코드를 키울 수 있다. 특히 분산 제어 방식에서 분기가 얼마나 유용하고 효율적으로 사용할 수 있는지 잘 알 수 있다.

중앙 제어 방식에서의 분기는 곧 변경 이력으로 반영되어 영구적으로 분기 이력이 남게 된다. 때문에, 분기를 개인적인 용도로 사용하는 것이 힘들다. 소스 제어의 파일 시스템 구조를 복잡하게 만들 수 있고 구성원 개개인이 이를 핸들링 하기에는 전체 제품의 소스 코드에 좋지 않은 영향을 미칠 수 있다.


이미지 참조

반면, 분산 제어 방식의 경우 분기는 반드시 알아야 할 매우 효과적인 기능 중 하나로 볼 수 있다. 위에서 언급 했듯이 서버에게는 클라이언트가 되지만, 제 3자에게는 곧 서버가 된다. 즉, 로컬 서버(클라이언트)에서 자체적으로 분기가 가능해진다. 클라이언트에서 분기와 서버로 Push되는 정보는 다르므로 서버의 정책이나 구조에 영향을 최소한으로 적게 미치게 된다.

하지만, 중앙 제어 방식에서도 이런 단점은 충분히 극복할 수 있다. 분기는 병합(Merge)이라는 조건을 전제로 수행되는데, 만약 병합이라는 전제 조건이 없다는 가정하에 이와 유사하게 문제를 해결할 수 있는 방법이 있다.

중앙 집중 방식의 소스 제어 제품마다 기능적으로 다른 점이 있겠지만, 다중 작업 영역(Workspace) 또는 보류(Shelve) 기능을 이용하여 로컬 분기(Local Branch) 기능을 유사하게 흉내낼 수 있다. (물론 진정한 의미에서의 분기 목적과는 다소 차이가 있다)

사용편의성

사용편의성은 소스 제어를 사용하는 사용자가 얼마나 소스 제어를 편하게 사용함을 의미한다. 이를 언급하기 전에 사용편의성은 개개인의 경험적인 부분에서 다를 수 있다.

먼저, 분산제어 방식의 대표적인 Git을 험오하는 이유 10가지에 대해 쓴 블로그 내용을 참고하자.

Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.
이하 생략…
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

대부분의 소스 제어 명령은 GUI(그래픽 인터페이스)와 CMD(명령줄 인터페이스) 방식을 제공한다. 주로 GUI 방식은 개발툴과 연동이 되는 확장 또는 플러그인 방식으로 제공되고, CMD 방식은 소스 제어 제품 자체에서 제공하는 고유의 기능으로 제공이 되는 것이 대부분이다. 그래서 소스 제어를 사용하는 개발자가 어떤 환경에서 개발하느냐에 따라 GUI 또는 CMD 방식으로 갈리는 경우가 많다.

먼저, 이클립스(Eclipse) 또는 비주얼 스튜디오(Visual Studio)와 같이 비주얼을 강조하는 개발툴에서는 GUI 방식의 소스 제어 플러그인을 사용하는 경우가 대부분이다. 이런 환경에서는 키보드와 마우스를 함께 사용하는 경우이고 아이콘(icon)으로 수정된 파일을 바로 확인할 수 있다.

반면, SVN 또는 Git 의 CMD 도구의 사용이 익숙해질 경우 상당히 빠르게 명령을 사용하거나 결과를 확인할 수 있다. 그리고 개인용 컴퓨터의 성능에 거의 영향을 받지 않고 소스 코드를 개발할 수 있고, 손이 마우스와 키보드로 번갈아가며 사용할 필요가 없어 익숙한 사람에게는 더할 나위 없이 편리하다. 더불어, SSH와 같은 단순 Plain Text 환경에서도 제어가 가능하기 때문에 사용에 있어 거의 제한도 없다.

하지만 대체적으로 두 방식 모두 GUI 도구를 제공하거나 GUI 공개 소프트웨어가 많기 때문에 취향에 맞에 사용할 수 있다.

성능

중앙제어 방식은 모든 동작이 서버 측의 허가 없이는 불가능하거나 반드시 서버와 연결이 되어야 한다. 인트라넷이라면 크게 성능의 손실은 없겠지만, 지역이 다른 사람과 오픈 소스 개발을 하거나 클라우드 소스 컨트롤을 사용하는 경우 매우 느리다.

분산제어 방식은 모든 동작이 대부분 로컬에서 이루어 진다. Push, Fetch 같은 동작만이 서버와 연결이 필요하다. 때문에 성능이 매우 좋은 것이 특징이다. 하지만, 중앙제어 방식과 다르게 많은 데이터를 로컬에 저장해야 하므로 중앙제어 방식보다 로컬에 충분한 용량이 확보되어야 한다.

결론

몇 가진 기본적인 관점에서 깊지 않은 내용으로 중앙제어 방식의 소스제어 컨트롤과 분산제어 방식의 소스 컨트롤을 살펴보았다.

필자에게 어떤 것을 사용할지 묻는다면, 작은 개발 조직과 기업 환경에서는 중앙제어 방식을 권장하고 싶다. 많은 소프트웨어 개발 조직에서 여전히 통제하에 소프트웨어 개발을 하기를 원한다. 그리고 암묵적인 소프트웨어 개발 프로세스를 명시적인 프로세스로 개선하고자 하는 곳도 과거보다 많이 생겼다. 이런 환경은 중앙제어 방식이 더 효과적이라 믿는다.

반대로 분산제어 방식은 패키지를 개발하는 기업이나 IT 컨설팅, 국지적 개발 환경이 필요한 경우 효과적일 것이라 생각한다. 물론 기업 환경과 맞지 않는다는 것이 아니며, 통상적인 경우를 말한다.

필자는 우연히 Stack Overflow에서 매우 흥미로운 주제를 발견하였다. 바로 [Git vs Team Foundation Server [closed]]11 인데, 어느 개발팀의 분산제어 방식과 중앙제어 방식의 대결 구도에서 어떤 것을 선택해야 할 것인가에 대한 논의였다. (참고로 필자는 최근 git을 더 좋아한다.)

내용인 즉, 자신의 개발팀에 Git를 도입시켰으나, 개발 팀원들은 팀 파운데이션 서버(Team Foundation Server)로 바꾸길 원했다. 이 질문에 추천 답변의 내용은 ’Git을 버려라. Git을 계속 쓰다가는 계속 비난을 받고 싸우게 될거다’고 한다.

결론은 소스제어 컨트롤(Source Control)은 개인이 아무리 좋고 훌륭한 소스제어라고 생각하더라도 다른 사람들은 그렇게 생각하지 않을 수 있고, 선택에 있어서 다수의 의견에 귀 귀울이는 것이 좋을 것 같다.

I think, the statement

everyone hates it except me

makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.
Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):
automatic backup of the whole repo: everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don’t worry, take one of those present on every workstation.
offline repo access: when I’m working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, anything.
But as I said: I think that you’re fighting a lost battle: when everyone hates Git, don’t use Git. It could help you more to know why they hate Git instead of trying them to convince them.
If they simply don’t want it ’cause it’s new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?

Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what’s the problem. Convince them and you’ll convince the rest of the team.

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이성훈 2018.05.10 14:53 Address Modify/Delete Reply

    분산제어 서버를 이용하면 프라이빗 블록체인과 차이가 없는건가요..?!

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


지난 1편의 글에 이어, 어떤 분이 원문을 쓰신 분에게 이런 말을 남겼다.

이 코멘트에 대해 원문을 쓰시는 분은 아래의 링크로 반박의 글을 작성하셨다.

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

   


필자의 입장에서는 상용 솔루션이 커스터마이징을 해야 쓸만한 제품이란 것은 제품을 구매한 사용자 입장에서는 그리 달갑지는 않을 것이다. 대신 3rd party 벤더나 오픈 소스를 이용하여 기능을 더 보탤 수 있고, SDK API를 이용하여 직접 도메인 제약에 맞게 만들 수도 있을 것이다.

원문을 읽어보면 저 분은 TFS에게 어떻게 데였는지 모르겠지만, 병적으로 거부하는 것 같다. 그렇다고 싫어하는 이유에 대해 근거가 있거나 정확하게 잘못된 정보를 바탕으로 작성이 되었다는 것에 매우 안타까움을 느낀다.



첫 번째로, 위의 원문에서 아래와 같이 잘못된 정보를 가지고 있다.

   

일단 TFS에서는 VCS 기능을 어느 정도 확장을 할 수 있다. 이때 TFS Server는 물론이고, 클라이언트인 Visual Studio Extensibility를 이용하여 클라이언트도 확장할 필요가 있다. 이는 비단 TFS 뿐만이 아니라 SVN도 마찬가지다. 고로 어느 범위까지 확장할 것인가 결정에 따라 개발을 해야 할 범위가 틀려질 수 있다.

   

두 번째로, TFS를 Git와 비교한다는 것은 좀 무리가 있다고 본다.

Git는 유명한 리눅스를 개발한 리누스 토발즈에 의해 분산 버전 관리할 수 있는 소스 제어 솔루션이다. 분산 버전 제어가 자칫 매우 유연해 보일 수 도 있을 것이다. 이에 반해, TFS는 중앙 집중 방식의 소스 제어 솔루션이다.

기업에서 통제가 되지 않는 소스 제어는 보안적인 이슈나 소스 코드 유출 등의 사고가 생기가 마련이다. 이런 점에서 분산 버전보다 중앙 집중 방식이 기업에서 개발 환경 조건에 더 부합한다고 본다.

이런 장단점 등으로 오픈 소스를 지향하는 사람들은 분산 버전 관리 방식인 Git를 선호한다.

반면에, TFS는 TFS란 제품이 나오기 전부터 Microsoft 내부적으로 이슈 관리와 소스 제어를 할 수 있는 솔루션을 만들어 사용하고 있었다. Microsoft는 소프트웨어 기업이다. 소프트웨어를 잘 개발할 수 있도록 Team Foundation이라는 제품으로 발전하면서 상당히 많은 노하우가 녹아있는 제품이다.

SVN는 CVS가 Atomic Transaction(원자성)이 보장되지 않는 이유의 심각한 문제로, SVN으로 다시 태어났다.

   

원문을 쓰신 분은 필자가 이해하기 힘든 이유로 CodePlex와 Git를 비교하는 것은 '중국이 한국보다 인구가 많으니 강대국이다.'라는 논리와 같다.

잘못된 정보만을 가지고 TFS를 혐오하는 것은 바람직하지 않다고 본다. 안된다고 하는 많은 기능들이 이미 예전부터 지원했던 것인데 원문을 쓰신 분은 이런 기능을 이용하는 방법을 몰랐던 것이지, TFS 자체의 문제는 아니다.




이런 말을 해주고 싶다.

도구는 단지 도구일 뿐이다.
쓰는 사람이 잘 써야 좋은 도구이다.
잘 쓸 수 없는 도구는 그 사람의 잘못이지 도구의 문제가 아니다.
 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 나그네 2013.01.13 17:36 Address Modify/Delete Reply

    git 든 svn 툴이든 오픈소스 제품군만으로도 충분 해서. .굳이 tfs 도입할 이유가 생각나지 않는군요.

    vs 플러그인으로 연동하면 그만이라서..

  2. JIN 2016.08.29 11:56 Address Modify/Delete Reply

    정성스레 작성하신 글 잘 보고 갑니다..
    TFS를 프로젝트에 처음 적용해 나가면서 어떤것인가 하고 경험해 가는 중에 포스팅 하신 몇몇 글들을 읽었습니다. ALM툴/서비스는 처음인지라 TFS가 정말 적당한지 어떤지에 대한 개념도 없이 아래의 몇가지 장점만으로 선택을 했습니다.
    처음엔 제목만 보고 아뿔싸 'TFS' 문제가 많은가보다 하고 심장이 쫀득해졌다가,
    객관적으로 분석해주신 내용을 보고 오히려 최고는 아니었어도 현재로써는 적절한 선택이었다는 생각이 들더군요..

    1. 현재 팀원이 1.2(12명 아닙니다 ㅎㅎ)명.. TFS 정책상 부담없이 쓸수 있고, 중장기적으로 팀이 5명까지 커질일이 없다는점
    2. 현재 Visual Studio를 사용중이며
    3. 1의 이유로 새로운 툴/서비스에 대한 시장조사/검증 자체가 부담
    4. 중앙 집중식 버전 컨트롤
    5. 그나마 접하고, 본게 이것
    6. 처음엔 단지 소프트웨어 버전컨트롤 이상도 이하도 아닌 이유로 사용함
    7. FDA 승인을 필요로 하는 제품 개발과 깊은 관련이 생기면서 Validation 문제에 봉착
    (FDA regulation 의 Validation 입니다 이는 Software의 Validation과는 다른 훨씬더 확장된 내용을 다루고 있습니다. 첨언하면, Software의 Validation하면 Software의 Specification과 Use case를 따르는 기능의 검증이 촛점이라면, FDA의 것은 SDLC를 어우르는 광범위한 Traceablity, 시스템 검증, 변경 관리 등등.. 전사적으로 등골빠지는 것중의 하나가 FDA 승인이죠..)
    8. 다만 7의 결과물이 Documented Evidence 가 되어야 하는게 FDA의 요구사항입니다. TFS내의 WORK ITEM과 Design Specification, Code, Test, Debug(issue) 등의 결과물이 문서상에 존재해야 한다는것이었죠.. 이 작업은 사람을 미치게도 할수 있는 부분입니다.. ㅎㅎ 이부분은 TFS에서도 직접적으로 문서화를 위한 솔류션을 통합한것은 아닌거 같더라구요 때문에 Modern Requirements라는 솔루션을 채택했습니다.. 이는 TFS상의 WORK ITEM의 부모자식관계 변경 이력, User Requirements, Design Specification, Code, Test, Debug(Issue) 의 Traceability등을 자동으로 생성해주는 역할을 합니다..
    9. 그 외에도 TFS가 'Microsoft' 라는 알려진 기업의 솔루션이기에 직접 구축한 Opensource based 시스템이나 시장에 인지도가 없는 회사의 솔류션일 경우 FDA의 Audit시에 수없이 많은 질문을 야기할 가능성을 줄여줄수 있다는 점도 큰 몫이었습니다.