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

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

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

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

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

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

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

혼자서 개발을 하면 소스코드의 브랜치/머지가 필요없을까?

소스코드관리에 대해서 얘기를 하다보면 혼자서 개발을 하기 때문에 별 고민 없이 대충 소스코드를 관리하는 경우를 많이 봤습니다.

Subversion 등의 소스코드관리시스템을 쓰더라도 그냥 소스코드를 백업 받는 수준으로 사용하고 많이 사용하면 Baseline설정(Tagging)정도 하곤하더군요. 그러면서 혼자서 개발을 하기 때문에 소스코드의 브랜치/머지가 필요 없다고 생각합니다. 하지만 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황은 꼭 발생하기 마련입니다. 만약에 이러한 상황에서 브랜치/머지를 능수능란하게 하지 못하면 기존의 수작업에 의존하는 방식으로 처리를 하면서 소스코드관리시스템이 주는 큰 혜택을 누리지 못하게 됩니다.

또, 개발자는 한명이 아니더라도 마치 혼자서 개발을 하는 것처럼 개발자들끼리 담당 소스코드를 철저히 나눠서 서로 충돌이 나는 일이 없도록 개발을 하는 경우가 허다합니다. 이런 것을 Component Owner라고 하고 이런 체제에서는 개발자들 간의 기술의 공유가 어려워지고 회사의 규모가 커질수록 개발 효율성은 점점 떨어지게 됩니다.

그럼, 어떤 상황에서 혼자서 개발을 하더라도 소스코드 브랜치/머지가 필요한 상황이 발생하는지 알아보도록 하겠습니다.

첫째, Hotfix인 경우입니다.

소프트웨어의 종류는 워낙 다양하기 때문에 획일적으로 말할 수 없습니다. 그래서 간단한 예를 하나 들어보죠. 매일 한번씩 패치를 만들어서 정해진 시간에 인터넷으로 업데이트를 하는 소프트웨어를 개발하고 있다고 칩십니다. 오늘 오후 5시에 내보낼 패치에 들어갈 Bug fix와 Feature를 열심히 넣고 있는데 긴급 Hotfix 상황이 발생한 겁니다. 따라서 정식 패치때까지 기다릴 수는 없고 일단 시급한 버그 하나만 고쳐서 서둘러서 업데이트를 해줘야 합니다. 이러한 상황에서 소스코드관리시스템을 사용하는 능숙도에 따라서 대처하는 방법들이 매우 다릅니다.

하수

소스코드관리시스템을 거의 제대로 쓰지 못하는 경우, 오늘 고치고 있는 소스코드를 수동으로 하나씩 지워서 원래 버전을 만들어냅니다. 이러한 경우는 믿기 힘들겠지만 제가 컨설팅을 하면서 많은 회사들이 이렇게 하고 있다는 것을 접했습니다. 이렇게 원래 버전을 만들어서 Hotfix를 만들어서 내보낸 후에 다시 재작업을 합니다.

중수

이보다 조금더 나은 경우, 원래 고치고 있던 소스코드의 디렉토리를 임시로 백업 받아 놓고 소스코드관리시스템에 있는 어제 버전의 소스코드를 다시 Check out합니다. 이렇게 Check out한 소스코드를 가지고 Hotfix를 만들어서 내보내고 오늘 작업하던 백업을 받아 놓은 소스코드와 Merge tool을 이용해서 Merge를 한 후에 정기 업데이트 버전을 만들어서 내보내는 방법입니다. 아까보다는 조금 나아 졌지만, 여전히 수작업에 많이 의존을 하고 귀찮은 작업들을 해줘야 합니다.

고수

Subversion등의 소스코드 관리시스템을 제대로 사용한다면 이보다 좀더 손쉽습니다. 

우선 어제 릴리즈를 한 소스코드의 Baseline(Tag)에서 Hotfix용 브랜치를 만듭니다. 기존에 개발하고 있던 디렉터리는 그대로 놔두고 새로운 디렉터리에 Hotfix를 Check out 받습니다. 보고된 버그를 수정하여 자동화된 빌드스크립트를 이용해서 Hotfix를 만들어내고 업데이트에 올립니다. 정상적으로 Hotfix가 배포된 것을 확인하고 Hotfix 브랜치는 Trunk로 Merge를 합니다. 이때 3Way Merge 툴을 이용하면 됩니다. 

3Way Merge를 적용하려면 3개의 기준점이 필요합니다. 3개의 기준점은 다음과 같습니다.

Base - 어제 릴리즈한 Baseline(Tag)

Their - 오늘 Hotfix 릴리즈한 Baseline(Tag)

Mine - Trunk의 Head revision(최신소스)

3Way Merge를 통하면 거의 99% 자동으로 Merge가 되고 Conflict가 나는 소스코드들도 KDiff3나 P4Merge등의 GUI가 뛰어난 3Way Merge툴을 이용하여 쉽게 Merge를 할 수 있습니다.

그리고 현재 로컬에서 고치고 있던 소스코드와 통합을 해야 합니다. 이를 Rebase라고 하는데 SVN에서는 Update명령을 내리면 서버에서 바뀐 내용이 자동으로 Working copy와 통합이 됩니다. 이때도 3Way Merge를 이용하게 됩니다.

즉, 개발자는 소스코드 내용 고치는데만 신경을 쓰면 되고 나머지는 소스코드관리시스템이 다 알아서 해 줍니다. 소스코드 통합하는데 불과 얼마 걸리지 않고 혼동도 없습니다. 시간은 하수,중수의 수십분의 1이면 가능하게 됩니다.

혼자 개발하더라도 제대로 하지 않으면 이렇게 혼동이 있고 소스코드관리시스템의 기능을 잘 사용만하며 이렇게 손 쉬운데 개발자가 수십명, 수백명이서 하수, 중수의 방법으로 어떻게 소프트웨어를 제대로 개발할 수 있을까요?

물론 이것이 다는 아니죠. 기능을 충분히 사용하는 것은 이제 시작입니다. 더 큰 조직에서 조직적으로 제대로 사용하려면 프로세스, 규칙, 문화 등과 접목되어서 돌아가야 하는데, 이는 더 어렵습니다. 그러데 하물며 기능도 제대로 사용을 못하는 회사가 대부분인데 그 다음은 말할 필요하고 없죠.

Hotfix 경우 외에도 기존 소스코드에 큰 변경을 가해서 성공 여부를 확신할 수 없는 기능을 추가할때.

시간이 오래 걸리는 기능을 추가하면서 중간 중간에 다른 변경에 대한 릴리즈를 해야 할 때.

등 혼자서 개발을 하더라도 Branch/Merge를 해야 할 경우는 수도 없이 나오게 됩니다.

소스코드관리를 너무 쉽게 생각하면 안됩니다. 잘해 놓으면 무척 쉽고 개발에 매우 큰 도움을 주지만, 대충대충 하다보면 큰 발목을 잡히게 됩니다. 혼자 개발하더라도 제대로 하겠다는 마음가짐을 가지고 완벽하게 전체 기능을 다 알아야 합니다. 그리고 나면 이좋은 것을 왜 지금까지는 제대로 하지 않았을까 아쉬움이 들겁니다.

책을 보고 해보는 방법도 있지만 시간이 좀 많이 걸리겠지요. 주변에서 잘아는 사람에게 물어보는 것은 시간을 절약할 수 있는 좋은 방법입니다. 주변에 그런 사람이 없다면 블로그에 궁금한 것을 올려주세요. 제가 힘이 닿는한 잘 설명드리겠습니다. 제가 쓴 책(소프트웨어개발의 모든 것)에서는 이러한 부분이 이론적이 아닌 실제 방법을 자세히 설명하고 있으니 보시는 것도 도움이 많이 될 것입니다.

맥에서 Subversion 사용하기

최근에 맥북을 구매해서 아이폰 개발 작업을 하고 있는데 맥에서 Subversion을 사용하는 환경이 그리 좋지 않다는 것을 알게 되었습니다. 그래서 맥에서 Subversion을 제대로 활용하기 위한 글을 적어보려고 합니다.

Subversion 자체에 대해서는 블로그의 다른 글들을 보시기 바랍니다.

일단 Xcode에는 기본적인 Subversion연동 기능이 포함되어 있습니다. 그런데 막상 써보면 기존에 TortoiseSVN의 뛰어난 기능과 성능에 익숙한 사람들은 불만스럽기 짝이 없습니다. 그래서 맥에서 Subversion을 쓰기 위한 방법을 비교해보도록 하겠습니다. 

• Xcode 기본 기능 
• 유/무료 맥용 SVN Client 사용 - Syncro, Diffly
• 터미널
• 가상머신 + TortoiseSVN 

Subversion 서버는 이미 구축되어 있다고 가정합니다. Subversion서버가 아직 구축되지 않았다면 제 책을 참조하여 Subversion을 구축하시기 바랍니다. 또는 Google Code를 이용하는 방법도 있습니다. Google Code를 이용하면 소스코드가 공개가 되니 소스코드를 공개해도 되는 경우라면 Google Code를 이용하면 편리할 것입니다.

Xcode의 기본 기능 사용

사실 Xcode의 기본 Subversion연동 기능은 그렇게 편리하지 않습니다. 그래도 사용법에 대해서 잠시 알아보죠.

우선 Xcode의 Preferences의 SCM항목에서 이미 구축된 Repository를 등록해야 합니다. 그래야 Xcode에서 해당 Repository와 Xcode 프로젝트를 연결 할 수 있습니다.

그리고 Xcode>SCM>Repositories에서 해당 Repository의 디렉터리를 만들어야 합니다. 

위 그림과 같이 branches, tags, trunk로 나누면 됩니다. 디렉터리를 어떻게 나누냐 하는 이슈는 전략이 필요한 항목이므로 신중하게 판단해야 합니다.

소스코드를 서버에 등록하기 전에 먼저 설정할 것이 있습니다. Subversion에 등록되면 안되는 파일을 설정해야 합니다. ~/.subversion/config파일을 열면 global-ignores 항목이 있습니다. 여기에 등록되면 안되는 파일의 패턴을 적어주면 됩니다. 저는 일단 build 디렉터리만 등록되지 않도록 했습니다. 그외에도 빌드시 생기는 임시 파일들이 있거나 하면 그 패턴을 등록해서 Subversion에 등록되지 않도록 해야 합니다.

그리고 Import 메뉴를 이용해서 Mac에 저장되어 있는 소스코드를 모두 Subversion 서버에 등록합니다. 

이제 서버의 소스코드를 내려 받아야 하는데, 기존에 소스코드가 있던 디렉터리에는 내려 받을 수 없으니 소스코드의 디렉터리를 임시로 바꿔놓고 Check out을 통해서 소스코드를 내려받습니다. 소스코드를 내려 받았다고 해서 Xcode와 바로 연결되지는 않습니다. Xcode연동 기능을 사용하지 않을 거라면 여기까지만 하면 되지만 Xcode와 연동해서 사용하려고 하면 Xcode Project와 Subversion repository를 연결해 줘야 합니다.

Xcode에서 Check out하여 내려 받은 프로젝트를 Open하고 Project info를 보면 우상단에 "Configure Roots & SCM..."이 있습니다.

그 버틑을 클릭하면 이미 등록한 리파지토리중에서 본 프로젝트와 연결한 리파지토리를 선택하도록 되어 있습니다. 간단하게 고르면 됩니다.

그리고 Groups & Files에서 마우스 오른쪽 버튼을 눌러서 SCM을 선택하면 SCM과 연동 상태를 확인할 수 있습니다.

이제 Xcode의 SCM 메뉴를 통해서 소스코드를 관리할 수 있게 됩니다.

기본적으로 소스코드를 Check out하고 Commit하고 Tag, brach까지 이 기능을 이용해서 할 수 있도록 되어 있습니다. 하지만 제가 간략하게 본 바로는 Conflict를 해결하고 Merge를 하는 등의 협업이 필요한 작업은 지원이안되는 것 같더군요. 혹시 제가 모르는 방법이 있다면 알려주세요. 

그래서 이럴 때는 다른 솔루션들을 추가로 사용해야 하겠더군요.

맥용 SVN Client 사용

Syncro, Diffly등 몇몇 유/무료 SVN Client가 있습니다. 하지만 이 부분은 제가 Evaluation을 해보지 않았습니다. 추후 써보게 되면 내용을 보강하도록 하지요.

터미널 사용

Command line에서 SVN을 사용할 수 있다면 Windows, Linux, Mac 어느 OS에서든지 동일하게 SVN을 사용할 수 있습니다. SVN의 모든 기능은 Command line에서 사용할 수 있도록 되어 있습니다. 단지 Merge등의 몇몇기능이 GUI환경에서 더 편한 것 뿐입니다. Mac에서도 Command line 명령어를 이용하여 SVN을 사용할 수 있습니다.

가상머신 + TortoiseSVN 사용

마지막으로 제가 최종적으로 선택한 방법은 TortoiseSVN을 이용하는 방법입니다.

Windows에서 TortoiseSVN을 오랫동안 사용한 개발자라면 그 편리함을 잊지 못할 겁니다.

저는 Parallels Desktop에 Windows7을 설치한 다음에 TortoiseSVN을 사용하고 있습니다.

Mac의 모든 디렉터리가 Windows에서 접근 가능하니 Windows에서 사용하는 것과 거의 동일하게 TortoiseSVN을 사용할 수 있습니다. 이렇게 하여 Windows에서 사용하던 Merge tool도 그대로 쓸 수 있게 되었습니다.

Windows에서 TortoiseSVN을 사용할 경우는 Mac에서 SVN을 설정하는 것과 별도로 Windows에서 SVN을 설정해줘야 합니다. C:\Users\{사용자ID}\AppData\Roaming\Subversion\config 파일을 열어서 아까와 같이 global-ignores를 설정하면 됩니다.

저는 기본적인 SVN Commit기능만 쓸때는 Xcode기본 기능을 사용하고 브랜치, 태그, 머지 기능을 사용할 때는 Tortoise SVN을 사용하고 있습니다. 또한 개발자가 여러명이라면 그냥 TortoiseSVN을 사용하는 것도 좋을 것 같습니다.

이상으로 Mac에서 Subversion을 사용하는 방법을 알아봤습니다. Subversion을 제대로 사용하는 방법은 완전히 별개 이슈이니 제 책과 블로그의 다른 글들을 참고하세요.

수정하거나 덧붙일 내용이 있으면 댓글 남겨 주세요.

Diff and Merge in SCM(Software Configuration Management)

헝그리맨님의 Subversion(TortoiseSVN)의 Diff에서 한글이 깨지는 문제...

에 관한 포스팅에 대하여 답변 겸 SCM에서의 Diff와 Merge에 대해서 글을 남겨 봅니다.

일단 헝그리맨님의 글에 대한 답변을 먼저 해야 겠군요.

사실 그동안 소스코드를 Diff하고 Merge하는데는 GUI Diff, Merge툴의 한글 깨지는 문제는 크게 신경을 쓰지 않았습니다.

• 대부분의 소스코드는 거의 영어로 되어 있고, 
• 주석에 일부 한글이 들어 갔어도 이부분이 수정되서 Diff, Merge가 필요한 부분이 거의 없었고,
• 대부분의 머지는 줄단위로 이루어져서 줄 내에서 한글을 깨지게 표현하는 것은 사실 문제가 안되었습니다.
• 3-way merge를 할때는 오랫동안 Unified diff를 사용했기 때문에 문제가 안되었습니다.

이것은 단지 한글 깨지는 것이 큰 이슈가 아니었다는 얘기입니다.

하지만 한글이 큰 이슈라면 AcroDiff나 WinMerge를 사용하시면 될 것 같습니다.

TortoiseSVN은 외부 Application을 등록하여 사용할 수 있도록 되어 있으니 한글(2byte)문자를 지원하는 AcroDiff나 WinMerge를 사용하세요. 

물론 Araxis Merge같은 상용제품을 사용하시면 금삼첨화지요.

Araxis Merge은 단순히 한글 지원 장점 외에도 3-way Merge를 지원하므로 제대로된 Merge Tool이라고 할 수 있습니다.

3-Way Merge를 지원하는 Merge Tool 중에서 무료로 사용할 수 있는 것은 KDiff3가 있습니다.

GPL 라이센스라서 무료이기는 하나 한글지원에서 약간 문제가 있습니다.

머지 기능 자체의 문제는 아니고 한글 부분이 약간 깨져서 보입니다만 Merge는 잘됩니다.

그래서 저는 KDiff3를 사용합니다.

얘기가 나온 김에 3-Way Merge가 무엇이며 왜 필요한지 "소프트웨어개발의 모든것"이라는 책의 내용을 잠시 소개하겠습니다.

머지(Merge)

머지는 분기된 소스코드를 하나로 합치는 일이다. 머지를 능수능란하게사용할 수 있어야 소스코드관리시스템을 원활하게 사용할 수 있다.

머지는 크게 2-way 머지와3-way 머지로 나뉜다. 2-way 머지는 두 개의 파일을 가지고 서로 다른 부분을 비교하면서하나로 합치는 것이다. 이 방법은 100% 수동에 의존할수 밖에 없다. 서로 다른 부분 중 어느 것을 빼고 어느 것을 남겨야 하는지 어느 것이 옛날 내용이고어느 것이 새로 바뀐 것인지 직접 보고 판단해야 한다. 우리가 흔히 보는 머지툴의 대부분이 2-way 머지툴이다.

위 그림은 파일1과 파일2를합쳐서 파일3을 만들려는 것이다. 파일1과 파일2 는 원래는 하나의 파일이었으나 과거에 브랜치가 되어서 각각따로 수정된 것이다. 이 경우 어떻게 합쳐야 할 지 막막하다. B가 shark일지 monkey일지 판단하는 것이 쉽지 않다. F=mango는 새로 추가된 것인지 원래 있던 것이 반대 파일에서 삭제된 것인지 알기 어렵다. 따라서 소스코드를 잘 알고 있는 사람이 내용을 모두 보고 판단하는 수밖에 없는 것이다.

하지만 3-way 머지는 방법이 좀 다르다. 두 파일을 단순히 비교하는 것이 아니고 두 파일로 나누어지기 전의 파일도 같이 포함하여 비교하며 머지하는 것이다. 그렇게 되면 어떤 내용이 추가되거나 삭제되거나 변경되었는지를 알 수 있기 때문에 최종본으로 합치는 일이 훨씬수월하다. 파일의 충돌만 없다면 자동으로도 머지가 가능하다. 파일의충돌이 있을 경우에만 충돌된 부분을 사람이 판단하여 통합하면 되는 것이다.

여기서 새로 등장한 파일0은 파일1과파일2가 브랜치 되기 전의 원래 파일이다. 파일0, 파일1, 파일2를 각각비교하면, 파일1에서 monkey가 shark로 수정된 것을 알 수 있다. 또, 파일2에서 apple은삭제되고 mango가 추가된 것도 알 수 있다. 이 정도면사람이 별도로 판단할 필요 없이 자동으로 머지가 가능하다. 이러한3-way 머지툴에는 다음과 같은 것들이 있다.

• Perforce Merge
  • Publisher: Perforce software
  • License: 무료
• Araxis Merge
  • Publisher: Araxis ltd.
  • License: 유료
• KDiff3
• Publisher: KDevelop
• License: GPL

이 중에서 KDiff3는 인터넷을 통해서 쉽게 구하여 사용할 수 있다.

3-way 머지를 이용하면 또 다른 기능을 이용할 수도 있는데, 부분 머지(Range Merge)가 바로 그것이다. 예를 들어 브랜치를 하여 수정한 여러 부분에서 특정 부분만 트렁크와 머지를 하고 싶을 때가 있다. 고객의 요구에 의해 브랜치를 했고, 해당 브랜치에는 고객의 특별요구 기능이 반영이 되어 있었다. 그런 다음 브랜치에서 발견한 버그를 수정했는데, 이를 트렁크에도 반영하고 싶을 때가 있다. 이 경우에 3-way 머지를 이용하면 다른 부분은 빼고 버그를 수정한 부분만 골라서 머지를 할 수 있다.

소스코드관리시스템과 3-way 머지툴을 효과적으로 사용하면 머지작업이아주 효율적으로 진행된다. 그러나 3-way 머지가 매우유용한 방법인 것은 사실이나 100% 자동에 의존할 수는 없다.3-way 머지툴이 충돌없이 머지에 성공했다 하더라도, 그 결과를 눈으로 직접 확인하는것이 더욱 안전할 것이다.