✍️ 필사 모드: AI 시대의 프로젝트 일정 관리: 견적·벨로시티·스프린트 계획이 무너진 자리에서 다시 세우기

프롤로그 — 견적이 망가진 건 추정을 못해서가 아니다

2024년 어느 스프린트 회고. 한 팀의 벨로시티가 갑자기 두 배가 됐다. 누구도 더 오래 일하지 않았다. Cursor와 Claude Code가 팀에 들어왔을 뿐이다. 다음 스프린트, 벨로시티는 다시 절반으로 떨어졌다. 어려운 티켓만 남았기 때문이다.

이 팀의 PM은 회고에서 이렇게 말했다. "우리 벨로시티 그래프가 더 이상 아무것도 예측하지 못한다."

맞는 말이다. 하지만 원인을 오해하면 안 된다. 추정을 못하게 된 게 아니다. 추정의 단위였던 '사람의 노력'이라는 양이 더 이상 안정적이지 않게 된 것이다.

스토리 포인트는 한 번도 시간이 아니었다. 그것은 노력·복잡도·불확실성의 묶음이었고, 그 묶음이 팀 안에서 비교적 일관됐기 때문에 작동했다. "3점짜리"는 팀 모두에게 대략 비슷한 무게였다. AI 에이전트가 루프에 들어오면서 이 일관성이 깨졌다. 같은 3점짜리가 어떤 날은 4초 만에 초안이 나오고, 어떤 날은 여전히 이틀이 걸린다. 평균을 내도 의미가 없다. 분포 자체가 두 개의 봉우리로 갈라졌기 때문이다.

이 글은 그 갈라진 분포 위에서 일정을 다시 세우는 방법을 다룬다. 대상 독자는 테크리드, EM, 그리고 시니어 IC다. 추상적인 "AI가 바꾼 미래" 이야기가 아니라, 다음 스프린트 계획 회의에서 바로 쓸 수 있는 것들을 정리한다.

다룰 내용:

1. 스토리 포인트가 의미를 잃은 정확한 메커니즘
2. 새 병목은 구현이 아니라 리뷰·통합이다
3. AI 보조 작업을 견적하는 법 — 점이 아니라 범위, 스파이크 우선
4. 벨로시티는 이제 바이모달이다
5. 에이전트가 하룻밤에 5티켓을 끝낼 때의 스프린트 계획
6. AI 보조 작업 vs 사람 작업을 추적하기
7. 에이전트 산출물의 "90% 완료" 함정
8. 리뷰가 제약일 때의 용량 계획
9. 여전히 의미 있는 지표 — 리드 타임, 탈출률, 리뷰 지연
10. 에필로그 — 체크리스트와 안티패턴

1장 · 스토리 포인트가 의미를 잃은 정확한 메커니즘

스토리 포인트를 비난하기 전에, 왜 그게 원래 작동했는지부터 짚자. 스토리 포인트는 세 가지 가정 위에 서 있었다.

세 가정이 전부 동시에 흔들렸다.

노력 일관성이 깨졌다. CRUD 엔드포인트 추가는 예전엔 2점이었다. 지금은 에이전트가 스키마를 보고 5분 만에 초안을 만든다. 하지만 분산 락 경합을 디버깅하는 5점짜리는 여전히 5점이다. AI가 거기서 별 도움이 안 되기 때문이다. 같은 척도 안에 5분짜리와 이틀짜리가 같은 숫자를 달고 있다.

노력이 시간의 프록시이길 멈췄다. 구현 시간이 0에 수렴해도 캘린더 시간은 줄지 않는다. 에이전트가 4초 만에 짠 코드도 사람이 리뷰하고, 통합하고, QA하는 데는 똑같은 시간이 든다. 노력을 합산해서 시간을 예측하던 공식의 분모가 사라졌다.

복잡도와 구현 비용이 분리됐다. 이게 가장 근본적이다. 예전엔 "어려운 문제"와 "코드 많이 짜야 하는 문제"가 강하게 상관됐다. 지금은 아니다. 명세가 명확하고 패턴이 흔한 작업은 — 복잡하든 단순하든 — 에이전트가 빠르게 처리한다. 반대로 명세가 모호하거나 시스템 맥락이 깊게 얽힌 작업은 — 코드 양이 적어도 — 여전히 사람의 시간을 통째로 먹는다.

결론: 스토리 포인트를 버릴 필요는 없다. 하지만 무엇을 추정하는지 다시 정의해야 한다. 생성 시간이 아니라 — 그건 거의 0이다 — 명세 비용과 검증 비용을 추정해야 한다.

옛 견적 = f(구현 노력)
새 견적 = f(명세 명확도) + f(리뷰·통합·QA 노력)

다음 장에서 이 두 번째 항이 왜 새 병목인지 본다.

2장 · 새 병목은 구현이 아니라 리뷰·통합이다

제약 이론(Theory of Constraints)의 한 줄 요약: 시스템의 처리량은 가장 느린 단계가 결정한다. 다른 단계를 아무리 빠르게 해도 소용없다.

AI 이전, 소프트웨어 전달의 단계별 시간 비중은 대략 이랬다.

[설계 15%] → [구현 50%] → [리뷰 10%] → [통합·QA 20%] → [배포 5%]
                  ↑ 병목

구현이 가장 큰 덩어리였고, 그래서 우리는 구현을 빠르게 하는 데 모든 도구를 투자했다. IDE, 자동완성, 보일러플레이트 생성기. 에이전트는 그 흐름의 정점이다 — 구현을 거의 공짜로 만들었다.

그런데 구현이 공짜가 되면 어떻게 될까. 병목이 옮겨간다.

[설계 25%] → [구현 5%] → [리뷰 35%] → [통합·QA 30%] → [배포 5%]
                              ↑ 새 병목

리뷰가 새 병목이다. 이유는 단순하다. 리뷰는 본질적으로 사람의 인지 작업이고, 그 양은 검토할 코드의 양에 비례하는데 에이전트는 코드를 더 많이, 더 빠르게 만든다. 게다가 에이전트 코드는 사람 코드와 리뷰 부담이 다르다.

리뷰어는 이제 "코드를 읽는" 게 아니라 "코드가 맞다는 걸 증명"해야 한다. 작성자의 의도라는 지름길이 없기 때문이다. 이건 더 느리고, 더 피곤하고, 더 쉽게 놓친다.

실전 함의 하나. 팀에 에이전트를 도입하면서 리뷰 용량을 그대로 두면, 처리량은 거의 그대로다. 구현이 빨라진 만큼 PR이 리뷰 큐에 쌓일 뿐이다. 큐는 길어지고, 리드 타임은 오히려 늘 수 있다. 빨라진 건 "PR 생성 속도"지 "전달 속도"가 아니다.

실전 함의 둘. 통합·QA도 같이 부풀어 오른다. PR이 많아지면 머지 충돌이 많아지고, 통합 환경에서 깨지는 조합이 많아진다. 에이전트는 자기 PR이 다른 사람의 미머지 PR과 어떻게 충돌할지 모른다.

그래서 다음 장의 견적 원칙이 나온다: 에이전트가 만드는 단계가 아니라, 사람이 검증하는 단계를 추정하라.

3장 · AI 보조 작업을 견적하는 법 — 점이 아니라 범위, 스파이크 우선

AI 보조 작업의 견적이 어려운 진짜 이유는 결과의 분산이 크다는 것이다. 같은 티켓이 30분에 끝날 수도, 이틀이 걸릴 수도 있다. 그 분기점은 작업을 시작하기 전엔 잘 안 보인다.

분산이 큰 양을 단일 숫자로 추정하면 거의 항상 틀린다. 그래서 두 가지 원칙.

원칙 1: 점이 아니라 범위로 견적한다

단일 포인트 대신 낙관-비관 범위를 낸다. 핵심은 범위의 폭 자체가 정보라는 것이다.

폭이 넓다는 건 "더 큰 작업"이라는 뜻이 아니라 **"우리가 이 작업을 아직 이해 못 했다"**는 뜻이다. 넓은 범위를 본 스프린트 계획자는 숫자를 키울 게 아니라 불확실성을 줄일 행동을 해야 한다.

원칙 2: 스파이크 우선 (spike-first)

폭이 넓은 티켓은 곧장 스프린트에 넣지 않는다. 먼저 타임박스된 스파이크를 넣는다.

넓은 견적 (1~4일) 발견
   │
   ▼
타임박스 스파이크 (2~4시간)
   ├─ 에이전트에게 프로토타입 시켜본다
   ├─ 명세의 빈 곳을 찾는다
   └─ 통합 지점을 확인한다
   │
   ▼
재견적 → 보통 좁은 범위로 수렴

AI 시대에 스파이크는 예전보다 훨씬 싸졌다. 에이전트에게 "이거 일단 만들어봐"라고 시키면 30분 만에 작동하는 프로토타입이 나온다. 그 프로토타입은 버리더라도, 그것을 만드는 과정에서 명세의 모호함과 통합 위험이 드러난다. 이게 스파이크의 진짜 가치다 — 코드가 아니라 학습.

스파이크 후 재견적하면 대부분 범위가 좁아진다. 좁아지지 않으면? 그것 자체가 강력한 신호다. 이 작업은 본질적으로 불확실하니 스프린트 약속에서 빼거나, 더 작게 쪼개야 한다.

견적 워크플로 정리

1. 초안 견적을 범위로 낸다 (낙관 ~ 비관)
2. 폭이 좁으면 → 그대로 스프린트 후보
3. 폭이 넓으면 → 스파이크를 먼저 스프린트에 넣는다
4. 스파이크 후 재견적 → 좁아지면 후보, 안 좁아지면 쪼갠다
5. 스프린트 약속은 "좁은 범위" 티켓들로만 채운다

이 워크플로의 핵심 메시지: 불확실한 걸 확실한 척 추정하지 말고, 불확실성을 줄이는 작업을 먼저 하라.

4장 · 벨로시티는 이제 바이모달이다

벨로시티 그래프가 무의미해진 이유를 통계로 보면 명확하다. 작업 시간 분포가 단봉(unimodal)에서 쌍봉(bimodal)으로 바뀌었다.

AI 이전, 팀의 작업 시간 분포는 대략 정규분포에 가까웠다. 평균 주변에 대부분 몰려 있고, 평균과 중앙값이 비슷했다. 평균을 내는 게 의미 있었다.

AI 이전 — 단봉 분포
빈도
 │        ▁▃▅█▅▃▁
 │     ▁▃█████████▃▁
 └──────────────────────── 작업 소요 시간
         평균 ≈ 중앙값 (의미 있음)

AI 이후, 분포가 두 개의 봉우리로 갈라졌다.

AI 이후 — 쌍봉 분포
빈도
 │  █                      █
 │  █▆                    ▆█
 │  ██▃                  ▃██
 └──────────────────────────── 작업 소요 시간
   봉우리 A              봉우리 B
   (사소한 작업,         (어려운 작업,
    에이전트가 붕괴시킴)   거의 안 변함)

        ↑ 이 사이의 "평균"은 아무도 살지 않는 곳

• 봉우리 A — 붕괴한 작업. CRUD, 보일러플레이트, 잘 알려진 패턴 적용, 명확한 리팩터링. 에이전트가 시간을 거의 0으로 만들었다.
• 봉우리 B — 변하지 않은 작업. 모호한 명세, 깊은 시스템 맥락, 새로운 설계 결정, 까다로운 디버깅. 에이전트가 별 도움이 안 된다.

평균은 두 봉우리 사이의 골짜기를 가리킨다. 거기엔 실제 작업이 하나도 없다. "이번 스프린트 평균 작업은 1.5일" 같은 문장은 평균 가족 구성원이 2.3명이라는 말처럼 공허하다.

그래서 무엇을 추적하는가

평균 대신 두 봉우리를 따로 추적한다.

특히 봉우리 B의 처리량이 진짜 신호다. 봉우리 A는 에이전트가 처리하니 거의 무한정 늘릴 수 있다 — 리뷰만 따라준다면. 하지만 봉우리 B는 사람의 깊은 사고가 필요하고, 그게 팀의 실제 상한이다. 분기 계획은 봉우리 B 처리량으로 세워야 한다.

바이모달 인식이 바꾸는 회고 대화

회고에서 "벨로시티가 떨어졌다"는 말이 나오면 이렇게 되묻는다.

"봉우리 A가 떨어졌나, 봉우리 B가 떨어졌나?"

• 봉우리 A가 떨어졌다 → 리뷰 큐가 막혔거나, 에이전트 활용이 줄었다. 도구·프로세스 문제.
• 봉우리 B가 떨어졌다 → 진짜 어려운 일을 하고 있거나, 시니어가 막혔다. 사람·집중 문제.

같은 "벨로시티 하락"이 완전히 다른 두 처방을 부른다. 평균 하나로는 이 구분이 불가능하다.

5장 · 에이전트가 하룻밤에 5티켓을 끝낼 때의 스프린트 계획

이제 현실적인 시나리오. 금요일 저녁, 시니어 IC가 에이전트에게 백로그 상단 5개 티켓을 맡기고 퇴근한다. 월요일 아침, 5개 PR이 올라와 있다.

스프린트 계획의 전제가 흔들린다. "2주에 팀이 N포인트를 한다"는 약속의 의미가 뭔가, PR 생성이 하룻밤에 끝난다면?

흔한 오해: 스프린트는 죽었다

아니다. 스프린트는 살아 있다. 단지 스프린트가 무엇을 약속하는 단위인지가 바뀌었다.

• 옛 스프린트: "이만큼의 코드를 작성하겠다"
• 새 스프린트: "이만큼의 코드를 검증하고, 통합하고, 배포 가능 상태로 만들겠다"

월요일 아침의 5개 PR은 "끝난 일"이 아니다. 그것은 리뷰·통합 큐에 들어온 입력이다. 스프린트 약속은 그 큐를 비우는 능력에 대한 약속이다.

스프린트 계획을 두 트랙으로 나눈다

트랙 1 — 생성 트랙 (에이전트 주도)
  ├─ 백로그 상단 티켓을 에이전트에게 위임
  ├─ 빠르고 병렬적, 거의 무제한
  └─ 출력: 리뷰 대기 PR

트랙 2 — 검증 트랙 (사람 주도) ← 스프린트 약속은 여기
  ├─ 리뷰, 통합, QA, 배포
  ├─ 사람 용량에 엄격히 묶임
  └─ 출력: 배포된 가치

스프린트 계획 회의에서 따져야 할 질문이 바뀐다.

생성 트랙을 의도적으로 제한한다

직관에 어긋나지만 중요하다: 생성 트랙에 고삐를 채워야 한다.

에이전트가 하룻밤에 5개, 다음 날 5개, 또 5개를 만들면 리뷰 큐는 끝없이 길어진다. 이건 진척이 아니라 재고 과잉이다. 미머지 PR은 자산이 아니라 부채다 — 머지 충돌의 위험을 키우고, 코드베이스에 대한 가정이 오래될수록 리베이스가 어려워진다.

규칙: 검증 트랙이 소화할 수 있는 만큼만 생성 트랙을 돌린다. 리뷰 큐에 일정 수 이상 PR이 쌓이면 에이전트에게 새 작업을 위임하지 않는다. 칸반의 WIP 제한을 리뷰 큐에 적용하는 것이다.

리뷰 큐 WIP 제한 = 3
┌─────────────────────────────────┐
│ 리뷰 대기: [PR][PR][PR]  ← 가득  │
│ → 에이전트에 새 위임 중단         │
│ → 리뷰가 하나 빠지면 다시 위임    │
└─────────────────────────────────┘

이게 5장의 핵심: 스프린트는 살아 있되, 약속의 단위가 생성에서 검증으로 옮겨갔고, 생성은 검증 용량에 맞춰 의도적으로 조절해야 한다.

6장 · AI 보조 작업 vs 사람 작업을 추적하기

"우리 팀에서 AI가 얼마나 기여하나"라는 질문은 경영진에게서 반드시 온다. 답하는 방식이 팀 문화를 만들거나 망친다.

추적하지 말아야 할 것

먼저 함정. 다음 지표들은 측정하지 마라. 측정하는 순간 게임당한다.

이 지표들의 공통 문제: AI를 사람과 경쟁시키거나, 도구 사용 자체를 목표로 만든다. AI는 키보드나 컴파일러처럼 도구다. "이번 분기 컴파일러 사용률"을 추적하지 않듯, "AI 활용률"도 그 자체로는 추적할 가치가 없다.

추적해야 할 것

대신 작업의 성격을 추적한다. 개인이 아니라 작업 유형을.

티켓 분류 (개인 평가 아님, 백로그 이해용)

  유형 A: 에이전트가 주도, 사람이 검증
    → 봉우리 A. 빠른 처리. 리뷰가 제약.

  유형 B: 사람이 주도, 에이전트가 보조
    → 봉우리 B. 깊은 사고. 사람 시간이 제약.

  유형 C: 순수 사람 작업 (설계, 디버깅, 협상)
    → 에이전트 부적합. 시니어 시간이 제약.

이 분류는 개인의 성과표가 아니다. 백로그의 구성을 이해하고 용량을 계획하기 위한 것이다. 같은 사람이 어떤 티켓은 유형 A로, 어떤 티켓은 유형 C로 한다. 분류 대상은 사람이 아니라 일이다.

유용한 단 하나의 비율

굳이 "AI 효과" 숫자가 필요하다면, 이것 하나만 본다.

유형 A 처리량 증가분
─────────────────────  = 에이전트의 실제 레버리지
유형 A에 든 리뷰 비용

분자가 분모보다 충분히 크면 에이전트가 순이득이다. 분모가 분자를 따라잡으면 — 리뷰 비용이 생성 이득을 먹어버리면 — 도구가 아니라 프로세스를 고쳐야 한다는 신호다.

보고할 때의 프레이밍

경영진에게는 이렇게 보고한다.

"에이전트로 유형 A 작업의 리드 타임이 X% 줄었습니다. 그 결과 병목이 리뷰로 이동했고, 다음 분기에 리뷰 용량에 투자하면 그 이득을 처리량으로 전환할 수 있습니다."

이 프레이밍은 정직하고("줄 수가 늘었다" 같은 허수가 없다), 행동 가능하다(다음 투자처를 지목한다). "AI가 코드의 40%를 짭니다" 같은 문장은 인상적이지만 아무 결정도 못 내리게 한다.

7장 · 에이전트 산출물의 "90% 완료" 함정

소프트웨어 견적의 오래된 농담: "90% 완료됐고, 남은 10%에 또 90%의 시간이 든다." 에이전트는 이 함정을 더 깊고 더 그럴듯하게 만든다.

왜 에이전트 출력은 90%처럼 보이는가

에이전트가 만든 PR을 처음 열면 인상적이다. 코드가 컴파일된다. 테스트가 있다. 통과한다. 변수명이 깔끔하다. 구조가 합리적이다. 완성된 것처럼 보인다.

하지만 "보인다"가 핵심 단어다. 에이전트는 그럴듯해 보이는 것에 최적화돼 있다. 표면적 완성도와 실제 완성도가 사람 코드보다 더 크게 벌어진다.

사람이 짠 코드
  표면 완성도 ──────────●  70%
  실제 완성도 ─────────●   65%
  (작성자가 약한 곳을 안다. 갭이 작다.)

에이전트가 짠 코드
  표면 완성도 ───────────────────●  95%
  실제 완성도 ──────────●            60%
  (갭이 크다. 그리고 갭이 어디 있는지 보이지 않는다.)

표면과 실제 사이의 그 35%가 "남은 10%"의 정체다. 그리고 이 갭은 보통 다음에 숨어 있다.

특히 마지막에서 두 번째가 위험하다. 에이전트가 만든 테스트는 종종 자기가 짠 코드가 하는 일을 그대로 단언한다. 버그가 있어도 테스트는 그 버그를 "정답"으로 박제한다. 테스트 통과가 정확성을 보장하지 않는다.

함정을 피하는 견적 규칙

규칙 1: "PR 올라옴"은 0% 완료다. 견적의 끝점을 "PR 생성"이 아니라 "배포되어 관측됨"으로 잡는다. 에이전트가 PR을 올린 순간은 검증 작업의 시작점이지 끝점이 아니다.

규칙 2: 검증을 별도 티켓·별도 견적으로. 생성과 검증을 한 티켓에 묶으면 검증이 항상 과소평가된다. 큰 에이전트 산출물은 "구현" 티켓과 "검증·통합" 티켓으로 나누고, 후자를 정직하게 견적한다.

규칙 3: 에이전트 PR에는 "역방향 리뷰"를. 코드를 위에서 아래로 읽지 말고, 위 표의 다섯 가지 숨은 곳을 체크리스트로 먼저 친다. "엣지 케이스는? 통합 가정은? 테스트가 의도를 검증하나?" 표면적 완성도에 속지 않으려면 의도적으로 갭을 찾아야 한다.

규칙 4: 마지막 10%에 버퍼가 아니라 트랙을. 버퍼는 "혹시 모르니 시간을 더"다. 트랙은 "이 작업은 반드시 있고 별도로 계획한다"다. 에이전트 산출물의 마지막 10%는 혹시가 아니라 항상이다. 버퍼로 숨기지 말고 검증 트랙의 일등 시민으로 계획한다.

8장 · 리뷰가 제약일 때의 용량 계획

2장에서 병목이 리뷰로 옮겨갔다고 했다. 8장은 그 사실을 용량 계획에 반영하는 법이다.

옛 용량 계획 vs 새 용량 계획

옛 방식
  팀 용량 = Σ (개인별 구현 가능 시간)
  계획 = 이 용량에 맞춰 구현 작업을 채운다

새 방식
  팀 용량 = MIN(생성 용량, 리뷰 용량, 통합 용량)
  계획 = 가장 작은 항(보통 리뷰)에 맞춰 약속한다

제약 이론을 그대로 적용한 것이다. 생성 용량은 에이전트 덕에 사실상 무한에 가깝다. 그러니 그건 더 이상 계획의 기준이 아니다. 가장 작은 항 — 거의 항상 리뷰 — 이 팀의 진짜 처리량이다.

리뷰 용량을 실제로 계산하기

리뷰 용량은 추상적이지 않다. 측정 가능하다.

리뷰 용량 (PR/주)
  = 리뷰어 수
  × 인당 주간 리뷰 가능 시간
  ÷ PR당 평균 리뷰 시간

예시:
  리뷰어 4명
  × 인당 주 6시간 (리뷰에 쓸 수 있는 현실적 시간)
  ÷ PR당 1.5시간 (에이전트 PR은 더 걸린다)
  = 16 PR/주

이 16이라는 숫자가 스프린트 약속의 상한이다. 에이전트가 주에 50개 PR을 만들 수 있어도, 팀이 약속할 수 있는 건 16개 분량이다. 나머지 34개를 만드는 건 진척이 아니라 큐 적체다.

리뷰 용량을 늘리는 레버

리뷰가 제약이면, 개선은 리뷰 용량을 늘리는 데서 온다. 다른 데를 개선하면 낭비다.

가장 효과가 큰 건 보통 PR을 작게 만드는 것이다. 리뷰 시간은 PR 크기에 선형이 아니라 초선형으로 증가한다 — 큰 PR은 사람이 머릿속에 다 담지 못해서 더 느리고 더 부정확하다. 에이전트에게 "이 기능 전체를 한 PR로"가 아니라 "이 기능을 5개 작은 PR로 쪼개서"라고 위임하는 규율이 용량을 가장 크게 늘린다.

용량 계획 회의의 새 안건

스프린트 용량 계획 — 새 체크리스트
  □ 이번 스프린트 리뷰 용량은 몇 PR인가? (위 공식으로 계산)
  □ 통합·QA 용량은? (머지 충돌·환경 시간 포함)
  □ 둘 중 작은 값이 스프린트 약속의 상한
  □ 생성 트랙은 그 상한에 맞춰 WIP 제한 설정
  □ 시니어 리뷰 시간이 봉우리 B에 충분히 남는가?

마지막 항목이 미묘하지만 중요하다. 시니어가 봉우리 A의 에이전트 PR을 리뷰하느라 시간을 다 쓰면, 봉우리 B의 진짜 어려운 일을 할 사람이 없어진다. 리뷰 용량을 계획할 때 시니어의 깊은 작업 시간을 먼저 떼어 놓아야 한다.

9장 · 여전히 의미 있는 지표 — 리드 타임, 탈출률, 리뷰 지연

스토리 포인트와 벨로시티가 흔들렸다고 측정을 포기할 순 없다. 다행히 흔들리지 않는 지표들이 있다. 공통점: 이들은 "노력"을 측정하지 않고 "흐름"과 "결과"를 측정한다. 그래서 AI가 노력을 바꿔도 의미가 유지된다.

지표 1: 리드 타임 (Lead Time)

작업이 시작된 순간부터 배포되어 사용자에게 닿기까지의 캘린더 시간.

왜 살아남는가: 리드 타임은 생성 시간이 아니라 전체 흐름을 본다. 에이전트가 구현을 0으로 만들어도, 리드 타임이 안 줄면 병목이 다른 데 있다는 뜻이다. 리드 타임은 그 병목을 숨기지 않는다.

리드 타임 분해 (병목 진단용)
  [대기] → [생성] → [리뷰 대기] → [리뷰] → [통합] → [배포]
                        ↑
            여기가 길어졌으면 리뷰가 제약

리드 타임을 단계별로 쪼개면 어느 단계가 부풀었는지 바로 보인다. AI 시대에는 거의 항상 "리뷰 대기" 구간이 범인이다.

지표 2: 탈출률 (Escape Rate)

프로덕션까지 빠져나간 결함의 비율. 리뷰·QA를 통과했지만 사용자가 발견한 버그.

왜 중요해졌는가: 에이전트 코드의 "90% 완료 함정"(7장)이 정확히 탈출률로 나타난다. 표면적으로 완성돼 보이는 PR이 리뷰를 통과하기 쉽고, 숨은 갭이 프로덕션에서 터진다. 탈출률이 오르면 검증 트랙이 생성 속도를 못 따라가고 있다는 직접 증거다.

탈출률이 오르는데 벨로시티(생성 속도)도 오르고 있다면, 그건 좋은 게 아니다. 검증되지 않은 코드를 빠르게 내보내고 있을 뿐이다.

지표 3: 리뷰 지연 (Review Latency)

PR이 올라온 시각부터 리뷰가 시작되는 시각까지의 시간. 리뷰에 걸리는 시간이 아니라 리뷰를 기다리는 시간.

왜 핵심 지표인가: 리뷰 지연은 리뷰 큐의 길이를 직접 보여준다. 2장·8장에서 본 새 병목의 체온계다.

리뷰 지연이 말해주는 것
  지연 ≈ 0      → 리뷰 용량 여유. 생성 트랙을 더 돌려도 됨
  지연 증가 추세 → 큐 적체 시작. 생성 트랙 조절 필요
  지연 폭증     → 병목 심각. 즉시 WIP 제한 강화

리뷰 지연은 선행 지표다. 리드 타임은 사후에 "느렸다"고 알려주지만, 리뷰 지연은 "지금 막히고 있다"를 실시간으로 알려준다.

지표 4: 봉우리 B 처리량 (4장 재등장)

어려운 작업(유형 B·C)의 스프린트당 완료 수. 4장에서 강조한 그 지표.

왜 분기 계획의 기준인가: 봉우리 A는 에이전트가 처리하니 신축적이다. 하지만 봉우리 B는 사람의 깊은 사고가 상한이고, 그게 팀이 실제로 만들 수 있는 가치의 한계다. 로드맵 약속은 봉우리 A의 빠른 처리에 취하지 말고 봉우리 B 처리량에 근거해야 한다.

지표 종합

이 네 가지의 공통점을 다시 강조한다. 하나도 "코드를 얼마나 빨리 짰나"를 측정하지 않는다. 전부 흐름·결과·역량을 측정한다. 그래서 AI가 구현을 공짜로 만들어도 의미가 그대로 유지된다. 측정해야 할 것은 처음부터 노력이 아니라 흐름이었다 — AI 시대는 그저 그 사실을 더 이상 무시할 수 없게 만들었을 뿐이다.

에필로그 — 무너진 자리에서 다시 세우기

견적이 망가졌다는 말은 절반만 맞다. 노력 기반 견적이 망가졌다. 흐름 기반 계획은 멀쩡하다 — 오히려 AI 시대에 더 또렷해졌다. 우리가 할 일은 측정을 포기하는 게 아니라, 측정의 대상을 노력에서 흐름으로 옮기는 것이다.

핵심을 한 문장으로: 에이전트는 구현을 공짜로 만들었고, 그래서 병목은 리뷰·통합으로 옮겨갔으며, 계획과 측정의 중심도 거기로 옮겨가야 한다.

실전 체크리스트

다음 스프린트 계획 회의 전에 점검할 것들.

1. 견적은 범위로. 단일 포인트를 버리고 낙관-비관 범위로 견적한다. 범위의 폭을 불확실성의 신호로 읽는다.
2. 넓은 견적엔 스파이크 먼저. 폭이 넓은 티켓은 스프린트에 직접 넣지 말고 타임박스 스파이크를 먼저 넣어 재견적한다.
3. 벨로시티를 두 봉우리로 쪼갠다. 평균을 버리고 봉우리 A(사소)와 봉우리 B(어려움)를 따로 추적한다. 분기 계획은 봉우리 B 기준.
4. 스프린트 약속을 검증 트랙으로. "코드를 짜겠다"가 아니라 "검증하고 통합하고 배포하겠다"를 약속한다.
5. 생성 트랙에 WIP 제한. 리뷰 큐가 소화할 수 있는 만큼만 에이전트에게 위임한다. 미머지 PR은 자산이 아니라 부채다.
6. 리뷰 용량을 숫자로 계산한다. 리뷰어 수 × 주간 리뷰 시간 ÷ PR당 리뷰 시간. 이 값이 스프린트 약속의 상한.
7. PR을 작게 위임한다. 리뷰 시간은 PR 크기에 초선형. 작은 PR이 리뷰 용량을 가장 크게 늘린다.
8. 에이전트 PR은 "0% 완료"로 본다. PR 생성은 검증의 시작점. 검증·통합을 별도 티켓·별도 견적으로.
9. 숨은 갭을 체크리스트로 친다. 엣지 케이스, 통합 가정, 비기능 요구, 테스트의 빈틈, 에러 처리 — 위에서 아래로 읽지 말고 갭을 먼저 찾는다.
10. 흔들리지 않는 지표를 본다. 리드 타임, 탈출률, 리뷰 지연, 봉우리 B 처리량. 이 넷은 노력이 아니라 흐름을 측정한다.

안티패턴

피해야 할 것들. 하나씩 다 흔한 실수다.

• 벨로시티 평균에 매달리기. 쌍봉 분포의 평균은 아무도 살지 않는 골짜기다. 평균이 올랐다고 좋아하거나 떨어졌다고 걱정하기 전에 어느 봉우리인지 묻는다.
• AI 활용률을 목표로 삼기. "AI 보조 PR 80%" 같은 목표는 도구 사용 자체를 목적으로 만든다. AI는 도구지 목표가 아니다.
• 줄 수로 기여 측정하기. AI가 짠 코드 줄 수를 자랑하는 보고서는 과잉 생성을 보상하고 아무 결정도 못 내리게 한다.
• 생성 트랙을 무제한으로 돌리기. 에이전트가 만들 수 있다고 다 만들게 두면 리뷰 큐가 끝없이 길어진다. 진척처럼 보이는 재고 과잉이다.
• "PR 올라옴 = 완료"로 처리하기. 에이전트 PR은 표면적으로 완성돼 보인다. PR 생성을 완료로 세면 검증이 항상 과소평가된다.
• 시니어를 에이전트 PR 리뷰로 소진하기. 시니어가 봉우리 A 리뷰에 시간을 다 쓰면 봉우리 B의 진짜 어려운 일을 할 사람이 없다. 시니어의 깊은 작업 시간을 먼저 떼어 놓는다.
• 검증이 제약인데 생성 도구에 더 투자하기. 병목이 아닌 곳을 개선하는 건 낭비다. 제약 — 거의 항상 리뷰 — 에 투자한다.
• 탈출률을 무시한 채 속도만 보기. 벨로시티가 오르는데 탈출률도 오르면 그건 빠른 게 아니라 검증 안 된 코드를 빠르게 내보내는 것이다.

다음 글 예고

다음 글은 **"AI 시대의 코드 리뷰: 에이전트 PR을 검증하는 실전 워크플로"**다. 이 글에서 "리뷰가 새 병목"이라고 반복했으니, 다음 글은 그 병목 안으로 들어간다. 에이전트 PR 전용 리뷰 체크리스트, 역방향 리뷰의 구체적 절차, 자동 게이트와 사람 리뷰의 역할 분담, 그리고 주니어가 에이전트 PR을 리뷰할 수 있도록 키우는 법까지 — 리뷰 용량을 실제로 늘리는 방법을 코드 레벨에서 다룬다.

견적이 망가진 자리는 빈터가 아니다. 흐름을 측정하고, 병목을 따라가고, 검증을 일등 시민으로 대접하는 — 더 정직한 계획이 들어설 자리다.