그동안 제 블로그에서 약 20일간 기업의 소스코드 관리 방법 투표를 진행했습니다.
현재 각 기업들의 소프트웨어 개발 환경 및 현황을 파악하고 공유하기 위해서 소프트웨어 개발에 대한 다양한 설문 조사를 시행하고 있습니다.
이번 소스코드관리 설문의 질문은 다음과 같습니다.
| 소스코드는 어디에 보관하세요? (최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능) |
약 3주간의 설문 결과 아래와 같은 분포가 나왔습니다.
| 0% | 27% | 54% | COUNT | PERCENT | ||||
|---|---|---|---|---|---|---|---|---|
| COUNTRY | OVERALL | |||||||
| Subversion | 302 | 54.41% | 54.41% | |||||
| CVS | 38 | 6.85% | 6.85% | |||||
| Visual SourceSafe | 28 | 5.05% | 5.05% | |||||
| Team Foundation Server | 16 | 2.88% | 2.88% | |||||
| IBM Rational ClearCase | 16 | 2.88% | 2.88% | |||||
| RCS | 2 | 0.36% | 0.36% | |||||
| Git | 38 | 6.85% | 6.85% | |||||
| Mercurial | 13 | 2.34% | 2.34% | |||||
| SVK | 0 | 0% | 0% | |||||
| Bazaar | 1 | 0.18% | 0.18% | |||||
| BitKeeper | 0 | 0% | 0% | |||||
| FileServer에 보관 | 14 | 2.52% | 2.52% | |||||
| 개인 PC에 보관 | 41 | 7.39% | 7.39% | |||||
| 공용개발서버에 보관 | 26 | 4.68% | 4.68% | |||||
| 실운영서버에 보관 | 6 | 1.08% | 1.08% | |||||
| Other: | ||||||||
일단, 예산대로 소스코드관리시스템중에서는 Subversion이 압도적인 1위를 차지했습니다.
그리고 CVS가 2위, VSS가 3위입니다.
하지만 소스코드관리시스템을 사용하지 않고, 일반 서버나 개인PC에 보관한다는 응답도 꽤(25%) 많았습니다.
아래 수치는 내가 컨설팅을 하면서 보아온 비율과 크게 다르지 않습니다. 하지만, 소스코드관리시스템을 사용하는 방법에 있어서는 많은 차이들이 있기 때문에 소스코드관리시스템을 얼마나 잘 활용하고 있는지에 대해서는 또다시 조사를 하는 것도 의미가 있다고 생각합니다.
그중에서도 특히 개인 PC에 많이 소스코드를 보관하고 있는 것으로 조사가 되었습니다. 다음은 소스코드관리시스템이 아닌 장소에 소스코드를 보관하는 방법중에서의 비율입니다.
위와 같이 소스코드관리시스템을 사용하지 않고 개발을 하는 방법은 대단히 불편하며, 쓸데 없는데 시간과 노력을 빼앗기는 정말 비효율적인 방법이 아닐 수 없습니다. 설령 소스코드관리시스템을 사용하고 있다고 하더라도, 소스코드의 기준이 개인 PC나 서버에 보관된 소스코드라면 소스코드관리시스템을 사용하고 있는 것과 크게 다르지 않습니다.
소스코드관리시스템을 사용하지 않으면 당장 겪는 어려움은 다음과 같습니다.
- 최신 소스코드를 쉽게 파악하기 어렵고 이게 정말 최신 소스인지 확인이 어렵다.
- 소스코드 공유가 불편하다.
- 소스코드를 동시에 수정하는 등의 협업이 불편하다.
- 소스코드를 안정적으로 백업 받을 수가 없다.
- 소스코드의 변경에 대한 히스토리를 파악하기 어렵다.
- 소스코드에 베이스라인 설정이 불편하다.
- 소스코드의 변경과 버그의 연관성을 파악하기 어렵다.
이정도는 아주 기본적인 불편함에 속합니다. 좀더 나아가면 엄청나게 복잡해집니다. 왠만한 규모의 회사도 소스코드의 관리는 꽤 복잡하며 이률 효율적으로 관리하지 않으면 생산성을 높이기가 어렵습니다. 다음과 같은 일들이 벌어지는 상황에서는 더욱더 소스코드관리시스템이 필요합니다.
- 동일 제품이 신규 개발과 유지보수가 동시에 진행되고 있다.
- 여러 개발팀이 동일한 소스코드를 동시에 수정한다.
- 서로 릴리즈 시기가 다른 기능들을 동시에 서로 다른 팀에서 구현하고 있다.
- 특정 회사의 긴급한 요구에 의해서 소스코드 브랜치가 일어났고, 곧 머지(Merge)할 계획이다.
- 미국과 중국에 있는 개발자와 동시에 개발을 진행하고 있다.
소스코드관리시스템없이 소프트웨어 개발을 하고 있다면 이는 한마디로 "기적"이며 정말로 쓸데없는 낭비를 하고 있는 겁니다. 소스코드관리시스템없이 소프트웨어를 개발한다는 것은 상상할 수도 없으며, 이미 소스코드관리시스템을 사용하고 있는 화사는 과거로 돌아가서 소스코드관리시스템 없이 개발하라고 하면 그런 상황은 상상하기도 싫을 겁니다.
소스코드관리시스템은 일단 설치해서 사용하는 것은 쉽게 할 수 있지만, 제대로 사용해서 생산성을 극대화하는 것은 상당히 어렵습니다. 앞으로 이에 대한 설문도 진행해 볼 계획이고, 블로그 글도 작성을 해보려고 합니다.
수고하셨네요. 좋은 내용을 열심히 잘 정리해주신것 같아요.
답글삭제재미있는 글 잘 봤습니다.
답글삭제저는 기타(0.9 %)에 속하는 군요. 빨리 Subversion으로 갈아타고 싶습니다 ㅠㅠ
안녕하세요. 수경씨
답글삭제제가 한건 별로 없고, 독자들이 열심히 투표를 해준 덕분이죠. ^^
헝그리맨님 안녕하세요.
답글삭제기타에 속한다는 것은 위에서 예로 든 툴이 아닌 전혀 다른 툴을 쓴다는 것이네요? 뭘 쓰시나요? Migration에 대해서 궁금하신 점이 있으면 제가 알려드릴께요. 감사합니다.
저도 SVN 사용중입니다.
답글삭제CVS가 생각보다 낮네요
wifil님 안녕하세요.
답글삭제저도 여러가지 소스코드관리시스템을 사용해봤지만, SVN이 가장 만족스럽습니다.
안녕하세요.
답글삭제저희는 StarTeam 을 사용중인데요, SVN으로 마이그레이션을 검토해본적이 있는데, 저희가 사용중인 버전이 너무 구버전이라 마이그레이션이 안되네요. 혹시라도 좋은 방법이 있다면 알려주시면 감사하겠습니다.
많은 회사들이 소스코드관리시스템의 마이그레이션 문제로 고민을 하고 있고, 이슈가 복잡하여 그냥 쓰는 경우가 많습니다.
답글삭제사실 제가 StarTeam을 써본적이 없기 때문에 일반적으로 Migration이슈를 설명해보죠.
우선 StarTeam이 어떤 문제가 있는지 정리를 한번 해보세요.
현재까지 몇년을 썼고, 어떠한 History들이 쌓여 있고, 기능이 부족해서 문제가 된 적은 없는지, 장애나 불편함이 있었는지, 그로 인해서 개발에 어떤 문제가 있었는지 정리를 해보세요.
그리고나서 StarTeam을 앞으로 10년을 더 쓸 수 있는지 판단을 해봅시다. 10년을 더 쓰는데 아무 문제가 없다면 그냥 쓰면 되겠죠. 그렇지 않다면 Migration으로 결정입니다.
그런데, 많은 소스코드관리시스템들이 서로 과거 History까지 호환이 되면서 Migration이 되는 경우는 그렇게 많지 않습니다. 또 많은 회사들이 과거 History가 너무 중요할만큼 History를 잘 남기지도 않습니다. 어쨋든 Migration을 결정했다면 이슈가 줄어 들었습니다. History까지 Migration이 되더라도 Tag나 Branch등 모든 것이 다 Migration 되는 경우도 드믈죠. 그래서 새로운 소스코드관리시스템을 사용하더라도, 과거에 사용하던 StarTeam은 1년건, 2년이건 더이상 필요없다는 확신이 설 때까지 Read only로 계속 운영을 하면 됩니다.
그리고 이번 기회에 소스코드를 깨끗히 정리하고 SVN에 import를 해서 사용하는 것도 좋을 듯 싶습니다.
이미 이렇게 생각을 하고 계셨을 수도 있겠네요. 어쨋든 확신을 하는데, 도움이 되면 좋겠습니다.
Ray님과 버전관리에 대한 댓글을 주고 받다보니, 갑자기 예전에 실루엣을 개발해서 처음으로 실루엣의 소스를 실루엣에 올렸던 기억이 납니다. 개밥이라고 하죠 :) 실루엣 형상관리방안.pdf 벌써 3년이나 지난 문서를 CMS(Content Management System)인 CodeInside2에서 찾아 봤습니다. 지금 보면 초라하기 짝이 없는 문서이지만, 팀 자신이 판매하는 도구를 자신이 직접 사용 해 봄으로서 아주 귀중한 경험을 할 수 있었습니다...
답글삭제