이슈 트래커(Issue Tracker)인 트랙(Trac)을 어떻게 사내에 도입하게 됐고 그것으로 인한 효과와 구성원들에 대한 반응을 기록한 것입니다.
트위터에서 김기웅(@KayKimTwit)님이 질문을 하셨는데 그에 대한 답변으로서 글을 쓰게 됐습니다. 하지만 이슈 트래커를 도입하려고 하는 다른 분들에게도 참고가 되었으면 합니다. 참고로 트랙 도입하던 당시 회사 구성원은 약 20명이 조금 넘었고, 약 30명이 조금 넘는 인원까지 사용하였습니다.
트랙(Trac)을 선택하다
트랙의 도입은 형상관리도구인 서브버전(Subversion)의 성공적인 사내 정착 이후 새로운 시스템을 통해 효율 증대를 희망했던 저의 주장에 따라 시작됐습니다.
여러가지 중 트랙이 선정된 것은 비교적 다른 도구보다 예쁜 디자인이 컸습니다. 디자인이 예쁘면 개발자가 아닌 사람들도 거부감이 덜하기 때문입니다.
nFORGE도 검토되었습니다. 한국어가 잘 지원되고 PHP를 사용했으며 일정 등 개발자 외의 사람들에게도 유용한 기능이 많다고 판단했습니다. 하지만 국내 오픈소스의 꾸준한 지원에 대해 의구심을 가질 수 밖에 없어 트랙으로 정했습니다. 참고로 nFORGE는 지금까지도 잘 발전되고 있으며, 지금은 도입을 해도 괜찮을 정도라고 생각합니다.
도입의 어려움
트랙 도입을 주장한 초기에는 역시 기술자들 외 사람들의 부정적인 반응이 많았습니다.
부정적 반응들은 주로 아래와 같은 것들입니다.
- 기존 업무에 절차만 늘어나서 오히려 방해가 될 것 같아요.
- 기술적인 입력 항목들이 많아 이해하기 힘들어요.
- 몇번 써보다 안 쓰게 되는 것 아닐까요?
이런 반응으로 인해 거의 1년에 걸쳐 몇차례 도입에 대해서 이야기를 나누었으나 도입을 하지는 못 했습니다.
첫 도입 시도 이후 거의 1년 후에야 경영진의 재가와 부서장의 의지로 일괄 도입을 결정하게 됐습니다. 트랙을 테터앤컴퍼니에서 잘 쓰고 있다는 것이 어느 정도 영향이 있었던 것으로 보입니다. 레퍼런스의 중요성이 여기서도 나타나는 것 같습니다. 뭔가 새로운 도구의 도입이 잘 안 될 경우 같은 시장의 유명 업체에서 사용 중이라는 논리가 비교적 잘 먹히는듯 합니다.
트랙을 시작하다
일단 첫 도입은 개발 관련 부서만 하게 되었습니다. 여기에는 디자인과 운영, 마케팅 부서가 간접적으로 연결이 되어 있습니다.
우선 모든 서브버전 저장소를 트랙에 연결시키고, 우리가 개발하는 프로젝트들을 등록하였습니다.
초기에는 단순하게 티켓(버그, 이슈, 작업)을 발행하고 처리하는 방식으로 사용하기 시작했습니다. 기획, 디자인, 운영, 마케팅에서 개발이 필요한 것이 있으면 디자인이나 개발부서로 티켓을 발행을 하도록 요청을 드렸습니다. 잘 안 될 경우 직접 개발자가 도와주어 티켓을 발행했습니다. 티켓은 상황에 따라 다시 다른 사람이나 부서로 이관되었고, 경우에 따라서는 취소(Invalid 또는 Works for me) 했습니다.
차츰 시간이 흐르자 개발 외에 트랙의 활용 범위가 늘어나게 되었습니다.
스크럼과의 연계
개발을 위해 스크럼을 도입하였을 때 트랙의 마일스톤과 연계하였습니다.
스프린트가 시작되면 하나의 스프린트를 트랙의 마일스톤으로 등록했습니다. 그리고 스프린트 백로그를 마일스톤의 티켓으로 등록했습니다.
물론 스크럼 미팅 때는 포스트잇을 사용했습니다. 다만 코드 변경에 대한 이력과 전사적인 진척 공유를 위해 트랙에도 티켓을 만들도록 했습니다.
스크럼을 사용하지 않고 기존 방식으로 개발 할 때도 역시 기획에 따라 마일스톤과 함께 작업(Task)들을 등록하여 개발하였는데 이것에는 디자인 작업도 포함됩니다.
운영파트의 캠페인 관리
캠페인은 보통 고정적으로 처리되는 패턴과 구체적인 담당자가 있습니다. 이것을 하나의 티켓으로 처리하여 댓글이나 상태로서 캠페인의 진행과 과정을 기록으로 남기도록 하였습니다. 여기에 사용자 정의 쿼리를 통해서 담당자별로 처리 중인 캠페인을 보거나, 진행 과정별로 캠페인들을 그룹핑 하여 볼 수 있도록 했습니다.
사용자 정의 쿼리와 커스텀 필드를 사용하면 트랙을 활용해서 업무에 유용한 기능을 손쉽게 만드는 것이 가능합니다.
기획, 디자인, 개발, 운영의 전통적인 개발 프로세스
폭포수 모델의 전통적인 방식과 유사한 개발 프로세스도 많이 사용했습니다. 이 과정에서 트랙을 아래처럼 활용했습니다.
- 기획자가 스토리보드 작성합니다. 일정 회의 후 트랙에 마일스톤을 등록합니다.
- 개발자들은 모듈 개발 등의 일들을 티켓으로 만들어 마일스톤에 등록합니다.
- 기획자와 디자이너는 협의하여 디자인 티켓을 만들어 마일스톤에 등록합니다.
- 디자이너들이 디자인을 하고 티켓을 통해 기획자 및 개발자들과 의견 교환을 합니다.
- 디자이너들이 티켓에 디자인 파일을 첨부하거나 댓글을 달면 관련자들에게 자동으로 메일로서 공유가 됩니다.
- 기획자와 디자이너의 작업이 마무리 되면 개발자에게 해당 티켓이 넘어옵니다.
- 개발자들은 개발 후 티켓 완료합니다.
- 기획자와 디자이너의 일차적인 QA 후 티켓이 되살아나거나 추가되기도 합니다.
- 최종적인 테스트가 QA를 담당하는 운영부서로 넘어갑니다. 버그나 수정 사항이 발견되면 티켓이 마일스톤에 추가합니다.
- 서비스가 런칭되면서 마일스톤의 모든 티켓은 처리됨 상태로 되면 진행율이 100%로 표시됩니다.
- 다음 마일스톤 전에라도 긴급히 수정해야 할 사항이 발생하면 현재 마일스톤에 티켓을 추가적으로 발행하여 처리합니다.
마케팅 부서의 요청
마케터나 AE가 서비스 상의 변화나 개발이 필요한 사항이 있으면 티켓을 발급합니다. 이 때 티켓은 현재 진행 중인 프로젝트에서 수정이 필요한 사항은 해당 프로젝트로 보내고, 그 외의 것들은 별도의 전사적인 작업을 관리하기 위한 프로젝트로 보냅니다. 관리자들은 일정, 인력을 고려하여 해당 하는 티켓을 적절한 담당자에게 할당(Assign) 합니다. 담당자는 해당 티켓에 대해 처리를 합니다. 처리 전에 댓글을 통해서 티켓을 발행한 사람과 의견을 교환하기도 하고 경우에 따라서 개발하지 않고 티켓을 닫아버리기도 합니다.
이 부분에서 여러 프로젝트가 있는 경우 어느 프로젝트로 티켓을 보내야 하는지를 이해시키는 것이 어려웠습니다. 특히 트랙은 프로젝트 별로 좀 나뉘어지는 모양새로 이런 이해가 더욱 어려웠던 것 같습니다.
트랙 도입 후 사람들의 변화
처음에는 사용에 어려움을 호소하거나 강하게 거부하던 사람들도 사용한지 1년이 넘어가자 반대로 업무 진행을 트랙에 전적으로 의존하는 경향이 나타났습니다. 트랙에 자신과 관련된 일이 등록이 되면 이에 대해 안내 메일이 발송되는데, 다들 이 메일에 깊히 의존하게 됐습니다. 아침에 출근하여 온 메일을 확인하고, 구체적인 티켓 내용을 파악한 후 그에 따라 피드백을 보내고, 티켓을 처리한 후에 닫는 흐름이 자연스럽게 회사 내에 정착되었습니다.
한번은 구글이 트랙에서 발신하는 메일을 스팸으로 처리하여 블럭하는 바람에 트랙으로부터 메일이 제대로 송신되지 않은 적이 있었는데 이 때 사람들은 업무가 진행이 안 된다며 계속 문제 해결을 제게 요청하였습니다. 이것이 트랙 도입 1년만에 일어난 일입니다.
트랙 도입 후 잇점
회의 중에 좋은 의견이 나와서 그렇게 처리하자고 합의를 보았는데 몇 달이 지나도 그 일이 처리되지 않고 있다 사람들 뇌리에서 잊혀지는 일이 있습니다. 그러나 트랙을 도입한 이후로 이런 일은 생기지 않았습니다. 일정상 우선 순위에 밀려서 몇 달씩 티켓이 처리되지 못하는 일은 있었지만, 트랙에 티켓이 계속 남아있기 때문에 일이 완전히 잊혀져 사라지는 일이 없었습니다. 더구나 티켓에는 담당자도 할당되어 있기 때문에 일 처리가 안 될 경우 해당 담당자에게 물어보거나 왜 지연되는지에 대한 답변을 확실히 얻을 수 있었습니다.
시간이 흘러 해당 티켓이 무의미 해지거나, 우선순위에 밀려 결국 티켓을 취소하더라도 티켓을 처음 만든 사람에게 메일로 안내가 날아갑니다. 즉, 몇 달 뒤에라도 그 일이 어떻게 됐는지에 대한 피드백을 받지 못 하는 일은 생기지 않았습니다. 자신이 발행한 티켓이 처리되지 않고 닫혀버리더라도 티켓을 다시 열어 할당하는 것이 가능하므로 얼마든지 티켓에 대한 처리를 재차 요청하는 것이 가능하여 티켓의 생명에 대해 일일히 신경쓰지 않아도 되는 잇점이 있었습니다.
그리고 어떤 작업이 왜 시작됐는지 알 수 있다는 것이 트랙의 큰 잇점 중 하나였습니다.
하나의 시나리오를 가지고 이야기 해 보려고 합니다. 개발자가 코드를 보다 별 의미없어 보이는 코드를 발견했습니다. 1년 전에 6개월 계약으로 외부 업체와 연동하기 위해 추가한 코드였습니다. 그래서 개발자는 이제 별로 필요없겠다고 생각하고 삭제를 했습니다. 몇 시간 후 마케팅 부서에서 외부 업체에서 연락왔는데 갑자기 우리와 연동한 부분이 동작하지 않는다고 합니다. 마케팅 부서에 알아보니 계약을 끝났지만 서로 협력하기로 구두로 약속하고 1년 정도 더 유지하기로 한 것이라고 합니다.
이처럼 형상관리도구는 개발자로서 왜 변화한지 기록은 되어도, 회사 전체적으로 보았을 때의 기록으로는 부족한 면이 있습니다. 이렇게 트랙을 쓰면 최초로 그 일을 만들어낸 담당자에게 손쉽게 확인 할 수 있습니다. 댓글 하나만 달면 됩니다. “이 코드를 지울까 하는데 그 업체랑 계약 끝나지 않았어요?”
이런 기록은 트랙에 남아 다른 개발자가 그 코드에 대해서 의문을 갖게 되었을 때도 손쉽게 1년 정도 더 유지해야 하는 코드라는 것을 알 수 있게 됩니다. 다른 사람들의 집중을 방해하거나 시간을 빼았지 않고 말입니다.
이슈 트래커 도입시 신경을 써야 할 점
이슈 트래커의 개념이나 처리 절차, 항목의 의미 등은 개발자들에게는 어느 정도 익숙할지 몰라도 디자이너나 마케터, 운영자들에게는 쉽지 않은 개념일 수 있습니다. 그렇기에 세미나나 자료 등을 통해서 이슈 트래커 전반에 대한 충분한 설명과 강의가 필요합니다.
위에서도 언급했지만 디자인이 예쁜 이슈 트래커를 도입해야 합니다. 심리적으로 디자인이 예쁘면 보다 쓰기 쉽다라고 느낀다고 합니다. 그렇기에 이슈 트래커 중에 디자인이 예쁜 것을 도입하고, 가능하면 회사의 컨셉에 맞도록 독자적인 스킨을 입히는 수고 정도는 해주는 것이 좋습니다.
이메일을 통한 안내가 반드시 포함되어야 합니다. 레드마인과 같은 것은 한 페이지를 통해서 모든 프로젝트의 일감을 확인 할 수 있지만, 트랙은 그런 기능이 없습니다. 설사 그런 기능이 있다고 하더라도 메일과 이슈 트래커를 둘 다 살펴보고 있어야 한다면 업무에 일이 하나 더 늘었다고만 느낄 수 있습니다. 거기에 익숙하지 않은 이슈 트래커를 자주 확인도 하지 않을 것이고, 그렇다 보면 티켓을 만든 사람은 일 처리가 늦게 된다고 느껴져 점점 티켓을 발행하지 않을 수 있습니다. 티켓이 처리가 되던 안 되던 티켓을 통한 피드백이 빠르고 원활해야 많은 사람들이 점차 활용도를 높여가게 됩니다. 그러므로 무조건 모든 티켓의 발행, 처리 등은 메일을 통해서 실시간으로 관련자들에게 안내가 되어야 합니다.
일정 부분은 마일스톤의 마감일(Due date) 정도면 충분한 것 같습니다. 레드마인의 경우 간트 차트를 지원하고, nFORGE도 달력 형식의 일정 관리를 지원하기는 하나, 애자일 방법론을 쓰던 안 쓰던 마일스톤의 기간은 짧은 것이 좋고, 보통 2-3주 간격의 마일스톤이라면 각 티켓에 대한 세세한 일정 관리 보다는 마일스톤 단위의 일정 관리만 있으면 충분하다고 생각 됩니다.
가능하면 많이 쓰는 이슈 트래커가 좋은 듯 합니다. 이는 향후 꾸준한 지원이나 관련 플러그인 및 자료의 존재 때문이기도 하지만 더 중요한 것은 레퍼런스가 존재하는가 여부입니다. 많이 쓰는 이슈 트래커는 동종 업계에서 주목받는 업체에서도 사용하고 있을 가능성이 높고, 이를 통해서 부정적인 사람들에게도 받아들여질 기회를 만들 수 있습니다.
아직 이슈 트래커를 도입하지 못한 분들께
트랙을 사내에 도입한지 2년 8개월여가 지났고, 올해 초부터는 레드마인(Redmine)도 도입하였습니다. 프로젝트별로 설치하고 통합적인 관리가 지원되지 않았던 트랙에 비해, 해당 기능들이 지원되기 때문에 도입을 한 것인데 향후에 레드마인으로 완전히 이전하게 되지 않을까 합니다. 레드마인을 도입하게 된데에는 형상관리도구로 Git을 도입한 것도 한 원인입니다.
형상관리도구도 일단 적응하면 없이는 개발하기 힘들다고 하듯, 이슈 트래커도 꼭 도입을 해야 하는 유용한 도구라고 생각합니다. 다만 초기 적응 기간동안 학습 비용과 효율 저하는 감수를 해야 합니다. 하지만 그 기간이 그리 길지는 않습니다.
형상관리도구를 사용하고 계신다면 꼭 이슈 트래커도 도입해서 사용 해 보시길 추천 해드립니다. 다만, 형상관리도구를 사용하지 않는데 둘 다 동시에 도입하는 것은 추천하지 않습니다.