🏗️ chore: TaskMaster AI 작업 관리 도구 초기 설정

- TaskMaster 설정 파일 (config.json, state.json) - 작업 문서 및 템플릿 추가 - PRD 문서 디렉토리 구성
2026-03-24 22:26:10 +09:00
parent 1ea395b6bd
commit 5b84d0f30a
6 changed files with 990 additions and 0 deletions
--- a/.taskmaster/config.json
+++ b/.taskmaster/config.json
@@ -0,0 +1,44 @@
+{
+  "models": {
+    "main": {
+      "provider": "anthropic",
+      "modelId": "claude-sonnet-4-20250514",
+      "maxTokens": 64000,
+      "temperature": 0.2
+    },
+    "research": {
+      "provider": "perplexity",
+      "modelId": "sonar",
+      "maxTokens": 8700,
+      "temperature": 0.1
+    },
+    "fallback": {
+      "provider": "anthropic",
+      "modelId": "claude-3-7-sonnet-20250219",
+      "maxTokens": 120000,
+      "temperature": 0.2
+    }
+  },
+  "global": {
+    "logLevel": "info",
+    "debug": false,
+    "defaultNumTasks": 10,
+    "defaultSubtasks": 5,
+    "defaultPriority": "medium",
+    "projectName": "Task Master",
+    "ollamaBaseURL": "http://localhost:11434/api",
+    "bedrockBaseURL": "https://bedrock.us-east-1.amazonaws.com",
+    "responseLanguage": "English",
+    "enableCodebaseAnalysis": true,
+    "enableProxy": false,
+    "anonymousTelemetry": true,
+    "userId": "1234567890"
+  },
+  "claudeCode": {},
+  "codexCli": {},
+  "grokCli": {
+    "timeout": 120000,
+    "workingDirectory": null,
+    "defaultModel": "grok-4-latest"
+  }
+}
--- a/.taskmaster/docs/prd.txt
+++ b/.taskmaster/docs/prd.txt
@@ -0,0 +1,124 @@
+# FE AI 표준화 방안 PRD
+
+## 프로젝트 개요
+프론트엔드(FE) 개발 전 주기에 AI를 활용한 표준화 방안을 수립하고 각 단계별 가이드라인과 실행 방안을 문서화한다.
+대상 스택: Nuxt 4, TypeScript (strict), Tailwind CSS v4, shadcn-vue, Pinia
+
+---
+
+## STEP 01 · 기획 (Planning)
+
+### 1-1. 스펙 검토 표준화
+- 플로우차트 기준으로 스펙 문서를 AI가 검토하는 프로세스 정의
+- 기능 요건 정의 템플릿 작성
+- AI 프롬프트 템플릿: 스펙 → 플로우차트 자동 생성
+
+### 1-2. SEO 정보 표준화 및 검증
+- Nuxt 4 useSeoMeta / useHead 기반 SEO 메타 표준 정의
+- AI 기반 SEO 검증 도구 선정 (Lighthouse, 커스텀 스크립트 등)
+- SEO 검증 프로세스 표준화 문서 작성
+
+### 1-3. 번역코드 생성 표준화 (i18n)
+- i18n 키 네이밍 컨벤션 정의 (예: `page.section.element`)
+- AI를 활용한 i18n 키 자동 생성 프롬프트/스크립트 작성
+- 번역 파일 구조 표준화 (locale JSON 구조)
+
+---
+
+## STEP 02 · 디자인 (Design)
+
+### 2-1. Figma 네이밍 규칙
+- Figma 컴포넌트 명명 규칙 가이드 작성 (PascalCase, BEM 등)
+- AI 기반 Figma 네이밍 검수 프로세스 정의
+- Vue 컴포넌트명과 Figma 컴포넌트명 매핑 규칙 수립
+
+### 2-2. EDM 마크업 표준화
+- 이메일 템플릿 규격 정의 (width, font, 지원 클라이언트 목록)
+- 이메일 HTML 마크업 표준화 가이드 작성 (table 레이아웃, inline style)
+- 이메일 검증 도구 선정 (Litmus, Email on Acid 등)
+- AI 기반 이메일 검증 프로세스 표준화
+
+### 2-3. 프로모션 마크업 표준화
+- 프로모션 페이지 필요 정보 입력 방식 정의
+  - 이미지 URL, 프로모션 기간, 유의사항, 아이템 코드
+- AI 기반 프로모션 마크업 자동 생성 프롬프트 작성
+- 프로모션 컴포넌트 템플릿 표준화
+
+---
+
+## STEP 03 · 구현 (Implementation)
+
+### 3-1. AI 코딩 도구 표준화
+- Claude / Cursor 사용 가이드 작성
+- 팀 내 AI 코딩 도구 선정 및 라이선스 정책 수립 (Claude, Cursor 기준)
+- 코드 자동 완성 활용 패턴 및 주의사항 문서화
+
+### 3-2. 개발 컨벤션 표준화
+- i18n 사용 컨벤션 (useI18n, $t 사용 기준)
+- 미들웨어 작성 컨벤션 (인증, 권한, 리다이렉트)
+- 언어 정책 컨벤션 (다국어 라우팅, locale 전환)
+- 점검 페이지 컨벤션
+- 인트로/스플래시 페이지 컨벤션
+- 에러 페이지 컨벤션 (404, 500, error.vue)
+
+### 3-3. 코드 리팩토링 표준화
+- AI 기반 리팩토링 제안 프로세스 정의
+- 리팩토링 체크리스트 작성 (컴포넌트 분리, 재사용성, 타입 안전성)
+- 코드 품질 지표 정의 및 AI 분석 방법
+
+### 3-4. 코드 리뷰 자동화
+- AI 코드 리뷰 도구 선정 및 설정 (GitHub Copilot PR Review 등)
+- MR/PR 자동 요약 프롬프트/봇 설정
+- Git Conflict 처리 AI 보조 프로세스 정의
+
+### 3-5. 파일 수정 표준화 (커밋 · 테스트)
+- 커밋 메시지 표준 정의 (feat/fix/refactor/style/docs/test/chore)
+- 단위 테스트 작성 표준 (Vitest + @nuxt/test-utils)
+- AI 기반 테스트 코드 자동 생성 프롬프트/스크립트
+
+### 3-6. CI 파이프라인 표준화
+- CI 파이프라인 스크립트 생성 가이드 (GitLab CI 기준)
+- AI 기반 빌드 오류 분석 프로세스
+- CI 최적화 제안 체크리스트
+
+### 3-7. 기술 문서 자동화
+- 기능별 플로우 다이어그램/ERD AI 작성 가이드
+- README 자동 생성 프롬프트 템플릿
+- 코드 주석 자동 생성 표준 (JSDoc / TSDoc)
+
+### 3-8. 보안 검수 표준화
+- AI 기반 취약점 자동 탐지 도구 선정 (Snyk, ESLint security plugin 등)
+- 보안 패턴 검사 체크리스트 작성
+- 보안 검수 CI 단계 통합 방안
+
+---
+
+## STEP 04 · 검증 (Verification)
+
+### 4-1. 테스트 케이스 설계
+- AI 기반 테스트 케이스 자동 생성 프로세스 정의
+- 엣지 케이스 도출 방법론 및 프롬프트 작성
+- 테스트 케이스 템플릿 표준화
+
+### 4-2. 기능·통합 테스트 자동화
+- E2E 테스트 자동화 스크립트 작성 (Playwright 등)
+- AI 기반 이슈 자동 탐지 프로세스
+- 테스트 결과 리포트 표준화
+
+### 4-3. 성능·보안 검토
+- 성능 취약점 자동 탐지 (Lighthouse CI, Web Vitals 기준)
+- 병목 지점 AI 분석 방법론
+- 성능·보안 검토 체크리스트 작성
+
+### 4-4. 버그 리포트·수정 자동화
+- AI 기반 버그 원인 분석 프로세스
+- 버그 수정 제안 프롬프트 템플릿
+- 자동 버그 리포팅 시스템 설계
+
+---
+
+## 공통 산출물
+- 각 단계별 AI 프롬프트 템플릿 모음
+- 표준화 가이드 문서 (Markdown)
+- CI/CD 통합 스크립트
+- 팀 온보딩 자료
--- a/.taskmaster/state.json
+++ b/.taskmaster/state.json
@@ -0,0 +1,6 @@
+{
+  "currentTag": "master",
+  "lastSwitched": "2026-03-24T12:55:59.367Z",
+  "branchTagMapping": {},
+  "migrationNoticeShown": false
+}
--- a/.taskmaster/tasks/tasks.json
+++ b/.taskmaster/tasks/tasks.json
@@ -0,0 +1,258 @@
+{
+  "master": {
+    "tasks": [
+      {
+        "id": "1",
+        "title": "프로젝트 기본 구조 및 환경 설정",
+        "description": "Nuxt 4, TypeScript (strict), Tailwind CSS v4, shadcn-vue, Pinia 기반 프로젝트 초기 설정 및 기본 구조 구축",
+        "details": "1. Nuxt 4 프로젝트 초기화: `npx nuxi@latest init project-name`\n2. TypeScript strict 모드 설정: nuxt.config.ts에서 typescript: { strict: true }\n3. Tailwind CSS v4 설치 및 설정: npm install tailwindcss@next @tailwindcss/postcss@next\n4. shadcn-vue 설치: npx shadcn-vue@latest init\n5. Pinia 설치 및 설정: npm install pinia @pinia/nuxt\n6. 기본 폴더 구조 생성: components/, composables/, stores/, middleware/, plugins/, utils/\n7. 환경변수 파일 설정: .env.example, .env.local",
+        "testStrategy": "프로젝트 빌드 성공 확인, TypeScript 컴파일 오류 없음, 각 라이브러리 정상 동작 확인, 개발 서버 실행 테스트",
+        "priority": "high",
+        "dependencies": [],
+        "status": "cancelled",
+        "subtasks": [],
+        "updatedAt": "2026-03-24T13:16:43.852Z"
+      },
+      {
+        "id": "2",
+        "title": "스펙 검토 표준화 프로세스 구축",
+        "description": "AI를 활용한 스펙 문서 검토 및 플로우차트 자동 생성 프로세스 정의",
+        "details": "1. 기능 요건 정의 템플릿 작성 (Markdown 형식)\n2. AI 프롬프트 템플릿 작성:\n   - 스펙 문서 → 플로우차트 변환 프롬프트\n   - Mermaid 다이어그램 생성 프롬프트\n3. 스펙 검토 체크리스트 작성\n4. 플로우차트 검증 기준 정의\n5. 문서화 도구 선정 (VitePress 또는 Nuxt Content)\n6. 스펙 검토 워크플로우 문서 작성",
+        "testStrategy": "샘플 스펙 문서로 플로우차트 생성 테스트, AI 프롬프트 정확도 검증, 생성된 플로우차트 품질 평가",
+        "priority": "high",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "3",
+        "title": "SEO 메타데이터 표준화 및 검증 시스템",
+        "description": "Nuxt 4 useSeoMeta/useHead 기반 SEO 표준 정의 및 AI 검증 도구 구축",
+        "details": "1. SEO 메타데이터 표준 스키마 정의:\n   - useSeoMeta() 표준 템플릿\n   - useHead() 사용 가이드라인\n2. SEO 검증 컴포저블 작성: composables/useSeoValidation.ts\n3. Lighthouse CI 설정 및 통합\n4. AI 기반 SEO 점수 분석 프롬프트 작성\n5. SEO 체크리스트 자동화 스크립트\n6. 메타데이터 자동 생성 유틸리티 함수\n7. Open Graph, Twitter Card 표준 템플릿",
+        "testStrategy": "Lighthouse 점수 90+ 달성 확인, 메타데이터 누락 검증, 소셜 미디어 미리보기 테스트, SEO 검증 자동화 테스트",
+        "priority": "high",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "4",
+        "title": "i18n 다국어 표준화 시스템",
+        "description": "i18n 키 네이밍 컨벤션 및 AI 기반 번역 키 자동 생성 시스템 구축",
+        "details": "1. @nuxtjs/i18n 모듈 설치 및 설정\n2. i18n 키 네이밍 컨벤션 정의: page.section.element 형식\n3. 번역 파일 구조 표준화:\n   - locales/ko.json, locales/en.json\n   - 중첩 객체 구조 정의\n4. AI 번역 키 자동 생성 스크립트:\n   - 컴포넌트 스캔하여 번역 키 추출\n   - 누락된 번역 키 자동 감지\n5. 번역 검증 유틸리티 작성\n6. 다국어 라우팅 설정 및 locale 전환 컴포넌트",
+        "testStrategy": "번역 키 중복 검사, 누락된 번역 키 감지 테스트, 언어 전환 기능 테스트, 번역 파일 구조 검증",
+        "priority": "medium",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "5",
+        "title": "Figma 네이밍 규칙 및 컴포넌트 매핑 시스템",
+        "description": "Figma 컴포넌트와 Vue 컴포넌트 간 네이밍 규칙 표준화 및 AI 검수 프로세스",
+        "details": "1. Figma 컴포넌트 네이밍 컨벤션 가이드 작성:\n   - PascalCase 기본 원칙\n   - BEM 방법론 적용 가이드\n2. Vue 컴포넌트명 매핑 규칙 정의\n3. Figma API 연동 스크립트 작성\n4. AI 기반 네이밍 검수 프롬프트:\n   - 일관성 검사\n   - 네이밍 개선 제안\n5. 컴포넌트 매핑 테이블 자동 생성\n6. Figma 토큰 추출 및 Tailwind 변수 매핑",
+        "testStrategy": "Figma API 연동 테스트, 네이밍 규칙 준수 검증, 컴포넌트 매핑 정확도 확인, AI 검수 결과 품질 평가",
+        "priority": "medium",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "6",
+        "title": "EDM 이메일 템플릿 표준화 시스템",
+        "description": "이메일 마크업 표준 정의 및 AI 기반 검증 프로세스 구축",
+        "details": "1. 이메일 템플릿 규격 정의:\n   - 최대 width: 600px\n   - 지원 클라이언트 목록 (Outlook, Gmail, Apple Mail)\n   - 폰트 스택 표준화\n2. HTML 마크업 표준 가이드:\n   - Table 기반 레이아웃\n   - Inline CSS 스타일링\n   - 이미지 최적화 가이드\n3. 이메일 템플릿 컴포넌트 작성\n4. AI 기반 이메일 검증 프롬프트\n5. 이메일 테스트 도구 통합 (Litmus API)\n6. 반응형 이메일 가이드라인",
+        "testStrategy": "주요 이메일 클라이언트 렌더링 테스트, HTML 유효성 검사, 이미지 로딩 테스트, 스팸 필터 통과 테스트",
+        "priority": "medium",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "7",
+        "title": "프로모션 페이지 자동 생성 시스템",
+        "description": "프로모션 마크업 표준화 및 AI 기반 자동 생성 프로세스",
+        "details": "1. 프로모션 데이터 스키마 정의:\n   - 이미지 URL, 프로모션 기간, 유의사항, 아이템 코드\n2. 프로모션 컴포넌트 템플릿 작성:\n   - BasePromotion.vue\n   - PromotionBanner.vue\n   - PromotionModal.vue\n3. AI 마크업 자동 생성 프롬프트\n4. 프로모션 관리 인터페이스 (CMS 형태)\n5. 프로모션 유효성 검증 로직\n6. A/B 테스트 지원 구조",
+        "testStrategy": "프로모션 데이터 유효성 검사, 자동 생성된 마크업 품질 확인, 반응형 레이아웃 테스트, 성능 최적화 검증",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "4"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "8",
+        "title": "AI 코딩 도구 표준화 가이드",
+        "description": "Claude/Cursor 사용 가이드 및 팀 내 AI 도구 정책 수립",
+        "details": "1. AI 코딩 도구 비교 분석 문서 작성\n2. Claude 사용 가이드:\n   - 효과적인 프롬프트 작성법\n   - 코드 리뷰 활용 방법\n3. Cursor 설정 및 사용 가이드:\n   - IDE 통합 설정\n   - 코드 자동완성 최적화\n4. 라이선스 정책 및 비용 관리\n5. AI 도구 사용 시 주의사항 및 보안 가이드\n6. 팀 내 AI 도구 사용 모범 사례 수집",
+        "testStrategy": "AI 도구 설정 검증, 프롬프트 효과성 측정, 코드 품질 개선 정도 평가, 보안 정책 준수 확인",
+        "priority": "medium",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "9",
+        "title": "개발 컨벤션 표준화 문서",
+        "description": "i18n, 미들웨어, 에러 페이지 등 개발 컨벤션 표준 정의",
+        "details": "1. i18n 사용 컨벤션:\n   - useI18n() vs $t() 사용 기준\n   - 번역 키 사용 패턴\n2. 미들웨어 작성 컨벤션:\n   - 인증 미들웨어: middleware/auth.ts\n   - 권한 체크: middleware/role.ts\n   - 리다이렉트 로직 표준화\n3. 페이지 컨벤션:\n   - 에러 페이지: error.vue, 404.vue\n   - 점검 페이지: maintenance.vue\n   - 스플래시 페이지: splash.vue\n4. 라우팅 컨벤션 및 다국어 라우팅\n5. 컴포넌트 구조 및 네이밍 가이드",
+        "testStrategy": "컨벤션 준수 검사 스크립트, 미들웨어 동작 테스트, 에러 페이지 렌더링 확인, 라우팅 테스트",
+        "priority": "high",
+        "dependencies": [
+          "1",
+          "4"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "10",
+        "title": "AI 기반 코드 리팩토링 시스템",
+        "description": "코드 품질 분석 및 AI 리팩토링 제안 프로세스 구축",
+        "details": "1. 코드 품질 지표 정의:\n   - 복잡도, 중복도, 타입 안전성\n   - 컴포넌트 재사용성 점수\n2. AI 리팩토링 분석 프롬프트:\n   - 코드 스멜 탐지\n   - 성능 개선 제안\n   - 타입 안전성 강화\n3. 리팩토링 체크리스트 자동화\n4. ESLint/Prettier 규칙 커스터마이징\n5. 코드 메트릭 수집 및 시각화\n6. 리팩토링 전후 성능 비교 도구",
+        "testStrategy": "리팩토링 제안 정확도 평가, 코드 품질 개선 정도 측정, 성능 벤치마크 비교, 타입 안전성 검증",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "9"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "11",
+        "title": "자동화된 코드 리뷰 시스템",
+        "description": "AI 기반 코드 리뷰 및 PR/MR 자동 요약 시스템 구축",
+        "details": "1. GitHub Actions 또는 GitLab CI 코드 리뷰 봇 설정\n2. AI 코드 리뷰 프롬프트:\n   - 코드 품질 검사\n   - 보안 취약점 탐지\n   - 성능 이슈 식별\n3. PR/MR 자동 요약 기능:\n   - 변경사항 요약\n   - 영향도 분석\n4. Git Conflict 해결 AI 보조 도구\n5. 코드 리뷰 체크리스트 자동화\n6. 리뷰 결과 알림 시스템",
+        "testStrategy": "코드 리뷰 봇 동작 확인, AI 분석 정확도 검증, PR 요약 품질 평가, Conflict 해결 도구 테스트",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "10"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "12",
+        "title": "커밋 및 테스트 표준화 시스템",
+        "description": "커밋 메시지 표준 및 AI 기반 테스트 코드 자동 생성",
+        "details": "1. 커밋 메시지 컨벤션 정의:\n   - feat/fix/refactor/style/docs/test/chore\n   - Conventional Commits 표준 적용\n2. Commitizen 설정 및 커밋 템플릿\n3. Vitest + @nuxt/test-utils 테스트 환경 구축\n4. AI 테스트 코드 생성 프롬프트:\n   - 단위 테스트 자동 생성\n   - 컴포넌트 테스트 템플릿\n5. 테스트 커버리지 목표 설정 (80% 이상)\n6. 테스트 실행 자동화 스크립트",
+        "testStrategy": "커밋 메시지 형식 검증, 테스트 코드 품질 확인, 커버리지 목표 달성 검사, 테스트 실행 성공률 모니터링",
+        "priority": "high",
+        "dependencies": [
+          "1"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "13",
+        "title": "CI/CD 파이프라인 표준화",
+        "description": "GitLab CI 기반 빌드 파이프라인 및 AI 오류 분석 시스템",
+        "details": "1. GitLab CI/CD 파이프라인 템플릿 작성:\n   - .gitlab-ci.yml 표준 구조\n   - 스테이지별 작업 정의 (build, test, deploy)\n2. Docker 컨테이너 기반 빌드 환경\n3. AI 기반 빌드 오류 분석:\n   - 오류 로그 분석 프롬프트\n   - 해결 방안 제안 시스템\n4. 성능 최적화 체크리스트:\n   - 번들 크기 분석\n   - 빌드 시간 최적화\n5. 배포 자동화 스크립트\n6. 롤백 전략 및 Blue-Green 배포",
+        "testStrategy": "파이프라인 실행 성공률 확인, 빌드 시간 측정, 오류 분석 정확도 검증, 배포 안정성 테스트",
+        "priority": "high",
+        "dependencies": [
+          "1",
+          "12"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "14",
+        "title": "기술 문서 자동화 시스템",
+        "description": "플로우 다이어그램, README, 코드 주석 자동 생성 시스템",
+        "details": "1. 플로우 다이어그램 자동 생성:\n   - Mermaid 다이어그램 생성 프롬프트\n   - ERD 자동 생성 스크립트\n2. README 자동 생성 템플릿:\n   - 프로젝트 구조 분석\n   - API 문서 자동 추출\n3. JSDoc/TSDoc 표준 정의:\n   - 함수/컴포넌트 주석 템플릿\n   - AI 기반 주석 자동 생성\n4. API 문서 자동화 (OpenAPI/Swagger)\n5. 컴포넌트 스토리북 자동 생성\n6. 문서 버전 관리 및 배포 자동화",
+        "testStrategy": "생성된 문서 품질 검증, 다이어그램 정확도 확인, API 문서 동기화 테스트, 주석 완성도 평가",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "2"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "15",
+        "title": "보안 검수 자동화 시스템",
+        "description": "AI 기반 취약점 탐지 및 보안 패턴 검사 시스템",
+        "details": "1. 보안 도구 통합:\n   - Snyk 취약점 스캔\n   - ESLint security plugin 설정\n   - OWASP ZAP 자동화\n2. AI 기반 보안 분석 프롬프트:\n   - XSS, CSRF 취약점 탐지\n   - 민감 정보 노출 검사\n3. 보안 체크리스트 자동화:\n   - 의존성 취약점 검사\n   - 환경변수 보안 검증\n4. CI 파이프라인 보안 단계 통합\n5. 보안 정책 문서 작성\n6. 보안 이슈 자동 리포팅",
+        "testStrategy": "취약점 탐지 정확도 검증, 보안 스캔 성능 테스트, False Positive 비율 확인, 보안 정책 준수 검사",
+        "priority": "high",
+        "dependencies": [
+          "1",
+          "13"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "16",
+        "title": "AI 기반 테스트 케이스 자동 생성",
+        "description": "테스트 케이스 설계 및 엣지 케이스 도출 자동화 시스템",
+        "details": "1. 테스트 케이스 자동 생성 프롬프트:\n   - 컴포넌트 분석 기반 테스트 시나리오\n   - 사용자 스토리 기반 테스트 케이스\n2. 엣지 케이스 도출 방법론:\n   - 경계값 분석\n   - 예외 상황 시나리오\n3. 테스트 케이스 템플릿 표준화:\n   - Given-When-Then 패턴\n   - 테스트 데이터 관리\n4. E2E 테스트 자동화 (Playwright)\n5. 시각적 회귀 테스트 도구 통합\n6. 테스트 결과 분석 및 리포팅",
+        "testStrategy": "생성된 테스트 케이스 품질 평가, 엣지 케이스 커버리지 확인, E2E 테스트 안정성 검증, 테스트 실행 시간 최적화",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "12"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "17",
+        "title": "성능 및 통합 테스트 자동화",
+        "description": "성능 모니터링, 병목 분석 및 통합 테스트 자동화 시스템",
+        "details": "1. 성능 모니터링 도구 통합:\n   - Lighthouse CI 설정\n   - Web Vitals 측정 자동화\n   - Bundle Analyzer 통합\n2. AI 기반 병목 분석:\n   - 성능 이슈 자동 탐지\n   - 최적화 제안 생성\n3. 통합 테스트 자동화:\n   - API 통합 테스트\n   - 데이터베이스 연동 테스트\n4. 성능 벤치마크 설정:\n   - Core Web Vitals 목표 설정\n   - 성능 회귀 탐지\n5. 모니터링 대시보드 구축\n6. 성능 알림 시스템",
+        "testStrategy": "성능 지표 목표 달성 확인, 병목 분석 정확도 검증, 통합 테스트 안정성 확인, 모니터링 시스템 동작 테스트",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "16"
+        ],
+        "status": "pending",
+        "subtasks": []
+      },
+      {
+        "id": "18",
+        "title": "버그 리포트 및 수정 자동화 시스템",
+        "description": "AI 기반 버그 분석, 자동 리포팅 및 수정 제안 시스템",
+        "details": "1. 버그 자동 탐지 시스템:\n   - 에러 로그 분석\n   - 사용자 행동 패턴 분석\n2. AI 기반 버그 원인 분석:\n   - 스택 트레이스 분석 프롬프트\n   - 코드 변경 이력 연관성 분석\n3. 자동 버그 리포팅:\n   - 이슈 트래커 연동 (GitLab Issues)\n   - 버그 재현 단계 자동 생성\n4. 버그 수정 제안 시스템:\n   - 유사 버그 해결 사례 검색\n   - 수정 코드 제안 프롬프트\n5. 버그 우선순위 자동 분류\n6. 수정 검증 자동화 테스트",
+        "testStrategy": "버그 탐지 정확도 검증, 원인 분석 품질 평가, 자동 리포팅 완성도 확인, 수정 제안 유효성 테스트",
+        "priority": "medium",
+        "dependencies": [
+          "1",
+          "17"
+        ],
+        "status": "pending",
+        "subtasks": []
+      }
+    ],
+    "metadata": {
+      "version": "1.0.0",
+      "lastModified": "2026-03-24T13:16:43.852Z",
+      "taskCount": 18,
+      "completedCount": 0,
+      "tags": [
+        "master"
+      ]
+    }
+  }
+}
--- a/.taskmaster/templates/example_prd.txt
+++ b/.taskmaster/templates/example_prd.txt
@@ -0,0 +1,47 @@
+<context>
+# Overview  
+[Provide a high-level overview of your product here. Explain what problem it solves, who it's for, and why it's valuable.]
+
+# Core Features  
+[List and describe the main features of your product. For each feature, include:
+- What it does
+- Why it's important
+- How it works at a high level]
+
+# User Experience  
+[Describe the user journey and experience. Include:
+- User personas
+- Key user flows
+- UI/UX considerations]
+</context>
+<PRD>
+# Technical Architecture  
+[Outline the technical implementation details:
+- System components
+- Data models
+- APIs and integrations
+- Infrastructure requirements]
+
+# Development Roadmap  
+[Break down the development process into phases:
+- MVP requirements
+- Future enhancements
+- Do not think about timelines whatsoever -- all that matters is scope and detailing exactly what needs to be build in each phase so it can later be cut up into tasks]
+
+# Logical Dependency Chain
+[Define the logical order of development:
+- Which features need to be built first (foundation)
+- Getting as quickly as possible to something usable/visible front end that works
+- Properly pacing and scoping each feature so it is atomic but can also be built upon and improved as development approaches]
+
+# Risks and Mitigations  
+[Identify potential risks and how they'll be addressed:
+- Technical challenges
+- Figuring out the MVP that we can build upon
+- Resource constraints]
+
+# Appendix  
+[Include any additional information:
+- Research findings
+- Technical specifications]
+</PRD>
--- a/.taskmaster/templates/example_prd_rpg.txt
+++ b/.taskmaster/templates/example_prd_rpg.txt
@@ -0,0 +1,511 @@
+<rpg-method>
+# Repository Planning Graph (RPG) Method - PRD Template
+
+This template teaches you (AI or human) how to create structured, dependency-aware PRDs using the RPG methodology from Microsoft Research. The key insight: separate WHAT (functional) from HOW (structural), then connect them with explicit dependencies.
+
+## Core Principles
+
+1. **Dual-Semantics**: Think functional (capabilities) AND structural (code organization) separately, then map them
+2. **Explicit Dependencies**: Never assume - always state what depends on what
+3. **Topological Order**: Build foundation first, then layers on top
+4. **Progressive Refinement**: Start broad, refine iteratively
+
+## How to Use This Template
+
+- Follow the instructions in each `<instruction>` block
+- Look at `<example>` blocks to see good vs bad patterns
+- Fill in the content sections with your project details
+- The AI reading this will learn the RPG method by following along
+- Task Master will parse the resulting PRD into dependency-aware tasks
+
+## Recommended Tools for Creating PRDs
+
+When using this template to **create** a PRD (not parse it), use **code-context-aware AI assistants** for best results:
+
+**Why?** The AI needs to understand your existing codebase to make good architectural decisions about modules, dependencies, and integration points.
+
+**Recommended tools:**
+- **Claude Code** (claude-code CLI) - Best for structured reasoning and large contexts
+- **Cursor/Windsurf** - IDE integration with full codebase context
+- **Gemini CLI** (gemini-cli) - Massive context window for large codebases
+- **Codex/Grok CLI** - Strong code generation with context awareness
+
+**Note:** Once your PRD is created, `task-master parse-prd` works with any configured AI model - it just needs to read the PRD text itself, not your codebase.
+</rpg-method>
+
+---
+
+<overview>
+<instruction>
+Start with the problem, not the solution. Be specific about:
+- What pain point exists?
+- Who experiences it?
+- Why existing solutions don't work?
+- What success looks like (measurable outcomes)?
+
+Keep this section focused - don't jump into implementation details yet.
+</instruction>
+
+## Problem Statement
+[Describe the core problem. Be concrete about user pain points.]
+
+## Target Users
+[Define personas, their workflows, and what they're trying to achieve.]
+
+## Success Metrics
+[Quantifiable outcomes. Examples: "80% task completion via autopilot", "< 5% manual intervention rate"]
+
+</overview>
+
+---
+
+<functional-decomposition>
+<instruction>
+Now think about CAPABILITIES (what the system DOES), not code structure yet.
+
+Step 1: Identify high-level capability domains
+- Think: "What major things does this system do?"
+- Examples: Data Management, Core Processing, Presentation Layer
+
+Step 2: For each capability, enumerate specific features
+- Use explore-exploit strategy:
+  * Exploit: What features are REQUIRED for core value?
+  * Explore: What features make this domain COMPLETE?
+
+Step 3: For each feature, define:
+- Description: What it does in one sentence
+- Inputs: What data/context it needs
+- Outputs: What it produces/returns
+- Behavior: Key logic or transformations
+
+<example type="good">
+Capability: Data Validation
+  Feature: Schema validation
+    - Description: Validate JSON payloads against defined schemas
+    - Inputs: JSON object, schema definition
+    - Outputs: Validation result (pass/fail) + error details
+    - Behavior: Iterate fields, check types, enforce constraints
+
+  Feature: Business rule validation
+    - Description: Apply domain-specific validation rules
+    - Inputs: Validated data object, rule set
+    - Outputs: Boolean + list of violated rules
+    - Behavior: Execute rules sequentially, short-circuit on failure
+</example>
+
+<example type="bad">
+Capability: validation.js
+  (Problem: This is a FILE, not a CAPABILITY. Mixing structure into functional thinking.)
+
+Capability: Validation
+  Feature: Make sure data is good
+  (Problem: Too vague. No inputs/outputs. Not actionable.)
+</example>
+</instruction>
+
+## Capability Tree
+
+### Capability: [Name]
+[Brief description of what this capability domain covers]
+
+#### Feature: [Name]
+- **Description**: [One sentence]
+- **Inputs**: [What it needs]
+- **Outputs**: [What it produces]
+- **Behavior**: [Key logic]
+
+#### Feature: [Name]
+- **Description**:
+- **Inputs**:
+- **Outputs**:
+- **Behavior**:
+
+### Capability: [Name]
+...
+
+</functional-decomposition>
+
+---
+
+<structural-decomposition>
+<instruction>
+NOW think about code organization. Map capabilities to actual file/folder structure.
+
+Rules:
+1. Each capability maps to a module (folder or file)
+2. Features within a capability map to functions/classes
+3. Use clear module boundaries - each module has ONE responsibility
+4. Define what each module exports (public interface)
+
+The goal: Create a clear mapping between "what it does" (functional) and "where it lives" (structural).
+
+<example type="good">
+Capability: Data Validation
+  → Maps to: src/validation/
+    ├── schema-validator.js      (Schema validation feature)
+    ├── rule-validator.js         (Business rule validation feature)
+    └── index.js                  (Public exports)
+
+Exports:
+  - validateSchema(data, schema)
+  - validateRules(data, rules)
+</example>
+
+<example type="bad">
+Capability: Data Validation
+  → Maps to: src/utils.js
+  (Problem: "utils" is not a clear module boundary. Where do I find validation logic?)
+
+Capability: Data Validation
+  → Maps to: src/validation/everything.js
+  (Problem: One giant file. Features should map to separate files for maintainability.)
+</example>
+</instruction>
+
+## Repository Structure
+
+```
+project-root/
+├── src/
+│   ├── [module-name]/       # Maps to: [Capability Name]
+│   │   ├── [file].js        # Maps to: [Feature Name]
+│   │   └── index.js         # Public exports
+│   └── [module-name]/
+├── tests/
+└── docs/
+```
+
+## Module Definitions
+
+### Module: [Name]
+- **Maps to capability**: [Capability from functional decomposition]
+- **Responsibility**: [Single clear purpose]
+- **File structure**:
+  ```
+  module-name/
+  ├── feature1.js
+  ├── feature2.js
+  └── index.js
+  ```
+- **Exports**:
+  - `functionName()` - [what it does]
+  - `ClassName` - [what it does]
+
+</structural-decomposition>
+
+---
+
+<dependency-graph>
+<instruction>
+This is THE CRITICAL SECTION for Task Master parsing.
+
+Define explicit dependencies between modules. This creates the topological order for task execution.
+
+Rules:
+1. List modules in dependency order (foundation first)
+2. For each module, state what it depends on
+3. Foundation modules should have NO dependencies
+4. Every non-foundation module should depend on at least one other module
+5. Think: "What must EXIST before I can build this module?"
+
+<example type="good">
+Foundation Layer (no dependencies):
+  - error-handling: No dependencies
+  - config-manager: No dependencies
+  - base-types: No dependencies
+
+Data Layer:
+  - schema-validator: Depends on [base-types, error-handling]
+  - data-ingestion: Depends on [schema-validator, config-manager]
+
+Core Layer:
+  - algorithm-engine: Depends on [base-types, error-handling]
+  - pipeline-orchestrator: Depends on [algorithm-engine, data-ingestion]
+</example>
+
+<example type="bad">
+- validation: Depends on API
+- API: Depends on validation
+(Problem: Circular dependency. This will cause build/runtime issues.)
+
+- user-auth: Depends on everything
+(Problem: Too many dependencies. Should be more focused.)
+</example>
+</instruction>
+
+## Dependency Chain
+
+### Foundation Layer (Phase 0)
+No dependencies - these are built first.
+
+- **[Module Name]**: [What it provides]
+- **[Module Name]**: [What it provides]
+
+### [Layer Name] (Phase 1)
+- **[Module Name]**: Depends on [[module-from-phase-0], [module-from-phase-0]]
+- **[Module Name]**: Depends on [[module-from-phase-0]]
+
+### [Layer Name] (Phase 2)
+- **[Module Name]**: Depends on [[module-from-phase-1], [module-from-foundation]]
+
+[Continue building up layers...]
+
+</dependency-graph>
+
+---
+
+<implementation-roadmap>
+<instruction>
+Turn the dependency graph into concrete development phases.
+
+Each phase should:
+1. Have clear entry criteria (what must exist before starting)
+2. Contain tasks that can be parallelized (no inter-dependencies within phase)
+3. Have clear exit criteria (how do we know phase is complete?)
+4. Build toward something USABLE (not just infrastructure)
+
+Phase ordering follows topological sort of dependency graph.
+
+<example type="good">
+Phase 0: Foundation
+  Entry: Clean repository
+  Tasks:
+    - Implement error handling utilities
+    - Create base type definitions
+    - Setup configuration system
+  Exit: Other modules can import foundation without errors
+
+Phase 1: Data Layer
+  Entry: Phase 0 complete
+  Tasks:
+    - Implement schema validator (uses: base types, error handling)
+    - Build data ingestion pipeline (uses: validator, config)
+  Exit: End-to-end data flow from input to validated output
+</example>
+
+<example type="bad">
+Phase 1: Build Everything
+  Tasks:
+    - API
+    - Database
+    - UI
+    - Tests
+  (Problem: No clear focus. Too broad. Dependencies not considered.)
+</example>
+</instruction>
+
+## Development Phases
+
+### Phase 0: [Foundation Name]
+**Goal**: [What foundational capability this establishes]
+
+**Entry Criteria**: [What must be true before starting]
+
+**Tasks**:
+- [ ] [Task name] (depends on: [none or list])
+  - Acceptance criteria: [How we know it's done]
+  - Test strategy: [What tests prove it works]
+
+- [ ] [Task name] (depends on: [none or list])
+
+**Exit Criteria**: [Observable outcome that proves phase complete]
+
+**Delivers**: [What can users/developers do after this phase?]
+
+---
+
+### Phase 1: [Layer Name]
+**Goal**:
+
+**Entry Criteria**: Phase 0 complete
+
+**Tasks**:
+- [ ] [Task name] (depends on: [[tasks-from-phase-0]])
+- [ ] [Task name] (depends on: [[tasks-from-phase-0]])
+
+**Exit Criteria**:
+
+**Delivers**:
+
+---
+
+[Continue with more phases...]
+
+</implementation-roadmap>
+
+---
+
+<test-strategy>
+<instruction>
+Define how testing will be integrated throughout development (TDD approach).
+
+Specify:
+1. Test pyramid ratios (unit vs integration vs e2e)
+2. Coverage requirements
+3. Critical test scenarios
+4. Test generation guidelines for Surgical Test Generator
+
+This section guides the AI when generating tests during the RED phase of TDD.
+
+<example type="good">
+Critical Test Scenarios for Data Validation module:
+  - Happy path: Valid data passes all checks
+  - Edge cases: Empty strings, null values, boundary numbers
+  - Error cases: Invalid types, missing required fields
+  - Integration: Validator works with ingestion pipeline
+</example>
+</instruction>
+
+## Test Pyramid
+
+```
+        /\
+       /E2E\       ← [X]% (End-to-end, slow, comprehensive)
+      /------\
+     /Integration\ ← [Y]% (Module interactions)
+    /------------\
+   /  Unit Tests  \ ← [Z]% (Fast, isolated, deterministic)
+  /----------------\
+```
+
+## Coverage Requirements
+- Line coverage: [X]% minimum
+- Branch coverage: [X]% minimum
+- Function coverage: [X]% minimum
+- Statement coverage: [X]% minimum
+
+## Critical Test Scenarios
+
+### [Module/Feature Name]
+**Happy path**:
+- [Scenario description]
+- Expected: [What should happen]
+
+**Edge cases**:
+- [Scenario description]
+- Expected: [What should happen]
+
+**Error cases**:
+- [Scenario description]
+- Expected: [How system handles failure]
+
+**Integration points**:
+- [What interactions to test]
+- Expected: [End-to-end behavior]
+
+## Test Generation Guidelines
+[Specific instructions for Surgical Test Generator about what to focus on, what patterns to follow, project-specific test conventions]
+
+</test-strategy>
+
+---
+
+<architecture>
+<instruction>
+Describe technical architecture, data models, and key design decisions.
+
+Keep this section AFTER functional/structural decomposition - implementation details come after understanding structure.
+</instruction>
+
+## System Components
+[Major architectural pieces and their responsibilities]
+
+## Data Models
+[Core data structures, schemas, database design]
+
+## Technology Stack
+[Languages, frameworks, key libraries]
+
+**Decision: [Technology/Pattern]**
+- **Rationale**: [Why chosen]
+- **Trade-offs**: [What we're giving up]
+- **Alternatives considered**: [What else we looked at]
+
+</architecture>
+
+---
+
+<risks>
+<instruction>
+Identify risks that could derail development and how to mitigate them.
+
+Categories:
+- Technical risks (complexity, unknowns)
+- Dependency risks (blocking issues)
+- Scope risks (creep, underestimation)
+</instruction>
+
+## Technical Risks
+**Risk**: [Description]
+- **Impact**: [High/Medium/Low - effect on project]
+- **Likelihood**: [High/Medium/Low]
+- **Mitigation**: [How to address]
+- **Fallback**: [Plan B if mitigation fails]
+
+## Dependency Risks
+[External dependencies, blocking issues]
+
+## Scope Risks
+[Scope creep, underestimation, unclear requirements]
+
+</risks>
+
+---
+
+<appendix>
+## References
+[Papers, documentation, similar systems]
+
+## Glossary
+[Domain-specific terms]
+
+## Open Questions
+[Things to resolve during development]
+</appendix>
+
+---
+
+<task-master-integration>
+# How Task Master Uses This PRD
+
+When you run `task-master parse-prd <file>.txt`, the parser:
+
+1. **Extracts capabilities** → Main tasks
+   - Each `### Capability:` becomes a top-level task
+
+2. **Extracts features** → Subtasks
+   - Each `#### Feature:` becomes a subtask under its capability
+
+3. **Parses dependencies** → Task dependencies
+   - `Depends on: [X, Y]` sets task.dependencies = ["X", "Y"]
+
+4. **Orders by phases** → Task priorities
+   - Phase 0 tasks = highest priority
+   - Phase N tasks = lower priority, properly sequenced
+
+5. **Uses test strategy** → Test generation context
+   - Feeds test scenarios to Surgical Test Generator during implementation
+
+**Result**: A dependency-aware task graph that can be executed in topological order.
+
+## Why RPG Structure Matters
+
+Traditional flat PRDs lead to:
+- ❌ Unclear task dependencies
+- ❌ Arbitrary task ordering
+- ❌ Circular dependencies discovered late
+- ❌ Poorly scoped tasks
+
+RPG-structured PRDs provide:
+- ✅ Explicit dependency chains
+- ✅ Topological execution order
+- ✅ Clear module boundaries
+- ✅ Validated task graph before implementation
+
+## Tips for Best Results
+
+1. **Spend time on dependency graph** - This is the most valuable section for Task Master
+2. **Keep features atomic** - Each feature should be independently testable
+3. **Progressive refinement** - Start broad, use `task-master expand` to break down complex tasks
+4. **Use research mode** - `task-master parse-prd --research` leverages AI for better task generation
+</task-master-integration>