소스코드관리시스템 사용도 2차 조사 결과

2009년 2월에 이와 동일한 조사를 한 적이 있었습니다.

2009/02/22 - [기반시스템/소스코드관리] - 소스코드 관리 방법 조사 결과

그때도 약 20일간 조사를 했었고, 이번에도 마찬가지로 20일간 조사를 했습니다. 

2009년에는 109명이 참여를 했는데 이번에는 370명이 넘는 인원이 참여를 해서 더 정확한 결과가 나왔을 것으로 기대합니다.

이번 설문의 핵심은 소스코드관리시스템을 사용하는지? 사용하지 않는지? 또, 사용한다면 어떤 시스템을 사용하고 있는지를 알아내는 것이었습니다.

2009년초와 비교를 해보면 꽤 많은 변화가 있었음을 알 수 있습니다.

가장 큰 변화를 요약하면 다음과 같습니다.

• 소스코드관리시스템 사용률의 향상
• CVS, VSS의 몰락
• Git의 약진
• Subversion(SVN)의 꾸준한 증가

그럼 조사 결과를 살펴 보도록 하겠습니다.

소스코드관리시스템을 사용하고 있는 그룹에서만 통계를 내보면 여전히 Subversion이 압도적인 1위를 차지하고 있고, CVS와 VSS의 사용률이 많이 떨어지면서 Git가 크게 치고 나온 것을 알 수 있습니다. Mercurial의 가세까지 보면 분산소스코드관리시스템에 대한 관심이 많이 높아졌음을 알 수 있습니다.

또한 더 다양한 소스코드관리시스템의 사용을 시도해보고 있는 것이 눈에 띕니다.

소스코드관리시스템을 사용하는 비율도 많이 높아졌습니다. 그동안 책이나 블로그를 통해서 소스코드관리시스템을 사용하지 않고 소프트웨어를 개발하는 것은 기적에 가깝다고 하였는데, 이는 긍정적인 신호로 생각됩니다.

물론 소스코드관리시스템을 사용하고 있는 83%에서도 제대로 사용하고 있는 비율은 극히 낮습니다. 그래도 사용하기 시작한 것만 해도 큰 의미라고 생각됩니다.

많은 발전이 있었음에도 여전히 소스코드관리시스템을 사용하지 않는 개발자나 회사가 많이 있고 그 속에서의 비율은 큰 차이가 없어 보입니다.

소스코드관리시스템을 100%의 개발자들이 사용하고, 또한 제대로 사용할 수 있는 날까지 계속 노력을 합시다. 

저는 수많은 회사에서 소프트웨어 공학/경영 컨설팅을 진행하면서 소스코드관리시스템이 개발 문화를 긍정적으로 상당히 많이 바꾸는 것을 보아 왔습니다. 소스코드관리시스템 없이 소프트웨어를 개발한다는 것은 남들은 총들고 전쟁할 때 돌멩이 들고 싸우겠다는 것과 같습니다. 일단 무기가 있어야 싸움을 시작할 수 있을 것 아닙니까?

그리고 나서야 기술이나 전략이 의미가 있어집니다. 돌멩이 들고 싸우면서 전략을 논할 수는 없습니다.

물론 이와 같이 꼭 필요한 무기들은 몇가지 있습니다. 이런한 것들이 기본은 되어야 글로벌 소프트웨어 회사들과 경쟁이란 것을 생각해 볼 수 있습니다. 그렇다고 물론 경쟁이 된다는 것이 아닙니다. 이제 시작할 수 있다는 것 뿐입니다. 

그리고 나면 진짜 개발 실력, 전략, 마케팅이 필요한 때입니다. 하지만 국내 대부분의 소프트웨어 회사들은 아직 글로벌 경쟁은 생각하지도 못할 수준인데 단순히 요소기술만 가지고 경쟁을 할 수 있다고 착각하는 경우가 많습니다.

이번 조사 결과를 보면서 점점 긍정적인 신호들을 느낍니다. 앞으로 좀 더 깊은 내용들도 풀어 나가도 될 것 같습니다.

조사에 협조해주신 모든 분들께 감사드립니다.

VSS, CVS, SVN 비교

Google Trend에서 세가지 SCM(Software Configuration Management)의 경향을 살펴봤습니다. (아래 그림 참조)

CVS가 여전히 압도적인 우위를 점하고 있고, 상대적으로 SVN은 꾸준히 성장을 하고 있습니다. 물론 Google Trend가 실제 제품의 점유율을 보여주지는 않지만 그만큼 사람들의 관심사는 엿볼 수 있을 것 같습니다.

CVS의 감소는 SVN으로 대체되고 있는 듯 보입니다.

하지만 이렇게 더딘 이유는 CVS도 충분히 좋은 SCM이고 더 좋은 SCM이 나왔다고 함부로 바꿀 수 있는 것이 아니기 때문입니다.

물론 새로 시작하는 회사가 있다면 SVN을 쓰면 좋겠지만, 기존에 수년가 CVS를 쓰던 회사가 치명적인 문제도 없는데 SVN을 그냥 바꿀 필요는 없겠지요.

(3가지를 비교한 그래프입니다. SVN의 성장이 눈이 띕니다. 아래 Comment의 권남님이 제시한 그래프를 보면 SVN의 비율이 훨씬 더 높아지네요. 그리고 미국과 인도에서의 CVS 검색 비중이 아주 높고 나머지 나라에서는 SVN이 더 높은 나라가 많네요.)

(VSS는 점차 감소 추세입니다.)

(CVS는 약간의 감소추세이나 급격하지는 않네요)

(SVN의 성장 추세는 괄목할 만하네요)

CVS와 SVN의 비교는 이미 제가 글을 올린 적이 있으므로 그 내용은 생략하고 주로 VSS와 SVN을 비교해볼까 합니다.

제가 가장 오랫동안 사용한 SCM은 VSS입니다. 제가 사용한 VSS는 v6.0이었습니다.

물론 유료지요. 하지만 제가 종종 겪었던 가장 큰 문제는 깨지는 저장소였습니다. CS구조가 아닌 NFS 방식으로 파일을 공유하기 때문에 그런 문제가 있었던 것으로 생각합니다. 물론 VSS 2005에서 안정성(stability)를 향상하고 HTTP를 지원한다고 하지만 그 당시는 제가 SVN을 사용하고 있을 때라서 VSS가 얼마나 좋아졌는지 모릅니다. 혹시 최신 VSS를 쓰고 계신 분은 평가를 올려주시면 좋겠습니다.

하지만, 안정성이 가장 중요한 요소 중 하나인 SCM에서 자주 깨지는 저장소는 신뢰를 잃기에 충분했습니다. 

매일 백업을 받고 있었으므로 몇 시간 분량의 손실만 있을 뿐 복구는 할 수 있었지만, 개발 시간을 낭비하게 만드는 것은 아주 짜증나는 일이었습니다.

그리고 허약한 Branch기능은 부족한 기능 중에 하나였습니다.

그 뒤에 CVS를 거쳐서 SVN을 사용하게 되었는데, 제가 써본 SCM 중에서 최고는 SVN입니다.

VSS < CVS < SVN 이라고 생각합니다.

SVN은 일단 무료이며, 그 오랫동안 사용하면서 저장소는 단 한번도 깨진 적이 없습니다.

그리고 빠릅니다. 아무리 큰 디렉터리를 태깅하거나 브랜치를 해도 시간은 몇 십초 안 걸립니다.

CVS에서 엄청나게 큰 디렉터리 태깅하면서 기다려보신 분은 아실 겁니다.

그렇게 빠른 이유는 SVN은 기존의 SCM의 파일 시스템과 완전히 다른 방식을 사용하고 있기 때문입니다. 기존의 대부분의 SCM들이 RCS(Revision Control System)에서 기초한 파일시스템을 사용하는데 반해서 SVN의 파일시스템은 기존의 단점을 없애고 새로 만들었습니다. 즉 각 Revision의 Diff만 저장하는 방식입니다.

따라서 태그나 브랜치를 만들 때는 Diff가 없으므로 순식간에 이루어집니다.

그리고 SVN의 VSS와 비교한 장점 중의 하나가 협업이 훨씬 쉬워졌다는 겁니다.

SVN도 Lock기능이 있지만, 이걸 사용하지 않고도 협업에 문제가 없습니다. 왜냐하면 하나의 파일을 동시에 수정할 경우에는 Merge를 해주기 때문입니다. 이때 사용하는 3way Merge에 대해서는 제가 올린 글이 있으니 참조하세요.

기존에 VSS를 사용할 때는 물론 Multi-lock 기능이 있기는 하지만, 며칠씩 Lock을 걸어 놓고 풀지 않는 사람 때문에 보통 귀찮은 게 아니었습니다. SVN을 사용하면서 이런 문제는 싹 사라졌습니다.

VSS를 사용하면서는 IDE와 통합되는 기능이 왠지 멋져 보이고 매우 편리하다고 생각했었는데, SVN과 TortoiseSVN을 IDE와 별도로 쓰면서 불편하게 생각되어 본 적이 별로 없었습니다. SVN도 IDE와 통합해주는 Plug-in들이 있지만 이는 취향에 따라서 선택하면 되고 꼭 써야 하는 필수요소는 아닙니다.

결국 SVN의 빠른 속도, 안전한 저장소, 뛰어는 브랜치 기능, 머지기능 등은 저와 저희 팀이 즐겁게, 제대로 일하는데 많은 도움을 주었습니다.

누군가 새로 SCM을 사용하려고 한다면 SVN을 추천합니다.

소스코드관리시스템을 몇개 사용하고 있나요?

소프트웨어 개발 컨설팅을 하다보면 여러가지 경우를 보지만 그중의 한 예를 소개할까 합니다.

국내의 굴지의 금융회사 중의 한 사례입니다.

회사 내에서 각 팀별로 소스코드관리시스템을 여러 개를 사용하고 있더군요.

A팀 Windows 플랫폼의 Application를 개발하니까 Microsoft Visual SourceSafe를 사용하고

B팀 Web 서비스를 개발하고 있었는데, CVS를 사용하더군요.

그리고 C팀은 Unix에서 개발을 하는데, 아무런 소스코드관리시스템을 사용하고 있지 않았고,

D팀은 별로 잘 알려져 있지 않은 외국의 상용 제품의 한글화된 버전을 사용하고 있었습니다.

한 회사에 총 4가지 유 형의 소스코드 관리가 존재하는 겁니다.

이런 상황에서는 다음과 같은 부작용이 생깁니다.

• 개발자들이 다른 부서로 이동할 때 쓸데 없는 학습 비용이 들어 갑니다.
• 중복된 시스템 및 관리 비용이 들어갑니다. 소스코드관리시스템은 비용이 많이 들어가는 시스템입니다. 
• 각 부서간의 정보의 공유가 어렵게 됩니다.

이런 일들이 발생하는 이유는 다음과 같습니다.

• 회사에서 기술적인 결정을 컨트롤하는 상위 조직이 없어 개발자들의 입맛에 따라 각각 다른 시스템을 쓰게 된 경우
• 회사를 인수하면서 기존의 시스템을 그대로 사용하고 통합을 시도하지 않은 경우

소스코드관리시스템은 한 회사에 딱 하나만 설치하는 것이 좋습니다. 세계 각지에 떨어져서 개발을 하더라도 하나의 소스코드관리시스템을 사용해야 합니다.

만약 이미 여러가지 소스코드관리시스템을 사용하고 있다면 비용을 지불하고라도 통일을 하는 것이 좋습니다.

이러한 통일 작업은 기계적으로 할 수도 없는 어려운 작업이 됩니다. 

하지만 늦어질 수록 더 많은 비용을 치르게 됩니다.