이슈 트래커 개발자가 들려주는 이슈 트래커 이야기, Part 2: 이슈 트래커를 슬기롭게 활용하자

박영록 pak.youngrok@gmail.com 엔씨소프트 오픈마루 스튜디오 웹서비스 개발팀에서 일하고 있다. 2007년 12월 31일

(편집자 주: 이번 연재는 대화체로 쓰여졌습니다).

연재순서
1회(2007년 11월): 무엇을 어떻게 골라쓸까
2회(2007년 12월): 이슈 트래커를 슬기롭게 활용하자

1회에선 세 가지 오픈소스 이슈 트래커를 리뷰해 보았죠? 그리고 제가 직접 이슈 트래커를 개발하면서 겪은 고민들을 다른 이슈 트래커들에서는 어떻게 해결하고 있나에 초점을 맞춰 리뷰를 했어요. 그래서 주로 이슈 트래커에 어떤 기능이 어떻게 구현되면 좋은가에 초점을 맞췄죠. 이번엔 조금 다른 각도의 고민들을 이야기해볼까 해요. 이슈 트래커가 팀 작업에서 어떤 역할을 담당하고, 어떻게 활용해야 할 것인가 하는 문제 말이죠. 때때로 이슈 트래커 자체의 기능만으로는 풀 수 없는 문제들이 생기거든요. 지금부터 그런 상황들을 하나씩 보면서 어떻게 풀어내면 좋을지를 이야기해볼 겁니다. 정답을 제시할 수는 없겠지만 이슈 트래커를 사용하는 데 도움이 될 것이라고 생각해요.

위로

할 일 목록과 이슈 트래커의 통합

예전에는 이슈 트래커를 버그 트래커(bug tracker)라 불렀어요. 지난 번에 리뷰한 버그질라(Bugzilla)의 이름도 거기서 나온 거죠. 그 때는 목적이 버그 목록 관리뿐이었거든요. 그런데 버그 트래커를 쓰다보니 기능 개선 요구나 아이디어 제안, 질문 등도 처리해야 했는데 이게 버그는 아니지만 버그와 아주 비슷한 방식으로 관리해야 하는 것들이죠. 그래서 버그 트래커의 기능을 조금만 확장하면 좀 더 범용적인 이슈를 다룰 수 있겠구나 해서 버그 트래커들이 전부 이슈 트래커로 확장된 거랍니다.
이렇게 확장해 쓰다 보면 팀이 해야 할 일의 목록과 이슈 목록이 아주 비슷해집니다. 추가 기능이든 버그 수정이든 개발자가 하는 일은 대부분 이슈 트래커에 올라올 법한 일이죠. 그러다 보니 아예 할 일 목록(to do list) 자체를 이슈 트래커로 관리하면 좋지 않겠냐는 아이디어가 나왔고 그 아이디어를 구현한 것이 지난 번에 소개했던 트랙(trac)입니다. 트랙이 이슈가 아닌 티켓(ticket)이라는 개념을 사용한다고 언급했는데 이건 개념 자체가 바뀌었음을 나타내는 것이죠.
지난 글에서 맨티스(Mantis)나 버그질라는 일반 사용자를 염두에 두고 만든 게 아니라고는 했지만 실제로 모질라 같은 프로젝트에서는 사용자들이 버그를 보고하는 창구로 버그질라를 그대로 사용해요. 이 때 이슈는 사용자가 이슈를 올리는 것에서 라이프사이클이 시작되는 거죠. 하지만 트랙은 좀 더 개발자 중심적이예요. 버그 같은 게 생기면 트랙에서는 개발자가 그 버그에 대한 티켓을 만들어요. 뭔가 할 일이 생기면 전부 티켓으로 만들죠. 그래서 티켓을 모두 완료하면 릴리스를 하게 된답니다.
사실 기존 이슈 트래커도 이렇게 사용할 수 있지만 트랙은 용어부터 이슈 대신 티켓이란 말을 사용하고 로드맵과 연동하도록 만들어서 이슈 트래커를 할 일 목록으로 사용하기 좀 더 좋은 어포던스(affordance)를 주었습니다. 그래서 할 일 목록 관리를 트랙 하나로 통합하게 되죠. 물론 다른 이슈 트래커도 그렇게 쓰게 되는 경우가 많아요. 제가 경험했던 몇몇 팀들도 처음에는 할 일 목록과 이슈 트래커를 따로 쓰다가 목록 두 개를 봐야 하는 일이 번거로워지자 그냥 하나로 통합하기로 결정하고 이슈 트래커에 할 일을 다 관리하는 상황이 되기도 했죠. 트랙 개발자도 아마 이런 현상을 겪었기 때문에 좀 더 적극적으로 통합하도록 유도하기 위해 트랙을 그렇게 만들었을 겁니다.
하지만 경험상으론 이게 좋은 것 같지 않아요. 먼저 정말 모든 할 일이 이슈 트래커로 모을 수 있는 성격이냐 하는 문제가 있습니다. 팀이 하는 일이 늘 개발 업무만 있는 것은 아니죠. 이를테면 디자인 시안을 다시 잡아본다든가, 협업하는 다른 팀과 미팅을 한다든가, 조사를 한다거나 하는 개발 이외의 업무가 늘 있어요. 그럼 이런 일들도 이슈 트래커에 올릴 수 있을까요? 물론 올릴 수야 있겠지만 그렇게 하면 이런 이슈들은 개발하는 소프트웨어의 기능이 아니기 때문에 로드맵에 포함시킬 수도 없고 릴리스 노트(release note)에 넣을 수도 없어요. 뭔가 불일치가 생기기 시작하면 결국은 또 다른 할 일 목록이 생기게 되요.
라이프사이클도 좀 달라요. 할 일 목록은 단순하게 ‘했다’, ‘아니다’만 표기할 수 있으면 되는데 이슈는 몇 가지 단계를 거칩니다. 새로 올라온 이슈를 보고 팀원들이 처리할 것인지 말 것인지를 결정하고 또 처리한다면 누가 맡았는지, 사용자에게 어떻게 피드백을 하는지 등이 다 기록되거든요. 그래서 할 일 목록 관리용으로 이슈 트래커를 쓰기는 좀 무거운 감이 있죠.

의사 소통 문제

하지만 이보다 더 근본적인 문제가 있어요. 이슈 트래커를 할 일 목록 관리로 사용하면 이런 일들이 생깁니다.

• A: 사용자가 이런 피드백을 보내왔어요.
• B: 아, 이슈 트래커에 정리해 올려주세요. 나중에 볼께요.

• A: 지난 번에 이거 말씀드렸죠?
• B: 이슈 트래커에 없잖아요. 할 일은 전부 거기에 올려주셔야죠.

위로

어떤 식으로 통합할 것인가

그래도 여전히 문제는 남습니다. "그럼 결국 목록 두 개를 관리하는 것인가?" 하는 문제 말이죠. 분명히 통합해서 보고 싶은 욕구가 있고 이 욕구를 불합리하다고 할 수는 없어요. 그럼 어떻게 해결할 수 있을까요? 아직 뾰족한 해답은 없지만 몇 가지 제시는 할 수 있을 것 같아요.

일일 회의에서 이슈 리뷰하기

많은 팀에서 매일 아침에 일일 회의를 합니다. 애자일 방법론에서 이야기하는 ‘daily standup meeting’을 생각하면 되요. 어제 무슨 일이 있었는지, 그리고 오늘 무슨 일을 할 것인지를 이야기하는 거죠. 이 때 전날 올라왔거나 변경된 이슈들을 뽑아서 하나씩 같이 이야기하면 좋아요. 이야기하다 보면 자연스럽게 이슈를 어떤 식으로 처리할지에 대해 의견을 교환할 수 있죠. 간단한 일이면 바로 처리할 수도 있을 테니 굳이 목록에 관리할 필요가 없고 좀 오래 걸리는 일이면 스토리 카드에 써서 벽에 붙여서 다른 스토리와 같이 관리할 수도 있고요.

할 일 목록에 이슈 트래커를 통합

이슈 트래커에서 할 일 목록을 관리하는 것이 부작용을 낳는다면 그 반대는 어떨까요? 위에서 언급한 것처럼 일일 회의에서 이슈를 리뷰하고 스토리 카드에 쓰는 식도 부작용이 있을까요? 경험상으로 의사 소통에 큰 부작용은 없었어요. 이슈 트래커는 아침에만 보고 바로 할 일 목록으로 전환되니까 목록을 두 개 봐야 하는 필요성도 없어졌구요. 다만, 일을 끝냈을 때 이슈 트래커에 가서, 보고했던 사용자에게 알려주는 일을 잊어 버리는 경우가 종종 생겼습니다. 그래서 스토리 카드를 쓸 때 이슈 트래커에서 온 것이라는 것을 표시하는 관례를 만들었는데 약간 번거롭지만 이 문제는 해결이 되었어요.
하지만 또 다른 문제가 있었어요. 바로 스토리와 이슈가 일의 크기와 일을 서술하는 세밀함(granulity)이 다르다는 점입니다. 스토리는 보통 작게 잡아도 하루, 보통 3일 정도 걸리는 일이 많지만 이슈는 그렇지 않아요. 큰 일도 가끔 있지만 대부분 몇 시간 안에, 혹은 몇 분 안에 해결할 수 있는 일이죠. 그러다 보니 같은 등급으로 관리하기가 좀 이상하고 스토리 기반 작업 시간 추정에도 오차를 만들어냅니다. 그래서 이슈 여러 개를 묶어 스토리 하나로 처리해 보기도 하고 별도로 작은 이슈 처리만 하는 시간을 정해보기도 했어요. 둘 다 효과가 약간은 있었지만 문제를 완전하게 해결하지는 못하더군요. 하지만 의사 소통 문제에 비하면 이 정도는 작은 문제죠. 사실 이런 크기 차이는 그냥 인정하고 하나로 통합해 가면 크게 문제가 되지는 않아요.

스토리를 소프트웨어로 관리하는 경우

스토리를 소프트웨어로 관리하면 부작용이 생긴다고 했지만 사실 어쩔 수 없이 소프트웨어로 쓰게 되는 경우가 생겨요. 위(?)에서 그렇게 하라고 정해버렸다든지, 혹은 팀원이 멀리 떨어져 있는데 협업을 해야 한다든지, 무슨 일을 했는지에 대한 업무 보고를 상세하게 써야 한다든지 하는 경우죠. 이 때는 그냥 위와 같은 방법으로 할 수도 있긴 하지만 이왕 소프트웨어를 쓰는 건데, 좀 더 편하게 할 수 있는 방법을 생각해볼 필요가 있어요.
요즘 OpenAPI를 이용해 매시업을 하는 게 유행처럼 번지고 있는데 이걸 여기서 활용할 수 있어요. 이슈 트래커들이 API를 제공하는 경우가 별로 없지만 대부분 약간만 손보면 API처럼 사용할 수 있어요. 그래서 이슈 트래커에서 최근 목록을 긁어와 할 일 목록에 통합해 보여주도록 약간만 코딩을 하면 할 일 목록 뷰에서 다 같이 볼 수가 있어요. 그래서 할 일 목록에서 완료 표시를 하면 자동으로 이슈 트래커에서 해결 상태로 바꾼다든지 하는 정도의 기능만 넣으면 쉽게 통합해 쓸 수 있죠.

용어 정의하고 공유하기

너무 무거운 이야기를 길게 끌어온 것 같아 이번엔 좀 가벼운 이야기를 해보겠싑니다. 팀에서 이슈 트래커를 사용하다 보면 용어 문제로 충돌이 생기기도 해요. 팀에서 맨티스를 쓸 때 이런 일이 있었어요. 어떤 사람이 이슈를 읽고 나서 자기가 확인했다는 의미에서 확인된 이슈로 상태를 바꿔놨어요. 그런데 다른 사람은 확인된 이슈를 앞으로 하기로 결정된 일이라 생각해 버리고, 할지 안 할지 결정이 아직 안 됐는데 그 일을 처리하고 반영해 버렸어요. 그래서 문제가 생겼죠. 이런 일을 막으려면 미리 용어들을 잘 정해 놓아야 해요. 특히 이슈 상태가 뭘 의미하는지를 잘 공유해야 해요. 이슈 트래커마다 상태에 대해 사용하는 용어와 의미가 조금씩 다르죠. 예를 들어 맨티스는 상태도 있고 처리 상태도 있어 더 헷갈리죠. 이런 경우 팀이 용어에 대해 어떤 의미로 사용할지 충분히 공유를 해야 해요.
마찬가지로 분류에 대해서도 합의해야 해요. 분류도 의사 소통 오류가 많이 생기거든요. 사람마다 각자 자기 마음대로 분류할 수 있게 하면 같은 의미인데 분류가 두 개 생기거나 하나의 분류인데 서로 다른 의미로 사용하거나 하는 경우가 생겨요. 이슈 개수가 늘어나면 분류가 필수인데 이렇게 불일치가 생기면 분류를 신뢰할 수 없게 되어 버리죠. 그래서 이슈 트래커에서 접하는 용어들은 전부 팀 내에서 공유하는 게 좋아요.

이슈는 어떻게 할당할 것인가

이 문제는 작업 할당에 대한 문제이기도 해요. 일반적으로 이슈 관리자가 있으면 이슈 관리자가 읽고 다른 팀원에게 할당해주는 경우가 많죠. 그럼 개발자들은 자기에게 할당된 이슈만 보고 작업하고요. 하지만 지난 회에서 언급했듯이 이런 구조는 부작용이 많아요. 이슈 관리자가 모든 팀원들이 어떤 일을 하는지 정확히 알아야 하는데 그렇지 못할 때가 많아 부적절한 사람에게 할당하기도 하거든요. 제대로 할당하려면 어차피 의사 소통을 한 번 거쳐야 해요. 그럴 바에는 아침 일일회의 때 이슈를 한 번 공유하고 그 자리에서 이야기하는 게 더 좋죠. 그리고 그 이슈를 가장 잘 처리할 수 있는 사람은 본인이 제일 잘 알게 마련입니다. 그래서 누군가가 일을 할당해 주는 식보다는 스스로 일을 가져갈 수 있게 유도하는 것이 좋고요.

위로

정리

기존 오픈소스 이슈 트래커를 써보고 또 직접 개발한 이슈 트래커를 다른 사람에게 써보게 하기도 했는데 그러면서 사람들이 이슈 트래커라는 시스템에 갇히기 쉬운 것 같다고 느꼈습니다. 무슨 일이든 자꾸 이슈 트래커 안에서 해결하려고 하죠. 그러다 보면 위에서 살펴본 것처럼 여러 가지 부작용이 생겨요. 가서 그냥 말 한 마디 하면 해결될 일인데 시스템에다 올려놓고 왜 안 해주냐고 투덜거리죠. 기능적으로도 그래요. 다른 소프트웨어와 조금만 조합하면 쉽게 풀 수 있는 문제를 전부 이슈 트래커의 기능으로 커버해야 한다고 생각할 때가 많아요. 저 역시 그런 함정에 빠지곤 합니다. ECUS에는 검색 조건 저장 기능이 있습니다. 그런데 사실 알고 보면 검색 조건이 URL에 반영되기 때문에 즐겨찾기만 해놔도 해결할 수 있는 문제였어요. 그런데 거기까지 생각하지 못하고 기능으로 넣어버린 거죠. 그랬더니 그렇게 저장한 검색 조건을 다른 팀원과 공유할 수 있게 해달라고 하더라고요. 이것도 그냥 URL 복사해주면 되는 건데 말입니다. 물론 UI의 편의성이라든지 하는 문제는 있겠지만 어쨋든 사람들이 시스템에 갇히는 모습 중 하나인 것 같아요. 이런 점을 극복하고 다른 소프트웨어나 다른 도구, 방법과 잘 조화시켜 사용하면 훨씬 편하게 이슈 트래커를 쓸 수 있어요. 그리고 위에서 살펴본 문제들, 잘 보면 알겠지만 대부분 의사 소통 문제입니다. 이슈 트래커 자체가 의사 소통 도구인데 이걸 이슈 목록 관리로만 보면 의사 소통 문제들이 생기는 것 같아요. 시스템이 의사 소통을 도와줄 수는 있어도 대신해줄 수는 없습니다. 어떤 시스템이든 그걸 사용하면서 의사 소통에 장애가 생기기 시작한다면 사용 방법을 바꿔보는 것이 좋아요. 저도 이런 문제를 많이 겪었어요. 모든 작업 흐름(workflow)의 시스템화를 외치는 팀장 때문에 전부 그룹웨어에 통합해 써보기도 했고 또 일마다 그 성격에 맞는 도구를 써야 한다며 대여섯 개의 도구가 난립하기도 했죠. 이슈 트래커를 쓰면서 의사 소통 단절이 생기니까 다른 걸로 바꿔보자면서 계속 새로운 도구만 찾아다기도 했고요. 하지만 대개 문제는 시스템 자체보다 그 시스템을 어떻게 사용하느냐에 있었어요. 시스템을 지혜롭게 사용하는 방법을 배우면서 시스템 자체의 문제까지 극복하기도 했구요. 더 좋은 이슈 트래커를 찾기 위해 소스포지를 뒤지고 개발해 보고 하는 것도 좋지만 오늘은 이슈 트래커를 잘 사용하는 방법에 대해 팀원들끼리 이야기를 해보는 것이 어떨까요?

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

기존 오픈소스 이슈 트래커를 써보고 또 직접 개발한 이슈 트래커를 다른 사람에게 써보게 하기도 했는데 그러면서 사람들이 이슈 트래커라는 시스템에 갇히기 쉬운 것 같다고 느꼈습니다. 무슨 일이든 자꾸 이슈 트래커 안에서 해결하려고 하죠. 그러다 보면 위에서 살펴본 것처럼 여러 가지 부작용이 생겨요. 가서 그냥 말 한 마디 하면 해결될 일인데 시스템에다 올려놓고 왜 안 해주냐고 투덜거리죠.
기능적으로도 그래요. 다른 소프트웨어와 조금만 조합하면 쉽게 풀 수 있는 문제를 전부 이슈 트래커의 기능으로 커버해야 한다고 생각할 때가 많아요. 저 역시 그런 함정에 빠지곤 합니다. ECUS에는 검색 조건 저장 기능이 있습니다. 그런데 사실 알고 보면 검색 조건이 URL에 반영되기 때문에 즐겨찾기만 해놔도 해결할 수 있는 문제였어요. 그런데 거기까지 생각하지 못하고 기능으로 넣어버린 거죠. 그랬더니 그렇게 저장한 검색 조건을 다른 팀원과 공유할 수 있게 해달라고 하더라고요. 이것도 그냥 URL 복사해주면 되는 건데 말입니다.
물론 UI의 편의성이라든지 하는 문제는 있겠지만 어쨋든 사람들이 시스템에 갇히는 모습 중 하나인 것 같아요. 이런 점을 극복하고 다른 소프트웨어나 다른 도구, 방법과 잘 조화시켜 사용하면 훨씬 편하게 이슈 트래커를 쓸 수 있어요.
그리고 위에서 살펴본 문제들, 잘 보면 알겠지만 대부분 의사 소통 문제입니다. 이슈 트래커 자체가 의사 소통 도구인데 이걸 이슈 목록 관리로만 보면 의사 소통 문제들이 생기는 것 같아요. 시스템이 의사 소통을 도와줄 수는 있어도 대신해줄 수는 없습니다. 어떤 시스템이든 그걸 사용하면서 의사 소통에 장애가 생기기 시작한다면 사용 방법을 바꿔보는 것이 좋아요.
저도 이런 문제를 많이 겪었어요. 모든 작업 흐름(workflow)의 시스템화를 외치는 팀장 때문에 전부 그룹웨어에 통합해 써보기도 했고 또 일마다 그 성격에 맞는 도구를 써야 한다며 대여섯 개의 도구가 난립하기도 했죠. 이슈 트래커를 쓰면서 의사 소통 단절이 생기니까 다른 걸로 바꿔보자면서 계속 새로운 도구만 찾아다기도 했고요. 하지만 대개 문제는 시스템 자체보다 그 시스템을 어떻게 사용하느냐에 있었어요. 시스템을 지혜롭게 사용하는 방법을 배우면서 시스템 자체의 문제까지 극복하기도 했구요. 더 좋은 이슈 트래커를 찾기 위해 소스포지를 뒤지고 개발해 보고 하는 것도 좋지만 오늘은 이슈 트래커를 잘 사용하는 방법에 대해 팀원들끼리 이야기를 해보는 것이 어떨까요?

[지난 Special Issue 보기]