스프린트는 기간이 아니라 효용을 자른다

마감이 3주 남은 기능이 하나 있었다. 스프린트를 셋으로 나눴다. 1주차는 설계, 2주차는 화면, 3주차는 개발과 QA. 일정표는 깔끔하게 세 칸으로 잘렸고 매주 계획대로 끝났다. 문제는 3주 내내 아무도 그 기능을 써보지 못했다는 거다. 실제로 돌아가는 화면을 처음 만져본 건 마지막 주 목요일이었다.

PM: “어, 이거 저희가 생각한 거랑 다른데요.”

그때 남은 시간은 하루였다. 3주를 셋으로 잘랐는데 정작 배운 건 마지막 하루에 몰려 있었다. 이건 스프린트가 아니다. 3주짜리 폭포수를 상자 세 개에 나눠 담았을 뿐이다. 일정은 잘렸는데 효용은 하나도 안 잘렸으니까.

그래서 나는 스프린트를 이렇게 본다. 기간을 자르는 일이 아니라 효용을 자르는 일이다. 조각 하나가 끝날 때마다 누군가 실제로 쓸 수 있는 것이 조금씩 늘어나야 한다.

한 번에 푸는 계획에 깔린 전제

한 번에 푸는 쪽이 더 빨라 보이는 건 사실이다. 어설픈 걸 중간에 내보내면 욕먹을 것 같고, 나눠 만들면 같은 자리를 두 번 건드리는 낭비처럼 느껴진다. 나도 오래 그렇게 만들었다.

그런데 한 번에 푸는 계획에는 조용한 전제가 하나 깔려 있다. 지금 우리가 아는 게 맞다는 전제다. 6주 뒤에 무엇이 필요할지, 사람들이 그 기능을 어떻게 쓸지, 어디서 막힐지를 지금 앉은 자리에서 다 안다는 가정 위에서만 성립한다.

실제로는 그렇지 않다. 계획은 그 시점에 가진 정보로 세운 가설이고, 그 정보 대부분은 만들면서 생긴다. 화면을 붙여봐야 흐름이 이상한 걸 알고, 사람들이 써봐야 아무도 안 쓰는 기능이 뭔지 안다. 착수 시점에 다 설계하는 게 왜 원리적으로 안 되는지는 kludge 이야기에서 따로 다뤘다. 요점만 말하면, 정답은 아직 세상에 없다. 만들면서 생겨난다.

그러니 한 번에 푼다는 건 자신감의 문제가 아니다. 만들면서 생길 정보를 안 쓰겠다는 선택이다. 6주치 계획을 6주 내내 그대로 밀고 가겠다는 건 그 6주 동안 계획을 한 번도 안 고치겠다는 말과 같다.

두 방식은 곡선 모양이 다르다

두 방식은 결과물의 완성도가 아니라 곡선 모양이 다르다. 같은 6주짜리 일을 한 번에 푸는 쪽과 조각내는 쪽으로 나눠서, 매주 사용자가 실제로 손에 쥐는 것이 얼마나 되는지를 그려보면 이렇게 된다.

두 선은 6주차에 같은 높이에서 만난다. 그래서 마지막 칸만 보면 두 방식이 똑같아 보인다. 차이는 두 군데에 있다.

하나는 선 아래 면적이다. 조각내는 쪽은 1주차부터 뭔가를 쓰고 있었고 한 번에 푸는 쪽은 5주 동안 0이었다. 같은 자리에 도착했더라도 그 5주 동안 누군가에게 쓰인 쪽은 하나뿐이다. 다른 하나는 더 중요하다. 조각내는 쪽은 매주 끝에 방향을 틀 기회가 한 번씩 있었다. 1주차 조각을 내보내고 사람들이 안 쓰면 2주차 계획을 그 자리에서 고칠 수 있다. 한 번에 푸는 쪽은 그 기회가 6주차 금요일에 딱 한 번 온다.

한 번에 푸는 쪽의 마지막 높이는 확정된 값도 아니다. 아무도 안 써봤으니까. 절반일 수도 0일 수도 있다는 걸 6주가 다 지나서야 알게 된다. 두 곡선은 계획서 위에서만 만난다.

층으로 자르면 조각이 아니다

여기까지 동의해도 실전에서는 앞의 3주짜리처럼 잘리기 쉽다. 자를 줄 몰라서가 아니라 자르는 방향이 잘못돼서다.

케이크를 생각해보자. 3층짜리 케이크를 층으로 자르면 스펀지 한 접시, 크림 한 접시, 또 스펀지 한 접시가 나온다. 셋을 다 모으면 케이크지만 접시 하나만 받은 사람은 케이크를 먹은 게 아니다. 세로로 자르면 다르다. 아무리 얇게 잘라도 그 한 조각 안에 스펀지와 크림이 다 들어 있다. 작을 뿐 케이크다.

제품에서 층은 공정이다. 1주차 설계, 2주차 화면, 3주차 개발. 또는 1주차 데이터 구조, 2주차 서버, 3주차 화면. 매주 뭔가는 끝나지만 끝나는 게 층이라서 마지막 층이 얹히기 전까지는 아무도 아무것도 못 한다. 맨 앞에 적은 3주짜리가 정확히 이 모양이었다.

세로로 자른다는 건 한 사람이 처음부터 끝까지 한 바퀴 돌 수 있는 가장 얇은 길을 하나 내는 것이다. 설계도 하고 화면도 그리고 서버도 붙이는데 대신 그 길 하나만. 폭은 좁아도 끝에서 끝까지 이어져 있으니 누군가는 그걸로 실제 일을 해낸다.

Henrik Kniberg가 그린 그림이 이 대비를 한 장으로 보여준다.Henrik Kniberg, Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable, blog.crisp.se, 2016년 1월 25일. 2026년 8월에 원문을 열어 두 줄의 구성과 아래 인용한 고객의 말을 확인했다. 그림 자체는 이 글보다 몇 해 앞서 그렸다고 본인이 밝힌다. 위쪽 줄은 바퀴 하나에서 시작해 자동차에 점점 가까워지다 마지막에 완성차가 되고, 아래쪽 줄에는 스케이트보드, 킥보드, 자전거, 오토바이, 자동차가 놓여 있다. 위쪽 줄에서 첫 조각을 받은 고객은 이렇게 말한다. 나는 자동차를 주문했는데 타이어를 왜 주느냐, 이걸로 뭘 하라는 거냐. 아래쪽 줄에서 첫 조각을 받은 사람은 스케이트보드를 타고 이미 어딘가로 간다. 그리고 여기 언덕이 많아 힘들다고 말해주면 다음 조각이 킥보드가 아닌 것이 될 수도 있다.

얇게 자르되 대충 만들지 않는다

얇게 자른 조각과 대충 만든 물건은 겉보기에 비슷해서 자주 섞인다. 줄이는 건 범위지 완성도가 아니다. 범위를 줄이는 방법은 대체로 세 가지다.

첫째, 대상을 줄인다. 전체 고객이 아니라 한 팀, 한 채널, 한 지역만. 그 한 팀에서 걸리는 문제는 대개 다른 데서도 걸린다.

둘째, 경우의 수를 줄인다. 잘 풀리는 길 하나만 제대로 만들고 나머지 경우는 막아두거나 안내로 넘긴다. 예외 처리는 그 길이 쓸모 있다고 확인된 뒤에 붙여도 늦지 않다.

셋째, 자동화를 뒤로 미룬다. 사용자 눈에는 되는 것처럼 보이는데 뒤에서는 사람이 손으로 처리하는 방식이다. 열 명이 쓸 때는 손으로 감당된다. 그 열 명이 계속 쓰면 그때 자동화한다.

세 가지 다 범위를 깎는다. 반대로 그 좁은 범위 안에서는 완성도를 깎으면 안 된다. 한 팀만 쓰는 기능이라도 그 팀한테는 제대로 돌아가야 한다. 완성도를 지키는 건 결벽이 아니라 조각내기가 작동하기 위한 조건이다. 조각을 내는 목적은 정보를 얻는 것인데 대충 만들면 그 정보가 오염된다. 사람들이 안 쓰고 넘어갔을 때, 필요가 없어서 안 쓴 건지 어설퍼서 못 쓴 건지 구분이 안 되기 때문이다.

내 주장이 깨지는 자리

여기까지가 내 주장이다. 그런데 뜯어보면 걸리는 자리가 세 군데 있다.

첫째, 반쯤 켜면 오히려 손해인 일이 있다. 결제, 로그인, 권한, 데이터 이전, 가격 정책 같은 것들이다. 절반짜리 로그인은 절반의 효용이 아니라 마이너스다. 여기서는 내 기준이 안 선다. 매주 사용자가 쓸 수 있는 것이 늘어야 한다고 해놓고, 이런 자리에서는 다 되기 전까지 아무것도 못 내보내는 게 맞다. 안에서 잘게 잘라 확인하며 갈 수는 있지만 그건 학습을 조각낸 것이지 효용을 조각낸 게 아니다. 다른 주장이라는 걸 인정하고 넘어가는 편이 정직하다. 다만 제품에서 그런 자리가 몇 개인지는 세어볼 만하다. 대개 손에 꼽고 나머지가 훨씬 많다.

둘째, 조각내기 자체에 비용이 든다. 조각마다 릴리스, 회귀 테스트, 안내, 컨텍스트 전환이 붙는다. 조각이 얇아질수록 고정비의 비중이 커진다. 이건 앞의 곡선에도 그대로 걸린다. 고정비를 넣으면 조각내는 쪽 선도 6주차에 같은 높이까지 못 간다. 나는 한 번에 푸는 쪽의 마지막 값만 의심했는데 공평하지 않았다. 조각내는 쪽이 사는 건 총량이 아니라 방향을 틀 기회의 횟수다. 총량으로만 재면 조각내기가 지는 경우도 있다. 그러니 좋은 조각 크기는 무조건 얇은 게 아니라, 그 조각에서 얻는 정보가 고정비보다 클 만큼만 얇은 거다. 이틀짜리로 쪼갰는데 이틀 중 하루를 배포 준비에 쓰고 있다면 너무 얇게 잘랐다.

셋째는 반론이라기보다 경계다. 자르는 것과 방향을 정하는 것은 다른 일이다. 눈앞의 조각만 보고 가다 보면 나중에 통째로 뒤집어야 할 결정을 조각 밑에 깔아두는 수가 있다. 조각내기는 문제를 자르는 방법이지 어디로 갈지를 정해주지 않는다. 방향은 크게 보고 가는 길만 잘게 밟는다.

누가 무엇을 할 수 있게 되나

스프린트가 제대로 돌고 있는지는 두 가지로 드러난다.

하나, 보여줄 게 진행률뿐이다. 스프린트 끝에 데모할 게 없고 몇 퍼센트 진행됐다는 숫자만 있으면 그 스프린트는 효용을 안 자른 것이다.

둘, 계획이 한 번도 안 바뀐다. 조각을 낸 이유는 조각마다 배운 걸로 다음 조각을 고치려는 건데, 6주 전에 그린 계획이 6주 동안 한 번도 안 바뀌었다면 조각낼 이유가 애초에 없었다. 일정표를 여섯 칸으로 그린 것이지 스프린트가 아니다.

PM: “이번 스프린트에 뭐가 나와요?”

개발자: “설정 쪽 서버 작업이 끝나요.”

PM: “그럼 그게 끝나면 누가 뭘 할 수 있게 되는데요?”

개발자: “그건 다음 스프린트에 화면이 붙어야…”

PM의 두 번째 질문이 스프린트를 판별한다. 이번 조각이 끝나면 누가 무엇을 할 수 있게 되나. 답이 사용자의 말로 한 문장이 안 나오면 공정을 자른 거지 효용을 자른 게 아니다. 스토리 포인트 글에서 나는 추정을 정교하게 다듬는 것보다 쪼개는 게 예측에 크게 기여한다고 썼다. 그 글의 쪼개기는 추정을 맞히려는 것이고 이 글의 쪼개기는 배우려는 것인데, 공정으로 자르면 둘 다 안 된다.

마무리

제품을 만드는 게 완성이라는 지점까지 가는 일이라면 한 번에 푸는 쪽이 맞다. 도착점이 정해져 있고 거기 닿으면 끝나니까. 그런데 제품은 완성되지 않는다. 매번 조금 더 쓸모 있어질 뿐이다. 그렇게 보면 질문이 바뀐다. 언제 다 끝나느냐가 아니라 이번 주에 무엇이 얼마나 좋아졌느냐다.

맨 앞의 3주짜리로 돌아가 보자. 그때 필요했던 건 더 정확한 일정표가 아니었다. 1주차 끝에 PM이 뭐라도 만져볼 수 있게 하는 것이었다. 설계 문서 대신, 한 사람이 한 바퀴 돌 수 있는 가장 얇은 길 하나. 그랬다면 목요일에 나온 그 말이 첫 주 금요일에 나왔을 거고, 그때는 고칠 시간이 아직 2주 남아 있었다.