태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

소스코드 관리 방법 조사 결과

2009/02/22 23:23 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed
그동안 제 블로그에서 약 20일간 기업의 소스코드 관리 방법 투표를 진행했습니다.
현재 각 기업들의 소프트웨어 개발 환경 및 현황을 파악하고 공유하기 위해서 소프트웨어 개발에 대한 다양한 설문 조사를 시행하고 있습니다.

이번 소스코드관리 설문의 질문은 다음과 같습니다.


소스코드는 어디에 보관하세요?

(최신 소스코드의 기준이 되는 저장 장소를 선택해주세요. 다중 선택 가능)


약 3주간의 설문 결과 아래와 같은 분포가 나왔습니다.

Answer TextVotes%
Subversion 50 45.87%
CVS 18 16.51%
개인 PC에 보관 14 12.84%
공용개발서버에 보관 8 7.34%
Visual SourceSafe 7 6.42%
IBM Rational ClearCase 4 3.67%
FileServer에 보관 3 2.75%
실운영서버에 보관 2 1.83%
GIT 2 1.83%
BitKeeper 0 0%
Bazaar 0 0%
SVK 0 0%
Mercurial 0 0%
RCS 0 0%
Other answer... 1 .92%

일단, 예산대로 소스코드관리시스템중에서는 Subversion이 압도적인 1위를 차지했습니다.
그리고 CVS가 2위, VSS가 3위입니다.


하지만 소스코드관리시스템을 사용하지 않고, 일반 서버나 개인PC에 보관한다는 응답도 꽤(25%) 많았습니다.
아래 수치는 내가 컨설팅을 하면서 보아온 비율과 크게 다르지 않습니다. 하지만, 소스코드관리시스템을 사용하는 방법에 있어서는 많은 차이들이 있기 때문에 소스코드관리시스템을 얼마나 잘 활용하고 있는지에 대해서는 또다시 조사를 하는 것도 의미가 있다고 생각합니다.



그중에서도 특히 개인 PC에 많이 소스코드를 보관하고 있는 것으로 조사가 되었습니다. 다음은 소스코드관리시스템이 아닌 장소에 소스코드를 보관하는 방법중에서의 비율입니다.


위와 같이 소스코드관리시스템을 사용하지 않고 개발을 하는 방법은 대단히 불편하며, 쓸데 없는데 시간과 노력을 빼앗기는 정말 비효율적인 방법이 아닐 수 없습니다. 설령 소스코드관리시스템을 사용하고 있다고 하더라도, 소스코드의 기준이 개인 PC나 서버에 보관된 소스코드라면 소스코드관리시스템을 사용하고 있는 것과 크게 다르지 않습니다.

소스코드관리시스템을 사용하지 않으면 당장 겪는 어려움은 다음과 같습니다.

  • 최신 소스코드를 쉽게 파악하기 어렵고 이게 정말 최신 소스인지 확인이 어렵다.
  • 소스코드 공유가 불편하다.
  • 소스코드를 동시에 수정하는 등의 협업이 불편하다.
  • 소스코드를 안정적으로 백업 받을 수가 없다.
  • 소스코드의 변경에 대한 히스토리를 파악하기 어렵다.
  • 소스코드에 베이스라인 설정이 불편하다.
  • 소스코드의 변경과 버그의 연관성을 파악하기 어렵다.

이정도는 아주 기본적인 불편함에 속합니다. 좀더 나아가면 엄청나게 복잡해집니다. 왠만한 규모의 회사도 소스코드의 관리는 꽤 복잡하며 이률 효율적으로 관리하지 않으면 생산성을 높이기가 어렵습니다. 다음과 같은 일들이 벌어지는 상황에서는 더욱더 소스코드관리시스템이 필요합니다.

  • 동일 제품이 신규 개발과 유지보수가 동시에 진행되고 있다.
  • 여러 개발팀이 동일한 소스코드를 동시에 수정한다.
  • 서로 릴리즈 시기가 다른 기능들을 동시에 서로 다른 팀에서 구현하고 있다.
  • 특정 회사의 긴급한 요구에 의해서 소스코드 브랜치가 일어났고, 곧 머지(Merge)할 계획이다.
  • 미국과 중국에 있는 개발자와 동시에 개발을 진행하고 있다.

소스코드관리시스템없이 소프트웨어 개발을 하고 있다면 이는 한마디로 "기적"이며 정말로 쓸데없는 낭비를 하고 있는 겁니다. 소스코드관리시스템없이 소프트웨어를 개발한다는 것은 상상할 수도 없으며, 이미 소스코드관리시스템을 사용하고 있는 화사는 과거로 돌아가서 소스코드관리시스템 없이 개발하라고 하면 그런 상황은 상상하기도 싫을 겁니다.
소스코드관리시스템은 일단 설치해서 사용하는 것은 쉽게 할 수 있지만, 제대로 사용해서 생산성을 극대화하는 것은 상당히 어렵습니다. 앞으로 이에 대한 설문도 진행해 볼 계획이고, 블로그 글도 작성을 해보려고 합니다.




저작자 표시 비영리 변경 금지

전규현 기반시스템/소스코드관리

Trackback Address: http://allofsoftware.net/trackback/88 관련글 쓰기
  1. 2009/03/28 09:02
    오래된 문서 - 실루엣 형상관리 방안 Tracked from 머샤의 인생과 웃기는 고양이
  1. 수고하셨네요. 좋은 내용을 열심히 잘 정리해주신것 같아요.

  2. 안녕하세요. 수경씨
    제가 한건 별로 없고, 독자들이 열심히 투표를 해준 덕분이죠. ^^

  3. 재미있는 글 잘 봤습니다.
    저는 기타(0.9 %)에 속하는 군요. 빨리 Subversion으로 갈아타고 싶습니다 ㅠㅠ

  4. 헝그리맨님 안녕하세요.
    기타에 속한다는 것은 위에서 예로 든 툴이 아닌 전혀 다른 툴을 쓴다는 것이네요? 뭘 쓰시나요? Migration에 대해서 궁금하신 점이 있으면 제가 알려드릴께요. 감사합니다.

  5. 안녕하세요.
    저희는 StarTeam 을 사용중인데요, SVN으로 마이그레이션을 검토해본적이 있는데, 저희가 사용중인 버전이 너무 구버전이라 마이그레이션이 안되네요. 혹시라도 좋은 방법이 있다면 알려주시면 감사하겠습니다.

  6. 많은 회사들이 소스코드관리시스템의 마이그레이션 문제로 고민을 하고 있고, 이슈가 복잡하여 그냥 쓰는 경우가 많습니다.
    사실 제가 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를 해서 사용하는 것도 좋을 듯 싶습니다.

    이미 이렇게 생각을 하고 계셨을 수도 있겠네요. 어쨋든 확신을 하는데, 도움이 되면 좋겠습니다.

  7. 저도 SVN 사용중입니다.
    CVS가 생각보다 낮네요

  8. wifil님 안녕하세요.
    저도 여러가지 소스코드관리시스템을 사용해봤지만, SVN이 가장 만족스럽습니다.

문서를 작성하면 더 오래 걸린다는 고정관념

최근에 국내 유수 대학의 컴퓨터 공학 교수를 만난 적이 있다. 그 교수님도 문서를 작성하면서 Software를 개발하면 더 오래 걸린다고 굳게 믿고 있었다. 어느 정도 이해가 되는 상황이다. 원래 소프트웨어 공학은 실전에서..

이슈를 모으기도 정말 어렵다.

많은 회사들이 개발 프로세스 개선을 하겠다고 선진 개발 방법론을 흉내내거나 실패한 대기업의 프로세스를 가져다가 적용하곤 한다. 복잡한 프로세스와 많은 Template를 가져다가 적용해보려고 하는데 대부분은 실패를 한다. 기초..

변화에 실패하는 9가지 고정관념

회사는 끊임없이 변화하지 않으면 지속 성장하지 못한다. 하지만 변화는 피와 살을 깍는 고통을 동반하고 또 많은 회사가 변화에 실패해서 성장하지 못하거나 사라져간다. 보통의 사람들은 대부분 변화를 싫어하고 기존에 하던대로 계속..

좋은 프로그래머가 되는 24가지 방법

1. 프로그래밍에 열정이 있어야 한다. 열정이 없고 즐기지 못하면 평생하기 어려운 일이다. 2. 프로그래밍 기초 원리를 완전히 이해해야 한다. 원리를 모르면 근본적인 해결을 할 수 없다. 3. 문제 해결 능력을 키워야 한다...

요즘 실리콘밸리에서는...

얼마전 실리콘밸리의 한 Startup company에서 CTO로 일하고 있는 오랜 친구가 한국에 놀러와서 같이 여행을 갔다. Informix에서 소프트웨어 엔지니어로 시작해서 한 20년 정도 일한 중국인 친구다. 같이 일을..

전문가 vs. 책임자

우리나라 조직문화는 전문가보다 책임자를 선호한다. 조직의 장이 책임을 지고 모든 일을 알아서 하는 것이다. 상명하복 관계 위주다. 경영자가 SW개발에 대해서는 잘 모르는 경우 누구 한명이 책임지고 개발해줬으면 하는 생각을 하..

소프트웨어 회사의 자산은?

소프트웨어 회사의 자산은 무엇일까? 흔히 개발자가 소프트웨어 회사의 재산이라고 한다. 이런 회사일 수록 회사가 가지고 있는 것은 정말 개발자밖에 없다. 또한 파악하기 어려운 한 무더기의 소스코드가 있다. 개발자들이 나가면 이..

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..