09. 개발 워크플로우 (PRD부터 배포까지)

AI 시대의 개발 프로세스는 본질적으로 기존과 동일하다. 요구사항을 분석하고, 설계하고, 구현하고, 테스트한다. 달라진 것은 AI가 잘할 수 있는 영역을 위임하고, 사람이 잘할 수 있는 판단은 사람이 내린다는 협업 구조다. 이 챕터에서는 Anthropic이 권장하는 개발 워크플로우를 PRD 작성부터 배포까지 단계별로 살펴본다.

1. Anthropic 공식 개발 워크플로우 전체 그림

소프트웨어 개발의 근본적인 흐름은 AI 시대에도 변하지 않는다.

분석 → 설계 → 구현 → 테스트 → 배포

AI가 등장하면서 달라진 것은 각 단계에서 누가 주도하느냐다. 사람이 방향을 결정하고 AI가 실행을 담당하는 구조가 가장 효과적이다.

AI 시대 이전과 이후의 차이

단계	AI 이전	AI 이후
요구사항 분석	수동으로 이해관계자 인터뷰 정리	AI가 초안 구조화, 사람이 맥락 보완
설계 (PRD)	수일간 문서 작성	AI가 몇 분 만에 초안 생성, 사람이 검증
로드맵	경험 기반 추정	AI가 기술적 의존성 분석 후 제안
Task 분할	PM이 수동으로 분할	AI가 자동 분할, 사람이 우선순위 조정
구현	모든 코드를 직접 작성	AI가 보일러플레이트 담당, 사람이 핵심 로직 결정
테스트	수동 테스트 + 단위 테스트 작성	AI가 테스트 코드 생성, 자동 실행
배포	배포 스크립트 작성	AI가 설정 보조, 사람이 최종 확인

핵심은 AI가 모든 것을 대체하는 것이 아니라, 반복적이고 구조적인 작업을 위임받는 것이다. 비즈니스 판단, 우선순위 결정, 사용자 경험 감각은 여전히 사람의 몫이다.

2. PRD 문서 (Product Requirements Document)

PRD는 프로젝트의 핵심 정보를 담은 요구사항 명세서다. "무엇을 만들 것인가"를 명확히 정의하는 문서로, 이 문서가 프로젝트 전체의 기준점이 된다.

PRD에 포함되어야 할 내용

항목	설명	예시
프로젝트 개요	프로젝트의 목적과 배경	"중소기업용 견적서 자동 생성 웹앱"
핵심 사용자	누가 이 제품을 사용하는가	"영업팀 직원, 소규모 사업자"
사용자 여정	사용자가 제품을 사용하는 흐름	"로그인 → 고객 선택 → 항목 입력 → PDF 다운로드"
기능 명세	구체적인 기능 목록 (ID 부여)	F-001: 사용자 인증, F-002: 견적 항목 관리
비기능 요구사항	성능, 보안, 호환성 등	"응답시간 2초 이내, 모바일 반응형"
기술 스택	사용할 기술	"Next.js, Supabase, Tailwind"
제약사항	제한 조건	"2주 내 MVP 완성, 1인 개발"

서브에이전트를 활용한 PRD 생성

Claude Code에서 서브에이전트 패턴(08장 참조)을 활용하면 PRD 초안을 빠르게 생성할 수 있다. 핵심은 PRD Generator와 PRD Validator를 분리하는 것이다.

단계 1: PRD Generator로 초안 생성

프롬프트 예시:

"아래 요구사항을 바탕으로 PRD 문서를 작성해줘.
- 중소기업 대상 견적서 관리 웹앱
- Notion API로 데이터 관리
- PDF 다운로드 기능
- 모바일 반응형"

Claude Code가 PRD Generator 역할을 수행하면서 기능 명세표를 ID와 함께 구조화한다.

markdown

## 기능 명세

| ID | 기능 | 설명 | 우선순위 |
|----|------|------|----------|
| F-001 | 사용자 인증 | 이메일/비밀번호 기반 로그인 | 높음 |
| F-002 | 견적 항목 CRUD | 항목 추가, 수정, 삭제, 목록 조회 | 높음 |
| F-003 | 고객 관리 | 고객 정보 등록 및 선택 | 중간 |
| F-004 | PDF 다운로드 | 견적서를 PDF로 변환하여 다운로드 | 높음 |
| F-005 | Notion 동기화 | Notion DB와 양방향 데이터 동기화 | 중간 |
| F-006 | 대시보드 | 견적 현황 통계 요약 | 낮음 |

단계 2: PRD Validator로 기술적 검증

생성된 PRD를 그대로 사용하면 구현 불가능한 스펙이 포함될 수 있다. Plan 모드를 활용하여 기술적 타당성을 검증한다.

Plan 모드에서:

"이 PRD의 기술적 타당성을 검증해줘.
- 2주 내 1인 개발로 가능한지
- 기술 스택 간 호환성 문제는 없는지
- 구현 불가능하거나 과도하게 복잡한 기능은 없는지"

검증 결과 예시:

[검증 결과]
- F-005 (Notion 양방향 동기화): 양방향은 MVP에서 과도함.
  → 권장: 단방향(Notion→앱) 읽기 전용으로 축소
- F-006 (대시보드): 2주 내 완성하려면 v2로 이동 권장
- 전체: 기술적으로 실현 가능하나, F-005 수정 필요

단계 3: 반복 검토 후 확정

Plan 모드로 PRD를 반복 검토하면서 **"이 PRD대로 구현하면 문제없겠는가?"**를 스스로 질문한다. PRD가 확정되면 이후 모든 작업의 기준점이 된다.

핵심 원칙: PRD는 한 번에 완벽하게 작성하는 것이 아니라, AI와 사람이 여러 번 주고받으며 다듬는 것이다. Plan 모드의 반복 검토가 품질을 결정한다.

3. 로드맵 작성

PRD가 확정되면 다음은 개발 단계를 나누는 로드맵이다. "무엇을 만들지"가 정해졌으니, 이제 "어떤 순서로 만들지"를 결정한다.

로드맵의 구조

로드맵은 보통 3~5단계로 나눈다. 각 단계는 이전 단계의 결과물에 의존하므로, 순서가 중요하다.

[예시: 견적서 웹앱 로드맵]

1단계 (기초 세팅)     → 프로젝트 초기화, 기술 스택 설정, DB 스키마
2단계 (UI 구현)       → 레이아웃, 페이지 라우팅, 컴포넌트 구조
3단계 (핵심 기능)     → 인증, CRUD, Notion 연동, PDF 생성
4단계 (최적화/배포)   → 반응형 조정, 성능 최적화, Vercel 배포

Development Planner 서브에이전트 활용

프롬프트 예시:

"이 PRD를 기반으로 개발 로드맵을 작성해줘.
- 1인 개발, 총 2주
- 단계별로 의존성을 고려해서 순서를 정해줘
- 각 단계의 예상 소요 기간도 포함해줘"

AI가 생성한 로드맵 예시:

markdown

## v1 개발 로드맵

### 1단계: 프로젝트 기초 (2일)
- [ ] Next.js 프로젝트 초기화
- [ ] Tailwind CSS + ShadCN UI 설정
- [ ] Supabase 프로젝트 생성 및 DB 스키마 정의
- [ ] 환경변수 설정 (.env.local)

### 2단계: UI 프레임워크 (3일)
- [ ] 공통 레이아웃 (헤더, 사이드바, 메인 영역)
- [ ] 페이지 라우팅 (/, /login, /quotes, /quotes/[id])
- [ ] 공통 컴포넌트 (Button, Input, Table, Modal)

### 3단계: 핵심 기능 구현 (5일)
- [ ] F-001: 사용자 인증 (Supabase Auth)
- [ ] F-002: 견적 항목 CRUD
- [ ] F-003: 고객 관리
- [ ] F-004: PDF 다운로드
- [ ] F-005: Notion 단방향 연동

### 4단계: 마무리 및 배포 (2일)
- [ ] 모바일 반응형 조정
- [ ] 에러 처리 및 로딩 상태
- [ ] Vercel 배포 및 환경변수 설정

버전 관리: v1에서 v2로

첫 번째 로드맵(v1)이 완료되면, v2 로드맵을 작성하여 고도화한다. v1에서 의도적으로 제외했던 기능(예: 대시보드, 양방향 동기화)을 v2에 배치한다.

v1 로드맵 완료 → v2 로드맵 작성 → v2 구현 → v3 로드맵...

이 반복 구조가 **점진적 발전(Incremental Improvement)**의 핵심이다. 처음부터 완벽하게 만들려 하지 말고, 동작하는 최소 단위를 빠르게 완성한 뒤 확장한다.

4. Task 관리 도구

로드맵이 만들어졌으면 각 단계의 작업을 더 세부적으로 나누고 추적해야 한다. Claude Code 생태계에서 자주 사용되는 Task 관리 도구 두 가지를 살펴본다.

Task 생명주기

Claude Task Master

Claude Task Master는 MCP 서버 기반의 작업 관리 도구다. Claude Code 안에서 자연어로 작업을 분할하고 순차적으로 실행할 수 있다.

명령	기능	설명
`plan_task`	작업 분할	큰 작업을 실행 가능한 하위 작업으로 분할
`execute_task`	작업 실행	분할된 작업을 순서대로 실행
`update_task`	작업 갱신	진행 상태, 메모, 결과를 업데이트
`list_tasks`	작업 조회	전체 작업 목록과 진행 상태 확인

사용 흐름 예시:

1. plan_task: "사용자 인증 기능을 구현하기 위한 작업을 분할해줘"
   → 결과:
     Task 1: Supabase Auth 설정
     Task 2: 로그인 페이지 UI
     Task 3: 로그인 API 연동
     Task 4: 세션 관리 미들웨어
     Task 5: 로그아웃 기능

2. execute_task: Task 1 실행
   → Supabase 프로젝트 설정 코드 생성

3. update_task: Task 1 완료 표시 + 다음 작업으로 이동

Shrimp Task Manager

Shrimp Task Manager는 Claude Task Master와 유사한 기능을 제공하는 대안 도구다.

명령	기능	설명
`plan_task`	작업 계획	작업을 단계별로 구조화
`execute_task`	작업 실행	계획된 작업을 실행
`list_task`	작업 조회	현재 작업 목록 확인
`verify_task`	작업 검증	완료된 작업의 결과를 검증

두 도구 모두 핵심 워크플로우는 동일하다:

Plan → List → Execute → Verify → Update

선택 기준은 팀의 선호도와 프로젝트 특성에 따라 결정하면 된다. 도구 자체보다 워크플로우를 일관되게 유지하는 것이 더 중요하다.

5. 작업 관리 도구에 대한 올바른 이해

이 절은 매우 중요하다. Task 관리 도구를 처음 접하면 흔히 빠지는 오해가 있기 때문이다.

흔한 오해

"Task 관리 도구를 쓰면 AI가 알아서 작업을 완벽하게 나누고, 순서도 정하고, 실행도 해줄 것이다."

현실

도구는 관리를 도와줄 뿐, 주도권은 반드시 개발자에게 있어야 한다. 이유는 다음과 같다.

1) 개발 순서의 중요성

소프트웨어 개발에서 작업 순서는 매우 중요하다. AI는 기능 목록을 나열할 수 있지만, 어떤 순서로 구현해야 가장 효율적인지는 맥락에 따라 달라진다.

잘못된 순서:
  1. 로그인 페이지 UI 구현
  2. 대시보드 UI 구현
  3. 공통 컴포넌트 제작   ← 이미 1, 2에서 중복 코드 발생
  4. API 연동

올바른 순서:
  1. 공통 컴포넌트 제작   ← 먼저 만들어두면 이후 작업이 빨라짐
  2. API 연동 기초 설정
  3. 로그인 페이지 (공통 컴포넌트 활용)
  4. 대시보드 (공통 컴포넌트 활용)

공통 모듈을 먼저, 개별 기능은 나중에. 이 원칙은 AI가 자동으로 판단하기 어렵다.

2) AI가 모르는 컨텍스트

컨텍스트	왜 AI가 모르는가	사람의 판단 예시
비즈니스 우선순위	시장 상황, 경쟁사 동향	"결제 기능을 먼저 만들어야 매출이 나온다"
팀 역량	각 팀원의 기술 수준	"백엔드를 잘하는 A가 API를 담당하고..."
기술 부채	레거시 코드 상태	"이 모듈은 리팩토링 없이 기능 추가 불가"
외부 의존성	서드파티 API 일정	"결제 API가 다음 주에야 제공된다"
정치적 요인	이해관계자 요구	"CEO가 데모용으로 이것을 먼저 보고 싶어한다"

3) 계획은 변한다

소프트웨어 개발에서 계획 변경은 예외가 아니라 일상이다.

구현 중 기술적 제약을 발견할 수 있다
사용자 피드백으로 우선순위가 바뀔 수 있다
새로운 요구사항이 추가될 수 있다
예상보다 오래 걸리는 작업이 나타날 수 있다

Task 관리 도구는 이런 변경을 구조적으로 반영하는 데 도움을 준다. 하지만 언제, 어떻게 변경할지를 결정하는 것은 개발자의 역할이다.

핵심 원칙: Task 관리 도구는 "비서"이지 "매니저"가 아니다. 비서에게 일정을 관리해달라고 맡기되, 어떤 회의에 참석할지는 본인이 결정한다.

6. 구현 단계의 핵심 패턴

로드맵과 Task가 준비되었으면 실제 코드를 작성하는 구현 단계에 들어간다. Claude Code를 활용한 구현은 다음 패턴을 반복한다.

구현 사이클

각 단계 상세 설명

단계 1: Plan 모드로 계획 수립

구현을 시작하기 전에 반드시 Plan 모드로 계획을 먼저 세운다. 바로 코드를 작성하게 하면 방향이 엉뚱하게 갈 수 있다.

[Plan 모드 프롬프트 예시]

"F-001 사용자 인증 기능을 구현하려고 해.
Supabase Auth를 사용하고, 이메일/비밀번호 로그인만 지원해.
어떤 파일들을 만들어야 하고, 어떤 순서로 작업해야 하는지 계획을 세워줘."

Claude Code가 Plan 모드에서 내놓는 계획에는 보통 다음이 포함된다:

생성/수정할 파일 목록
각 파일의 역할
작업 순서와 이유
예상 주의사항

단계 2: 계획 검토와 수정

Plan 모드에서 나온 계획을 꼼꼼히 읽고, 문제가 있으면 수정을 요청한다.

수정 요청 예시:

"계획은 좋은데, 미들웨어를 먼저 만들고 나서 로그인 페이지를 만드는 게 더 나을 것 같아.
미들웨어가 있어야 로그인 후 리다이렉트를 테스트할 수 있으니까.
순서를 바꿔줘."

단계 3: AcceptEdit / Bypass로 구현

계획이 만족스러우면 실제 구현을 진행한다. Claude Code가 파일을 생성하거나 수정할 때 AcceptEdit 또는 Bypass를 적절히 사용한다.

AcceptEdit: 각 변경 사항을 하나씩 확인하며 승인
Bypass (Shift+Tab): 신뢰할 수 있는 작업일 때 자동 승인으로 빠르게 진행

단계 4: 결과 확인 + 커밋

구현이 끝나면 반드시 결과를 확인하고, 정상 동작하면 즉시 Git 커밋한다.

bash

# 빌드 확인
npm run build

# 테스트 실행
npm run test

# 문제 없으면 커밋
git add .
git commit -m "F-001: 사용자 인증 기능 구현"

각 기능 단위로 커밋하는 것이 핵심이다. 여러 기능을 한꺼번에 구현한 뒤 한 번에 커밋하면, 문제가 생겼을 때 어디서 발생했는지 추적하기 어렵고 롤백도 힘들어진다.

단계 5: /clear로 컨텍스트 정리

하나의 작업이 끝나면 /clear 명령어로 컨텍스트를 정리한다. 이전 작업의 컨텍스트가 남아 있으면 토큰을 불필요하게 소비하고, 다음 작업에 혼선을 줄 수 있다.

/clear

정리 후 다음 작업으로 넘어간다. 이 사이클을 모든 Task에 대해 반복한다.

작업 분할의 원칙

하나의 큰 작업을 작은 단위로 쪼개는 것이 성공의 열쇠다.

원칙	설명	예시
단일 책임	한 번에 하나의 기능만 구현	"로그인"과 "회원가입"을 같이 하지 않기
독립적 테스트	각 작업 결과를 독립적으로 검증 가능	"로그인 후 세션이 유지되는지" 단독 확인
커밋 가능 단위	각 작업 완료 시 커밋할 수 있는 상태	반쪽짜리 기능을 커밋하지 않기
롤백 가능	문제 시 해당 커밋만 되돌릴 수 있음	`git revert`로 특정 기능만 제거 가능

7. 테스트 & 디버깅

구현된 코드가 올바르게 동작하는지 확인하는 과정이다. AI를 활용하면 테스트 코드 작성과 디버깅 속도를 크게 높일 수 있다.

CLAUDE.md에 테스트 규칙 추가

프로젝트의 CLAUDE.md 파일에 테스트 관련 규칙을 명시해두면, Claude Code가 작업을 완료할 때마다 자동으로 확인 과정을 거친다.

markdown

# CLAUDE.md 예시

## 작업 완료 후 확인 규칙
- 코드 수정 후 반드시 `npm run build` 실행하여 빌드 오류 확인
- 새 기능 구현 시 관련 테스트 파일도 함께 작성
- `npm run lint` 통과 확인
- TypeScript 사용 시 `npx tsc --noEmit`으로 타입 오류 확인

이렇게 해두면 Claude Code가 기능 구현 후 "빌드 확인을 해볼까요?"라고 스스로 제안하거나, 빌드 명령을 자동 실행한다.

Playwright MCP를 활용한 브라우저 테스트

웹 애플리케이션의 경우 Playwright MCP를 연결하면 브라우저를 자동으로 조작하면서 테스트할 수 있다.

프롬프트 예시:

"Playwright로 로그인 기능을 E2E 테스트해줘.
1. 로그인 페이지로 이동
2. 이메일과 비밀번호 입력
3. 로그인 버튼 클릭
4. 대시보드로 리다이렉트 되는지 확인
5. 잘못된 비밀번호로 시도했을 때 에러 메시지 확인"

Playwright MCP가 설정되어 있으면 Claude Code가 직접 브라우저를 열어 위 시나리오를 실행하고, 각 단계의 결과를 보고한다.

에러 발생 시 디버깅 전략

에러가 발생했을 때 Claude Code에게 가장 효과적으로 도움을 요청하는 방법:

방법 1: 에러 메시지 직접 전달

"이 에러가 발생해:

TypeError: Cannot read properties of undefined (reading 'map')
  at QuoteList (src/components/QuoteList.tsx:15:23)

원인을 분석하고 수정해줘."

방법 2: 스크린샷 활용

브라우저의 에러 화면을 캡처하여 컨텍스트로 제공한다. Claude Code는 이미지를 분석하여 문제를 파악할 수 있다.

"이 스크린샷에서 보이는 에러를 분석해줘.
[스크린샷 경로 또는 이미지 첨부]"

방법 3: 콘솔 로그 활용

"브라우저 콘솔에서 이런 에러가 나와:

[콘솔 로그 내용 붙여넣기]

서버 로그에서는 이렇게 나오고:

[서버 로그 내용 붙여넣기]

이 두 로그를 보고 문제를 찾아줘."

디버깅 체크리스트

순서	확인 항목	Claude Code 요청 예시
1	에러 메시지 정확히 파악	"이 에러 메시지의 의미를 설명해줘"
2	관련 코드 분석	"에러가 발생한 파일의 해당 라인 주변을 분석해줘"
3	데이터 흐름 추적	"이 변수가 undefined인 이유를 추적해줘"
4	수정 및 테스트	"원인을 바탕으로 수정하고, 동일 에러가 재발하지 않는지 확인해줘"

8. 배포

코드가 완성되고 테스트를 통과하면 배포 단계에 들어간다. Vercel을 예시로 배포 과정을 설명한다.

Vercel 배포 기본 흐름

1. GitHub 저장소와 Vercel 연동
2. 환경변수 설정
3. 자동 빌드 및 배포
4. 프리뷰 URL로 확인
5. 프로덕션 도메인 연결

단계 1: GitHub 연동

Vercel에서 GitHub 저장소를 선택하면, 이후 main 브랜치에 push할 때마다 자동으로 빌드와 배포가 진행된다.

단계 2: 환경변수 설정

로컬 .env 파일에 있는 환경변수를 Vercel에도 설정해야 한다. 주의할 점:

[로컬 .env 파일]
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1...
NOTION_API_KEY=ntn_xxx...

NEXT_PUBLIC_ 접두사가 붙은 변수: 클라이언트에서 접근 가능 (공개 가능한 것만)
접두사 없는 변수: 서버 사이드에서만 접근 (비밀키)

Vercel 대시보드에서 Settings > Environment Variables에 하나씩 추가한다.

단계 3: 빌드 실패 대응

배포 시 빌드가 실패하면, Vercel의 에러 로그를 Claude Code에 전달하여 해결한다.

프롬프트 예시:

"Vercel 배포에서 빌드 실패가 발생했어. 에러 로그:

Error: Module not found: Can't resolve '@/components/QuoteForm'
  Import trace for requested module:
    ./src/app/quotes/new/page.tsx

이 에러를 수정해줘."

Claude Code가 경로 문제, 누락된 파일, 잘못된 import 등을 분석하여 수정한다. 수정 후 다시 push하면 Vercel이 자동으로 재배포한다.

배포 확인 체크리스트

항목	확인 내용
빌드 성공	Vercel 대시보드에서 "Ready" 상태 확인
환경변수	모든 필요한 변수가 설정되었는지 확인
API 연동	배포 환경에서 외부 API가 정상 동작하는지 확인
CORS	API 호출 시 CORS 에러 없는지 확인
도메인	커스텀 도메인 연결 시 DNS 설정 확인
HTTPS	SSL 인증서 자동 발급 확인

9. 실전 프로젝트 사례

위 워크플로우를 적용한 실전 프로젝트 사례를 요약한다. 각 사례는 실제로 Claude Code를 활용하여 단기간에 완성할 수 있는 수준의 프로젝트다.

사례 1: Starter Kit (프로젝트 템플릿)

항목	내용
목적	새 프로젝트를 빠르게 시작할 수 있는 기반 템플릿
기술 스택	Next.js + ShadCN UI + Tailwind CSS
포함 기능	프로젝트 구조, 공통 컴포넌트, 테마 설정, 기본 라우팅
Claude Code 활용	PRD 없이 바로 구현 가능한 수준. 기술 스택과 구조를 지시하면 빠르게 생성
소요 시간 (예상)	2~4시간

프롬프트 예시:

"Next.js 14 App Router + ShadCN UI + Tailwind CSS로 스타터 킷을 만들어줘.
- src/ 디렉토리 구조
- 공통 레이아웃 (헤더, 사이드바)
- 다크 모드 토글
- 기본 페이지 3개 (홈, 소개, 설정)"

사례 2: 견적서 웹앱

항목	내용
목적	중소기업용 견적서 생성 및 관리
기술 스택	Next.js + Notion API + html2pdf.js
핵심 기능	고객 관리, 견적 항목 CRUD, PDF 다운로드, Notion 데이터 동기화
Claude Code 활용	PRD 작성 → 로드맵 → Task 분할 → 단계별 구현 (전체 워크플로우 적용)
소요 시간 (예상)	1~2주

이 프로젝트는 앞에서 설명한 전체 워크플로우(PRD → 로드맵 → Task → 구현 → 테스트 → 배포)를 처음부터 끝까지 적용하기에 적합한 규모다. Notion API 연동은 Claude Code가 API 문서를 참조하며 코드를 생성할 수 있으므로, 개발자가 API 사양만 확인해주면 된다.

사례 3: 이벤트 관리 앱

항목	내용
목적	이벤트 생성, 참가자 관리, 실시간 업데이트
기술 스택	Next.js + Supabase (인증 + DB + 스토리지)
핵심 기능	사용자 인증, 이벤트 CRUD, 이미지 업로드, 참가자 실시간 목록
Claude Code 활용	Supabase 설정부터 배포까지 전체 과정을 Claude Code와 협업
소요 시간 (예상)	1~2주

Supabase를 사용하면 인증, 데이터베이스, 파일 스토리지를 하나의 서비스에서 해결할 수 있어서 1인 개발에 효율적이다. Claude Code는 Supabase의 클라이언트 라이브러리를 잘 알고 있으므로, 스키마를 정의해주면 CRUD 코드를 빠르게 생성한다.

프로젝트 복잡도별 워크플로우 적용 가이드

복잡도	예시	PRD 필요	로드맵 필요	Task 도구 필요
낮음	스타터 킷, 랜딩 페이지	불필요	불필요	불필요
중간	견적서 앱, 블로그	권장	권장	선택
높음	이벤트 관리 앱, SaaS	필수	필수	권장
매우 높음	대규모 플랫폼	필수	필수	필수

프로젝트가 커질수록 체계적인 관리의 중요성이 높아진다. 작은 프로젝트에서는 오버엔지니어링을 피하고, 큰 프로젝트에서는 반드시 체계를 갖추자.

10. 전체 워크플로우 종합 정리

이 챕터에서 다룬 전체 흐름을 하나의 다이어그램으로 정리한다.

핵심 요약

단계	핵심 활동	AI의 역할	사람의 역할
요구사항 분석	무엇을 만들지 정의	구조화 보조	비즈니스 판단
PRD 작성	상세 명세서	초안 생성 + 검증	최종 확정
로드맵	개발 순서와 일정	의존성 분석 + 제안	우선순위 조정
Task 분할	실행 가능 단위로 분해	자동 분할	순서 재배치
구현	코드 작성	보일러플레이트 + 패턴	설계 결정 + 리뷰
테스트	품질 검증	테스트 코드 생성	시나리오 설계
배포	프로덕션 반영	설정 보조	최종 확인 + 모니터링

이 챕터의 핵심 메시지: AI 시대의 개발 워크플로우에서 가장 중요한 것은 도구가 아니라 "사람이 방향을 잡고, AI가 실행을 돕는" 협업 구조를 일관되게 유지하는 것이다. 도구는 바뀌어도 이 원칙은 변하지 않는다.

09. 개발 워크플로우 (PRD부터 배포까지) ​

1. Anthropic 공식 개발 워크플로우 전체 그림 ​

AI 시대 이전과 이후의 차이 ​

2. PRD 문서 (Product Requirements Document) ​

PRD에 포함되어야 할 내용 ​

서브에이전트를 활용한 PRD 생성 ​

단계 1: PRD Generator로 초안 생성 ​

단계 2: PRD Validator로 기술적 검증 ​

단계 3: 반복 검토 후 확정 ​

3. 로드맵 작성 ​

로드맵의 구조 ​

Development Planner 서브에이전트 활용 ​

버전 관리: v1에서 v2로 ​

4. Task 관리 도구 ​

Task 생명주기 ​

Claude Task Master ​

Shrimp Task Manager ​

5. 작업 관리 도구에 대한 올바른 이해 ​

흔한 오해 ​

현실 ​

1) 개발 순서의 중요성 ​

2) AI가 모르는 컨텍스트 ​

3) 계획은 변한다 ​

6. 구현 단계의 핵심 패턴 ​

구현 사이클 ​

각 단계 상세 설명 ​

단계 1: Plan 모드로 계획 수립 ​

단계 2: 계획 검토와 수정 ​

단계 3: AcceptEdit / Bypass로 구현 ​

단계 4: 결과 확인 + 커밋 ​

단계 5: /clear로 컨텍스트 정리 ​

작업 분할의 원칙 ​

7. 테스트 & 디버깅 ​

CLAUDE.md에 테스트 규칙 추가 ​

Playwright MCP를 활용한 브라우저 테스트 ​

에러 발생 시 디버깅 전략 ​

방법 1: 에러 메시지 직접 전달 ​

방법 2: 스크린샷 활용 ​

방법 3: 콘솔 로그 활용 ​

디버깅 체크리스트 ​

8. 배포 ​

Vercel 배포 기본 흐름 ​

단계 1: GitHub 연동 ​

단계 2: 환경변수 설정 ​

단계 3: 빌드 실패 대응 ​

배포 확인 체크리스트 ​

9. 실전 프로젝트 사례 ​

사례 1: Starter Kit (프로젝트 템플릿) ​

사례 2: 견적서 웹앱 ​

사례 3: 이벤트 관리 앱 ​

프로젝트 복잡도별 워크플로우 적용 가이드 ​

10. 전체 워크플로우 종합 정리 ​

핵심 요약 ​

09. 개발 워크플로우 (PRD부터 배포까지)

1. Anthropic 공식 개발 워크플로우 전체 그림

AI 시대 이전과 이후의 차이

2. PRD 문서 (Product Requirements Document)

PRD에 포함되어야 할 내용

서브에이전트를 활용한 PRD 생성

단계 1: PRD Generator로 초안 생성

단계 2: PRD Validator로 기술적 검증

단계 3: 반복 검토 후 확정

3. 로드맵 작성

로드맵의 구조

Development Planner 서브에이전트 활용

버전 관리: v1에서 v2로

4. Task 관리 도구

Task 생명주기

Claude Task Master

Shrimp Task Manager

5. 작업 관리 도구에 대한 올바른 이해

흔한 오해

현실

1) 개발 순서의 중요성

2) AI가 모르는 컨텍스트

3) 계획은 변한다

6. 구현 단계의 핵심 패턴

구현 사이클

각 단계 상세 설명

단계 1: Plan 모드로 계획 수립

단계 2: 계획 검토와 수정

단계 3: AcceptEdit / Bypass로 구현

단계 4: 결과 확인 + 커밋

단계 5: /clear로 컨텍스트 정리

작업 분할의 원칙

7. 테스트 & 디버깅

CLAUDE.md에 테스트 규칙 추가

Playwright MCP를 활용한 브라우저 테스트

에러 발생 시 디버깅 전략

방법 1: 에러 메시지 직접 전달

방법 2: 스크린샷 활용

방법 3: 콘솔 로그 활용

디버깅 체크리스트

8. 배포

Vercel 배포 기본 흐름

단계 1: GitHub 연동

단계 2: 환경변수 설정

단계 3: 빌드 실패 대응

배포 확인 체크리스트

9. 실전 프로젝트 사례

사례 1: Starter Kit (프로젝트 템플릿)

사례 2: 견적서 웹앱

사례 3: 이벤트 관리 앱

프로젝트 복잡도별 워크플로우 적용 가이드

10. 전체 워크플로우 종합 정리

핵심 요약