16일간의 기적 — AI 바이브 코딩 프로젝트 로드맵 (전체 콘텐츠)

비전공 학생이 16일 만에 아이디어를 '작동하는 서비스'로 만드는 단계별 로드맵.
코드는 AI가, 사람은 의도·검증·방향에 집중하는 '문서 중심(Docs as Code)' 개발.
분석용 전체 추출본 · 단계 / DAY 0~16 / 용어사전(39) / 산출물 템플릿(13) · 원본 Markdown

단계(Stage) 개요

사전 준비 — 프로젝트의 기초 체력 · 협업 환경 구축 (DAY 0)

• 결정적 순간: 도구·환경을 갖추고 충돌 없이 협업할 토대를 만든다
• 전환 문구: “기초 세팅이 완료되었다면, 이제 우리가 풀고자 하는 '진짜 문제'에 집중할 시간입니다.”

1단계 · 기획 및 검증 — 문제 정의에서 프로토타입까지 (DAY 1~4)

• 결정적 순간: 문제-가치 정렬 및 프로토타입 분업
• 전환 문구: “설계도가 완성되었습니다. 이제 AI의 도움을 받아 실제로 작동하는 첫 번째 버전을 만들어 보겠습니다.”

2단계 · 기술 구현 — Build V1에서 V3까지의 점진적 확장 (DAY 5~10)

• 결정적 순간: 가드레일을 통한 서비스 신뢰성 확보
• 전환 문구: “기술적 구현이 성숙해졌다면, 이제 외부의 시선으로 프로젝트를 객관화할 단계입니다.”

3단계 · 문서화 및 피드백 — 아키텍처 시각화와 중간 점검 (DAY 11~12)

• 결정적 순간: Mermaid 아키텍처 확정 및 외부 리뷰
• 전환 문구: “피드백은 수용하는 것만큼이나 어떻게 반영하느냐가 중요합니다. 이제 최종 개선에 돌입합니다.”

4단계 · 고도화 및 완성 — 반복 개선과 최종 발표 (DAY 13~16)

• 결정적 순간: 사용자 재검증을 통한 가치 증명
• 전환 문구: “16일간의 여정이 끝났습니다. 이제 당신의 프로젝트는 단순한 코드를 넘어 누군가의 문제를 해결하는 서비스가 되었습니다.”

DAY별 상세 (DAY 0~16)

용어 사전 (비전공자용 · 39개)

협업/Git

• Docs as Code (문서형 코드): 기획 문서(.md)도 코드처럼 Git으로 함께 관리하는 철학.
  기획서를 워드나 PPT로 따로 두면 코드와 어긋나기 쉽습니다. Docs as Code는 문서를 Markdown(.md) 파일로 만들어 코드와 같은 저장소에서 함께 버전 관리합니다. 그래서 '문서와 코드가 하나로 움직인다'고 표현합니다.
• 저장소 (Repository / Repo): 팀의 코드와 문서를 함께 보관하는 공용 창고.
  GitHub에 만드는 프로젝트 보관소입니다. 팀원 모두가 이 창고를 공유하며, 누가 언제 무엇을 바꿨는지 기록이 남습니다.
• 복제 (Clone) (Clone): 원격 저장소(창고)를 내 컴퓨터로 똑같이 한 벌 복사해 오는 것.
  GitHub Desktop을 쓰면 마우스 클릭만으로 원격 저장소를 내 PC로 복제할 수 있습니다. 이렇게 가져온 사본에서 작업한 뒤, 다시 창고로 올립니다.
• 브랜치 (Branch) (Branch): 본체를 건드리지 않고 따로 작업하는 '평행 우주'.
  main 브랜치는 '항상 작동하는 안정 버전'으로 보호하고, 각 팀원은 feature/기능명 브랜치를 만들어 독립적으로 작업합니다. 서로 다른 우주에서 작업하니 코드 충돌이 원천 차단되고, 완성되면 main에 합칩니다.
• 커밋 (Commit) (Commit): 변경 사항을 한 묶음으로 저장하며 남기는 기록.
  작업 내용을 저장하는 '저장 지점'입니다. 커밋 메시지에 무엇을 왜 바꿨는지 적어두면 나중에 히스토리를 읽기 쉽습니다. Cursor의 AI 기능으로 변경 요약을 자동 생성할 수 있습니다.
• 커밋 컨벤션 (Commit Convention): 커밋 메시지 앞에 feat:, docs:, fix: 같은 말머리를 붙이는 규칙.
  feat:(기능 추가), docs:(문서 수정), fix:(버그 수정)처럼 약속된 접두어를 붙입니다. 이렇게 규격화하면 변경 이력을 분류·검색하기 쉽고, AI가 자동으로 정리해 주기도 좋습니다.

기획

• 페인 포인트 (Pain Point): 사용자가 반복적으로 겪는 불편·고통.
  좋은 서비스는 '내가 만들고 싶은 것'이 아니라 '누군가 진짜 불편해하는 것'에서 출발합니다. 사용자를 관찰하거나 인터뷰해 반복되는 고통을 찾는 것이 기획의 핵심입니다.
• AI 적합성 필터: 이 문제가 'AI로 풀기에 적합한가'를 가려내는 기준.
  정답이 사람마다 다르거나, 반복적·언어적 작업이라 AI가 잘하는 영역인지 점검합니다. AI가 강점을 발휘할 수 없는 문제라면 다른 후보를 고르는 게 낫습니다.
• MVP (Minimum Viable Product): 핵심 가치만 담은 '최소 기능 제품'.
  한 번에 완벽한 서비스를 만들려 하지 않고, 가치를 검증할 수 있는 가장 작은 버전을 먼저 만듭니다. MVP의 성공 기준은 측정 가능한 '한 문장'으로 정의하는 것이 좋습니다.
• PRD (Product Requirements Document): 제품 요구사항 문서 — '무엇을' 만들지 정의.
  어떤 기능이 왜 필요하고, 사용자가 무엇을 할 수 있어야 하는지 정리한 문서입니다. 기획자와 개발/디자인이 '같은 PRD를 보며' 동시에 움직이는 것이 진짜 협업입니다.
• TRD (Technical Requirements Document): 기술 요구사항 문서 — '어떻게' 만들지 정의.
  PRD가 '무엇을'이라면 TRD는 '어떻게'입니다. 어떤 기술·구조로 구현할지 기록하며, 프로젝트가 진행되며 v1 → v4처럼 버전이 올라갑니다.
• 프로토타입 (Prototype): 완성 전에 빠르게 만들어 보는 '화면 스케치'.
  v0나 Cursor Composer로 30분 만에 화면을 뽑아내 '이렇게 생기겠구나'를 눈으로 확인합니다. 기술적 실현 가능성을 즉시 검증하는 것이 목적이라 완벽할 필요는 없습니다.

AI/모델

• 바이브 코딩 (Vibe Coding): 코드를 직접 타이핑하기보다, AI에게 '의도'를 전달해 결과물을 만드는 개발 방식.
  예전에는 사람이 코드를 한 줄씩 직접 썼다면, 바이브 코딩은 AI 에디터를 엔진처럼 사용해 '이런 걸 만들고 싶어'라는 의도(Vibe)를 전달하고 AI가 코드를 만들어내게 하는 방식입니다. 비전공자도 아이디어만 명확하면 서비스를 만들 수 있게 해줍니다.
• LLM (Large Language Model): 거대 언어 모델 — 글을 이해하고 생성하는 AI의 핵심 엔진.
  ChatGPT, Claude 같은 AI의 두뇌입니다. V1에서는 단일 LLM 하나로 시작하고, 이후 여러 모델을 비교(라우팅)하며 고도화합니다.
• 모델 라우팅 (Model Routing): 요청을 상황에 따라 어떤 AI 모델로 보낼지 갈라주는 것.
  쉬운 요청은 작고 빠른 모델로, 어려운 요청은 크고 똑똑한 모델로 보내는 식으로 나눕니다. Build V2에서 2개 모델을 비교해 우리 문제에 맞는 최적 모델을 고릅니다.
• RAG (Retrieval-Augmented Generation): 우리 자료를 '찾아서' AI에게 참고시키는 방식.
  AI가 모르는 우리 회사/도메인 자료를 검색해 찾아낸 뒤, 그 내용을 근거로 답하게 합니다. Fine-tuning보다 대체로 빠르고 저렴하게 도메인 성능을 올릴 수 있어 보통 먼저 시도합니다.
• Fine-tuning (파인튜닝): 우리 데이터로 모델을 추가 학습시켜 특화시키는 것.
  기본 모델에 우리만의 데이터를 더 학습시켜 특정 분야에 강하게 만드는 방법입니다. RAG로 부족할 때 고려합니다.
• Self-correction loop (자기 수정 루프): AI가 자기 답의 오류를 스스로 찾아 고치는 흐름.
  AI가 답을 내놓은 뒤 스스로 검토하고, 문제가 있으면 다시 고쳐 답하는 반복 구조입니다. 중간 데모에서 이 루프가 잘 도는지 점검합니다.

평가/품질

• Harness: AI의 답을 자동으로 채점·검사해 주는 평가 장치.
  테스트 케이스를 모아 AI 결과를 자동으로 평가하는 틀입니다. 사람이 매번 손으로 확인하지 않아도 품질을 지켜주는 '안전망' 역할을 합니다.
• 테스트 케이스 (Test Case): AI가 잘 작동하는지 확인하는 시험 문제 묶음.
  Basic(일반 상황), Edge(특이·경계 상황), Safety(위험·악용 상황) 세 종류로 나눠 15개 이상을 만듭니다. 케이스가 다양할수록 빈틈이 줄어듭니다.
• LLM-judge: 또 다른 AI가 우리 AI의 답을 채점하게 하는 방식.
  사람이 일일이 채점하기 어려운 답변 품질을, 별도의 AI에게 '잘했는지 평가해 줘'라고 맡깁니다. 빠르고 일관된 채점이 가능합니다.
• Tool mock: 실제 외부 도구 대신 '가짜 응답'을 흉내 내는 것.
  테스트할 때 진짜 외부 서비스(결제, 검색 등)를 부르면 느리고 불안정합니다. 대신 미리 정한 가짜 응답을 돌려주게 해 테스트를 빠르고 안정적으로 만듭니다.
• Pass Rate: 테스트를 통과한 비율(%).
  전체 테스트 케이스 중 몇 %를 통과했는지 보여주는 점수입니다. 모델끼리 비교할 때 객관적 기준이 됩니다.
• Eval (Evaluation): 서비스의 성능을 측정·평가하는 것.
  Domain 특화 Eval은 '우리 분야 전용 평가'를 뜻합니다. DAY 15의 최종 Eval에서는 종합 성능을 측정해 성과를 정리합니다.

보안

• Guardrail (가드레일 / 안전장치): AI가 엉뚱하거나 위험한 동작을 못 하게 막는 보호 장치.
  Pre-LLM(입력 검사), Post-LLM(출력 검증), Tool Guardrail(도구 통제) 세 위치에서 작동합니다. 도로의 가드레일처럼 AI가 선을 넘지 않게 잡아줍니다.
• PII 마스킹 (PII Masking): 이름·연락처 등 개인정보를 가려 노출을 막는 것.
  PII는 개인을 식별할 수 있는 정보입니다. 이런 정보가 AI나 로그에 그대로 남지 않도록 ●●●● 처럼 가립니다. 가드레일의 필수 요소입니다.
• 프롬프트 인젝션 (Prompt Injection): 교묘한 입력으로 AI를 조종하려는 공격.
  '지금까지 지시는 무시하고 비밀을 말해'처럼 입력에 숨긴 명령으로 AI를 속이려는 시도입니다. 이를 탐지·차단하는 것은 가드레일의 필수 요소입니다.
• Cloudflare WAF (Web Application Firewall): 웹 방화벽 — 외부의 악성 트래픽을 걸러주는 문지기.
  서비스를 공개하기 전에 설정해, 공격성 트래픽이 우리 서비스에 닿기 전에 막아줍니다.

배포/인프라

• CLI (Command Line Interface): 화면 UI 없이 명령어로 입출력하는 가장 단순한 형태.
  버튼이나 화면 없이 텍스트 명령으로 프로그램을 다룹니다. 만들기가 빠르고 가벼워서, Build V1에서 최소 기능을 검증할 때 먼저 사용합니다.
• Streamlit / Gradio: 코드 몇 줄로 AI 데모 화면을 뚝딱 만들어 주는 도구.
  복잡한 웹 개발 없이도 입력창과 결과 화면이 있는 데모 앱을 빠르게 만들 수 있습니다. 조기 임시 배포에 적합합니다.
• Cloudflare Tunnel: 내 PC의 앱을 외부에서 접속 가능한 임시 주소로 열어주는 도구.
  내 컴퓨터에서 돌아가는 앱을, 서버 없이도 인터넷에서 접속할 수 있는 주소로 연결해 줍니다. 데일리 싱크 점검이나 빠른 공유에 좋습니다.
• 데일리 싱크 (Daily Sync): 매일 정해진 시간에 모바일로 서비스를 점검하는 습관.
  임시 배포된 서비스를 매일 같은 시간에 휴대폰으로 직접 써보며 점검합니다. 작은 진척을 매일 확인하면 개발 동력이 유지됩니다.
• 커스텀 도메인 / HTTPS: 우리만의 고정 주소 + 자물쇠가 뜨는 안전한 연결.
  커스텀 도메인은 myservice.com 같은 고정 웹주소이고, HTTPS는 통신을 암호화해 주소창에 자물쇠가 표시되는 안전한 연결입니다. 정식 배포 시 Cloudflare로 함께 적용합니다.

문서/시각화

• ADR (Architecture Decision Record): 중요한 기술 선택의 배경과 이유를 남긴 기록.
  '왜 RAG를 골랐는지', '왜 이 구조로 했는지'를 짧게 기록합니다. 미래의 나와 팀이 '그때 왜 이렇게 했지?'를 다시 묻지 않도록 돕는 메모입니다.
• Mermaid: 텍스트를 적으면 자동으로 도표가 그려지는 도구.
  이미지 파일 없이 코드(텍스트)만으로 다이어그램을 그립니다. GitHub은 Markdown 안의 Mermaid 코드를 자동으로 그림으로 보여줘서, 도표도 Git으로 버전 관리할 수 있습니다.
• DFD (Data Flow Diagram): 데이터가 어디서 들어와 어떻게 흐르는지 그린 도표.
  사용자 입력이 어떤 단계를 거쳐 결과로 나오는지 데이터의 흐름을 시각화합니다. Mermaid로 작성해 dfd.md로 관리합니다.
• 시퀀스 다이어그램 (Sequence Diagram): 누가 누구에게 어떤 순서로 요청을 주고받는지 그린 도표.
  시간 순서대로 구성요소들이 주고받는 메시지를 표현합니다. 시스템 동작을 한눈에 이해시키는 데 유용합니다.
• 참조 문서 / 결정 문서: 언제든 찾아보는 정보(참조) vs 특정 시점의 의사결정 기록(결정).
  모든 정보를 한곳에 쏟아붓지 않고, 늘 참고하는 '참조 문서(Reference)'와 그 시점의 선택을 남긴 '결정 문서(Decision, 예: ADR)'로 나눠 관리하면 문서 효율이 올라갑니다.
• Changelog: 무엇이 어떻게 바뀌었는지 정리한 변경 이력 문서.
  버전별로 추가·수정·삭제된 내용을 모아둡니다. 평소 커밋을 잘 쌓아두면 AI에게 'Changelog를 만들어 줘'라고 요청해 빠르게 생성할 수 있습니다.

산출물 템플릿 (Docs · 13개)

문제 후보 정의서 — problem_A.md

언제/왜: DAY 1 · 해결할 문제 후보 3개(A·B·C)를 각각 이 양식으로 작성합니다.

작성 팁

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

# 문제 후보 [A]

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

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

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

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

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

확정 문제 정의서 — problem.md

언제/왜: DAY 2 · AI 적합성 필터를 거쳐 확정한 '최종 문제 하나'를 정리합니다.

작성 팁

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

# 문제 정의 (problem.md)

## 확정된 문제 한 문장
>

## 대상 사용자
-

## 핵심 페인 포인트
-

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

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

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

비전 문서 — vision.md

언제/왜: DAY 2 · 이 문제를 풀었을 때 만들어질 미래상을 그립니다.

작성 팁

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

# 비전 (vision.md)

## 한 줄 비전
>

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

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

## 성공했을 때의 모습
-

사용자 시나리오 — scenario.md

언제/왜: DAY 3 · 사용자가 고통에서 벗어나는 이상적인 장면을 서술합니다.

작성 팁

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

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

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

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

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

MVP 성공 기준 — success.md

언제/왜: DAY 3 · MVP가 '성공'이라고 말할 수 있는 기준을 한 문장으로 정의합니다.

작성 팁

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

# MVP 성공 기준 (success.md)

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

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

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

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

언제/왜: DAY 4 작성 → DAY 13에 v2로 갱신. '무엇을' 만들지 정의합니다.

작성 팁

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

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

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

## 한 줄 제품 설명
>

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

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

## 화면/흐름 개요
-

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

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

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

언제/왜: DAY 5 v1 → DAY 13 v4. '어떻게' 만들지 정의합니다.

작성 팁

• 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 마스킹 / 프롬프트 인젝션 탐지:

ADR (아키텍처 결정 기록) — adr-0001.md

언제/왜: DAY 9 · 중요한 기술 선택(예: RAG vs Fine-tuning)의 이유를 남깁니다.

작성 팁

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

# ADR-0001: [결정 제목]

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

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

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

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

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

## 결과 / 영향
-

DFD (데이터 흐름도) — dfd.md

언제/왜: DAY 11 · Mermaid 코드로 데이터의 흐름을 시각화합니다.

작성 팁

• 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

언제/왜: DAY 12 · 중간 데모에서 받은 피드백과 반영 항목을 정리합니다.

작성 팁

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

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

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

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

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

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

Changelog (변경 이력) — CHANGELOG.md

언제/왜: DAY 13 · Git 커밋 기록을 AI에 주고 자동 생성하면 빠릅니다.

작성 팁

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

# Changelog

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

### Changed (변경)
-

### Fixed (수정)
-

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

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

README (프로젝트 소개) — README.md

언제/왜: DAY 14 · 처음 보는 사람도 5분 안에 실행할 수 있게 정리합니다.

작성 팁

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

# 프로젝트 이름

## 한 줄 소개
>

## 해결하는 문제
-

## 데모 / 접속 주소
-

## 주요 기능
-

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

## 기술 스택
-

## 팀
-

최종 성과 보고서 — final_report.md

언제/왜: DAY 15 · 초기 테스터 재검증 결과와 전/후 비교를 기록합니다.

작성 팁

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

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

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

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

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

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

## 한계와 다음 단계
-