지라를 지금까지 사용해오지 않았던 이유, 그리고 이제 도입을 제안하는 이유를 정리해보았습니다. 팀이 제 생각에 충분히 공감한다면, 팀에 도입하고자 합니다.
지라에 대한 두려움
지라는 어렵습니다. 그리고 복잡하죠. 서비스는 무겁고 느리며 유연하지 못합니다. 시간이 갈수록 일을 위해 사용하는게 아니라 관리자에게 보여주기 위해서 사용하게 되고, 일을 위해서 도구를 사용하게 되는게 아니라 도구를 위해서 일을 하게 됩니다.
이것은 제가 지라에 가지고 있는 조금은 막연한 두려움입니다. 지라를 제대로 사용하기 위해서는 일정 수준의 학습이 분명히 필요하고, 특정 도구에 대한 깊은 의존성을 가지는 것도 바람직하지 못하다고 생각했습니다. 제목은 분명히 지라 도입 제안서인데, 이렇게 시작하려니까 조금 이상하네요. 지라를 주요 도구로 사용한 것은 저의 세 번째 직장뿐이였지만, 직접 사용하면서도 그리고 인터넷에 돌아다니는 사용기를 보면서도 저의 생각은 크게 변하지 않았습니다.
공동 창업으로 시작한 지금 직장에서 초기 업무 프로세스 도구 환경을 구성할 때, 구성원들이 일정 부분 이런 생각들을 모두 가지고 있었고 우리는 이슈 관리 도구로서 트렐로를 사용하였습니다. 그리고 문서는 G Suite (이제는 Google Workspace) 내 드라이브에 작성하였죠. 그리고 프로젝트가 커지고, 사업 아이템이 피봇되는 과정에서 업무 환경 개선을 위한 여러 가지 시도를 해왔습니다. 트렐로에서 Github Project 로 이슈 관리 도구를 이동하려고 했지만 개발자가 아닌 구성원이 사용하기에는 접근성이 많이 떨어졌습니다.
이러한 여러 번에 시도 과정에서도 지라는 항상 배제되었습니다. 가끔씩 한번 써볼까? 라는 생각에 잠깐 들어가보면 어디서부터 시작해야할지 모르는 막막함에 다시 눈을 돌려왔죠. 그리고 우리는 노션을 발견했고 노션은 우리에게 아주 좋은 도구였습니다.
최고의 도구, 노션
다양한 형태의 뷰, 어떠한 형태로든 변경될 수 있는 블록 시스템, 개발팀을 넘어선 모든 구성원의 사용 편의성, 그 외 많은 노션의 특징은 우리가 업무를 하면서 느꼈던 갈증을 해소해주기에 충분했습니다. 여기저기 흩어져있던 정보들은 모두 노션 안으로 이전되었고, 노션을 단순히 메모장으로 사용하는 사람도, 이슈 트래커로 사용하는 팀도, 데이터 시트로 사용하는 사람도 있었습니다. 동시 편집 기능으로 협업 능력도 향상되었고, 접근 권한이나 외부 공유에 대한 제어도 직관적이고 편리했습니다. 쉽고 무엇보다도 빨랐죠. 그렇게 노션에 정착하고 1년이 넘게 흘렀습니다. 노션은 여전히 저희 팀에 주요 업무 도구이며, 앞으로도 지식 관리 시스템 (KMS) 혹은 위키로 사용할 생각입니다. 그런데 노션을 오랫동안 사용하면서 몇 가지 문제점이 눈에 밟히기 시작했습니다.
정리된 정보와 팀 데이터의 필요성
모든 데이터가 노션에 있다.
정보의 파편화는 내가 원하는 정보를 어디서 찾아야할지 고민하게 만드는 주요한 이슈입니다. 노션은 이러한 부분을 많이 해소해주었습니다만, 이에 따라오는 부작용이 있었습니다. 바로 불필요한 정보 = 즉 정보라고 보기 힘든 문서들 또한 다량으로 저장되어 있다는 점입니다. 그 이유 중에 하나가 노션에서 모든 이슈를 생성하고 있기 때문입니다.
저는 노션에 존재하는 이런 데이터를 흐르는 데이터라고 표현하고자 합니다. 정보로서는 크게 가치가 없는, 이미 변경되어 더 이상 효용이 없는 문서말이죠. 그리고 노션 안에는 이런 문서들이 가득합니다. 현재 노션에서 특정 키워드로 검색하더라도 지금 업무를 진행하기 위해 필요한 문서를 찾을 확률은 극히 낮아져있습니다. 또한 그 문서를 찾더라도 이슈 트래킹을 위해서 작성한 프로제트 과정 중에 티켓일 수 있어서 신뢰성이 없습니다. 즉 노션에서 문서(이슈 티켓)를 찾아서 그 배경지식을 가지고 일을 진행했으나, 이미 다른 이슈 티켓으로 변경된 후라 일이 제대로 진행되지 않는 현상이 반복적으로 발생하고 있습니다.
이는 흐르는 정보와 저장하고 있어야 할 정보를 분리하면 해결할 수 있다고 생각합니다. 즉 이슈 트래커를 별도로 사용하여 업무 진행은 그 도구에서 하고 진행이 완료되어 최종적으로 사내에 공유될 부분만 "정리"하여 노션에서 축적하고 기존 문서를 업데이트한다면, 업무 중에 참고해야 할 문서의 퀄리티나 신뢰도가 높아질 수 있습니다.
스크럼을 위한 이슈 트래커에 필요성
우리는 애자일 프로세스를 지향하고 있고, 스크럼 보드를 채택하여 스프린트 단위로 일을 진행하고 있었으나, 돌이켜보면 하는 시늉만 했을 뿐 스크럼 내 반복주기(스프린트)를 통해 도출해내야하는 프로젝트 팀의 속도(속도 그래프)와 일의 진행 상태(번다운 그래프)와 같은 수치로 표현할 수 있는 데이터들은 도출해내지 못하고 있었습니다. 그냥 2주일 단위로 짤라서 할 일을 했을 뿐이죠. 대략적인 팀의 속도를 파악할 수 없으니 "가능한 빨리"라는 비즈니스 요구 조건에 따라 정해져진 프로젝트 마감일자를 지나는 것도 빈번해졌습니다.
최근에 읽은 Clean Agile 이라는 책에서 반복 주기를 통해 팀의 속도를 계속해서 파악하고, 팀의 데이터를 도출했다면 그 스프린트는 실패한 것이 아니다. 라는 부분에 많이 공감했습니다. 노션 안에서 이런 데이터를 수동으로 뽑아낼 수는 있지만 한계가 명확했고, 지라는 이런 쪽에서는 오랜 기간 개선해오면서 뛰어난 기능을 제공해주고 있습니다.
전체적인 일정 파악 필요
구성원이 늘어나고 팀이 분리되면서 각 팀은 노션 내에서 각각의 이슈 트래킹 문서를 가지게 되었고, 전체적인 일의 진행 상황을 파악하고 조율해야하는 Project Manager 혹은 Spring Master 는 각 문서를 하나하나 들어가서 확인해야 합니다. 노션에서 링크된 데이터베이스 생성 기능으로 하나의 문서로 합칠 수는 있지만 한계가 확실히 있습니다. 반면 지라의 경우 대시보드를 제공해서 여러 프로젝트 보드를 한 화면에서 파악할 수 있죠. 물론 제대로 활용하기 위해서는 학습이 필요합니다.
도구는 도구다.
중요한 점은 지라를 사용하든 노션을 사용하든 도구는 도구일 뿐이라는 점입니다. 결국 도구를 사용하는 사람이 어떻게 사용하느냐에 따라서 도움이 될 수도 있고, 그냥 관리 포인트만 늘리는 형식이 되어버릴 수 있습니다. 아이러니하게도 'Clean Agile' 에서는 애자일 프로세스 관리 도구는 지양해야 하며 가장 좋은 도구는 인덱스 카드라고 합니다. 이런 조언도 간과해서는 안될 것 같네요.
마치며
팀 내 지라 도입 제안을 하기 전에 장단점을 정리하고, 왜 필요한지, 도입 했을 때 개선되는 점들은 무엇인지 적어보려고 했는데 두서없이 적다보니 군살이 너무 많이 붙어버렸습니다. 이대로 제안한다면 팀원들에 공감을 얻어내기는 힘들어보입니다. 그래도 적으면서 다시 한번 생각해보는 계기가 되었습니다. 이 초안을 바탕으로 군살은 빼고 핵심만 나열해서 다시 작성해봐야겠네요. 긴 글 읽어주셔서 감사합니다.