백로그가 엉망이면 제품도 엉망? 좋은 백로그를 만드는 4가지 방법

 

"이거... 어디서부터 시작하죠?" 이 말, 들어보셨나요?

스프린트가 시작되고 팀원들이 백로그 아이템을 열어봅니다. 그런데 딱 보자마자 분위기가 싸해져요. 개발자는 고개를 갸웃거리고, 기획자는 말을 더듬고, 스크럼 미팅은 엉뚱한 방향으로 흘러갑니다.

이거 솔직히 PO 입장에서 정말 민망한 상황이잖아요.

백로그가 있다는 것과, 잘 만들어진 백로그가 있다는 건 완전히 다른 이야기입니다. 오늘은 글로벌 애자일 전문가 조한나 로스만(Johanna Rothman)의 최신 인사이트를 바탕으로, 현장에서 바로 쓸 수 있는 백로그 형성(Shaping) 방법 4가지를 정리해드릴게요.

백로그가 망가지는 이유, 사실 생각보다 단순해요

백로그가 엉망이 되는 가장 흔한 원인은 딱 하나입니다. 바로 기능 중심 사고예요.

제품 리더가 '현재 우리 제품'에서 '원하는 목표'까지의 경로를 혼자는 알고 있는데, 그 맥락이 팀에게는 전혀 전달되지 않은 상태. 리더 입장에서는 "이건 당연히 아는 거 아닌가요?"라고 생각하지만, 팀은 아무것도 모른 채 기능 목록만 받아드는 거죠.

그렇게 기획이 문제 기반이 아니라 기능 기반으로 흘러가고, 실행 가능성 없는 아이템들이 백로그를 채우기 시작합니다.

국내 스타트업 현장에서도 이런 상황은 흔합니다. 스프린트를 열심히 돌리고 있는데 정작 팀이 어떤 고객의 어떤 문제를 해결하려는지 모호한 경우, 생각보다 많거든요. 실제로 국내 SaaS 스타트업들이 꼽는 가장 큰 어려움 중 하나가 바로 이 제품 방향성 불명확 문제라는 점, 결코 가볍게 볼 수 없습니다.

'형성(Shaping)'이 뭔데 그렇게 중요한가요?

로스만은 백로그 아이템이 너무 크거나 불명확할 때, 무작정 개발을 시작하는 대신 먼저 작업을 형성(Shaping)해야 한다고 말합니다.

형성이란 팀이 실제로 무엇을 해야 하는지를 명확하게 만드는 과정이에요. 이 과정 없이 개발을 시작하면, 팀은 사실상 안개 속을 달리는 거예요. 방향은 있는데, 앞에 뭐가 있는지 아무도 모르는 상태.

그 결과는 뻔하죠. 스프린트가 끝나도 뭔가 찜찜하고, 리뷰 때 이해관계자들의 반응은 싸늘하고, 다음 스프린트엔 또 같은 문제가 반복됩니다.

그렇다면 어떻게 형성할 수 있을까요? 크게 4가지 방법이 있습니다.

방법 1. 시니어가 먼저 탐색하고, 팀이 완성하는 방식

가장 유명한 건 베이스캠프(Basecamp)의 방식입니다. 일명 "Place Your Bets"라고 불리는 이 방법인데요. 시니어 구성원이 사전에 충분히 탐색하고, 6주 분량의 작업 범위와 위험 요소를 정의해서 팀에 넘기는 방식이에요.

이 방식의 장점은 명확합니다. 팀이 불필요한 견적 논쟁을 줄이고 실행에만 집중할 수 있어요. 베이스캠프는 이 방식으로 무엇을 만들지 결정하는 데 쓰는 시간을 줄이고, 실제 제작에 에너지를 집중하는 문화를 만들었거든요.

다만 단점도 있어요. 시니어가 의사결정 근거를 충분히 전달하지 않으면, 팀은 "왜 이 방향인지" 이해 못 한 채 그냥 실행하게 됩니다. 자율적인 팀을 만들고 싶다면, 이 방식만으로는 한계가 있어요.

방법 2. 한 명이 먼저 탐색하고, 팀 전체가 마무리하는 방식

팀 내 누군가에게 여유 시간이 생겼을 때, 그 사람이 먼저 다음 아이템을 탐색하는 방식이에요. 언뜻 효율적으로 보이지만, 로스만은 이 방식에 꽤 비판적입니다.

이유가 뭐냐고요? 핵심은 팀의 학습 속도예요.

제품 개발에서 진짜 중요한 건 팀이 함께 배우는 속도인데, 한 사람만 먼저 탐색하고 나머지는 브리핑을 받는 구조에서는 맥락이 손실될 수밖에 없어요. 또 WIP(Work In Progress), 즉 진행 중인 작업이 늘어나면서 전체 흐름이 느려지는 부작용도 생기고요.

더 큰 문제는 그 사람이 전략적 맥락을 충분히 이해하고 있는지도 불확실하다는 거예요. 단순히 여유가 있다는 이유만으로 탐색을 맡기면, 오히려 방향이 엇나갈 수 있습니다.

방법 3. 팀 전체가 함께 워크숍으로 문제를 정의하는 방식

로스만이 가장 추천하는 방식 중 하나입니다. 팀 전원이 모여서 이 질문을 함께 정리하는 거예요. "이 기능 세트가 어떤 사용자의 어떤 문제를 해결하는가?"

이 과정에서 팀은 자연스럽게 어디서 실험이 필요하고, 어디서는 점진적인 가치를 제공할 수 있는지 스스로 판단하게 됩니다. 기능 세트 단위로 생각하기 시작하면, 작업이 더 작고 실행 가능한 단위로 분해되기 시작해요.

국내 SaaS 팀에서도 이 방식은 꽤 유효합니다. 제품팀과 개발팀이 따로 놀던 문화에서, 워크숍 한 번으로 서로의 이해를 맞추고 공동의 문제의식을 갖는 경험은 팀 전체의 품질을 바꿔놓거든요. 실제로 애자일에서 초기에 사용자 스토리 워크숍을 진행하면 전반적인 기능을 빠르게 도출하고 팀 간 업무 맥락을 공유하는 데 큰 도움이 된다는 건 이미 검증된 방법론입니다.

방법 4. 팀 전체가 함께 스파이크(실험)를 하는 방식

스파이크(Spike)는 불확실성을 줄이기 위해 짧게 실험적으로 탐색하는 활동이에요. 코드와 테스트를 포함해, 팀이 함께 학습하며 문제를 이해해가는 방식입니다.

요즘은 생성형 AI를 활용해 빠르게 프로토타입을 만들고 아이디어를 검증하는 팀도 많아졌죠. 속도는 확실히 빨라졌어요. 하지만 로스만은 AI가 생성한 코드에 대해서는 장기적으로 신중해야 한다고 조언합니다.

어떤 도구를 쓰든 핵심은 같습니다. 팀 전체가 함께 배우고, 작은 단위로 가치를 전달하고, 고객 반응을 함께 평가하는 것. 이게 빠져 있으면 아무리 좋은 도구도 소용없어요.

왜 반드시 '팀으로' 해야 하나요?

로스만이 4가지 방법을 이야기하면서 반복적으로 강조하는 말이 있어요. 바로 "as a team", 팀으로서입니다.

혼자 탐색하고 혼자 결정하면, 나머지 팀원들은 항상 따라잡아야 하는 처지가 돼요. 반면 팀이 함께 학습하면 별도의 동기화가 필요 없습니다. 모두가 같은 맥락을 갖고, 진행 중인 작업은 줄어들고, 결과적으로 제품의 사이클 타임도 빨라지죠.

국내에서도 PO가 백로그를 혼자 관리하는 전통적인 방식의 한계는 이미 많은 실무자들이 경험하고 있어요. PO가 직접 실무를 담당하지 않는 경우가 많기 때문에 백로그가 세밀하게 세분화되기 어렵고, PO가 생각한 작업 규모와 실무자가 생각한 규모가 다를 때가 너무 많거든요.

그래서 좋은 백로그는 혼자 만드는 게 아니라, 팀이 함께 만드는 겁니다.

PO가 가장 놓치는 것: 백로그는 설계도다

백로그는 단순히 해야 할 일의 목록이 아니에요. 제품이 어떤 고객의 어떤 문제를 해결할 것인지를 담은 설계도입니다.

그 설계도가 모호하면, 팀은 매 스프린트마다 방향을 잃게 됩니다. 불확실함을 해결해줄 기준 없이 스프린트를 돌리면 즉흥적으로 업무가 추가되고, 중간에 새 작업이 끼어들고, 결국 주먹구구식으로 일하는 팀이 되어버리죠.

형성 작업에 시간을 투자하는 것, 팀이 함께 문제를 이해하는 시간을 갖는 것. 이게 결국 가장 빠른 지름길입니다.

마무리

백로그 형성은 선택이 아니라 필수입니다. 시니어 탐색, 개인 선행 탐색, 워크숍 정의, 팀 스파이크 중 어떤 방식을 택하든, 핵심은 팀 전체가 같은 맥락을 공유하는 것에 있어요.

지금 여러분의 백로그, 팀원이 아이템을 열자마자 바로 시작할 수 있는 상태인가요? 딱 한 번만 돌아보세요. 그 점검 하나가 다음 스프린트를 완전히 바꿔놓을 수 있습니다.