Jira의 늪에서 허우적대던 PM이 룰 메이커가 되기까지의 이야기
얼마 전 발행한 SEO 관련 게시글에서, 우연한 기회로 시작된 SEO 정책서가 전사 공식 문서로 제정된 에피소드를 짧게 언급한 적이 있다. 사실 그건 전 회사에서 맨땅에 헤딩하며 만들어낸 25개의 정책서 중 하나에 불과하다.
당장 눈앞의 업무를 쳐내기도 바빴던 신입 기획자가 왜 굳이 그 방대한 정책들을 하나하나 문서화해야만 했을까? 오늘은 그 이유와 기나긴 과정을 기록해 보려 한다.
내가 담당했던 3개의 서비스는 모두 최소 5년, 길게는 10년 가까이 된 회사의 주요 캐시카우였다. 하지만 그간 빠른 실행력이 우선시되었던 탓에, 모든 기능 정의와 의사결정 히스토리가 체계적인 문서가 아닌, Jira 티켓과 수천 개의 댓글 속에 혼재되어 있었다. A 기능의 사이드 이펙트를 파악하려면 JQL을 붙잡고 몇 년 전 티켓까지 거슬러 올라가야 했고, 당시의 맥락을 아는 담당자를 찾아다니는 것이 일상이었다.
Jira 고고학자가 된 나는 유물을 발굴하듯 댓글 하나하나를 뜯어보며 서비스의 원형을 찾아내는 데 너무나 많은 리소스를 소모하고 있었고, 이는 곧 팀 전체의 커뮤니케이션 비용 상승으로 이어졌다. 모두가 같은 화면을 보면서도 서로 다른 과거의 기억을 이야기하는 상황. 이제는 기록이 아닌 시스템이 필요한 시점이었다.
가장 먼저 손을 댄 것은 서비스의 관문인 회원가입/로그인 정책이었다. 당시 내가 기획 중이던 다국어 지원 정책이 추가되면서, 기존 로그인 로직에 변화가 생긴 것이 결정적인 계기였다.
기초가 튼튼해야 그 위의 기능들이 흔들리지 않는 법. 이참에 파편화된 Jira 티켓들을 하나씩 대조하며 과거의 히스토리와 예외 케이스들을 전수 조사했고, 여기에 신규 다국어 정책까지 반영해 하나의 통합된 기준 문서로 정리했다. 이 첫 기준점이 탄탄하게 잡히고 나자, 이후 뻗어 나가는 다른 정책들을 작성하는 데에도 확실히 가속도가 붙었다.
정책서는 서비스 기능에만 머물지 않았다. 유료 멤버십, 다국어 지원 등 기존 기능의 정상화를 위한 문서와 더불어, 현재 기획 중인 신규 기능의 미래 정책서를 병행해서 작성했다.
또한, 기획자의 업무를 넘어 팀 전체의 효율을 고민했다. 외부 개발사 커뮤니케이션 가이드, 비용 및 결제 처리 가이드, SEO 최적화 기술 정책 등이 그렇게 탄생한 문서들이다.
결과적으로 프로덕트 정책 22개와 운영/협업 가이드 3개를 포함해 총 25개의 정책서를 완성했다.
이 방대한 양을 빠르게 쳐낼 수 있었던 비결은 AI와의 협업이었다. 먼저 타사의 정책 레퍼런스를 리서치해 수집하고, AI의 도움을 받아 우리 팀이 보기 편한 문서 규격으로 통일했다.
AI가 정리한 내용은 참고용에 불과했기에, 여기에 우리 서비스의 특성이나 규칙 등을 대입한 커스텀 템플릿을 직접 설계했다. 단순히 글만 나열하지 않고, 어떤 기획자가 오더라도 동일한 퀄리티의 문서를 생산할 수 있는 프레임워크를 만든 셈이다.
이 프레임워크 안에서, 나의 최종 목표는 언제든 최신 상태로 찾을 수 있는 정보 체계를 구축하는 것이었다. 서비스의 정책은 한 번 작성하고 끝나는 것이 아니라 기능 추가나 비즈니스 변화에 발맞춰 끊임없이 업데이트되어야 하기 때문이다.
이를 위해 전사가 공통으로 따를 수 있는 정책서 유지보수 및 버전 관리 규칙을 아주 촘촘하게 세팅했다.
| X | 구조 변경 등 큰 수정 |
|---|---|
| Y | 중간 규모 이상 추가/변경 |
| Z | 오탈자 등 경미한 수정 |
이제는 누구나 궁금한 게 생겼을 때 Jira의 과거 댓글을 뒤지는 대신 이 Wiki 문서를 켜고, 1분 만에 가장 최신 버전의 정책을 정확히 찾아낼 수 있다!
처음엔 “바쁜데 굳이?”라는 시선이 신경 쓰여 남몰래 정책서를 써 내려 가기도 했다. 반전의 계기는 지난 글에서 다뤘던 SEO 최적화 기술 정책서였다. 복잡한 기술을 비전공자도 이해하기 쉽게 풀어 쓴 결과물을 보고 대표님께서 큰 만족감을 표하셨고, 덕분에 나의 개인적인 정리는 회사의 공식 프로젝트로 단숨에 격상될 수 있었다. 이후 외주 개발사와의 잦은 커뮤니케이션 트러블을 가이드 한 장으로 해결하면서, 팀원들 사이에서도 문서화가 곧 속도라는 인식이 형성되기 시작했다.
정책서가 하나둘 완성될수록 가장 크게 달라지는 건 나의 업무 환경이었다. 타 부서에서 과거의 출시일이나 특정 기능의 예외 케이스를 물어볼 때, 나는 더 이상 Jira의 늪을 탐험할 필요가 없었다. 언제 어디서나 컴퓨터 또는 휴대폰으로 정책서를 확인하고 정확한 답변을 전달하는 데 걸리는 시간은 단 1분. 잘 만든 시스템 덕분에 히스토리를 뒤적거리는 행위에서 벗어나, 프로덕트의 미래를 그리는 기획의 본질에 오롯이 집중할 수 있게 되었다.
솔직히 말하면, 서비스의 모든 기능에 대한 정책서를 끝까지 완성하지 못하고 온 것이 아직도 못내 아쉽다. 자식들을 두고 나온 기분이 이럴까 싶다. 하지만 문서 불모지에 나만의 유기적인 정책 시스템을 만들면서 확실하게 깨달은 것이 있다.
기획자의 진짜 역량은 화려한 화면 설계나 철저한 기능 정의에서만 나오지 않는다. (물론 이 또한 중요하지만!) 진짜 기획의 힘은, 무질서하게 흩어진 정보들 사이에서 팀이 나아갈 기준을 정립하는 데에 있다.
흔히 말하는 0 to 1은 없던 일들을 뚝딱 만들어내는 걸 뜻하기도 하지만, 정확히는 지속 가능한 성장을 버텨낼 기틀을 세우는 과정 그 자체라고 생각한다. 그렇기에 나는 나 자신을 당당히 룰 메이커(Rule Maker)라고 부르고 싶다. 나를 믿고 지지해 주는 동료들만 있다면, 세상의 모든 무질서여 내게 오라! 전부 다 완벽한 시스템으로 만들어 줄 테니😎