버그 트래킹 시스템 종류와 특징

업무에 사용할 프로젝트 매니징 시스템(PMS)를 알아보다가 버그트래킹시스템 종류와 각자의 특징을 잘 소개해놓은 글이 있어 발췌하였다.

출처 : 마이크로 소프트웨어

추적 그 이상의 커뮤니케이션 도구 '이슈 트래킹 시스템'

대규모 프로젝트에서 각각의 기술 조직과 이를 관리하는 조직 간에는 정보를 빠르게 공유하고 각 이해 관계자에게 피드백해야 하는 경우가 많다. 원활한 소통은 프로젝트의 성패를 결정짓는 중요한 요소기에 더욱 그렇다. 그러므로 고객과 기획자, 설계자, 개발자, 품질보증 조직 등 참여 주체 간에 커뮤니케이션을 명확히 함으로써 혼선을 막아야 한다. 또한 요구사항이나 이슈 처리 결과를 예측할 수 있도록 각 주체가 수행할 역할에 자원이 집중되는 환경을 조성해야 한다. 이를 가능케 하는 도구가 이슈 트래커(Issue tracker), 형상관리 도구, 위키 등의 협업 도구다.

윤동민 ydongmin@gmail.com｜개발자에 첫 발을 내딛었지만 현재 KTDS의 DS본부에서 애플리케이션 아키텍처로 근무 중이다. 새로운 것에 대한 도전과 시도를 즐기면서 기술의 절묘한 조합이 세계를 변화시킬 수 있다고 믿는 테크 크레이터(Tech creator)다. 또한 기술 전문가 집단인 GoDev(www.godev.kr)에서 오픈소스를 담당하고 있다.
김도균 dokyun@dokyun.pe.kr(프리지아 랩)｜마이크로소프트 공인 강사(MCT)이자 MVP(Exchange)이며 IT 전문 번역가로 활동하고 있다. 스마트 라이프를 추구하는 라이프 스타일 이노베이터(Innovator)이며 사소하고 일상적인 것에 새로운 가치를 부여하는 일을 즐긴다. 기술 전문가 집단 GoDev(www.godev.kr)의 기술 창의성 리더다.

이슈 트래커는 종종 버그 트래커(Bug tracker)라고 불리는데 이름에서 짐작되듯 개발 조직과 품질보증(Quality Assurance) 조직이 가장 많이 사용한다. 개발 조직의 요구사항대로 개발됐는지 품질보증 조직에서 테스트를 수행하고 그 과정에서 발견된 버그들에 대해 “디자인이 문제다”, “생각과 다르다”, “기능이 요구사항과 다르다”처럼 두루뭉술하게 평가하는 것이 아니라 “기대 결과는 A인데 결과물은 B다” 그리고 “어떤 현상을 재현하려면 C처럼 해라”와 같이 현상 기술과 화면 캡처, 덤프 등의 구체적인 자료를 첨부해 이슈를 등록한다.

기획, 설계, 개발, 품질보증, 영업 등 관련 팀의 핵심 멤버가 참여하거나 소규모 조직에서는 시니어 그룹이 담당하는 선별회의가 있다. 여기서 각 이슈별로 수정할지 아니면 다시 재개발할지의 여부, 문제이긴 하지만 고치지 않는 이슈로 둘 것인지, 문제가 아니라고 판단할지 등이 결정된다. 물론 조직의 상황에 따라 우선순위를 설정하거나 목표 시점을 조정할 수도 있다.

고쳐야 할 문제로 판별되면 개발자는 자신에게 할당된 이슈에 대한 예상되는 일정을 설정하고 개발을 시작하기 위해 형상 관리 도구에서 최종 버전의 코드를 업데이트한다. 프로젝트의 일부분을 담당한 여러 개발자가 코드를 수정해도 각 개발자는 완전한 프로젝트 패키지를 가지고 작업할 수 있어 개발 과정에서 개별 테스트도 가능하다. 수정 과정을 통해 이슈가 해결됐다고 판단되면, 개발자는 수정 내용을 diff 도구를 활용해 패키징하고 수정 내역을 간단하게 기술한다. 

다시 프로젝트 멤버들이나 담당자에게 코드 리뷰를 받고 추가 수정 내역을 반영하는 등의 과정을 거쳐 형상 관리 도구에 커밋해 이슈 상태를 해결로 수정한다. 이때 형상 관리 도구에 커밋 당시의 개정 버전을 이슈에 함께 저장해 이슈와 소스 코드를 연결한다.

품질보증 조직은 해결 상태의 이슈들에 대해서 요구사항이 제대로 반영됐는지, 이 이슈로 인해 다른 문제가 발생하진 않는지(풍선 효과), 성능 저하는 없는지 등을 확인하고 문제가 없으면 이슈를 종료시킨다. 품질보증 조직은 개발 조직에서 실행 프로그램을 전달 받는 것이 아니라, 형상 관리 도구의 최종 개정 버전을 업데이트해 새롭게 빌드하고 임의적 수정이나 소스 패키지의 변형 등에 대한 상시적 검사를 수행한다. 이런 품질보증 조직과 개발 조직 간의 소통에 최근 영업 조직, 기획자, 설계자, 오픈소스 개발자, 고객, 협력사까지 확장된 협업 체계의 도입이 확산되는 추세다.

왜 이슈 트래커를 도입하는가?
고객의 요구나 불만을 듣고 단지 상황을 모면하는 것이 아니라 고객의 요구나 불만을 조직 자산으로 여기고 이슈 트래커에 등록 및 관리해야 한다. 각 이슈의 해결은 형상 관리 도구의 특정 개정 버전을 통해 해결 과정을 구체화할 수 있다. 후임자는 이슈 기록과 형상 관리 개정 버전을 통해 수정 과정을 되짚어 볼 수 있고, 관리자의 경우 조직의 자원이 어떻게 사용됐는지 파악하고 이를 더 효과적으로 운용할 수 있다. 그리고 프로젝트 참여자는 각 구성원의 역할과 임무를 공유하고 프로젝트의 진행 상황을 알 수 있다.

이슈 트래커는 단순히 게시판이나 포럼 등의 일반적인 도구에 정보를 기록 및 관리하는 방법, 이슈 트래킹만을 목적으로 한 전문 기능을 구현하는 방법, 여러 도구(프로젝트 관리와 형상 관리 도구, 위키 등)와 통합된 형태로 구현하는 방법 등이 있다. 이슈 추적은 목적에 따라 다음과 같이 나뉜다.

● 프로젝트 일정관리
이슈 트래커를 통상 버그 관리 시스템이라고 여겨 단순히 개발 작업이나 운영상에 발생하는 오류사항만 관리한다는 생각은 지나치게 좁은 시각이다. 프로젝트 초반에 WBS(Work Break down Structure)가 만들어지면 태스크를 수행해 나가는 일정관리로도 활용된다.

● 개발 단계의 버그 관리
개발 단계에서 버그를 관리하기 위한 용도로도 사용된다. 테스트 단계에 들어가면 테스트 케이스 번호를 연계시키기 때문에 별도의 버그 알람을 만들지 않아도 된다는 점에서 편리하다.

● 유지 보수 활동의 요구사항 관리
유지보수 작업을 진행할 때 고객과 협업해 사용함으로써 고객의 요청사항을 실시간으로 접수하고 일원화해 관리할 수 있다. 이를 통해 고객의 요구사항의 누락과 오해를 막을 수 있기 때문에 커뮤니케이션을 보다 명확히 할 수 있다.

다양한 이슈 추적 도구
이슈 트래커를 잘 활용하면 프로젝트의 다양한 이슈에 대해 투명성, 공동 작업의 효율성 증대, 지식 축적, 릴리즈 관리, 소스 연동을 통해 접근성을 강화할 수 있다. 장애, 버그, 기능개선 요청 등을 의미하는 이슈를 관리하는 정통적인 방식인 엑셀이나 웹 게시판 등은 이슈의 라이프사이클을 제대로 관리하지 못해 다양한 경로로 습득된 경험이 자산화되지 못하는 단점이 있다. 프로젝트의 이슈는 프로젝트에서 정의한 이슈 작업흐름(Work Flow)에 따라 생성에서 종료까지 이슈의 상태를 바탕으로 담당자와 작업이 유기적으로 연결되고 그 과정이 투명해야 하며 이력으로 남겨져야 한다. 다양한 이슈 트래커들은 그 과정을 시스템 차원에서 지원한다.

● 맨티스
맨티스(Mantis)는 버그에 한정된 전형적인 버그 추적 시스템이다(<그림 1> 참조). 이를 잘 활용하면 이슈 관리도 가능하지만 제품의 초기 콘셉트가 BTS(Bug Tracking System)에 한정된 만큼 이슈, 문서, 지식, 형상을 포함한 개념으로 확장하기 어렵다. PHP와 MySQL 기반이기에 설치가 비교적 쉽지만 위키(WiKi)나 서브버전(Subversion)과 연동 설정이 다소 어렵다.

<그림 1> 버그 추적 시스템인 맨티스

● 트랙
이슈 트래커 소프트웨어 중 BSD 라이선스 정책의 오픈소스인 트랙은 판매를 위한 목적이 아닌 이상 프로젝트에 사용하는 데 아무런 문제가 없다. 트랙은 이슈의 관리와 할당, 추적을 모두 지원한다. 버그질라와 맨티스 등의 기존 도구들이 버그 추적에 중점을 뒀다면 트랙은 업무와 버그를 통합된 형태로 관리한다. 한 가지 독특한 점은 트랙에서는 버그나 이슈를 티켓(Ticket)이라고 부른다는 점이다. 한글에서 동음 반복문이 좋은 표현이 아닌 것처럼 issue to issue란 표현을 재치 있게 issue the ticket(티겟 발행)이란 형태로 표현했다.

<그림 2> 트랙

트랙은 기본적으로 위키 페이지 형태로 구성됐다(<그림 2> 참조). 위키는 일반적인 페이지들이 연결된 집합체로 볼 수 있는데 사이트 관리자 외에도 누구나 페이지 내용을 수정하고 추가할 수 있다. 프로젝트의 특성상 급하게 요청해야 할 부분이나 프로젝트 멤버에게 전달해야 할 사항 등으로 첫 페이지를 자유롭게 구성할 수 있다.

<그림 3> Trac의 이슈 등록 메인 화면(티켓 생성)

트랙의 특징 중 하나는 이슈를 티켓으로 관리하는 것이다. 이 티켓은 트랙에서 가장 중요한 개념으로, 해야 할 하나의 작업 단위를 뜻한다. 예컨대 어떤 버그가 발견되면 발견한 사람은 해당 버그를 수정하라는 내용의 티켓을 발행해 이 티켓을 개발자에게 전달한다(<그림 3> 참조). 티켓을 받은 개발자는 해당 티켓이 해결할 수 있는 문제일 경우 수용(Assign)해서 해당 문제를 해결하고 폐기한다. 만약 자신의 능력으로 힘들 경우 다른 사람에게 티켓을 전달해 다른 사람이 해결하도록 고안됐으며, 만약 문제 해결이 불가능한 경우 해당 개발자가 티켓을 폐기할 수 있다.

● JIRA
JIRA의 정확한 명칭은 Atlassian JIRA다. 오픈소스로 시작해서 성공적으로 상용 도구로 전환한 JIRA는 지금까지 가장 활발히 이용되고 가장 발전된 형태의 이슈 트래커로 평가된다. 이클립스의 태스크 관리자라고 할 수 있는 Mylyn과 연동될 뿐 아니라 작업을 하다보면 해당 이슈에 컨텍스트(Context)가 자동으로 등록된다. 컨텍스트란 해당 이슈와 관련된 여러 주변 환경이라고 볼 수 있으며 여기에는 관련 패키지와 클래스 등이 포함된다. <그림 4>의 오른쪽에 위치한 클래스는 현재 활성화돼 있는 이슈와 관련된 것을 필터링해 보여준다.

<그림 4> JIRA 대시보드

<그림 5>의 Package Explorer의 <Focus on Activate Task> 버튼을 클릭하면 현재 선택된 이슈와 관련된 컨텍스트를 메소드 단위로 등록할 수 있다.

<그림 5> JIRA 이슈 등록

● 코드비머
코드비머(CodeBeamer)는 이슈 관리, 위키, 서브버전, 뷰어, 빌드 관리, 포럼과 게시판이 포함된 프로젝트 협업 관리 시스템이다. 마치 종합 선물세트 같은 이 솔루션은 압축만 풀면 바로 협업에 사용할 수 있을 정도로 설치가 쉽다. 2008년 Jolt Productivity와 Software Dev. Jolt Awards를 수상한 바 있으며, 라이선스 정책에 따르면 오픈소스 프로젝트와 5명 이하 2개 미만의 프로젝트는 무료로 사용할 수 있다.

새로운 도구 도입에 대한 부정적인 시각
무엇이든지 간에 새로운 것에 대한 거부감은 있게 마련이다. 기존에 관리되지 않거나 새롭게 시작된 프로젝트의 경우 툴에 대한 적응은 물론 이와 관련된 부정적인 시각을 줄이기 위해서는 팀원들과 먼저 만들어가는 기본적인 신뢰와 약속으로 프로젝트를 정의하고 이를 지켜야만 한다는 책임 의식을 갖도록 상호 간의 거리를 좁히는 것이 가장 우선돼야 한다.

그러나 이슈 트래커를 사용하다 보면 이슈 자체에 대한 잘못된 해석이 건강한 이슈관리를 훼손하기도 한다. 이를테면 ‘이슈를 많이 만드는 팀은 문제가 있는 팀’이라던가 ‘결함이 많이 발견되는 모듈을 개발한 프로그래머는 능력이 부족하다’ 등으로 평가하는 경우다. 이것은 프로젝트의 이슈 자체를 투명하게 이끌어내고 적극적으로 관리함으로써 경험을 축적하고자 한 이슈 트래킹의 근본 목적과 상반될 뿐 아니라 이슈 자체를 은폐하는 문화를 조장할 수 있다. 따라서 이슈는 해결해야 하는 태스크 그 이상도 이하로도 여기지 않는 풍토를 정착시키는 것이 중요하다. 

중요한 점은 조기에 혼란을 얼마나 최소화할 수 있는지 여부가 관건이다. 이슈 트래킹에 점차 익숙해지고 프로젝트의 문화로 자리 잡으면 다음과 같은 이점을 얻을 수 있다. 지금부터 긍정의 마인드로 새로운 변화를 만들어보자.

● 노하우 축적
모든 이슈에 대한 이력이 관리되고 축적되면 이러한 노하우들은 회사의 중요한 자산이 된다. 반복되는 문제에 대한 올바른 해결책을 도출하기 쉬워지고 조직의 업무 처리 능력에 변화를 가져온다. 버그 트랙에서 통계적인 데이터를 만들어주지만 이를 활용하는 것은 전적으로 사용자의 몫이다.

● 확실한 결정과 공유
이슈는 상태와 담당자라는 항목이 있기 때문에 방치되는 업무를 줄일 수 있다. 특정 상태로 진전이 없는 이슈에 대한 조치나 담당자 할당 규칙, 이슈 처리 과정에서 발생하는 문제 처리 절차 등 버그 트랙을 통해 의사 결정에 필요한 프로세스를 검토하게 돼 조직을 좀더 탄탄하게 만들어준다. 또한 등록된 모든 이슈에는 확실한 결정이 뒤따르는 이점이 있다. 항상 최선의 해결책이 나오는 것은 아니지만 일련의 과정을 통해 조직의 의사 결정과정을 성숙시키는 밑거름이 될 것이다.

때론 누구나 해도 되는 일이면서 누구도 담당하지 않은 일이 있다. 이 경우 대체로 서로 일을 미루게 되는데 그 결과가 좋지 않을 것으로 생각될수록 더욱 그렇다. 이런 일이 생기는 원인은 조직 구성원이 특별히 이기적이기 때문이 아니다. 조직의 능력과 수준의 문제다. 만약 버그 트랙을 쓰면 어떤 일이 이렇게 미뤄지고 있는지 확연히 드러난다. 미루기만 해서는 나아질 수 없다. 변화를 통해서 문제를 해결해야 함을 잊지 말아야 한다.

● 분석 및 평가
다양한 이슈 트래커는 유용한 통계 자료를 제공하는 대시보드 등을 제공한다. 이를 활용할 만큼 프로세스가 성숙됐으면 유용하겠지만 그렇지 않으면 아무런 의미가 없다. 오히려 사용을 경계해야 할 정보일 뿐이다. 예컨대 버그 트랙에 문제점을 등록하는 것이 철저하게 지켜지지 않는다면 문제점을 공유하고 함께 해결하기 위해 등록한 것이 오히려 문제가 많은 제품으로 여겨질 수 있다. 반면, 문제가 많음에도 등록하지 않는다면 그 제품은 결국 품질 문제로 이어져 결코 좋은 평가를 받지 못할 것이다. 업무 평가도 마찬가지다. 

버그 트랙에 많은 이슈를 등록하고 해결한다고 해서 꼭 일을 잘하는 것은 아니다. 오히려 문제가 많은 제품을 만들어서 새로운 제품 개발에 써야 할 시간을 허비하고 있을 수도 있다. 이처럼 시스템이 제공하는 정보는 정보 자체일 뿐이다. 이에 대한 해석과 활용은 시스템 사용자의 문제다.

트랙뿐 아니라 모든 이슈 트래커의 궁극적인 목표는 팀 관리다. 발생한 문제점에 대해서 누가 언제 조치를 취하는가를 명확하게 하기 위해 해당 이슈를 할당하는 것이다. 효율적인 팀 관리를 돕는 오픈소스 기반 이슈 트래커는 이 같은 고민에 빠진 관리자들에게 좋은 해결책이 될 것이다.