애자일이 '빨리빨리'가 되어버린 현실. 돌파구는?
'속도'라는 함정에 빠진 팀을 구하기 위한 새로운 PRD와 리뷰 문화
"이번 스프린트도 정신없었네요. 그래도 배포는 했습니다."
개발팀과 회고를 할 때마다 묘한 찝찝함이 남을 때가 있었습니다.
우리는 분명 '애자일(Agile)'하게 일하고 있습니다. 2주 단위로 스프린트를 돌고, 매일 아침 데일리 스크럼을 하죠.
그런데 왜 우리는 항상 쫓기는 기분일까요? 왜 "고객에게 어떤 가치를 줬는가"보다 "제시간에 기능을 다 만들었는가"에 더 집착하게 되었을까요?
저는 이 지점을 '애자일의 원죄'라고 부르기로 했습니다.
오늘은 제가 회사에서 제안했던, '무늬만 애자일'인 상황을 타파하고 진짜 '가치'를 만들기 위해 도입한 새로운 PRD 방식과 일하는 문화(Shape Up)에 대한 이야기를 나눠보려 합니다.
우리가 겪는 '가짜 애자일'의 늪
혹시 이런 경험 있으세요?
애자일의 원래 취지는 '고객에게 가치를 더 빠르고 작게 전달하자'였습니다. 그런데 현장에서는 이 철학이 미묘하게 변질되곤 합니다. 가치라는 건 추상적이고, '반복 주기(Iteration)'는 눈에 보이기 때문이죠.
결국 많은 조직에서 애자일은 '고강도 고빈도의 워터폴(Waterfall)'이 되어버립니다.
기획자가 기획을 던지고, 디자이너가 쳐내고, 개발자가 허겁지겁 코딩하는 그 과정을 2주마다 반복하는 것이죠. 성공의 기준은 오직 '속도'가 되어버리고요.
이런 상황이 반복되면 팀원들은 지칩니다. "이게 정말 고객한테 필요한 거야?"라는 질문을 던질 시간조차 사치로 느껴지니까요.
'언제까지'가 아니라 '얼마만큼'을 묻다
이 문제를 해결하기 위해 제가 주목한 것은 베이스캠프(Basecamp)사의 'Shape Up' 방법론이었습니다.
핵심은 관점의 전환입니다. 우리는 보통 기능을 만들 때 이렇게 묻습니다.
"이거 만드는 데 얼마나 걸려요? (Estimate)"
하지만 Shape Up은 이렇게 묻습니다.
"이 기능은 얼마만큼의 시간을 투자할 가치가 있나요? (Appetite)"
이 차이는 엄청납니다.
전자가 개발자에게 책임을 떠넘기는 질문이라면, 후자는 기획자와 비즈니스 결정권자가 투자의 관점에서 책임을 지는 질문입니다.
"이 기능은 딱 4주만 투자할 가치가 있어. 그 안에 안 되면 범위를 줄여야 해."라고 선언하는 것이죠.
이것을 '식욕(Appetite, 욕구)'이라고 부릅니다
기획자의 진짜 역할: '모양 잡기(Shaping)'
그렇다면 PM인 저는 무엇을 해야 할까요?
개발자에게 "일단 되게 해주세요"라고 던지거나, 반대로 와이어프레임을 픽셀 단위까지 그려서 "이대로 만들어주세요"라고 하는 것 모두 정답이 아니었습니다.
제가 제안한 새로운 역할은
'Shaping(쉐이핑)'입니다.
추상적인 아이디어를 구체적인 솔루션의 '경계선'으로 만들어주는 작업이죠. 너무 헐겁지도, 너무 빡빡하지도 않게 말이죠.
저는 이를 위해 사내 PRD 양식을 완전히 뜯어고쳤습니다. 기존의 기능 명세서 대신, 아래의 4가지 핵심 질문에 답하는 문서로 바꿨습니다.
1. Context (맥락)
"왜 이걸 해야 하는가?"에 대한 답입니다. 단순히 "로그인 기능 추가"가 아니라, "사용자가 재방문 시 이탈하는 것을 막기 위해"라는 비즈니스적 배경을 설명합니다.
2. Appetite (투자 의지)
앞서 말한 시간 예산입니다. "최대 2주" 혹은 "6주(Big Batch)"처럼 우리가 감당할 수 있는 리스크의 총량을 정합니다.
3. Boundaries (경계)
여기가 핵심입니다. 솔루션의 윤곽을 잡습니다. UI를 그리는 게 아닙니다. "이 기능은 반드시 포함되어야 하고, 저 기능은 이번엔 절대 하지 않는다(No-Gos)"라는 경계를 명확히 긋는 것입니다.
4. Rabbit Holes (토끼굴, 잠재적 위험)
개발하다가 빠지기 쉬운 함정을 미리 찾아냅니다. "기술적으로 이 부분은 연동이 까다로우니, 차라리 수동 처리를 고려하자"는 식으로 불확실성을 미리 제거합니다.
리뷰 문화의 변화: 검사가 아닌 '이해'
문서를 바꿨으니, 리뷰하는 방식도 바뀌어야겠죠?
기존의 기획 리뷰가 "빠진 기능 없나?"를 검사하는 자리였다면, 새로운 리뷰는 "이 제약 조건 안에서 우리가 해결할 수 있을까?"를 논의하는 자리가 되었습니다
제가 팀원들에게 제안한 리뷰의 원칙은 간단합니다.
1. 비동기 리뷰: 굳이 다 같이 회의실에 모여서 문서를 낭독하지 맙시다. 각자 읽고 코멘트를 답니다.
2. 싱크 미팅: 코멘트로 해결 안 된 '쟁점'만 모아서 짧고 굵게 이야기합니다.
이렇게 하니, 개발자분들은 "무조건 다 만들어야 한다"는 압박에서 벗어나 "주어진 시간 안에 최선의 방법을 찾자"는 크리에이티브한 고민을 하기 시작했습니다.
마치며: 결국 PM은 '불확실성'과 싸우는 사람
이 새로운 시도가 회사에 정착하려면 꽤 오랜 시간이 걸릴 겁니다. 시행착오도 겪겠죠.
하지만 한 가지 확실한 건 있습니다.
기획서(PRD)는 개발자에게 일을 시키기 위한 지시서가 아닙니다.
그것은 우리가 해결하려는 문제의 불확실성을 줄이고, 팀이 안전하게 몰입할 수 있는 울타리를 쳐주는 '전략 문서'여야 합니다.
혹시 여러분의 팀도 '속도'라는 단어에 갇혀 지쳐가고 있진 않나요?
그렇다면 한 번쯤 멈춰서 물어보셨으면 좋겠습니다.
"우리는 지금 모양(Shape)을 잡고 있나요, 아니면 그냥 달리고 있나요?"
[함께 읽으면 좋은 자료]
> Ryan Singer, Shape Up (Basecamp의 제품 개발 방법론)
> Amazon 6-Pager (서술형 문서 문화)
