소스코드관리 상세 조사 결과 리포트

지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 2주에 걸쳐서 2차 조시를 실시했습니다.

질문항목이 26개나 되는 상당히 긴 투표였지만, 많은 분들이 응해주셔서 나름대로 의미있는 수치를 얻을 수 있었습니다. 투표에 참여해주신 모든 분께 감사드립니다.

투표위젯에 참 참여자 수를 보는 방법이 없어서 가장 많은 득표를 한 항목으로 미루어 짐작해서 35명이 투표에 참여한 것으로 생각하고 있습니다.

질문은 다음과 같았습니다.

각 항목별로 총 득표수는 다음과 같습니다. 아래 조사는 소스코드관리시스템을 사용하는 회사를 기준으로 계산을 할 것이므로 1번 항목은 100%입니다.

그럼 각 항목 별로 분석을 해보도록 하겠습니다.

1) 관리방법

2번 항목은 모든 개발자가 얼마나 소스코드관리시스템을 철저히 사용하는지에 대한 조사입니다. 소스코드의 Working copy가 개발자 PC나 개발서버에 임시로 있을 수는 있어도, 보관의 목적으로 다른 곳에 보관을 하면 안됩니다. 

3번 항목은 소스코드와 문서를 같이 보관하고 있는가에 대한 조사입니다. 즉, 소스코드 뿐만 아니라 Baseline에 포함이 되어야할 모든 문서도 같이 보관을 해야 합니다. 조사결과 문서를 같이 보관한다는 응답이 40%에 불과하는데, 실제로 Baseline에 포함될 모든 문서와 자료를 다 보관하는 경우는 40%보다 더 적을 것으로 생각이 되는 군요. Baseline을 설정할 때 항상 문서와 소스코드는 같은 버전으로 짝을 이루어야 합니다. 대부분의 소프트웨어 개발 회사가 문서 작성에 소흘하기 때문에 이 항목은 아예 신경을 안쓰는 경우가 많습니다.

2) Baseline

이 항목들은 Baseline을 얼마나 제대로 설정하고 있는가에 대한 조사입니다.

Baseline을 설정한다는 응답도 54%로 낮은 편이나 제때 빠짐없이 Baseline을 항상 설정한다는 응답은 26%에 불과하다는 것을 알 수 있습니다. 특히 프로젝트 종료후 한번만 Baseline을 설정하는 경우도 있었습니다.

똑, 특이할만 한 점은 앞의 조사에서 문서도 같이 저장하는 경우는 40%이나 문서도 같이 Baseline을 설정하는 경우는 17%에 불과합니다. 즉, Tag나 Label을 만들 때 문서는 제외하고 소스코드만을 포함하는 경우입니다. 

3) Rule

8번 항목을 보면 대부분의 회사가 메시지 작성 규칙이 없음을 알 수 있습니다.즉, 개발자들이 알아서 메시지를 남기거나 안남기기도 한다는 것이죠. 실제로 많은 회사들의 경우를 보면 소스코드관리시스템의 History가 거의 쓸모 없는 경우가 대부분입니다. 단순히 소스코드 저장소 역할만 하는 것이죠.

9번은 버그관리시스템과 연동이 되는지 보는 것인데, 8번과 같은 비율이 나온 것은 좀 이상하네요. 8번은 그야말로 기본적인 항목이고, 9번은 좀더 성숙도가 높은 항목인데요. 어쨋든, 소스코드관리시스템과 버그관리시스템은 서로 연동을 하면 개발 생산성을 높일 수 있습니다. 그리고, 버그ID가 없이 소스코드를 임의로 수정하는 일을 막을 수 있습니다. 시스템에서 버그 ID가 없으면 소스코드를 수정할 수 없도록 막을 수도 있습니다.

10번 항목은 소스코드가 항상 빌드가 가능한 상태를 유지하는지에 대한 질문입니다. 나름대로 회사들이 Broken tree를 방지하기 위해서 노력하고 있네요. 

4) Review

이번 리뷰에 대한 조사 결과는 기대보다 대단히 낮은 것을 볼 수 있습니다. 일단 리뷰를 거의 안하고, 소스코드를 등록할 때도 리뷰자를 남기는 경우가 별로 없네요. 즉, 리뷰의 대한 저변은 매우 낮은 것을 알 수 있습니다.

특이한 것은 Pair programming을 하는 회사가 11%나 되네요. 

5) Build

자동으로 Daily Build를 하고 있는 회사는 29%에 불과했습니다.

개발자 중에는 매일 빌드를 한다고해서 Daily Build를 하는 것으로 착각하는 경우가 있는데, Daily Build는 자동화 되어서 매일 지정된 시간에 자동으로 빌드를 하는 것을 말합니다.

6) 응용

이 항목은 개발자들의 공동작업을 얼마나 효율적으로 소스코드관리시스템을 이용해서 유연하게 처리하고 있는지 조사한 것입니다.

일단 Branch를 사용하고 있는 회사는 꽤 많습니다.(40%) 이에 비해서 Branch를 승인받아야 한는 경우는 17%에 불과합니다. 개발자들이 Branch를 아무 때나 만들 수 있다면 자칫 Branch가 관리가 안될 수도 있습니다.

소스코드를 Merge하는 회사는 60%정도이고 이중에서 아직도 상당히 많은 회사가 2-way merge나 눈을 이용해서 수동으로 Merge를 하고 있는 것으로 알 수 있습니다.

3-way merge툴을 아는 개발자가 40%나 되지만 그 활용도는 대단히 떨어집니다.(23%)

즉, 안다고 제대로 활용할 수 있는 것은 아니네요.

7) 백업

소스코드관리시스템은 꼭 백업을 받아야 합니다. 그런데, 약 60%만이 백업을 받고 있고 그중에서 안전한 장소에 백업을 보관하고 있는 회사는 훨씬 더 적습니다. (26%)

총평)

소스코드관리시스템 사용에 대한 성숙도를 따져보면 평균적으로 초,중급 정도의 사용도를 보이고 있습니다. 하지만, 이는 제가 실제로 접하는 여러 회사들이 평균보다도 높은 수치입니다. 그 원인이 블로그의 방문자들의 수준이 더 높던가, 얼굴을 보지 않고 이루어지는 투표라서 더 관대하게 투표를 했다고 생각합니다. 그렇다고 하더라도 아직 소스코드관리시스템의 활용도는 대단히 낮은 상태라고 볼 수 있습니다. 물론 소스코드관리시스템을 쓰지조차 않는 조직과 비교하면 상대적으로 낫겠지만, 개선할 점이 많습니다. Allofsoftware 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.

다시한번 설문에 응해주신 모든 분께 감사드립니다.

몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다.

주변의 회사들을 보면 몇 억짜리 툴을 사서 활용도 제대로 못하는 경우를 정말 많이 봤습니다.

제가 이전에 올린 글을 보면 소프트웨어를 개발하는데 있어서 그 팀의 성숙도에 따라서 무엇을 우선 도입해야 하고 무엇은 좀더 성숙도가 높아진 다음에 도입해야 하는지 설명한 적이 있습니다.

이중에서 가장 중요한 소스코드관리시스템과 버그관리시스템은 좋은 무료 툴들이 정말 많습니다. 하지만 이러한 무료 툴조차 쓰지 않거나 쓰더라도 아주 기초적인 기능만 사용을 하고 제대로 활용을 못하면서 정작 문제를 엉뚱한 곳에서 찾으려고 합니다. 그래서 비싼 툴을 팔고 있는 영업사원들에게 현혹되어서 몸에 걸맞지 않은 액세서리를 걸치듯 효용성도 떨어지는 툴을 사놓고 제대로 활용 못하는 경우가 많습니다.

쓰다 보면 그리 좋지 않다는 것을 느끼게 되도, 이를 도입한 담당자는 자신의 실수와 미숙함을 숨기기 위해서 효과를 과대포장하는 경우가 많습니다.

제가 장담 하건데 대부분의 소프트웨어 회사들은 무료 개발툴(기반시스템)로 충분히 좋은 소프트웨어를 만들 수 있습니다. 제가 이 블로그에서 소개하는 툴이나 기반시스템도 대부분은 Open Source나 무료 소프트웨어에 포커스를 하고 있습니다. 이러한 것들이 유료툴에 못지 않게 좋으니까요.

하지만 결국 무료냐 유료냐를 떠나서 얼마나 툴을 잘 사용하느냐가 중요합니다. 소프트웨어 개발에 문제가 있는 개발팀이 어느날 툴하나 도입했다고 해서 갑자기 드라마틱하게 상황이 바뀌지는 않습니다. 결국 사람들이 바뀌어야 하는데, 프로세스, 조직도 바꾸고, 각 개발자들의 마인드도 바꿔야 합니다. 스스로의 노력으로 오랜 시간에 걸쳐서 바꿀 수도 있고, 전문가의 도움을 받을 수 있죠.

앞으로도 이와 같은 툴을 유용하게 쓰는 법이나, 개발 프로세스 등 소프트웨어 개발에 우선적으로 필요한 요소들을 계속 올릴 겁니다.

감사합니다.

짝퉁 고수

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

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

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

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

이러한 짝퉁 고수, 짝퉁 컨설턴트를 구별하는 방법은 없을까요?

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

좋은 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. 리스크 감시 - 프로젝트가 진행되면서 리스크는 계속 변합니다. 따라서 리스크를 지속적으로 감시해야 합니다. 리스크의 모든 기록은 리스크관리대장을 만들어서 기록해야 합니다. 리스크관리대장에는 다음과 같은 것들이 적힙니다.

• 리스크 제목
• 리스크 내용
• 리스크 분류
• 리스크 발생 가능성
• 리스크 파급 효과
• 리스크 관리계획
• 리스크 발생 시 대처 계획
• 리스크 대처 기록
• 리스크 재평가 기록

리스크를 주기적으로 재평가하고 우선순위를 재정렬하고, 리스크 대처 계획을 갱신해야 합니다. 이와 더불어 새로운 리스크를 인지하기 위해서 지속적인 리스크 감시를 해야 합니다. 리스크관리대장에 내용이 꾸준히 쌓이면, 프로젝트가 끝난 후에도 다른 프로젝트에서 참조할 수 있습니다. 이 때 놓치기 쉬운 리스크를 쉽게 찾아낼 수도 있고, 리스크에 어떻게 대처해서 문제를 해결했는지도 도움을 얻을 수 있습니다.

사라진 소스코드

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

소스코드 백업은 흔히 소홀히 하기 쉽습니다.

사고가 발생한 후에야 문제가 되고, 사고가 그렇게 자주 발생하는 것은 아니죠.

자주 발생하지는 않지만, 일단 발생하는 타격이 아주 큽니다.

일상 생활에서는 보험을 들지만, 소프트웨어를 개발하는 현장에서는 보험을 드는 격인 백업을 제대로 하는 경우는 흔히 보기 어렵습니다.

소스코드는 이러한 경우에 흔히 사라지거나 깨지게 됩니다.

이 때 백업이 없으면 낭패가 됩니다.

• 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만원을 보험료로 내는 선택을 할 겁니다.

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

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

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가 좋을 것으로 생각합니다.