벤처회사에서 일하다가, 솔루션을 파는 현재의 회사로 이직한지도 1년. 가장 신기했던건 복지포인트도, 산행도 아닌 이슈관리시스템(Issue Tracking System)이었다. 올해 스터디그룹에서 보았던 코드 크래프트(code craft) 라는 책에서도 이슈관리 시스템은 버그를 추적하고 좀더 나은 다음 버전의 소프트웨어를 만드는데 중요한 역할을 한다고 나와있다. 참고로, 필자가 사용하는 이슈관리 시스템은 Atlassian 사의 JIRA 를 사용하고 있다. 

약 1년간 JIRA를 이용하면서, 그리고 그 안에서 보고자(Reporter) 가 아닌 담당자(Assigner) 로 주로 활동을 하면서 느꼈던 바를 두서없이 적어 내려가려고 한다.

*1. 이슈 관리 시스템은 이슈만을 관리 해야한다. *

– 많은 분들이 가장 많이 착각을 하는 부분 중 하나가 이슈와 요구사항의 차이를 모르고 오로지 이슈관리 시스템을 통해서 요구사항을 전달하려고 한다는 점이다. 이슈와 요구사항은 분명히 다르다. 이슈는 배포된 소프트웨어에서 발견된 버그와 결함을 해결해야 하는 것이 이슈이고, 요구사항은 현재 배포된 소프트웨어에서는 지워하지 않는 기능인데, 고객이 원하는 기능이 바로 요구사항인 것이다.(이 부분은 IEEE의 정의를 찾아보길 바란다.) 요구사항은 분석단계를 거쳐서 완벽하게 현재의 소프트웨어에 녹아들수 있게 해야하기 때문에 반드시 협의를 거쳐야 한다고 생각한다. 그렇기 때문에 요구사항을 이슈관리 시스템에 올리는 것은 적당하지 않다. 

2. 우선순위의 오류

– 다른 회사에서 어떻게 사용하는지는 모르겠지만, 이슈를 주로 처리하는 팀이 있다. 필자가 있는 팀 역시 주로 시스템 안에서 담당자(Assigner)로 할당되는데, 팀원은 한정되어 있다는 것을 보고자(Reporter)가 인지하지 못하는 것 역시 문제이다. 쉽게 말하자면, 우선순위에서 빨리 처리를 받고자 very urgent 단계로 10명의 보고자들이 이슈를 올린다고 하자. 이슈를 처리하는 담당자가 2명이라면 어떻게 될까? 10개의 very urgent 이슈를 2명이서 처리 할 수 있는 방법은 순차처리(FIFO) 방식 밖엔 없다. (실제로는 약간의 시분할로 이루어지긴 한다.) 이렇게 되면 보고자(Reporter)들은 왜 내가 올린 이슈는 늦게 처리해주냐며 문제제기를 하기 시작한다. 실제로는 조금 더 일찍 올린 다른 보고자의 이슈를 처리하느라 해당 이슈가 처리가 안된것이다. 

때문에 이슈관리 시스템에서 우선순위 설정의 문제는 매우 민감한 부분이다. 실제로 회사에서 보고자들이 이슈의 우선순위의 명확한 기준을 가지고 있지 않다면, 이러한 문제가 발생된다. 기준은 단순히 프로젝트 종료일로 정하면 당연히 문제가 생기기 마련이기 때문에(프로젝트는 병렬로 진행되니까.) 이슈의 성격이나 프로젝트의 현재 진행상태 등을 파악해서 적절한 우선 순위를 정해야 한다. 

*
*

*
*

*3. 처리는 담당자가 아니라, 보고자가 하는것. *

– 담당자가 실질적인 코드 작업이나 버그추적을 하긴 하지만, 결국 이슈관리 시스템에서 ‘해결함’으로 바꾸는 작업은 보고자가 해야하는 일이다. 실제로 담당자 입장에서 일을 하다보면, 보고자는 “바로해야한다.”,”내일오픈이다.” 이런 말로 담당자를 협박아닌 협박을 하면서 쪼여 오지만, 그 시간내에 해주면 실제 피드백은 훨씬 더 늦게 오게 된다. 담당자는 해당이슈의 처리에 따라서 다른 어떤 이슈를 어떻게 진행할지 말지를 결정하게 된다. 그렇기 때문에 적용중이라던지, 언제 적용할건지 등의 일정을 언급해 주는 것이 중요하다. 필자가 최대 늦게 피드백을 받은 것은 한달 이상 피드백을 받지 못한 적이 있었다. 이런 경우 한달후에 문제가 있다고 연락을 받게 될 경우, 해당 이슈 뿐만아니라 진행하고 있던 이슈 자체에 대한 중지(suspend)가 이루어 지기 때문에 전체적인 이슈처리 효율이 떨어지게 된다. 

*
*

*4. 가능한한 많은 정보를 달라. *

– 환경에 대한 정보 뿐만 아니라, 데이터 및 설정정보에 대한 정보를 가능한한 많이 주는것이 이슈처리를 신속하게 할 수 있는 방안이다. 실제로 OS나 플랫폼에 대한 정보 뿐만 아니라,  gcc나 java 와 같은 프로그래밍 언어의 버전 그리고 가능하다면 프로젝트의 상황까지 올려주는 것이 좋다. 왜냐하면 JIRA 에서 댓글 하나에 대한 피드백을 받는것 자체가 다 시간을 쓰는 행위이기 때문에 보고자가 처음에 올릴때 대략적으로 어떤 정보들이 필요하겠다라고 생각하고 관련 정보들을 올려준다면, 훨씬 더 처리속도가 빨라질 수 있을 것이다. 사실 이런 부분은 해당 보고자의 프로젝트 경험에 많이 좌우된다고 볼 수 있다. 프로젝트 경험이 많은 필드 개발자분들은 가능한한 많은 정보를 담으려고 노력한다. 경험해 봤을때도 정보가 많은 경우가 훨씬 이슈처리가 빨리 이루어 진다. 

보고자(Reporter) 분들도 의견이 많겠지만 필자가 주로 담당자라서(Assigner) 담당자에 편향된 의견을 쓴 것에 대해서는 어쩔 수 없다.(가재는 게편, 나는 아이유편..) 여러가지 논쟁이 있을수 있겠지만 개인적인 바램은 좀더 ‘인간적인’ *이슈관리 시스템이 되었으면 하는 바램이다. 아침에 출근해서 퇴근할때까지 회사의 JIRA 화면만 F5 키를 누르면서 보고 있는 나를 돌아보면, 이슈관리 시스템은 이슈처리를 위한 공장자동화 같은 느낌이 들고, 나는 컨베이어 벨트앞에 이슈를 기다리고있는 노동자처럼 느껴지기까지 한다. *다른 회사에서는 어떻게 이슈관리시스템을 활용하고 프로세스가 어떻게 흘러가는지도 참고해 보는것도 좋을 것 같다.