Claude Code로 실제 프로젝트 개발 견적을 만드는 워크플로

개발 견적은 “며칠이면 끝나는지 맞히는 일”이 아닙니다. 실무에서 좋은 견적은 범위, 전제, 미확정 사항, 위험, 리뷰 시간, 검증 작업을 함께 보여 주어 제품 담당자, 개발자, 고객이 같은 근거로 판단하게 만드는 문서입니다.

초보자가 자주 하는 실수는 구현 시간만 계산하는 것입니다. “프로필에 전화번호 필드 하나 추가”는 작아 보이지만 DB migration, API 타입, 폼 검증, CSV 내보내기, 감사 로그, 테스트, 릴리스 노트, 리뷰 대기까지 이어질 수 있습니다. migration은 데이터베이스 구조나 데이터를 바꾸는 작업입니다. 코드는 되돌리기 쉽지만 데이터 변경은 복구가 어려울 수 있으므로 별도로 봐야 합니다.

Claude Code가 견적을 마법처럼 맞혀 주지는 않습니다. 강점은 저장소를 읽고 영향 범위를 찾고, assumptions와 unknowns를 표로 만들고, 위험을 숨기지 않게 하는 데 있습니다. 날짜를 만들어 내게 하지 말고, 빠뜨린 일을 줄이게 하세요.

이 방식은 공식 Scrum Guide의 경험주의와도 잘 맞습니다. 투명하게 만들고, 근거를 검사하고, 계획을 조정하는 흐름입니다. 여러 Issue와 PR을 묶어 추적하려면 GitHub milestones 문서가 유용합니다. 상대 견적은 Atlassian의 estimation guide도 참고할 만합니다. Claude Code 사용법은 공식 overview와 CLI reference를 기준으로 삼으세요.

함께 읽으면 좋은 글은 코드베이스 탐색 가이드, 버그 리포트 템플릿, 코드 리뷰 체크리스트입니다.

견적 재료를 먼저 분리하기

날짜를 말하기 전에 다섯 가지 입력을 분리합니다.

입력	쉬운 뜻	Claude Code가 도울 일
scope	이번에 할 일과 하지 않을 일	변경 파일, 관련 기능, 테스트 범위
assumptions	견적이 성립하는 전제	제품 규칙, 권한, 릴리스 경로
unknowns	아직 모르는 것	추가로 읽을 파일, 질문, 담당자
risk buffer	실패와 대기 시간을 위한 여유	migration, 인증, 결제, 리뷰 대기
evidence	숫자를 뒷받침하는 근거	과거 PR, git 이력, 테스트 수

“2일입니다”처럼 하나의 숫자로 끝내지 마세요. “낮은 경우 1.5일, 보통 3일, CRM 연동이 포함되면 높은 경우 5일”이 더 낫습니다. 범위는 애매함이 아니라, 무엇을 알고 무엇이 아직 움직일 수 있는지 드러내는 방식입니다.

flowchart LR
  A["요청"] --> B["repo scan"]
  B --> C["작업 분해"]
  C --> D["assumptions table"]
  D --> E["risk register"]
  E --> F["견적 범위"]
  F --> G["review prompt"]
  G --> H["고객 요약"]

현실적인 네 가지 사용 사례

첫 번째는 SaaS 프로필 필드 변경입니다. phone_number 하나가 DB schema, API validation, UI, 검색, CSV export, audit log, 개인정보 처리, 테스트에 영향을 줄 수 있습니다. 개인정보라면 로그 마스킹과 삭제/내보내기 요청도 견적에 포함해야 합니다.

두 번째는 레거시 화면의 버그 수정입니다. “필터가 동작하지 않는다”는 오래된 query helper, cache, URL parameter, fixture, E2E 테스트와 연결될 수 있습니다. 바로 수정시키기보다 먼저 영향 범위와 검증 경로를 Claude Code에 그리게 하세요.

세 번째는 외주 제안이나 사내 DX 요청입니다. 고객이 “관리 화면이 필요하다”고 말해도 실제로는 로그인, 역할, 감사 이력, CSV, 알림, 권한 이관, 운영 문서가 필요할 수 있습니다. Claude Code는 기존 Issue와 코드를 읽고 요청서에 빠진 작업을 드러내는 데 도움이 됩니다.

네 번째는 수익화된 콘텐츠 사이트입니다. 작은 MDX 수정도 속도, 내부 링크, OGP, 구조화 데이터, 현지화, 스크린샷, AdSense 친화 레이아웃 검토를 포함할 수 있습니다. 게시 품질은 단순 텍스트 편집보다 큽니다.

자주 실패하는 패턴

첫 번째 실패는 첫 느낌을 약속으로 말하는 것입니다. 코드를 읽기 전의 “아마 하루”는 희망일 뿐입니다. 그 희망이 이해관계자에게 전달되면, 현실적인 견적으로 바꿔도 지연처럼 보입니다.

두 번째 실패는 리뷰와 검증을 0으로 보는 것입니다. 구현이 6시간이어도 테스트 추가, 리뷰 반영, staging 확인, 릴리스 노트, 배포 조율이 필요합니다.

세 번째 실패는 unknowns를 막연한 buffer에 숨기는 것입니다. “30% 더하기”가 아니라 외부 API 미확인, rollback 설계 없음, 리뷰어 대기, 테스트 데이터 부족처럼 이름을 붙여야 합니다.

네 번째 실패는 근거 없는 AI 숫자를 믿는 것입니다. Claude Code가 “3일”이라고 말해도 파일, 과거 PR, 테스트, 위험이 없다면 보기 좋은 문장일 뿐입니다.

Step 1: 읽기 전용 repo scan

먼저 저장소의 외형을 봅니다. 아직 수정하지 않습니다.

git status --short
git branch --show-current
git rev-parse --show-toplevel

rg --files \
  -g '!*node_modules*' \
  -g '!dist' \
  -g '!build' \
  -g '!coverage' \
  -g '!*.lock' \
  | sort \
  | head -200

find . -maxdepth 3 \( \
  -name package.json -o \
  -name pyproject.toml -o \
  -name go.mod -o \
  -name Cargo.toml -o \
  -name AGENTS.md -o \
  -name CLAUDE.md -o \
  -name README.md \
\) -print

이후 Claude Code에 읽기 전용 지도를 요청합니다.

claude -p "
읽기 전용 repo scan을 실행하세요.
파일 수정, 생성, dependency 추가는 하지 마세요.

출력:
1. apps, packages, services
2. runtime, test, build entrypoints
3. 무시해야 할 generated folders
4. 이번 견적에서 반드시 읽을 10개 파일
5. 아직 견적을 낼 수 없는 이유
"

Step 2: 작업을 리뷰 가능한 단위로 나누기

작업은 너무 잘게가 아니라 리뷰와 검증이 가능한 단위로 나눕니다.

claude -p "
Task: 사용자가 프로필에서 전화번호를 추가, 조회, 수정할 수 있게 한다.

이 작업을 리뷰 가능한 work item으로 나누세요.
각 항목에는 다음을 포함하세요.
- name
- likely files
- implementation work
- test work
- definition of done
- size: small, medium, large

out-of-scope 항목도 작성하세요.
추측한 제품 규칙은 assumptions로 분리하세요.
"

보통 DB, API, UI, tests, release work로 나뉩니다. 한 항목이 PR 하나에 담기 어렵다면 견적 전에 더 나눕니다.

Step 3: assumptions table 만들기

전제는 나중에 일정이 흔들리는 지점입니다. 표로 적습니다.

| ID | Assumption | Why it matters | Owner | Confirm by |
| --- | --- | --- | --- | --- |
| A1 | Phone number is optional | Required fields change validation and migration | PM | 2026-06-05 |
| A2 | Web only, no mobile app change | Mobile release adds review and store delay | PM | 2026-06-05 |
| A3 | Existing user rows stay null | Backfill work is not included | Tech lead | 2026-06-06 |

claude -p "
Review this assumptions table.
Find assumptions that could break the estimate.
Add missing owners, deadlines, and questions.
Move anything risky into a risk register.
"

Step 4: risk register 작성

risk register는 계획을 깨뜨릴 수 있는 조건을 적는 표입니다.

| Risk | Trigger | Impact | Mitigation | Buffer |
| --- | --- | --- | --- | --- |
| DB rollback is unclear | migration changes existing rows | High | dry-run and rollback plan | 0.5-1 day |
| External CRM stores phone | CRM field mapping appears | Medium | check integration owner | 0.5 day |
| Review queue is full | no reviewer within 24h | Medium | book review slot early | 1 day |
| Test data is missing | no edge-case users | Medium | create fixtures first | 0.5 day |

buffer는 게으름을 위한 여유가 아닙니다. 미지의 작업, 실패, 대기 시간을 계획에 넣는 장치입니다. 인증, 결제, 개인정보, 삭제 흐름, migration은 UI 수정보다 더 명시적인 위험 관리가 필요합니다.

Step 5: 범위 계산 스크립트

아래 스크립트는 그대로 복사해 실행할 수 있습니다.

// estimate-range.mjs
const tasks = [
  { name: "Repo scan and design check", hours: 2, risk: 1.1 },
  { name: "DB migration and schema", hours: 4, risk: 1.4 },
  { name: "API contract and validation", hours: 5, risk: 1.2 },
  { name: "Profile UI update", hours: 6, risk: 1.2 },
  { name: "Tests and fixtures", hours: 5, risk: 1.3 },
  { name: "Review fixes and release note", hours: 3, risk: 1.2 },
];

const base = tasks.reduce((sum, task) => sum + task.hours, 0);
const likely = tasks.reduce((sum, task) => sum + task.hours * task.risk, 0);
const low = Math.max(base * 0.8, base - 4);
const high = likely * 1.35;

const day = 6;
const format = (hours) => `${hours.toFixed(1)}h / ${(hours / day).toFixed(1)}d`;

console.log(`Low:    ${format(low)}`);
console.log(`Likely: ${format(likely)}`);
console.log(`High:   ${format(high)}`);

node estimate-range.mjs

배수를 진실처럼 다루지 마세요. risk: 1.4는 “이 영역이 불확실하다”는 메모입니다. 바꾸면 Issue나 PR에 이유를 남깁니다.

Step 6: 비판적으로 리뷰하기

고객에게 보내기 전에 Claude Code가 견적을 공격하게 합니다.

You are a critical project estimation reviewer.

Review this estimate before I share it with a client.
Find:
1. hidden scope
2. weak assumptions
3. missing tests
4. missing rollout or rollback work
5. fake precision
6. tasks that should be split

Return findings first.
Then provide a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

“더 예쁘게 써 달라”고 하면 예쁜 문장이 나옵니다. “비판적으로 리뷰하라”고 해야 실제 누락이 나옵니다.

Step 7: 고객용 요약 만들기

내부 메모는 짧은 결정 문서로 바꿉니다.

# Development Estimate Summary

## Scope
- Add optional phone number to user profile.
- Update DB schema, API validation, profile UI, and tests.
- Include release note and manual verification.

## Not included
- SMS notification.
- Mobile app release.
- Historical data backfill.
- CRM integration changes unless confirmed.

## Estimate
- Low: 3 business days
- Likely: 4-5 business days
- High: 7 business days if CRM or migration rollback work expands

## Assumptions
- Phone number is optional.
- Web only.
- Existing users can keep the value empty.

## Risks
- DB rollback plan must be reviewed before implementation.
- Reviewer availability may add one calendar day.

## Next decision
- Confirm whether CRM and mobile app are in scope by 2026-06-05.

견적은 GitHub Issue나 milestone에 다시 넣어 실제 결과와 비교합니다.

## Estimate
- Low:
- Likely:
- High:
- Confidence: Low / Medium / High

## Scope
- [ ]

## Out of scope
- [ ]

## Assumptions
- [ ]

## Risks
- [ ]

## Verification
- [ ] Unit tests:
- [ ] Integration tests:
- [ ] Manual check:

## Actual result
- Started:
- Merged:
- Extra work found:
- What to adjust next time:

Actual result가 있어야 팀이 학습합니다. 다음 견적은 감이 아니라 증거에서 시작됩니다.

상담과 수익화 CTA

견적은 상담 전환과 잘 맞는 주제입니다. 독자는 자기 저장소, 고객 설명, 팀 규칙에 맞춘 흐름이 필요합니다. ClaudeCodeLab은 견적 템플릿, Claude Code 리뷰 prompt, PR 체크리스트, 팀 도입 규칙 설계를 도울 수 있습니다. 실제 Issue나 제안 프로세스에 연결하고 싶다면 Claude Code 교육 및 상담으로 상황을 보내 주세요.

실제 검증 결과

Masa는 작은 프로필 필드 변경에 이 흐름을 적용했습니다. 첫 감은 “반나절 UI 작업”이었지만, repo scan 후에는 DB schema, API validation, CSV export, audit log, tests, review queue가 드러났습니다. 고객에게 보낸 범위는 보통 4-5 영업일, CRM 작업이 생기면 높은 경우 7일이었습니다. Claude Code가 유용했던 이유는 날짜를 맞힌 것이 아니라 숨은 파일과 unknowns를 초기에 보이게 했기 때문입니다.