dev-spec

기능 개발의 세 번째 단계로, 구현 단위의 상세 스펙을 작성한다. AI가 상세 스펙 초안과 인수 조건(Acceptance Criteria)을 작성하고, 사용자가 도메인 규칙과 엣지 케이스를 검증한다.

Workflow

1. 선행 문서 및 코드베이스 분석

다음을 순서대로 확인한다:

1. docs/dev-process/PRD.md — 요구사항과 사용자 시나리오 파악
2. docs/dev-process/ARCHITECTURE.md — 기술 스택, 컴포넌트 구조, 데이터 모델 파악
3. 프로젝트 코드 탐색 — 기존 패턴(API 구조, 네이밍 규칙, 파일 구성) 파악

선행 문서가 없으면 사용자에게 기능 개요, 기술 스택, 주요 컴포넌트를 직접 물어본다.

2. 구현 단위 분해

선행 문서를 바탕으로 기능을 구현 단위(Implementation Unit)로 분해한다:

• 각 단위는 하나의 PR 또는 하나의 작업 티켓 수준
• 단위 간 의존 관계와 구현 순서를 정리

분해 결과를 사용자에게 보여주고 확인받는다.

3. 정보 수집 — 1차 질문 (도메인 규칙)

• 핵심 비즈니스 규칙(반드시 지켜야 할 도메인 로직)은?
• 데이터 유효성 검증 규칙은? (필수값, 형식, 범위 등)
• 권한/인가 규칙은?

4. 정보 수집 — 2차 질문 (엣지 케이스)

1차 답변을 바탕으로:

• {구체적 시나리오}에서 동시 요청이 발생하면 어떻게 처리하는가?
• 데이터가 없는 경우/빈 상태의 동작은?
• 실패 시 롤백 또는 재시도 전략은?

(질문은 기능 특성에 따라 AI가 적절히 조정한다)

5. 스펙 문서 작성

수집된 정보를 바탕으로 references/spec-template.md 형식에 맞춰 구현 단위별 상세 스펙을 작성한다.

작성 원칙:

• 각 구현 단위마다 **인수 조건(AC)**을 Given-When-Then 형식으로 명시한다
• API가 있으면 Request/Response를 구체적 예시와 함께 기술한다
• 비즈니스 규칙은 코드로 바로 옮길 수 있는 수준으로 상세히 적는다
• 에러 케이스는 에러 코드, 메시지, 발생 조건을 명시한다
• 기존 코드 패턴(네이밍, 구조)을 따르도록 한다

6. 리뷰 및 확정

초안을 사용자에게 보여주고:

• 도메인 규칙의 정확성 검증
• 누락된 엣지 케이스 확인
• 인수 조건의 완전성 확인

피드백을 반영하여 확정한다.

7. Output

docs/dev-process/SPEC.md에 저장한다. 파일 저장 후 한 줄 요약과 함께 다음 단계(/dev-testcase)를 안내한다.