16일간의 기적

• '내가 만들고 싶은 것'이 아니라 '누가 불편해하는가'에서 출발하세요.
• 관찰·인터뷰로 확인한 실제 페인 포인트를 적으세요.

# 문제 후보 [A]

## 누구의 문제인가 (대상 사용자)
-

## 어떤 상황에서 겪는가
-

## 반복적으로 겪는 페인 포인트 (관찰/인터뷰 근거)
-
-

## 지금은 어떻게 (불편하게) 해결하고 있나
-

## 이 문제가 중요한 이유
-

• AI 적합성: 반복적·언어적 작업이거나 사람마다 답이 다른 영역인지 확인하세요.
• 범위를 좁힐수록 16일 안에 끝낼 확률이 올라갑니다.

# 문제 정의 (problem.md)

## 확정된 문제 한 문장
>

## 대상 사용자
-

## 핵심 페인 포인트
-

## AI 적합성 판단 (왜 AI로 풀기 적합한가)
-

## 후보 A·B·C 중 이 문제를 고른 이유
-

## 범위 (이번 16일에 다루는 것 / 다루지 않는 것)
- 다룬다:
- 다루지 않는다:

• 1년 뒤, 사용자의 하루가 어떻게 달라지는지 상상해서 적어보세요.

# 비전 (vision.md)

## 한 줄 비전
>

## 이 서비스가 없을 때 vs 있을 때
- 없을 때:
- 있을 때:

## 궁극적으로 사용자에게 주는 가치
-

## 성공했을 때의 모습
-

• '사용자가 ○○할 때 → 서비스가 ○○해주고 → 결국 ○○하게 된다' 흐름으로 쓰세요.

# 이상적 시나리오 (scenario.md)

## 등장 인물 (사용자)
- 이름/역할:
- 상황:

## 이상적인 흐름 (Before → 사용 → After)
1. (Before) 사용자는 지금 ____ 때문에 불편하다.
2. 사용자가 우리 서비스에서 ____ 한다.
3. 서비스는 ____ 해준다.
4. (After) 결국 사용자는 ____ 하게 된다.

## 이 시나리오에서 가장 중요한 '결정적 순간'
-

• 측정 가능해야 합니다. '좋아진다'가 아니라 '○○ 시간이 △분 줄어든다'처럼.

# MVP 성공 기준 (success.md)

## 성공 기준 한 문장
> (예: "테스터가 기존 30분 걸리던 작업을 5분 안에 끝낸다.")

## 측정 방법
- 무엇을:
- 어떻게 측정:
- 목표 수치:

## 성공/실패 판단 시점
-

• 기획자와 개발/디자인이 '같은 PRD'를 보며 동시에 움직이게 하세요.
• 핵심 기능부터. 욕심내면 16일 안에 못 끝냅니다.

# PRD - 제품 요구사항 문서 (prd.md)

## 문서 버전
- v1 (DAY 4) / 이후 v2 (DAY 13)

## 한 줄 제품 설명
>

## 핵심 기능 (우선순위 순)
1. [필수]
2. [필수]
3. [선택]

## 각 기능별 사용자 스토리
- (사용자)는 (목적)을 위해 (행동)을 할 수 있다.

## 화면/흐름 개요
-

## 이번 버전에서 하지 않는 것 (Out of Scope)
-

## 성공 지표 (success.md 연동)
-

• PRD가 '무엇을'이면 TRD는 '어떻게'. 구조·기술 선택을 적습니다.

# TRD - 기술 요구사항 문서 (trd.md)

## 문서 버전
- v1 (DAY 5) → v4 (DAY 13)

## 시스템 개요
-

## 기술 스택
- LLM/모델:
- 프론트/데모: (CLI → Streamlit/Gradio → 정식)
- 인프라/배포: (Cloudflare Tunnel → 커스텀 도메인 + HTTPS)

## 주요 모듈 구성
- 모듈 1:
- 모듈 2:

## 평가(Eval) 방식
- 테스트 케이스 수: (Basic / Edge / Safety)
- 채점 방식: (Pass Rate / LLM-judge)

## 가드레일
- Pre-LLM(입력 검사):
- Post-LLM(출력 검증):
- Tool Guardrail:
- PII 마스킹 / 프롬프트 인젝션 탐지:

• 결정 1건당 문서 1개. 짧아도 됩니다. 핵심은 '왜'입니다.

# ADR-0001: [결정 제목]

## 상태
- 제안 / 채택 / 폐기  (택1)

## 맥락 (어떤 상황에서 결정이 필요했나)
-

## 결정 (무엇을 선택했나)
- (예: 도메인 특화를 위해 Fine-tuning 대신 RAG를 채택한다.)

## 이유 (왜 이 선택인가)
-

## 고려했지만 택하지 않은 대안
-

## 결과 / 영향
-

• GitHub은 아래 ```mermaid 블록을 자동으로 그림으로 보여줍니다.
• 화살표 방향 = 데이터가 흐르는 방향입니다.

# 데이터 흐름도 (dfd.md)

```mermaid
flowchart LR
    User([사용자 입력]) --> Pre[입력 검사 / 전처리]
    Pre --> LLM[LLM 처리]
    LLM --> Post[출력 검증 / 가드레일]
    Post --> Result([결과 반환])
    LLM -.참고.-> KB[(지식베이스 / RAG)]
```

## 흐름 설명
1. 사용자 입력이 들어온다.
2. 전처리·입력 검사를 거친다.
3. LLM이 (필요 시 RAG로 자료를 참고해) 처리한다.
4. 출력 검증/가드레일을 통과한다.
5. 결과를 사용자에게 돌려준다.

• 피드백은 '수용'보다 '반영'이 중요. 반드시 반영 항목으로 옮기세요.

# 중간 데모 피드백 (feedback.md)

## 데모 개요
- 일시 / 대상:

## 체크리스트 점검 결과
- [ ] 페인 포인트가 실제 시연에서 해결되었는가?
- [ ] Self-correction loop가 원활히 작동하는가?
- [ ] PRD/TRD 갱신이 필요한 항목이 정의되었는가?

## 받은 피드백
| # | 피드백 | 중요도 | 반영 여부 | 반영 문서(PRD/TRD) |
|---|--------|--------|-----------|--------------------|
| 1 |        |        |           |                    |
| 2 |        |        |           |                    |

## 다음 Iterate에서 반영할 항목
-

• AI 프롬프트 예: '아래 Git 커밋 기록을 바탕으로 변경 근거와 Changelog를 생성해 줘.'

# Changelog

## [v2] - DAY 13
### Added (추가)
-

### Changed (변경)
-

### Fixed (수정)
-

### 변경 근거 (피드백 연동)
-

## [v1] - DAY 5
### Added
- 최소 기능 구현 및 조기 배포

• '무엇을 하는 서비스인지'와 '어떻게 실행하는지'가 핵심입니다.

# 프로젝트 이름

## 한 줄 소개
>

## 해결하는 문제
-

## 데모 / 접속 주소
-

## 주요 기능
-

## 실행 방법
```bash
# 1. 설치
# 2. 실행
```

## 기술 스택
-

## 팀
-

• DAY 4의 그 테스터에게 다시 물어, 같은 사람의 전/후를 비교하세요.

# 최종 성과 보고서 (final_report.md)

## 해결한 문제 (요약)
-

## 사용자 전/후 반응 비교
| 항목 | Before (DAY 4) | After (DAY 15) |
|------|----------------|----------------|
| 소요 시간 |            |                |
| 만족도   |              |                |
| 인상적 반응 |           |                |

## 최종 Eval 결과
- Pass Rate:
- 주요 지표:

## 성공 기준 달성 여부 (success.md 대비)
-

## 한계와 다음 단계
-