스펙 요구사항 정리

사용자의 자연어 요청을 분석하여 구조화된 기술 스펙으로 변환하고, 누락된 정보를 사전에 확인하여 구현 품질을 높인다.

실행 워크플로우

Step 1: 요청 분석

사용자의 요청에서 다음을 판별한다:

• 변경 유형: 신규 기능 / 기능 수정 / 버그 수정 / 리팩토링
• 대상 도메인: 01-architecture-check의 프로젝트 개요에 정의된 도메인 중 어디인지
• 예상 영향 레이어: 01-architecture-check의 레이어 표 중 어디에 해당하는지

Step 2: 누락 정보 확인

변경 유형에 따라 아래 질문을 사용자에게 확인한다. 이미 요청에 포함된 항목은 건너뛴다.

공통 질문:

• 구체적으로 어떤 동작이 변경/추가되어야 하는가?
• 예외 상황이나 엣지 케이스가 있는가?

새 API 엔드포인트 추가 시:

• API 유형: 01-architecture-check의 인증/인가 표 중 어디에 속하는가?
• API 버전은?
• 프로젝트에 분기 축(테넌트·프로바이더·타입 등)이 있다면 그 분기가 필요한가?
• 요청/응답 형식은?

DB 변경 시:

• 스키마 변경(ALTER TABLE, 새 테이블)이 필요한가?
• 마이그레이션이 필요한가?
• 인덱스 추가가 필요한가?

캐시 관련 시:

• 캐시 대상 데이터는 무엇인가?
• 캐시 키 패턴과 TTL은?
• 무효화 시점은?

외부 연동 시:

• 어떤 외부 API·서비스에 의존하는가?
• 연동 계정/토큰 관리가 필요한가? 실패 시 폴백은?

Step 3: 스펙 문서 출력

수집한 정보를 아래 형식으로 정리하여 사용자에게 제시한다.

## 요구사항 스펙

### 개요
(한 줄 요약)

### 변경 유형
(신규 기능 / 기능 수정 / 버그 수정 / 리팩토링)

### 영향 레이어
(Controller / Service / Lib / Model / Entity 중 해당 항목)

### 기능 상세
1. (구체적인 요구사항)
2. ...

### API 엔드포인트 (해당 시)
- 메서드: GET / POST / PUT / PATCH / DELETE
- 경로: (프로젝트 URL 규칙에 맞춰)
- 인증 방식: (인증/인가 표의 유형)
- 요청 형식: (파라미터, 바디)
- 응답 형식: (필드 구조)

### 데이터 변경 (해당 시)
- 테이블명, 컬럼, 인덱스 변경 사항

### 캐시 영향 (해당 시)
- 캐시 키 패턴, TTL, 무효화 전략

### 제약 조건 및 엣지 케이스
- (식별된 제약 사항)

### 사용자 확인 필요 사항
- (아직 불명확한 항목)

주의사항

• 단순한 버그 수정이나 한 줄 수정은 스펙 문서 없이 바로 4단계(플랜)로 진행 가능
• 사용자가 이미 명확한 스펙을 제시한 경우 확인 질문을 최소화
• 스펙 확정 후 사용자 동의를 받은 뒤 4단계(플랜)로 진행