이슈 트래커 개발자가 들려주는 이슈 트래커 이야기, Part 1: 무엇을 어떻게 골라쓸까

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

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

필자는 최근 회사에서 이슈 트래커를 개발하는 일을 맡았습니다. 그 전에는 맨티스(Mantis)라는 오픈 소스 이슈 트래커를 사용했는데 여러 가지로 만족스럽지 않아 개선 방안을 찾다가 그냥 새로 만들어 보기로 한 것이죠. 물론 기존에 이미 나와 있는 다른 이슈 트래커들도 고려해 봤어요. 오픈 소스 이슈 트래커 중 가장 유명한 버그질라(Bugzilla)를 비롯해 상용 제품 중 가장 널리 쓰이는 Jira, 요즘 프로그래머들 사이에서 인기를 끄는 트랙(trac)까지 대략 10여 종의 이슈 트래커를 평가해 보았는데 어느 것도 팀의 요구를 만족시킬 수 없었어요.

기능이 부족해 그런 것이 아니었습니다. 사실 그 반대였죠. 이런 소프트웨어들은 기능이 너무나 막강해 사용하기 어렵더라고요. 필자가 속한 팀에 필요한 것은 단지 사용자들이 버그를 쉽게 등록하고 그것들을 개발자들이 쉽게 조회하는 것뿐이었거든요. 그래서 기능 측면보다 사용성에 최우선을 두고 새로 만들어 보기로 하고 프로젝트 이름도 ECUS(Engineer and Customer's Understanding and Satifaction)라고 지었어요. 기존 이슈 트래커가 엔지니어에게만 초점을 맞추고 있었다면 이제 고객(customer)에게도 초점을 맞추자는 의도를 나타낸 것이죠.

이 연재에서는 이런 경험에 비추어 여러 이슈 트래커를 살펴보겠습니다. 비교해볼 대상은 트랙, 맨티스, 버그질라 세 가지로 가장 널리 쓰이고 높은 평가를 받는 것들입니다. 단, 단편적인 비교 분석은 지양하고 이슈 트래커 개발 과정에서 필자가 고민했던 문제들을 다른 이슈 트래커들은 어떻게 풀어냈는지, 그리고 ECUS 프로젝트에서는 어떤 대안을 제시하는지에 초점을 맞춰볼 거에요. 물론 ECUS 프로젝트가 리뷰에 포함되기 때문에 필자가 균형 감각을 잃을 위험이 있지만 이슈 트래커에 대한 고민을 보여주려면 결국 ECUS 팀에서 선택한 대안도 보여주는 것이 더 효과적일 것이라 생각합니다.

이슈 트래커는 그 자체의 기능적 특성들을 이해하는 것도 중요하지만 이슈 트래커를 어떻게 사용할 것인지에 대한 문제를 이해하는 것도 중요해요. 프로젝트에서 어떤 역할을 담당하게 할 것인지, 다른 프로젝트 관리 도구들과는 어떻게 조화시킬 것인지, 팀내 커뮤니케이션은 어떻게 할 것인지 등이 제대로 정립되지 않으면 때때로 이슈 트래커가 부정적인 영향을 미치기도 하거든요. 그래서 다음 회에는 이런 부분에 대한 고민을 다뤄보겠습니다.

위로

사용자 모델링과 권한 체계

ECUS 개발에는 XP(eXtreme Programming) 방법론을 적용했어요. XP에서는 보통 사용자 스토리(user story)를 뽑아내는 것으로 시작하는데 그 첫 단계가 사용자 모델링이죠. ECUS 팀에서는 사용자 모델링에서 세 가지 역할을 찾아냈습니다. 먼저 버그나 제안을 등록하는 역할을 일반 사용자로, 버그를 읽고 담당자에게 전달하며 보고한 사람에게 피드백하는 사람을 관리자로 정했어요. 마지막은 실제 이슈를 처리하는 개발자고요. 이렇게 사용자 역할을 나누니 사용자 스토리도 비교적 쉽게 나오더군요.

그런데 사용자 스토리를 이리저리 분류하다 보니 관리자와 개발자를 분리하는 것이 의미가 없겠다는 생각이 들었습니다. 이전에 몇몇 프로젝트에서 나타난 현상인데 이슈 관리자를 별도로 두면 개발자들은 이슈가 올라와도 읽지 않고 관리자가 계속 재촉하거나 할당해야만 읽더라고요. 그러다 보면 개발자는 점점 사용자의 목소리에서 멀어졌고요. 물론 개발에 전념한다는 핑계를 대긴 하지만 필자가 일하는 회사처럼 웹 서비스를 하는 회사에서는 개발자도 고객의 요구를 민감하게 느껴야 한다고 생각해요. 게다가 관리자 역할을 따로 배정하면 그 사람은 어떻게 보면 계속 잡무만 하는 셈이죠. 팀에서 잡일꾼으로 취급 받는 사람이 버그 보고에 즐겁게 응대하기는 어렵겠죠? 그래서 결국 사용자의 역할을 두 가지로 압축했습니다. 관리자 역할은 개발자의 역할도 포함한다고 보고 일반 사용자와 관리자 두 가지로 나눈 것이죠.

사용자의 역할을 두 가지로만 분류하니 권한 모델도 단순해졌습니다. 그래서 관리자는 모든 권한을 다 가질 수 있게 됐죠. 그런데 실제 적용 중에 문제가 생겼어요. 외부 업체와 협업을 하다 보니 외부 업체 사람들이 협업하는 프로젝트의 이슈를 관리할 수 있어야 하는데 그 사람이 우리의 다른 프로젝트까지 보면 안 되는 상황이 생긴 것입니다. 그래서 사이에 한 단계를 더 놓기로 하고 관리자(Adminitrator)의 권한을 한 프로젝트에 대해서만 가질 수 있는 서비스 운영자(Service Manager)를 두었고 이것이 ECUS의 권한 체계로 확립됐습니다.

맨티스는 ‘권한을 볼 수만 있음’, ‘보고 가능’, ‘갱신 가능’, ‘개발자’, ‘매니저’, ‘관리자’ 여섯 가지로 구분합니다. 그리고 프로젝트별로 다른 권한을 줄 수 있죠. 프로젝트 A는 볼 수만 있는데 프로젝트 B는 매니저 권한을 가진다든가 하는 게 가능해요. 그래서 좀 더 세밀하게 조정할 수 있지요(그런데 예전에 맨티스를 쓸 때 보니 그냥 팀원 전부를 다 관리자로 놓고 쓰게 되더군요).

버그질라는 권한 모델이 좀 더 체계적입니다. 사용자를 모아 그룹으로 설정하고 그룹별로 권한을 줄 수 있어요. 사실 이건 ECUS에서 아쉬운 점이기도 합니다. 가끔 사용자 여러 명에게 권한을 줘야 하는 일이 생기잖아요. 버그질라에서는 해당 사용자를 이미 만들어진 그룹에 넣기만 하면 다 똑같은 권한을 줄 수 있는데 ECUS에서는 하나하나 바꿔줘야 하거든요. 그리고 버그질라에서는 권한도 상당히 세분화되어 있어서 이슈를 만드는 권한, 편집하는 권한, 프로젝트를 만드는 권한 등 거의 모든 기능 단위별로 권한을 조정할 수 있어요. 트랙도 비슷하구요. 그래서 버그질라나 트랙을 쓰면 원하는 대로 다 설정할 수 있습니다. 물론 그만큼 어렵지만요.

사실 ECUS처럼 권한 모델을 단순화할 수 있는 것은 아직 필자가 일하는 조직이 100명도 안 되는 작은 조직이기 때문일 겁니다. 조직이 좀 더 커지고 복잡해지면 그만큼 복잡한 권한 체계가 필요해지고 트랙이나 버그질라의 그룹 기반 권한 체계가 부러워질지도 모릅니다. 하지만 아직은 YAGNI(You aren't gonna need it!)!라고 결론을 내려버려도 될 것 같군요.

위로

이슈 등록

이슈 트래커에서 가장 중요한 과정은 아무래도 이슈를 등록하는 과정이라 할 수 있습니다. ECUS 팀에서 다른 이슈 트래커를 포기했던 이유이기도 해요. 먼저 버그질라의 버그 등록 화면을 보세요(그림 1). 뭔가 어지럽죠. 필자도 버그질라에서 버그 보고를 하려다 이 화면을 보고 당황해 포기했던 적이 있습니다. 사실 저렇게 많은 항목이 모두 필수는 아니고 제목과 내용만 필수요소죠. 하지만 UI가 그런 느낌을 주지 않기 때문에 지레 겁먹고 버그 보고를 포기하는, 필자처럼 소심한 사용자가 많은 것 같습니다.

맨티스는 일단 한국어 번역이 있으니 좀 나은 것 같긴 한데 여전히 좀 복잡합니다(그림 2). 트랙은 이보다는 훨씬 쉽고요. 다른 이슈 트래커와는 달리 이슈가 아니라 티켓(ticket)이라는 용어를 사용한다는 점이 조금 걸리긴 한데 복잡한 속성들을 밑으로 끌어내려 놓아 꼭 입력하지 않아도 된다는 느낌을 주고 위지윅 편집기도 붙어 있어 좀 더 쉽게 쓸 수 있는 것 같습니다(그림 3).

ECUS는 이보다 조금 더 단순하게 만들었어요. 사용자가 그냥 게시판에 글 쓰는 기분으로 쓸 수 있도록 제목과 내용, 첨부 이외의 항목들은 모두 뺐고 관리자가 상태나 우선순위 같은 걸 설정하고 싶을 때도 글 쓸 때부터 하는 게 아니라 글 쓰고 나서 하도록 만들었습니다(그림 4). 그래서 사용자들이 좀 더 편하게 글을 쓰는 것 같습니다(하지만 팀내 개발자들은 글 쓰면서 바로 우선순위 같은 항목을 지정하고 싶다고 불평을 하고 있긴 해요).

위로

이슈 찾기

맨티스나 버그질라를 쓰면서 제일 어려웠던 점이 바로 이슈를 찾는 것이었습니다. "어, 그 때 그 이슈 어디 갔더라"부터 "현재 검토하지 않은 이슈들을 찾고 싶어"라든지, "작업 중인 것들을 우선순위대로 보고 싶어"처럼 다양한 조건으로 이슈를 찾아야 하는 경우가 생기거든요. 그래서 이슈를 쉽게 찾는 것도 중요하지만 조금 어렵더라도 원하는 작업을 할 수 있는 게 중요합니다.

먼저 맨티스를 보죠(그림 5). 단순 필터 화면인데 사실 고급 필터를 눌러도 항목은 똑같습니다. 다만 각 항목에서 선택의 자유도가 좀 더 높아집니다. 예를 들면 상태의 경우 단순 필터에서는 새로운 이슈만 본다거나, 해결된 이슈는 제외한다거나 하는 건 가능하지만 폐쇄된 이슈와 검토 중인 이슈만 본다거나 하는 복잡한 조합은 불가능한데 고급 필터에서는 이것이 가능해요. 항목이 너무 많다보니 어지러운 감이 있는데 실제로 사용하는 항목은 얼마 되지 않고 이슈 상태, 우선순위, 할당 정도죠. 가끔 날짜로도 검색하고요. 다행히 맨티스에는 선택한 검색조건을 저장하는 기능이 있어 필터 저장 버튼을 누르면 현재 검색조건이 저장됩니다.

ECUS도 맨티스의 필터를 출발점으로 삼았습니다. 단순 필터와 고급 필터가 항목은 같고 인터페이스만 다른데 자바스크립트를 잘 활용하면 하나로 잘 합칠 수 있을 것 같더군요. 그리고 실제로 쓰지 않는 항목들은 모두 과감하게 제거하기로 하고 그림 6과 같은 인터페이스를 만들었습니다. 검색조건은 필요 없는 경우는 접어둘 수도 있고요. 맨티스의 필터 저장 기능도 그대로 가져왔고 덧붙여 기본적으로 많이 쓸 것 같은 조건을 바로가기로 만들었습니다. 내가 쓴 글이나 나에게 할당된 글 같은 경우는 따로 검색조건을 열 필요 없이 바로 찾을 수 있죠. 이 기능은 일반 사용자 입장에서도 필요한 기능이에요. 사용자는 자기가 올렸던 글이 어떻게 처리되고 있는지를 보고 싶어하거든요.

버그질라는 단순 검색과 고급 검색이 완전히 분리되어 있습니다. 단순 검색에서는 상태와 제품, 검색어만으로 검색하지만 고급 검색은 아래 그림처럼 모든 필드를 다 검색할 수 있죠. 검색하면 다음과 같은 화면이 나옵니다. 나름대로 두 가지 요구를 모두 만족시킬 수 있는 실용적인 대안이죠.

하지만 한 가지 단점은 검색된 결과를 보는 화면과 검색조건을 입력하는 화면이 분리되어 있어 검색 결과가 맘에 들지 않을 땐 다시 뒤로 돌아가 검색해야 한다는 것입니다. 페이징이 안 되어 검색된 이슈가 많을 경우에는 속도가 엄청나게 느리다는 것도 문제구요. 이 점 때문에 예전에 맨티스와 버그질라를 비교하다 맨티스를 선택했던 거에요.

트랙은 좀 색다른 접근 방식을 취하고 있습니다. 앞서 언급했듯 트랙에서는 이슈를 티켓이라 부르는데 View Ticket 화면을 처음 누르면 ECUS의 바로가기 같은 것들이 뜨고요. 이미 정의된 많은 조건이 링크로 저장되어 있어 누르면 바로 볼 수 있어요.

이 바로가기 조건이 맘에 들지 않으면 Custom Query를 눌러 조건을 직접 지정할 수 있습니다. 검색조건의 오른족 아래에서 add filter 버튼을 누르면 검색조건을 추가할 수 있지요. 제목이나 내용으로 검색할 수도 있고 담당자라든지 티켓의 모든 필드를 검색조건에 넣을 수 있고요. 트랙의 방식도 나름대로 단순 검색과 고급 검색의 필요성을 꽤 실용적으로 만족시켰다고 할 수 있지만 버그질라와 마찬가지로 검색과 관련된 화면이 세 가지라는 점은 다소 걸림돌이 되기도 합니다.

위로

이슈 처리 과정

이슈를 등록하고 찾았으면 이제 해당 이슈에 대한 작업을 해야 하죠. 이슈를 읽고 답글을 달거나, 상태를 변경하고 우선순위를 변경하는 등 다양한 작업이 있어요. 일단 이 중에 제일 중요한 상태 변경 작업만 살펴보겠습니다. 맨티스는 이슈를 보는 화면과 수정하는 화면이 그림 8과 같이 분리되어 있는데 이슈를 보는 화면에서는 이슈에 대한 상세한 내용은 수정할 수 없지만 대신 할당이라든지 상태 변경 같은 작업은 할 수 있습니다. 그래서 실제로 등록된 이슈의 내용을 수정하는 경우가 아니면 이슈 수정화면은 거의 열 필요가 없어요. 하지만 변경 작업을 할 때 코멘트를 입력하는 화면으로 넘어가기 때문에 실질적으로 작업이 한 화면에서 일어나진 않죠. 버그질라도 맨티스와 비슷하구요(그림 9).

트랙은 특이하게 이슈 보기와 수정이 한 화면에 붙어 있습니다. 기능적으로 합쳐진 게 아니라 말 그대로 그냥 붙어 있죠(그림 10). 그래서 그냥 볼 때는 별 불편함이 없지만 상태 변경 같은 걸 할 때는 웬지 고치면 안 되는 항목도 같이 고쳐버리는 실수를 할까봐 불안한 느낌이 들더군요. 한 화면으로 모은 점이 장점일 수도 있긴 하지만 맨티스보다 더 어려운 느낌이 듭니다.

ECUS는 맨티스와 비슷합니다. 상태 변경이나 우선순위 변경 등 메타 정보 변경은 보기 화면에서 하고 본문을 수정할 때는 수정 화면으로 가죠. 각종 변경 작업을 할 때는 Ajax를 써서 다른 화면으로 넘어가지 않도록 했어요. 그래서 맨티스보다는 조금 더 편해진 면도 있지만 여전히 항목들이 아래 위로 퍼져 있어서 어지러운 감이 있는 점이 아쉽습니다.

위로

중복된 이슈 다루기

이슈 트래커에서 또 하나 골치아픈 문제가 바로 중복된 이슈입니다. 이슈를 등록하는 사람은 대개 프로젝트팀 외부에 있는 경우가 많다 보니 현재 어떤 이슈가 올라와 있는지에는 관심이 없거든요. 그러니 같은 이슈라도 계속 등록해요. 따라서 이런 문제를 효과적으로 처리할 수 있는 장치가 필요하고요. 이 문제에 대한 처리 방식은 맨티스나 버그질라, 트랙이 모두 비슷합니다. 이슈를 중복된 이슈로 설정하고 같은 내용을 담은 원래 이슈 번호를 기록하게 하는 거죠. 그리고 그 이슈는 닫고 원래 이슈만 계속 다루고요.

그런데 ECUS는 일반 사용자도 써야 하는 시스템이라서 이렇게 할 수 없었습니다. 일반 사용자가 불만사항을 담은 글을 올렸는데 같은 문제를 다른 사람이 올렸다고 해서 새로 올린 사람한테 다른 글에 가서 보라고 하면 불친절하다고 느끼므로 개별적으로 답을 해야 합니다. 또 완전히 중복된 건 아니라고 해도 약간씩 연관된 이슈가 올라오는 경우도 있는데 이런 경우는 버그질라 방식으로 처리할 수 없죠. 그래서 글을 서로 연관 짓는 기능을 만들었습니다. 그림 12에서 연관글 버튼을 누르면 작은 창이 뜨는데 거기서 비슷한 이슈를 찾아 연관글로 지정하는 것입니다. 그럼 두 이슈가 서로 연관되어 어느 쪽 글에서 보든 다른 글이 연관글로 보이죠. 이렇게 연관글 창에서 연관된 글들을 모아 하나하나 보면서 상태를 변경하거나 답글을 달 수 있습니다.

그러다가 아예 중복된 이슈가 적게 올라오게 만들면 더 좋지 않을까 하는 생각이 문득 들었어요. 글을 쓸 때 쓰는 내용과 비슷한 내용을 미리 검색해 화면 오른쪽에 보여주면 사용자가 같은 내용을 올리려다가 이미 있는 글에 가서 답글을 달거나 추천을 할 수 있겠죠. 그러면 사용자는 글을 쓰는 수고는 적게 하면서 자신의 의사를 전달할 수 있고 관리자는 더 적은 이슈를 관리해도 되므로 편해질 것이고요.

위로

로드맵

이슈 트래커는 원래 버그 트래커(Bug Tracker)에서 출발했습니다. 즉 소프트웨어 버그 목록을 관리하는 도구였던 것이죠. 그런데 사용하다 보니 꼭 버그라고는 부를 수 없지만 비슷하게 관리해야 하는 이슈들이 생겼고 그래서 아예 폭을 좀 넓혀 이슈 트래커라고 하고 기능을 약간 확장한 것입니다. 맨티스나 버그질라도 처음엔 버그 트래커라고 불렀지만 이제는 이슈 트래커라 부릅니다. 트랙은 아예 처음부터 이슈 트래커를 지향하고 출발해 티켓이라는 용어까지 정착시켰고요. 이렇게 범위를 확장하다 보니 이슈 트래커가 프로젝트 관리 도구 비슷하게 되어갔습니다. 버그가 할 일(To do)의 일종인데 이걸 확장해 이슈라고 하니까 아예 할 일 목록(To do list)을 통째로 관리해도 되지 않겠느냐 하는 생각을 한 것이죠. 그래서 로드맵(roadmap)이라는 기능이 들어가게 됐습니다. 다음은 맨티스의 로드맵 기능입니다. 목표한 릴리스에 포함될 이슈들을 지정하면 릴리스 스케쥴링을 할 수 있어요.

트랙에도 이 기능이 잘 통합되어 있죠. 트랙은 처음부터 프로젝트 관리 기능을 다 담을 목적이었거든요.

하지만 애자일 방법론을 사용하는 팀에서 ECUS를 사용할 것이라 가정했기 때문에 로드맵 기능은 넣지 않았습니다. XP에서는 보통 프로젝트 관리나 할 일 관리로 소프트웨어 도구보다는 종이나 펜, 화이트보드 등 오프라인 도구를 더 많이 활용하니까요. 그래서 ECUS는 고객과의 커뮤니케이션에만 집중하도록 역할을 부여한 거죠. 팀이 지리적으로 분산된 경우라든가, 혼자 작업하는 경우라면 트랙 같은 시스템이 더 편리할 수 있을 겁니다.

위로

총평

지금까지 오픈 소스 이슈 트래커 세 가지를 리뷰해 보면서 ECUS와 비교해 봤습니다. 사실 이슈 트래킹 기능만으로는 세 가지 모두 별로 부족함이 없죠. 하지만 ECUS를 만들게 된 이유에서 알 수 있듯이 인터페이스, 사용성에 있어서는 개선할 여지가 많아요. 물론 일반 사용자를 고려하지 않고 개발팀 내부에서만 쓸 것이라면 괜찮을지도 모르지만.

하지만 필자는 일반 사용자에게 쉬운 것은 개발자에게도 쉬울 것이라고 생각합니다. 필자가 속한 팀에서 서비스를 오픈했을 때 고객 센터를 맨티스와 연동해 만들었었는데 연동 당시에는 일반 사용자들이 고객 센터에 와서 글을 올리고 개발자들은 맨티스에서 조회하고 처리하는 프로세스를 예상했어요. 하지만 이상하게도 개발자들이 맨티스를 보지 않고 이슈 처리 기능도 다 구현되지 않은 고객 센터에 가서 글을 보더군요. 왜 그런지 물어봤더니 고객 센터 쪽이 UI가 더 쉽고 디자인이 예뻐서 그렇다는 거에요. 결국 개발자도 사람인 이상 개발자에게 적합한 UI와 일반 사용자에게 적합한 UI가 따로 있는 것은 아니라는 이야기죠.

필자의 경험상으로 이슈 트래킹 기능만 놓고 본다면 맨티스가 가장 무리가 없는 것 같습니다. 버그질라의 인터페이스는 우리가 일상적으로 접하는 웹 애플리케이션과 너무 동떨어져 있죠. 기능적으로 막강하고 나름대로 실용성을 추구한 점이 많이 엿보이지만 개발자들조차도 어려워할 정도이니 기획자나 팀장, 디자이너 등 다른 직군과 협업하는 데 쓰기에는 무리가 많아요. 맨티스는 국내 IT 기업에서 비교적 많이 쓰이고 한글 번역도 꽤 잘 되어 있어서 다른 직군과 협업에도 그럭저럭 쓸 만하고요.

트랙은 요즘 한창 주가를 올리고 있는 소프트웨어죠. 처음부터 프로젝트 관리 용도에 초점을 맞췄기 때문에 서브버전(Subversion) 저장소의 소스와 통합할 수 있는 기능도 있고 위키와도 통합되어 있습니다. 서브버전 저장소에 소스를 커밋(commit)할 때 코멘트로 티켓 번호를 달면 자동으로 해당 티켓과 연결되기도 하고 이슈 내용에 위키의 링크를 포함시킬 수도 있기 때문에 종합적인 관리 도구로 사용할 만해요. 그래서 요즘 개발자들 사이에서 급속도로 퍼지고 있죠. 하지만 이 기능을 모두 연동해 사용하는 경우가 아니라면 다른 도구가 더 나은 것 같습니다. 위키 기능도 요즘 좋아지고는 있지만 미디어위키(MediaWiki)나 모인모인(MoinMoin) 같은 막강한 위키를 쓰다가 트랙을 쓰면 불편함을 많이 느끼거든요. 이슈 트래킹과 로드맵 기능은 완성도가 꽤 높지만 맨티스에 비하면 일목요연한 뷰가 좀 아쉽고 통계 기능도 좀 약하죠. 그리고 트랙을 쓸 경우 뭔가 프로젝트 관리 자체가 트랙에 종속되는 현상이 생기기도 하는데 이것도 팀에 따라 문제가 될 수 있어요.

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

그렇다면 무엇을 어떻게 선택하면 좋을까요? 조건에 따라 좀 다릅니다. 만약 개발팀 전원이 개발자이고 소스 저장소로 서브버전을 쓴다면 트랙이 제일 좋은 선택일 것이고, 개발자가 아닌 직군과 협업을 해야 한다면 맨티스가 더 나은 대안이 되겠죠. 그런데 만약 일반 사용자까지 포괄하고 싶다면? 현재로서는 세 가지 중 어떤 것도 대안이 될 수 없고 상용 소프트웨어를 고려해보는 것도 방법일 거에요. ECUS가 이미 오픈 소스가 되어 있다면 기쁜 마음으로 추천하겠지만 아직은 그럴 수 없어 안타깝군요.

직접 만들어 보는 것도 좋은 선택이 될 수 있습니다. 사실 팀마다 요구사항이 다 다르기 때문에 각 팀에서 필요한 기능만 구현한다면 그리 어려운 일이 아니에요. 게시판에 부가적인 항목이 몇 가지 더 붙는다고 생각하면 됩니다. 요즘 루비온레일스(Ruby on Rails)나 장고(Django)처럼 웹 애플리케이션을 뚝딱 만들어낼 수 있는 프레임워크가 많으니 며칠 걸리지 않을 거에요. ECUS 프로젝트도 개발한 지 오래되긴 했지만 핵심 기능을 완성하는 데는 2~3주 밖에 걸리지 않았습니다. 바퀴를 다시 발명하는(Reinvent the wheel) 것이 아니라 바퀴를 다시 설계하는(Redesign the wheel) 것이죠. 개발자는 때로는 자신에게 필요한 소프트웨어를 직접 만들 수도 있어야 합니다.

직접 만들지 않더라도 선택하기 전에 직접 설치해 사용해보는 경험은 필수입니다. 그냥 리뷰에서 보는 것과 직접 사용해보는 것은 느낌이 많이 다르거든요. 여기서 리뷰한 세 가지 외에도 살펴볼 만한 소프트웨어가 많습니다. 위키백과의 Comparison of issue tracking systems를 참조해 보세요.

[지난 Special Issue 보기]