작게보다 끝까지

핵심 질문: 3일짜리로 잘게 쪼갰는데, 왜 2주가 지나도 보여줄 게 없을까?

원글은 쪼개기에 관한 거의 모든 것을 다뤘습니다. Epic→Story→Task, 3일 법칙, 도파민 피드백, 심지어 "너무 잘게 쪼개는 함정"까지 스스로 경고했죠. 그래서 이 보론은 그 자기 경고보다 한 겹 더 안쪽을 봅니다.

원글이 끝내 말하지 않은 게 하나 있습니다. "얼마나 작게" 자를지는 집요하게 가르치지만, "어느 방향으로" 자를지는 한 번도 말하지 않는다는 것. 그런데 실무에서 일이 망가지는 건 조각의 크기가 아니라 조각의 방향입니다.

은수를 다시 부릅니다. 이번엔 PM 은수가 "추천 기능 출시"라는 Epic을 받았습니다. 은수는 자신만만했죠. 이 보론은 은수가 그 Epic을 쪼갠 2주에 관한 이야기입니다. 결론을 먼저 말하면 이렇습니다 — 잘게 쪼개는 것만으로는 부족하다. 각 조각이 끝까지 관통하지 않으면, 완료는 가짜고 진전은 환상이다.

깔끔하게 쪼갰는데, 데모할 게 없다

은수는 "추천 기능 출시" Epic을 원글이 시킨 대로 분해했습니다. 결과물을 정의하고, 단계를 나열하고, 각 단계를 3일 이내 Task로 잘랐죠. 보드는 아름다웠습니다.

(은수의 1차 분해)

Task A: 추천 알고리즘 API 개발 (3일)

Task B: 추천 결과 UI 컴포넌트 (2일)

Task C: 노출/클릭 로깅 이벤트 (2일)

Task D: 어드민 추천 설정 화면 (3일)

Task E: A/B 테스트 분기 처리 (2일)

3일을 넘는 Task가 하나도 없었습니다. 첫 주에 도현(개발자)이 Task A를 끝냈고, 둘은 체크박스를 채우며 도파민을 즐겼습니다. 진전의 원리가 작동하는 것 같았죠. 둘째 주, A·B·C가 "완료" 칸에 가 있었습니다.

그리고 스프린트 중간 데모 날, 팀장이 말했습니다. "한번 보여줘 봐요."

은수는 보여줄 게 없었습니다. 추천 API는 됩니다. UI 컴포넌트도 따로 띄우면 렌더링됩니다. 로깅도 붙었고요. 그런데 한 명의 유저가 앱을 열어서 추천 하나를 실제로 받아보는 길이, 아직 어디에도 없었습니다. 레이어는 다 쌓였는데, 그 레이어들을 끝까지 꿰는 줄기가 없었던 거죠.

도현이 짚었습니다. "우리, 벽돌은 다 구웠는데 아직 벽이 한 장도 안 섰어요."

가짜 완료의 정체 — 수평으로 잘랐기 때문

은수의 분해를 다시 보세요. A는 API 레이어, B는 UI 레이어, C는 로깅 레이어, D는 어드민 레이어. 전부 기술 레이어를 따라 가로로 자른 것입니다. 이걸 수평 슬라이싱(horizontal slicing)이라고 합니다.

수평 슬라이싱의 치명적 특징은, 각 조각이 혼자서는 아무 가치가 없다는 겁니다. API만 끝난 상태는 유저에게 0이고, UI만 끝난 상태도 0입니다. 가치는 모든 레이어가 다 끝나서 연결되는 마지막 순간에 한꺼번에 생깁니다. 그전까지의 "완료"는 전부 가짜 완료예요.

여기서 원글이 자기모순에 빠집니다. 원글이 쪼개기의 핵심 동력으로 내세운 게 아마빌레의 진전의 원리—"의미 있는(meaningful) 일에서의 진전이 동기를 만든다"—였죠. 그런데 레이어 하나를 끝낸 건 의미 있는 진전이 아닙니다. 유저에게 아무것도 바뀌지 않았으니까요.

도파민은 터지는데 가치는 0. 원글이 곳곳에 배치하라던 도파민 주유소가, 실은 헛불을 켜고 있었던 겁니다. 체크박스 8개를 채우는 동안 은수가 느낀 뿌듯함은, 진전이 아니라 진전의 착각이었습니다.

원글의 "3일 법칙"은 옳습니다. 다만 그건 크기 기준일 뿐, 방향을 보장하지 않습니다. 3일짜리 수평 조각 다섯 개보다, 5일짜리라도 끝까지 통하는 수직 조각 하나가 비교할 수 없이 낫습니다.