brunch

매거진 서비스 기획자 이야기

라이킷 9 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by beyes Jul 02. 2024

이슈 관리:지라(Jira) VS 리니어(Linear)

도구로 보는 제품 관리의 미학

지라는 전통적인 이슈 관리툴의 강자입니다. 특히 업무를 분류하고 Git과 연동하면, 자동으로 개발상태가 반영되기 때문에 SW 프로젝트에서 큰 업무효율 개선 효과를 볼 수 있습니다. 지라는 개발 방법론이던, 애자일(Agile)을 가장 잘 표현하는 도구입니다.

잠시 애자일에 대해 이야기하자면, 많은 사람들이 '애자일'이 일반적인 하향식 조직 운영에 반하는 유기적이고 민첩한 조직운영 방법으로 오해하고 있습니다. 사실 애자일을 단순히 유기적인 구조로 설명하면 큰 문제가 발생됩니다. 조직은 언제나 하나의 방향을 위해 강력한 '통제'를 필요로 합니다. 강력한 '통제'는 말 그대로 강한 규칙을 의미할 수도, 적극적인 동기부여를 의미할 수도 있습니다.

애자일의 여러 방법중 대표적인 것이 '스프린트' 입니다. 커다란 목표를 적당한 길이로 분절하고, 이 안에 필요한 업무를 구성하는 것을 하나의 '스프린트'라고 합니다. 스프린트는 빠른 호흡이 중요합니다. 그리고 이 짧은 호흡동안 구성원들의 업무는 투명하게 공개됩니다. 하나의 스프린트가 끝나면 회고가 시작됩니다.

'회고'에는 미비점 보완이나, 업무간 발견한 인사이트 정리 등, 목표를 이루고 다음 스프린트를 준비하기 위한 의견 합치가 이뤄집니다.'하향식 조직 운영'이 완전히 삭제되는 것은 바로 이 시점 입니다. 의논이 잘 마무리 되고 나면, 다음 스프린트가 시작됩니다.

여러 구성원이 참여한 스프린트를 제대로 '통제'하지 못한다면, 경주마들이 트랙을 벗어나 달리는 기상천외한 풍경이 펼쳐질 것입니다. 제대로 달릴 수 있는 공간과, 달리기 규칙, 또 경주를 모니터링 할 수 있는 적절한 수단이 필요합니다.

지라는 그동안 이러한 스프린트 관리에 있어서 충분히 훌륭한 소프트웨어 였습니다. 하지만 시간이 지나, 지나치게 많은 기능을 지원하는 서비스가 되었습니다. 이게 뭐가 문제가 되냐구요?

1. 느려집니다.

2. 너무 많은 기능을 제공하니, 너무 많은 선택지가 생깁니다.

끝없이 몸집을 불리던 지라는 더 이상 민첩한 SW는 아니게 되었습니다. '지라'의 워크스페이스를 'zero'부터 구성해 본 경험이 있으신 분이라면 'jira', 'jira management' 등 생소한 구분을 만나게 될 것 입니다. 프로젝트를 생성할 땐, 수 많은 템플릿을 제안받고, 회사가 관리하는프로젝트 생성이나, 팀이 관리하는 프로젝트 생성과 같은 선택을 요구 받을 것입니다.

이는 다양한 기능을 지닌 지라가 사용자를 온보딩하는 방식입니다. 많은 선택지를 주고, 선택자에게 적합한 결과물을 제공하는 것입니다. 단, 선택지에 대한 충분한 설명은 없습니다. 지라는 이러한 문제를 프로젝트마다 따라다니는 'Quick start' 라는 가이드 라인으로 해결하려고 합니다. 퀵 스타트는 "뭘 하려면, 이렇게 해. 이게 좋아" 같은 내용을 제공합니다. 직접 해볼 수 있도록 실습 동작까지 지원합니다.

하지만, 정말 큰 문제는 '회사가 관리하는 프로젝트'를 생성하면서 발생합니다. 지라로 프로젝트를 생성하면 사전에 구성한 템플릿을 사용하는 만큼 여러가지 사전설정 요소들이 따라 붙습니다. '이슈의 항목들' ,'워크 플로우' 등이 그것입니다. 구성자체는 잘 짜여져 있으나 여기서 3가지 문제가 발생합니다.

1. 디테일한 구성이 다를 수 있다.

2. 한 프로젝트시 4개의 프리셋이 생성되며 이들이 유기적으로 연결되어있다.

3. 프리셋은 공유할 수 있음에도 불구하고 프로젝트를 생성하면 반드시 프리셋이 항상 생성된다.

우선 디테일한 구성을 변경하는게 까다롭습니다. 느리기도 하거니와 UI도 불편하기 때문입니다. 또 2번 이슈처럼 여러 프리셋이 연동되어있어 이를 분리하고 다시 결합하는 일이 매우 귀찮습니다. 프로젝트를 복제한다면 상관없지만, 새로운 프로젝트를 누군가 생성한다면 이러한 프리셋들은 또 덕지덕지 생성될 것입니다. 사전에 구성한 프리셋만 사용할 수 있도록 선택하는 옵션은 없습니다. (제가 알기론)

지라의 불편함에 대해 모든 분들이 동의하지 않을 수도 있습니다. 하지만 '리니어(Linear)'의 이야기를 한 번 들어보신다면, '어쩌면 이슈 관리도구들이 가야할 방향성은 이게 아닐까?' 하는 생각이 들 수 있습니다. 나아가 리니어가 제안하는 모든 것이 Project Manager를 위한 가장 완벽한 덕목으로 느껴지기까지 합니다. 지금부터 리니어 예찬을 시작합니다.

가장 현대적인 팀을 위한 이슈트래커라고 합니다. (출처: Linear.com)

가운데 "Designd to move fast"가 보이시나요? 리니어는 정말 굉장히 빠릅니다. 이슈를 생성하고 삭제하고 팀을 생성하고 구성하고, 등등 딜레이가 거의 느껴지지 않을 정도입니다. 프로젝트에 따라 다르지만 한 화면에 백개가 넘는 이슈가 출력될 수도 있습니다. 누적된 이슈는 수 천, 수 만개에 달할것이고요. 레이블이나 구성요소가 일부 변경된다고 해도 리니어는 굉장히 신속하게 대응합니다.

'속도'는 모든 프로그램의 덕목이라고 생각됩니다. 하지만 이슈 관리도구인 '리니어'가 가진 최대의 덕목은 '프로젝트 관리'에 대한 방법론을 굉장히 구체적이고 상세하게 제안하고 있다는 것입니다. 리니어는 소프트웨어의 사용법을 제공하기 이전에 '프로젝트를 어떻게 대해야 하는지'를 먼저 제안합니다. 아래는 이들이 작성한 Linear Method 의 Principles & Practices 의 일부 내용입니다.

1) 크리에이터를 위한 빌드

소프트웨어 프로젝트 관리 도구는 최종 사용자, 즉 크리에이터를 염두에 두고 구축되어야 합니다. 완벽한 보고서를 생성하는 것보다 "개인의 생산성을 유지하는 것이 더 중요"합니다.

2) 고집스러운 소프트웨어 (Opinionated software)

생산성 소프트웨어는 명확한 방향성이 있어야 합니다. 그래야 사용자를 위한 커다란 작업을 수행할 수 있습니다. 유연한 소프트웨어는 모든 사람이 자신만의 워크플로를 만들 수 있게 해주지만, 팀 규모가 커지면 결국 혼란을 야기합니다.

3)서두르지 말고 모멘텀을 만드세요

업무의 리듬과 루틴을 찾아야 합니다. 주기에 따라 우선순위를 정하고 책임을 할당합니다. 우리의 목표는 끝을 향해 서두르는 것이 아니라 팀과 함께 건강한 모멘텀을 유지하는 것입니다.

Linear Method 는 짧고 간결하게 프로젝트 관리자를 위한 가이드를 제공하고 있습니다. 사이트에 들어가시면 보다 많은 내용을 열람할 수 있습니다. 모든 내용을 하나 하나 읽어내려가면서, 그동안의 프로젝트 관리가 주마등처럼 스쳐 지나갔습니다. 더 재미 있는것은 Linear Method 안에는 리니어에 대한 사용법도 조금씩 녹아있습니다. 내용을 읽어내려가면서 손쉽게 리니어에 적용해볼 수 있는 식입니다.

지라는 애자일을 강조합니다. 하지만 실제로 '스크럼'을 통해 애자일을 진행하려고하면 '방대한 문서'를 만날 수 있습니다. 리니어에는 유사하게 '사이클' 이라는 기능이 있습니다. 리니어는 '사이클'에 대해 매우 간결하게 설명합니다. 이는 리니어가 추구하는 "Aim for brevity. Short specs are more likely to be read." 와도 상통합니다. 간결한 글을 더 읽고 싶어하는 독자의 욕구를 충족하는 것입니다.

실제로 지라에서 스크럼 프로젝트를 생성하고자하면, 백로그, 스프린트, 애자일에 대한 3개의 문서를 읽어볼 수 있고, 이는 굉장히 긴 내용으로 구성되어 있으며, 실제 스크럼 사용법과는 무관합니다. 반명에 리니어는 사이클이 지니는 프로젝트 관리적 기능과 더불어 소프트웨어의 기능을 동시에 설명합니다. 그리고 이는 A4용지 한 장도 안되는 분량으로 끝납니다.

IT업계에서 일하면서 소프트웨어의 사용 설명서를 하루만에 다 읽어본 건 이번이 처음인 것 같습니다. 심지어 읽고 싶어서 자발적으로 읽게된 건요. 좋은 책 한권을 읽은 느낌이었습니다. 또, 서비스 기획자로서 사용자를 위한 글 작성에 대해 큰 인사이트를 얻을 수 있었습니다.

리니어는 지라만큼 다양한 기능을 지원하지는 않습니다. 프로젝트 전역적으로 관리가능한 자동화 기능도 없습니다. 지라와 같이 다양한 템플릿을 지원하지도 않습니다. 하지만 리니어는 프로덕트 담당자들을 위한 근본적인 담론을 제시합니다.

궁극적으로 생각해봤을때 업무관리도구가 PM에게 제공해야하는 것은 템플릿이 아닙니다. 하늘아래 똑같은 조직은 없고, 그만큼 무수한 관리 방법이 존재하니까요. 관리자는 언제나 자신의 조직과 프로덕트에 대한 깊은 고민을 갖고 있습니다. 이들의 갈증을 해소할 수 있는 건 템플릿 따위가 아니라, 공감되는 프로세스와 온보딩인 것 같습니다.

우리 회사는 광고대행사로 200명에 가까운 AE, 디자이너, 콘텐츠 에디터 등의 직군이 프로젝트를 중심으로 협업하고 있습니다. 이들을 위한 이슈 관리도구 도입이 필요했기에 관련 TF를 구축하고 지라, 리니어 등의 도구를 사용해 본 후기입니다.

사실 비개발직군 중심의 이슈관리도구로는 지라보다는 '아사나', '먼데이' 등이 적합한 것 같습니다. 유연하고, 이슈 작성이 매우 편리합니다. 다만 개발 관리도구로서는 조금 부족하지요. '지라'를 도입하게된 것은 좀더 견고한 관리를 하고 싶었기 때문인데, 이건 쓸데없는 욕심이었고, 시간낭비로 이어졌습니다. 지라를 활용해 업무환경을 구축했지만, 팀원들을 온보딩하는게 너무 어려웠거든요.

반면에 리니어는 TF 구성원들 또한 쉽게 사용할 수 있었습니다. 팀, 팀간 협업 등이 매우 직관적으로 표현되어 있는 UI는 누구라도 쉽게 적응할 수 있을 것입니다. 또, Asks를 활용한 슬랙 스레드와의 연동은 기존의 업무방식의 완벽한 상위호환이었습니다.

Linear 도입을 위해 제작한 가이드 문서의 일부. 구조를 이해할 수 있는 핵심 도안

그래서.. 지금도 리니어를 사용하고 있냐고요? 아닙니다. 지금은 슬랙의 '리스트'를 사용하고 있습니다. 리니어를 도입하고 모니터링을 하고 있던 지난 6월 말, 슬랙에 '리스트' 라는 간단한 이슈관리 기능이 업데이트 되었기 때문입니다.

슬랙의 리스트 소개 (출처:Slack)

정말 간단한 기능만을 제공합니다. 그러나 슬랙을 주요 커뮤니케이션 도구로 사용하는 팀에는 매우 유용한 기능들이었습니다. 스레드를 통해 업무를 생성하고, 연동할 수 있고, 별도의 인터그레이션 없이 워크플로를 통해 직관적으로 알림을 연동할 수 있었습니다. 그 외에 다른 기능은 없지만, 이것만으로도 충분하지요. 그래서 개발조직을 제외한 모든 구성원들은 그냥 슬랙만 사용하기로 했고, 이유를 요약하자면 다음과 같습니다.

1. 모두에게 익숙한 슬랙, 온보딩 간소화

2. 이슈관리툴로서 충분한 기능을 제공

3. 아직은 슬랙 요금제에 포함되어 무료로 이용가능

그래도 '리니어'를 통해 프로젝트 관리에 대해 한 번 더 진솔한 고민을 하게 되었고, 진정으로 제품 개발을 아끼는 자들의 마인드를 보면서 또 하나 배운 기분입니다. 참 세상은 넓고 대단한 사람은 많은 것 같습니다.

ps. 표지는 1900년대의 고양이 덕후 헨리엣 로너(Henriette Ronner-Knip)의 고양이 그림입니다. 고양이가 귀엽잖아요.

keyword