태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

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이 가장 만족스럽습니다.

관리자가 이런 일까지?

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

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

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

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

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

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..