Claude Code로 개발 견적 정확도를 3배 높이는 7가지 기법

“3일”이라고 했는데 2주가 걸렸다. 프로젝트 관리의 전형적 함정. 원인은? 아무도 견적을 내기 전에 코드를 읽지 않았다는 것. Claude Code에게 먼저 코드베이스를 읽히면 견적 정확도가 3배 뛴다.

1. Blast Radius를 읽고 견적 내기

태스크가 들어오면 먼저 범위를 잡는다.

claude -p "
태스크: users 테이블에 'phone_number' 컬럼을 추가하고
프로필 화면에서 표시/편집 가능하게 한다.

건드려야 할 모든 파일을 나열해줘:

1. DB layer (migrations, schema)
2. API layer (request/response types)
3. UI layer (폼, 표시)
4. Tests (기존 + 신규)
5. Docs

파일별로 라인 변경 추정치를 추가해줘.
"

‘3개 파일 변경’이 흔하게 ‘14개 파일 + 6개 테스트’로 드러난다.

2. 과거 유사 태스크 참조

git 히스토리에서 실측치를 끌어온다.

claude -p "
지난 6개월간 users 테이블에 컬럼을 추가한 모든 PR을 찾아줘:

1. PR 제목 + 번호
2. 시작부터 merge까지 일수
3. 변경된 파일
4. Review 왕복 횟수
5. 배포 후 버그 수

git log --grep='add.*column' --since='6 months ago'를 사용해.
평균과 중앙값을 제공하고, 이번 견적의 baseline도 제시해줘.
"

“유사한 과거 PR은 평균 5영업일”이라는 방어 가능한 baseline이 생긴다.

3. 숨은 의존성 드러내기

Scope creep은 일정을 죽인다.

claude -p "
'phone_number' 추가에 대해 숨은 영향을 조사해줘:

1. 업데이트가 필요한 검색/필터 기능
2. 알림(SMS) 기능
3. 외부 API 연동(CRM, email)
4. 개인정보 준수(GDPR / 유사)
5. 기존 analytics / event tracking
6. 모바일 앱 변경

각 영향을 High/Medium/Low로 평가해줘.
"

뒤늦게 드러나는 GDPR이나 모바일 작업은 견적을 몇 배로 불린다.

4. 리스크 버퍼 계산

불확실성을 수치화한다.

claude -p "
이 태스크의 리스크 버퍼 factor를 계산해줘:

Factor:
- 관련 코드에 대한 친숙도 (high/med/low)
- 관련 영역의 테스트 커버리지
- 건드리는 코드의 응집도
- 버그가 잦은 영역의 이력
- 외부 의존성 수
- 리뷰어 가용성

각 항목에 1.0-2.0을 부여한 뒤 출력:
최종 견적 = 순수 구현 시간 × factor의 곱.
"

“3일 × 1.8 = 5.4일” — 기계적이고 방어 가능하다.

5. 견적 근거 문서 생성

이해관계자를 위해.

claude -p "
docs/estimates/{task-id}.md를 작성해줘:

## 태스크 개요
## Blast radius (Claude 분석)
## 과거 유사 태스크 실측치
## 리스크 factor와 버퍼 factor
## 최종 견적 (낙관 / 표준 / 비관)
## 가정과 명시적 범위 외 항목

세분도: PM이 읽을 수 있게.
"

근거 없는 “3일”은 방어 불가능하다. 근거 문서가 buy-in을 만든다.

6. 주기적 견적 대 실측 분석

지속적인 정확도 개선을 위해.

claude -p "
지난달 완료된 태스크에 대해:

1. 견적 대 실측 delta 집계
2. 고정확 vs. 저정확 태스크 분류
3. 오차 원인 분류
4. 다음에 도입할 개선사항

docs/estimates/retrospective-$(date +%Y-%m).md로 출력.
팀 월간 retro용 포맷.
"

“DB 작업은 항상 2x로 잡는다”처럼 팀 고유의 편향을 드러낸다.

7. 대형 태스크를 단계화 (Rolling Wave Planning)

거대 태스크를 한 방에 견적 내지 마라.

claude -p "
'Checkout 플로우 재작성'을 단계별 견적으로 분해해줘:

Phase 1: Discovery (기존 코드 분석, 요구사항 정의) → X일
Phase 2: 설계 (기술 설계 문서) → Y일
Phase 3: PoC (최소 구현) → Z일

Phase 1에 대해서만 상세 견적.
Phase 2-3은 Phase 1 완료 후 재견적.

이것이 'Rolling Wave Planning'이다.
"

불확실성이 높은 작업에는 단계별 견적이 필수. 큰 작업에 대한 one-shot 견적은 언제나 터진다.

CLAUDE.md에 견적 규칙 코드화

## Estimation Rules

### Required process
- Tasks ≥1 day: scope with Claude Code first
- Tasks ≥3 days: state risk buffer explicitly
- Tasks ≥5 days: use phased estimates

### Buffer factor baselines
- Unfamiliar code: 1.5x
- Coverage <50%: 1.3x
- External API integration: 1.4x
- Legacy code: 1.8x

### Communication
- Always present optimistic / standard / pessimistic
- Escalate within 24h if scope shifts

안티패턴

❌ 감으로만 견적

사람 견적은 거의 항상 낙관 편향이다. 먼저 Claude Code에게 코드를 읽혀라.

❌ 버퍼 제로

“딱 맞는” 견적은 항상 밀린다. 최소 1.3x.

❌ 사후 정당화

실측 delta를 숨기지 마라. retro에서 분석해 개선하라.

❌ 단계 견적 건너뛰기

“지금 전체 견적을 달라”는 함정이다. Rolling Wave Planning을 제안하라.

결론

• Claude Code에게 blast radius를 읽혀라
• 과거 유사 태스크의 실측치를 인용하라
• 숨은 의존성을 드러내라
• 리스크 버퍼를 수치화하라
• 근거 문서를 생성하라
• 월간 정확도 retro를 운영하라
• 대형 태스크를 단계화하라
• 규칙을 CLAUDE.md에 성문화하라

더 나은 견적 = 팀에 대한 더 높은 신뢰. “약속대로 배포한다”가 더 큰 일을 가져온다.

관련: 팀 협업 / PR 품질 10배 / 개발자 온보딩

공식 문서: Anthropic Claude Code / Rolling Wave Planning (PMI)