AI주도개발 통합시스템 v3.2.0 with Cursor Rules & Commands
현재 버전
Version
- v3.2.0
- 릴리스일: 2025-09-16
- 주요 변경: 인지과학 기반 최적화를 통한 논리 플로우 재구성
5_implementation/
01-prototype-analysis.md
경로 : .cursor/commands/5_implementation/01-prototype-analysis.md
|---------|------|------------|----------|
| 1.1.0 | 2025-07-10 | MINOR | 카테고리 기반 구성 전환, 기능 확장 |
| 1.0.0 | 2025-06-10 | MAJOR | 초기버전 작성 |
---
# 프로토타입 분석 · 프로덕션 이행 갭(차이) 분석 가이드
## 개요
이 문서는 완성된 프로토타입을 상세히 분석하여 프로덕션 환경에 적용 가능한지 평가하고, 프로덕션 이행에 필요한 차이를 명확히 하는 프로세스를 정의합니다.
## 기본 방침
### 분석 접근
1. **Phase 1: 프로토타입 코드 이해** - 현행 기술 구성과 기능의 상세 파악
2. **Phase 2: 프로덕션 적합성 평가** - 프로덕션 요구사항과의 적합성 평가
3. **Phase 3: 차이 인식 · 명확화** - 부족 요소 식별과 우선순위 부여
### 평가 기준
프로덕션 환경에서 요구되는 품질 레벨:
- **보안**: 인증·인가·데이터 보호·취약점 대응
- **성능**: 응답 시간·확장성·리소스 효율
- **가용성**: 오류 처리·모니터링·복구 기능
- **유지보수성**: 코드 품질·테스트·문서화
- **운영성**: 배포·모니터링·로그·메트릭
## Phase 1: 프로토타입 코드 이해
### 1.1 기술 스택 분석
#### 프레임워크 · 라이브러리 조사
```markdown
## 기술 구성 맵
### 프런트엔드
- [ ] 프레임워크: _____ (버전: _____)
- [ ] UI 라이브러리: _____ (버전: _____)
- [ ] 스타일링: _____ (버전: _____)
- [ ] 상태 관리: _____ (버전: _____)
- [ ] 라우팅: _____ (버전: _____)
### 데이터 관리
- [ ] API 통신: _____ (버전: _____)
- [ ] 데이터 패칭: _____ (버전: _____)
- [ ] 캐시 전략: _____
- [ ] 상태 영속화: _____
### 인증 · 보안
- [ ] 인증 방식: _____
- [ ] 세션 관리: _____
- [ ] CSRF 대응: _____
- [ ] XSS 대응: _____
### 개발 · 테스트
- [ ] TypeScript: _____ (설정 레벨: _____)
- [ ] 린터: _____ (설정: _____)
- [ ] 테스트 프레임워크: _____
- [ ] 테스트 커버리지: _____%
### 빌드 · 배포
- [ ] 번들러: _____
- [ ] 최적화 설정: _____
- [ ] 환경변수 관리: _____
- [ ] CI/CD: _____
```
### 1.2 기능 구현 분석
#### 인증 기능 평가
```markdown
## 인증 시스템 분석
### 현재 구현
- [ ] 인증 방식: _____
- [ ] 세션 관리: _____
- [ ] 토큰 관리: _____
- [ ] 로그아웃 처리: _____
- [ ] 권한 관리: _____
### 보안 평가
- [ ] 비밀번호 암호화: _____
- [ ] 세션 유효기간: _____
- [ ] CSRF 대응: _____
- [ ] 무차별 대입(브루트포스) 대응: _____
- [ ] Secure 쿠키: _____
### 프로덕션 적합성
- [ ] 프로덕션에서 사용 가능: YES / NO
- [ ] 주요 이슈: _____
- [ ] 필요한 개선: _____
```
## Phase 2: 프로덕션 적합성 평가
### 2.1 보안 평가
#### 보안 체크리스트
```markdown
## 보안 점검
### 인증 · 인가
- [ ] 강력한 인증 기능: _____
- [ ] 적절한 인가 제어: _____
- [ ] 세션 관리: _____
- [ ] 비밀번호 정책: _____
### 데이터 보호
- [ ] 입력값 검증: _____
- [ ] 출력 이스케이프: _____
- [ ] SQL 인젝션 대응: _____
- [ ] XSS 대응: _____
### 보안 평가 결과
| 항목 | 현재 | 프로덕션 요구 | 적합성 | 개선 필요도 |
|------|------|---------------|--------|-------------|
| 인증 | | | | |
| 인가 | | | | |
| 데이터 검증 | | | | |
| 통신 암호화 | | | | |
| 보안 헤더 | | | | |
```
### 2.2 성능 평가
#### 성능 측정
```markdown
## 성능 분석
### Core Web Vitals
- [ ] First Contentful Paint (FCP): _____ 초
- [ ] Largest Contentful Paint (LCP): _____ 초
- [ ] First Input Delay (FID): _____ ms
- [ ] Cumulative Layout Shift (CLS): _____
### Lighthouse 점수
- [ ] Performance: _____ / 100
- [ ] Accessibility: _____ / 100
- [ ] Best Practices: _____ / 100
- [ ] SEO: _____ / 100
```
## Phase 3: 차이 인식 · 명확화
### 3.1 프로덕션 이행 갭 분석
#### 기능 갭 분석
```markdown
## 기능 차이 맵
### 인증 · 인가 시스템
| 기능 | 프로토타입 | 프로덕션 요구 | 갭 | 우선순위 | 공수 추정 |
|------|-------------|----------|---------|--------|----------|
| 로그인 | | | | | |
| 사용자 등록 | | | | | |
| 권한 관리 | | | | | |
| 세션 관리 | | | | | |
| 비밀번호 재설정 | | | | | |
### 파일 관리
| 기능 | 프로토타입 | 프로덕션 요구 | 갭 | 우선순위 | 공수 추정 |
|------|------------|---------------|----|----------|-----------|
| 파일 업로드 | | | | | |
| 파일 목록 | | | | | |
| 파일 삭제 | | | | | |
| 파일 공유 | | | | | |
| 파일 검색 | | | | | |
```
#### 기술 갭 분석
```markdown
## 기술 차이 맵
### 보안
| 항목 | 현재 | 프로덕션 요구 | 구현 필요성 | 우선순위 | 공수 추정 |
|------|------|---------------|-------------|----------|-----------|
| HTTPS 대응 | | 필수 | | | |
| CSRF 대응 | | 필수 | | | |
| XSS 대응 | | 필수 | | | |
| 보안 헤더 | | 필수 | | | |
| 입력값 검증 | | 필수 | | | |
### 성능
| 항목 | 현재 | 프로덕션 요구 | 구현 필요성 | 우선순위 | 공수 추정 |
|------|------|---------------|-------------|----------|-----------|
| 코드 스플리팅 | | 권장 | | | |
| 이미지 최적화 | | 필수 | | | |
| 캐시 전략 | | 필수 | | | |
| 번들 최적화 | | 필수 | | | |
| 렌더링 최적화 | | 권장 | | | |
```
### 3.2 우선순위화
#### 리스크 기반 우선순위
```markdown
## 개선 항목 우선순위
### 고우선(필수 · 리스크 높음)
1. **보안 대응**
- 취약점: _____
- 영향도: _____
- 공수: _____
2. **성능 개선**
- 문제: _____
- 영향도: _____
- 공수: _____
### 중우선(중요 · 리스크 중간)
1. **모니터링 · 로그 기능**
- 필요성: _____
- 영향도: _____
- 공수: _____
### 저우선(권장 · 리스크 낮음)
1. **UI/UX 개선**
- 개선점: _____
- 영향도: _____
- 공수: _____
```
## 산출물 · 다음 단계
### 분석 결과 요약
```markdown
## 분석 결과 요약
### 프로덕션 적합성 평가
- **종합 평가**: _____ / 100점
- **보안**: _____ / 100점
- **성능**: _____ / 100점
- **가용성**: _____ / 100점
- **유지보수성**: _____ / 100점
### 주요 갭
1. **최중요 과제**: _____
2. **보안 과제**: _____
3. **성능 과제**: _____
4. **운영 과제**: _____
### 권장 구현 전략
- **구현 기간**: _____ 주
- **필요 리소스**: _____
- **리스크 요인**: _____
- **성공 확률**: _____%
```
---
**이 문서를 활용하면 프로토타입의 현재 상태를 정확히 파악하고, 프로덕션 이행에 필요한 차이를 명확히 할 수 있습니다.
다음 단계로, 이 분석 결과를 바탕으로 상세 설계와 구현 계획 수립을 진행합니다.**
02-implementation-planning.md
경로 : .cursor/commands/5_implementation/02-implementation-planning.md
# 프로덕션 개발 구현 계획서 작성 가이드
## 개요
이 문서는 프로토타입 분석(doc08)과 상세 설계(doc06) 결과를 바탕으로, 프로덕션 환경을 향한 구현 계획을 단계적으로 수립하는 프로세스를 정의합니다. 체크리스트 형식으로 빈틈없는 계획 수립을 지원합니다.
## 기본 방침
### 계획 수립 접근
1. **Phase 1: 전제조건 확인** - 분석 결과와 설계서 완성도 점검
2. **Phase 2: 구현 전략 수립** - 우선순위와 구현 방침 결정
3. **Phase 3: 상세 구현 계획** - 작업 분해 및 공수 산정
4. **Phase 4: 리스크 관리 계획** - 리스크 식별 및 대응책 수립
5. **Phase 5: 품질 보증 계획** - 테스트·리뷰·배포 전략
### 성공 기준
- **완료 가능성**: 현실적인 공수와 일정
- **품질 보증**: 프로덕션 요구사항 충족
- **리스크 관리**: 잠재 이슈의 사전 대응
- **단계적 구현**: 점진적 릴리스와 피드백 반영
## Phase 1: 전제조건 확인
### 1.1 프로토타입 분석 결과 확인
```markdown
## 프로토타입 분석 완료 체크
### 기술 구성 분석
- [ ] 프런트엔드 기술 스택 분석 완료
- [ ] 백엔드 기술 스택 분석 완료
- [ ] 데이터베이스 구성 분석 완료
- [ ] 인증·보안 기능 분석 완료
- [ ] 외부 연계·API 분석 완료
### 기능 구현 현황 분석
- [ ] 구현 완료 기능 목록 작성
- [ ] 기능 품질 평가 완료(각 기능 완성도 %)
- [ ] 미구현 기능 목록 작성
- [ ] 기능 간 의존성 분석 완료
### 프로덕션 적합성 평가
- [ ] 보안 평가 완료(점수: ___/100)
- [ ] 성능 평가 완료(점수: ___/100)
- [ ] 가용성 평가 완료(점수: ___/100)
- [ ] 유지보수성 평가 완료(점수: ___/100)
- [ ] 운영성 평가 완료(점수: ___/100)
### 갭 분석
- [ ] 기능 갭 목록 작성 완료
- [ ] 기술 갭 목록 작성 완료
- [ ] 보안 갭 목록 작성 완료
- [ ] 성능 갭 목록 작성 완료
- [ ] 운영 갭 목록 작성 완료
```
### 1.2 상세 설계서 확인
```markdown
## 상세 설계서 완성도 체크
### 시스템 설계
- [ ] 시스템 개요·아키텍처 설계 완료
- [ ] 4+1 뷰 설계 완료
- [ ] 논리 뷰(컴포넌트 다이어그램)
- [ ] 개발 뷰(디렉터리 구조)
- [ ] 프로세스 뷰(시퀀스 다이어그램)
- [ ] 물리 뷰(배포 다이어그램)
- [ ] 유스케이스 뷰
- [ ] 컴포넌트 설계 상세 완료
### 데이터·API 설계
- [ ] 데이터 모델 설계 완료
- [ ] 데이터베이스 스키마 설계 완료
- [ ] API 설계서 완료(전 엔드포인트)
- [ ] 데이터 플로우 설계 완료
### UI/UX·보안 설계
- [ ] 사용자 인터페이스 설계 완료
- [ ] 사용자 경험 설계 완료
- [ ] 보안 설계 완료
- [ ] 에러 처리 설계 완료
### 구현 상세
- [ ] 주요 컴포넌트 구현 예시 작성 완료
- [ ] 데이터 모델 구현 예시 작성 완료
- [ ] API 구현 예시 작성 완료
- [ ] UI 구현 예시 작성 완료
```
## Phase 2: 구현 전략 수립
### 2.1 우선순위 결정
```markdown
## 구현 우선순위 매트릭스
### 고우선(필수·리스크 높음·의존성 강함)
- [ ] **보안 기반**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **인증 시스템**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **코어 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
### 중우선(중요·리스크 중간·의존성 중간)
- [ ] **데이터 관리 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **UI/UX 개선**
- 구현 항목: _____
- 이유: _____
- 기한: _____
### 저우선(권장·리스크 낮음·의존성 약함)
- [ ] **부가 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **최적화 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
```
### 2.2 구현 방침 결정
```markdown
## 구현 전략 체크
### 개발 접근
- [ ] **단계적 구현** vs **일괄 구현**
- 선택: _____
- 이유: _____
- [ ] **기능 기반** vs **레이어 기반**
- 선택: _____
- 이유: _____
### 기술 방침
- [ ] **기존 코드 활용도**
- 활용률: _____%
- 활용 방침: _____
- [ ] **신규 기술 도입**
- 도입 기술: _____
- 도입 이유: _____
- 리스크 평가: _____
### 릴리스 전략
- [ ] **단계적 릴리스 계획**
- Phase 1: _____ (기능: _____)
- Phase 2: _____ (기능: _____)
- Phase 3: _____ (기능: _____)
- [ ] **피드백 수집 계획**
- 방법: _____
- 타이밍: _____
- 대상: _____
```
## Phase 3: 상세 구현 계획
### 3.1 작업 분해
```markdown
## 구현 작업 분해 체크
### 보안 기반 구현
- [ ] **인증 시스템**
- [ ] JWT 구현(공수: ___일)
- [ ] 세션 관리(공수: ___일)
- [ ] 비밀번호 암호화(공수: ___일)
- [ ] 로그인·로그아웃(공수: ___일)
- [ ] **인가 시스템**
- [ ] 권한 관리(공수: ___일)
- [ ] 접근 제어(공수: ___일)
- [ ] API 보호(공수: ___일)
- [ ] **보안 대응**
- [ ] CSRF 대응(공수: ___일)
- [ ] XSS 대응(공수: ___일)
- [ ] 보안 헤더(공수: ___일)
- [ ] 입력값 검증(공수: ___일)
### 코어 기능 구현
- [ ] **사용자 관리**
- [ ] 사용자 등록(공수: ___일)
- [ ] 프로필 관리(공수: ___일)
- [ ] 비밀번호 변경(공수: ___일)
- [ ] **파일 관리**
- [ ] 파일 업로드(공수: ___일)
- [ ] 파일 목록 표시(공수: ___일)
- [ ] 파일 삭제(공수: ___일)
- [ ] 파일 공유(공수: ___일)
- [ ] 파일 검색(공수: ___일)
### 데이터베이스 구현
- [ ] **스키마 구현**
- [ ] 테이블 생성(공수: ___일)
- [ ] 인덱스 설정(공수: ___일)
- [ ] 제약 설정(공수: ___일)
- [ ] **데이터 접근 계층**
- [ ] ORM 설정(공수: ___일)
- [ ] 리포지토리 패턴(공수: ___일)
- [ ] 트랜잭션 관리(공수: ___일)
### API 구현
- [ ] **RESTful API**
- [ ] 엔드포인트 구현(공수: ___일)
- [ ] 요청·응답 처리(공수: ___일)
- [ ] 에러 핸들링(공수: ___일)
- [ ] API 문서 생성(공수: ___일)
### 프런트엔드 구현
- [ ] **UI 컴포넌트**
- [ ] 공통 컴포넌트(공수: ___일)
- [ ] 페이지 컴포넌트(공수: ___일)
- [ ] 폼 컴포넌트(공수: ___일)
- [ ] **상태 관리**
- [ ] 글로벌 상태(공수: ___일)
- [ ] API 연동(공수: ___일)
- [ ] 캐시 전략(공수: ___일)
```
### 3.2 GitHub 개발 효율화 전략
```markdown
## GitHub 연계를 통한 개발 효율화 체크
### 브랜치 전략 설계
- [ ] **기본 브랜치 구성**
```
main (프로덕션 릴리스용)
├── develop (개발 통합용)
├── feature/database-foundation
├── feature/auth-implementation
├── feature/core-functionality
└── feature/ui-enhancement
```
- [ ] **브랜치 네이밍 규칙**
- feature/[기능명] (예: feature/user-authentication)
- hotfix/[수정내용] (예: hotfix/security-patch)
- release/[버전] (예: release/v1.0.0)
- [ ] **브랜치와 Phase의 대응 관계**
- Phase 1 (보안 기반): `feature/security-foundation`
- Phase 2 (코어 기능): `feature/core-functionality`
- Phase 3 (추가 기능): `feature/additional-features`
### 풀리퀘스트(PR) 전략
- [ ] **PR 작성 규칙**
- [ ] 기능 구현 완료 시 자동 PR 생성 설정
- [ ] 테스트 실행 결과 자동 첨부 설정
- [ ] 코드 리뷰 필수 설정
- [ ] CI/CD 파이프라인 성공 조건 설정
- [ ] **PR 템플릿 설정**
```markdown
## 구현 내용
- [ ] 기능 개요: _____
- [ ] 변경 파일 목록: _____
- [ ] 테스트 실행 결과: _____
## 체크리스트
- [ ] 단위 테스트 실행 완료
- [ ] 코드 리뷰 완료
- [ ] 보안 점검 완료
- [ ] 성능 테스트 완료
```
### GitHub Actions CI/CD 설정
- [ ] **feature/ 브랜치 Push 시**
- [ ] 단위 테스트 자동 실행 설정
- [ ] 코드 커버리지 확인 설정
- [ ] 정적 분석(ESLint 등) 설정
- [ ] 테스트 실패 시 PR 머지 차단 설정
- [ ] **develop 머지 시**
- [ ] 전체 통합 테스트 실행 설정
- [ ] 성능 테스트 설정
- [ ] 보안 스캔 설정
- [ ] 성공 시에만 main 머지 허용 설정
- [ ] **main 머지 시**
- [ ] 프로덕션 배포 자동 실행 설정
- [ ] 롤백 기능 설정
- [ ] 모니터링 알림 설정
### GitHub MCP 서버 활용 계획
- [ ] **자동화 대상 작업 정의**
- [ ] 브랜치 생성·전환 자동화
- [ ] 테스트 실행·결과 확인 자동화
- [ ] PR 생성·머지 자동화
- [ ] 배포·모니터링 자동화
- [ ] **MCP 연계 커맨드 설계**
```
「Phase 1 시작」→ 자동으로 feature/security-foundation 브랜치 생성
「기능 완료」→ 자동으로 테스트 실행·PR 생성·리뷰 요청
「테스트 완료」→ 자동으로 통합 테스트·develop 머지
「Phase 완료」→ 자동으로 다음 Phase 브랜치 생성·태스크 이관
```
### 단계별 통합 전략
- [ ] **기능 단위 통합**
- [ ] 각 기능 구현 완료 시 개별 테스트 실행
- [ ] feature/* → develop 머지 조건 설정
- [ ] 머지 후 자동 통합 테스트 실행
- [ ] **Phase단위 통합**
- [ ] Phase 완료 시 종합 테스트 실행
- [ ] 품질 게이트 통과 조건 설정
- [ ] 다음 Phase 시작 조건 설정
- [ ] **릴리스 통합**
- [ ] develop → main 머지 조건 설정
- [ ] 프로덕션 배포 전 최종 점검 프로세스
- [ ] 롤백 절차 자동화 설정
### 개발 효율화 메트릭
- [ ] **효율화 목표 설정**
- 기존 수동 작업 시간: ___분/일
- 자동화 후 작업 시간: ___분/일
- 효율화율 목표: _____%
- [ ] **품질 향상 메트릭**
- 버그 검출률 향상 목표: _____%
- 테스트 커버리지 목표: _____%
- 배포 성공률 목표: _____%
### 프로토타입에서 본격 구현으로의 전환 전략
- [ ] **단계적 대체 계획**
- [ ] 프로토타입 기능의 본 구현으로의 대체 순서 정의
- [ ] 동작 비교 테스트 자동화 설정
- [ ] 문제 발생 시 프로토타입 복귀 절차 설정
- [ ] **데이터 마이그레이션 자동화**
- [ ] 프로토타입 목데이터 → 실DB 마이그레이션 스크립트
- [ ] 마이그레이션 테스트 자동 실행 설정
- [ ] 롤백 절차 자동화 설정
```
### 3.3 공수 산정·스케줄
```markdown
## 공수 산정·스케줄 체크
### 공수 요약
- [ ] **총 공수 산정**: ___일
- 보안 기반: ___일
- 코어 기능: ___일
- 데이터베이스: ___일
- API: ___일
- 프런트엔드: ___일
- 테스트: ___일
- 배포·운영: ___일
### 스케줄 계획
- [ ] **Phase 1 (보안 기반)**
- 시작일: _____
- 완료 예정일: _____
- 마일스톤: _____
- [ ] **Phase 2 (코어 기능)**
- 시작일: _____
- 완료 예정일: _____
- 마일스톤: _____
- [ ] **Phase 3 (추가 기능)**
- 시작일: _____
- 완료 예정일: _____
- 마일스톤: _____
### 리소스 계획
- [ ] **개발자 배치**
- 프런트엔드: ___명
- 백엔드: ___명
- 데이터베이스: ___명
- DevOps: ___명
- [ ] **외부 리소스**
- 필요한 외부 서비스: _____
- 필요한 툴·라이선스: _____
- 예산: _____
```
## Phase 4: 리스크 관리 계획
### 4.1 리스크 식별·평가
```markdown
## 리스크 관리 체크
### 기술 리스크
- [ ] **기술적 난이도**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
- [ ] **성능 문제**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
- [ ] **보안 취약점**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
### 스케줄 리스크
- [ ] **공수 산정 오차**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
- [ ] **외부 의존성**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
### 품질 리스크
- [ ] **요건 변경**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
- [ ] **테스트 부족**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응책: _____
```
### 4.2 리스크 대응 계획
```markdown
## 리스크 대응 실행 계획
### 예방책
- [ ] **기술 검증(PoC) 수행**
- 대상 기술: _____
- 수행 기간: _____
- 성공 기준: _____
- [ ] **프로토타입 확장 테스트**
- 테스트 항목: _____
- 수행 기간: _____
- 성공 기준: _____
### 비상 대응책
- [ ] **대체 기술 옵션**
- 주요 기술: _____ → 대체 기술: _____
- 전환 조건: _____
- 전환 공수: _____
- [ ] **기능 축소 계획**
- 축소 후보 기능: _____
- 축소 조건: _____
- 영향 평가: _____
### 모니터링 계획
- [ ] **진척 모니터링 지표**
- 지표: _____
- 측정 주기: _____
- 알림 조건: _____
- [ ] **품질 모니터링 지표**
- 지표: _____
- 측정 주기: _____
- 알림 조건: _____
```
## Phase 5: 품질 보증 계획
### 5.1 테스트 전략
```markdown
## 테스트 계획 체크
### 단위 테스트
- [ ] **프론트엔드 테스트**
- 테스트 프레임워크: _____
- 커버리지 목표: _____%
- 구현 공수: ___일
- [ ] **백엔드 테스트**
- 테스트 프레임워크: _____
- 커버리지 목표: _____%
- 구현 공수: ___일
### 통합 테스트
- [ ] **API 통합 테스트**
- 테스트 범위: _____
- 테스트 도구: _____
- 구현 공수: ___일
- [ ] **데이터베이스 통합 테스트**
- 테스트 범위: _____
- 테스트 데이터 전략: _____
- 구현 공수: ___일
### E2E 테스트
- [ ] **브라우저 자동화 테스트**
- 테스트 도구: _____
- 테스트 시나리오 수: _____
- 구현 공수: ___일
- [ ] **모바일 대응 테스트**
- 테스트 단말: _____
- 테스트 시나리오: _____
- 구현 공수: ___일
### 성능 테스트
- [ ] **부하 테스트**
- 테스트 도구: _____
- 부하 조건: _____
- 실행 공수: ___일
- [ ] **보안 테스트**
- 테스트 항목: _____
- 테스트 도구: _____
- 실행 공수: ___일
```
### 5.2 코드 리뷰·CI/CD
```markdown
## 품질 관리 프로세스 체크
### 코드 리뷰
- [ ] **리뷰 프로세스 정의**
- 리뷰 기준: _____
- 리뷰 담당자: _____
- 리뷰 도구: _____
- [ ] **자동 체크 설정**
- 정적 분석 도구: _____
- 코드 포매터: _____
- 린터 설정: _____
### CI/CD 파이프라인
- [ ] **지속적 통합(CI)**
- CI 도구: _____
- 빌드·테스트 자동화: _____
- 품질 게이트 설정: _____
- [ ] **지속적 배포(CD)**
- 배포 도구: _____
- 환경 구성: _____
- 롤백 전략: _____
### 모니터링·로그
- [ ] **애플리케이션 모니터링**
- 모니터링 도구: _____
- 메트릭 정의: _____
- 알림 설정: _____
- [ ] **로그 관리**
- 로그 수집 도구: _____
- 로그 레벨 정의: _____
- 로그 분석 방법: _____
```
## 구현 계획서 완료 체크
### 최종 확인
```markdown
## 구현 계획서 완성도 체크
### 계획서 구성 요소
- [ ] 프로토타입 분석 결과 반영 완료
- [ ] 상세 설계서 내용 반영 완료
- [ ] 구현 우선순위 결정 완료
- [ ] 상세 태스크 분해 완료
- [ ] 공수 산정·스케줄 완료
- [ ] 리스크 관리 계획 완료
- [ ] 품질 보증 계획 완료
### 실현 가능성 검증
- [ ] **기술적 실현 가능성**: 확인됨
- [ ] **공수·스케줄 타당성**: 확인됨
- [ ] **리소스 확보 가능성**: 확인됨
- [ ] **품질 요구 달성 가능성**: 확인됨
### 이해관계자 합의
- [ ] **개발팀 합의**: 취득 완료
- [ ] **프로젝트 매니저 합의**: 취득 완료
- [ ] **클라이언트 합의**: 취득 완료
### 다음 스텝 준비
- [ ] **개발 환경 준비 계획**: 작성 완료
- [ ] **킥오프 준비**: 완료
- [ ] **진척 관리 체계**: 구축 완료
```
## 구현 계획서 템플릿
### 산출물 요약
```markdown
# 본번(프로덕션) 개발 구현 계획서
## 프로젝트 개요
- **프로젝트명**: _____
- **구현 기간**: _____ ~ _____
- **총 공수**: ___일
- **팀 구성**: _____
## 구현 전략
- **구현 방침**: _____
- **기술 스택**: _____
- **릴리스 전략**: _____
## 주요 마일스톤
1. **Phase 1**: _____ (_____)
2. **Phase 2**: _____ (_____)
3. **Phase 3**: _____ (_____)
## 리스크 요인·대응
- **주요 리스크**: _____
- **대응책**: _____
- **비상 대응**: _____
## 품질 보증
- **테스트 전략**: _____
- **품질 기준**: _____
- **모니터링 체계**: _____
```
## GitHub 연계 실천 가이드
### 구현 계획서 작성 타이밍과 위치
```markdown
## GitHub 연계를 통한 구현 계획서 작성 플로우
### Phase 0: 계획서 작성 준비
- [ ] **레포지토리 준비**
- [ ] 프로젝트 레포지토리 생성·클론
- [ ] 기본 브랜치 구성 설정(main, develop)
- [ ] GitHub Actions 워크플로우 기본 설정
- [ ] Issue·PR 템플릿 설정
- [ ] **계획서 작성 환경**
- [ ] `/docs/implementation-plan/` 디렉터리 생성
- [ ] 구현 계획서 템플릿 파일 배치
- [ ] 계획서 리뷰용 브랜치 생성(`planning/implementation-plan`)
### 계획서 작성·리뷰 플로우
1. **계획서 드래프트 작성**
```
git checkout -b planning/implementation-plan
# 구현 계획서 작성·편집
git add docs/implementation-plan/
git commit -m "docs: 구현 계획서 드래프트 작성"
git push origin planning/implementation-plan
```
2. **계획서 리뷰 PR 생성**
- GitHub에서 PR 생성
- 이해관계자를 리뷰어로 지정
- 계획서 각 섹션에 대한 코멘트·디스커션 진행
3. **계획서 확정·머지**
- 리뷰 완료 후 develop 브랜치에 머지
- 확정된 계획서를 기반으로 구현 시작
### 구현 시작 시 GitHub 활용
- [ ] **구현 Phase 시작 시**
```
# 예: Phase 1 보안 기반 구현 시작
git checkout develop
git pull origin develop
git checkout -b feature/security-foundation
# GitHub Issue 생성(자동화 가능)
gh issue create --title "Phase 1: 보안 기반 구현" \
--body-file docs/implementation-plan/phase1-tasks.md \
--label "phase-1,security,implementation"
```
- [ ] **구현 진척 관리**
- GitHub Projects로 Phase별 칸반 보드 생성
- 각 태스크를 Issue로 관리
- PR 생성 시 관련 Issue 자동 링크
### MCP 서버 연계를 통한 효율화
- [ ] **계획서 작성 지원**
```
「구현 계획서를 작성해줘」
→ 자동으로 계획서 템플릿 생성·브랜치 생성·PR 생성
```
- [ ] **Phase 관리 자동화**
```
「Phase 1을 시작해」
→ 자동으로 브랜치 생성·Issue 생성·태스크 목록 생성
「Phase 1 완료, Phase 2 시작」
→ 자동으로 PR 생성·머지·다음 Phase 브랜치 생성
```
### 개발 효율화의 실현 예
```markdown
## 기존 방식 vs GitHub 연계 효율화
### 기존 방식(하루 작업 예)
1. 구현 계획 확인(10분)
2. 수동 브랜치 생성·전환(5분)
3. 코드 구현(6시간)
4. 수동 테스트 실행(30분)
5. 수동 커밋·푸시(10분)
6. 수동 PR 생성(15분)
7. 수동 리뷰 요청(10분)
8. 수동 머지·다음 태스크 준비(15분)
**총 사무 작업 시간: 1시간 35분/일**
### GitHub + MCP 연계 방식
1. 「오늘 태스크 시작」(30초)
→ 자동으로 계획 확인·브랜치 준비·환경 구축
2. 코드 구현(6시간)
3. 「구현 완료」(30초)
→ 자동으로 테스트 실행·PR 생성·리뷰 요청·다음 태스크 준비
**총 사무 작업 시간: 1분/일**
### 효율화 효과
- **시간 절감**: 94분/일 → 1분/일(99% 절감)
- **품질 향상**: 자동 테스트·리뷰로 품질 안정
- **집중력 유지**: 사무 작업으로 인한 중단 없이 개발 집중 가능
```
### 다인개발에서의 가치
```markdown
## 팀 개발에서의 GitHub 연계 가치
### 기존 과제
- 브랜치 관리 혼선
- 머지 충돌 빈발
- 테스트 실행의 개인 의존
- 리뷰 프로세스의 비일관성
- 진척 파악의 어려움
### GitHub 연계에 의한 해결
- [ ] **안전한 병렬 개발**
- 브랜치 전략으로 충돌 최소화
- 자동 테스트로 품질 보증
- PR 필수로 리뷰 프로세스 표준화
- [ ] **투명한 진척 관리**
- GitHub Projects로 가시화
- 자동화로 정확한 진척 반영
- 실시간 상태 공유
- [ ] **지식 공유 촉진**
- PR에서의 코드 리뷰·논의
- 구현 계획서의 공유·갱신
- 자동화 노하우 축적
### 구현 계획서의 지속적 개선
- [ ] **피드백 수집**
- 각 Phase 완료 시 회고
- 계획 vs 실적 차이 분석
- 개선점 문서화
- [ ] **계획서 템플릿 진화**
- 프로젝트 경험 반영
- 업계 베스트 프랙티스 도입
- 팀 고유 노하우 축적
```
---
**이 체크리스트를 활용하면, 프로토타입 분석과 상세 설계 결과를 빠짐없이 구현 계획에 반영하고, GitHub 연계를 통해 효율적인 개발 플로우를 구축할 수 있습니다.
각 페이즈의 체크 항목을 차례로 완료해, 누락 없는 포괄적 계획을 수립하고 자동화로 큰 폭의 효율 향상을 이루세요.**
03-implementation-planningf-no-github.md
경로 : .cursor/commands/5_implementation/03-implementation-planningf-no-github.md
|---------|------|------------|----------|
| 1.1.0 | 2025-07-10 | MINOR | 카테고리 기반 구성 전환, 기능 확장 |
| 1.0.0 | 2025-05-28 | MAJOR | 초기버전 작성 |
---
# 프로덕션 개발 구현 계획서 작성 가이드
## 개요
본 문서는 프로토타입 분석(doc08)과 상세 설계(doc06) 결과를 바탕으로, 프로덕션 환경을 향한 구현 계획을 단계적으로 수립하는 프로세스를 정의합니다. 체크리스트 형식으로 빈틈없는 계획 수립을 지원합니다.
## 기본 방침
### 계획 수립 접근법
1. **Phase 1: 전제 조건 확인** - 분석 결과와 설계서의 완성도 점검
2. **Phase 2: 구현 전략 수립** - 우선순위와 구현 방침 결정
3. **Phase 3: 상세 구현 계획** - 태스크 분해와 공수 산정
4. **Phase 4: 리스크 관리 계획** - 리스크 식별과 대응책 수립
5. **Phase 5: 품질 보증 계획** - 테스트·리뷰·배포 전략
### 성공 기준
- **완료 가능성**: 현실적인 공수와 일정
- **품질 보증**: 프로덕션 요구사항 적합
- **리스크 관리**: 잠재 문제의 사전 대응
- **단계적 구현**: 단계적 릴리스와 피드백
## Phase 1: 전제 조건 확인
### 1.1 프로토타입 분석 결과 확인
```markdown
## 프로토타입 분석 완료 체크
### 기술 구성 분석
- [ ] 프론트엔드 기술 스택 분석 완료
- [ ] 백엔드 기술 스택 분석 완료
- [ ] 데이터베이스 구성 분석 완료
- [ ] 인증·보안 기능 분석 완료
- [ ] 외부 연계·API 분석 완료
### 기능 구현 현황 분석
- [ ] 구현 완료 기능 목록 작성 완료
- [ ] 기능 품질 평가 완료(각 기능의 완성도 %)
- [ ] 미구현 기능 목록 작성 완료
- [ ] 기능 간 의존 관계 분석 완료
### 프로덕션 적합성 평가
- [ ] 보안 평가 완료(점수: ___/100)
- [ ] 성능 평가 완료(점수: ___/100)
- [ ] 가용성 평가 완료(점수: ___/100)
- [ ] 유지보수성 평가 완료(점수: ___/100)
- [ ] 운용성 평가 완료(점수: ___/100)
### 갭 분석
- [ ] 기능 갭 목록 작성 완료
- [ ] 기술 갭 목록 작성 완료
- [ ] 보안 갭 목록 작성 완료
- [ ] 성능 갭 목록 작성 완료
- [ ] 운영 갭 목록 작성 완료
```
### 1.2 상세 설계서 확인
```markdown
## 상세 설계서 완성도 체크
### 시스템 설계
- [ ] 시스템 개요·아키텍처 설계 완료
- [ ] 4+1 뷰 설계 완료
- [ ] 논리 뷰(컴포넌트 다이어그램)
- [ ] 개발 뷰(디렉터리 구조)
- [ ] 프로세스 뷰(시퀀스 다이어그램)
- [ ] 물리 뷰(디플로이먼트 다이어그램)
- [ ] 유스케이스 뷰
- [ ] 컴포넌트 설계 상세 완료
### 데이터·API 설계
- [ ] 데이터 모델 설계 완료
- [ ] 데이터베이스 스키마 설계 완료
- [ ] API 설계서 완료(전 엔드포인트)
- [ ] 데이터 플로우 설계 완료
### UI/UX·보안 설계
- [ ] 사용자 인터페이스 설계 완료
- [ ] 사용자 경험(UX) 설계 완료
- [ ] 보안 설계 완료
- [ ] 에러 처리 설계 완료
### 구현 상세
- [ ] 핵심 컴포넌트 구현 예시 작성 완료
- [ ] 데이터 모델 구현 예시 작성 완료
- [ ] API 구현 예시 작성 완료
- [ ] UI 구현 예시 작성 완료
```
## Phase 2: 구현 전략 수립
### 2.1 우선순위 결정
```markdown
## 구현 우선순위 매트릭스
### 고우선(필수·리스크 高·의존성 강)
- [ ] **보안 기반**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **인증 시스템**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **코어 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
### 중우선(중요·리스크 中·의존성 중)
- [ ] **데이터 관리 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **UI/UX 개선**
- 구현 항목: _____
- 이유: _____
- 기한: _____
### 저우선(권장·리스크 低·의존성 약)
- [ ] **부가 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
- [ ] **최적화 기능**
- 구현 항목: _____
- 이유: _____
- 기한: _____
```
### 2.2 구현 방침 결정
```markdown
## 구현 전략 체크
### 개발 접근
- [ ] **단계적 구현** vs **일괄 구현**
- 선택: _____
- 이유: _____
- [ ] **기능 기준** vs **레이어 기준**
- 선택: _____
- 이유: _____
### 기술 방침
- [ ] **기존 코드 활용도**
- 활용률: _____%
- 활용 방침: _____
- [ ] **신규 기술 도입**
- 도입 기술: _____
- 도입 이유: _____
- 리스크 평가: _____
### 릴리스 전략
- [ ] **단계적 릴리스 계획**
- Phase 1: _____ (기능: _____)
- Phase 2: _____ (기능: _____)
- Phase 3: _____ (기능: _____)
- [ ] **피드백 수집 계획**
- 방법: _____
- 타이밍: _____
- 대상: _____
```
## Phase 3: 상세 구현 계획
### 3.1 태스크 분해
```markdown
## 구현 태스크 분해 체크
### 보안 기반 구현
- [ ] **인증 시스템**
- [ ] JWT 구현(공수: ___일)
- [ ] 세션 관리(공수: ___일)
- [ ] 비밀번호 암호화(공수: ___일)
- [ ] 로그인·로그아웃(공수: ___일)
- [ ] **인가 시스템**
- [ ] 권한 관리(공수: ___일)
- [ ] 접근 제어(공수: ___일)
- [ ] API 보호(공수: ___일)
- [ ] **보안 대책**
- [ ] CSRF 대응(공수: ___일)
- [ ] XSS 대응(공수: ___일)
- [ ] 보안 헤더(공수: ___일)
- [ ] 입력값 검증(공수: ___일)
### 코어 기능 구현
- [ ] **사용자 관리**
- [ ] 사용자 등록(공수: ___일)
- [ ] 프로필 관리(공수: ___일)
- [ ] 비밀번호 변경(공수: ___일)
- [ ] **파일 관리**
- [ ] 파일 업로드(공수: ___일)
- [ ] 파일 목록 표시(공수: ___일)
- [ ] 파일 삭제(공수: ___일)
- [ ] 파일 공유(공수: ___일)
- [ ] 파일 검색(공수: ___일)
### 데이터베이스 구현
- [ ] **스키마 구현**
- [ ] 테이블 생성(공수: ___일)
- [ ] 인덱스 설정(공수: ___일)
- [ ] 제약 설정(공수: ___일)
- [ ] **데이터 접근 계층**
- [ ] ORM 설정(공수: ___일)
- [ ] 리포지토리 패턴(공수: ___일)
- [ ] 트랜잭션 관리(공수: ___일)
### API 구현
- [ ] **RESTful API**
- [ ] 엔드포인트 구현(공수: ___일)
- [ ] 요청·응답 처리(공수: ___일)
- [ ] 에러 핸들링(공수: ___일)
- [ ] API 문서 생성(공수: ___일)
### 프론트엔드 구현
- [ ] **UI 컴포넌트**
- [ ] 공통 컴포넌트(공수: ___일)
- [ ] 페이지 컴포넌트(공수: ___일)
- [ ] 폼 컴포넌트(공수: ___일)
- [ ] **상태 관리**
- [ ] 글로벌 상태(공수: ___일)
- [ ] API 연동(공수: ___일)
- [ ] 캐시 전략(공수: ___일)
```
### 3.2 공수 산정·스케줄
```markdown
## 공수 산정·스케줄 체크
### 공수 요약
- [ ] **총 공수 산정**: ___일
- 보안 기반: ___일
- 코어 기능: ___일
- 데이터베이스: ___일
- API: ___일
- 프론트엔드: ___일
- 테스트: ___일
- 배포·운영: ___일
### 스케줄 계획
- [ ] **Phase 1(보안 기반)**
- 시작일: _____
- 완료 예정일: _____
- 마일스톤: _____
- [ ] **Phase 2(코어 기능)**
- 시작일: _____
- 완료 예정일: _____
- 마일스톤: _____
- [ ] **Phase 3(추가 기능)**
- 시작일: _____
- 완료 예정일: _____
- 마일스톤: _____
### 리소스 계획
- [ ] **개발자 배치**
- 프론트엔드: ___명
- 백엔드: ___명
- 데이터베이스: ___명
- DevOps: ___명
- [ ] **외부 리소스**
- 필요한 외부 서비스: _____
- 필요한 도구·라이선스: _____
- 예산: _____
```
## Phase 4: 리스크 관리 계획
### 4.1 리스크 식별·평가
```markdown
## 리스크 관리 체크
### 기술 리스크
- [ ] **기술적 난이도**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
- [ ] **성능 이슈**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
- [ ] **보안 취약점**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
### 일정 리스크
- [ ] **공수 산정 오차**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
- [ ] **외부 의존성**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
### 품질 리스크
- [ ] **요구사항 변경**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
- [ ] **테스트 부족**
- 리스크: _____
- 발생 확률: ___%
- 영향도: _____
- 대응: _____
```
### 4.2 리스크 대응 계획
```markdown
## 리스크 대응 실행 계획
### 예방책
- [ ] **기술 검증(PoC) 수행**
- 대상 기술: _____
- 수행 기간: _____
- 성공 기준: _____
- [ ] **프로토타입 확장 테스트**
- 테스트 항목: _____
- 수행 기간: _____
- 성공 기준: _____
### 비상 대응책
- [ ] **대체 기술 옵션**
- 주요 기술: _____ → 대체 기술: _____
- 전환 조건: _____
- 전환 공수: _____
- [ ] **기능 축소 계획**
- 축소 후보 기능: _____
- 축소 조건: _____
- 영향 평가: _____
### 모니터링 계획
- [ ] **진척 모니터링 지표**
- 지표: _____
- 측정 주기: _____
- 알림 조건: _____
- [ ] **품질 모니터링 지표**
- 지표: _____
- 측정 주기: _____
- 알림 조건: _____
```
## Phase 5: 품질 보증 계획
### 5.1 테스트 전략
```markdown
## 테스트 계획 체크
### 단위 테스트
- [ ] **프론트엔드 테스트**
- 테스트 프레임워크: _____
- 커버리지 목표: _____%
- 구현 공수: ___일
- [ ] **백엔드 테스트**
- 테스트 프레임워크: _____
- 커버리지 목표: _____%
- 구현 공수: ___일
### 통합 테스트
- [ ] **API 통합 테스트**
- 테스트 범위: _____
- 테스트 도구: _____
- 구현 공수: ___일
- [ ] **데이터베이스 통합 테스트**
- 테스트 범위: _____
- 테스트 데이터 전략: _____
- 구현 공수: ___일
### E2E 테스트
- [ ] **브라우저 자동 테스트**
- 테스트 도구: _____
- 테스트 시나리오 수: _____
- 구현 공수: ___일
- [ ] **모바일 대응 테스트**
- 테스트 단말: _____
- 테스트 시나리오: _____
- 구현 공수: ___일
### 성능 테스트
- [ ] **부하 테스트**
- 테스트 도구: _____
- 부하 조건: _____
- 실행 공수: ___일
- [ ] **보안 테스트**
- 테스트 항목: _____
- 테스트 도구: _____
- 실행 공수: ___일
```
### 5.2 코드 리뷰·CI/CD
```markdown
## 품질 관리 프로세스 체크
### 코드 리뷰
- [ ] **리뷰 프로세스 정의**
- 리뷰 기준: _____
- 리뷰 담당자: _____
- 리뷰 도구: _____
- [ ] **자동 체크 설정**
- 정적 분석 도구: _____
- 코드 포매터: _____
- 린터 설정: _____
### CI/CD 파이프라인
- [ ] **지속적 통합(CI)**
- CI 도구: _____
- 빌드·테스트 자동화: _____
- 품질 게이트 설정: _____
- [ ] **지속적 배포(CD)**
- 배포 도구: _____
- 환경 구성: _____
- 롤백 전략: _____
### 모니터링·로그
- [ ] **애플리케이션 모니터링**
- 모니터링 도구: _____
- 메트릭 정의: _____
- 알림 설정: _____
- [ ] **로그 관리**
- 로그 수집 도구: _____
- 로그 레벨 정의: _____
- 로그 분석 방법: _____
```
## 구현 계획서 완료 체크
### 최종 확인
```markdown
## 구현 계획서 완성도 체크
### 계획서 구성 요소
- [ ] 프로토타입 분석 결과 반영 완료
- [ ] 상세 설계서 내용 반영 완료
- [ ] 구현 우선순위 결정 완료
- [ ] 상세 태스크 분해 완료
- [ ] 공수 산정·스케줄 완료
- [ ] 리스크 관리 계획 완료
- [ ] 품질 보증 계획 완료
### 실현 가능성 검증
- [ ] **기술적 실현 가능성**: 확인 완료
- [ ] **공수·스케줄 타당성**: 확인 완료
- [ ] **리소스 확보 가능성**: 확인 완료
- [ ] **품질 요구 달성 가능성**: 확인 완료
### 이해관계자 합의
- [ ] **개발팀 합의**: 획득
- [ ] **프로젝트 매니저 합의**: 획득
- [ ] **클라이언트 합의**: 획득
### 다음 단계 준비
- [ ] **개발 환경 준비 계획**: 작성 완료
- [ ] **킥오프 준비**: 완료
- [ ] **진척 관리 체계**: 구축 완료
```
## 구현 계획서 템플릿
### 산출물 요약
```markdown
# 프로덕션 개발 구현 계획서
## 프로젝트 개요
- **프로젝트명**: _____
- **구현 기간**: _____ ~ _____
- **총 공수**: ___일
- **팀 구성**: _____
## 구현 전략
- **구현 방침**: _____
- **기술 스택**: _____
- **릴리스 전략**: _____
## 주요 마일스톤
1. **Phase 1**: _____ (_____)
2. **Phase 2**: _____ (_____)
3. **Phase 3**: _____ (_____)
## 리스크 요인·대응
- **주요 리스크**: _____
- **대응**: _____
- **비상 대응**: _____
## 품질 보증
- **테스트 전략**: _____
- **품질 기준**: _____
- **모니터링 체계**: _____
```
---
**이 체크리스트를 활용하면, 프로토타입 분석과 상세 설계의 결과를 구현 계획에 확실히 반영하여 성공 확률이 높은 프로덕션 개발 계획을 수립할 수 있습니다.
각 페이즈의 체크 항목을 순차적으로 완료하여, 누락 없는 포괄적 계획을 마련해 주세요.**
04-implementation-generation.md
경로 : .cursor/commands/5_implementation/04-implementation-generation.md
# 프로토타입 기반 단계적 구현 생성 규칙
## 1. 프로젝트 개요
### 1.1 구현 전략의 기본 방침
본 계획서는 **구현 분석 → 기능별 구현 계획 수립 → 레벨별 구현 생성**의 단계적 접근을 통해, 프론트엔드와 백엔드 모두에서 3단계 구현 전략을 수행하여 풀스택 시스템의 품질을 점진적으로 향상시키는 것을 목표로 합니다.
### 1.2 실행 페이즈 개요
```mermaid
graph TD
A[Phase 0: 시스템 분석] --> B[Phase 1: 구현 계획 수립]
B --> C[Phase 2: 레벨 선택·구현 생성]
C --> D[Phase 3: 구현 실행·품질 확인]
A --> A1[구현 코드 분석]
A --> A2[사양서 분석]
A --> A3[API 사양 분석]
A --> A4[DB 설계 분석]
B --> B1[기능별 구현 대상 정리]
B --> B2[레벨별 구현 계획]
B --> B3[사용자 확인·선택]
C --> C1[지정 레벨 구현 생성]
C --> C2[구현 환경 준비]
D --> D1[구현 실행]
D --> D2[품질 확인·리포트]
```
### 1.3 구현 피라미드 구성(수정판)
```
Level 3 E2E 구현 (10%)
─────────────────────────────────
Frontend E2E | Backend E2E
Level 2 통합 구현 (20%)
───────────────────────────────────
Frontend 통합 | Backend 통합
Level 1 유닛/모크 구현 (70%)
────────────────────────────────────────
Frontend Unit | Backend Unit
```
## 2. 구현 레벨 정의(프론트엔드·백엔드 공통)
### 2.1 Level 1: 유닛/모크 구현
#### 2.1.1 Backend Level 1
- **목적**: 비즈니스 로직 단위 구현
- **신뢰도**: 60-70%
- **실행 빈도**: 매 커밋
- **소요 시간**: 분 단위
- **기술 스택**: FastAPI, Pydantic, unittest.mock
- **대상**:
- 순수 함수, 계산 로직
- API 핸들러(의존성 모킹)
- 서비스 클래스 메서드
- 검증(Validation) 함수
#### 2.1.2 Frontend Level 1
- **목적**: 컴포넌트 단위 구현
- **신뢰도**: 60-70%
- **실행 빈도**: 매 커밋
- **소요 시간**: 분 단위
- **기술 스택**: Next.js, React, TypeScript, Tailwind CSS
- **대상**:
- 개별 컴포넌트 구현
- props 처리 로직
- 이벤트 핸들러
- 커스텀 훅
### 2.2 Level 2: 통합 구현
#### 2.2.1 Backend Level 2
- **목적**: 컴포넌트 간 연계 구현
- **신뢰도**: 75-85%
- **실행 빈도**: 주간
- **소요 시간**: 시간 단위
- **기술 스택**: FastAPI, Supabase, PostgreSQL
- **대상**:
- API + 데이터베이스 연동
- 서비스 간 연계
- 외부 API 통합(개발 환경)
- 트랜잭션 관리
#### 2.2.2 Frontend Level 2
- **목적**: 컴포넌트 간 연계·API 통합 구현
- **신뢰도**: 75-85%
- **실행 빈도**: 주간
- **소요 시간**: 시간 단위
- **기술 스택**: Next.js, Zustand, API통합
- **대상**:
- 다중 컴포넌트 연계
- API 통신 구현
- 상태 관리(Zustand 등)
- 라우팅 기능
### 2.3 Level 3: E2E구현
#### 2.3.1 Backend Level 3
- **목적**: 완전한 워크플로우 구현
- **신뢰도**: 90-95%
- **실행 빈도**: 릴리스 직전
- **소요 시간**: 일 단위
- **기술 스택**: FastAPI, 프로덕션 유사 서비스
- **대상**:
- API 경유 전체 플로우
- 스테이징/프로덕션 유사 환경
- 성능 최적화
- 보안 강화
#### 2.3.2 Frontend Level 3
- **목적**: 사용자 여정(User Journey) 완전 구현
- **신뢰도**: 90-95%
- **실행 빈도**: 릴리스 직전
- **소요 시간**: 일 단위
- **기술 스택**: Next.js, 프로덕션 연동
- **대상**:
- 완전한 사용자 플로우
- 크로스 브라우저 대응
- 실제 브라우저 환경 최적화
- 접근성(Accessibility) 대응
## 3. 구현 환경 구성
### 3.1 Level 1 구현 환경
#### Backend Level 1
```yaml
backend_level1:
name: "Backend Mock Environment"
database: "In-memory SQLite"
external_services: "All Mocked"
storage: "Mock Storage"
setup_time: "< 1분"
cleanup: "자동"
```
#### Frontend Level 1
```yaml
frontend_level1:
name: "Frontend Unit Environment"
browser: "Development Mode"
api_services: "All Mocked"
components: "Isolated Implementation"
setup_time: "< 1분"
cleanup: "자동"
```
### 3.2 Level 2 구현 환경
#### Backend Level 2
```yaml
backend_level2:
name: "Backend Integration Environment"
database: "Development PostgreSQL"
external_services: "Development Services"
storage: "Development Bucket"
setup_time: "10-30분"
cleanup: "자동 + 수동 확인"
```
#### Frontend Level 2
```yaml
frontend_level2:
name: "Frontend Integration Environment"
browser: "Development Mode"
api_services: "Development Backend"
components: "Multi-component Implementation"
state_management: "Real Store"
setup_time: "5-15분"
cleanup: "자동"
```
### 3.3 Level 3 구현 환경
#### Backend Level 3
```yaml
backend_level3:
name: "Backend E2E Environment"
database: "Staging Database"
external_services: "Staging Services"
storage: "Staging Bucket"
setup_time: "1-5시간"
cleanup: "수동 확인 필수"
```
#### Frontend Level 3
```yaml
frontend_level3:
name: "Frontend E2E Environment"
browser: "Production-like Environment"
api_services: "Staging Backend"
environment: "Full Application"
setup_time: "30분-2시간"
cleanup: "자동 + 산출물 보존"
```
## 4. Phase 0: 시스템 분석·구현 계획 수립
### 4.1 구현 분석 페이즈
#### 4.1.1 분석 대상 문서
```yaml
required_documents:
implementation:
- backend_source_code: "API 구현, 서비스, 모델"
- frontend_source_code: "컴포넌트, 페이지, 훅"
- database_schema: "테이블 정의, 관계"
specifications:
- api_specification: "OpenAPI/Swagger 사양"
- database_design: "ERD, 제약 조건 정의"
- system_design: "아키텍처 설계서"
- user_requirements: "요구사항 정의서"
optional_documents:
- deployment_config: "인프라 설정"
- security_requirements: "보안 요구사항"
- performance_requirements: "성능 요구사항"
```
#### 4.1.2 자동 분석 프로세스
```python
class SystemImplementationAnalyzer:
def analyze_system(self, documents):
"""시스템 전반을 분석해 구현 대상을 식별"""
analysis_result = {
"backend_features": self._analyze_backend_implementation(documents),
"frontend_features": self._analyze_frontend_implementation(documents),
"integration_points": self._analyze_integrations(documents),
"critical_paths": self._identify_critical_implementation_paths(documents),
"quality_gaps": self._assess_implementation_gaps(documents)
}
return analysis_result
def _analyze_backend_implementation(self, documents):
"""Backend구현분석"""
return {
"api_endpoints": self._extract_api_implementations(),
"business_logic": self._extract_business_logic_implementations(),
"data_models": self._extract_data_model_implementations(),
"external_dependencies": self._extract_external_implementations(),
"security_features": self._extract_security_implementations()
}
def _analyze_frontend_implementation(self, documents):
"""Frontend구현분석"""
return {
"components": self._extract_component_implementations(),
"pages": self._extract_page_implementations(),
"user_flows": self._extract_user_flow_implementations(),
"state_management": self._extract_state_implementations(),
"api_integrations": self._extract_api_integration_implementations()
}
```
### 4.2 기능별 구현 계획 수립
#### 4.2.1 구현 대상 기능 매핑 예시
```markdown
# 시스템 분석 결과 예시
## Backend기능 목록
### 인증·인가 기능
- **Level 1 대상**: JWT 토큰 생성 구현, 비밀번호 해시 처리 구현
- **Level 2 대상**: 로그인 API + DB 연동, 권한 체크 구현
- **Level 3 대상**: 완전한 인증 플로우, 세션 관리 구현
### 사용자 관리 기능
- **Level 1 대상**: 사용자 생성 검증 로직, 갱신 로직
- **Level 2 대상**: 사용자 CRUD API + DB 구현, 메일 발송 연동
- **Level 3 대상**: 가입~인증 완료 전체 플로우
### 데이터 처리 기능
- **Level 1 대상**: 계산 로직, 데이터 변환 처리
- **Level 2 대상**: 파일 업로드 + 스토리지 연동
- **Level 3 대상**: 배치 처리 파이프라인
## Frontend 기능 목록
### 인증 UI
- **Level 1 대상**: 로그인 폼 컴포넌트, 폼 검증
- **Level 2 대상**: 인증 상태 관리, API 연동
- **Level 3 대상**: 로그인→대시보드 전환 플로우
### 사용자 관리 UI
- **Level 1 대상**: 사용자 목록·상세 컴포넌트
- **Level 2 대상**: CRUD + API 연동, 상태 동기화
- **Level 3 대상**: 사용자 관리 E2E 워크플로우
### 데이터 표시 기능
- **Level 1 대상**: 차트·테이블 컴포넌트
- **Level 2 대상**: 데이터 조회·갱신, 필터링
- **Level 3 대상**: 대시보드 전체 인터랙션
```
#### 4.2.2 레벨별 구현 계획 생성
```python
class ImplementationPlanGenerator:
def generate_level_plans(self, analysis_result):
"""분석 결과로부터 레벨별 구현 계획을 생성"""
plans = {}
for level in [1, 2, 3]:
plans[f"level_{level}"] = {
"backend": self._generate_backend_implementation_plan(analysis_result, level),
"frontend": self._generate_frontend_implementation_plan(analysis_result, level),
"estimated_time": self._estimate_implementation_time(analysis_result, level),
"dependencies": self._identify_implementation_dependencies(analysis_result, level),
"risks": self._assess_implementation_risks(analysis_result, level)
}
return plans
def _generate_backend_implementation_plan(self, analysis, level):
"""Backend용 레벨별 구현 계획"""
if level == 1:
return {
"implementation_targets": analysis["backend_features"]["business_logic"],
"mock_dependencies": analysis["backend_features"]["external_dependencies"],
"implementation_count_estimate": len(analysis["backend_features"]["business_logic"]) * 3
}
elif level == 2:
return {
"implementation_targets": analysis["integration_points"]["api_database"],
"real_dependencies": ["database", "development_services"],
"implementation_count_estimate": len(analysis["integration_points"]["api_database"]) * 2
}
# Level 3의 경우...
```
### 4.3 사용자 확인·선택 페이즈
#### 4.3.1 구현 계획 제시 포맷
```markdown
# 구현 실행 계획(사용자 확인용)
## 시스템 분석 결과 요약
- **Backend 기능 수**: 15개
- **Frontend 기능 수**: 12개
- **중요도 높은 기능**: 8개
- **외부 연동 수**: 5개 서비스
## 레벨별 실행 계획
### Level 1 (Backend + Frontend 유닛 구현)
**추정 소요 시간**: 2–3일
**구현 건수**: Backend 45건, Frontend 36건
**주요 대상 기능**:
- ✅ 인증 로직 (Backend: JWT 토큰 생성, Frontend: 로그인 폼)
- ✅ 사용자 관리 (Backend: 밸리데이션, Frontend: 사용자 리스트)
- ✅ 데이터 처리 (Backend: 계산 로직, Frontend: 차트 표시)
**필요 환경**: 개발 환경만
**리스크**: 낮음
### Level 2 (Backend + Frontend 통합 구현)
**추정 소요 시간**: 3–5일
**구현 건수**: Backend 30건, Frontend 24건
**주요 대상 기능**:
- ✅ API + DB 연동 구현
- ✅ 외부 서비스 통합 구현(개발 환경)
- ✅ 프론트엔드 상태 관리 + API 연동
**필요 환경**: 개발 DB, 개발용 서비스
**리스크**: 중간
### Level 3 (Backend + Frontend E2E 구현)
**추정 소요 시간**: 5–7일
**구현 건수**: Backend 20건, Frontend 15건
**주요 대상 기능**:
- ✅ 완전한 사용자 플로우
- ✅ 성능 최적화
- ✅ 보안 강화
**필요 환경**: 스테이징 환경
**리스크**: 높음
## 권장 실행 순서
1. **Level 1부터 시작** → 기반 품질 확보
2. **Level 2에서 통합 확인** → 서비스 간 연계 검증
3. **Level 3에서 최종 확인** → 프로덕션 릴리스 전
## 사용자 선택 옵션
- `"Level 1만 실행"` → 기본 품질 확보, 개발 단계 적합
- `"Level 1-2 실행"` → 통합 품질 확보, 개발 단계 적합
- `"전 레벨 실행"` → 완전 품질 확보, 프로덕션 릴리스 적합
- `"커스텀 선택"` → 특정 기능·레벨 조합
```
## 5. 구현 실행 플로우
### 5.1 단계적 실행 전략
#### Level 1 실행 플로우
```mermaid
graph TD
A[구현 코드 분석] --> B[Backend Level 1 생성]
A --> C[Frontend Level 1 생성]
B --> D[Backend Unit 구현 실행]
C --> E[Frontend Unit 구현 실행]
D --> F[Level 1 통합 리포트]
E --> F
F --> G[Level 2 실행 판단]
```
#### Level 2 실행 플로우
```mermaid
graph TD
A[Level 1 성공 확인] --> B[Backend Level 2 생성]
A --> C[Frontend Level 2 생성]
B --> D[Backend 통합 구현 실행]
C --> E[Frontend 통합 구현 실행]
D --> F[Level 2 통합 리포트]
E --> F
F --> G[Level 3 실행 판단]
```
#### Level 3 실행 플로우
```mermaid
graph TD
A[Level 2 성공 확인] --> B[Backend Level 3 생성]
A --> C[Frontend Level 3 생성]
B --> D[Backend E2E 구현 실행]
C --> E[Frontend E2E 구현 실행]
D --> F[Level 3 통합 리포트]
E --> F
F --> G[종합 품질 평가]
```
## 6. 구현 케이스 설계 방침
### 6.1 Level 1 구현 케이스 설계
#### Backend Level 1
```python
class BackendLevel1Categories:
BUSINESS_LOGIC = {
"calculation_functions": "계산·변환 처리 구현",
"validation_logic": "밸리데이션 처리 구현",
"data_transformation": "데이터 변환 처리 구현"
}
API_HANDLERS = {
"request_processing": "요청 처리 로직 구현(모크 사용)",
"response_formatting": "응답 포맷팅 구현",
"error_handling": "에러 핸들링 구현"
}
SERVICE_METHODS = {
"service_logic": "서비스 메서드 단위 구현",
"state_transitions": "상태 전이 로직 구현",
"business_rules": "비즈니스 규칙 구현"
}
```
#### Frontend Level 1
```typescript
class FrontendLevel1Categories {
COMPONENT_RENDERING = {
"basic_rendering": "기본 렌더링 구현",
"props_handling": "props 처리 구현",
"conditional_rendering": "조건부 렌더링 구현"
}
EVENT_HANDLING = {
"click_events": "클릭 이벤트 처리 구현",
"form_submission": "폼 전송 처리 구현",
"input_validation": "입력값 검증 구현"
}
CUSTOM_HOOKS = {
"state_management": "상태 관리 훅 구현",
"data_fetching": "데이터 페칭 훅 구현(모크)",
"side_effects": "사이드 이펙트 처리 구현"
}
}
```
### 6.2 Level 2 구현 케이스 설계
#### Backend Level 2
```python
class BackendLevel2Categories:
API_DATABASE = {
"crud_operations": "CRUD 작업의 완전 구현",
"transaction_management": "트랜잭션 처리 구현",
"constraint_validation": "DB 제약 검증 구현"
}
SERVICE_INTEGRATION = {
"service_chaining": "서비스 간 연계 구현",
"async_processing": "비동기 처리 구현",
"event_handling": "이벤트 처리 구현"
}
EXTERNAL_API = {
"third_party_integration": "외부 API 연동 구현(개발 환경)",
"authentication": "인증 플로우 구현",
"rate_limiting": "레이트 리미트 대응 구현"
}
```
#### Frontend Level 2
```typescript
class FrontendLevel2Categories {
COMPONENT_INTEGRATION = {
"parent_child_communication": "부모-자식 컴포넌트 연계 구현",
"sibling_communication": "형제 컴포넌트 연계 구현",
"context_providers": "Context Provider 기능 구현"
}
API_INTEGRATION = {
"data_fetching": "데이터 조회 구현",
"error_handling": "API 에러 핸들링 구현",
"loading_states": "로딩 상태 관리 구현"
}
STATE_MANAGEMENT = {
"zustand_integration": "Zustand 상태 관리 구현",
"local_storage": "로컬 스토리지 연동",
"routing": "라우팅 기능 구현"
}
}
```
### 6.3 Level 3 구현 케이스 설계
#### Backend Level 3
```python
class BackendLevel3Categories:
COMPLETE_WORKFLOWS = {
"user_registration": "사용자 등록 E2E 플로우 구현",
"data_processing": "데이터 처리 파이프라인 구현",
"report_generation": "레포트 생성 처리 구현"
}
PERFORMANCE = {
"optimization": "성능 최적화 구현",
"caching": "캐시 전략 구현",
"scalability": "스케일러빌리티 대응 구현"
}
SECURITY = {
"authentication_flow": "인증·인가 플로우 구현",
"data_protection": "데이터 보호 구현",
"input_sanitization": "입력값 세니타이즈 구현"
}
```
#### Frontend Level 3
```typescript
class FrontendLevel3Categories {
USER_JOURNEYS = {
"registration_flow": "사용자 등록 플로우 구현",
"login_logout": "로그인·로그아웃 구현",
"data_crud_flow": "데이터 CRUD 플로우 구현"
}
CROSS_BROWSER = {
"chrome_optimization": "Chrome 환경 최적화",
"firefox_optimization": "Firefox 환경 최적화",
"safari_optimization": "Safari 환경 최적화"
}
ACCESSIBILITY = {
"aria_implementation": "ARIA 속성 구현",
"keyboard_navigation": "키보드 내비게이션 구현",
"responsive_design": "반응형 디자인 구현"
}
}
```
## 7. 품질 기준(레벨·영역별)
### 7.1 Backend품질 기준
| Level | 구현 완료도 목표 | 품질 기준 | 구현 시간 제한 | 품질 지표 |
|----|---|---|----|----|
| Backend L1 | 90%+ | 동작 확인 95%+ | 각 구현 < 1시간 | 로직 품질 |
| Backend L2 | 80%+ | 동작 확인 90%+ | 각 구현 < 1일 | 연계 품질 |
| Backend L3 | 70%+ | 동작 확인 85%+ | 각 구현 < 1주 | 시스템 품질 |
### 7.2 Frontend품질 기준
| Level | 구현 완료도 목표 | 품질 기준 | 구현 시간 제한 | 품질 지표 |
|----|---|---|----|----|
| Frontend L1 | 85%+ | 동작 확인 95%+ | 각 구현 < 1시간 | UI 품질 |
| Frontend L2 | 75%+ | 동작 확인 90%+ | 각 구현 < 1일 | UX 품질 |
| Frontend L3 | 70%+ | 동작 확인 85%+ | 각 구현 < 1주 | 엔드유저 품질 |
### 7.3 통합 품질 지표
#### 시스템 전체 신뢰도 계산
```python
def calculate_system_implementation_quality():
# Backend 가중치
backend_l1_weight = 0.25 # Backend 기반 품질
backend_l2_weight = 0.20 # Backend 통합 품질
backend_l3_weight = 0.15 # Backend E2E 품질
# Frontend 가중치
frontend_l1_weight = 0.20 # Frontend 기반 품질
frontend_l2_weight = 0.15 # Frontend 통합 품질
frontend_l3_weight = 0.05 # Frontend E2E 품질
total_quality = (
backend_l1_quality * backend_l1_weight +
backend_l2_quality * backend_l2_weight +
backend_l3_quality * backend_l3_weight +
frontend_l1_quality * frontend_l1_weight +
frontend_l2_quality * frontend_l2_weight +
frontend_l3_quality * frontend_l3_weight
)
return total_quality
```
## 8. 실행 스케줄
### 8.1 개발 페이즈 실행 계획
#### Phase 1: Level 1 기반 구축(1–2주차)
```yaml
backend_level1:
- FastAPI 환경 구축
- 모크(mock) 기능 구현
- 유닛 구현 스위트 작성
frontend_level1:
- Next.js + TypeScript 환경 구축
- 컴포넌트 구현 작성
- 커스텀 훅 구현
```
#### Phase 2: Level 2 통합 구축(3–4주차)
```yaml
backend_level2:
- 개발 DB 환경 구축
- 통합 구현 스위트 작성
- 개발 데이터 관리
frontend_level2:
- API 통합 환경 구축
- API 통합 구현 작성
- 상태 관리 구현
```
#### Phase 3: Level 3 E2E 구축(5–6주차)
```yaml
backend_level3:
- 스테이징 환경 구축
- E2E 구현 스위트 작성
- 성능 구현
frontend_level3:
- 프로덕션 유사 환경 구축
- 사용자 저니(User Journey) 구현
- 접근성(Accessibility) 구현
```
### 8.2 지속 실행 스케줄
#### 일일 실행
- Backend Level 1: 전체 유닛 구현
- Frontend Level 1: 전체 컴포넌트 구현
#### 주간 실행
- Backend Level 2: 통합 구현 스위트
- Frontend Level 2: API 통합·상태 관리 구현
#### 릴리스 전 실행
- Backend Level 3: 완전 E2E 구현 스위트
- Frontend Level 3: 완전 사용자 저니 구현
- 전 레벨: 종합 품질 확인
## 9. 실행 지시 형식
### 9.1 레벨·영역별 실행 지시
#### Backend 전용 실행
```
"Backend Level 1로 구현 생성"
"Backend Level 2로 구현 생성"
"Backend Level 3로 구현 생성"
```
#### Frontend 전용 실행
```
"Frontend Level 1로 구현 생성"
"Frontend Level 2로 구현 생성"
"Frontend Level 3로 구현 생성"
```
#### 레벨별 풀스택 실행
```
"Level 1로 완전 구현 생성" // Backend + Frontend Level 1
"Level 2로 완전 구현 생성" // Backend + Frontend Level 2
"Level 3로 완전 구현 생성" // Backend + Frontend Level 3
```
#### 완전 실행
```
"풀스택 구현 생성" // 전 레벨 × 전 영역
"전 레벨로 구현 생성" // 단계적으로 전체 수행
```
### 9.2 커스터마이즈 실행 지시
#### 특정 조합
```
"Backend Level 1-2 + Frontend Level 1로 구현 생성"
"Backend Level 3 + Frontend Level 1-2로 구현 생성"
```
## 10. 리포트 생성 요구사항
### 10.1 레벨·영역별 리포트
#### 개별 리포트
- Backend Level 1 Report
- Frontend Level 1 Report
- Backend Level 2 Report
- Frontend Level 2 Report
- Backend Level 3 Report
- Frontend Level 3 Report
#### 통합 리포트
- Level 1 Complete Report (Backend + Frontend)
- Level 2 Complete Report (Backend + Frontend)
- Level 3 Complete Report (Backend + Frontend)
- Full Stack Summary Report
### 10.2 품질 대시보드
```markdown
# 풀스택 품질 대시보드
## 개요
| 영역 | Level 1 | Level 2 | Level 3 | 종합 |
|---|---|---|---|---|
| Backend | ✅ 95% | ✅ 88% | ⚠️ 82% | 88% |
| Frontend | ✅ 92% | ✅ 85% | ❌ 65% | 81% |
| **시스템 전체** | **93%** | **87%** | **74%** | **85%** |
## 권장 개선 액션
1. Frontend Level 3의 구현 품질 향상
2. Backend Level 3의 구현 시간 단축
3. 통합 구현 케이스 추가
```
## 11. 실제 실행 절차
### 11.1 Phase 0: 시스템 분석 시작
#### Step 1: 문서 제공
아래 문서를 공유해 주세요:
**필수 문서**:
- 구현 코드(Backend/Frontend)
- API 사양서(OpenAPI/Swagger 등)
- 데이터베이스 설계서(ERD, DDL 등)
**권장 문서**:
- 시스템 설계서
- 요구사항 정의서
- 기존 구현(보유 시)
#### Step 2: 자동 분석 실행
```
"시스템 분석을 실행해 주세요"
```
→ 모든 문서를 분석하여 구현 대상 기능을 식별
#### Step 3: 구현 계획 확인
분석 결과를 바탕으로 레벨별 구현 계획 제시
→ 사용자가 실행 레벨을 선택
### 11.2 Phase 1: 구현 생성·실행
#### 사용자 선택 기반 구현 생성
```
"Level 1로 실시"
"Level 1-2로 실시"
"Backend Level 2만 실시"
"인증 기능만 Level 1-3으로 실시"
```
### 11.3 실행 지시 예시
#### 단계적 분석·실행
```bash
# Step 1: 시스템 분석
"시스템 분석을 실행해 주세요"
# Step 2: 분석 결과 확인 후, 레벨 선택
"Level 1로 실시해 주세요"
"Level 2까지 실시해 주세요"
"전 레벨로 실시해 주세요"
# Step 3: 커스텀 선택(필요 시)
"인증 기능과 사용자 관리 기능만 Level 1-2로 실시"
"Backend Level 1-3 + Frontend Level 1-2로 실시"
```
---
**준비가 완료되었습니다. 먼저 시스템 분석부터 시작하겠습니다.
구현 코드, API 명세서, 데이터베이스 설계서 등을 공유해 주시면 시스템 전반을 분석하여 구체적인 구현 계획을 제시하겠습니다.**