14장 — 언제 멈출지 결정하라 (Decide When to Stop)

한 줄 요약

제때 출시한다는 것은 불완전한 것을 출시한다는 뜻이다. 이상과 비교해 올려다보지 말고 고객의 현재 상태(baseline)와 비교해 내려다보며, 스코프 해머링(scope hammering)으로 범위를 계속 두들겨 타임박스에 맞춘다.

핵심 내용

베이스라인과 비교하라 (Compare to baseline)

디자이너와 프로그래머는 어디에 있는 버튼이든 최선을 다하고 싶어 한다. 자부심은 품질과 사기에 중요하지만 과녁을 잘 잡아야 한다. 완벽한 이상과 비교하면 영원히 도달할 수 없다. 대신 비교 기준을 아래로 옮긴다 — 고객이 이 기능 없이 오늘 이 문제를 어떻게 푸는가? 이 기능이 없애줄 짜증나는 우회로는 무엇인가? 디자인 A/B를 고민하느라 고객을 얼마나 더 기다리게 할 것인가? 지금까지의 작업이 현재 대안보다 낫다는 걸 보면 결정할 동기가 생긴다. 절대 충분하지 않다가 아니라 지금 그들이 가진 것보다 낫다의 관점이다.

한계가 트레이드오프를 만든다 (Limits motivate trade-offs)

6주 베팅에는 서킷 브레이커가 있다 — 일이 끝나지 않으면 프로젝트는 그대로 종료된다. 이 강제가 팀이 트레이드오프를 하게 만든다. “이게 더 낫지 않을까?”라는 생각이나 새 엣지 케이스가 나오면, 먼저 이걸 할 시간이 있는가를 자문해야 한다. 우리는 스스로 일거리를 만들어 낸다. 새로 생긴 일은 필요하다고 받아들이기 전에 먼저 의심해야 한다.

스코프는 잔디처럼 자란다 (Scope grows like grass)

스코프 크리프는 나쁜 클라이언트·매니저·프로그래머의 잘못이 아니라 자연 현상이다. 프로젝트는 거시 수준에서 불투명해서 일에 들어가야만 예상 못 한 복잡성과 고칠 거리가 보인다. 모든 프로젝트에는 필요 없는 스코프가 가득하다 — 모든 부분이 똑같이 다듬어질 필요도, 모든 유스케이스가 똑같이 중요할 이유도 없다. 자라는 걸 막으려 하지 말고, 팀에게 계속 쳐낼 도구·권한·책임을 주어라.

스코프 커팅은 품질 저하가 아니다 (Cutting scope isn’t lowering quality)

무엇을 어디까지 실행할지 골라내는 것은 제품에 구멍을 내지 않는다. 선택이 제품을 더 낫게 만든다 — 다른 것 대신 어떤 것을 더 잘하게 만들고, 핵심과 주변을 구분하는 것이 경쟁 공간에서 제품을 차별화한다. 가변 스코프는 품질 희생이 아니다. 코드·비주얼·카피·인터랙션 성능의 품질에는 극도로 까다롭되, 어떤 것이 실제로 바늘을 움직이고 핵심 유스케이스에 차이를 만드는지를 묻는 것이다.

스코프 해머링 (Scope hammering)

자른다(cutting)보다 강한 말로, 타임박스에 맞을 때까지 반복해서 두들기는 힘을 담아 해머링이라 부른다. 고치고 더하고 개선할 거리가 나올 때마다 묻는다. 이게 must-have인가? 없이 출시할 수 있나? 안 하면 무슨 일이 생기나? 새 문제인가, 고객이 이미 감수해 온 기존 문제인가? 일어날 확률과 실제 영향은? 모두가 쓰는 핵심인가 엣지 케이스인가? 그 유스케이스가 목표 고객과 정렬돼 있나? 고정 마감이 이 질문들을 하게 만들고, 가변 스코프가 그 답대로 행동하게 해준다. must-have는 스코프의 태스크로 남고 그것이 끝나야 스코프가 done이다. nice-to-have는 틸드 표시를 달고 done 처리된 스코프에 남을 수 있다 — 시간이 남으면 하고 없으면 자르며, 대개 영영 만들어지지 않는다. nice-to-have로 표시하는 행위 자체가 스코프 해머링이다.

QA는 가장자리를 위한 것 (QA is for the edges)

Basecamp은 수백만 사용자 규모에 QA가 1명이다. QA는 사이클 후반에 들어와 핵심 기능 바깥의 엣지 케이스를 사냥한다. 가능한 이유는 디자이너와 프로그래머가 기본 품질을 스스로 책임지기 때문이다 — 프로그래머는 자기 테스트를 직접 쓰고, 팀은 셰이핑된 대로 동작하는지 함께 확인한다. QA는 모든 작업이 통과해야 하는 게이트가 아니라 레벨업이다. QA가 발견한 이슈는 기본적으로 전부 nice-to-have이고, 팀이 심각도와 남은 시간에 따라 일부만 must-have로 승격해 해당 스코프의 리스트로 옮긴다 — 그래야 그 이슈가 해결돼야 스코프가 done임이 보인다. 코드 리뷰도 같다. 리뷰를 기다리지 않고 출시할 수 있으며, 매번 거치는 절차가 아니라 시간이 될 때의 학습 기회다.

프로젝트를 연장할 때 (When to extend a project)

아주 드물게 마감을 넘긴 프로젝트를 몇 주 연장한다. 조건은 두 가지 — 남은 태스크가 모든 스코프 해머링을 견뎌낸 진짜 must-have일 것, 그리고 남은 일이 전부 내리막일 것(풀리지 않은 문제도 열린 질문도 없을 것). 사이클 끝에 오르막이 남았다는 것은 셰이핑의 실수나 콘셉트의 구멍을 뜻하며, 미지수에 더 베팅하는 것은 너무 위험하다. 그런 프로젝트는 셰이핑 단계로 되돌리고 다음 사이클엔 다른 것을 한다. 조건이 맞더라도 대개는 애피타이트를 지키는 규율을 선호한다. 보통 2주 쿨다운이 must-have가 약간 넘친 팀에게 충분한 여유가 되지만, 습관이 되면 셰이핑 문제거나 팀 퍼포먼스 문제다.

실무 포인트

출시 판단 기준을 이상적인 완성형이 아니라 고객의 현재 대안(baseline)과의 비교로 잡는다.
새 작업·엣지 케이스가 나올 때마다 스코프 해머링 질문(출시 가능한가, 기존 문제인가, 누가 겪나)을 돌린다.
must-have만 스코프 done의 조건으로 남기고, nice-to-have는 틸드 표시 후 미련 없이 버린다.
QA·코드 리뷰는 게이트가 아니라 레벨업으로 운영하고, QA 이슈는 기본 nice-to-have에서 선별 승격한다.
연장은 남은 일이 전부 must-have이면서 전부 내리막일 때만 검토하고, 오르막이 남았으면 셰이핑으로 되돌린다.