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

📝 docs: 스펙 검토 표준화 프로세스 문서 추가

Browse Source 
- 기능 요건 정의 템플릿 (Confluence 복사용)
- AI 프롬프트 템플릿 8종 (플로우차트, 스펙검토, 공수산정 등)
- 스펙 검토 체크리스트 48개 항목 + 판정 기준
- 플로우차트 검증 기준 (구조/가독성/Mermaid 문법)
- 전체 스펙 검토 워크플로우 (STEP 1-6, RACI, 소요시간)
This commit is contained in:
hyeonggil
2026-03-24 22:53:39 +09:00
parent 1440f335b7
commit c7b75013c4
5 changed files with 793 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

171
docs/spec-review/01-feature-requirements-template.md Normal file
View File

@@ -0,0 +1,171 @@
# 기능 요건 정의 템플릿
> Confluence에서 신규 기능 스펙 작성 시 본 템플릿을 복사하여 사용합니다.
---
## 기본 정보
| 항목 | 내용 |
|------|------|
| 기능명 | |
| 작성자 | |
| 작성일 | |
| 최종 수정일 | |
| 버전 | v1.0 |
| 상태 | 초안 / 검토중 / 확정 / 개발중 / 완료 |
---
## 1. 개요
### 1.1 배경 및 목적
_이 기능이 왜 필요한지, 어떤 문제를 해결하는지 서술합니다._
### 1.2 범위
- **포함**: 이번 스펙에 포함되는 내용
- **미포함**: 이번 스펙에서 제외되는 내용 (향후 검토)
---
## 2. 사용자 스토리
```
As a [사용자 유형]
I want to [원하는 기능/행동]
So that [달성하고자 하는 목표]
```
### 예시
```
As a 로그인된 사용자
I want to 프로필 사진을 변경하고 싶다
So that 나를 표현하는 아이덴티티를 업데이트할 수 있다
```
---
## 3. 기능 요건 (Functional Requirements)
### 3.1 핵심 기능
| ID | 요건 | 우선순위 | 비고 |
|----|------|---------|------|
| FR-001 | | Must | |
| FR-002 | | Should | |
| FR-003 | | Could | |
> 우선순위: **Must** (필수) / **Should** (권장) / **Could** (선택)
### 3.2 상세 기능 명세
#### FR-001: [기능명]
- **설명**: 기능에 대한 상세 설명
- **트리거**: 어떤 조건/이벤트로 시작되는가
- **입력**: 필요한 입력 데이터
- **처리**: 내부 처리 로직
- **출력**: 결과/응답
- **예외 처리**: 오류 케이스 및 처리 방법
---
## 4. 비기능 요건 (Non-Functional Requirements)
| 분류 | 요건 | 기준 |
|------|------|------|
| 성능 | 응답 시간 | 3초 이내 |
| 보안 | 인증 | JWT 토큰 기반 |
| 가용성 | 업타임 | 99.9% |
| 접근성 | WCAG | 2.1 AA 수준 |
---
## 5. UI/UX 요건
### 5.1 화면 목록
| 화면명 | 경로(URL) | 설명 |
|--------|----------|------|
| | | |
### 5.2 Figma 링크
- 디자인 시안: [링크]
- 프로토타입: [링크]
### 5.3 반응형 대응
- [ ] 모바일 (~ 767px)
- [ ] 태블릿 (768px ~ 1023px)
- [ ] PC (1024px ~)
---
## 6. API 요건
| Method | Endpoint | 설명 | 인증 필요 |
|--------|----------|------|----------|
| GET | /api/v1/ | | Y/N |
| POST | /api/v1/ | | Y/N |
---
## 7. 데이터 요건
### 7.1 입력 데이터
```typescript
interface InputData {
// 타입 정의
}
```
### 7.2 응답 데이터
```typescript
interface ResponseData {
// 타입 정의
}
```
---
## 8. 플로우차트
> AI 프롬프트 템플릿(`02-ai-prompt-templates.md`)을 사용하여 자동 생성 후 첨부합니다.
```mermaid
flowchart TD
A[시작] --> B{조건}
B -->|Yes| C[처리]
B -->|No| D[종료]
C --> D
```
---
## 9. 테스트 케이스
| ID | 시나리오 | 전제 조건 | 입력 | 기대 결과 |
|----|---------|---------|------|---------|
| TC-001 | 정상 케이스 | | | |
| TC-002 | 예외 케이스 | | | |
---
## 10. 의존성 및 관련 문서
- **선행 작업**:
- **연관 기능**:
- **참고 문서**:
---
## 11. 변경 이력
| 버전 | 날짜 | 작성자 | 변경 내용 |
|------|------|--------|---------|
| v1.0 | | | 최초 작성 |

163
docs/spec-review/02-ai-prompt-templates.md Normal file
View File

@@ -0,0 +1,163 @@
# AI 프롬프트 템플릿
> 스펙 문서를 AI(Claude)에 입력하여 플로우차트, 검토 의견 등을 자동 생성합니다.
---
## 1. 스펙 문서 → 플로우차트 변환
### 사용법
아래 프롬프트의 `[스펙 문서 내용]` 부분에 기능 요건 정의서를 붙여넣고 Claude에 전달합니다.
### 프롬프트 A: 기본 플로우차트 생성
```
다음 기능 스펙 문서를 분석하여 Mermaid flowchart 코드를 생성해주세요.
요구사항:
- flowchart TD (위→아래) 방향으로 작성
- 사용자 액션, 시스템 처리, 분기 조건, 에러 케이스를 모두 포함
- 노드명은 한국어로 작성
- 에러/예외 케이스는 점선 화살표(-.->)로 표현
- 완성된 Mermaid 코드 블록만 출력 (설명 불필요)
[스펙 문서 내용]
```
### 프롬프트 B: 사용자 시나리오 기반 플로우차트
```
다음 기능 스펙의 사용자 스토리를 기반으로 시나리오별 플로우차트를 Mermaid 코드로 생성해주세요.
요구사항:
- 각 사용자 스토리마다 별도 flowchart 생성
- 정상 흐름(Happy Path)과 예외 흐름(Edge Case)을 구분
- 사용자(Actor)와 시스템(System) 역할을 subgraph로 구분
- 완성된 Mermaid 코드 블록만 출력
[스펙 문서 내용]
```
### 프롬프트 C: 시퀀스 다이어그램 생성 (API 연동 포함)
```
다음 기능 스펙의 API 요건을 기반으로 클라이언트-서버 간 시퀀스 다이어그램을 Mermaid 코드로 생성해주세요.
요구사항:
- sequenceDiagram 형식 사용
- 참여자: Browser(사용자), Frontend(Nuxt), Backend(API), Database
- 각 API 호출의 Request/Response를 명시
- 인증 토큰 전달 과정 포함
- 에러 응답 케이스 포함
- 완성된 Mermaid 코드 블록만 출력
[스펙 문서 내용]
```
---
## 2. 스펙 문서 검토 및 보완 요청
### 프롬프트 D: 스펙 완성도 검토
```
다음 기능 요건 정의서를 검토하고 누락된 항목이나 불명확한 부분을 지적해주세요.
검토 기준:
1. 사용자 스토리가 명확한가
2. 예외/에러 케이스가 충분히 정의되었는가
3. 비기능 요건(성능, 보안, 접근성)이 포함되었는가
4. API 요건이 구체적인가
5. 테스트 케이스가 충분한가
6. 모호한 표현이나 주관적 기준이 있는가
출력 형식:
- 누락된 항목: [목록]
- 불명확한 부분: [목록 + 개선 제안]
- 전체 완성도: [점수/10]
[스펙 문서 내용]
```
### 프롬프트 E: 엣지 케이스 도출
```
다음 기능 스펙에서 개발자가 놓치기 쉬운 엣지 케이스와 예외 상황을 도출해주세요.
분류:
- 입력값 엣지 케이스 (빈값, 최대/최소값, 특수문자 등)
- 네트워크/서버 오류 케이스
- 동시성 이슈 (다중 탭, 중복 요청 등)
- 권한 관련 케이스
- 브라우저/기기 호환성 케이스
출력 형식: 표 형식 (케이스 | 발생 조건 | 기대 동작)
[스펙 문서 내용]
```
### 프롬프트 F: 개발 공수 산정 보조
```
다음 기능 스펙을 분석하여 프론트엔드 개발 공수를 산정해주세요.
기준:
- 기술 스택: Nuxt 4, TypeScript, Tailwind CSS, shadcn-vue
- 숙련도: 중급 개발자 기준
- 단위: 인일(man-day)
출력 형식:
| 작업 항목 | 공수(일) | 비고 |
- 합계 및 리스크 요소 포함
- 불확실한 항목은 범위로 표시 (예: 2~3일)
[스펙 문서 내용]
```
---
## 3. Mermaid 다이어그램 수정 보조
### 프롬프트 G: 다이어그램 수정
```
다음 Mermaid 다이어그램에서 [수정 요청 내용]을 반영하여 수정된 코드를 출력해주세요.
수정된 Mermaid 코드 블록만 출력합니다.
[기존 Mermaid 코드]
```
### 프롬프트 H: 다이어그램 검증
```
다음 Mermaid 코드의 문법 오류를 검사하고, 다이어그램이 논리적으로 올바른지 확인해주세요.
오류가 있으면 수정된 코드를 출력하고, 없으면 "정상"이라고 응답해주세요.
[Mermaid 코드]
```
---
## 4. 활용 팁
### Claude 사용 시 권장 설정
- **모델**: Claude Sonnet 4.6 이상 권장
- **온도(Temperature)**: 0.3 이하 (일관된 출력을 위해)
- **컨텍스트**: 한 번에 하나의 기능 스펙만 입력 (혼선 방지)
### 출력물 품질 향상 팁
1. 스펙 문서가 길면 섹션을 분리하여 순차적으로 입력
2. 생성된 플로우차트는 [Mermaid Live Editor](https://mermaid.live)에서 즉시 확인 가능
3. 만족스럽지 않으면 "더 구체적으로", "에러 케이스 추가" 등 후속 프롬프트로 개선
4. Confluence에는 Mermaid 매크로 또는 Draw.io로 변환하여 삽입
### Confluence 삽입 방법
```
1. Confluence 페이지 편집 → 삽입(+) → Mermaid Diagrams 매크로 선택
2. 또는 Code Block 매크로 → language: mermaid 선택 후 코드 붙여넣기
3. Mermaid 플러그인 미설치 시: mermaid.live에서 PNG로 export 후 이미지로 삽입
```

144
docs/spec-review/03-spec-review-checklist.md Normal file
View File

@@ -0,0 +1,144 @@
# 스펙 검토 체크리스트
> 기능 개발 시작 전, 스펙 문서가 개발 가능한 상태인지 확인합니다.
> 모든 항목이 ✅이 되어야 개발 착수할 수 있습니다.
---
## 체크리스트 사용법
1. 스펙 작성자(기획자/PM)가 1차 자체 검토
2. 개발 담당자가 2차 검토 후 보완 요청
3. 모든 항목 통과 시 개발 착수 승인
---
## 1. 기본 정보 확인
- [ ] 기능명이 명확하게 정의되어 있다
- [ ] 작성자, 작성일, 버전이 기록되어 있다
- [ ] 문서 상태가 "확정"으로 표시되어 있다
- [ ] 관련 Figma 디자인 링크가 포함되어 있다
---
## 2. 배경 및 목적
- [ ] 이 기능이 왜 필요한지 배경이 서술되어 있다
- [ ] 어떤 사용자 문제를 해결하는지 명확하다
- [ ] 이번 스펙의 범위(포함/미포함)가 구분되어 있다
- [ ] 비즈니스 목표와의 연관성이 기술되어 있다
---
## 3. 사용자 스토리
- [ ] 최소 1개 이상의 사용자 스토리가 있다
- [ ] As a / I want to / So that 형식으로 작성되어 있다
- [ ] 사용자 유형이 구체적으로 정의되어 있다 (예: "사용자" ❌ → "로그인한 일반 회원" ✅)
- [ ] 목표/가치가 명확하게 서술되어 있다
---
## 4. 기능 요건
- [ ] 모든 기능 요건에 고유 ID가 부여되어 있다 (FR-001, FR-002, ...)
- [ ] 각 요건의 우선순위가 정의되어 있다 (Must/Should/Could)
- [ ] 요건이 측정 가능하고 테스트 가능한 형태로 작성되어 있다
- [ ] 모호한 표현이 없다 ("빠르게" ❌ → "3초 이내" ✅)
- [ ] 예외/오류 케이스가 각 요건에 포함되어 있다
- [ ] 권한/인증 요건이 명시되어 있다
---
## 5. 비기능 요건
- [ ] 성능 기준이 정의되어 있다 (응답 시간, 처리량 등)
- [ ] 보안 요건이 명시되어 있다
- [ ] 접근성 요건이 정의되어 있다 (WCAG 수준)
- [ ] 지원 브라우저/기기 범위가 정의되어 있다
---
## 6. UI/UX
- [ ] 모든 화면의 경로(URL)가 정의되어 있다
- [ ] 반응형 대응 범위가 명시되어 있다 (모바일/태블릿/PC)
- [ ] Figma 디자인 시안이 확정 상태이다
- [ ] 로딩 상태(Skeleton/Spinner) 처리 방식이 정의되어 있다
- [ ] 빈 상태(Empty State) UI가 정의되어 있다
- [ ] 에러 상태 UI가 정의되어 있다
---
## 7. API 요건
- [ ] 필요한 API 목록이 정의되어 있다
- [ ] 각 API의 Method, Endpoint가 명시되어 있다
- [ ] 요청(Request) 파라미터가 정의되어 있다
- [ ] 응답(Response) 데이터 구조가 정의되어 있다
- [ ] 인증 필요 여부가 표시되어 있다
- [ ] HTTP 오류 코드별 처리 방법이 정의되어 있다
---
## 8. 플로우차트
- [ ] 전체 기능 흐름을 나타내는 플로우차트가 있다
- [ ] 정상 흐름(Happy Path)이 포함되어 있다
- [ ] 예외 흐름(Error Path)이 포함되어 있다
- [ ] 분기 조건이 명확하게 표현되어 있다
- [ ] 플로우차트와 기능 요건이 일치한다
---
## 9. 테스트 케이스
- [ ] 핵심 기능에 대한 테스트 케이스가 최소 3개 이상 있다
- [ ] 정상 케이스(Happy Path) 테스트가 포함되어 있다
- [ ] 예외/오류 케이스 테스트가 포함되어 있다
- [ ] 경계값 테스트가 포함되어 있다 (최소/최대값 등)
- [ ] 각 테스트의 기대 결과가 명확하다
---
## 10. 의존성 확인
- [ ] 선행 개발이 필요한 API/기능이 확인되었다
- [ ] 연관 기능과의 충돌 여부가 검토되었다
- [ ] 서드파티 서비스 연동이 필요한 경우 계약/키 발급이 확인되었다
- [ ] 데이터 마이그레이션이 필요한 경우 계획이 수립되어 있다
---
## 검토 결과
| 항목 | 통과 수 | 전체 수 | 통과율 |
|------|--------|--------|-------|
| 기본 정보 | / | 4 | % |
| 배경 및 목적 | / | 4 | % |
| 사용자 스토리 | / | 4 | % |
| 기능 요건 | / | 6 | % |
| 비기능 요건 | / | 4 | % |
| UI/UX | / | 6 | % |
| API 요건 | / | 6 | % |
| 플로우차트 | / | 5 | % |
| 테스트 케이스 | / | 5 | % |
| 의존성 | / | 4 | % |
| **합계** | / | **48** | % |
### 판정 기준
| 통과율 | 판정 | 조치 |
|--------|------|------|
| 90% 이상 | ✅ 개발 착수 가능 | - |
| 70~89% | ⚠️ 조건부 착수 | 미통과 항목 보완 후 재검토 |
| 70% 미만 | ❌ 재작성 필요 | 스펙 전면 보완 후 재검토 |
### 검토자 의견
| 역할 | 이름 | 검토일 | 의견 |
|------|------|--------|------|
| 기획 | | | |
| 개발 | | | |
| 디자인 | | | |

141
docs/spec-review/04-flowchart-validation.md Normal file
View File

@@ -0,0 +1,141 @@
# 플로우차트 검증 기준
> AI가 생성하거나 직접 작성한 플로우차트가 올바른지 판단하는 기준입니다.
---
## 1. 구조적 완전성
### 1.1 필수 요소 포함 여부
| 요소 | 설명 | 확인 |
|------|------|------|
| 시작점 | 명확한 시작 노드 (원형/Stadium) | [ ] |
| 종료점 | 모든 경로에 종료 노드가 있음 | [ ] |
| 분기 조건 | 모든 분기에 Yes/No 또는 조건 라벨이 있음 | [ ] |
| 처리 단계 | 주요 시스템/사용자 액션이 포함됨 | [ ] |
| 에러 경로 | 예외 상황 처리 흐름이 포함됨 | [ ] |
### 1.2 흐름 무결성
- [ ] 고아 노드가 없다 (연결되지 않은 노드)
- [ ] 무한 루프가 없다 (탈출 조건이 있는 경우만 루프 허용)
- [ ] 모든 분기가 다시 합류하거나 종료로 이어진다
- [ ] 화살표 방향이 일관적이다
---
## 2. 스펙 일치성
### 2.1 기능 요건과의 일치
- [ ] 스펙의 모든 주요 기능이 플로우차트에 반영되어 있다
- [ ] 플로우차트에 스펙에 없는 임의 로직이 추가되지 않았다
- [ ] 분기 조건이 스펙의 비즈니스 규칙과 일치한다
- [ ] API 호출 순서가 스펙의 API 요건과 일치한다
### 2.2 사용자 스토리와의 일치
- [ ] 사용자 스토리의 시작 조건이 플로우차트에 반영되어 있다
- [ ] 기대 결과(목표)가 플로우차트 종료 노드에 표현되어 있다
---
## 3. 가독성
### 3.1 노드 명명 규칙
| 노드 유형 | 명명 규칙 | 예시 |
|----------|---------|------|
| 사용자 액션 | 동사 + 목적어 | "로그인 버튼 클릭" |
| 시스템 처리 | 동사 + 결과 | "토큰 발급" |
| 분기 조건 | 조건문 형태 | "토큰 유효한가?" |
| 에러 상태 | 에러 + 설명 | "인증 실패" |
| 시작/종료 | 명사형 | "시작", "완료", "종료" |
### 3.2 복잡도 기준
| 기준 | 권장 값 | 초과 시 조치 |
|------|--------|-----------|
| 노드 수 | 20개 이하 | 서브 플로우로 분리 |
| 분기 깊이 | 4단계 이하 | 조건 단순화 또는 분리 |
| 다이어그램 너비 | 7열 이하 | 방향 변경 또는 분리 |
### 3.3 시각적 기준
- [ ] 동일 레벨의 노드들이 정렬되어 있다
- [ ] 화살표가 교차하지 않는다 (불가피한 경우 최소화)
- [ ] 에러/예외 경로가 정상 경로와 시각적으로 구분된다 (점선 사용)
- [ ] subgraph로 역할이 구분된 경우 라벨이 명확하다
---
## 4. Mermaid 문법 검증
### 4.1 기본 문법 체크
```mermaid
flowchart TD
%% 노드 유형 예시
A([시작]) %% Stadium: 시작/종료
B[처리 단계] %% 직사각형: 처리
C{조건 분기?} %% 마름모: 분기
D[(데이터베이스)] %% 원통: DB
E[[서브 루틴]] %% 이중 직사각형: 서브 루틴
%% 화살표 유형
A --> B %% 일반 화살표
B -.-> C %% 점선 화살표 (에러/예외)
C -->|Yes| D
C -->|No| E
```
### 4.2 자주 발생하는 오류
| 오류 | 원인 | 해결 방법 |
|------|------|---------|
| 파싱 에러 | 노드명에 특수문자 포함 | 따옴표로 감싸기: `["노드명"]` |
| 화살표 미연결 | 노드 ID 오타 | 노드 ID 일치 여부 확인 |
| 마름모 문법 오류 | 중괄호 누락 | `{조건?}` 형식 확인 |
| subgraph 미닫힘 | end 누락 | subgraph 블록에 `end` 추가 |
### 4.3 검증 도구
- **온라인 검증**: [Mermaid Live Editor](https://mermaid.live)
- **VSCode 플러그인**: Mermaid Preview (Bierner)
- **AI 검증**: `02-ai-prompt-templates.md`의 프롬프트 H 활용
---
## 5. 검증 프로세스
```
1단계: AI 생성
└── 프롬프트 A~C 사용하여 초안 생성
2단계: 문법 검증
└── Mermaid Live Editor에서 렌더링 확인
3단계: 구조 검증 (본 문서 1~2항 체크리스트)
└── 필수 요소, 흐름 무결성, 스펙 일치 확인
4단계: 가독성 검토
└── 복잡도, 노드 명명, 시각적 기준 확인
5단계: 스테이크홀더 검토
└── 기획자/개발자 최종 승인
6단계: Confluence 등록
└── Mermaid 매크로 또는 이미지로 삽입
```
---
## 6. 검증 결과 기록
| 항목 | 결과 | 수정 사항 | 검토자 |
|------|------|---------|--------|
| 구조적 완전성 | Pass/Fail | | |
| 스펙 일치성 | Pass/Fail | | |
| 가독성 | Pass/Fail | | |
| 문법 검증 | Pass/Fail | | |

174
docs/spec-review/05-workflow.md Normal file
View File

@@ -0,0 +1,174 @@
# 스펙 검토 워크플로우
> 신규 기능 개발 시 스펙 문서 작성부터 개발 착수까지의 전체 프로세스입니다.
---
## 전체 흐름
```mermaid
flowchart TD
A([신규 기능 요청]) --> B[기획자: 스펙 초안 작성]
B --> C[AI로 플로우차트 자동 생성]
C --> D[기획자 셀프 체크리스트 검토]
D --> E{체크리스트\n통과 90%+?}
E -->|No| F[스펙 보완]
F --> D
E -->|Yes| G[개발자 스펙 검토]
G --> H{개발 가능\n여부 확인}
H -->|보완 필요| I[보완 요청 및 재검토]
I --> G
H -->|승인| J[Confluence Wiki 등록]
J --> K([개발 착수])
```
---
## 단계별 상세 설명
### STEP 1. 스펙 초안 작성 (기획자)
**담당**: 기획자 / PM
**산출물**: 기능 요건 정의서 초안
**도구**: `01-feature-requirements-template.md` 템플릿 활용
**작업 내용**:
1. `01-feature-requirements-template.md`를 Confluence에 복사
2. 각 섹션 작성 (기본 정보, 배경, 사용자 스토리, 기능 요건 등)
3. Figma 디자인 링크 연결
**완료 기준**: 템플릿의 모든 필수 섹션 작성 완료
---
### STEP 2. AI 플로우차트 자동 생성 (기획자)
**담당**: 기획자 / PM
**산출물**: Mermaid 플로우차트
**도구**: `02-ai-prompt-templates.md` 프롬프트 활용
**작업 내용**:
1. Claude에 작성한 스펙 문서와 함께 **프롬프트 A** 입력
2. 생성된 Mermaid 코드를 [Mermaid Live Editor](https://mermaid.live)에서 확인
3. 필요 시 **프롬프트 G**로 수정 요청
4. 완성된 플로우차트를 스펙 문서 섹션 8에 삽입
**추가 옵션**:
- API 연동이 복잡한 경우: **프롬프트 C** (시퀀스 다이어그램) 추가 생성
- 스펙 품질 확인이 필요한 경우: **프롬프트 D** (스펙 완성도 검토) 실행
**완료 기준**: 플로우차트가 스펙 문서에 포함되고 렌더링 정상 확인
---
### STEP 3. 셀프 검토 (기획자)
**담당**: 기획자 / PM
**도구**: `03-spec-review-checklist.md`
**작업 내용**:
1. `03-spec-review-checklist.md`의 체크리스트를 Confluence에 복사
2. 각 항목 순서대로 검토
3. 통과율 계산 및 판정 결과 기록
**통과 기준**: 90% 이상 (48개 중 44개 이상)
**미통과 시**: 해당 항목 보완 후 재검토
---
### STEP 4. 개발자 스펙 검토
**담당**: 프론트엔드 개발자 (담당 개발자 + 리드 검토)
**도구**: `03-spec-review-checklist.md`, `04-flowchart-validation.md`
**작업 내용**:
1. 스펙 문서 전체 검토
2. 플로우차트 검증 기준(`04-flowchart-validation.md`) 적용
3. 기술적 실현 가능성 검토:
- API 스펙 충분한가
- 성능 요건 달성 가능한가
- 기술 스택(Nuxt 4, TS) 내에서 구현 가능한가
4. 공수 산정: **프롬프트 F** 활용 후 검토자가 조정
5. 검토 결과를 Confluence 댓글 또는 체크리스트 검토자 란에 기록
**완료 기준**: 개발자 승인 또는 보완 요청 목록 작성
---
### STEP 5. Confluence Wiki 등록
**담당**: 기획자 / PM
**산출물**: 확정된 스펙 문서 (Wiki 등록 완료)
**작업 내용**:
1. 스펙 문서 상태를 "확정"으로 변경
2. Confluence 페이지 트리 구조에 등록:
```
[프로젝트명]
└── 기능 스펙
└── [기능명] - [날짜]
├── 기능 요건 정의서
├── 플로우차트
└── 스펙 검토 결과
```
3. 관련 팀원에게 Confluence 알림 발송
4. 개발 티켓(GitLab Issue/Jira)에 스펙 문서 링크 연결
**완료 기준**: Confluence 페이지 공개 상태 확인, 팀 알림 발송 완료
---
### STEP 6. 개발 착수
**담당**: 프론트엔드 개발자
**개발 착수 전 최종 확인**:
- [ ] 스펙 문서 상태: "확정"
- [ ] 체크리스트 통과율: 90% 이상
- [ ] 플로우차트: Confluence 등록 완료
- [ ] Figma 디자인: 확정 상태
- [ ] API 명세: 백엔드 팀 확인 완료
- [ ] 개발 티켓: 생성 및 스펙 링크 연결 완료
---
## 역할별 책임 (RACI)
| 활동 | 기획자 | 개발자(담당) | 개발자(리드) | 디자이너 |
|------|--------|-----------|-----------|---------|
| 스펙 초안 작성 | **R** | C | C | C |
| 플로우차트 생성 | **R** | I | I | I |
| 셀프 체크리스트 | **R** | - | - | - |
| 개발자 스펙 검토 | C | **R** | **A** | - |
| Confluence 등록 | **R** | I | I | I |
| 개발 착수 승인 | A | - | **R** | - |
> R: Responsible (실행) / A: Accountable (승인) / C: Consulted (협의) / I: Informed (통보)
---
## 소요 시간 기준
| 단계 | 기능 규모 小 | 기능 규모 中 | 기능 규모 大 |
|------|-----------|-----------|-----------|
| 스펙 초안 작성 | 0.5일 | 1~2일 | 3~5일 |
| AI 플로우차트 생성 | 0.5시간 | 1시간 | 2시간 |
| 셀프 체크리스트 | 0.5시간 | 1시간 | 2시간 |
| 개발자 스펙 검토 | 1시간 | 2~4시간 | 1일 |
| Confluence 등록 | 0.5시간 | 1시간 | 1시간 |
> **기능 규모 기준**
> - 小: 단일 화면, API 1~2개
> - 中: 2~3개 화면, API 3~5개
> - 大: 4개 이상 화면, API 6개 이상 또는 복잡한 상태관리 필요
---
## 관련 문서
| 문서 | 설명 | 위치 |
|------|------|------|
| 기능 요건 정의 템플릿 | 스펙 작성 양식 | `01-feature-requirements-template.md` |
| AI 프롬프트 템플릿 | 플로우차트 자동 생성 | `02-ai-prompt-templates.md` |
| 스펙 검토 체크리스트 | 품질 검증 기준 | `03-spec-review-checklist.md` |
| 플로우차트 검증 기준 | 다이어그램 품질 기준 | `04-flowchart-validation.md` |