필자가 처음 개발 업무를 시작했을 때는 사용하는 툴은 에디터와 컴파일러, 그리고 빌드를 위한 make 등의 툴이 개발에 필요한 도구의 전부였다. 하지만 소프트웨어 개발 프로젝트의 규모가 커지고 업무는 복잡해지고 참여 인력이 많아지면서 원활한 개발과 프로젝트 진행을 위해서는 여러가지의 관리용 도구와 기법을 사용해서 관리해야 할 정도로 업무 환경이 복잡해졌다.

그중에서는 이 책에서 다루는 버전 관리, 이슈 관리, 아티팩트 저장소 관리, 지속적인 통합등이 있으며 그 외에 문서 및 지식 관리, 테스트 및 커버리지 도구, 리스크 관리 시스템등이 있다.

하지만 모두를 사용할 수 없는 환경에 놓이고 이중에서 두 개만 고르라고 한다면 필자는 버전 관리 시스템과 이슈 관리 시스템을 선택할 것이다.

과연 그러면 왜 이렇게 이슈 관리 시스템이 중요한지 생각해 보자.

전통적인 버그(Bug) 관리

소프트웨어 버그는 의도하지 않거나 잘못된 결과를 만들어 내는 에러나 실패, 실수등을 의미한다. 버그는  설계나 코딩상의 실수, 프레임워크나 운영 체계, 또는 컴파일러의 문제 등등 다양한 원인을 갖고 있다. 

세상에 버그없는 소프트웨어는 없다고 하며 특히 새로운 소프트웨어 제품을 만들거나 기존 제품을 개선할 경우 버그의 발생은 필연적인 것이라고 하지만 심각한 버그의 경우 치명적인 결과를 야기할 수 있으므로 체계적인 관리가 필요하다.

 

예전에는 주로 버그 관리를 이메일이나 전화, 구두로 보고 받고 이를 엑셀이나 워드 파일로 작성한 후에 내용이 변경되면 다시 이메일로 전송하거나 파일 서버등에 올려서 공유하는 경우가 많았다.

이런 방식은 다음과 같은 단점이 있었다.

  • 체계적인 버그 관리가 어렵고 변경시 이를 통보하고 리뷰하고 의견을 취합하는데 효율적이지 못하므로 오랜 시간이 걸리고 데이타 정합성을 유지하는 게 힘들다.
  • 버그는 대개 소프트웨어 변경때문에 발생하지만 엑셀과 워드는 버전 관리 시스템과 연동이 안 되므로 어떤 변경때문에 발생했는지 추적과 확인이 어렵다.
  • 버그를 보고 받은 이와 수정하는 이가 동일하지 않은 경우가 많지만 이렇게 업무를 할당하고 진행 상황을 공유하기가 어렵다.
  • 기존 비슷한 사례가 있는지 확인하고 싶을 경우 데이타가 파일 서버나 이메일에 있을 경우 제대로 검색이 안 될 수 있다. 특히 이메일은 내가 수신자로 등록되어 있지 않았다면 존재 여부를 확인할 수 없다.

이슈 관리 시스템의 특징

이슈 관리 시스템은 버그 관리 시스템이라고 하기도 하지만 버그 관리는 이슈 관리의 부분 집합이다. 이슈는 사전상으로는 "문제"라는 의미가 있어서 "이슈" 라고 할 때 문제로 인식하는 경우가 많고 이로 인해 "버그" 자체를 "이슈"로 생각하는 경우도 많다.

하지만 이슈의 다른 뜻으로는 "(논의・논쟁의 중요한) 주제[안건], 쟁점, 사안" 의 뜻도 있으며 이슈 관리에서 의미하는 건 후자가 더 맞을 것이다.

이슈 관리 시스템의 종류에 따라 이슈에 대한 정의는 약간씩 다르지만 일반적으로는  프로젝트를 진행하면서 발생하는 모든 사항들  (새 기능 구현, 기존 기능 개선, 버그 수정, 데이타 이관, 시스템 설치, 문서 작업, 해야할 작업, 성능 테스트, 물품 및 장비 조달, 고객 지원팀이 수신한 고객 요청 사항, 영업팀의 문의 사항 등) 을  의미하며 이런 이슈들은 이슈 관리 시스템을 통해 별도의 생명 주기와 작업 흐름을 갖고 추적 및 관리되고 있다.


위의 모든 사항을 이슈라고 본다면 이슈 관리의 총합은 프로젝트 관리의 대부분을 차지 한다고 볼 수 있으며 대부분의 이슈 관리 시스템이 프로젝트 관리도 표방하고 있는 이유를 이해할 수 있을 것이다.

그러면 정보를 공유하고 협업과 이력 관리를 하기 위한 이슈 관리 시스템의 주요 특징들에 대해서 알아 보자.

 

이력 관리 도구

소프트웨어 개발은 매우 복잡한 작업이며 프로젝트 진행중에 수행하는 개별 작업(업무 분석, 특정 기능 구현, 테스트, 설치등)들은 많은 실패와 시행 착오를 겪게 되지만 이런 실패를 통해 얻게 되는 경험과 지식은 향후 발생하는 문제를 해결하는데 매우 유용하고 꼭 필요한 지식이다.

하지만 이런 지식들을 나중에 참조하기 쉽게 만드는 것은 매우 어렵지만 꼭 필요한 도전적인 일이다.


엑셀은 개인 PC나 파일 서버에 존재하므로 다른 이들과 협업이 어렵고 작은 실수로 여럿이 어렵게 작업한 결과를 날릴 수 있는 위험이 있다. (파일 서버에 있는 엑셀 파일을 내가 수정했는데 다른 이는 실수로 그 이전 버전을 기반으로 수정한 후 덮어 쓰면 내가 한 작업은 모두 사라져 버린다.)

또 이메일은 검색 속도가 느리고 개인 PC 에 있으므로 직접 메일을 수신하지 않았다면 자료가 존재하는지 여부부터 알기가 어려우며 이메일로 토론할 경우 최종 상태를 명확하게 알기가 힘드므로 이력 관리에 적합하지 않다. 


이슈 관리 시스템은 모든 자료가 중앙 서버에 있고 동시성 제어가 되므로 여럿이 협업해도 예전 버전을 문제가 발생하지 않으며 최종본에 대해서 신경 쓰지 않아도 되며 최종 상태가 관리되므로 한 눈에 처리 내역과 결과를 파악할 수 있으며 다양한 조건으로 이슈를 검색 및 분석하고 정확한 현황을 알 수 있다.

엑셀 + 이메일과 이슈 관리 시스템은 "파일과 디렉터리로 소스를 관리하는 것"과 "전문 버전 관리 시스템"을 사용하여 소스를 관리하는 것으로 비교할 수 있다.

협업/의사 소통 도구

소프트웨어 개발에는 많은 이해 당사자(Stake holder) 가 존재할 수 있다. 이해 당사자은 직무에 따라 개발이나 소프트웨어에 대한 이해도가 다르기 마련이지만 PM과 개발팀은 다양한 이해당사자들과 소통 및 협업을 해야 한다.

개발팀이 사용하는 도구들은 개발자들에게는  필수적인 도구이지만 다른 직군과 소통할 때 사용되는 도구는 아니다. (영업 담당자가 버전 관리 커밋 내역을 보거나 최근 빌드된 아티팩트를 확인할 일은 많지 않을 것이다.)

이슈 관리 시스템은 보통 웹을 기반으로 제공되므로 브라우저만 있으면 사용할 수 있으며 게시판을 사용해 보았다면 이슈를 올리고 공유하는 기능은 크게 어렵지 않으므로 개발자가 아니더라도 쉽게 참여가 가능하다. 

또 이슈 관리는 버전 관리나 지속적인 통합등의 다른 기반 시스템과의 밀접한 연계를 지원하므로 현업에서 등록한 이슈가 어떻게 구체화 되고 처리되고 있는지 한눈에 파악할 수 있다.

 

 

 

작업흐름 (Work Flow)

프로젝트 진행시 대두되는 이슈들은 발생 -> 종료의 간단한 작업흐름을 갖지는 않는다. 실제로는 아래 그림처럼 복잡한 작업 흐름을 갖게 되며 각 상태는 다른 상태로 전이될 수 있다. (화살표는 전이(Transition) 이며 네모는 상태(Status)를 의미한다.)

실제 버그가 보고되고 해결되는 작업 흐름을 살펴 보자.

 

최초에 버그가 보고되면 "이슈 생성" 전이를 거쳐 "개설됨" 상태에 놓이게 된다. 이제 담당자를 지정하면 담당자는 "처리 시작" 전이를 거쳐 "진행중" 상태로 들어가게 된다. 

진행중인 버그는 "이슈 해결" 전이를 통해 "해결됨" 상태에 들어가지만 다른 사용자가 비슷한 버그를 리포팅하면 "재 개설" 전이를 거쳐 "재개설됨" 상태에 놓이게 된다.

 

업무를 진행하면 실제 이슈들은 이렇게 다양한 상태간에 전이가 일어 나고 있다.

전이와 상태 변경 기능은 대부분의 이슈 관리 시스템이 지원하는 기능으로 사용 방법은 메뉴에서 상태를 선택해서 저장하면 바로 반영되므로 사용법은 설명처럼 복잡하지 않다.

 

이슈 간의 관계(Association)

프로젝트 관리에 대한 자격증인 PMP(Project Management Professional)는 일정 관리 부분에서 실제 수행할 활동(액티비티)간의 연관 관계 및 의존성을 파악하고 관리하는 것을 권장하고 있다. 이에 따라 기본적으로 도출되는 의존성 관계는 총 4개이다.

  • FS(Finish-to-start) - 앞의 작업이 끝나야 뒤의 작업을 시작할 수 있음. 

  • FF(Finish-to-finish) - 앞의 작업을 마쳐야 뒤의 작업도 마칠 수 있음.

  • SF(Start-to-finish) - 앞의 작업을 시작해야 뒤의 작업을 마칠 수 있는 있음.

  • SS(Start-to-start) - 앞의 작업을 착수해야 뒤의 작업을 시작 할 수 있는 있음.

실제 프로젝트를 진행하다 보면 위의 관계보다 더욱 다양하고 복잡한 관계와 링크가 발생하게 된다. 예로 원인은 한가지인 버그가 사용자 단에서는 다양한 조건과 화면에서 발생할 수 있으며 이로 인해 다수의 버그 리포팅이 있을 수 있고 이는 PMP 에서 정의되지 않은 중복 관계라 볼 수 있다.

이슈 관리 시스템에서 중복된 이슈를 처리하는 모범 사례는 중복 이슈들을 삭제하는게 아니라 이슈간의 관계를 "중복됨"으로 설정하고 처리가 완료되면 나머지 중복 이슈들을 해결 상태로 전이하는 것이다.

 

새로운 기능 개발이나 개선은 버그를 만들어 낼 수 있으며 버그가 발생하면 이의 원인이 된  "새로운 기능 요청" 이슈를 "관련됨" 관계로 연결하면 이 버그가 어디에서 기원했는지 알 수 있으며 이와 관련된 버전 관리 시스템의 커밋 내역만 따로 뽑아서 분석하면 손쉽게 버그의 원인을 찾고 수정할 수 있다.

 

Road Map 과 버전 관리

프로젝트의 산출물은 0.0 에서 시작해서 바로 1.0 으로 진행되지 않는다. 사이에는 다양한 버전이 있을 수 있으며 각 버전마다 이정표(마일스톤)이 존재할 수 있다.

이슈 관리 시스템은 이슈들을 버전이라는 논리적인 집합으로 묶고 이를 기반으로 로드맵을 만들 수 있는 기능을 제공하므로 단위 이슈들에 대한 자세한 정보 확인도 가능하지만 큰 시야에서 현재 프로젝트의 상황과 온 길 나아가는 방향을 한 눈에 살펴 볼 수 있다.

다양한 시스템과 연동

많은 이슈 관리 시스템들이 REST API 를 제공하므로 이를 기반으로 다양한 외부 시스템에서 연동을 할 수 있다. 예로 서비스 모니터링중 특정 상황이 발생한다면 이를 이슈로 등록하여 관리할 수 있는등 다른 시스템과 연동을 통해 더 체계적으로 관리가 가능하다.

 

도입시 고려 사항

현재 시장에는 버그 관리 또는 이슈/프로젝트 관리를 지원하는 다양한 제품들이 출시되어 있다. 도입한 이슈 관리 시스템은 사용중에 타 제품으로 변경이 쉽지 않고 변경시에는 데이타 이관등에 많은 시간과 비용이 발생하게 된다.

그러므로 출시된 많은 제품들중에 도입할 제품을 선정할 경우 주의깊게 고려해야 할 사항들에 대해서 알아 보자.

 

사용성

이슈 관리 시스템은 개발팀외에 다른 팀과 협업시에도 사용하게 되므로 편리하고 쉬운 사용을 제공하는 것이 매우 중요하다.

사용법이 너무 복잡하거나 UI 가 미려하지 않거나 잘 사용하기 위해서는 마크업 언어를 배워햐 하는등의 진입 장벽이 있을 경우 참여를 꺼리게 되며 개발팀 전용 도구로 인식되거나 버그 관리 전문 시스템 등으로 용도가 한정될 수 있다.

 

비용

크게 무료인 제품과 상용인 제품으로 나뉘어 지며 상용의 경우 비용은 사용자 수 등으로 라이선스가 책정되게 된다. 상용이 보통 기능이나 교육, 문서및 사용자 경험이 좋은 편이므로 예산이 있고 지속적으로 잘 사용할 의지가 있다면 상용 제품을 도입하는 것도 괜찮다.

예산이 없다면 무료인 제품중에 선정해야 하며 주요 제품으로는 맨티스(Mantis), 트랙(Trac), 버그질라(BugZilla) 그리고 이 책에서 다루는 레드마인등이 있다.

 

연계 지원

잘 정의된 API 를 제공하여 외부에서 연계를 지원해야 하며 또 해당 이슈 관리 시스템과 연동을 지원하는 제품들이 많은게 좋다. 특히 이슈 관리는 버전 관리 시스템과 밀접하게 연동되므로 사용하는 버전 관리 시스템과 연계되는지 확인해 보는 것이 좋다.

 

서비스 방식

보통 소프트웨어를 보유한 하드웨어에 설치하여 사용하는 경우가 많지만 관리의 편이성때문에 웹 기반의 호스팅 서비스를 원하는 경우도 있다. 도입하려는 제품이 원하는 서비스 방식을 제공해 주는지 확인해 보자.

 

검색과 리포팅

이슈 관리 시스템은 도입하고 일정 궤도에 오르면 사용 빈도가 매우 높아지게 되며 이에 따라 많은 데이타가 쌓이게 된다. 이런 단계에서는 등록된 이슈를 대상으로 복잡한 조건으로 검색하고 이를 가공하여 다양한 보고서를 생성하는 경우가 많다.

사용하려는 시스템이 이런 기능을 만족하는지 확인해 보자.

 

주요 제품

다양한 제품들이 출시되어 있지만 무료로 사용 가능한 오픈 소스중에 유명한 제품과 상용 제품에 대해서 간략하게 알아 보자.

아주 많은 ITS를  써보진 못했지만 위의 도구들을 쓰면서 느낀 도구별 장단점을 간단하게 정리해 보고자 한다.


맨티스(mantis)

PHP 로 개발된 제품으로 버그 관리에 특화된 시스템이라고 볼 수 있다. 설치와 사용은 간단하지만 제대로 활용하기에는 기능이 좀 부족하고 UI 가 그리 미려하지 않아서 비 개발자 부서의 사용을 유도하기에는 어려움이 있다.

그리고 버전 관리 시스템과 연계가 그리 뛰어나지 않으며 여러 개의 저장소를 지원하지 못하는 등 제약 사항이 많았으므로 그리 추천하지 않는 시스템이다.


버그질라(Bugzilla)

모질라 브라우저의 버그를 관리하기 위해 모질라 재단에서 만들었으며 Perl 언어로 개발되었다. 버그 추적 및 관리가 주 용도이며 리눅스 커널, 레드햇 엔터프라이즈 리눅스등 여러 오픈 소스 프로젝트에 적용되었다.

개발자가 주로 사용하는 도구이므로 다른 직군의 사용자들은 어려워할 수가 있으므로 용도를 명확히 정의하고 도입하는게 좋다.

 

레드마인(Redmine)

루비 온 레일스 프레임워크를 사용하여 개발된 웹 기반의 이슈 및 프로젝트 관리 시스템으로 이슈 관리, 시간 관리, 위키 시스템, 버전 관리 통합, 게시판, 달력등 프로젝트 관리에 필요한 대부분의 기능을 기본적으로 제공하고 있다.

 

작업 흐름이나 이슈의 종류, 권한 관리등을 프로젝트나 업무의 특성에 맞게 설정할 수 있으므로 프로젝트나 업무의 상황에 맞게 설정하여 사용할 수 있으며 미려하고 심플한 UI 를 제공하므로 개발자가 아니더라도 어렵지 않게 사용할 수 있다.

 

특히 비슷한 제품인 Trac 에 비해 버전 관리 시스템 연계가 뛰어나며 프로젝트마다 별도의 버전 관리 저장소를 연계할 수 있으며 커밋 메시지에 따라 이슈의 상태를 변경할 수도 있다.

 

단점은 검색과 리포팅 기능이 상용 전문 이슈 관리 프로그램보다는 미약한 편이며  프로젝트와 이슈가 많아질 경우 다양한 조건으로 이슈를 검색하거나 이 결과를 가공해서 리포팅을 생성할 경우 불편할 수 있다.

또 이슈나 위키 페이지를 작성할 때 텍스트에 효과를 주려면 Textile 이라는 마크업 문법으로 작성해야 하므로 진입 장벽으로 작용하며 마크업 문법을 익히는 것은 비개발자라면 어려움을 느낄 수 있다.

 

지라(JIRA)

협업 솔루션 전문 회사인 아틀라시안 사의 상용 이슈 관리 시스템이다. 뛰어난 성능과 편리한 기능을 제공하고 있으며 UI 가 미려하고 강력한 커스터마이징 기능을 통해 목적에 맞게 화면이나 작업 흐름을 최적화 할 수 있다.

JQL 이라는 SQL 비슷한 검색 언어를 제공하므로 다양한 조건의 검색과 통계를 수행할 수 있으며 잘 작성된 사용자 설명서를 제공하고 있으며 잘 설계되고 사용이 쉬운 API를 제공하므로 다양한 제품과 서비스가 지라와의 연동을 지원하고 있으므로 엄청난 확장성을 갖고 있다.

상용이지만 오픈 소스 프로젝트에는 무료로 제공하므로 다양한 오픈소스 프로젝트가 활용하므로 모범 사례를 배우기 좋으며 이 책에서 다루는 넥서스와 젠킨스 프로젝트도 이슈 관리 시스템으로 지라를 사용하고 있다.

예산이 충분하고 이슈 관리를 도입하면 적극 활용할 자신이 있고 특히 사내에서 컨플루언스나 뱀부같은 다른 아틀라시안 제품을 쓰고 있다면 도입을 적극 검토해 볼 만한 가치가 있는 제품이다.


도입후 주의 사항

이슈 관리 시스템을 사용하기로 결정하고 도입했다면 먼저 사용자 교육을 실시하여 전사적으로 확산되도록 적극 지원하는 게 좋다. 교육시에는 사용자의 직군이나 직무를 고려해서 교육의 난이도를 결정해야 한다.

이슈 관리 시스템의 기본적인 사용법은 어렵지 않지만 버전 관리 연계, 로드맵 관리, 프로젝트 관리등은 잘 사용하려면 학습이 필요한 기능이지만 일반적인 사용자들은 이런 기능이 필요 없으므로 역할과 업무에 따라 교육을 하는게 좋으며

단계별로 여러 번에 나눠서 교육을 하는 게 효과가 높았다.

 

교육이 끝나고 이슈 관리 시스템을 정식으로 사용하게 되면 가장 중요한 부분은 모든 의사 소통의 창구로 이슈 관리 시스템을 사용하도록 정책과 문화를 만들고 이를 강제화 해야 하는 점이다.

이메일이나, 구두, 전화등 기존의 의사 소통 방식은 사용하지 않고 이슈 관리 시스템을 통해서 관리해야 제대로 이슈 관리 시스템이 정작될 수 있다.

 

물론 회의등의 오프라인 의사소통을 하지 말라는 것은 아니며 회의에 참석해서야 회의의 안건을 배포하고 관련 자료를 읽기 보다는 사전에 간략한 안건을 이슈 관리에 등록하고 회의후에는 결과를 관련 이슈에 갱신해 준다면 회의와 같은 기존 오프라인 방식의 의사 소통을 더욱 효율적으로 진행할 수 있다.

 

초기에는 익숙하지 않고 힘들겠지만 이렇게 창구를 단일화 해야 프로젝트의 모든 이력이 남게 되며 공유와 협업이 가능하며 타인이 이미 겪은 시행착오를 겪지 않을 수 있으며 점점 많은 자료가 쌓일수록 이슈 관리 시스템의 효과와 중요도를 느낄 수 있을 것이다.