<!-- G-0: 비즈니스 모델 캔버스 + 요금제 워크시트 (빈 양식) — Ch.2 연동 -->
# [서비스명] 비즈니스 모델 캔버스 (6칸)
① 문제   — 누가, 어떤 상황에서, 무엇 때문에 곤란한가?
② 기존 대안 — 지금 그들은 뭘 쓰나? 어디서 무너지나?
③ 해결책 — 내 서비스의 핵심 동작 한 문장
④ 차별점 — 기존 대안이 구조적으로 못 하는 것
⑤ 수익 모델 — 원타임/구독/기타 + 핵심 유료 트리거
⑥ 원가 구조 — 사용자 1명당 매달 나가는 돈 (Ch.3.4에서 계산)

# 요금제 설계 워크시트
1. 핵심 가치 체험에 최소한 필요한 것은? → Free에 넣을 것
2. 사용자가 "더 원하게 되는" 첫 순간은? → Free/Pro 분기점
3. Pro 사용자 1명의 월 원가는? → 가격의 하한선
4. 기존 대안들의 가격대는? → 가격의 중력장
5. 헤비 유저를 어떻게 수용할 것인가? → 상위 티어 또는 BYOK


<!-- G-1: 아키텍처 레퍼런스 (빈 양식) -->
# [서비스명] 아키텍처 레퍼런스
최종 수정: YYYY-MM-DD | 이 문서가 모든 기술 판단의 기준점이다.

## 1. 서비스 한 문장
[누가] [무엇을 하면] [무엇을 얻는다]

## 2. 구성 요소 지도 (식당 비유로 그려라)
- 홀(프론트엔드): [기술명] — 배포: [플랫폼]
- 주방(백엔드): [기술명] — 배포: [플랫폼]
- 요리사(AI): [모델 계열] — 호출 위치: [어디서]
- 냉장고(DB): [기술명]
- 출입구(인증): [서비스명]
- 설거지(워커): [있음/없음 — 있다면 기술명]
- 결제: [서비스명]

## 3. 데이터 흐름 (핵심 시나리오 1개)
사용자가 [행동] → [홀] → [주방] → [요리사/냉장고] → 사용자에게 [결과]

## 4. 모듈 간 약속 (인터페이스)
| 보내는 쪽 | 받는 쪽 | 주고받는 것 (형식) |
|---|---|---|
| (보내는 쪽) | (받는 쪽) | (주고받는 것) |

## 5. 구조적 결정 기록 (바뀔 때마다 추가)
| 날짜 | 결정 | 이유 |
|---|---|---|
| (날짜) | (결정) | (이유) |


<!-- G-2: 진행 추적 체크리스트 (빈 양식) -->
# [서비스명] 진행 추적
현재 Stage: [1/2/3] | 마지막 세션: YYYY-MM-DD

## 이번 Stage 작업 목록
- [ ] 작업명 — 완료 기준 한 줄
- [ ] ...

## 오늘 세션 (매번 갱신 — 시작 2분, 종료 2분)
- 지난 세션에서 한 것:
- 오늘 할 것 (하나만):
- 막힌 것 / 다음 세션에 넘길 것:

## Freeze 목록 (수정 금지 — Ch.6.3)
- [파일/모듈] (Stage N 통과, YYYY-MM-DD)


<!-- G-3: 빌드 프롬프트 (빈 양식) -->
# 빌드 지시서: [작업명]
날짜: YYYY-MM-DD

## 목표 (한 문장)

## 맥락 (먼저 읽을 것)
- 아키텍처 레퍼런스 [경로/첨부]
- 관련 스펙: [모듈명]
- 최신 결정사항 파일 확인할 것 (Ch.5.5)

## 할 일
1.
2.

## 하지 말 일 (금지 조항 — 반드시 작성)
- [Freeze 목록]의 파일은 절대 수정하지 마라. 수정이 필요하다고
  판단되면 수정하지 말고 나에게 보고해라.
- 이번 단계 범위 밖 기능([예: 인증, 결제])은 미리 만들지 마라.

## 완료 기준 (PASS/FAIL로 답 가능하게)
- [ ]


<!-- G-3.5: 스펙 문서 (빈 양식) — V2를 무너뜨린 바로 그 문서 -->
# 스펙: [모듈명]
최종 수정: YYYY-MM-DD | 이 모듈과 데이터를 주고받는 모든 작업은 이 문서가 기준이다.

## 한 문장 역할
이 모듈은 [무엇]을 받아 [무엇]을 해서 [무엇]을 내보낸다.

## 입력
| 항목 | 형식 | 예시 | 없으면? |
|---|---|---|---|
| (항목) | (형식) | (예시) | (거부 / 기본값 사용 / 빈 값 허용) |

## 처리 (개념 수준 — 비개발자 언어로)
1.
2.

## 출력
| 항목 | 형식 | 예시 |
|---|---|---|
| (항목) | (형식) | (예시) |

## 실패 시 동작 (무음 실패 금지 — Ch.12)
- 실패하면: [에러 반환 / 재시도 N회 / 알림]
- 실패를 나는 어떻게 알게 되나: [로그 / 알림 채널]

## 이 모듈과 약속을 맺은 상대들
- [모듈명] — 주고받는 것:


<!-- G-4: Stage 게이트 검증 (빈 양식) -->
# 게이트 검증: Stage [N] → [N+1]
검증일: YYYY-MM-DD | 규칙: 전 항목 PASS여야 통과. "거의 PASS"는 FAIL이다.

## 게이트 1 (Core → SaaS) 기본 항목
- [ ] 핵심 처리, 입력 바꿔 5회 연속 성공
- [ ] 결과물 품질: 나라면 돈을 내겠는가
- [ ] 처리 1건당 비용을 숫자로 안다 (→ 부록 D ③에 입력)
- [ ] 모듈 간 입출력이 문서와 실물 일치
- [ ] 다음 Stage의 Freeze 목록 작성 완료

## 게이트 2 (SaaS → Monetization) 기본 항목
- [ ] 타인이 안내 없이 가입~핵심 기능 완주
- [ ] 사용자 간 데이터 격리 확인 (A의 데이터가 B에게 안 보임)
- [ ] 배포 환경에서 전체 흐름 동작
- [ ] 에러 시 사용자에게 보이는 화면 확인
- [ ] API Freeze 선언 완료

## 프로젝트 고유 항목 (직접 추가)
- [ ]

## 판정: PASS / FAIL → FAIL 항목과 조치:


<!-- G-5: 교차 검증 체크리스트 (PASS/FAIL 양식 — Ch.5.6) -->
# 교차 검증: [대상 기능/화면/설계]
검증일: YYYY-MM-DD

## 역할 1 — 백엔드 개발자 관점
질문: 이 구조가 안정적인가? 사용자가 늘면 어디가 먼저 무너지나?
- 지적 사항:
- 조치: [반영 / 보류+이유]

## 역할 2 — UI/UX 디자이너 관점
질문: 처음 온 사용자가 헷갈리는 지점은?
- 지적 사항:
- 조치:

## 역할 3 — 보안 검토자 관점 (Ch.14)
질문: 전부 의심하고 전부 확인해라. 특히 권한·입력·기본값.
- 지적 사항:
- 조치:

## 역할 4 — 비용 관리자 관점
질문: API 호출이 과한 곳, 돈이 새는 구조는?
- 지적 사항:
- 조치:

## 기능 검증 (실패 경로 위주로 — AI에게 생성시켜 추가)
- [ ] 정상 경로: ___ (PASS/FAIL)
- [ ] 실패 경로: ___ (PASS/FAIL)
- [ ] 실패 경로: ___ (PASS/FAIL)

## 종합 판정 + 다음 점검일 (3:1 규칙 — Ch.16):


<!-- G-5: 교차 검증 체크리스트 (PASS/FAIL 양식 — Ch.5.6) -->
# 장애 사후 분석: [한 줄 제목]
발생: YYYY-MM-DD HH:MM ~ HH:MM (총 N분/시간)

- 무슨 일이 있었나 (사용자 관점):
- 왜 일어났나 (근본 원인):
- 어떻게 알게 됐나: [알림 / 직접 발견 / 사용자 신고] ← 사용자 신고였다면 모니터링 구멍
- 어떻게 복구했나: [롤백 / 재시작 / 설정 수정]
- 재발 방지 (셋 중 하나 이상): [알림 추가 / 체크리스트 추가 / 자동화 추가]
- 개발 규칙 문서에 추가할 한 줄 (Ch.14의 교훈):