이슈 트래커와 형상 관리 도구를 사용하기 위한 일반적 지식

프로젝트를 수행함에 있어서 참여 주체간의 원활한 소통은 프로젝트의 성패를 좌우하는 핵심 요소 중의 하나라고 단언할 수 있습니다.

고객 및 사용자, 기획 및 설계자, 개발자, 품질 보증 조직 등 참여 주체간에 커뮤니케이션을 명확히 하여 혼선을 막고, 요구 사항 또는 이슈의 처리 결과를 예측 가능하도록 하여 각 주체가 수행 할 역할에 각 자원을 집중 할 수 있도록 환경을 구축 하는 것이 필요 합니다.

이런 필요를 돕는 도구로 이슈 트래커, 형상 관리 도구, 위키 등과 같은 협업 도구를 예로 들 수 있는데 이번 포스팅에서는 이슈 트래커와 형상 관리 도구에 초점을 맞추어서 일반적인 사항을 다루어 보고자 합니다.

■ 이슈트래커

이슈트래커(Issue tracker)는 버그 트래커(Bug tracker)라고도 불리는데 이름에서도 짐작할 수 있듯이 가장 많이 사용되는 곳은 개발 조직과 품질 보증(Quality Assurance) 조직 입니다. 개발이 어느 정도 진행 되면  품질 보증 조직에서는 스펙대로 개발했는지 확인하기 위하여 테스트를 수행하고 그 과정에서 발견되는 버그들을 "디자인이 별로다!", "마음에 별로 들지 않는다!", "기능이 별로다!"와 같이 불평하는 것이 아니라, 기대 결과는 RRR인데 실제 결과로는 SSS였다, 그리고 이 현상을 재현해 볼려면 DDD로 하면된다와 같이 구체적인 현상 기술과 스크린샷이나 덤프와 같은 구체적인 자료를 첨부하여 이슈를 등록 합니다. 

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

  

개발자는 자신에게 할당되어진 이슈에 대해서 해결 예정 일시를 설정하고 개발에 들어 갑니다. 개발은 형상 관리 도구에서 최종 버전의 소스 코드를 업데이트 하는 것으로 시작 합니다. 여러 개발자가 프로젝트의 일부분을 담당하여 개별로 수정하더라도 각 개발자는 완전한 프로젝트 패키지를 가지고 작업할 수 있으니 개발 과정에서 개별 테스트 또한 가능해 집니다. 수정 과정을 통해서 이슈가 해결되었다고 판단하면, 개발자는 수정 내용을 diff 도구를 활용하여 패키징하고 수정 내역을 간단하게 설명하여 프로젝트 멤버들에게 코드 리뷰를 받던가, 관리자의 리뷰를 받아 리뷰 과정에서 추가 수정 내역이 있으면 반영하여 형상 관리 도구에 커밋하고 이슈 상태를 해결로 수정 합니다. 이때 형상 관리 도구에의 커밋 당시 리비전을 이슈에 함께 저장하여 이슈와 소스 코드를 연결해 놓습니다.

품질 보증 조직은 해결 상태의 이슈들에 대해서 각 이슈의 최초 등록 시점의 요구 사항이 제대로 반영되었는지, 이 이슈 해결로 인해서 다른 문제를 발생 시키지는 않았는지(풍선 효과), 성능 퇴화가 있지는 않는지 등을 확인하여 문제가 없다면 이슈를 종료 시킵니다. 품질 보증 조직은 개발 조직에서 실행 프로그램을 전달 받는 것이 아니라, 형상 관리 도구의 최종 리비전을 업데이트해서 새롭게 빌드하여 임의적 수정이나 소스 패키지의 변형 등에 대한 상시적 검사도 수행 합니다.

이런 품질 보증 조직과 개발 조직간의 소통을 오늘날에 이르러서는 영업조직, 기획자, 설계자, 오픈 소스 개발자, 고객 및 협력사까지 확장하여 협업하는 체계까지 도입하고 있는 상황 입니다.

그러면 왜 이슈 트래커를 도입하는가? 이 물음에 대한 몇가지 답을 정리해 보면 아래와 같습니다.

• 고객의 요구나 불만을 듣고 상황을 모면하는 것에 그치는 것이 아니라, 고객의 요구나 불만은 조직의 자산이라 여기고 이슈 트래커에 등록하여 관리한다.

• 각 이슈의 해결은 형상 관리 도구의 특정 리비전을 통해서 해결의 과정을 구체화 할 수 있다.

• 후임자는 이슈 기록과 형상 관리 리비전을 통해서 수정 과정을 되짚어 볼 수 있다.

• 관리자는 조직의 자원이 어떻게 사용되는지 구체적으로 파악하여 효과적 자원 활용을  도모 할 수 있다.

• 프로젝트 참여자는 각 구성원의 역할과 임무에 대해서 공유하고 프로젝트의 진행 상황을 판단할 수 있다.

이슈 트래커는 단순히 게시판이나 포럼과 같은 일반적인 도구에 정보를 기록하여 관리하는 방법과 이슈 트래킹만을 목적으로 해서 전문적으로 기능을 구현하는 방법, 프로젝트 관리, 형상 관리도구, 위키등의 다른 도구와 통합 형태로 구현하는 방법이 있습니다.

여러 도구를 하나의 플랫폼에 통합한 형태는 세계 유수의 오픈 소스 포털이 사용하는 방식으로 sourceforge.net, 깃허브 등을 대표적인 예로 들수 있고 패키지로는 gForge, Trac 등이 있습니다.

이슈 트래킹 전문 도구로는 Bugzilla(https://www.bugzilla.org/), Mantis(http://www.mantisbt.org/) 등을 들 수 있습니다.

■ 형상 관리 도구(Software Configuration Management)

형상 관리 도구는 소스코드나 이미지, 문서 변경 과정의 모든 정보를 체계적으로 관리할 수 있도록 돕는 도구로서, 이슈  트래커와 연동하여 밀접하게 사용하거나 단순하게 소스 코드의 형상 관리 목적만으로 사용하기도 합니다.

서버와 같은 다중 사용자 환경에서는 해당 서버에 소스 코드 Repository를 두어 서버 내부에서만 형상 관리를 할 수도 있겠지만 Repository를 설치한 서버에 형상 관리 서버 포트를 개방하거나, 웹 인터페이스를 제공하여 형상관리를 운영체제나 사용자 환경에 제약받지 않고 사용 할 수 있도록 하는것이 보다 협업에 효과적이라 할 수 있습니다.

아래의 그림은 Repository를 전세계의 개발자에게 Read 권한으로 공개하고 Write(Commit)는 프로젝트 개발자로 제한하는 형태인 sourceforge.net에서 Filezilla FTP 도구의 소스 코드를 내려 받고 있는 모습 입니다.

기업이라면 외부로 공개되지 않는 내부 네트워크에 유사한 방식으로 공개하거나, Read 권한 조차도 지정한 사용자로만 제한하는 방식으로 Repository를 운용할 수 있습니다.

아래의 그림은 한 프로젝트의 트렁크(trunk) 리포지토리 리비전 그래프(Repository Revision graph)로 trunk를 중심으로 소스가 변경되다가 중간에 가지를 만들었고 최종적으로는 5083 리비전임을 확인할 수 있습니다.

형상관리 단위는 개별 프로젝트 마다 결정할 사안이지만 형상관리 단위는 멤버간 협업의 단위로, 상호 연관성이나 협업이 없고 인터페이스도 존재하지 않는다면 별도 분리된 형상 관리 단위로 관리 하는 것이 좋다고 생각 합니다. 소스 포지나 깃허브에서는 한 프로젝트에 한 형상 관리단위를 제공하는 형태로 서비스 합니다.

일단 한 프로젝트에 한 형상관리단위를 적용한다는 가정으로 일반적인 사용 경험을 설명하면 Repository를 형상 관리 서버에 생성한 다음에는 우선 trunk, branches, tags 디렉토리를 추가 합니다. trunk 디렉토리는 프로젝트를 시작하는 곳으로 프로젝트의 현재 모습을 확인할 수 있는 메인 디렉토리 역할을 하도록 합니다. branches는 특별한 목적에 따라 새로운 가지를 만들어가면서 작업하기 위한 공간의 역할을 수행 합니다. tags는 alpha, beta등 trunk나 branches의 특정 시점 모습을 담는 역할을 수행하도록 하는 것이 다양한 프로젝트에서 적용되는 사용 경험 입니다.

다음은 서울의 A개발자, 부산의 B개발자, 제주의 C 개발자가 형상관리도구 기반으로 작업하는 프로세스를 예로 들어 본 것입니다.

A개발자는 프로젝트를 기획 및 설계하고 초반 개발을 주도했으며, 프로젝트에서 Core부분 개발과 코드 리뷰를 담당한다.

B개발자는 통신 모듈과 공통 모듈 개발을 담당한다.

C개발자는 주니어로 프로젝트에서 테스트를 담당한다.

• A는 서버에 형상관리도구와 이슈트래커를 설치하고 네트워크를 통해서 접근할 수 있도록 설정한다.

• A는 서버에 Repository를 생성하고 개인적으로 작성하던 코드들을 import하여 등록한다.

• A, B, C 모두 자신의 PC에 형상관리도구 접속을 위한 환경(클라이언트 설치)을 설치하고 프로젝트를 체크아웃(check out)한다.

• B는 자신이 담당한 부분을 개발하고 기존 모듈과 결합하여 테스트하며 디버깅을 수행한다.

• B가 개발이 완료되었다고 판단하면 Patch를(현 Repository와 diff) 만들어 멤버들에게 메일로 전송한다.

• C의 커멘트를 받을 수도 있지만 A가 OK라고 응답하면 B는 코드를 Repository에 커밋(commit, check in)한다.(대부분의 형상관리도구는 커밋 시점에 Hook을 통해서 메일 발송이나 기타 자동으로 특정 기능을 수행할 수 있는 기능을 제공 합니다)

• B는 코드 커밋후에 해당 이슈의 상태를 해결로 수정한다.
  (이런 경우 통상 이슈 트래커에서 관련이 있는 사람들에게 자동으로 메일이 발송되도록 하는 기능을 제공 합니다)

• C는 이슈 해결 통지가 오면 해당 이슈가 제대로 해결되었지 확인하기 위해서 일단 소스를 Update하여 최종 코드를 확보하여 새롭게 빌드한다.

• C는 최종 빌드를 가지고 이슈가 해결되었는지, 풍성 효과로 인한 퇴행은 없는지 등을 확인하고 문제가 있으면 이슈를 다시 개발자에게로 돌려주거나, 새로운 이슈를 등록한다. 문제가 없다면 이슈를 종료시킨다.

형상 관리 도구를 사용하는 장점은 무엇일까? 다음과 같이 생각해 보았습니다.

• 여러 개발자가 장소와 시간에 구애 받지 않고 효과적으로 협업할 수 있다.

• 개발자 간의 수정 과정에서 발생할 수 있는 충돌 문제를 효율적으로 관리 해결할 수 있다.

• 조직간 유기적인 협업이 가능하다.

• 코드와 이슈 트래커를 통한 지식 전달의 매체 역할을 할 수 있다.

• 모든 개발자가 각자 완전한 빌드 환경을 가지고 독립적으로 작업함과 동시에 통합을 용이하게 할 수 있다.

• 회사의 모든 소스 코드를 통합적으로 관리할 수 있다(권한을 포함하여)

전통적인 형상 관리 도구로는 cvs와 Subversion을 들 수 있고, 요즘은 git를 많이 사용하기도 합니다.(모두 무료)

유료로는 MS의 SourceSafe와 IBM의 Clearcase가 대표적인데 Subversion 정도면 어떤 유료 도구에 뒤지지 않는다고 추천할 만 합니다. 특히 Subversion은 대부분의 운영체제에서 지원하고 있고, 여러 이슈 트래커와의 연동, Eclipse나 Visual studio(AnkhSVN을 통해 가능)와 연동 등을 지원하는 측면에서 보면 기업내 형상 관리 도구로 적극 추천할 만 합니다.

단순히 도구를 설치해서 사용하는 것으로 대부분의 필요는 해결 되겠지만 문제가 생기거나, 도구 자체의 오류가 있거나, 도구를 기업의 실정에 맞게 수정하고 싶다면 기술적 지식 배경도 어느 정도 확보할 필요가 있습니다.