답답해서 직접 PM 해본 개발자의 후기

어쩌다가 다른 role을 맡게 되었는가?

리워드앱 개발팀에 속해 있을 때 기획자가 회사를 떠나고 세 명의 개발자만 팀에 남게 되었다. 남아 있는 셋 다 앱을 키워내고픈 열망이 강했기 때문에 추가 DAU 확보 방법을 치열하게 고민하고 있는 상황이었다. 그중에서도 만보기는 가장 효과적인 DAU 확보 수단으로 예상되는 핵심 일감이었다. 나는 한두 달 전부터 유저 리텐션 확보를 위해 만보기 기능을 추가하자는 의견을 내어 왔었던 까닭에 자연스레 만보기를 맡게 되었다.

만보기 전체를 책임지는 것에 대한 부담이 있었다. 지금까지 개발자로서 기획에 의견을 내거나, 기획부터 구현까지 전 과정을 혼자서 진행했던 웹 게임 프로젝트 같은 케이스가 있긴 했지만 이번 건 스케일이 달랐다. 이번에는 내 아이디어를 모두가 볼 수 있는 문서로 구체화하고, 기획안을 동료들로부터 심사받고, 동료들의 업무 범위와 협업 방식까지 지정해준 다음에 다시 작업자로 돌아가 백엔드, 디자이너와 소통하며 화면을 구현해야 하는 전천후 역할이었다.

그럼에도 마침내 엉망이었던 업무 프로세스를 주도적으로 개선해볼 수 있겠다는 기대가 컸다. 처음 개발자로 발을 디딜 때부터 바라왔던 목표 중 하나가 효율적으로 운용되는 팀에 속해 업무에 몰입하는 것이여서, 업무 상의 비효율에 스트레스를 받는 편이고 이런쪽의 개선에 욕심이 좀 있다. 나는 지난 2년 여간 틈틈이 팀내 Jira 활용법에 대한 답답함을 토로하며 대안을 제안해 왔었지만 좀처럼 받아들여지질 않아 무력감을 느끼던 차였는데, 이제는 내가 뱉은 말을 증명해 보일 차례였다.

엉망이었던 업무 프로세스

사내 업무 방식은 프로젝트와 시기(구성인원의 변화)에 따라 조금씩 달랐지만, 공통된 문제는 기획서의 유지보수가 제대로 이뤄지지 못했다는 점이다. 요구사항은 끊임없이 변하고, 따라서 기획서도 빈번하게 변경된다는 특성이 기획서에 반영되질 못했다.

만보기 직전의 상황을 예로 들면 다음과 같았다. 기획자가 Notion에 줄글 형태의 기획서를 작성하고 그것을 Figma에 화면설계서와 연동한다. 작업자들은 기본적으로 Figma 화면설계서를 보되 상세한 내역이나 맥락은 링크되어있는 Notion을 참고하는 형식이었다.

이 방식도 초기 단계에는 문제가 없었다. 하지만 기획서 초안이 완성된 이후에 회의나 Slack을 통해 오고 갔던 피드백이 Notion/Figma에 누락되는 경우가 발생했다. 화면설계서는 기획자의 의도를 시각적으로 보여주는 훌륭한 소통 수단이지만, 변경 비용이 너무 컸다. 요구사항이 변경되었을 때 버저닝하는 체계가 미비해서 소통에 혼선이 빚어졌고, 이는 한참 뒤 기능 구현이 완료되고 유지보수하는 과정에도 히스토리 추적에 어려운 부메랑으로 작용해 돌아왔다.

기획서의 요구사항이 작업자들의 업무 단위로 적절히 할당되지 못하는 문제도 발생했다. 백/프/디 작업자들은 기획서를 보고 자가판단하에 필요한 업무를 정의하고 Jira 티켓을 생성한다. 이 때 작업자들의 티켓이 공통의 목표와 범위를 갖고 분배된다기보다는 각자 할일을 기록하는 정도에 가깝다. 티켓은 개개인의 todo list에 가까웠다. 이로인해 티켓이 업무현황 파악이나 소통의 편리성이라는 본분을 다하지 못했다.

워터폴과 애자일의 끔찍한 혼종

업무 프로세스가 엉망이었던 이유는 워터폴과 애자일이 끔찍하게 뒤섞였기 때문이라고 생각한다. 우리는 스프린트에 맞춰 짧은 주기로 배포하고 정기적으로 회의를 진행하며 애자일을 지향했지만 정작 기획 단계는 기민하게 가져가지 못했다. 워터폴과 애자일의 실무적 분류법은 '어느 단계에 힘을 실을 것인가'라고 생각한다. 워터폴은 기획단계부터 가능한 많은 것을 예측하고, 이후 차질없이 한 번에 쭉 작업해나갈 수 있도록 촘촘하게 문서화하는 방식이라고 볼 수 있다. 반면 애자일은 소통에 필요한 최소한의 문서만으로 기획 단계를 넘기고(모든 변수를 예측 할 수 없음을 인정한다), 실무자들간의 핑퐁으로 구체화하며 변화에 대응해나가는 방식이다. 쉽게 말하면 워터폴은 기획자가 캐리해야하는 방식이고 애자일은 PM의 조율하에 모두가 책임을 조금씩 나눠 가진다.

우리는 기획 쪽에 실린 부담이 너무 컸던 게 패착이었다. 기획자가 IT 서비스 흐름에 정통하고 도메인 지식에도 박학하며 문서 작성에 충분한 시간을 줄 수 있는 상황이라면 잘 굴러갔을 것 같다. 하지만 그런 상황은 아니었고, 변화가 필요했다.

기획서부터 작업할당까지의 SSOT 파이프라인을 구축하다

기존 업무 프로세스에서 워터폴적인 부분을 도려냈다. 기획과정과 문서를 최소화했다. 작업자들이 일을 시작할 수 있는 최소한의 정보만 제공해주고 나머지는 그들의 역량에 맡긴다.

1. PRD(Product Requirement Document) 단일화

딱 하나의 기획문서만 골라야 한다면 그건 두 말할 여지 없이 PRD였다. 요구사항이 텍스트로 명시된 형태의 문서. 기존의 화면설계서 같은 부가적인 엔트리 포인트를 제거하여 관리 요소를 줄였다. 서비스는 줄글만으로도 효과적으로 소통하면서 완성될 수 있다는 믿음이 있었다. 문서를 심플하게 유지하면서 버저닝을 도입해서 히스토리 추적 및 잦은 업데이트에 대응하기 훨씬 편리한 형태를 갖췄다.

2. 사용자 관점에서의 요구사항, 유저 스토리

PRD에 기재된 것들은 모두 사용자 관점에서의 요구사항 뿐이다. 사용자 관점에서의 요구사항이 곧 해당 서비스에 필요한 기능이 되기 때문이다. 이렇듯 사용자 관점에서 정의한 요구사항을 유저 스토리라고 한다.

유저스토리는 주로 사용자는 (Why)를 위해 (what)할 수 있다와 같은 형식으로 작성된다. 경험에 의하면 형식은 크게 중요치 않았다. 구체적인 방식(how)은 제시하지 않고 사용자에게 필요한 기능(what)을 명시하면 충분했다.

• 예시1) 유저는 마일스톤을 달성하여 보상을 획득할 수 있다
• 예시2) 유저는 출석 페이지에서 출석 보상을 수령할 수 있다

유저스토리의 의의는 작업자들을 하나로 묶어주는 요구사항이자 소통의 단위가 되어준다는 점에 있다. PM은 작업자들에게 유저스토리 단위로 업무를 할당하고 소통할 수 있게 된다. 작업자들은 1번 예시의 유저 스토리를 보고 구체적인 구현 방식(how)을 떠올린다. 그 후 작업자들을 마일스톤 기능 구현에 필요한 작업들을 나열 할 수 있다. 특히 Jira와 연동할 때 유저 스토리가 빛을 발하는데, 자세한 방법은 아래에서 이어가겠다.

3. 유저스토리를 보강하는 완료 조건(Acceptance Criteria, AC)

완료 조건은 유저 스토리에 붙는 일종의 테스트 케이스다. 유저에게 필요한 '마일스톤'이라는 기능을 설명할 때 부가적으로 붙는 최소한의 완료 조건들이다.

유저는 마일스톤을 달성하여 보상을 획득할 수 있다
- [ ] 목표 걸음수에 도달하지 못한 마일스톤은 LOCKED(목표 미달) 상태로 표시된다
- [ ] 목표 걸음수를 충족한 마일스톤은 READY(보상 수령 가능) 상태로 전환된다

이런식으로 하나의 유저 스토리에 여러개의 완료 조건이 포함될 수 있다. PM은 사용자에게 필요한 요구사항(what)만 문서에 명시한다. 구체적인 방식(how)은 작업자들의 몫이다.

위 완료조건에 명시된 상태 같이 what에 필요한 맥락은 Notion 내 다른 문서에 작성한 뒤 참조하는 형식으로 구성했다. 비용 계산에 필요한 엑셀 문서가 될 수도 있고, Mermaid를 활용한 각종 다이어그램같은 도식 위주로 요구사항을 부연한다.

4. 문서와 실무 사이의 연결 고리, Jira Story

• Story
  • PRD의 유저 스토리와 1:1로 매핑되는 Jira 이슈 단위
  • 주로 PM이 관리
• Task
  • 기술/인프라 측면의 작업
  • 사용자는 모르지만 서비스 개발/기능 구현에 있어 꼭 필요한 것
  • 주로 작업자가 생성하여 관리
• Sub-Task
  • 작업자가 Story, Task 하위에 생성하여 관리

북산 엔딩을 맞다

15개~20개 정도의 만보기앱을 설치하고 한 달 좀 넘게 분석한 끝에 업무 프로세스 자료와 만보기 기획 자료를 만들어냈다. 한 두 차례의 피드백 후 기획안과 업무프로세스 모두 통과되었다. 이 과정에서 몇몇 동료로부터 호평을 받았다. 그러나 작업자 일정 조율에 문제가 생겨 지연되다가 갑작스레 서비스 추가 개발 중단이 결정났다.

나한테 남은건 뭘까? 내 생각이 틀리지 않았다는 위안과 그로인한 자존감? 그러나 실제 운용 단계를 겪지 못한 반쪽짜리 증명에 가깝다. 많이 아쉽다.

기획자/PM 역할을 맡아본 점에는 의의를 둬볼 수 있겠다. 프론트엔드가 아닌 다른 역할군으로 롤-플레잉 하는건 완전히 다른 경험이었다. 당시에 '작업자들과 싸워야 하는 포지션' 이라고 메모해둔 게 있는데, 많은 부분을 내포하는 문장이라 생각한다.

기획/PM 롤을 겸비한 개발자가 살아남는다는 영상을 본 적이 있는데, 그런 면에서도 귀중한 경험이었다. AI로 인해 개발에 소요되는 비용은 저렴해지고 '의사결정'이 병목이 되는 추세가 이어질거라고 한다. 제품 방향성에 많은 의견을 낸다는 점은 부담이 크면서도 재밌었다.