소프트웨어 개발에서 이슈 트래킹 시스템은 한때 성배처럼 여겨졌다. 프로젝트가 복잡해질수록, 협업의 규모가 커질수록, 버그와 기능 요청을 체계적으로 관리하는 도구의 필요성은 절대적이었다. Jira, Bugzilla, Redmine 같은 도구들은 개발자의 일상을 지배했고, 그 과정에서 수많은 팀이 “이슈 기반 개발”이라는 종교에 가까운 신념을 갖게 되었다. 하지만 이제 그 신념에 금이 가고 있다. Linear의 선언처럼, 이슈 트래커는 죽어가고 있다. 아니, 어쩌면 이미 죽었을지도 모른다. 문제는 그 죽음이 과연 축복인지, 아니면 또 다른 혼란의 시작인지를 가늠하기 어렵다는 점이다.
이슈 트래킹 시스템의 근본적인 문제는 그것이 애초에 해결하려 했던 문제 자체를 왜곡했다는 데 있다. 개발자들은 버그를 고치고, 기능을 구현하고, 시스템을 개선하는 데 집중해야 하는데, 이슈 트래킹 도구는 그 과정에서 발생하는 모든 것을 “이슈”라는 단일한 프레임으로 강제한다. 버그는 이슈가 되고, 기능 요청은 이슈가 되고, 심지어 단순 질문이나 문서화 요청도 이슈가 된다. 이 과정에서 진짜 중요한 것은 무엇인가? 문제의 본질인가, 아니면 그 문제를 이슈로 포장한 후의 형식인가?
더 심각한 것은 이슈 트래킹 시스템이 협업을 방해한다는 점이다. 팀이 커질수록 이슈의 수는 기하급수적으로 증가하고, 그 이슈들을 관리하기 위한 또 다른 이슈들이 생겨난다. 이슈 간의 의존성, 우선순위 조정, 상태 변경 등 관리해야 할 것들이 산처럼 쌓이면서, 개발자들은 코딩보다 이슈를 관리하는 데 더 많은 시간을 쓰게 된다.
“이슈를 생성하는 데 10분, 설명을 작성하는 데 20분, 관련자를 태그하고 우선순위를 조정하는 데 30분… 결국 버그를 고치는 데는 5분밖에 남지 않는다.”
이런 상황이 반복되면 개발자들은 자연스럽게 이슈 트래킹 시스템을 기피하게 된다. 시스템이 복잡해질수록 사용자는 단순해진다. 결국 이슈 트래킹 도구는 팀의 생산성을 높이는 도구가 아니라, 생산성을 갉아먹는 또 하나의 관료제처럼 변질된다.
그렇다고 이슈 트래킹 시스템이 완전히 쓸모없는 것은 아니다. 규모가 큰 조직에서는 여전히 체계적인 관리가 필요하고, 그 관리를 위한 도구가 없다면 혼돈만이 남을 것이다. 하지만 문제는 그 도구가 “이슈”라는 단일한 프레임에 갇혀 있다는 점이다. Linear가 제안하는 것처럼, 이제 필요한 것은 통합된 접근 방식이다. 버그 리포팅, 기능 요청, 사용자 피드백, 심지어 문서화까지 모든 것이 하나의 흐름으로 연결되어야 한다. 이슈 트래킹 시스템이 죽었다면, 그 자리를 대체할 것은 더 유연하고, 더 인간적인 시스템이어야 한다.
기술의 발전은 항상 새로운 도구를 낳지만, 그 도구가 정말로 필요한 것인지, 아니면 그저 새로운 관성을 만들어내는 것인지는 항상 의문이다. 이슈 트래킹 시스템의 종말은 어쩌면 개발자의 일상을 더 단순하고, 더 인간적으로 만들 기회일지도 모른다. 하지만 그 기회가 또 다른 복잡성으로 변질되지 않으려면, 우리는 시스템이 아니라 문제를 먼저 봐야 한다. 이슈가 아니라 해결책을, 도구가 아니라 사람을 중심에 두어야 한다.
이 모든 논의의 출발점인 Linear의 선언은 여기에서 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
