팀 내 커뮤니케이션을 할 때, 이슈 Issue 와 태스크 Task 를 혼용해서 쓰는 경우가 많다. 두 가지 모두가 가리키는 지점이 비슷하다 보니, 아무래도 “어떻게 이야기 하든 찰떡같이 알아들으면 그만”이라는 생각이 있었는데, 그래도 정확하게 구분하는 무언가가 있지 않을까 싶어서 찾아보기 시작했다. 하지만…
길다면 길고, 짧다면 짧은 소프트웨어 엔지니어링 분야에서 이슈와 태스크는 다른 조직, 기업, 심지어 방법론이나 프로젝트 매니지먼트 시스템 PMS: Project Management System 에서도 약간씩 다르게 쓰이고 있는게 보이더라. 하하, 그래 이런 난장판일 줄 알았지.
어쨌든 나름대로 정리한 바는 아래와 같다.
이슈 Issue
이슈의 사전적 의미는 “주제, 쟁점, 사안, 문제” 등의 여러 의미가 있다. 이슈 트레킹 시스템 Issue Tracking System 이라는 어플리케이션 그룹에서는 대부분 이슈를 업무를 위한 하나의 단위로 보고 있다 – 이 때문에 태스크와 같은 것 아닌가? 라는 혼란을 준다.
대중적인(?) 프로젝트 관리 시스템 중 하나인 지라 Jira 의 경우, 이슈를 업무 Task, 결함 보고, 논의 필요한 쟁점 사항 등을 묶어서 프로젝트 진행 중 발생하는 모든 분류의 이야기들을 이슈로 표현하고 있다. 개인적으로도 이쪽이 좀 더 사전적 의미와 맞기도 하고, 프로젝트 관리에 있어서도 이해되기 쉬운 개념이 아닐까 한다.
태스크 Task
“어차피 모든 이슈는 처리해야 할 업무 아닌가?” 라는 점에 있어서 태스크 = 이슈 라는 가정이 성립 할 수 있으나, 위의 이슈 항목에서 먼저 서술했다시피, 태스크 ⊆ 이슈 가 옳을 것이다.
다만, 그럼에도 불구하고 혼란을 가져올 여지가 많기 때문에 태스크에 대해 좀 더 구체적으로 정의를 내릴 필요가 있을 것인데, 일단 “구체적인 업무 계획 및 일정을 가지고 진행하는 일”를 의미하면 되지 않을까 싶다. 이슈는 의사 결정이 필요한 태스크를 실행하기 전 단계의 작업 진행 단계를 의미한다면, 태스크는 이슈가 논의 등을 통해 의사 결정 된 내용을 바탕으로, 실제 진행해야 하는 업무를 가리킨다고 할 수 있지 않을까?
버그를 보고하고 이를 디버그 하는 일은?
작성된 버그 리포트는 분명 이슈일 것이다. 이 리포트를 가지고 업무 계획을 수립하게 된다면 이 버그 리포트는 이슈이자 태스크로 전환이 될 것이다. 태스크가 마무리 된다면, 수행 된 결과물에 대한 테스트나 평가가 이뤄질 것이고, 이 때 다시 이는 이슈로 전환되어 트래킹 될 것이다 – 사실 지나치게 논리적인 단계로 업무의 진행을 쪼개 놓은 것 뿐 실제로는 큰 구분 없이 진행이 될테지만.
잠시만, 그럼 다시 원점으로 돌아와서 태스크 = 이슈 라는 것도 성립되는 것 아닐까? 하지만, 이슈는 실제로 진행되지 않는다면(중복 보고되었거나, 마일스톤에서 제외 된다던가 하는 식으로) – 즉, 태스크로서 실제 업무가 진행되지 않는다면 결국 이슈 상태에서 끝나는 것이 맞을테니 여전히 태스크 ⊆ 이슈 는 유효하다.
이 모든 이야기는, 그저 의견일 뿐 정답이 아닐 수 있다(실제로 어떤 방법론에서는 태스크와 이슈를 위 내용과 정확히 뒤집어서 구분하는 것도 있으니).