스코프 크리프

일정이 밀린 이유를 아무도 짚지 못하는 상황이 반복됐습니다. 2주로 잡은 일이 6주가 되어 끝났는데, 회고에서 왜 그랬는지 물으면 답이 나오지 않습니다. 하루 만에 4주가 늘어난 날이 없기 때문입니다. 반나절짜리와 이틀짜리 요청이 열 번 남짓 얹혔고, 매번 "이건 작으니까" 라는 말과 함께 들어왔습니다.

한 건 한 건은 실제로 작습니다. 2주 추정에 붙는 오차가 사흘쯤이라면, 반나절짜리 요청은 그 오차 안에 묻혀 일정표에 흔적을 남기지 않습니다. 열 번째 요청까지 같은 방식으로 묻히고, 그 사이 일정은 오차가 아니라 세 배로 벌어져 있습니다. 늘어난 양을 재려면 처음 합의한 목록과 지금 만들고 있는 것을 나란히 놓아야 하는데, 그 비교를 매주 하는 팀은 드뭅니다.

그래서 이 현상에 이름이 붙었습니다. 이름이 있으면 진행 중에 지목할 수 있습니다. "지금 스코프 크리프가 일어나는 것 같습니다" 라는 한 마디가 개인을 탓하는 말이 아니라 절차를 다시 보자는 신호로 읽히고, 요청을 받느냐 마느냐가 아니라 받으면서 무엇을 함께 고칠지의 논의로 넘어갑니다.

네 단계가 돌면서 누적됩니다. 한 바퀴 안에서는 아무 문제가 없어 보이는 것이 이 현상의 핵심입니다.

1. 작은 요청이 들어옵니다. 만드는 도중에 누가 지나가며 "목록 정렬만 추가하면 되지 않아요" 라고 묻는 식입니다.
2. 거절할 근거가 없습니다. 범위 목록에 없는 항목이지만, 하지 않기로 명시한 범위 밖 칸에도 없습니다. 둘 다에 없는 요청은 담당자의 판단에 맡겨집니다.
3. 받습니다. 반나절이면 되는 일이라 일정 협의를 다시 열 만한 크기가 아니고, 문서도 고치지 않습니다.
4. 같은 일이 반복됩니다. 반나절이 여덟 번이면 나흘이고, 그 나흘은 어느 항목에도 적혀 있지 않아서, 일정이 밀린 뒤에 세어 볼 때야 보입니다.

늘어나는 경로는 셋인데 눈에 띄는 정도가 다릅니다. 첫째는 없던 기능이 붙는 경우입니다. 쿠폰 입력칸을 만들던 일에 관리자 발급 화면이 들어오는 식이라 가장 알아보기 쉽습니다. 둘째는 있던 항목의 깊이가 자라는 경우입니다. 같은 "쿠폰 코드 확인" 항목인데 만료된 코드, 이미 쓴 코드, 다른 사람 코드까지 처리하게 되면 기능 요구사항이 한 줄에서 여섯 줄로 늘어납니다. 항목 이름이 그대로라서 목록을 봐도 늘어난 것이 보이지 않습니다. 셋째는 품질 기준이 올라가는 경우로, 1초 안에 응답하면 된다고 했던 것을 0.3초로 바꾸는 일이 여기 들어갑니다.

막는 방법은 요청을 거절하는 것이 아니라 요청이 문서를 지나가게 만드는 것입니다. 새로 들어온 것은 그 자리에서 받지 않고 제품 백로그에 넣습니다. 아직 손대지 않은 항목을 순서대로 쌓아 둔 목록이고, 다음 계획을 짤 때 다른 항목들과 함께 순서를 다시 매깁니다. 이번에 꼭 해야 하는 것이면 범위 칸을 고치고 기간이나 사람을 함께 다시 봅니다.

이 말이 실제로 나오는 자리는 셋입니다.

1. 진행 중인 주기의 중간입니다. 스프린트 도중에 담지 않은 항목이 슬며시 들어오면 그날 데일리 회의에서 지목합니다. 시작할 때 합의한 목록이 있어서 비교 대상이 분명한 자리입니다.
2. 문서를 리뷰하는 자리입니다. 범위 밖 칸이 왜 필요하냐는 질문에 대한 답이 이 현상입니다. 안 하기로 한 것을 적는 칸은 나중에 요청을 막기 위해서가 아니라 요청이 들어왔을 때 5분 안에 결론을 내기 위해 있습니다.
3. 회고입니다. 밀린 이유를 설명할 때 쓰는 이름입니다. 여기서는 늘어난 항목을 세어 보는 것이 말보다 값을 합니다.

세 자리 모두 비교 대상이 있어야 성립합니다. 처음 합의한 목록이 문서에 남아 있지 않으면 늘어났다는 말 자체를 꺼낼 수 없고, 손에 남는 것은 밀렸다는 사실뿐입니다.

"이거 원래 범위에 있던 건가요? 지금 스코프 크리프 같아서요."

합의한 목록 밖의 일을 하고 있는 것이 아닌지 확인하는 말입니다.

"한 건은 작은 게 맞는데, 이번 주에 이런 게 다섯 개째입니다."

한 건의 크기가 아니라 누적된 양을 문제로 짚는 말입니다.

"받는 건 가능합니다. 대신 범위 문서 고치고 일정은 다시 잡겠습니다."

요청을 거절하지 않되 절차를 거치게 만드는 답입니다.

페이지덱에서 쿠폰 기능을 만들 때가 그랬습니다. 지현이 2주로 잡고 시작했는데, 첫 주에 수아가 고객사 요청으로 사용 내역 화면을 물었고 반나절이라 받았습니다. 둘째 주에 만료 알림 메일이 붙었고 이것도 하루였습니다. 셋째 주에 태오가 쿠폰 코드 확인 로직의 예외가 여섯 가지로 늘어난 것을 발견했을 때, 남은 일이 처음 목록의 두 배였습니다.

그 주 회고에서 늘어난 항목을 세어 보니 아홉 개였고 합이 11일이었습니다. 아홉 개 중 여덟 개는 문서에 적히지 않은 채 들어와 있었습니다. 그 뒤로 지현은 반나절짜리 요청도 백로그에 먼저 넣는 방식으로 바꿨습니다. 요청을 거절한 것이 아니라, 다음 주기를 계획할 때 다른 항목들과 함께 순서를 보게 만든 것입니다.

요청하는 쪽을 문제로 보는 경우가 많습니다. 일정이 밀린 원인이 밖에서 들어온 요청이니 그렇게 보입니다. 하지만 요청 하나하나는 대개 타당하고, 고객이 실제로 원하는 것이거나 빼면 안 되는 예외입니다. 문제는 요청이 아니라 요청이 일정에 반영되지 않고 통과하는 경로입니다. 요청하는 쪽을 탓하는 방향으로 가면 다음부터는 요청이 사라지는 대신 담당자에게 직접 가는 쪽으로 옮겨 가고, 그러면 문서에 남을 기회조차 없어집니다.

범위가 바뀌는 것 자체를 이 현상으로 부르는 것도 흔합니다. 둘은 다릅니다. 새로 알게 된 사실 때문에 범위를 고치고 기간을 함께 다시 잡았다면 그것은 정상적인 변경입니다. 구분하는 기준은 요청의 크기가 아니라 문서와 일정이 함께 움직였는지입니다. 정상적인 변경은 문서에 흔적을 남기고, 스코프 크리프는 아무 흔적 없이 일정에만 나타납니다. 이 구분을 놓치면 팀은 변경을 나쁜 것으로 취급하게 되고, 명백히 틀린 계획을 그대로 밀고 나가는 쪽으로 기울어집니다.