Issue tracker

살아가다가 issue tracker를 써 본 것은 작은 조직에서 (대기업인데 조직과 인력이 빠듯한) 써봤던 기억이 있다. 써봤다기 보단 쓰임 당했다고 봐야 할 것 같다.

이걸 쓰는 이유는 워낙에 문제는 많이 터지는데 그 양이 기억을 할 수 없을 정도로 많을 때 쓴다. 흔히 회의만 들락거리다 기운 다 빠지던 (옛날의) 부장이나 과장이 하는 일을 실무자들이 직접하는 것이다. 상위의 관리자들은 사실 있어봐야 실무자 불러다가 ‘이거 언제 해결할 거냐’ 아니면 resource planning만 하게 되겠지만 그 입장에서도 이슈가 미친 듯이 터지면 통제불능 상태가 되기 때문에 상황을 봐서 직접 유니폼 갈아입고 경기를 뛰어야 할 지 말지 결정해야 한다. 아니면 내내 불러다 조인트나 까던가.

당시 기억은 bigzilla 에서 썼던 기억인데, 지금은 이 아이는 거의 추억의 이슈트래커가 된 것 같고 jira를 많이 사용하는지 jira에 대한 이야기만 많이 나오고 뭐랄까 좀 클래식한 룩을 가지고 있는 redmine이나 trac을 쓰라고 권하는 사람들이 좀 보인다.

개인적인 경험으로는 jira는 이것 저것 달라붙은 게 많고 내부적으로 transaction이 많이 일어나는지 제법 느리고 redmine이나 trac은 다소 빠르긴 한데, 의미를 파악하기 어려운 설정사항이 너무도 많다. jira는 유료인데다 기능을 플러그인 형태로 확장하게 해놓고 건당 과금이 되는 거라 별로 사용하고 싶은 생각이 들지 않는다. 물론 느린 걸 고려해서 호스팅까지 해주는 것으로 해서 별도의 과금 항목이 설정되어있긴하다.

소규모 그룹 프로젝트에서 간단하고 빠르고 그러면서도 git과 같은 것과 연동이 잘되도록 되어있는 issue tracker가 잘 안보인다.

오늘은 gitea를 한번 써볼까한다.