스필오버

Spillover

개념

이번 주기에 끝내기로 했지만 마치지 못해 다음 주기로 넘어간 작업으로, 계획과 실제가 얼마나 벌어졌는지를 보여 줍니다.

등장 배경

고정 길이 주기로 일한다는 것은 주기가 끝나는 날에 끝난 것과 끝나지 않은 것이 갈린다는 뜻입니다. 결과물을 내놓기로 한 고정 길이 작업 주기인 스프린트가 그 틀입니다.

문제는 그 경계에서 말이 흐려지는 데 있었습니다. 주기 마지막 날 회의에서 남은 항목을 물으면 거의 다 됐다는 답이 돌아옵니다. 거의라는 말에는 기준이 없으니 그 항목은 다음 주기로 조용히 넘어가고, 다음 주기 마지막 날에도 같은 답이 돌아옵니다. 한 항목이 세 주기째 진행 중인 상태로 남아 있고, 그동안 보고서에는 매주 90퍼센트라고 적혀 있습니다.

이렇게 되면 주기를 나눈 이유가 사라집니다. 주기별로 얼마를 끝내는지 세서 다음 계획의 근거로 쓰겠다는 것이 목적이었는데, 끝났는지가 흐릿하면 셀 수 있는 것이 없습니다. 계획은 늘 맞은 것처럼 보이고 실제로 나가는 결과물은 줄어듭니다.

스필오버는 그 흐릿한 자리에 이름을 붙여 세게 만든 말입니다. 넘어간 작업을 넘어간 작업이라고 부르고 개수와 크기를 기록하면, 계획이 실제보다 얼마나 앞서 있었는지가 숫자로 남습니다.

작동 방식

주기가 끝나는 순간에 항목을 둘로 가르는 것에서 시작합니다. 기준은 팀이 미리 합의한 완료 정의이고, 보통 코드 리뷰를 통과하고 테스트가 돌고 운영에 올라간 상태까지를 말합니다.

  1. 완료 정의를 채우지 못한 항목을 따로 모읍니다. 개발은 끝났지만 검수가 남은 것도 여기 들어옵니다.
  2. 그 항목의 점수를 0으로 처리합니다. 8짜리 작업을 90퍼센트 했다고 7점을 주면 매 주기 숫자가 실제보다 높게 잡히고, 그 부푼 숫자로 세운 다음 계획이 다시 밀립니다. 넘어간 항목은 다음 주기에 완료될 때 8점을 온전히 받습니다.
  3. 넘긴 항목의 개수와 점수 합을 적어 둡니다. 담았던 점수 대비 넘어간 점수의 비율이 이 주기의 스필오버입니다. 40점을 담아 6점이 넘어갔으면 15퍼센트입니다.
  4. 넘어간 이유를 분류합니다. 크기를 잘못 본 경우, 다른 팀이나 외부 답변을 기다린 경우, 도중에 요구사항이 바뀐 경우, 사람이 빠진 경우, 급한 일이 끼어든 경우로 나눕니다. 이유 없이 건수만 세면 다음 주기에 같은 일이 반복됩니다.
  5. 다음 계획에서 넘어온 항목을 먼저 앉힙니다. 남은 여유만큼만 새 항목을 담습니다. 넘어온 것을 세지 않고 새로 담으면 주기마다 짐이 쌓입니다.

비율을 읽는 기준이 있습니다. 10퍼센트 안쪽은 정상입니다. 주기 단위로 일을 자르다 보면 경계에 걸리는 항목이 늘 생깁니다. 30퍼센트를 넘기면 계획을 조금 줄이는 것으로는 풀리지 않고, 항목을 자르는 크기나 주기 길이 같은 구조를 봐야 합니다. 스필오버가 쌓이면 한 주기에 끝낸 작업량의 평균인 벨로시티가 자동으로 내려가므로, 두 값을 함께 보면 계획이 부풀었는지 실행이 막혔는지가 갈립니다.

쓰이는 곳

세 자리에서 재료로 씁니다.

첫째는 스프린트 플래닝입니다. 이번 주기에 무엇을 할지 정하는 회의인데, 넘어온 항목을 먼저 올려 두고 시작합니다. 지난 세 주기의 스필오버가 계속 20퍼센트대였다면 담는 양 자체를 줄이는 결정이 여기서 나옵니다. 이번 주기에 하기로 뽑아 둔 작업 묶음인 스프린트 백로그의 첫 줄이 넘어온 항목인 경우가 많습니다.

둘째는 회고입니다. 일하는 방식 자체를 돌아보고 고칠 점을 정하는 자리인데, 4번에서 분류해 둔 이유가 그대로 안건이 됩니다. 외부 대기가 세 주기 연속 원인이었다면 고칠 것은 팀의 속도가 아니라 그 대기를 줄이는 절차입니다.

셋째는 동시에 벌여 놓는 양을 정할 때입니다. 동시에 진행할 수 있는 작업 수의 상한인 WIP 제한을 두는 근거가 스필오버에서 나옵니다. 다섯 명이 일곱 개를 동시에 붙들고 있으면 주기 끝에 일곱 개가 모두 80퍼센트로 남습니다. 하나씩 끝내 가면 다섯 개가 끝나고 두 개가 넘어갑니다. 넘어간 양은 줄고 나간 결과물은 늘어납니다.

실무 용례

"이번 주기 스필오버가 6점이라 다음 주기는 34점만 담겠습니다."

넘어온 양을 빼고 새로 담을 양을 정했다는 말입니다.

"이 항목은 부분 점수 없이 0으로 넘깁니다."

거의 됐다는 이유로 점수를 주지 않는다는 원칙을 확인하는 말입니다.

"스필오버 이유가 세 주기 연속 외부 대기입니다. 이건 우리 속도 문제가 아닙니다."

원인이 팀 밖에 있으니 계획을 줄이는 대신 절차를 고치자는 지적입니다.

페이지덱에서는 지현이 스필오버 비율을 주기마다 적기 시작한 뒤에 논의의 모양이 바뀌었습니다. 그전에는 마지막 날 회의에서 남은 항목을 하나씩 짚으며 얼마나 남았는지를 물었고, 답은 대체로 거의 다 됐다는 말이었습니다. 비율을 세기 시작한 첫 세 주기는 각각 28퍼센트, 31퍼센트, 24퍼센트였습니다.

이유를 분류해 보니 절반이 크기 오판이었고 나머지가 외부 대기였습니다. 크기 오판에 대해서는 8점 이상 항목을 계획 단계에서 쪼개기로 했고, 외부 대기는 태오가 다른 팀 요청을 주기 시작 전에 미리 보내는 쪽으로 바꿨습니다. 넉 달 뒤 비율은 9퍼센트에서 13퍼센트 사이로 내려왔습니다.

흔한 오해

스필오버가 0이어야 잘하는 팀이라고 읽는 경우가 가장 많습니다. 넘어간 것이 없으면 계획대로 됐다는 뜻이니 자연스러운 오해입니다. 그런데 0을 만드는 방법은 대개 둘입니다. 담는 양을 아주 적게 잡거나, 마지막 날에 완료 정의를 느슨하게 적용해 끝난 것으로 처리하는 것입니다. 앞쪽은 팀이 할 수 있는 것보다 적게 하는 상태이고, 뒤쪽은 검수와 테스트가 빠진 것이 완료로 기록되는 상태입니다. 몇 달 뒤 두 번째 경우는 운영 장애로 돌아옵니다.

넘어간 작업을 개인의 성실함 문제로 읽는 것도 흔합니다. 이름 옆에 담당자가 적혀 있으니 그렇게 보입니다. 하지만 분류해 보면 크기를 잘못 본 경우와 외부를 기다린 경우가 대부분이고, 둘 다 계획하는 자리와 절차의 문제입니다. 개인에게 원인을 돌리면 다음 주기부터 사람들은 넘어가지 않을 만큼만 담거나 거의 다 됐다고 말하는 쪽으로 움직이고, 그 순간 이 값은 재는 기능을 잃습니다.

같이 보면 좋은 페이지

  • 스크럼

    이 현상이 어느 틀 안에서 세어지는지 먼저 봅니다

  • 개발팀

    넘어간 작업을 실제로 이어 받는 구성원입니다

마지막 업데이트 2026-09-16