스프린트라는 단어를 쓰지 않게 된 이유

교과서대로 했는데 왜 느렸을까

처음엔 교과서대로였다. 2주 단위 스프린트, 시작 전날 플래닝, 마지막 날 리뷰와 회고. Jira 티켓은 깔끔하게 정리됐고, 스프린트 번다운 차트도 그럴듯했다. 그런데 몇 달을 돌려보고 나서 이상한 숫자를 마주쳤다. 2주 스프린트 주기에서 실제 "계획·리뷰·회고·플래닝 포커"에 쓰는 시간을 합산했더니 한 스프린트당 약 6~~8시간이 나왔다. 3명 팀 기준으로 18~~24 인시(person-hour)다. 우리 팀 전체 유효 작업 시간이 스프린트당 약 120인시라고 하면, 세리머니만으로 15~20%가 증발하는 구조였다.

이 수치 자체가 문제는 아니다. 스프린트는 원래 "조율 비용"을 낮추기 위한 구조이고, 팀이 크면 그 비용이 정당하다. 하지만 3명이 한 방(또는 슬랙 채널 하나)에 있는 환경에서 2주치 맥락을 동기화하는 데 24인시를 쓰는 건 다른 이야기다. 우리가 스프린트를 버린 것은 게으름이 아니라, 그 비용 대비 우리가 얻는 조율 이득이 너무 낮다는 계산이었다.

결제·정산 현장에서 2주 사이클이 특히 안 맞는 이유

일반 소프트웨어 팀도 스프린트 피로를 겪지만, 결제·정산·자동화를 직접 운영하는 팀은 구조적으로 더 안 맞는다. 이유는 간단하다. 결제 이슈는 스프린트 캘린더를 기다리지 않는다.

실제 시나리오를 하나 들면: PG사가 특정 카드사 빈(BIN) 범위의 응답 코드 체계를 변경했다는 공지가 금요일 오후에 온다. 변경 적용일은 다음 주 화요일이다. 우리 정산 자동화 파이프라인은 해당 응답 코드를 파싱해서 성공/실패를 분류하는 로직이 있다. 이걸 이번 스프린트 플래닝에 넣을까, 다음 스프린트로 넘길까를 논의하는 게 말이 되는가? 안 된다. 화요일까지 반드시 고쳐야 한다.

정산 자동화 파이프라인에서 T+1 마감 시간은 절대 협상 불가다. 월말 세금계산서 일괄 발행, 카드사별 정산 파일 포맷 변경, 환율 API 공급사 점검 공지—이 모든 외부 이벤트는 2주 사이클 밖에서 날아온다. 2주짜리 계획 단위가 있으면 팀은 본능적으로 "이번 스프린트 스코프에 없다"는 방어 논리를 만들기 쉽다. 작은 팀일수록 그 관성이 위험하다.

우리가 실제로 바꾼 것: 숫자와 구조

지금 우리 리듬은 이렇다. 매주 월요일 오전 30분 이내 싱크. 안건은 딱 두 줄이다: "이번 주 반드시 끝낼 것(Must)"과 "여력 되면 할 것(Can)". Must는 최대 3개로 제한한다. 그 이상을 Must로 올리면 그건 Must가 아니라 희망 목록이다.

플래닝 포커, 스프린트 리뷰, 회고는 없앴다. 대신 매주 금요일 오후에 각자 세 줄짜리 비동기 업데이트를 슬랙에 올린다: "완료한 것 / 막힌 것 / 다음 주 넘기는 것". 이 세 줄을 읽으면 팀 전체 맥락이 2분 안에 공유된다. 회의가 필요한 이슈는 그때 별도로 잡는다.

세리머니 절감 시간은 스프린트 대비 한 달 기준 약 12~16인시다. 이 시간을 실제로 어디 썼냐면: 자동화 파이프라인 모니터링 대시보드 고도화, 정산 예외처리 케이스 문서화, PG사 신규 API 연동 PoC. 회의를 줄인 게 아니라 그 시간이 다른 곳으로 간 것이다.

트레이드오프: 버린 것과 얻은 것

이 방식이 만능은 아니다. 솔직하게 쓴다.

버린 것: 스프린트 구조가 주는 "마감 효과"다. 2주 끝에 데모를 해야 한다는 압박은 실제로 작동한다. 우리 주간 리듬에선 그 압박이 옅다. 특히 정확한 마감이 없는 내부 인프라 개선 작업—예를 들어 정산 파이프라인 리팩터링—이 "다음 주 Can"으로 계속 밀리는 현상이 생겼다. 이건 의식적으로 Must에 박아 넣지 않으면 해결이 안 된다.

얻은 것: 외부 이벤트 반응 속도다. PG사 정책 변경, 세금계산서 API 업데이트, 카드사 응답 코드 변경—이런 이슈가 들어오면 다음 월요일 싱크 없이도 당일 Must 리스트를 조정한다. 이게 가능한 건 우리 세 명이 "이번 주 Must가 뭔지" 항상 알고 있기 때문이다. 스프린트 스코프가 없으니 "이건 스프린트 밖이라 넣기 어렵다"는 저항도 없다.

수치로 비교하면: 스프린트 운영 당시 긴급 이슈가 생기면 스프린트 외 작업으로 분류하거나, 다음 스프린트 첫날로 미루는 패턴이 월 평균 2~3회 있었다. 지금은 그 패턴 자체가 없다. 긴급 이슈가 곧 이번 주 Must가 된다.

단어 하나가 만드는 기대치의 무게

"스프린트"라는 단어를 안 쓰게 된 것은 사소해 보이지만, 실제로 팀 내 기대치를 바꿨다. 스프린트라는 단어를 쓰면 그 단어에 붙어 있는 전제들이 함께 들어온다. 플래닝이 있어야 하고, 리뷰가 있어야 하고, 회고가 있어야 한다. 팀원 중 누군가가 스크럼을 알면 그 틀 전체를 기대한다.

우리가 실제 쓰는 언어는 이렇다. "이번 주 Must", "다음 주 Can", "지금 막힌 것". 이 단어들은 어떤 프레임워크도 전제하지 않는다. 그래서 신규 외부 파트너나 협업자가 들어왔을 때 "스크럼은 어떻게 운영해요?"라는 질문 대신 "이번 주 뭐 작업해요?"라는 질문이 먼저 나온다. 설명 비용이 줄었다.

방법론의 이름을 달고 일하는 것과, 지금 어떻게 일하는지를 바로 설명할 수 있는 것은 다르다. 전자는 구조를 빌리는 것이고, 후자는 구조를 소유하는 것이다.

당장 써먹을 수 있는 시사점

이 글을 읽고 "우리도 스프린트 버려야 하나"를 고민 중이라면, 먼저 이 세 가지를 측정해보라.

1. 세리머니 비용을 인시로 계산하라. 플래닝 + 리뷰 + 회고 + 플래닝 포커를 합산해 한 스프린트당 총 인시를 낸다. 팀 전체 유효 작업 인시 대비 비율이 10%를 넘으면 구조를 의심할 시점이다.

2. 긴급 이슈가 스프린트 외로 처리되는 빈도를 기록하라. 월 2회 이상이면 스프린트 경계가 실질적인 업무 흐름과 괴리된 것이다. 특히 결제·정산처럼 외부 변수가 많은 도메인이면 이 빈도는 더 높을 수밖에 없다.

3. Must/Can 분리부터 2주 동안 실험하라. 스프린트를 한 번에 없애지 않아도 된다. 이번 주 Must를 최대 3개로 제한하고, 나머지는 Can으로 내려라. 2주 뒤 Must 달성률과 Can 달성률을 비교하면 팀의 실질 처리량(throughput)이 수면 위로 올라온다. 그 데이터로 스프린트 유지 여부를 판단하면 된다.

결제·정산·자동화를 직접 운영한다면 외부 변수가 언제든 Must를 바꿔버린다는 걸 이미 알고 있을 것이다. 그 현실에 맞게 리듬을 설계하는 것이, 방법론 이름을 달고 그 방법론을 억지로 따르는 것보다 훨씬 싸다.