2009년 3월 4일 수요일

짝퉁 고수

이 바닥은 이상하리만치 짝퉁 고수들이 많습니다.

자신이 대한민국에서 무슨 기술이 제일 뛰어나다고 소개하는 사람을 종종 만나는데, 대한민국를 개발자 다 만나봤나 반문하고 싶습니다. 또 조금 사용해봤거나 심지어는 어디서 단어만 들어봤어도 그건 아는 거다라고 얘기하는 사람이 정말로 많습니다. 컨설팅을 하면서 개발자들의 정확한 수준을 파악하기 위해서 기술력 조사를 하는데, 자신이 전문가라고 한 항목에 대해서 beginner라도 알 수 있는 내용을 물어봐도 모르는 경우는 허다하더군요.

수많은 사람들이 자신이 고수라고 허위광고를 하고 다니는 이유는 사람들을 속이기 쉽기 때문입니다. 알맹이는 없는 표면적인 지식을 가지고 사람들을 현혹하면 더 많은 연봉을 받을 수도 있고, 더 좋은 프로젝트를 낚아챌 수도 있습니다. 하지만 이런 사람들이 진행하는 프로젝트는 자신의 실력에 비해서 무리하게 벌려 놓다가는 실패하기 일쑤이고, 또 프로젝트가 실패한 이유는 요구사항이 많이 바뀌어서라든가 다른 개발자들이 실력이 없어서라든가 PM이 무능해서 그렇다는 둥 온갖 이유를 대면서 자신의 책임을 피해가다가 약발이 떨어지면 회사를 옮겨서 또 그런 일을 반복합니다.

또, 이런 사람이 컨설팅을 한다고 하면, 자신이 알고 있는 표면적인 지식의 잣대로 수많은 종류의 회사에 적용하려고 하면 제대로 되지 않을 것은 불 보듯 뻔합니다. 그런데, 심지어는 몇 개월의 교육만을 받은 채로 컨설팅에 투입되곤 합니다. 이러한 현상들이 컨설팅 자체를 불신하는 분위기를 만들고 있다고 생각합니다.

이러한 짝퉁 고수, 짝퉁 컨설턴트를 구별하는 방법은 없을까요?
이들보다 실력이 낮은 사람이나 엔지니어가 아닌 경영자나 관리자들은 구별하기 정말 어렵습니다. 또 설령 짝퉁으로 보인다고 해도 이들에 대항해서 논리적으로 반박하기도 어렵습니다. 오히려 본인이 밀려서 낭패를 볼 수도 있습니다. 사기를 많이 당해본 사람은 사기꾼을 잘 구별하듯이 짝퉁에게 많이 당해보면 구별하는 눈이 생길 것입니다. 하지만 이 방법은 많은 비용을 지불해야 하니 별로 좋은 방법이 아닙니다. 오히려 불신만 키울 수도 있습니다. 뾰족한 답이 있어서 얘기를 꺼낸 것은 아닙니다. 그저 섯불리 판단하지 말고 신중하는 수밖에 없을 것 같습니다. 주변이 진짜 고수가 있다면 짝퉁을 가리는데 도움을 받을 수 있겠죠. 

2009년 3월 2일 월요일

좋은 PM은 훌륭한 리스크 관리자

프로젝트에서 가장 중요한 활동 중에 하나가 리스크 관리입니다. 프로젝트 실패의 원인의 대부분이 리스크 관리를 하지 않거나 하더라도 부실하게 하는 데 있습니다. 성공하는 프로젝트관리자는 우수한 리스크 관리자입니다.

성공하는 프로젝트는 대부분 성공 가능한 범위 및 일정을 가지고 리스크를 잘 관리한 프로젝트입니다. 반면, 성공 가능한 범위 및 일정을 가지고 시작한 프로젝트라도 리스크 관리에 거의 신경을 쓰지 않으면 예상치 못한 돌발 변수에 프로젝트는 실패하기 쉽습니다.
프로젝트 리스크 관리를 하다 보면 소프트웨어 프로젝트는 정말 가시밭길을 걷고 있다는 생각이 듭니다. 웬만한 크기의 프로젝트에서 리스크 수십 개를 찾아내기란 그리 어렵지 않기 때문입니다. 하지만 미리 발견되고 관리되는 리스크들은 그 위험을 현저히 낮출 수 있고, 다른 대처 방법들을 얼마든지 찾을 수 있습니다.

 프로젝트에서 리스크 관리는 다음과 같은 절차로 진행됩니다.

1. 리스크관리 책임자 임명 - 대부분의 중소규모의 프로젝트는 프로젝트관리자가 리스크관리자도 겸하지만 프로젝트가 대단히 크거나 특수한 경우 리스크관리자를 별도로 임명합니다.

2. 리스크 인지 - 리스크는 프로젝트에 관련된 모든 사람이 찾아내야 합니다. 추후 인지하지 못한 리스크 때문에 프로젝트가 지현되거나 실패하면, 리스크 인지가 소흘했기 때문입니다. 리스크 인지는 프로젝트 초기에 한번만 하는 것이 아니고, 프로젝트가 끝날 때까지 꾸준히 찾아야 합니다. 리스크관리자는 사소하게 흘려버리는 걱정거리들을 정리하고 계수화해서 리스크 관리 항목으로 끌어들여야 합니다.

3. 리스크 분석 - 인지된 리스크는 분석하여 분류를 해야 합니다. 그리고 발생가능성(P)과 파급효과(I)로 나누어서 분석하여 수치화를 해야 합니다. 각각은 1~5까지의 수치로 정량화를 할 수 있는데, 이때 주관적인 판단이 필요합니다. 발생가능성이 몇%가 될지를 정확하게 예측한다는 것이 거의 불가능하기 때문입니다. 그에 비하여 파급효과는 예측이 좀더 쉽습니다. 그 일이 일어났을 때 발생할 수 있는 피해를 일정이나 금액으로 환산해서 예측할 수 있습니다.

4. 리스크 우선순위화 - 프로젝트에서 관리하는 리스크는 대단히 많은 수가 됩니다. 이를 모두 동일하게 관리하기란 쉽지 않고 비효율적입니다. 따라서 우선순위가 높은 리스크를 집중적으로 관리하는 것이 좋습니다.

아래 노출도 계산 공식을 엑셀의 수식으로 변화하면 입력하면 자동으로 해당 리스크의 노출도가 계산이 됩니다.
노출도(E, Exposure) = (P/5-0.1)*0.05*(2^(I-1))
P = 발생가능성(Probability)
I = 파급효과(Impact)


낮은 노출도: 0.05 미만
중간 노출도: 0.05 이상 0.15 미만
높은 노출도: 0.15 이상

5. 리스크 대처 계획 - 리스크가 문제가 되지 않도록 미리 대처를 하거나 리스크가 발생해도 되도록 대비를 하는 것입니다. 예를 들어 개발자가 퇴사할 징후가 보일 때 다음과 같은 대응책을 마련할 수 있다.
  • 개발자가 퇴사하지 않도록 노력한다.
  • 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다.
  • 사내에서 보충한 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다. 즉, 채용 공지를 하고, 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다.
  • 해당 개발자의 모듈을 다른 개발자와 많은 부분 공유하도록 계획 한다.
  • 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.

6. 리스크 감시 - 프로젝트가 진행되면서 리스크는 계속 변합니다. 따라서 리스크를 지속적으로 감시해야 합니다. 리스크의 모든 기록은 리스크관리대장을 만들어서 기록해야 합니다. 리스크관리대장에는 다음과 같은 것들이 적힙니다.
  • 리스크 제목
  • 리스크 내용
  • 리스크 분류
  • 리스크 발생 가능성
  • 리스크 파급 효과
  • 리스크 관리계획
  • 리스크 발생 시 대처 계획
  • 리스크 대처 기록
  • 리스크 재평가 기록
리스크를 주기적으로 재평가하고 우선순위를 재정렬하고, 리스크 대처 계획을 갱신해야 합니다. 이와 더불어 새로운 리스크를 인지하기 위해서 지속적인 리스크 감시를 해야 합니다. 리스크관리대장에 내용이 꾸준히 쌓이면, 프로젝트가 끝난 후에도 다른 프로젝트에서 참조할 수 있습니다. 이 때 놓치기 쉬운 리스크를 쉽게 찾아낼 수도 있고, 리스크에 어떻게 대처해서 문제를 해결했는지도 도움을 얻을 수 있습니다.



2009년 2월 28일 토요일

사라진 소스코드

바이너리는 있는데 소스코드는 없어서 낭패를 보신 적은 없으신가요?

소스코드 백업은 흔히 소홀히 하기 쉽습니다.
사고가 발생한 후에야 문제가 되고, 사고가 그렇게 자주 발생하는 것은 아니죠.
자주 발생하지는 않지만, 일단 발생하는 타격이 아주 큽니다.
일상 생활에서는 보험을 들지만, 소프트웨어를 개발하는 현장에서는 보험을 드는 격인 백업을 제대로 하는 경우는 흔히 보기 어렵습니다.

소스코드는 이러한 경우에 흔히 사라지거나 깨지게 됩니다.
이 때 백업이 없으면 낭패가 됩니다.

  • HDD는 그리 드물지 않게 깨집니다. 그냥 운영 중에 HDD가 깨져버리는 경험은 많이들 있을 겁니다.
  • 장비를 사무실 내에서 옮기거나, 회사가 이사를 갈 때는 HDD가 깨지는 경우가 더 흔합니다.
  • 컴퓨터바이러스 등의 악성 코드에 의해서 데이터가 파손되거나 시스템이 망가질 수 있습니다.
  • 번개나 전기 공사중의 시스템에 과도한 전류 등의 문제로 시스템이 망가지는 경우
  • 화재, 지진, 홍수 등의 재난으로 시스템이 완전히 망가질 수 있습니다.
  • 시스템이나 HDD를 도난 당할 수 있습니다.
  • 개발자가 개발을 하다가 실수로 소스코드 전체 혹은 일부 파일을 삭제할 수 있습니다.
  • 여러 개발자가 파일서버에서 동시에 개발을 하다가 실수로 다른 개발자가 개발해 놓은 내용을 무시하고 싹 Overwrite를 해버릴 수 있습니다.

그래서 소스코드를 백업을 받아야 하는데, 아래와 같이 불완전하게 백업을 받으면 완벽한 보험장치가 될 수 없습니다.
  • 소스코드를 보관하고 있는 시스템을 RAID로만 구성하고 별도로 백업 받지 않음
  • 소스코드가 보관되어 있는 시스템의 다른 디렉터리에 파일을 복사해서 백업
  • 사내의 다른 시스템에 미러링 또는 정기적으로 복사
  • 소스코드는 소스코드관리시스템에 있지만, 또한 각 개발자들의 PC에도 일부 또는 전체가 있어서 소스코드관리시스템이 망가져도 어딘가에는 소스코드가 있다. 
  • 주기적으로 DVD로 백업을 받아서 사내에 보관
  • 사내에 소스코드는 팀 별로 여러 시스템에 보관이 되어 있는데, 팀 별로 알아서 스스로 백업을 받는다.

위의 경우 대부분의 사고에도 소스코드를 복구할 수 있겠지만, 화재가 발생 한다면 백업 받아 놓은 DVD도 같이 싹 타버릴 것입니다. 실제로 911테러나 고베 대지진 때 수많은 회사들이 백업 데이터가 없어서 문을 닫은 경험들이 있습니다. 이런 큰 사건이 아니라고 하더라도 화재 등의 사건은 발생할 수 있고, 회사는 화재에 대한 보험을 거의 다들 들고 있습니다. 하지만, 그런 화재보험이 소스코드를 복구 시켜 주지는 않습니다. 대부분의 회사가 화재를 경험하는 일은 평생 없겠지만, 누군가는 겪게 되고, 화재 뿐만 아니라도, 서두에서 언급했던, 백업이 필요한 수많은 경험들은 한번씩은 해봤을 겁니다. 
그래서 백업은 아래와 같이 3단계로 이루어져야 합니다. 

기본적으로 소스코드관리시스템을 사용한다는 전제하에 설명을 하겠습니다. 그래야, 최종 소스뿐만 아니라 소스코드 History도 모두 보관을 할 수 있습니다. 아래 활동은 개발팀마다 각각 수행하면 안되고, 회사가 아무리 커도 전체소스코드를 한군데서 관리를 하며 백업도 한번에 받아야 합니다. 


  • 소스코드관리시스템은 RAID를 구성하거나 실시간 미러링 시스템을 만들어서 시스템 장애 시 항상 복구가 가능해야 합니다. 이는 시스템이 항상 작동하도록 해줍니다.
  • 소스코드관리시스템은 하루에 한번 DVD등의 미디어에 Incremental 백업을 받아야 합니다. 그리고 백업 받은 DVD는 사내에 보관합니다. Incremental 백업은 크기가 크지 않으므로 그리 오래 걸래지 않습니다. 이는 시스템이 망가져도 적어도 24시간 이전의 소스코드로 돌아갈 수 있도록 해줍니다.
  • 소스코드관리시스템은 일주일에 한번 DVD로 Full 백업을 받아서 회사 외부의 안전 장소에 보관을 해야 합니다. 안전한 장소는 은행의 안전금고 등이 될 수 있습니다. 이는 회사가 완전히 불타서 없어져도, 적어도 일주일 전의 소스코드로 완전히 복구를 해줍니다.
소스코드를 안전하게 백업을 받았다가 불의의 사고 시 복구를 한다고 해도, 소스코드를 가지고 제품을 만들어 내는데 일주일 또는 수주가 걸린다고 하면 안됩니다. 백업의 목표는 소스코드 복구 후 24시간 안에 원래 제품을 그대로 만들어 낼 수 있어야 합니다. 그러기 위해서는 정확한 개발환경, 빌드환경, 테스트환경 정보가 문서에 기록이 되어서 소스코드관리시스템에 같이 보관이 되어 있어야 하고, 빌드는 완전히 자동화 되어서 빌드환경 구성 후 빌드 스크립트만 실행하면 제품이 만들어지도록 준비가 되어야 합니다. 

이 정도가 되어야 제대로 된 백업을 받고 있다고 할 수 있습니다. 

뭐, 백업을 이정도까지 완벽하게 받는냐?라고 반문하시는 분이 계실지 모릅니다. 

그런 분이 질병 보험을 들면서, 한달에 보험료를 3만원만 내면, 감기, 골절 등 대부분의 질병은 다 보장이 되는데, 암 등의 죽을 수 있는 병은 보장이 안된다고 하면 어떻게 생각하시겠습니까? 
또, 죽을 병이 보장이 되려면 보험료를 4만원을 내야 한다고 하면 어떻게 하시겠습니까? 나는 절대 암에 걸리지 않을 거야 하고 3만원만 내시겠습니까?  아니면 암에 꼭 걸릴 것을 예상하고 4만원을 내십니까? 
대부분은 암에 절대로 걸리지 않을 것이라고 생각하면서도 일단 암에 걸리면 타격이 크니, 4만원을 보험료로 내는 선택을 할 겁니다.

백업도 마찬가지입니다. 절대로 화재나 지진등의 사고는 발생하지 않을 것이지만, 대비를하는 것입니다. 그 대비 비용이 사고 발생 후의 피해 보다는 훨씬 작기 때문입니다.

보험료를 지불한 만큼 보장을 받는 것입니다.

2009년 2월 25일 수요일

Merge Tool(머지툴) 비교 - (3way merge 기능) - 수정

소프트웨어를 개발하다 보면 소스코드의 브랜치가 일어나고 이를 Merge(머지)하는 일은 피하기가 어렵습니다.
이 Merge(머지)과정을 자동화 툴을 이용하면 상당히 많은 시간을 절약할 수 있습니다.
특히 Merge의 자동화를 위해서는 3way-Merge가 필수적인데, 시중에서 3way머지가 지원된다고 하는 툴 4가지와 SVN에서 지원하는 Unified diff, 이렇게 총 5가지를 비교해봤습니다.
그 결과는 아래와 같이 평가를 하였습니다. KDiff3, P4Merge와 Araxis Merge가 우수하게 나왔습니다.

2way merge툴은 같은 레벨에서 비교 대상이 되지 않기 때문에 비교하지 않았습니다. 2way merge툴보다는 꼭 3way merge툴을 쓰기를 권장합니다.

3way merge툴은 실무에 있어서 2way merge툴보다 10배에서 100배까지 더 효율적입니다. 직접 이해를 하고 써보기 전까지는 짐작하기 어려울 정도입니다.

제 책(소프트웨어 개발의 모든 것)에서 3way merge에 대해서 자세히 설명하고 있으니 참조하기시 바랍니다.


 총점



 비교 데이터

비교 방법은 일부러 Conflict가 일어나는 상황을 만들어서 각 Merge툴이 얼마나 손쉽게 Conflict를 해결하는지 비교하였습니다.

제가 분석을 위해서 사용한 파일은 다음과 같습니다.


위에서 자동으로 Merge가 가능한 부분은 노란색으로 칠했고, Conflict가 나는 부분은 보라색으로 칠했습니다.
이렇게 Conflict를 일으켜서 SVN에서 자동 Merge를 실패하게 한 후에 각각의 Merge툴로 비교를 해 봤습니다.


 실행
KDiff3와 Araxis Merge는 Conflict가 났을 때 SVN에 떨궈주는 파일 3개를 선택해서 쉽게 해당 툴을 실행할 수 있습니다. 그래서 Merge하는 시간을 절약할 수 있습니다.

KDiff3


Araxis Merge


 비교 화면

비교는 Orginal File(Base)과 Trunk File(Working)과 Branch File 3개를 비교했습니다.
그 화면은 다음과 같습니다. 이미지를 클릭하면 큰 이미지를 볼 수 있습니다.
언뜻 보기에는 각각의 화면이 크게 차이가 나지 않는 것처럼 보입니다. 각 툴마다 다른 부분, Conflict가 나는 부분을 다른 방법으로 표시를 하고 있습니다. KDiff3는 한글이 깔끔하게 나오는 것이 눈에 좀 거슬리지만, 기능에는 문제가 없습니다.
비교 화면에서는 Araxis Merge가 가장 직관적이고 깔끔한 화면을 보여줍니다.

KDiff3

P4Merge

Araxis Merge

Beyond Compare

Ultra Compare


Merge시 Conflict를 알려주는 다이얼로그 

KDiff3와 Araxis Merge는 의미있는 Conflict 정보를 Merge시 알려줍니다. 둘다 자동 Merge를 하면서 Conflict가 난 2건을 표시해 줍니다.
P4Merge는 가장 직관적인 화면을 보여주며 마찬가지로 Conflict 2건을 표시합니다.

KDiff3
 
P4Merge

Araxis Merge
 

Merge 화면

Merge를 실행하게 되면 KDiff3, P4Merge와 Beyond Compare는 원래 파일 3개는 그대로 두고 새로운 Merge파일 창이 새로 생깁니다. 하지만, Araxis Merge와 Ultra Compare는 기존의 파일을 수정하도록 되어 있네요.
P4Merge가 가장 직관적입니다.

KDiff3

P4Merge

Araxis Merge
 
Beyond Compare
 
Ultra Compare
 

Conflict 해결

Conflict는 각각 어떻게 해결을 할 수 이나 비교를 해 봤습니다.

KDiff3 - Merge화면에서 Conflict가 난 줄은 <Merge Conflict>라고 표시가 됩니다. 원래 비교 대상인 3개의 파일 중에서 하나를 마우스나 키보드를 이용해서 선택할 수 있습니다.
 
P4Merge - Merge창에서 Conflict가 난 부분은 붉은 표시가 되어 있습니다. 오른쪽에 있는 버튼을 클릭해서 원하는 부분은 클릭하면 쉽게 Conflict가 해결됩니다.

Araxis Merge - Conflict가 난 줄들은 줄 앞에 빨간 동그라미가 나옵니다. 해당 줄에서 >>, << 버튼을 이용해서 선택을 하면 됩니다.
 
Beyond Compare - Conflict가 일어난 줄은 붉은 바탕으로 표시가 됩니다. 이 줄에서 마우스 버튼을 이용해서 원하는 파일을 선택하면 적용이 됩니다. 테스트 시 라인 단위로 정교하게 선택이 안되고 뭉쳐서 선택이 되는 바람에 원하는대로 Merge를 하는데 시간이 좀 걸렸습니다.
 
Ultra Compare - Conflict는 표시가 안됩니다. 그냥 서로 다른 줄을 찾아서 ->, <-버튼을 이용해서 선택하면 됩니다. 자동 Merge가 안되서 수동으로 일일이 선택을 해줘야 합니다.


Unicode 지원

KDiff3 - Unicode를 지원하나 Auto detect가 잘 안되네요.
P4Merge - Unicode를 완벽하게 지원합니다.
Araxis Merge - 지원한다고 하는데, View에서 깨져 보임,  Merge는 됨 
Beyond Compare - View, Merge 모두 지원
Ultra Compare - View, Merge 모두 지원

총평

기능면에서는 약간 부족함은 있으나, 기본적인 Merge기능에 충실하고 가격이 무료인 KDiff3와 모든 기능이 우수하지만 가격이 좀 부담스러운 Araxis Merge에 높은 점수를 주었습니다.
그리고 P4Merge는 Merge 기능이 가장 직관적인고 편리합니다. 

실제로 Merge결과 원하는 결과대로 바로 Merge가 되면서 Conflict를 몇 초만에 해결할 수 있었던 것은 KDiff3, P4Merge와 Araxis Merge밖에 없었습니다.

Branch와 Merge가 빈번하고 회사에 경제적인 여유가 된다면 Araxis Merge가 적당할 것 같고, 그렇지 않은 경우라면 다른 유료 툴보다도 KDiff3와 P4Merge가 좋을 것으로 생각합니다.

2009년 2월 24일 화요일

Build Script를 C언어로 작성하기

Build Script를 Script언어가 아닌 C언어로 작성하시거나 그런 경험이 있으십니까?
저는 Build Script를 C언어로 작성하는 것을 본 적이 있습니다. 이 경우에 Build Script라고 하기에 좀 그렇군요. Build Program이라고 해야 할까요? 
누구나가 Build Script라고 부르는 이유는 Script언어로 작성하기 때문이기도 합니다.
물론 IDE에서 공식 빌드를 하는 것이 아니고 Build Script를 작성한 것은 긍정적으로 볼 수 있지만 Build Script를 사용하기 위해서 다시 Build를 해야 한다면 우습네요.
Build Script를 C언어와 같이 Build가 필요한 언어로 작성하는 경우는 이러한 경우가 있을 수 있습니다.

  • C언어는 기가 막히게 잘 아는 Script언어는 잘 모른다.
  • Build Logic이 복잡하여 Script언어로는 작성하기 어려울 것 같다.
  • Build 과정에서 다른 시스템과 연동하는 등 인터페이스가 많다.

Script언어를 하나도 모른다면 어쩔 수 없겠지만, Script언어로도 빌드에 필요한 정도의 모든 기능은 쉽게 구현할 수 있습니다. 오히려 Build를 위해서 만들어진 Ant같은 경우는 더 효율적입니다. Script언어에 아직 익숙하지 않다면 간단하게 Batch 파일로 작성할 수도 있습니다. 그리고 C언어와 유사한 Python을 이용하면 Python을 아주 잘하지 않더라도 간단한 Build Script 정도는 만들어 낼 수 있습니다.

Build Script는 처음부터 모든 원하는 기능을 다 자동화 할 필요는 없습니다. 우선 기본적인 빌드 기능부터 구현을 한 다음에 사용을 해보면서 자동화가 필요한 부분을 차례차례 추가해 넣으면 무난히 효율적인 Build Script를 만들 수 있습니다.

2009년 2월 22일 일요일

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

그동안 제 블로그에서 약 20일간 기업의 소스코드 관리 방법 투표를 진행했습니다.
현재 각 기업들의 소프트웨어 개발 환경 및 현황을 파악하고 공유하기 위해서 소프트웨어 개발에 대한 다양한 설문 조사를 시행하고 있습니다.

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


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

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

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

0%27%54%COUNTPERCENT
COUNTRYOVERALL
Subversion
30254.41%54.41%
CVS
386.85%6.85%
Visual SourceSafe
285.05%5.05%
Team Foundation Server
162.88%2.88%
IBM Rational ClearCase
162.88%2.88%
RCS
20.36%0.36%
Git
386.85%6.85%
Mercurial
132.34%2.34%
SVK
00%0%
Bazaar
10.18%0.18%
BitKeeper
00%0%
FileServer에 보관
142.52%2.52%
개인 PC에 보관
417.39%7.39%
공용개발서버에 보관
264.68%4.68%
실운영서버에 보관
61.08%1.08%
Other:

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





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





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




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

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

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

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

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

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