잠시 후 Google blogger로 이동됩니다.
지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 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 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.
다시한번 설문에 응해주신 모든 분께 감사드립니다.
전규현
기반시스템/소스코드관리
Configuration,
소스코드관리
당연한 얘기를 글로써 상기 시킨다는 현실이 참 슬프네요
저도 한번은 그렇게 큰 사이트가 아닌데 소스만 400MB
짜리를 본적이 있었습니다. portal1,portal2,real-portal.....
같은 디렉토리가 여러개 있는데 마치 닭 갈비집 이름 처럼
"원조집","진짜원조집","진짜진짜원조집" 같은 느낌이였습니다.
시스템은 점점더 고도화되고 복잡한 기술을 사용하는데
개발 환경과 현실은 너무 구닥다리를 따르고 있습니다.
Beyond J2EE님 안녕하세요.
정말 적절한 비유입니다.
이런 소스코드는 감당하지도 못합니다. 소스코드관리시스템의 브랜치와 머지 기능을 충분히 활용하고 개발 프로세스 상에서 이를 잘 통제하면 부처님 손바닥안의 소스코드죠.
언제 다 같이 모아 놓고 세미나를 한번 하고 싶은 마음은 굴뚝 같은데 여유가 안생기네요. - -;
항상 좋은 글 감사합니다^^ 개발자로써 구구절절 옳은 말씀만 올려주시지만 현실과의 괴리감이 드는 건 어쩔수가 없네요. 형상관리를 하고 있지만 어느 순간에서부턴가 각 개발자끼리 마치 개별 브랜치를 가진 듯이 다른 방향으로 진행되고 있는 상황을 자주 접하게 됩니다. 물론 상황에 따라 머징이 되긴 하지만 주기적으로 이루어지는 머징도 아니고 필요에 따라, 상황에 따라 이루어지다보니 커뮤니케이션이 소홀해 지는 경우 각자의 프로젝트는 결국 다른 산으로 가고 있더군요.
다시 한번 좋은 글로 일깨워주심에 감사드립니다~^^
안녕하세요. 옥수석님
당연한 기초가 현실과 괴리가 있는 현실이 안타깝습니다. 대학생들을 갈쳐도 몇주면 익숙해지는 것을 십수년 경력의 개발자들도 제대로 하지 못하는 것이 현실이기는 하죠.
브랜치와 머지는 보통 개발자가 마음대로 하면 안됩니다. 이에 대한 회사의 정책이 있고 개발자는 이를 따라야죠. 일반적으로 브랜치는 승인하에서 합니다. 머지계획도 미리 작성해야 하고요. 번거로우라고 이렇게 하는 것이 아니고 이렇게 하는 것이 가장 효율적이기 때문입니다.
또 머지는 3-way머지를 해야 합니다. 보통 2-way머지툴을 가지고 머지를 하는데 이는 수십배 더 시간이 많이 들고 잘못 머지가 될 가능성도 대단히 높습니다.
이렇게 해 놓고 개발자들이 계획에 따라서 자유롭게 개발하는 것이 좋지, 대충 해놓고 뭔가 고칠려고 할 때마다 소스코드 공유/통합을 신경써야 한다면 프로젝트 기간 내내 소스관리 비용이 몇백배로 더 많이 들게 됩니다.
산으로 가고 있다면 다시 땅으로 끌어 내려야 겠네요. ^^ 필요하면 제가 세미나 등을 통해서 개발자와 경영진들을 설득시키고 교육도 시켜주곤 합니다.
비밀댓글입니다
Repository를 어떻게 나누고 각 Repository안의 프로젝트 별 디렉터리를 어떻게 구성하는지는 회사마다 다릅니다.
일단 revision number는 신경쓰지 않는 것이 좋습니다. revision number에 의미를 부여해서 사용하면 나중에 문제가 발생합니다.
Repository구분은 각 프로젝트가 단 0.1%라도 서로 연관성이 있는지를 봐야 합니다. 공유되는 소스코드가 있는지? 나중에 쓰고 버릴 소스코드인지? 백업은 공통으로 해야 하는지? 이렇게 생각을 해보고 연관이 있으면 한 Repository에 넣는 것이 좋습니다.
Repository안의 디렉터리 구조는 각 프로젝트가 완전히 자동으로 Build가 가능하도록 구성을 해야 하는데 공통모듈이 잘 관리되고 있는 회사가 아니라면 이 말이 무슨 뜻인지 잘 모를겁니다. 하지만 공통모듈이 있다면 디렉터리를 어떻게 구성하냐에 따라서 빌드가 달라집니다.
이렇게 여러가지를 고려하여 처음부터 잘 정해 놓고 시작해야지 나중에 바꾸려고 하면 큰 문제입니다.
리파지터리 주소는 프로젝트 check out할 때 처음에 한번만 입력하면 되는 것이기 때문에 기억하는 것은 문제가 알될 것 같습니다.
늘 잘 안되는 것들이 포스팅이 되어서 마음이 아팠었는데
오늘 포스팅에 대해서는 자신감이 생기네요..
svn을 사용하고 있고 capistrano를 통해서 각 환경(개발, 백업, 리얼)으로 소스를 deploy 할수 있고 이슈트래킹의 부가기능에 svn history를 연결해놔서 누가 언제 어떻게 고쳤는지 웹상으로 확인할수 있습니다. ^^ 이정도면 자신감을 가져도 괜찮겠죠?
안녕하세요. zeous님
일단 SVN과 이슈트래킹(아마 Trac)을 연동해서 잘 쓰고 계시나보네요. 평균 이상은 되시네요. ^^
항상 안되는 것만 있으면 빵점이게요? 그럴리가 있겠습니까? 항상 포스트를 보면서 조금씩 고쳐나가자는 의미입니다.
SVN을 잘 쓰시는 것 같기는 한데 Branch, Merge는 어떻게 하는지 궁금하네요. 사실 SVN의 핵심은 Merge거든요. 나중에 Git나 Mercurial들의 분산소스코드관리시스템을 쓰더라도 Merge를 제대로 하지 못하면 반쪽짜리가 됩니다. 그래서 3-Way Merge를 능수능란하게 다룰 수 있어야 합니다. 어떠신가요?
branch를 전혀 쓰지 않는 것은 아닙니다.
이번에도 새로운 프로젝트를 시작하는데 기존 소스의 서비스도 유지하면서 거기에서 파생되어서 추가적인 작업을 하고 완성후에 합치기 위해서 branch를 생성해서 작업을 하고 있습니다만은
branch를 생성하고 나서 마지막에 합칠때 실수하지 않을까 (자동으로 하게 되면 가끔 한쪽을 날려먹는 경우가 있어서 안볼수는 없더라구요)
챙겨야 할것들이 있기에 이왕이면 안만들어졌으면 하는 바램은 있습니다 ^^
SVN을 쓰는 곳, 다수가 해당 소스를 Root에 그냥 올려버리는 곳을 많이 봤습니다.

Branch나 Tags, Merge와 같은 기능은 꺼버리고 사용하는 것과 마찬가지 인데도 불구하고 말입니다.
초반엔 인식을 심어주려고 교육도 해보고 노력했으나..역시나 이쪽 부분엔 관심 없어 하더군요.
무술고수가 항상 강조하는 기본기 "정권찌르기"를 거스르고 현란한 기술만 쓰고자 하는 사람들의 심리때문일까요? 아니면 남들이 모르니 나도 몰라도 된다..라는 심리때문일까요
가장 기본이 되는 소스코드 관리 정말 중요하죠~ 말이 필요없다고 생각합니다.
하나를 보면 열을 안다고.. 이런 기본을 중요시하는 기본기가 탄탄한 조직은 정말 안정적인 조직이라고 생각합니다. ( 비단 소스코드관리뿐만이 아닌...
moova님 안녕하세요.
제가 좀 바빴네요. - -;
소스코드시스템을 쓰는 이유가 소스코드를 잃어버릴까봐 백업용도로만 쓰는 곳이 의외로 많습니다.
빠뀌지 않는 이유는
1. 막연히 새로운 것을 배우는 것이 귀찮아서
2. 나아진 다는 확신이 없어서
3. 현재 방법에 익숙해져서
4. 가르쳐 주는 사람에 대한 믿음이 부족해서
5. 소스코드를 감추려고
등등 다양합니다.
산넘어 산입니다.
그래서 카리스마 있는 사람의 도움을 받아서 설득을 하면서 강제화하는 것이 가장 좋은 방법입니다.
어느분이 지적하신대로 저 역시 Branch, Tags, Merge 기능을 사용해보질 못했네요 -_-;
현재 SVN의 기본 저장 기능만 쓰고 계신거라고 볼 수 있습니다. 혼자서 개발을 해도 브랜치 요구는 항상 생깁니다.