Lesson learn (1) - 제품 백로그 관리하기

운영의 불편함에서 시작된 제품 백로그 관리 개선 회고

그동안 제품을 운영하면서 가장 꾸준히 어려움을 느꼈던 영역 중 하나는 제품 백로그 관리였다.
아이디어는 계속 생기고, VOC도 꾸준히 들어오고, 운영팀이나 CS를 통해 다양한 요청들이 쌓이는데, 이를 체계적으로 정리하고 추적하는 일이 생각보다 쉽지 않았다.

기존에는 아래와 같은 방식으로 제품 관련 이슈들을 관리해왔다.

기존 운영 방식

1. PON 시트 운영

아이디어 단계의 내용이나 VOC, 운영 중 발견된 문제 등을 우선 가공되지 않은 raw 형태로 기록하는 방식이었다.
말 그대로 “일단 적어두는 공간”에 가까웠고, 빠르게 메모할 수 있다는 장점은 있었지만 시간이 지날수록 내용이 누적되면서 관리가 점점 어려워졌다.

2. Jira 백로그 운영

PON 시트에 쌓인 항목들 중 일부를 선별해, PRD 작성이 완료되면 그때 Jira에 티켓을 생성하는 방식으로 운영했다.
즉, 실제 개발 대상으로 확정된 이후에야 비로소 Jira에서 추적이 가능해지는 구조였다.

3. 개발 진행

이후에는 Jira를 기준으로 개발이 진행됐다.

---

기존 방식의 한계

이 방식은 초기에는 나름대로 굴러갔지만, 운영을 지속할수록 몇 가지 분명한 한계가 드러났다.

가장 큰 문제는 아이디어와 요청사항이 ‘가공되기 전 단계’에서 너무 오래 머무른다는 점이었다.
운영팀이나 CS에서 전달받은 내용들은 대부분 PON에 raw하게 저장해두고 필요할 때마다 꺼내 쓰는 식이었는데, 이 과정에서 다음과 같은 문제가 반복됐다.

• 어떤 아이디어가 실제로 검토 중인지 한눈에 보기 어렵다.
• 누가 제안한 내용인지, 왜 필요한지, 어떤 배경에서 나온 요청인지 맥락이 쉽게 사라진다.
• 전사적으로 현재 어떤 아이디어가 살아 있고, 어떤 상태에 있는지 추적하기 어렵다.
• 결국 제품 관련 정보가 개인의 기억이나 수작업에 의존하게 된다.

즉, “아이디어를 모으는 공간”은 있었지만,
그 아이디어가 어떻게 제품 백로그로 발전하고 관리되는지 보여주는 체계는 부족했다고 볼 수 있다.

---

그래서 어떻게 바꿨는가

이 문제를 해결하기 위해 제품 백로그 운영 방식을 조금 더 구조적으로 바꾸기로 했다.

변화의 방향: 정제된 제품 백로그를 Notion에서 운영하기

이제는 제품 백로그를 단순한 아이디어 모음이 아니라,
일정 수준 이상 정제된 형태로 관리되는 공간으로 정의하고 Notion을 중심으로 운영하기로 했다.

변경된 운영 방식

1. 정제된 제품 백로그를 Notion에서 관리

이제 제품 백로그는 단순 메모 수준이 아니라,
BRD와 PRD가 작성된 상태의 항목들 중심으로 관리한다.

이를 통해 다음이 가능해졌다.

• 전사적으로 현재 어떤 백로그가 존재하는지 확인 가능
• 각 항목의 상태값을 간단하게라도 일관되게 관리 가능
• 아이디어가 단순 제안에서 끝나는 것이 아니라, 검토와 정제 과정을 거쳐 관리됨
• 제품 관련 논의가 특정 개인이 아닌 조직 단위에서 공유됨
• 사이즈가 큰 기능일 경우 BRD 작성으로 기능의 로드맵과 변수를 최대한 찾고 진행 가능

2. BRD를 통해 아이디어의 배경과 목적을 먼저 정리

특히 이번에 중요하게 본 것은 아이디어를 바로 개발 요청으로 넘기지 않는 것이었다.

아이디어 제공자는 BRD를 통해,
해당 아이디어가 왜 필요한지, 어떤 배경에서 나왔는지, 실제로 개발되었을 때 우리가 무엇을 얻을 수 있는지를 최소한으로라도 정리한다.

이 과정은 단순한 문서 작성 이상의 의미가 있었다.

• 아이디어의 필요성을 스스로 한 번 더 검토하게 된다.
• 요청의 맥락이 살아남는다.
• PO 입장에서도 왜 이 아이디어를 제품 백로그로 받아들여야 하는지 판단하기 쉬워진다.
• 결과적으로 PRD 작성의 출발점이 더 명확해진다.

즉, BRD는 단순한 형식이 아니라
아이디어에 설득력을 부여하고, PO가 더 나은 PRD를 작성할 수 있게 만드는 장치가 되었다.

---

이번 변화에서 얻은 레슨런

이번 경험을 통해 느낀 점은 분명했다.

백로그는 많이 모으는 것보다, 어떻게 정제하고 추적 가능하게 관리하느냐가 더 중요하다.

raw한 아이디어를 많이 쌓아두는 것 자체는 나쁘지 않다.
하지만 그것이 관리 체계 없이 누적되면 결국 정보는 쌓이는데 인사이트는 줄어든다.
특히 제품 조직이 커질수록 “지금 무엇이 논의 중이고, 무엇이 우선순위에 있으며, 무엇이 보류되었는지”를 모두가 같은 언어로 볼 수 있어야 한다.

이번에 운영 방식을 바꾸면서 얻은 가장 큰 배움은 다음과 같다.

• 아이디어 수집 공간과 제품 백로그 공간은 구분되어야 한다.
• 제품 백로그는 누구나 볼 수 있고, 상태를 추적할 수 있어야 한다.
• 좋은 PRD는 좋은 입력값에서 시작되고, 그 시작점은 BRD처럼 배경과 목적이 정리된 문서다.
• 결국 백로그 관리는 문서 관리가 아니라, 조직의 사고 과정을 정리하는 일에 가깝다.

---

마무리

아직 완벽한 방식이라고 보기는 어렵다.
다만 분명한 것은, 이전보다 훨씬 아이디어의 흐름이 보이고,
어떤 요청이 어떤 과정을 거쳐 제품 백로그가 되는지 설명할 수 있게 되었다는 점이다.

앞으로도 백로그 관리 방식은 계속 다듬어야겠지만,
이번 변화는 최소한 “아이디어가 흩어지지 않고 조직 안에서 관리되기 시작했다”는 점에서 의미가 있었다.