2009년 4월 12일 일요일

버그관리시스템 사용 현황 조사 결과

그동안 제 블로그에서 50일동안 버그관리시스템 사용 현황을 조사하였습니다.

소프트웨어를 개발하는데 필수적인 요소 중의 하나인 버그관리를 어떻게 하고 있는지 조사하기 위함이었습니다.

물론 여기서 말하는 광의의 버그를 말하며, 이슈관리시스템, 이슈추적시스템이라고도 불리며 모두 같은 시스템이라고 생각하시면 됩니다.

질문은 다음과 같습니다.

 버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요.

복수 응답을 허용하면서 투표한 결과 총 73표가 모였습니다.
그럼 그 투표결과를 분석해보도록 하겠습니다.



 버그관리시스템 사용 vs. 미사용 비율


버그관리시스템을 사용하는 것만으로도 소프트웨어 개발 생산성 및 효율성은 상당히 향상됩니다. 그리고 소프트웨어의 규모나 복잡성이 증가할 수록 시스템 없이 파일 등으로 관리하는 것은 점점 불가능해집니다. 물론 소프트웨어가 아무리 작아도 엑셀파일로 관리하는 것보다는 버그관리시스템이 훨씬 낫죠.


 전체 투표 결과





전체 투표결과는 위와 같습니다. 엑셀로 버그관리를 하는 비율(18%)와 자체 제작한 버그관리시스템 사용 비율이 매우 높다는 것에 놀리자 않을 수 없었습니다. 특히 자체 제작한 버그관리시스템은 실패하는 것이 일반적입니다. 버그관리를 간단하고 쉽게 생각하고 자신의 회사에 딱 맞는 버그관리시스템을 만들 수 있다고 착각하지만, 실제 만들어서 사용하다보면 문제점이 많습니다.

우선 자신의 회사에 딱 맞는 시스템이라는 것이 기존의 회사에서 개발하는 방식에 문제가 있는 경우가 대부분이기 때문에 이에 딱 맞추면 회사의 개발 프로세스는 나아지는 것이 없습니다. 오히려 제대로 된 툴에 회사의 프로세스를 변화시켜서 맞춰나가는 것이 성공할 가능성이 더 높습니다. 또 버그관리시스템에 대한 전문적인 지식 없이 표면적인 기능만 구현을 하게 되면 계속되는 기능 추가 및 유지보수 이슈로 본업인 제품개발에 지장을 초래할 수도 있습니다. 이러다가 결국 포기하고 제대로된 툴을 사용하다보면 그동안 나쁜 버릇들이 몸에 베어서 정상적인 경우면 1,2개월이면 적응할 것을 적응 기간이 몇배 더 들고 또 실패할 수도 있습니다. 운동도 처음에 나쁜 자세가 몸에 익어버리면 제대로 배우는데 처음부터 배우는 것보다 몇배 더 오래 걸리는 것과 같은 원리입니다.

따라서 버그관리시스템은 처음부터 기존에 나와았는 상용이나 무료 툴들을 사용하는 것이 올바른 방법입니다. 서투른 다른 시도는 안하니만 훨씬 못합니다.

버그를 관리하지 않는 비율이 7%나 되는데, 음.. 버그가 하나도 없다는 얘기일까요? 신기하군요. 회사가 작다면 작은 PC에다가 Mantis등의 무료 버그관리시스템을 설치해서 써보는 것도 좋은 방법입니다. 제대로 쓰기만 하면 개발 패러다임이 바뀔 것 입니니다.



 버그관리시스템의 사용 비율




버그관리시스템을 사용하고 있는 집단에서의 시스템 사용비율을 따로 뽑아봤습니다.
그 결과 Mantis가 32%를 기록했습니다. 즉 버그관리시스템을 사용하고 있다면 3명중 1명은 Matis를 사용하고 있다는 것입니다.
그리고 Trac, JIRA, Bugzilla등의 순서인데, IBM CQ나 Teamwork를 쓰고 있는 회사도 소수 있었습니다.
Mantis는 설치가 쉽고 사용이 쉽고 직관적이라서 많은 개발자들이 선호하는 것으로 보입니다. 또 무료라는 것도 무시할 수 없는 매력이겠지요.

 결론

버그관리시스템의 사용비율은 예상외로 낮았습니다. - 68%
또, 자체적으로 만들어서 사용한다는 비율도 꽤 높았습니다. - 10%

이를 미루어 볼 때 버그관리에 대한 의식이 매우 낮고, 버그관리를 만만하게 보는 경향을 엿볼 수 있었습니다.
소스코드관리시스템을 만들어서 사용한다는 개발자들은 별로 보기가 힘듭니다. 일단 어려워보이거든요.
하지만 버그관리시스템을 팔기위해서가 아니고 자신들이 사용하기 위해서 만든다고 하는 개발자들을 쉽게 볼 수 있는 이유는 버그관리시스템이 만들기 쉽다고 생각하는 것 같습니다. 

DB 좀 핸들링 할 줄 알고 Web 프로그래밍을 할 수 있으면  버그관리시스템을 만들 수 있다고 생각합니다. 버그관리시스템은 그렇게 간단한 것이 아닙니다. 크고 작은 소프트웨어 회사의 전체 개발프로세스를 완전히 이해하지 않으면 이를 개발할 수는 없습니다. 현재 유명한 Mantis 등의 버그관리시스템들도 모두 수십년에 걸쳐서 축적된 버그관리 철학이 녹아 있는 것입니다.

따라서, 이러한 버그관리시스템에 잘 적응해여 사용하는 것만으로도 수십년간 축적된 개발 프로세스와 문화를 흡수할 수 있는 좋은 기회입니다.

버그관리가 별거 아니라고 생각하는 서투른 착각으로 이런 좋은 기회를 차버리는 과오를 범하면 안되겠습니다.

버그관리시스템을 도입하거나 사용하시면서 의논할 사항이 있으면 언제든지 연락을 주세요. 도움을 드리도록 하겠습니다. 감사합니다.


댓글 4개:

  1. 맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
    저희회사도 이제막 도입을 검토중이거든요..
    프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
    늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
    그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^

    답글삭제
  2. 어떤 시스템을 도입하려하시나요? Mantis? JIRA? 도입과정에서 어려움이 있거나 사용상의 이슈등 궁금하신 것이 있으면 언제든지 문의하세요. 감사합니다.

    답글삭제
  3. 언제나 좋은 글을 올려주시는 Ray.전규현님이 50일동안 조사하신 버그관리시스템 사용현황을 올려 주셨네요. Ray님은 가볍고, 무료인 버그관리시스템을 사용하는 것이 좋다. 자체제작(인하우스)는 실패 가능성이 높다고 하셨는데... :) 사실입니다.!!! 그런데, 실루엣팀의 경우에는 조금 상황이 다르겠지요. 실루엣팀은 자체 제작한 버그관리 시스템을 사용합니다. "코드인사이드2"라는 녀석인데, 링크한 동영상을 보시면 아시겠지만, 버그(이슈 혹은 워크아이템..

    답글삭제
  4. 아래의 링크는 Trac 과 관련된 링크를 모아봤습니다. TOW 설치 후에는 Trac을 잘 쓰여야 활용도를 높일 수 있을 거 같아서 한번 모아봤습니다. 추천할 만한 사이트가 있는데로 계속 업데이트하겠습니다. Trac on Windows 설치 (TOW가 아닌 직접 설치) TracOnWindows 01 - Trac: 다양한 커스터마이징 방법 소개 Trac, 닥치고 어디 한 번 설치나 해 봅시다.: RWAPM + mod_wsgi + Python + Trac..

    답글삭제