gil/fe-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

새로운 프로젝트 구조 및 개발 가이드라인 추가: .mcp.json, shrimp_data, shrimp-rules.md, Cursor 설정 가이드, 업무일지 템플릿, ROADMAP.md, 커밋 메시지 규칙 포함. 각 파일은 Nuxt 4 및 TypeScript strict 모드에 최적화된 개발 환경을 지원합니다.

Browse Source
This commit is contained in:
hyeonggil
2026-03-19 23:12:15 +09:00
commit d65bb12a15
10 changed files with 1502 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
.claude/agent-memory/frontend-roadmap-architect/MEMORY.md Normal file
View File

@@ -0,0 +1,24 @@
# Frontend Roadmap Architect - Memory
## 프로젝트 컨텍스트
- **조직**: Smilegate FE Team
- **원본 문서**: FE AI 표준화 방안 (https://static-pubcomm.onstove.com/live/fe-project/fe_ai_standardization.html)
- **기술 스택**: Nuxt 4, TypeScript strict, Tailwind CSS v4, shadcn-vue, Pinia, Vitest
- **로드맵 위치**: `/Users/hyeonggilkim/fe-agent/docs/ROADMAP.md`
## 문서 구조
- 4단계 프로세스: 기획(Planning) -> 디자인(Design) -> 구현(Implementation) -> 검증(Verification)
- 전사 공통: 일정관리 표준화, 업무일지 표준화
- 총 21개 표준화 항목 (공통 2 + Step별 3/3/8/4)
## 로드맵 설계 패턴
- 2주 스프린트 x 6 + 준비 1주 = 총 13주 구성
- MoSCoW 프레임워크: Must 8개, Should 7개, Could 5개
- 태스크 분해: 1-3일 단위, 총 50+ 태스크
- 팀 가정: 5-7명 (TL 1, Senior 2, Mid 2-3, Junior 1)
## 사용자 선호
- 산출물 언어: 한국어
- 코드 주석: 한국어
- 커밋 메시지: 한국어
- 변수/함수명: 영어

144
.claude/agents/frontend-roadmap-architect.md Normal file
View File

@@ -0,0 +1,144 @@
---
name: frontend-roadmap-architect
description: "Use this agent when you need to transform complex technical standardization documents, architecture decisions, or tech stack specifications into actionable development roadmaps and execution plans. This agent is ideal for project planning, sprint organization, technical debt prioritization, and converting abstract frontend standards into concrete team tasks.\\n\\n<example>\\nContext: The user has just finalized a Nuxt 4 migration guide and technical standards document and needs it converted into a team roadmap.\\nuser: \"우리 팀의 Nuxt 4 마이그레이션 기술 표준 문서를 실행 가능한 개발 로드맵으로 변환해줘\"\\nassistant: \"frontend-roadmap-architect 에이전트를 사용하여 기술 표준 문서를 실행 가능한 로드맵으로 변환하겠습니다.\"\\n<commentary>\\nThe user wants to turn a technical standards document into an actionable roadmap. Use the Task tool to launch the frontend-roadmap-architect agent.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: The user has a list of new frontend coding standards and wants them broken down into sprint tasks.\\nuser: \"새로운 TypeScript strict 모드 및 컴포넌트 분리 원칙을 스프린트 태스크로 분해해줘\"\\nassistant: \"frontend-roadmap-architect 에이전트를 호출하여 코딩 표준을 스프린트 태스크로 분해하겠습니다.\"\\n<commentary>\\nThe user needs coding standards converted into sprint-level actionable tasks. Use the Task tool to launch the frontend-roadmap-architect agent.\\n</commentary>\\n</example>\\n\\n<example>\\nContext: A team has accumulated technical debt and needs a prioritized remediation plan.\\nuser: \"현재 프로젝트의 기술 부채 목록을 우선순위 기반 실행 계획으로 만들어줘\"\\nassistant: \"지금 frontend-roadmap-architect 에이전트를 사용하여 기술 부채 우선순위 계획을 작성하겠습니다.\"\\n<commentary>\\nThe user needs a technical debt prioritization roadmap. Use the Task tool to launch the frontend-roadmap-architect agent.\\n</commentary>\\n</example>"
model: opus
color: red
memory: project
---
당신은 최고 수준의 프로젝트 매니저이자 프론트엔드 기술 아키텍트입니다. 수년간의 대규모 프론트엔드 프로젝트 경험을 바탕으로, 복잡한 기술 표준화 문서를 개발팀이 실제로 실행 가능한 로드맵으로 변환하는 전문가입니다.
## 기술 전문성
당신은 다음 기술 스택에 깊은 전문 지식을 보유합니다:
- **프레임워크**: Nuxt 4, Vue 3 (Composition API)
- **언어**: TypeScript (strict 모드)
- **CSS**: Tailwind CSS v4
- **UI**: shadcn-vue
- **상태관리**: Pinia
- **테스트**: Vitest + @nuxt/test-utils
- **빌드/인프라**: pnpm, ESLint, Prettier, Nitro
## 핵심 역할 및 책임
### 1. 기술 문서 분석
- 기술 표준화 문서, 아키텍처 결정사항(ADR), 마이그레이션 가이드를 수신하면 즉시 구조적으로 분석합니다.
- 각 기술 요구사항을 **비즈니스 임팩트**, **기술적 복잡도**, **팀 역량 요구사항** 3가지 축으로 평가합니다.
- 모호한 기술 요구사항은 명확히 하기 위해 구체적인 질문을 제시합니다.
### 2. 로드맵 설계 원칙
**우선순위 결정 프레임워크 (MoSCoW)**:
- **Must Have**: 프로젝트 기반 안정성에 필수적인 항목 (예: TypeScript strict 설정, 디렉토리 구조 마이그레이션)
- **Should Have**: 팀 생산성을 크게 향상시키는 항목 (예: ESLint 규칙 정비, 컴포넌트 분리 표준화)
- **Could Have**: 코드 품질 개선에 기여하지만 즉각적이지 않은 항목
- **Won't Have (이번 사이클)**: 현 시점에서 범위 외 항목
**스프린트 구성 원칙**:
- 각 스프린트는 명확한 완료 기준(Definition of Done)을 포함해야 합니다.
- 스프린트 당 기술 부채 작업은 전체 용량의 20-30%를 초과하지 않도록 권고합니다.
- 각 태스크는 **1-3일** 단위로 분해합니다. (더 크면 추가 분해 권장)
### 3. 로드맵 산출물 형식
로드맵을 작성할 때 반드시 다음 구조를 따릅니다:
```
## 📋 프로젝트 개요
- 목표, 기간, 팀 구성, 성공 지표
## 🗺️ 마일스톤 개요
- 단계별 큰 그림 (Phase 1, 2, 3...)
## 📅 스프린트 계획
### Sprint N: [스프린트 명]
- **기간**:
- **목표**:
- **태스크 목록**:
- [ ] 태스크명 | 담당자 역할 | 예상 소요 시간 | 우선순위
- **완료 기준 (DoD)**:
- **리스크 및 의존성**:
## ⚠️ 리스크 레지스터
- 리스크 항목 | 발생 가능성 | 영향도 | 대응 방안
## 📊 성공 지표 (KPI)
```
### 4. Nuxt 4 프로젝트 특화 고려사항
로드맵 작성 시 다음 Nuxt 4 특이사항을 반드시 반영합니다:
- `app/` 디렉토리 구조로의 마이그레이션이 포함된 경우, 이를 **별도 마이그레이션 스프린트**로 분리합니다.
- TypeScript strict 모드 적용은 **점진적 적용 전략** (파일 단위 → 모듈 단위 → 전체)을 권고합니다.
- `any` 타입 제거 작업은 자동화 도구(tsc --noEmit) 활용 태스크를 포함합니다.
- shadcn-vue 컴포넌트 표준화 작업은 기존 컴포넌트 인벤토리 작성을 선행 태스크로 포함합니다.
### 5. 커뮤니케이션 및 문서화 규칙
- **모든 산출물은 한국어로 작성**합니다.
- 코드 예시가 필요한 경우 코드 주석도 한국어로 작성합니다.
- 태스크 설명은 개발자가 즉시 실행 가능할 만큼 구체적으로 작성합니다.
- 기술 용어는 원문(영문)을 병기합니다. (예: 컴포저블(Composable))
## 작업 프로세스
1. **입력 수신**: 기술 문서, 표준 목록, 또는 아키텍처 요구사항을 받습니다.
2. **구조 분석**: 항목을 분류하고 의존성 그래프를 파악합니다.
3. **명확화 요청**: 불명확한 항목이 있으면 구체적인 질문 목록을 먼저 제시합니다.
4. **초안 로드맵 작성**: 위의 형식에 따라 로드맵 초안을 작성합니다.
5. **자기 검증**: 다음 체크리스트로 품질을 검증합니다:
- [ ] 모든 기술 요구사항이 최소 하나의 태스크에 매핑되었는가?
- [ ] 각 태스크는 1-3일 내 완료 가능한 크기인가?
- [ ] 의존성 순서가 올바르게 반영되었는가?
- [ ] 리스크가 식별되고 대응 방안이 제시되었는가?
- [ ] 성공 지표가 측정 가능한 형태로 정의되었는가?
6. **최종 산출물 제공**: 검증 완료 후 최종 로드맵을 제공합니다.
## 에스컬레이션 및 폴백 전략
- 기술적 의사결정이 필요한 트레이드오프가 발견되면 옵션과 장단점을 제시하고 의사결정을 요청합니다.
- 팀 규모나 역량 정보가 없을 경우, 5-7명 풀스택 프론트엔드 팀을 기본 가정으로 명시하고 작업합니다.
- 기간 정보가 없을 경우, 2주 스프린트 기준으로 계획을 수립하고 조정 가능함을 명시합니다.
**Update your agent memory** as you discover project-specific patterns, team conventions, recurring technical debt themes, and architectural decisions from this codebase. This builds up institutional knowledge across conversations.
기억에 기록할 항목 예시:
- 프로젝트의 현재 기술 부채 패턴 및 반복 이슈
- 팀이 선호하는 스프린트 길이 및 태스크 분해 단위
- 과거 로드맵에서 실제로 지연된 항목 및 원인
- 팀의 기술 역량 수준 및 온보딩 필요 영역
- 자주 참조되는 아키텍처 결정사항(ADR)
# Persistent Agent Memory
You have a persistent Persistent Agent Memory directory at `/Users/hyeonggilkim/fe-agent/.claude/agent-memory/frontend-roadmap-architect/`. Its contents persist across conversations.
As you work, consult your memory files to build on previous experience. When you encounter a mistake that seems like it could be common, check your Persistent Agent Memory for relevant notes — and if nothing is written yet, record what you learned.
Guidelines:
- `MEMORY.md` is always loaded into your system prompt — lines after 200 will be truncated, so keep it concise
- Create separate topic files (e.g., `debugging.md`, `patterns.md`) for detailed notes and link to them from MEMORY.md
- Update or remove memories that turn out to be wrong or outdated
- Organize memory semantically by topic, not chronologically
- Use the Write and Edit tools to update your memory files
What to save:
- Stable patterns and conventions confirmed across multiple interactions
- Key architectural decisions, important file paths, and project structure
- User preferences for workflow, tools, and communication style
- Solutions to recurring problems and debugging insights
What NOT to save:
- Session-specific context (current task details, in-progress work, temporary state)
- Information that might be incomplete — verify against project docs before writing
- Anything that duplicates or contradicts existing CLAUDE.md instructions
- Speculative or unverified conclusions from reading a single file
Explicit user requests:
- When the user asks you to remember something across sessions (e.g., "always use bun", "never auto-commit"), save it — no need to wait for multiple interactions
- When the user asks to forget or stop remembering something, find and remove the relevant entries from your memory files
- Since this memory is project-scope and shared with your team via version control, tailor your memories to this project
## MEMORY.md
Your MEMORY.md is currently empty. When you notice a pattern worth preserving across sessions, save it here. Anything in MEMORY.md will be included in your system prompt next time.

11
.claude/settings.local.json Normal file
View File

@@ -0,0 +1,11 @@
{
"permissions": {
"allow": [
"WebFetch(domain:static-pubcomm.onstove.com)"
]
},
"enabledMcpjsonServers": [
"shrimp-task-manager"
],
"enableAllProjectMcpServers": true
}

13
.mcp.json Normal file
View File

@@ -0,0 +1,13 @@
{
"mcpServers": {
"shrimp-task-manager": {
"command": "node",
"args": ["/Users/hyeonggilkim/01.Study/shrimp/mcp-shrimp-task-manager/dist/index.js"],
"env": {
"DATA_DIR": "/Users/hyeonggilkim/fe-agent/shrimp_data",
"TEMPLATES_USE": "en",
"ENABLE_GUI": "true"
}
}
}
}

400
docs/ROADMAP.md Normal file
View File

@@ -0,0 +1,400 @@
# FE AI 표준화 실행 로드맵
> 원본 문서: [FE AI 표준화 방안](https://static-pubcomm.onstove.com/live/fe-project/fe_ai_standardization.html)
> 작성일: 2026-03-19
> 기술 스택: Nuxt 4 / TypeScript strict / Tailwind CSS v4 / shadcn-vue / Pinia / Vitest
---
## 프로젝트 개요
### 목표
FE 팀의 AI 활용 표준화를 기획-디자인-구현-검증 4단계에 걸쳐 체계적으로 도입한다. 각 단계의 표준화 항목을 구체적인 태스크로 분해하고, Nuxt 4 기반 프로젝트에 실제 적용 가능한 수준으로 구현한다.
### 기간
- 총 12주 (6개 스프린트, 각 2주)
- Sprint 0(준비) 1주 포함 시 총 13주
### 팀 구성 (기본 가정: 5-7명)
| 역할 | 인원 | 담당 영역 |
|------|------|-----------|
| 테크 리드 (Tech Lead) | 1명 | 아키텍처 결정, 컨벤션 수립, 코드 리뷰 |
| 시니어 개발자 (Senior Dev) | 2명 | CI/CD, 보안, 테스트 자동화, 핵심 모듈 구현 |
| 미드레벨 개발자 (Mid Dev) | 2-3명 | 컴포넌트 구현, i18n, 문서 자동화 |
| 주니어 개발자 (Junior Dev) | 1명 | 프로모션 마크업, EDM, 보조 태스크 |
### 성공 지표 요약
- AI 도구 활용률 80% 이상 (Copilot/Cursor 일일 활성 사용)
- 코드 리뷰 자동 요약 적용률 100%
- 단위 테스트 커버리지 70% 이상
- 보안 취약점 자동 탐지 파이프라인 구축 완료
---
## MoSCoW 우선순위 분류
### Must Have (필수)
| ID | 항목 | 근거 |
|----|------|------|
| M1 | 개발 컨벤션 표준화 (i18n, 에러 처리, 미들웨어) | 프로젝트 기반 안정성의 핵심 |
| M2 | AI 코딩 도구 설정 (Copilot/Cursor) | 전 팀원 생산성 기반 |
| M3 | 파일 수정 표준화 (커밋 메시지, 단위 테스트 표준) | 코드 품질 게이트 역할 |
| M4 | 코드 리뷰 자동화 (MR/PR 요약, Conflict 처리) | 리뷰 병목 해소 |
| M5 | CI 파이프라인 표준화 | 빌드/배포 안정성 |
| M6 | 테스트 케이스 설계 및 자동 생성 | 품질 보증 기반 |
| M7 | 일정관리 표준화 | 전 단계 공통, 프로젝트 관리 기반 |
| M8 | 업무일지 표준화 | 전 단계 공통, 진행 상황 추적 |
### Should Have (권장)
| ID | 항목 | 근거 |
|----|------|------|
| S1 | 스펙 검토 표준화 (플로우차트 기반 기능 요건 정의) | 기획 품질 향상 |
| S2 | SEO 정보 추출 표준화 | 검색 최적화 자동화 |
| S3 | 번역코드 생성 표준화 (i18n 키 자동 생성) | 다국어 생산성 |
| S4 | 코드 리팩토링 (AI 제안 기반) | 기술 부채 관리 |
| S5 | 기술 문서 자동화 (ERD, README, 주석) | 문서화 부담 감소 |
| S6 | 기능/통합 테스트 자동화 | 회귀 테스트 강화 |
| S7 | 보안검수 표준화 | 보안 리스크 감소 |
### Could Have (선택)
| ID | 항목 | 근거 |
|----|------|------|
| C1 | 피그마 네이밍 규칙 표준화 | 디자인-개발 협업 개선 |
| C2 | EDM 표준화 | 이메일 마케팅 효율화 |
| C3 | 프로모션 마크업 표준화 | 반복 작업 자동화 |
| C4 | 성능/보안 검토 (병목 분석) | 최적화 |
| C5 | 버그 리포트/수정 자동화 | 디버깅 효율화 |
### Won't Have (이번 사이클 제외)
- 없음 (모든 항목을 12주 내 단계적으로 다룸. 단, Could Have 항목은 팀 여력에 따라 조정)
---
## 마일스톤 개요
```
Phase 0 [1주] : 기반 구축 - 도구 설정, 공통 표준 수립
Phase 1 [2주] : 개발 컨벤션 및 AI 코딩 환경 구축
Phase 2 [2주] : 코드 리뷰 자동화 및 CI 파이프라인
Phase 3 [2주] : 기획/디자인 단계 표준화 및 문서 자동화
Phase 4 [2주] : 테스트 자동화 및 보안 표준화
Phase 5 [2주] : 성능 최적화, 버그 자동화, 고도화
Phase 6 [2주] : 안정화, 교육, 전사 롤아웃
```
---
## 스프린트 계획
---
### Sprint 0: 기반 구축 및 공통 표준 수립
- **기간**: 1주 (2026-03-23 ~ 2026-03-27)
- **목표**: 전사 공통 적용 사항(일정관리, 업무일지) 표준을 확정하고, AI 도구 환경을 준비한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T0-1. 일정관리 표준화 템플릿 설계 및 도구 선정 (Jira/Linear/Notion 등) | 테크 리드 | 1일 | Must |
| T0-2. 업무일지 표준화 템플릿 설계 (AI 자동 요약 연동 검토) | 테크 리드 | 1일 | Must |
| T0-3. Copilot 라이선스 확인 및 전 팀원 설치/설정 가이드 작성 | 시니어 Dev | 1일 | Must |
| T0-4. Cursor 에디터 설정 가이드 작성 (Nuxt 4 프로젝트 컨텍스트 설정 포함) | 시니어 Dev | 1일 | Must |
| T0-5. AI 도구 활용 규칙 문서화 (프롬프트 가이드, 코드 검증 정책) | 미드 Dev | 1일 | Must |
| T0-6. Nuxt 4 프로젝트 보일러플레이트 생성 및 `app/` 디렉토리 구조 확인 | 미드 Dev | 1일 | Must |
#### 완료 기준 (DoD)
- [ ] 일정관리 및 업무일지 템플릿이 팀 Confluence/Notion에 등록됨
- [ ] 전 팀원이 Copilot 또는 Cursor 중 최소 1개 도구를 설치 완료
- [ ] AI 도구 활용 규칙 문서가 리뷰 및 승인됨
- [ ] Nuxt 4 보일러플레이트가 Git 저장소에 푸시됨
#### 리스크 및 의존성
- **리스크**: Copilot 라이선스 승인 지연 가능성 (발생 시 Cursor 우선 도입)
- **의존성**: 없음 (첫 스프린트)
---
### Sprint 1: 개발 컨벤션 및 AI 코딩 환경 구축
- **기간**: 2주 (2026-03-30 ~ 2026-04-10)
- **목표**: i18n 미들웨어, 에러 처리, 언어 정책 등 개발 컨벤션을 코드 수준에서 확립하고, 커밋 메시지/단위 테스트 표준을 적용한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T1-1. i18n 미들웨어 표준 구현 (`app/middleware/i18n.ts`) | 시니어 Dev | 2일 | Must |
| T1-2. i18n 언어 정책 점검 로직 구현 (지원 언어 목록, fallback 전략) | 시니어 Dev | 1일 | Must |
| T1-3. 글로벌 에러 처리 표준 구현 (`app/plugins/error-handler.ts`, `app/error.vue`) | 시니어 Dev | 2일 | Must |
| T1-4. 인트로(Intro) 페이지 표준 템플릿 작성 | 미드 Dev | 1일 | Must |
| T1-5. 커밋 메시지 표준 설정 (commitlint + husky 설정) | 미드 Dev | 1일 | Must |
| T1-6. 단위 테스트 표준 가이드 작성 (Vitest + @nuxt/test-utils 설정) | 시니어 Dev | 2일 | Must |
| T1-7. 테스트 코드 자동 생성 프롬프트 템플릿 작성 (Copilot/Cursor용) | 미드 Dev | 1일 | Must |
| T1-8. ESLint + Prettier 규칙 통합 설정 (`@nuxt/eslint` 기반) | 미드 Dev | 1일 | Must |
| T1-9. TypeScript strict 모드 검증 및 `any` 타입 탐지 스크립트 작성 | 미드 Dev | 1일 | Must |
| T1-10. AI 코딩 도구 효과 측정 기준 수립 (생산성 메트릭 정의) | 테크 리드 | 1일 | Should |
#### 완료 기준 (DoD)
- [ ] i18n 미들웨어가 모든 라우트에서 정상 동작 확인 (테스트 포함)
- [ ] `app/error.vue` 에러 페이지가 구현되고 글로벌 에러 핸들러 작동 확인
- [ ] commitlint가 `feat:`, `fix:` 등 한국어 커밋 메시지 형식을 검증함
- [ ] Vitest 설정이 완료되고 샘플 테스트 3개 이상 통과
- [ ] `tsc --noEmit` 실행 시 `any` 타입 경고 0건
- [ ] ESLint + Prettier가 pre-commit hook으로 자동 실행됨
#### 리스크 및 의존성
- **리스크**: i18n 미들웨어와 Nuxt 4의 `app/middleware/` 구조 호환성 이슈 가능
- **의존성**: Sprint 0 완료 (보일러플레이트 기반)
- **대응**: Nuxt 4 공식 i18n 모듈(`@nuxtjs/i18n`) 최신 버전 호환성 사전 검증
---
### Sprint 2: 코드 리뷰 자동화 및 CI 파이프라인
- **기간**: 2주 (2026-04-14 ~ 2026-04-25)
- **목표**: MR/PR 자동 요약, Conflict 자동 처리를 포함한 코드 리뷰 자동화와 CI 파이프라인을 구축한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T2-1. AI 코드 리뷰 봇 선정 및 설정 (CodeRabbit/GitHub Copilot PR Review 등) | 시니어 Dev | 2일 | Must |
| T2-2. MR/PR 자동 요약 템플릿 설정 (변경 파일 요약, 영향 범위 분석) | 시니어 Dev | 1일 | Must |
| T2-3. Conflict 자동 감지 및 알림 워크플로우 구축 | 미드 Dev | 2일 | Must |
| T2-4. CI 파이프라인 기본 구축 (lint, type-check, test, build) | 시니어 Dev | 2일 | Must |
| T2-5. 빌드 오류 분석 자동화 (AI 기반 오류 메시지 해석 및 제안) | 미드 Dev | 2일 | Must |
| T2-6. CI 최적화 제안 자동화 (번들 사이즈 경고, 성능 회귀 감지) | 미드 Dev | 2일 | Should |
| T2-7. 코드 리팩토링 AI 제안 워크플로우 설계 (정기 리팩토링 사이클 정의) | 테크 리드 | 1일 | Should |
| T2-8. PR 템플릿 작성 (체크리스트: 테스트, 타입 검증, i18n 확인 포함) | 주니어 Dev | 1일 | Must |
#### 완료 기준 (DoD)
- [ ] PR 생성 시 AI 리뷰 봇이 자동으로 요약 코멘트를 작성함
- [ ] CI 파이프라인이 `pnpm lint && pnpm typecheck && pnpm test && pnpm build` 순서로 실행됨
- [ ] 빌드 실패 시 AI 기반 오류 분석 코멘트가 PR에 자동 첨부됨
- [ ] PR 템플릿이 저장소 `.github/PULL_REQUEST_TEMPLATE.md`에 등록됨
- [ ] Conflict 발생 시 Slack/Teams 알림이 트리거됨
#### 리스크 및 의존성
- **리스크**: AI 리뷰 봇의 오탐(false positive)으로 인한 팀 피로도 증가
- **의존성**: Sprint 1의 ESLint/Prettier 설정 완료
- **대응**: 초기 2주간 리뷰 봇 결과를 수동 검증 후 규칙 조정 기간 운영
---
### Sprint 3: 기획/디자인 표준화 및 기술 문서 자동화
- **기간**: 2주 (2026-04-28 ~ 2026-05-08)
- **목표**: 기획 단계(스펙 검토, SEO, 번역코드)와 디자인 단계(피그마, EDM, 프로모션) 표준을 확립하고, 기술 문서 자동화를 구축한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T3-1. 스펙 검토 표준화: 플로우차트 기반 기능 요건 정의 프롬프트 템플릿 작성 | 테크 리드 | 2일 | Should |
| T3-2. SEO 메타 정보 자동 추출 유틸리티 구현 (`app/utils/seo.ts`) | 미드 Dev | 2일 | Should |
| T3-3. Nuxt 4 `useHead()` / `useSeoMeta()` 표준 패턴 문서화 | 미드 Dev | 1일 | Should |
| T3-4. i18n 키 자동 생성 스크립트 구현 (소스 코드 스캔 -> 키 추출) | 시니어 Dev | 3일 | Should |
| T3-5. 피그마 네이밍 규칙 가이드 작성 (컴포넌트명, 레이어 구조 표준) | 미드 Dev | 1일 | Could |
| T3-6. EDM 이메일 템플릿 표준 규격 정의 및 샘플 작성 | 주니어 Dev | 2일 | Could |
| T3-7. 프로모션 마크업 자동 생성 도구 구현 (이미지URL, 기간, 유의사항, 아이템코드 입력 -> HTML 생성) | 주니어 Dev | 3일 | Could |
| T3-8. ERD 자동 작성 도구/프롬프트 표준화 | 미드 Dev | 1일 | Should |
| T3-9. README 자동 생성 스크립트 구현 (프로젝트 구조 기반) | 미드 Dev | 1일 | Should |
| T3-10. 코드 주석 자동 생성 규칙 설정 (JSDoc/TSDoc 표준) | 미드 Dev | 1일 | Should |
#### 완료 기준 (DoD)
- [ ] 스펙 검토 프롬프트 템플릿이 팀 위키에 등록되고 최소 1개 프로젝트에 시범 적용됨
- [ ] `useSeoMeta()` 표준 패턴이 문서화되고 샘플 페이지에 적용됨
- [ ] i18n 키 자동 생성 스크립트가 `pnpm i18n:extract` 명령으로 실행 가능
- [ ] 프로모션 마크업 생성 도구가 CLI 또는 웹 UI로 동작 확인
- [ ] README 자동 생성 스크립트가 프로젝트 루트에서 실행 가능
#### 리스크 및 의존성
- **리스크**: i18n 키 자동 생성의 정확도 문제 (동적 키 패턴 누락 가능)
- **의존성**: Sprint 1의 i18n 미들웨어 구현 완료
- **대응**: 동적 키 패턴에 대한 수동 검증 프로세스 병행, 점진적 정확도 개선
---
### Sprint 4: 테스트 자동화 및 보안 표준화
- **기간**: 2주 (2026-05-11 ~ 2026-05-22)
- **목표**: 테스트 케이스 자동 생성, 기능/통합 테스트 자동화, 보안 취약점 탐지를 구축한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T4-1. 테스트 케이스 자동 생성 프롬프트 고도화 (엣지 케이스 도출 포함) | 시니어 Dev | 2일 | Must |
| T4-2. 컴포넌트 테스트 표준 작성 (Vitest + @vue/test-utils 패턴) | 시니어 Dev | 2일 | Must |
| T4-3. 기능 테스트(E2E) 자동화 프레임워크 설정 (Playwright 또는 Cypress) | 시니어 Dev | 3일 | Should |
| T4-4. 통합 테스트 자동화 스크립트 구현 (API 목 서버 포함) | 미드 Dev | 2일 | Should |
| T4-5. 이슈 자동 탐지 워크플로우 (테스트 실패 시 자동 이슈 생성) | 미드 Dev | 1일 | Should |
| T4-6. 보안 취약점 자동 탐지 설정 (npm audit, Snyk/Trivy 연동) | 시니어 Dev | 2일 | Should |
| T4-7. 보안 패턴 검사 규칙 정의 (XSS, CSRF, SQL Injection 패턴) | 미드 Dev | 2일 | Should |
| T4-8. 보안 검사 CI 파이프라인 통합 | 미드 Dev | 1일 | Should |
| T4-9. 테스트 커버리지 리포트 자동 생성 및 PR 코멘트 연동 | 미드 Dev | 1일 | Must |
#### 완료 기준 (DoD)
- [ ] AI 프롬프트로 컴포넌트별 테스트 케이스 자동 생성이 가능함 (최소 5개 컴포넌트)
- [ ] E2E 테스트 프레임워크가 설정되고 핵심 플로우 3개 이상 자동화됨
- [ ] `pnpm audit` 또는 Snyk 스캔이 CI 파이프라인에 통합됨
- [ ] 테스트 커버리지 리포트가 PR 코멘트에 자동 첨부됨
- [ ] 보안 패턴 검사 규칙이 ESLint 플러그인 또는 별도 스크립트로 실행 가능
#### 리스크 및 의존성
- **리스크**: E2E 테스트의 CI 환경 불안정성 (헤드리스 브라우저 이슈)
- **의존성**: Sprint 2의 CI 파이프라인 구축 완료
- **대응**: CI 환경에서 Docker 기반 헤드리스 브라우저 사용, 재시도 로직 적용
---
### Sprint 5: 성능 최적화, 버그 자동화, AI 리팩토링 고도화
- **기간**: 2주 (2026-05-25 ~ 2026-06-05)
- **목표**: 성능/보안 검토, 버그 리포트 자동화, AI 리팩토링 제안 시스템을 고도화한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T5-1. 성능 병목 분석 자동화 (Lighthouse CI 연동) | 시니어 Dev | 2일 | Could |
| T5-2. 번들 사이즈 모니터링 대시보드 구축 | 미드 Dev | 2일 | Could |
| T5-3. 버그 원인 분석 AI 프롬프트 표준화 (에러 로그 -> 원인 분석 템플릿) | 미드 Dev | 1일 | Could |
| T5-4. 버그 수정 제안 자동화 (AI 기반 수정 코드 생성) | 시니어 Dev | 2일 | Could |
| T5-5. 자동 버그 리포팅 워크플로우 구축 (에러 트래킹 -> 이슈 자동 생성) | 미드 Dev | 2일 | Could |
| T5-6. AI 리팩토링 제안 정기 실행 스크립트 구현 (주간 코드 품질 리포트) | 시니어 Dev | 2일 | Should |
| T5-7. 코드 품질 메트릭 대시보드 구축 (복잡도, 중복도, 커버리지 통합) | 미드 Dev | 2일 | Should |
| T5-8. shadcn-vue 컴포넌트 인벤토리 작성 및 사용 현황 분석 | 미드 Dev | 1일 | Should |
#### 완료 기준 (DoD)
- [ ] Lighthouse CI가 PR 단위로 성능 점수를 리포트함
- [ ] 프로덕션 에러 발생 시 자동으로 이슈가 생성됨
- [ ] 주간 코드 품질 리포트가 팀 채널에 자동 발송됨
- [ ] shadcn-vue 컴포넌트 인벤토리 문서가 작성됨
#### 리스크 및 의존성
- **리스크**: 에러 트래킹 도구(Sentry 등) 미도입 시 자동 리포팅 구현 제한
- **의존성**: Sprint 4의 테스트 및 보안 파이프라인 완료
- **대응**: Sentry 미도입 시 `console.error` 후킹 + GitHub Issues API 연동으로 대체
---
### Sprint 6: 안정화, 교육, 전사 롤아웃
- **기간**: 2주 (2026-06-08 ~ 2026-06-19)
- **목표**: 전체 표준화 항목을 검증하고, 팀 교육 및 전사 확산을 준비한다.
#### 태스크 목록
| 태스크 | 담당 역할 | 소요 시간 | 우선순위 |
|--------|-----------|-----------|----------|
| T6-1. 전체 표준화 항목 체크리스트 기반 최종 검증 | 테크 리드 | 2일 | Must |
| T6-2. 미완료 항목 보완 작업 (버퍼) | 전원 | 3일 | Must |
| T6-3. AI 표준화 활용 가이드북 최종본 작성 | 테크 리드 | 2일 | Must |
| T6-4. 팀 내 워크숍 진행 (AI 도구 활용 실습, Q&A) | 테크 리드 + 시니어 | 1일 | Must |
| T6-5. 전사 공유 세션 준비 및 발표 자료 작성 | 테크 리드 | 2일 | Should |
| T6-6. 표준화 효과 측정 리포트 작성 (KPI 기반) | 테크 리드 | 1일 | Should |
| T6-7. 차기 분기 개선 로드맵 초안 작성 | 테크 리드 | 1일 | Could |
#### 완료 기준 (DoD)
- [ ] 문서 원본의 4단계 19개 항목 + 공통 2개 항목 = 총 21개 표준화 항목이 모두 태스크에 매핑됨
- [ ] AI 표준화 가이드북이 팀 위키에 최종 등록됨
- [ ] 워크숍이 전 팀원 대상으로 진행됨
- [ ] KPI 측정 리포트가 작성되고 경영진에 보고됨
#### 리스크 및 의존성
- **리스크**: 이전 스프린트의 미완료 태스크 누적으로 안정화 기간 부족
- **의존성**: Sprint 0-5의 모든 Must Have 태스크 완료
- **대응**: Sprint 5까지의 주간 회고에서 미완료 태스크를 조기에 식별하고 Sprint 6 버퍼에 반영
---
## 리스크 레지스터
| ID | 리스크 항목 | 발생 가능성 | 영향도 | 대응 방안 |
|----|-------------|-------------|--------|-----------|
| R1 | Copilot/Cursor 라이선스 승인 지연 | 중 | 높음 | Cursor 무료 티어 우선 도입, Copilot은 승인 후 전환 |
| R2 | AI 리뷰 봇 오탐(False Positive) 누적 | 높음 | 중 | 2주 튜닝 기간 운영, 팀 피드백 기반 규칙 조정 |
| R3 | Nuxt 4 + i18n 모듈 호환성 이슈 | 중 | 높음 | `@nuxtjs/i18n` 최신 버전 사전 검증, 커스텀 미들웨어 폴백 준비 |
| R4 | TypeScript strict 모드 전환 시 기존 코드 대량 수정 필요 | 높음 | 중 | 점진적 적용 전략 (파일 단위 -> 모듈 단위 -> 전체) |
| R5 | E2E 테스트 CI 환경 불안정 (헤드리스 브라우저) | 중 | 중 | Docker 기반 실행 환경, 재시도 로직(3회) 적용 |
| R6 | i18n 키 자동 추출 정확도 부족 (동적 키 누락) | 높음 | 중 | 수동 검증 병행, 정규식 패턴 점진 개선 |
| R7 | 팀원 AI 도구 숙련도 편차 | 중 | 중 | 페어 프로그래밍 세션, 주간 팁 공유, 워크숍 운영 |
| R8 | 보안 도구(Snyk/Trivy) 유료 플랜 필요 | 낮음 | 낮음 | `npm audit` + 커스텀 ESLint 보안 규칙으로 우선 대체 |
| R9 | 에러 트래킹 도구(Sentry) 미도입 | 중 | 중 | GitHub Issues API 연동 자동 리포팅으로 대체 |
| R10 | 스프린트 간 태스크 이월 누적 | 중 | 높음 | 주간 회고에서 조기 식별, Sprint 6에 3일 버퍼 확보 |
---
## 성공 지표 (KPI)
### 생산성 지표
| 지표 | 측정 방법 | 목표치 | 측정 시점 |
|------|-----------|--------|-----------|
| AI 도구 일일 활성 사용률 | Copilot/Cursor 사용 로그 | 80% 이상 | Sprint 1 이후 주간 |
| PR 생성 ~ 머지 평균 시간 | GitHub/GitLab 메트릭 | 기존 대비 30% 단축 | Sprint 2 이후 격주 |
| 코드 리뷰 1차 응답 시간 | AI 봇 자동 요약 후 리뷰어 응답까지 | 4시간 이내 | Sprint 2 이후 주간 |
| i18n 키 생성 소요 시간 | 수동 vs 자동 비교 | 기존 대비 70% 단축 | Sprint 3 이후 |
### 품질 지표
| 지표 | 측정 방법 | 목표치 | 측정 시점 |
|------|-----------|--------|-----------|
| 단위 테스트 커버리지 | `vitest --coverage` | 70% 이상 | Sprint 4 이후 주간 |
| TypeScript `any` 타입 사용 건수 | `tsc --noEmit` + grep | 0건 | Sprint 1 이후 매 PR |
| ESLint 경고/에러 건수 | CI 파이프라인 리포트 | 경고 0건 | Sprint 1 이후 매 PR |
| 보안 취약점 미해결 건수 | npm audit / Snyk 리포트 | Critical/High 0건 | Sprint 4 이후 주간 |
| Lighthouse 성능 점수 | Lighthouse CI | 90점 이상 | Sprint 5 이후 |
### 프로세스 지표
| 지표 | 측정 방법 | 목표치 | 측정 시점 |
|------|-----------|--------|-----------|
| 표준화 항목 완료율 | 체크리스트 대비 완료 비율 | 100% (Must/Should) | Sprint 6 종료 시 |
| 일정관리 템플릿 활용률 | 팀 설문 | 90% 이상 | Sprint 6 종료 시 |
| 업무일지 작성률 | 주간 작성 건수 | 100% | Sprint 0 이후 주간 |
| 팀 만족도 (AI 도구 활용) | 분기 설문 | 4.0/5.0 이상 | Sprint 6 종료 시 |
---
## 부록: 원본 문서 항목 -> 태스크 매핑표
원본 문서의 모든 표준화 항목이 최소 1개 태스크에 매핑되었는지 검증한 결과입니다.
| 단계 | 원본 항목 | 매핑 태스크 |
|------|-----------|-------------|
| 공통 | 일정관리 표준화 | T0-1 |
| 공통 | 업무일지 표준화 | T0-2 |
| Step 1 기획 | 스펙 검토 표준화 | T3-1 |
| Step 1 기획 | SEO 정보 추출 표준화 | T3-2, T3-3 |
| Step 1 기획 | 번역코드 생성 표준화 | T3-4 |
| Step 2 디자인 | 피그마 네이밍 규칙 | T3-5 |
| Step 2 디자인 | EDM 표준화 | T3-6 |
| Step 2 디자인 | 프로모션 마크업 표준화 | T3-7 |
| Step 3 구현 | AI 코딩 | T0-3, T0-4, T0-5 |
| Step 3 구현 | 개발 컨벤션 표준화 | T1-1, T1-2, T1-3, T1-4 |
| Step 3 구현 | 코드 리팩토링 | T2-7, T5-6 |
| Step 3 구현 | 코드 리뷰 자동화 | T2-1, T2-2, T2-3 |
| Step 3 구현 | 파일 수정 표준화 | T1-5, T1-6, T1-7 |
| Step 3 구현 | CI 파이프라인 | T2-4, T2-5, T2-6 |
| Step 3 구현 | 기술 문서 자동화 | T3-8, T3-9, T3-10 |
| Step 3 구현 | 보안검수 표준화 | T4-6, T4-7, T4-8 |
| Step 4 검증 | 테스트 케이스 설계 | T4-1, T4-2 |
| Step 4 검증 | 기능/통합 테스트 | T4-3, T4-4, T4-5 |
| Step 4 검증 | 성능/보안 검토 | T5-1, T5-2 |
| Step 4 검증 | 버그 리포트/수정 | T5-3, T5-4, T5-5 |
**검증 결과**: 원본 문서의 공통 2개 + 4단계 19개 = 총 21개 항목이 모두 1개 이상의 태스크에 매핑되었습니다.
---
## 자기 검증 체크리스트
- [x] 모든 기술 요구사항이 최소 하나의 태스크에 매핑되었는가? (부록 매핑표 참조)
- [x] 각 태스크는 1-3일 내 완료 가능한 크기인가? (최대 3일 이내)
- [x] 의존성 순서가 올바르게 반영되었는가? (Sprint 0 -> 1 -> 2 -> 3 -> 4 -> 5 -> 6)
- [x] 리스크가 식별되고 대응 방안이 제시되었는가? (10개 리스크 항목)
- [x] 성공 지표가 측정 가능한 형태로 정의되었는가? (생산성/품질/프로세스 3개 카테고리)

339
docs/cursor-setup-guide.md Normal file
View File

@@ -0,0 +1,339 @@
# Cursor 에디터 설정 가이드 (Nuxt 4 최적화)
> 작성일: 2026-03-19
> 버전: v1.0
> 담당: 시니어 Dev
> 적용 대상: FE 팀 전원
---
## 개요
Cursor는 AI 기반 코드 에디터로, VS Code 기반 위에 Claude/GPT-4 등 LLM을 통합하여
코드 생성·리팩토링·디버깅을 대화형으로 지원합니다.
이 가이드는 Nuxt 4 프로젝트에 최적화된 Cursor 설치 및 설정 방법을 안내합니다.
### GitHub Copilot과의 차이점
| 항목 | GitHub Copilot | Cursor |
|------|---------------|--------|
| 기반 에디터 | VS Code (플러그인) | VS Code 포크 (독립 에디터) |
| AI 엔진 | GitHub (OpenAI 기반) | Claude / GPT-4o / 자체 모델 선택 가능 |
| 컨텍스트 | 현재 파일 중심 | 프로젝트 전체 인덱싱 (@codebase) |
| 대화형 편집 | 제한적 (인라인 제안) | Composer: 멀티파일 동시 편집 |
| 프로젝트 규칙 | 없음 | `.cursorrules` / `.cursor/rules/` |
| 가격 | $19/월 (Business) | $20/월 (Pro), 무료 티어 있음 |
> **권장**: Cursor를 주 에디터로 사용하고, Copilot은 VS Code 환경에서 병행 사용
---
## 1. 설치
### 1-1. 다운로드 및 설치
1. [cursor.com](https://www.cursor.com) 접속
2. **Download for Mac** 클릭 (macOS 기준)
3. `.dmg` 파일 실행 → Applications 폴더로 드래그
### 1-2. 기존 VS Code 설정 가져오기
최초 실행 시 **"Import from VS Code"** 선택:
- 익스텐션, 키바인딩, 테마, 설정이 자동으로 이전됩니다.
- 기존 VS Code 사용자는 적응 비용 최소화
### 1-3. 계정 연동
1. Cursor 실행 → 우측 하단 프로필 아이콘 클릭
2. **Sign In** → GitHub 계정으로 로그인 (권장)
3. 팀 플랜 사용 시 초대 링크로 팀 워크스페이스 참여
---
## 2. 초기 설정
### 2-1. AI 모델 선택
`Cursor Settings` (⌘ + ,) → **Models** 탭:
| 모델 | 추천 용도 | 속도 |
|------|----------|------|
| `claude-sonnet-4-6` | 복잡한 리팩토링, 아키텍처 설계 | 중간 |
| `claude-haiku-4-5` | 빠른 자동완성, 간단한 수정 | 빠름 |
| `gpt-4o` | 대안 모델 | 중간 |
> **권장**: 기본 모델을 `claude-sonnet-4-6`으로 설정
### 2-2. 핵심 설정값 (settings.json)
`⌘ + Shift + P` → **"Open User Settings (JSON)"** → 아래 설정 추가:
```json
{
// Cursor AI 설정
"cursor.general.enableShadowWorkspace": true,
"cursor.cpp.enablePartialAccepts": true,
// 자동완성 설정
"editor.inlineSuggest.enabled": true,
"editor.suggest.preview": true,
"editor.tabCompletion": "on",
// Nuxt 4 / Vue 3 최적화
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"[vue]": {
"editor.defaultFormatter": "Vue.volar"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
// TypeScript 설정
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
// 파일 제외 (성능 향상)
"files.exclude": {
"**/.nuxt": true,
"**/.output": true,
"**/node_modules": true,
"**/.git": true
},
// Tailwind CSS IntelliSense
"tailwindCSS.experimental.classRegex": [
["cva\\(([^)]*)\\)", "[\"'`]([^\"'`]*).*?[\"'`]"],
["cn\\(([^)]*)\\)", "[\"'`]([^\"'`]*).*?[\"'`]"]
]
}
```
### 2-3. 권장 익스텐션
VS Code에서 사용하던 익스텐션이 이전되지 않은 경우 수동 설치:
```
# 필수
Vue.volar # Vue - Official (Nuxt 4 TypeScript 지원)
esbenp.prettier-vscode # Prettier
dbaeumer.vscode-eslint # ESLint
bradlc.vscode-tailwindcss # Tailwind CSS IntelliSense
# 선택
antfu.iconify # Iconify 아이콘
antfu.unocss # UnoCSS (선택)
```
---
## 3. Nuxt 4 프로젝트 설정
### 3-1. .cursorrules 파일 적용
프로젝트 루트에 `.cursorrules` 파일을 생성하면 Cursor가 해당 규칙을 모든 AI 응답에 적용합니다.
> 템플릿: `docs/cursorrules-template.md` 참조
> 실제 파일: 프로젝트 루트 `.cursorrules`로 복사 후 사용
### 3-2. .cursor/rules/ 디렉토리 방식 (권장 - Cursor 0.45+)
최신 Cursor는 `.cursor/rules/` 디렉토리 내 여러 `.mdc` 파일로 규칙을 분리할 수 있습니다:
```
.cursor/
└── rules/
├── nuxt4-conventions.mdc # Nuxt 4 디렉토리 및 컨벤션
├── typescript-rules.mdc # TypeScript strict 규칙
├── vue-components.mdc # Vue 컴포넌트 작성 패턴
└── tailwind-patterns.mdc # Tailwind CSS v4 패턴
```
`.mdc` 파일 예시 (`nuxt4-conventions.mdc`):
```
---
description: Nuxt 4 프로젝트 구조 및 컨벤션
globs: **/*.vue, **/*.ts
---
# Nuxt 4 컨벤션
- 앱 코드는 반드시 `app/` 디렉토리 하위에 위치
- 컴포넌트: `app/components/`, 페이지: `app/pages/`
- `any` 타입 사용 금지, `unknown` 또는 명시적 타입 사용
```
### 3-3. 프로젝트 인덱싱 확인
1. Cursor 하단 상태바 → **"Indexing"** 완료 확인
2. 완료 후 `@codebase` 명령으로 전체 프로젝트 컨텍스트 참조 가능
---
## 4. 주요 기능 및 단축키
### 4-1. 핵심 기능
| 기능 | 단축키 | 설명 |
|------|--------|------|
| AI Chat | `⌘ + L` | 우측 사이드바 AI 채팅 |
| Composer | `⌘ + I` | 멀티파일 편집 (핵심 기능) |
| 인라인 편집 | `⌘ + K` | 선택 영역 인라인 수정 |
| 자동완성 수락 | `Tab` | AI 제안 수락 |
| 자동완성 거부 | `Esc` | AI 제안 무시 |
| 부분 수락 | `⌘ + →` | 단어 단위 부분 수락 |
### 4-2. Composer 활용 (멀티파일 편집)
`⌘ + I` 로 Composer 실행 후:
```
@codebase 를 참고해서 app/components/UserCard.vue 컴포넌트를 생성해줘.
- Props: userId(string), showAvatar(boolean, 기본값 true)
- TypeScript strict 모드 준수
- Tailwind CSS v4 스타일 적용
- 관련 테스트 파일도 함께 생성
```
### 4-3. 컨텍스트 참조 문법
| 문법 | 설명 |
|------|------|
| `@파일명` | 특정 파일 참조 (예: `@app/app.vue`) |
| `@codebase` | 프로젝트 전체 인덱스 참조 |
| `@docs` | 연동된 공식 문서 참조 |
| `@web` | 실시간 웹 검색 |
| `@git` | Git 커밋 히스토리 참조 |
---
## 5. Nuxt 4 개발 프롬프트 패턴
### 5-1. Vue 컴포넌트 생성
```
app/components/[ComponentName].vue 파일을 생성해줘.
요구사항:
- Props 인터페이스를 TypeScript로 명시적으로 정의 (any 금지)
- <script setup lang="ts"> 사용
- Tailwind CSS v4 반응형 클래스 적용 (sm/md/lg 브레이크포인트)
- shadcn-vue 컴포넌트 활용 가능
기능: [기능 설명]
```
### 5-2. Pinia 스토어 생성
```
stores/use[StoreName]Store.ts 파일을 Composition API 방식으로 생성해줘.
- defineStore("storeName", () => { ... }) 형식 사용
- 상태(ref/reactive), 게터(computed), 액션(function) 구조 준수
- TypeScript 타입 명시
- 필요한 경우 useFetch 또는 useAsyncData 활용
스토어 역할: [역할 설명]
```
### 5-3. Vitest 테스트 작성
```
@app/components/[ComponentName].vue 를 참고해서 Vitest 테스트를 작성해줘.
- @nuxt/test-utils의 mountSuspended 사용
- 주요 props 조합에 대한 렌더링 테스트
- 사용자 인터랙션 테스트 (클릭, 입력 등)
- 엣지 케이스 포함 (빈 값, 최대값 등)
```
### 5-4. 서버 API 엔드포인트 생성
```
server/api/[endpoint].ts Nitro API 라우트를 생성해줘.
- defineEventHandler 사용
- 요청 바디/쿼리 파라미터 TypeScript 타입 정의
- 에러 처리 (createError 활용)
- 응답 타입 명시
엔드포인트 역할: [역할 설명]
```
### 5-5. 코드 리뷰 요청
```
@app/components/[ComponentName].vue 코드를 리뷰해줘.
체크리스트:
- TypeScript any 타입 사용 여부
- 반응형 디자인 적용 여부 (Tailwind 브레이크포인트)
- Vue 3 Composition API 베스트 프랙티스 준수
- 불필요한 리렌더링 유발 요소
- 접근성(a11y) 이슈
```
---
## 6. 외부 문서 연동 (@docs)
Cursor Settings → **Features** → **Docs** 탭에서 추가:
| 문서명 | URL |
|--------|-----|
| Nuxt 4 공식 문서 | `https://nuxt.com/docs` |
| Vue 3 공식 문서 | `https://vuejs.org/guide` |
| Tailwind CSS v4 | `https://tailwindcss.com/docs` |
| shadcn-vue | `https://www.shadcn-vue.com` |
| Pinia | `https://pinia.vuejs.org` |
| Vitest | `https://vitest.dev` |
등록 후 `@Nuxt 4 공식 문서` 형태로 AI 채팅에서 참조 가능
---
## 7. 팀 설정 공유
### .cursor/ 디렉토리를 Git으로 관리
```bash
# .gitignore에서 제외 (팀 공유 대상)
# .cursor/rules/ 는 커밋 대상
# .gitignore 예시
.cursor/mcp.json # MCP 서버 설정 (로컬 전용)
```
### 팀 공유 설정 체크리스트
- [ ] `.cursorrules` 또는 `.cursor/rules/` 파일 커밋
- [ ] `docs/cursor-setup-guide.md` 팀 위키 등록
- [ ] 팀원 계정 초대 (팀 플랜 사용 시)
- [ ] 권장 익스텐션 목록 공유
---
## 8. 주의사항 및 팁
### 보안 주의사항
> `.cursorrules`에 API 키, 비밀번호, 개인정보를 **절대 포함하지 마세요**.
> AI 컨텍스트로 전송되어 외부 서버에 노출될 수 있습니다.
### 성능 팁
- 대형 프로젝트에서 인덱싱 속도가 느린 경우 `files.exclude`에 불필요한 디렉토리 추가
- `.nuxt`, `.output`, `node_modules`는 기본 제외 권장
### 비용 절약 팁
- 단순 자동완성: `claude-haiku-4-5` 사용 (빠르고 저렴)
- 복잡한 리팩토링: `claude-sonnet-4-6` 사용
- `@codebase` 남발 시 토큰 소비 증가 → 필요한 경우에만 사용
---
## 검토 이력
| 날짜 | 버전 | 변경 내용 | 작성자 |
|------|------|-----------|--------|
| 2026-03-19 | v1.0 | 최초 작성 | 시니어 Dev |

195
docs/cursorrules-template.md Normal file
View File

@@ -0,0 +1,195 @@
# .cursorrules 파일 템플릿 (Nuxt 4)
> 이 파일의 내용을 프로젝트 루트의 `.cursorrules` 파일로 복사하여 사용하세요.
> Cursor 0.45+ 사용 시 `.cursor/rules/` 디렉토리 방식을 권장합니다.
---
## 사용 방법
```bash
# 프로젝트 루트에 .cursorrules 파일 생성
cp docs/cursorrules-template.md .cursorrules
# 또는 아래 내용을 직접 .cursorrules에 붙여넣기
```
---
## .cursorrules 내용 (아래부터 복사)
```
# FE 팀 Nuxt 4 프로젝트 AI 코딩 규칙
# 마지막 업데이트: 2026-03-19
## 프로젝트 개요
- 프레임워크: Nuxt 4 (2025년 7월 안정 릴리즈)
- 언어: TypeScript (strict 모드, any 타입 사용 금지)
- CSS: Tailwind CSS v4
- UI 컴포넌트: shadcn-vue (shadcn/ui Vue 포트)
- 상태관리: Pinia (Composition API 방식)
- 테스트: Vitest + @nuxt/test-utils
- 패키지 매니저: pnpm
## 디렉토리 구조 (Nuxt 4)
앱 코드는 반드시 app/ 디렉토리 하위에 위치합니다:
- app/components/ → 재사용 컴포넌트 (PascalCase.vue)
- app/composables/ → 컴포저블 함수 (use로 시작)
- app/layouts/ → 레이아웃
- app/middleware/ → 라우트 미들웨어
- app/pages/ → 파일 기반 라우팅 (kebab-case)
- app/plugins/ → 플러그인
- app/stores/ → Pinia 스토어 (useXxxStore.ts)
- app/utils/ → 유틸리티 함수
- server/api/ → Nitro API 라우트
- shared/ → 클라이언트/서버 공유 코드
## 네이밍 컨벤션
- 변수/함수: camelCase
- 컴포넌트: PascalCase (파일명도 PascalCase.vue)
- 상수: UPPER_SNAKE_CASE
- 파일(페이지/기타): kebab-case
- Pinia 스토어: useXxxStore (예: useAuthStore, useCartStore)
- 컴포저블: useXxx (예: useUser, useCart)
## TypeScript 규칙
- any 타입 절대 금지 → unknown 또는 명시적 타입 사용
- 인터페이스는 Props, Emits 등 명시적으로 정의
- 제네릭 활용으로 타입 안전성 확보
- tsconfig.json의 strict: true 항상 유지
## Vue 컴포넌트 작성 규칙
- <script setup lang="ts"> 형식 사용 (Options API 금지)
- defineProps<Interface>() 형식으로 Props 타입 정의
- defineEmits<{ eventName: [payload: Type] }>() 형식 사용
- 컴포넌트 내 비즈니스 로직은 컴포저블로 분리
- 템플릿은 단순하게 유지, 복잡한 로직은 computed/methods로
## Tailwind CSS v4 규칙
- 인라인 스타일 대신 Tailwind 클래스 사용
- 반응형 디자인 필수: sm/md/lg/xl 브레이크포인트 활용
- 커스텀 색상은 tailwind.config.ts에 정의
- @apply 사용 최소화 (컴포넌트 레벨 스타일은 허용)
## shadcn-vue 컴포넌트 규칙
- Button, Input, Card 등 shadcn-vue 기본 컴포넌트 우선 사용
- 커스터마이징은 컴포넌트 래핑으로 처리
- app/components/ui/ 디렉토리에 위치
## Pinia 스토어 규칙
- Composition API 방식 필수: defineStore('id', () => { ... })
- 구조: 상태(ref/reactive) → 게터(computed) → 액션(function) 순서
- 스토어 간 직접 참조 최소화
## API 호출 규칙
- 서버사이드: useAsyncData 또는 useFetch 사용
- 클라이언트사이드: $fetch 사용
- 중복 요청 방지를 위한 key 파라미터 필수
## 코드 품질 규칙
- 함수는 단일 책임 원칙 준수
- 컴포넌트는 200줄 이하 유지 (초과 시 분리 검토)
- 주석은 한국어로 작성 (변수명/함수명은 영어)
- 커밋 메시지: "타입: 한국어 설명" 형식 (feat, fix, refactor 등)
## 테스트 규칙
- 컴포넌트 테스트: Vitest + mountSuspended (@nuxt/test-utils)
- 단위 테스트: 컴포저블, 유틸리티 함수 대상
- 테스트 파일: __tests__/ 또는 .spec.ts / .test.ts 확장자
## 금지 사항
- any 타입 사용
- Options API 사용 (Vue 3에서도 금지)
- 직접 DOM 조작 (ref 또는 Nuxt의 useNuxtApp 활용)
- console.log 프로덕션 코드 잔류
- 하드코딩된 URL (환경변수 사용)
- 민감 정보(API 키, 비밀번호)를 코드에 직접 작성
## AI 응답 시 우선순위
1. TypeScript 타입 안전성
2. Nuxt 4 app/ 디렉토리 구조 준수
3. 기존 코드 패턴과의 일관성
4. 성능 최적화
5. 가독성
```
---
## .cursor/rules/ 디렉토리 방식 (Cursor 0.45+)
더 세밀한 규칙 분리가 필요한 경우 아래 구조를 사용하세요:
### `.cursor/rules/nuxt4-conventions.mdc`
```markdown
---
description: Nuxt 4 디렉토리 구조 및 프로젝트 컨벤션
globs: app/**/*.vue, app/**/*.ts, server/**/*.ts
---
# Nuxt 4 프로젝트 컨벤션
## 디렉토리 구조
앱 코드는 반드시 app/ 디렉토리 하위에 위치합니다.
- app/components/ → PascalCase.vue
- app/pages/ → kebab-case.vue
- app/composables/ → useXxx.ts
- app/stores/ → useXxxStore.ts
## 네이밍
- 컴포넌트 파일: PascalCase.vue
- 페이지 파일: kebab-case.vue
- 컴포저블: useXxx (camelCase)
- 스토어: useXxxStore
```
### `.cursor/rules/typescript-strict.mdc`
```markdown
---
description: TypeScript strict 모드 규칙
globs: **/*.ts, **/*.vue
---
# TypeScript 규칙
- any 타입 절대 금지 → unknown 또는 명시적 타입 사용
- <script setup lang="ts"> 필수
- defineProps<Interface>() 형식 사용
- 모든 함수 파라미터와 반환값에 타입 명시
```
### `.cursor/rules/vue-components.mdc`
```markdown
---
description: Vue 3 컴포넌트 작성 패턴
globs: app/components/**/*.vue, app/pages/**/*.vue
---
# Vue 컴포넌트 패턴
- Composition API + script setup 필수 (Options API 금지)
- 비즈니스 로직은 app/composables/로 분리
- shadcn-vue 컴포넌트 우선 사용
- 컴포넌트 200줄 이하 유지
```
### `.cursor/rules/tailwind-patterns.mdc`
```markdown
---
description: Tailwind CSS v4 사용 패턴
globs: **/*.vue, **/*.html
---
# Tailwind CSS v4 패턴
- 인라인 스타일 금지, Tailwind 클래스 사용
- 반응형 필수: sm/md/lg/xl 브레이크포인트
- @apply 사용 최소화
- cn() 유틸리티로 조건부 클래스 처리
```
---
## 검토 이력
| 날짜 | 버전 | 변경 내용 | 작성자 |
|------|------|-----------|--------|
| 2026-03-19 | v1.0 | 최초 작성 | 시니어 Dev |

261
docs/work-log-template.md Normal file
View File

@@ -0,0 +1,261 @@
# 업무일지 표준화 템플릿
> 작성일: 2026-03-19
> 버전: v1.0
> 담당: 테크 리드
> 적용 대상: FE 팀 전원
---
## 개요
FE 팀원 개인이 매일 작성하는 업무일지의 표준 템플릿을 정의합니다.
일관된 형식으로 작성하면 AI 자동 요약 연동 및 주간 회고 자동화가 가능합니다.
---
## 일일 업무일지 템플릿
> 파일명 규칙: `YYYY-MM-DD_이름.md` (예: `2026-03-19_홍길동.md`)
> 작성 시점: 업무 종료 전 (17:30~18:00 권장)
```markdown
# 업무일지 - YYYY-MM-DD (요일)
**작성자**: 이름
**팀**: FE팀
**작성 시각**: HH:MM
---
## ✅ 오늘 완료한 일
<!-- 태스크 ID와 함께 작성하면 자동 연동 가능 -->
- [ ] [T0-X] 태스크 제목: 간략한 작업 내용
- [ ] [T0-X] 태스크 제목: 간략한 작업 내용
- [ ] (태스크 외) 코드 리뷰, 회의, 기타 업무
**완료 요약**: 오늘 주요 성과를 1~2문장으로 요약
---
## 📋 내일 예정 작업
- [ ] [T0-X] 태스크 제목: 예상 작업 내용
- [ ] [T0-X] 태스크 제목: 예상 작업 내용
**예상 완료 비율**: X% (태스크 단위 예상)
---
## 🚧 블로커 / 의존성
<!-- 진행을 막는 이슈나 다른 팀원의 작업 완료를 기다리는 항목 -->
| 블로커 내용 | 영향 태스크 | 해결 담당 | 예상 해결일 |
|-------------|-------------|-----------|-------------|
| 예: Copilot 라이선스 미할당 | T0-3 | 시니어 Dev | 2026-03-20 |
블로커 없음 시: `없음`
---
## 📝 메모 / 학습 기록
<!-- 오늘 배운 것, 참고할 링크, 팀 공유 사항 등 -->
- 참고 링크:
- 학습 내용:
- 팀 공유 사항:
---
## 🔢 시간 배분 (선택)
| 업무 분류 | 소요 시간 |
|-----------|-----------|
| 개발 | Xh |
| 코드 리뷰 | Xh |
| 회의 | Xh |
| 문서 작업 | Xh |
| 기타 | Xh |
| **합계** | **8h** |
```
---
## 주간 요약 템플릿
> 파일명 규칙: `YYYY-WXX_이름_주간요약.md` (예: `2026-W12_홍길동_주간요약.md`)
> 작성 시점: 금요일 업무 종료 전
```markdown
# 주간 업무 요약 - YYYY년 XX주차 (MM/DD ~ MM/DD)
**작성자**: 이름
**작성일**: YYYY-MM-DD
---
## 이번 주 완료 태스크
| 태스크 ID | 태스크명 | 완료일 | 비고 |
|-----------|---------|--------|------|
| T0-X | 태스크명 | MM/DD | - |
---
## 이번 주 주요 성과
1.
2.
3.
---
## 다음 주 계획
| 우선순위 | 태스크 ID | 태스크명 | 예상 소요 |
|----------|-----------|---------|-----------|
| 높음 | T0-X | 태스크명 | X일 |
| 중간 | T0-X | 태스크명 | X일 |
---
## 블로커 / 리스크
-
---
## 기술 메모 / 학습
-
```
---
## AI 자동 요약 연동 방안
### 1. 일일 요약 자동화 (Claude API 활용)
업무일지 원문을 Claude API에 전달하여 핵심 요약을 자동 생성합니다.
#### 프롬프트 템플릿
```
당신은 FE 팀의 업무일지를 요약하는 AI 어시스턴트입니다.
아래 업무일지를 다음 형식으로 요약해주세요:
[요약 형식]
- 오늘의 핵심 성과: (1~2문장)
- 주요 완료 태스크: (태스크 ID와 함께 3개 이내)
- 내일 예정: (1~2문장)
- 블로커 여부: (있음/없음, 있을 경우 간략 설명)
[업무일지 내용]
{work_log_content}
```
#### 연동 방식 (검토 결과)
| 방식 | 장점 | 단점 | 권장 여부 |
|------|------|------|-----------|
| Claude API 직접 연동 (서버 스크립트) | 자동화 완전, 커스터마이징 자유 | 구현 비용, API 키 관리 필요 | **권장** (Sprint 1 이후 구현) |
| GitHub Actions + Claude API | PR/커밋 이벤트 트리거 가능 | GitHub 의존성 | 권장 (CI 파이프라인과 통합) |
| Notion AI 내장 기능 | 별도 구현 불필요 | Notion 플랜 필요, 커스터마이징 제한 | Notion 선택 시 단기 대안 |
| ChatGPT/Claude 수동 붙여넣기 | 즉시 사용 가능 | 자동화 불가, 수작업 | Sprint 0 임시 방안 |
### 2. 주간 요약 자동화 방안
```
매주 금요일 18:00에 GitHub Actions가 실행:
1. 해당 주의 일일 업무일지 파일 5개 수집
2. 파일 내용을 Claude API에 일괄 전달
3. 주간 팀 요약 자동 생성
4. Slack #daily-log 채널에 자동 게시
```
#### 주간 요약 자동화 프롬프트
```
당신은 FE 팀의 주간 업무를 요약하는 AI 어시스턴트입니다.
아래는 이번 주 팀원들의 업무일지 모음입니다.
팀 관리자를 위한 주간 요약을 작성해주세요:
[요약 형식]
1. 이번 주 팀 주요 성과 (3~5개)
2. 완료된 주요 태스크 목록
3. 현재 진행 중인 블로커
4. 다음 주 팀 계획 요약
5. 팀원별 기여 요약 (간략)
[업무일지 목록]
{work_logs_combined}
```
### 3. 단계별 도입 계획
| 단계 | 시점 | 방식 | 상태 |
|------|------|------|------|
| Phase 1 | Sprint 0 (현재) | 수동 작성 + 수동 AI 요약 | ✅ 즉시 적용 |
| Phase 2 | Sprint 1 | GitHub Actions + Claude API 자동 요약 스크립트 | 📋 계획됨 |
| Phase 3 | Sprint 2 이후 | Slack 연동 자동 게시, 주간 리포트 대시보드 | 📋 계획됨 |
---
## 작성 규칙 및 가이드라인
### 필수 작성 항목
- ✅ 오늘 완료한 일 (최소 1개)
- ✅ 내일 예정 작업 (최소 1개)
- ✅ 블로커 여부 (없음이라도 명시)
### 선택 작성 항목
- 📝 메모 / 학습 기록
- 🔢 시간 배분
### 작성 팁
1. **태스크 ID 명시**: `[T0-X]` 형식으로 로드맵 태스크와 연결
2. **구체적 작성**: "개발함" 대신 "Copilot 설정 가이드 VSCode 섹션 완료"
3. **블로커 조기 공유**: 하루 이상 막히면 즉시 팀에 공유
4. **시간 기록 권장**: 주간 회고 시 실제 소요 시간 파악에 활용
---
## Confluence/Notion 등록 가이드
### Notion 사용 시
1. 팀 워크스페이스 > FE팀 > 업무일지 페이지 생성
2. 위 템플릿을 Notion 템플릿으로 저장
3. 매일 새 페이지 생성 시 템플릿 적용
### Confluence 사용 시
1. FE팀 Space > 업무일지 > YYYY-MM 폴더 구조
2. 페이지 템플릿으로 등록 (Space 관리자 권한 필요)
3. 매일 새 페이지 생성 시 템플릿 적용
### Git 기반 (권장 - 자동화 용이)
```
docs/
└── work-logs/
├── 2026-03/
│ ├── 2026-03-23_홍길동.md
│ ├── 2026-03-24_홍길동.md
│ └── weekly/
│ └── 2026-W12_홍길동_주간요약.md
└── templates/
├── daily-template.md
└── weekly-template.md
```
> Git 저장소에 업무일지를 저장하면 GitHub Actions를 통한 자동 요약 연동이 가장 용이합니다.
---
## 검토 이력
| 날짜 | 버전 | 변경 내용 | 작성자 |
|------|------|-----------|--------|
| 2026-03-19 | v1.0 | 최초 작성 | 테크 리드 |

114
shrimp-rules.md Normal file
View File

@@ -0,0 +1,114 @@
# Development Guidelines
## 프로젝트 개요
- **목적**: Smilegate FE팀의 AI 활용 표준화 로드맵 관리 및 커스텀 에이전트 운영 도구
- **핵심 산출물**: `docs/ROADMAP.md` — FE AI 표준화 13주 실행 로드맵 (Sprint 0-6)
- **기술 스택**: Nuxt 4, TypeScript strict, Tailwind CSS v4, shadcn-vue, Pinia, Vitest
- **이 디렉토리는 Nuxt 앱이 아님** — 앱 코드(Vue 컴포넌트, 페이지 등)를 이 디렉토리에 생성하지 않는다
---
## 프로젝트 구조
```
fe-agent/
├─ .claude/
│ ├─ agents/ # 커스텀 에이전트 정의 파일 (YAML frontmatter + 프롬프트)
│ │ └─ frontend-roadmap-architect.md # 로드맵 설계 전문 에이전트
│ ├─ agent-memory/ # 에이전트별 영구 메모리
│ │ └─ frontend-roadmap-architect/
│ │ └─ MEMORY.md # 에이전트 영구 메모리 (200줄 이내 유지)
│ └─ settings.local.json
├─ docs/
│ └─ ROADMAP.md # FE AI 표준화 실행 로드맵 (핵심 문서)
├─ shrimp_data/ # shrimp-task-manager 내부 데이터 (직접 편집 금지)
├─ .mcp.json # MCP 서버 설정
└─ shrimp-rules.md # 이 파일 (AI Agent 운영 규칙)
```
---
## 파일 상호작용 규칙
### ROADMAP.md 수정 시
- `docs/ROADMAP.md`의 로드맵 구조(스프린트, 마일스톤, 팀 구성, KPI)가 변경되면 `.claude/agent-memory/frontend-roadmap-architect/MEMORY.md`의 해당 섹션을 동기화한다
- 새 스프린트 추가 → MEMORY.md의 "로드맵 설계 패턴" 섹션 업데이트
- 기술 스택 변경 → MEMORY.md의 "프로젝트 컨텍스트" 섹션 업데이트
### 에이전트 추가 시
- `.claude/agents/[에이전트명].md` 파일 생성
- `.claude/agent-memory/[에이전트명]/MEMORY.md` 파일 동시 생성 (초기에는 빈 메모리 파일)
- 에이전트 파일은 반드시 YAML frontmatter(`name`, `description`, `model`, `color`) 포함
### 에이전트 정의 수정 시
- `.claude/agents/[에이전트명].md` 역할/능력 변경 시 MEMORY.md의 관련 컨텍스트 항목을 함께 검토
- `description` 필드 변경은 에이전트 트리거 조건에 직접 영향 — 주의하여 수정
---
## 언어 및 커뮤니케이션 규칙
- **모든 문서**: 한국어로 작성
- **코드 주석**: 한국어
- **커밋 메시지**: 한국어 (`feat: 로드맵 Sprint 3 태스크 추가`)
- **변수/함수명**: 영어 (코드 표준 준수)
- **에이전트 프롬프트**: 한국어 (YAML frontmatter의 `description`은 영어 허용)
---
## 로드맵 문서 작성 규칙
- 태스크는 **1-3일** 단위로 분해 (3일 초과 시 재분해)
- 스프린트 구성: 목표 → 태스크 목록 → 완료 기준(DoD) → 리스크 및 의존성 순서 준수
- 우선순위는 MoSCoW 분류(`Must` / `Should` / `Could`) 명시
- 새 태스크 ID 생성 규칙: `T[스프린트번호]-[순번]` (예: `T3-5`)
- 부록 "원본 문서 항목 → 태스크 매핑표"에 새 태스크 반영 시 매핑표도 갱신
---
## 에이전트 정의 파일 작성 규칙
### YAML Frontmatter 필수 필드
```yaml
---
name: 에이전트명 (영어 kebab-case)
description: "트리거 조건 포함 상세 설명 (영어 또는 한국어)"
model: opus | sonnet | haiku
color: red | blue | green | yellow | purple | orange
---
```
### 프롬프트 작성 원칙
- 에이전트의 **역할**, **전문성**, **산출물 형식**, **자기 검증 체크리스트**를 포함
- 에스컬레이션 조건(모호한 요구사항 처리 방법)을 명시
- `memory: project` 설정 시 `.claude/agent-memory/[에이전트명]/` 디렉토리 생성 필수
---
## AI 의사결정 기준
### 문서 수정 요청이 모호할 때
1. `docs/ROADMAP.md` 현재 내용 확인
2. 변경 범위가 단일 태스크인지 스프린트 전체인지 파악
3. 의존성 있는 다른 태스크에 영향 여부 판단 후 수정
### 새 에이전트 추가 vs 기존 에이전트 수정
- 역할이 완전히 다른 경우 → 새 에이전트 파일 생성
- 기존 에이전트의 전문성 범위 확장인 경우 → 기존 파일 수정
### MEMORY.md 업데이트 시점
- 로드맵 구조 변경 → 즉시 동기화
- 일회성 작업 결과 → 저장하지 않음
- 팀 컨벤션/의사결정 확정 → 저장
---
## 금지사항
- **`shrimp_data/` 직접 편집 금지** — shrimp-task-manager가 내부적으로 관리하는 디렉토리
- **앱 코드 생성 금지** — Vue 컴포넌트, Nuxt 페이지 등은 이 디렉토리가 아닌 실제 Nuxt 프로젝트에서 작업
- **MEMORY.md 200줄 초과 금지** — 초과 시 세부 내용은 별도 토픽 파일로 분리 후 링크
- **명시적 요청 없이 커밋/푸시 금지**
- **에이전트 파일에서 `any` 타입 사용 금지** (TypeScript 코드 포함 시)
- **로드맵 태스크 ID 중복 사용 금지** — 삭제된 태스크 ID 재사용 불가

1
shrimp_data Submodule

Submodule shrimp_data added at 45845e0bb5