2009년 3월 8일 일요일

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

지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 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 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.

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

댓글 6개:

  1. 예상대로 코드리뷰에 대한 결과는 저조하군요. 흠...

    답글삭제
  2. 3번 Rule 에서 8,9번 항목의 경우 처음 질문 때 의도가 명확치 않으면 구분해서 쓰지 않고 중복 체크를 할 것 같습니다만.
    그리고 버그트래커-버전관리툴 이 연동된 시스템을 쓰는 개발자 입장에선 버그 번호를 쓰는게 더 쉽습니다. 아무 설명도 안쓰고 버그 번호만 쓰면 되거든요. (상세 내용은 어차피 버그트래커에서 계속 덧글로 달리므로. 그리고 버그 트래커와 버그 번호 연동되는 시스템인 경우 버그 번호만 룰에 맞춰 남기는게 훨씬 보기에도 좋고 추적성 면에서도 좋습니다. 그리고 SVN Log 로 쓸 수 있는 텍스트 양은 한계가 있습니다. 차라리 별도 문서를 남기죠)
    3 way merge 의 경우.. 툴 자체가 편하긴 하나, 자동 테스트가 구축되고 커밋 빈도가 높은 곳의 경우 그냥 눈으로 비교하는 것으로도 충분합니다. (한 changeset 당 코드 변화량이 적은 경우) changeset 당 코드 변화량과 conflict 단위가 큰 경우 툴의 편의성 문제로 보기보다는 그렇게 conflict 단위가 크게 가는 상황 자체가 문제일지도 모르죠.
    그리고 질문이 있다면.. '팀/프로젝트 규모 대비 필요한 만큼의 성숙도' 의 기준이 정해진 것이 있는지 궁금합니다.

    답글삭제
  3. 헝그리맨님 안녕하세요.
    코드리뷰는 가장 정착시키기 어려운 개발문화 중의 하나입니다. 실리콘밸리에서도 귀찮기는 마찬가지이지만, 규칙으로 정해 놓고 누구나 따릅니다.

    답글삭제
  4. 좋은 의견 감사합니다.
    8,9번 항목의 경우 실제로 그렇게 하고 있는 개발자라면 다 이해를 할 것입니다. 제대로 하고 있는 곳이라면 8,9번을 다 체크하겠지요.
    머지는 팀이 커질수록 머지에 많은 노력이 들어가는데, 눈으로 비교해서 머지하는 것은 시간도 많이 걸리고 실수의 가능성도 크다고 생가가합니다. 팀이 커지고 동시에 많은 사람들이 소스코드를 중복해서 수정하더라도 Conflict가 가능하면 적게 생기도록 하는 것이 좋습니다. 이런 경험이 쌓이면 자연스럽게 어떻게 해야 Conflict가 적게 생기는지 요령이 생깁니다.
    3,4명의 개발자들이 동시에 개발하는 팀에서는 어떻게 해도 큰 문제가 되지는 않습니다. 개발팀이 커질 수록 신경을 써야겠지요.
    제가 소프트웨어공학 컨설팅을 하기 때문에 '팀/프로젝트 규모 대비 필요함 만큼의 성숙도'에 대한 기준은 가지고 있습니다. 하지만 많은 회사들이 그 기준에 미치지 못하고, 발생하는 수많은 문제를 피해 다님으로서 스스로의 생산성과 역량을 떨어뜨리는 결과를 가져오고 있습니다. 팀의 규모와 역량에 알맞은 규칙과 툴을 적절하게 이용하면 훨씬 더 생산성을 높일 수 있는데, 심지어는 자신만의 세계에 갇혀서 이러한 변화를 거부하는 개발자도 많답니다.

    답글삭제
  5. 안녕하셔요?
    이제는 개발자에서는 조금 멀어진 애 늙은이 입니다.^^
    제가 종사하는 분야에서는 아직도 주먹구구식으로 개발이 이루어지고 있습니다.
    후배들에게는 체계가 갖추어진 환경을 물려주기 위해 공부 중입니다.

    그런데, 코드리뷰는 어떻게 해야 하나요?
    막연한 질문이지만, 간단히 설명 부탁드립니다.
    혹시, 좋은 무료도구가 있을까요?
    집필하신 책을 주문했는데, 그 안에 답이 있을까요?

    그리고, 버그추적시스템을 소개와 비교 부탁드립니다.

    감사합니다.

    답글삭제
  6. 한인철님 안녕하세요.
    코드리뷰는 가장 필요하면서도 매우 정착시키기 어려운 개발문화입니다. 코드리뷰는 종류가 여러가지고 있고, 개발 조직에 따라서 알맞은 방법을 써야 하며 제도적으로, 시스템적으로 뒷받침이 필요합니다. 여러 도구가 있기는 하지만 당장 도구가 없어서 코드리뷰를 못하는 것은 아닙니다. 일단 시작하는 것이 중요하고 시작하기 위한 기본적인 지식은 갖춰야죠. 좀더 구체적인 것이 필요하면 연락주세요.

    그리고 버그추적시스템은 제 책에도 소개가 되어 있고, 현재 투표가 진행중인데, 투표가 끝나면 글을 올릴 예정입니다.

    감사합니다.

    답글삭제