일정 추정의 50% 룰 — 우리가 멈춘 지점

결제·정산 팀에서 일정이 어긋나면 무슨 일이 벌어지는가

일반적인 프로덕트 팀에서 일정이 밀리면 기능 출시가 늦어진다. 아쉽지만 대개는 수습이 가능하다. 결제·정산·자동화를 직접 운영하는 팀에서는 사정이 다르다. 정산 마감 시간은 VAN사·PG사·카드사 정책에 묶여 있다. 새벽 2시에 돌아가는 배치 job이 그 시간을 놓치면 하루치 정산 사이클이 통째로 날아간다. 규제 신고 기한은 법적으로 고정돼 있다. 이 맥락에서 일정 추정의 오차는 단순한 계획 차질이 아니라 금전적·운영적 손실로 즉시 전환된다.

HEDVION에서 결제 자동화 모듈 하나가 예상보다 3일 늦게 배포된 적이 있다. 해당 기능이 특정 가맹점 정산 흐름과 연결돼 있었기 때문에, 그 3일 동안 정산 데이터를 수작업으로 검증해야 했다. 총 추가 투입 시간은 팀원 2명 기준 약 18시간. 추정 오차 3일이 18시간의 수동 운영 비용으로 전환된 셈이다. 이 경험이 우리가 추정 문제를 단순한 "정확도" 이슈가 아니라 "운영 리스크" 이슈로 바라보게 된 계기였다.

"두 배로 잡으면 돼"가 틀리는 구조적 이유

"두 배 룰"은 직관적으로 맞는 것처럼 들린다. 3일짜리 작업이면 6일을 잡아라. 하지만 우리 경험에서 두 배로 잡아도 계속 부족했던 이유는, 두 배가 작업 복잡도에만 대응하는 승수이기 때문이다. 비작업 시간은 승수가 아니라 고정 오버헤드로 붙는다. 작업을 두 배로 늘려도 고정 오버헤드는 그대로 남는다.

구체적으로 어떤 시간들이 여기 해당하는가. 코드 리뷰 대기 시간, PG사 테스트 환경 접속 지연, 샌드박스 계정 발급 대기, 외부 API 문서에 없는 예외 케이스 파악 시간, 정산 로직 검증을 위한 회계 팀 싱크 시간. 이것들은 "작업"처럼 느껴지지 않기 때문에 추정 단계에서 잘 포함되지 않는다. 결제·정산 도메인에서는 여기에 외부 의존성이 하나 더 추가된다: 테스트 트랜잭션 승인/취소 사이클이 실 환경에서는 몇 시간이 걸리기도 한다. 개발 시간은 두 배로 잡았어도, 이 검증 사이클 자체가 1~2일을 추가로 잡아먹는다.

우리 팀 작업 로그를 돌아보면, 작업 구현 시간과 검증·배포 전 확인 시간의 비율이 대략 6:4였다. 10시간짜리 구현 작업에 6~8시간의 검증·조율 시간이 항상 붙었다는 의미다. 두 배 룰은 이 검증 시간을 전혀 다루지 않는다.

우리가 써본 방법들, 그리고 버린 이유

스토리 포인트 기반 상대 추정. 스프린트 플래닝에서 포인팅을 시도했다. 3명 팀에서 플래닝 포커에 드는 시간이 스프린트당 50~60분이었고, 추정 정확도 개선은 측정 가능한 수준이 아니었다. 스토리 포인트가 유효하려면 기준점(앵커)이 팀 내에 공유돼야 하는데, 팀이 작고 작업 종류가 다양할수록 앵커가 흔들린다. 결제 API 연동 작업과 정산 배치 스케줄링 작업을 같은 척도로 포인팅하는 것 자체가 무리였다. 결국 관리 오버헤드만 남기고 폐기했다.

과거 실적 데이터 참고. 이론적으로 가장 올바른 접근이다. 비슷한 작업의 실제 소요 시간을 기록해두고 참고하면 된다. 문제는 데이터가 쌓이기 전까지는 쓸 수 없고, 쌓인 후에도 맥락이 달라지면 참조값의 신뢰도가 떨어진다. PG사가 교체되거나, 정산 방식이 바뀌거나, 새 팀원이 합류하면 과거 데이터의 대표성이 급격히 약해진다. 작은 팀일수록 맥락 변화가 잦기 때문에 이 약점이 더 부각됐다.

작업 쪼개기(task decomposition). 이것이 우리에게 가장 실용적이었다. 1주짜리 작업을 하루 단위로 쪼개면 추정 오차가 줄어드는 경험을 반복했다. 작업 단위가 작아질수록 숨어 있던 의존성이 수면 위로 올라오고, 비작업 시간도 각 단위에 배분해서 볼 수 있게 된다. 다만 이 방법에도 한계가 있다: 분해 자체에 시간이 들고, 결제 시스템 전체 구조 변경처럼 잘게 쪼개지지 않는 작업에서는 적용이 어렵다.

우리가 멈춘 지점: 추정 ROI 계산

추정 정확도를 높이려는 노력을 일정 수준 이상 기울이다 보니, 어느 시점에서 수확 체감이 뚜렷해졌다. 추정 회의에 더 많은 시간을 쓰고, 더 세밀하게 작업을 분해하고, 리스크를 더 꼼꼼하게 점검해도 실제 소요 시간의 분산은 좁혀지지 않았다. 특히 외부 의존성이 많은 결제 도메인에서는 아무리 정교하게 추정해도 PG사 정기 점검 공지 하나, 카드사 API 스펙 변경 하나로 계획이 흔들렸다.

이 시점에서 우리가 던진 질문은 "추정을 더 잘하려면 어떻게 해야 하는가"가 아니었다. "추정 노력의 어느 지점에서 멈추고, 남은 에너지를 어디에 써야 하는가"였다. 결론은 이렇다: 추정 노력의 약 50% 지점에서 멈추고, 나머지 50%는 실행 중 신호 감지와 커뮤니케이션에 쓴다. 이것이 우리가 말하는 "50% 룰"의 실제 의미다. 추정치에 50% 버퍼를 얹으라는 게 아니다. 추정 정확도를 90%에서 95%로 끌어올리는 데 쓸 에너지를, 딜레이 신호를 하루 빨리 감지하고 공유하는 데 쓰는 것이 결제·정산 현장에서 더 큰 실질 이득을 낸다.

실제로 지금 쓰는 방식 — 시나리오로 보여주기

최근 정산 자동화 파이프라인 개선 작업을 예로 들겠다. 기존 방식이었다면 전체 소요 시간을 추정하고, 스프린트 일정에 넣고, 마감에 맞추는 식으로 관리했을 것이다. 지금은 세 가지만 한다.

첫째, 이번 정산 사이클(2주) 안에 반드시 들어가야 하는 것과 그렇지 않은 것을 먼저 분리한다. 이 구분이 추정보다 먼저 일어난다. 정산 마감일이 고정돼 있기 때문에, "이게 그 날까지 필요한가"라는 질문이 "이게 얼마나 걸리는가"보다 선행한다. 우선순위가 없으면 추정 정확도는 의미가 없다. 둘째, 작업을 3일 이내 단위로 쪼개되, 각 단위가 독립적으로 테스트 가능하도록 자른다. 이 단위 내에서만 추정을 하고, 전체 일정 추정은 하지 않는다. 셋째, 각 단위가 예상 시간의 1.5배를 넘기는 순간 팀 슬랙 채널에 즉시 공유한다. 이 신호가 올라오면 우선순위 재조정, 범위 축소, 병렬 지원 투입 중 어떤 대응을 할지 팀이 함께 결정한다. 이 방식의 핵심은 추정 정확도가 아니라 신호 지연 시간 최소화다. 결제 시스템에서 "늦어지고 있다"는 신호가 3일 늦게 오면 대응 옵션이 없다. 1일 이내에 오면 범위를 줄이거나 우선순위를 바꿀 수 있다. 이 방식 적용 이후 우리 팀에서 "마감 당일에야 딜레이를 알게 된" 케이스는 거의 사라졌다.

바로 써먹을 수 있는 시사점

추정이 자꾸 빗나가는 팀이라면, 아래 세 가지를 순서대로 점검해보자.

1. 추정에 비작업 시간이 포함돼 있는가. 코드 구현 시간만 추정하고 있다면, 리뷰·검증·배포·외부 의존성 대기 시간을 별도로 추정해서 더한다. 결제·정산 맥락에서는 구현 시간의 40~60%를 추가로 잡는 것이 현실적이다. 이게 두 배 룰보다 더 정직한 출발점이다.

2. 전체 추정 대신 3일 이내 단위로만 추정한다. 그 이상은 추정이 아니라 희망이다. 3일을 넘기는 작업은 반드시 쪼갠다. 쪼개지지 않는다면 작업 정의 자체를 다시 해야 한다.

3. 추정 정확도 개선보다 신호 공유 속도를 높인다. 팀 내에 "계획보다 늦어지고 있다"는 신호를 즉시 공유하는 채널과 문화가 없다면, 추정을 아무리 정교하게 해도 소용없다. 슬랙 채널이든, 데일리 스탠드업이든, 예상 시간 1.5배 초과 시 공유 규칙이든, 신호 전달 시간을 줄이는 메커니즘을 하나 만들어라. 결제·정산처럼 외부 마감이 고정된 도메인일수록 이 메커니즘의 가치는 배가 된다.

추정은 맞추는 게 목표가 아니다. 추정은 어긋났을 때 빠르게 알아채기 위한 기준선이다. 그 기준선을 세우는 데 필요한 최소한의 노력을 투자하고, 나머지는 실행과 소통에 쓴다. 그게 우리가 멈춘 지점이고, 지금은 그 선택이 맞다고 생각한다.

— by mings