이슈관리 시스템에 대한 고찰

벤처회사에서 일하다가, 솔루션을 파는 현재의 회사로 이직한지도 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 키를 누르면서 보고 있는 나를 돌아보면, 이슈관리 시스템은 이슈 처리를 위한 공장자동화 같은 느낌이 들고, 나는 컨베이어 벨트 앞에서 이슈를 기다리고 있는 노동자처럼 느껴지기까지 한다. 다른 회사에서는 어떻게 이슈관리 시스템을 활용하고 프로세스가 어떻게 흘러가는지도 참고해 보는 것도 좋을 것 같다.