| 기획 |
Phase 1 |
- 기획서를 개발자가 수동으로 읽고 페이지 구조·컴포넌트를 직접 설계 - 기획 의도 해석 오류로 인한 재작업 발생 - 플로우차트 작성에 별도 시간 소요 - 개발자마다 요구사항 해석 기준 상이 |
- requirement-analyzer Skill이 기획서를 자동 파싱 - Nuxt pages/ 라우팅 구조, 컴포넌트 트리, API 엔드포인트 목록 자동 생성 - Mermaid 플로우차트로 화면 전환 흐름 자동 시각화 - 팀 전체가 동일한 요구사항 명세 기반으로 개발 착수 |
requirement-analyzer |
|
| 다국어 |
Phase 1-1 |
- 번역 요청 후 결과를 다국어 번역코드 키값을 엑셀파일에서 수동 입력 - 누락된 번역 키나 중복 키값 발생 시 런타임에서야 발견 |
- AI가 번역 코드 전체에서 번역 대상 문자열에서 자동 추출 생성 - 번역 키 누락 및 중복을 사전 감지 및 경고 |
translation-keys |
|
| 마크업 (기본) |
Phase 2 |
- 개발자 역량에 따라 시멘틱 태그 사용 수준 불일치 - Tailwind 클래스 순서 및 패턴 제각각 - 접근성(ARIA) 검토를 별도 단계로 진행 - 반응형 브레이크포인트 구현 기준 없음 |
- markup Skill이 시멘틱 HTML 구조 자동 생성 - Tailwind 클래스 7단계 순서 컨벤션 자동 적용 - ARIA 레이블 및 접근성 속성 자동 삽입 - 팀 전체 마크업 품질 균일화 |
markup |
|
| PSD → Figma |
Phase 2-0 |
- PSD 파일을 디자이너가 Figma에 수동 재작업 - 레이어 구조 재설계로 많은 시간 소요 - 변환 과정에서 디자인 요소 누락·변형 발생 |
- Codia AI / PSD Importer for Figma 활용으로 자동 컨버팅 - PSD 레이어 구조를 유지하며 Figma 포맷으로 변환 - 디자이너 수작업 시간 대폭 단축 |
Codia AI / PSD Importer for Figma |
|
| Figma → HTML |
Phase 2-1 |
- 피그마 시안을 보며 개발자가 수동으로 HTML 작성 - 반응형 브레이크포인트를 수동으로 추출·적용 - 피그마 컴포넌트와 HTML 구조 간 매핑 기준 없음 |
- markup (Figma) Skill + Figma MCP로 레이어 자동 파싱 - 피그마 컴포넌트를 Nuxt SFC 구조로 자동 매핑 - 반응형 브레이크포인트 자동 추출 및 Tailwind 클래스 적용 |
markup + Figma MCP |
|
| 프로모션 마크업 |
Phase 2-2 |
- 프로모션/랜딩페이지마다 마크업 패턴 상이 - 반응형 대응 일관성 없음 - 프로모션별 재작업 반복으로 생산성 저하 |
- markup-promotion Skill로 캠페인 표준 마크업 패턴 자동 생성 - 시멘틱 구조, 반응형 일관 적용 - 프로모션 유형별 템플릿 재사용으로 개발 속도 향상 |
markup-promotion |
|
| EDM 마크업 |
Phase 2-3 |
- 이메일 클라이언트별(Outlook 등) 호환성 수동 대응 - 테이블 기반 레이아웃 반복 작성으로 시간 소요 - 인라인 스타일 누락으로 렌더링 오류 발생 |
- markup-edm Skill로 이메일 클라이언트 호환 table 기반 마크업 자동 생성 - 인라인 스타일 자동 적용으로 렌더링 오류 사전 방지 - 뉴스레터·EDM 표준 구조 일관 유지 |
markup-edm |
|
| FE 개발 (컴포넌트) |
Phase 3 |
- 개발자마다 컴포넌트 분리 기준 상이 - Nuxt 디렉토리 구조(pages/, components/, composables/) 불일치 - 컴포넌트 재사용률 낮음 (30% 수준) - 신규 인력 온보딩 기간 필요 |
- dev-component Skill이 Atomic Design 기반 컴포넌트 트리 자동 설계 - 표준 디렉토리 구조 자동 제안으로 일관성 확보 - 컴포넌트 재사용률 70%↑ 목표 - 온보딩 기간 단축 |
dev-component |
|
| Nuxt 공식 문서 기반 개발 |
Phase 3-1 |
- Nuxt 공식문서를 직접 검색하며 Best Practice 파악 - server/, middleware/, plugins/ 활용 기준 불명확 - composable 작성 시 공식 패턴 확인에 시간 소요 |
- dev-docs Skill이 6개 참조 문서(server, middleware, plugins, composables, components, config)를 컨텍스트에 따라 선택 로드 - 즉시 Nuxt 3 Best Practice 코드 생성 - 공식문서 탐색 없이 정확한 API 활용 |
dev-docs |
|
| 단위 테스트 |
Phase 3-2 |
- 컴포넌트 개발 완료 후 테스트 작성 생략 또는 뒤늦게 작성 - Vue Test Utils / Vitest 설정을 매번 조사 - 테스트 케이스 구성 기준 없어 커버리지 20% 미만 - 테스트 코드 패턴이 개발자마다 상이 |
- dev-unit-test Skill이 컴포넌트 분석 후 Vitest + Vue Test Utils 기반 단위 테스트 자동 생성 - Props / Emits / 슬롯 / 인터랙션 케이스 자동 커버 - 테스트 패턴 팀 표준화로 코드 리뷰 부담 감소 - 커버리지 80%↑ 목표 |
dev-unit-test |
|
| 컴포넌트 문서화 |
Phase 3-3 |
- 컴포넌트 사용법 문서화 없어 팀원이 소스 코드 직접 확인 - Storybook 미운영으로 컴포넌트 목록 파악 어려움 - Props / Emits 스펙 구두 전달 의존 - 신규 인력이 재사용 가능한 컴포넌트를 중복 개발 |
- dev-storybook Skill로 컴포넌트 Props / Emits / 슬롯 기반 사용 가이드 자동 생성 - Storybook Story 파일 자동 생성 - 팀 내 컴포넌트 재사용 진입 장벽 감소 - 컴포넌트 카탈로그 자동 갱신 |
dev-storybook |
|
| API 연동 & 상태관리 |
Phase 4 |
- useFetch / $fetch / useAsyncData 혼용으로 일관성 없음 - Pinia 스토어 설계 기준 없어 구조 제각각 - 에러 핸들링 패턴 통일 없음 - BFF 패턴 미활용으로 API 키 노출 위험 |
- dev-api-state Skill로 상황별 데이터 페칭 패턴 자동 선택·생성 - Setup Store 기반 Pinia 스토어 표준 코드 자동 생성 - 에러 핸들링·로딩 상태 처리 패턴 통일 - server/api/ BFF 패턴으로 API 키 보호 |
dev-api-state |
|
| 코드 리뷰 |
Phase 4-1 |
- PR 리뷰어가 팀 컨벤션을 기억하며 수동 확인 - 리뷰어 역량 차이로 컨벤션 누락 발생 - 반복적인 스타일 지적으로 리뷰 사이클 증가 - 리뷰어 부재 시 병목 발생 - 비즈니스 로직보다 코드 스타일 지적에 리뷰 시간 소비 |
- verify-component-review Skill이 PR 머지 전 팀 공통 지침 기준으로 자동 사전 검토 - Composition API / 타입 / Tailwind 컨벤션 위반 자동 감지 - 반복적 스타일 지적 제거로 리뷰어가 비즈니스 로직 집중 - 코드 리뷰 반려율 50%↓ 목표 |
verify-component-review |
|
| 접근성 검증 |
Phase 5-0 |
- 접근성 검토 별도 단계 없음 - ARIA 속성 누락 QA 단계에서야 사후 발견 - 키보드 네비게이션 테스트 수동 진행 - WCAG 기준 인지 부족으로 누락 항목 반복 발생 - 스크린 리더 대응 미검증 |
- verify-a11y Skill로 WCAG 2.1 AA 기준 자동 검증 - ARIA 레이블 누락 / 키보드 포커스 순서 / 색상 대비 비율 자동 감지 - 개선 가이드 코드 레벨 자동 제시 - 접근성 관련 QA 반려 건수 80%↓ 목표 |
verify-a11y |
|
| 요구사항 검증 |
Phase 5-1 |
- 개발 완료 후 QA 단계에서 수동 검증 - 기획 대비 누락 기능을 늦게 발견하여 재작업 발생 - 기획자·개발자 간 스펙 해석 차이 사후 발견 |
- requirement-optimizer Skill이 Phase 1 요구사항 명세와 실제 구현 결과를 자동 비교 - 기능 누락, 스펙 불일치, 미구현 항목 사전 감지 - 개선 방안 자동 제시로 QA 전 품질 확보 |
requirement-optimizer |
|
| 성능 최적화 |
Phase 5-2 |
- Lighthouse 수동 실행 후 결과 해석에 시간 소요 - Core Web Vitals 개선 방법 별도 조사 필요 - Lighthouse 선택적 확인 - 번들 최적화·이미지 최적화 개발자 개인 역량 의존 |
- perf-optimizer Skill로 성능 병목 자동 분석 - 코드 스플리팅, 이미지 최적화, SSR/ISR 전략 자동 제안 - LCP < 2.5s / CLS < 0.1 / INP < 200ms 달성 가이드 - Lighthouse 점수 80+ 목표 |
perf-optimizer |
|
| SEO · GEO · AEO 검증 |
Phase 6 |
- SEO 메타태그 누락률 40% 수준 - Schema.org 구조화 데이터 미적용 - AI 검색(ChatGPT, Perplexity, Google AI Overview) 대응 전무 - 검색 가시성 개선 활동 미체계화 |
- nuxt-seo-geo Skill로 SEO · AEO · GEO 3계층 자동 감사 - useSeoMeta() / useSchemaOrg() 기반 메타·구조화 데이터 자동 생성 - FAQ·HowTo Schema 적용으로 AI 검색 직접 답변 노출 - SEO 메타 누락률 5%↓ · AI 검색 인용률 측정 체계 구축 |
nuxt-seo-geo |
|
| 보안 검토 |
Phase 6-1 |
- 보안 취약점 점검 별도 프로세스 없음 - XSS / CSRF 등 프론트엔드 보안 항목 개인 역량 의존 - npm audit 결과 미모니터링 - 민감 정보 하드코딩 발생 위험 - 서드파티 라이브러리 취약점 미파악 |
- security-review Skill로 XSS / CSRF / 의존성 취약점 자동 감지 - 민감 정보 하드코딩 코드베이스 전체 스캔 - npm audit 결과 해석 및 패치 우선순위 가이드 자동 생성 - 배포 전 보안 체크리스트 자동 검증 |
security-review |
|
