5장 — 리스크와 래빗홀 (Risks and Rabbit Holes)

원문: Risks and Rabbit Holes — Shape Up

한 줄 요약

셰이핑된 컨셉에 구멍이 하나만 있어도 고정 시간 예산이 무너지므로, 베팅 전에 사용 사례를 슬로모션으로 재생해 rabbit hole(함정)을 찾아 패치하고, 범위 밖(out of bounds)을 선언하고, 기술 전문가의 검증을 거친다.

핵심 내용

리스크의 분포가 다르다

잘 셰이핑된 작업은 확률 분포의 꼬리가 얇다(thin-tailed) — 한 주쯤 늦을 수는 있어도 그 이상 끌 이유가 없다. 반면 기술적 미지수, 안 풀린 디자인 문제, 오해된 상호의존성 같은 rabbit hole이 남아 있으면 오른쪽 꼬리가 길게 늘어져 원래 appetite의 몇 배가 들 수 있다. 팀이 예상 못 한 2주짜리 문제를 만나면 6주 예산의 3분의 1이 그냥 타 버린다. 더 나쁜 건 해법이 아예 없는 문제다 — Basecamp는 홈 화면 재설계 프로젝트에서 “디자이너가 알아서 풀겠지”라고 가정하고 실행 가능한 접근이 존재하는지 셰이핑 단계에서 검증하지 않았다가, 6주 안에 아무도 해법을 못 찾아 프로젝트를 폐기했다. 목표는 독립적이고 잘 이해된 부품들이 알려진 방식으로 조립되는, 최대한 꼬리가 얇은 프로젝트다.

rabbit hole 찾기

요소 탐색이 넓고 빠른 작업이었다면, 이 단계는 느리고 비판적이다. 스케치한 해법을 놓고 사용 사례를 슬로모션으로 재생한다 — 사용자가 시작점에서 끝까지 정확히 어떻게 가는가? 그리고 풀었다고 생각한 부분마다 묻는다: 해 본 적 없는 기술 작업이 필요한가? 부품들이 맞물리는 방식을 가정만 하고 있진 않은가? 우리도 못 떠올린 디자인 해법이 존재한다고 가정하고 있진 않은가? 팀이 걸려 넘어지지 않도록 미리 정해 줘야 할 어려운 결정이 있는가?

사례: 구멍 패치하기

To-Do Groups 프로젝트에서 divider와 loose/grouped 논리는 마음에 들었지만, 완료된 항목을 어떻게 표시할지를 다루지 않았음을 발견했다. 그룹별 하단에 렌더링할까? 기존처럼 리스트 하단에 모으고 divider를 반복할까? 완료 항목 처리를 전면 재고할까? 이건 컨셉의 구멍이었고, 방치하면 깊은 디자인 문제를 마감에 몰린 팀에 떠넘기는 셈이다. 완료 투두 렌더링 변경은 UX·내비게이션·성능에 복잡한 파급이 있음을 경험으로 알기에, 셰이핑 단계에서 해법을 지시했다: 완료 항목은 기존 그대로 두고 각 항목에 그룹 이름만 덧붙인다. 약간 지저분하지만 문제를 극적으로 단순화한다. 사이클 안에서 압박받는 디자이너라면 “스타일을 좀 더 실험하면 되지 않을까” 하며 며칠을 막다른 길에 쓰기 쉽다 — 셰이퍼는 궁극의 디자인이 아니라 기본 품질과 리스크를 생각하며, 프로젝트를 가치 있게 만든 핵심 요소는 지키면서 리스크의 긴 꼬리를 잘라낸다. 이 “패치”는 피치에 명시해 아무도 걸려 넘어지지 않게 한다.

범위 밖 선언 (Declare out of bounds)

팀은 최선을 다하고 싶어서 모든 사용 사례를 필요하다고 여기기 마련이다. 지원하지 않을 케이스를 명시적으로 불러내 appetite 안에 묶어 둔다. 그룹 알림 아이디어의 예: 프로그래머 5명을 하나씩 체크하는 대신 “Programmers”를 클릭해 한번에 선택하는 기능인데, 둘러보니 투두 할당, 챗 멘션 등 적용할 곳이 널려 있었다. 핵심 가치를 “메시지 알림 대상 좁히기”로 정하고 나머지는 전부 out of bounds로 표시했다.

잘라내기 (Cut back)

스케치 단계에서 신났지만 꼭 필요하진 않은 부분도 있다. To-Do Groups의 그룹 색상 코딩이 그랬다 — 페이지가 더 흥미로워 보이고 더 유용할 수도 있지만, 불필요로 표시하고 핵심에서 잘랐다. 팀에 nice-to-have로 언급은 하되, 그것 없이도 가치 있다는 전제에서 모두가 출발한다.

기술 전문가에게 보여주기

글로 쓰기 전, 확신 없는 부분은 코드를 잘 아는 사람에게 검증받는다. 분위기는 우호적 공모 — “생각 중인 게 있는데, 아직 아무한테도 보여줄 건 아니고, 어떻게 생각해?” 함정 질문은 “이거 가능해?”다. 소프트웨어에서 모든 건 가능하지만 공짜인 건 없다 — “X가 6주 안에 가능해?”라고 물어야 전혀 다른 대답이 나온다. appetite를 공유해 프로젝트 크기를 지키는 파트너로 만들고, 커밋 후에 터질 시한폭탄을 함께 사냥한다는 걸 강조한다. 점토를 마르지 않게(keep the clay wet) — 문서나 슬라이드 대신 화이트보드에 컨셉을 처음부터 다시 그려 가며 보여주고, 다 보여준 뒤에야 극적으로 단순화할 아이디어가 있는지 연다.

리스크 제거 완료

해법의 요소 + rabbit hole 패치 + out of bounds 울타리가 갖춰지면, 비공개 셰이핑에서 베팅 테이블로 넘어갈 준비가 된 것이다. 맥락이 적은 사람도 이해하고 평가할 수 있는 형태의 글 — 피치(pitch) — 로 쓴다.

실무 포인트

• 베팅 전에 사용 사례를 슬로모션으로 끝까지 재생해 빠진 조각을 찾는다
• “디자이너/팀이 알아서 풀겠지”라는 가정이 있으면 셰이핑 단계에서 직접 해법을 지시하거나 검증한다
• 발견한 rabbit hole은 트레이드오프를 감수한 패치로 막고, 피치에 명시한다
• 확장 가능한 케이스들은 핵심 하나만 남기고 out of bounds로 선언한다
• 기술 검증은 “가능한가?”가 아니라 “appetite 안에 가능한가?”로 묻는다
• 전문가 리뷰는 문서가 아니라 화이트보드로 — 피드백 받을 여지를 살려 둔다