redmine 은 사용성만 아니라 플러그인 만드는 등의 확장성이 뛰어나서 자유도가 상당히 높은 도구지만, 버젼 업그레이드 하면
서 작동 안하는 플러그인들이 있어 반대로 확장이 위험한 도구이기도 하다는 결론입니다.
제가 만든 플러그인이면 직접 수정이 가능하지만, 많이 사용하는 공개된 플러그인들도 은근히 레드마인의 버젼 갱신에 영향을 받는 경
우가 있어서 문제가 되는 경우가 생기더군요. 그러면서도 버젼 갱신을 안할 수가 없는 경우가 발생하는 게, 아직도 redmine
에는 자잘한 버그들이 있고 꽤 빨리 업그레이드 되면서 수정되고 있거든요. pdf export 시 발생하던 charset 문제도
리포팅된지 한참 되었는데 작년 중반에서야 고쳐졌는데, 그런 필요한 갱신 때문에 새 버젼을 적용하긴 해야겠지만 그때마다 영향받을
플러그인들이 걱정됩니다. 이부분은 jira 나 다른 도구들도 마찬가지일 것 같긴 합니다만, 직접 뛰어드는 개발자가 많지 않고서
는 어쩔 수 없는 부분이죠. 직접 뛰어들고 싶어도 제 ruby 실력에 한계가...
그런데 도구 자체의 자유도면에서는 상당히 뛰어나죠. 그전에 사용해본 mantis 나 trac 같은 도구에서 할 수 있는 것들 중
에 안되는 건 없는 것 같습니다. 요즘 jira 를 사용하면서 자꾸 비교를 하게 되는데, redmine 에서는 되는 게
jira 에서는 한계가 있는 것도 발견하게 되고, 물론 그 반대 경우도 봅니다.
예를 들어 redmine 에서 issue 아래 sub-issue 를 생성하는 기능이 있습니다. 저는 이 기능을 무척 유용하게 사
용했는데, 좀 큰 단위의 스토리에 대한 issue 를 만들어놓고 그 issue 를 해결하기 위한 sub-issue 들을 진행하면
서 추가하는 거죠. 그리고 그 sub-issue 들 아래에 또 sub-issue 를 넣을 수도 있고 (실제로 그렇게까지 내려가
는 경우는 별로 없지만) 그렇게 하면서 일의 정의가 점점 더 세분화 되어가면서 구체화시킬 수 있게 됩니다. 일이 세분화되면서 진
행정도를 파악하는 것도 redmine 의 장점이죠. 그렇게 하지 않을 경우 대충 개발자가 감으로 50% 진행됐다는 말에 의존해
야 하지만, redmine 의 issue 세분화 기능은 작은 단위로 쪼개고 서로의 의존성을 상세히 넣을 수 있기 때문에 어제까지
는 50% 였던 일이 오늘은 30% 가 되었다면 그건 스토리를 구현하기 위해 새로운 issue 가 추가되었기 때문이란 걸 분명
히 보여줍니다. 개발자의 감에 의존했다면 PM 은 50%가 30%로 후퇴된 것에 대해 너그러운척 하면서도 이해를 못하고 개발자
역시 애초에 감으로 진작했던 수치기 때문에 말하기 꺼려지는 부분이어서 risk 가 증가하죠. 명확하게 드러낼 수 있는 도구가 있
다는 건 이런 경우에 효용성이 있다고 봅니다.
반면 jira 는 오직 한 단계의 sub-task(issue) 만을 만들 수 있고, 그 sub-task 의 issue-type
에 "bug", "new feature" 등, 상위 task 에서 사용하는 issue type 을 사용할 수가 없어요. 별도로
만들어야 하는 귀찮음이 발생하죠. 위에서 이야기한 redmine 의 sub-issue 분기가 갖는 장점이 jira 에선 하나도
없습니다. 반면에 별별게 다 구현되어있다 싶은 것이, A 프로젝트의 a type 이슈를 B 프로젝트로 옮길 경우, B 프로젝트
에 a type 이 없을 경우 move 마법사(?)가 친절하게 a type 을 B 프로젝트의 어떤 issue-type 으로
migration 할 건지를 물어봐줍니다. 나아가서 issue-type scheme 을 만들어 이미 진행중인 특정 프로젝트에 적
용할 때도, 기존에 있던 issue-type 이 새로 생성된 issue-type scheme 에 없는 경우의 migration
도 마법사로 해결해주네요. 있으면 좋은 기능이지만 없어도 그다지 자주 이용하는 게 아니므로...
같은 팀에 jira 의 장점을 여러 프로젝트의 issue 들을 한꺼번에 볼 수 있는 dashboard 에 있다고 말한 사람이 있
었는데요, redmine 역시 sub-project 로 설정하면 하위 프로젝트들을 상위 프로젝트에서 볼 수 있게 되죠. 다시 말
해 redmine 의 자유도를 장점으로 보는 또다른 예시입니다.
atlassian 도구를 풀셋으로 샀기 때문에 당연히 생선눈깔이나 군중인증 같은 것도 함께 사용하게 되었고,
confluence 도 쓰고 있는데 이게 또 물건이더군요. 그러나 confluence 자체만 놓고 보면 그렇지만 jira 와 연
동하는 걸 보면 또다시 redmine 이 참 좋은 도구라는 걸 느끼게 됩니다. confluence 의 강력한 WYSWYG 편집기
는 redmine 이 못 따라오는 부분이지만, redmine 은 각종 docs, project, issue, files,
revision 등등을 wiki 를 사용하는 모든 데이터(issue, comment, wiki docs itself) 안에서 참
조로 넣을 수가 있습니다. 그런데 jira 는 단지 URL 을 첨부하는 식으로 confluence page link 가 지원될
문이어서 그마저도 단 한개밖에 넣을 수가 없어요. (jira linker plugin 의 confluence page 검색 기능
은 redmine 보다 편리하더군요.) 그래서 여러개 산출물을 링크하기 위해서는 confluence 에 issue 와 1:1 매
칭되는 page 를 생성하고 그 page 에 child page 를 만들어줘야합니다. 그렇게 쓸 수는 있지만 역시
redmine 에 비해 자유도가 떨어지는 부분이죠.
올해 프로젝트에선 jira 를 쓸 수밖에 없어서 앞으로 많은 장점들도 찾게 되고 반면 redmine 에 비해 못한 부분도 계속
발견하게 될 것 같네요. 오픈소스 프로젝트들이 jira 를 많이 사용하는 추세라 어쩌면 redmine 이 점점 힘을 잃어가게 되
잖을까 싶은 느낌이 있는데, 10명 이상이 되면 가격적으로 부담스러워지는 atlassian 도구들을 고민하느니 redmine
을 사용하는 회사들이 많아졌으면 좋겠네요.