66~71일차 4단계 정리 추가, 바이브 코딩 진행 문서 05-VIBE-CODING으로

2026-10-27 23:28:09 +09:00
1 parent bb719d81fa
commit 3a8da78da3
@@ -0,0 +1,139 @@
+# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
+
+- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY66-OVERVIEW.md)
+- 이 시간이 끝나면: 오늘 1~3단계에서 한 일(결과 먼저 · JSON으로 받기 · 반복과 검증)이 **왜 필요했는지**, 숫자로 **무엇이 좋아졌는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
+- 숫자: 수업 준비 때 정답 워크플로우를 실행한 값입니다 (2026-10-18, gpt-4.1-mini, 1회. 강사의 수업 준비 기록).
+
+```mermaid
+flowchart LR
+  A["1. 오늘 한 장"] --> B["2. 왜 결과 먼저인가"] --> C["3. 효과를 숫자로"] --> D["4. 회사에서 부르는 이름"]
+  D --> E["5. 산업별 응용"] --> F["6. 하지 말아야 할 때"] --> G["7. 직무 · 면접"] --> H["8. 최종 프로젝트로"]
+```
+
+## 0. 이 시간 (35분)
+
+| 시간 | 절 | 하는 일 |
+| --- | --- | --- |
+| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 "결과 먼저"인가 |
+| 17:15~17:20 | 3 | 오늘 숫자로 본 효과 |
+| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
+| 17:28~17:33 | 6 | 하지 말아야 할 때 |
+| 17:33~17:40 | 7 · 8 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
+| 17:40~17:45 | 9 · 토론 | 다음 일차와의 연결, 질문 둘 |
+
+## 1. 오늘 한 장
+
+| 단계 | 한 일 | 오늘 숫자 |
+| --- | --- | --- |
+| 1단계 · 결과 먼저 | 결과 모양을 먼저 정하고, CLI 에이전트에게 요청문(프롬프트)으로 회의록 요약 워크플로우를 만들게 함 | 빈 회의록 · 제목 없음 `lab01-challenge` 예제 상태 **1/4** → **4/4** |
+| 2단계 · JSON으로 받기 | LLM 답을 JSON으로 받아 파싱 · 변환, 참석자 뽑기 | 참석자 과제 처음 **3/4** → 지시문 보강 **4/4**, `lab02` 6/6 |
+| 3단계 · 반복과 검증 | 할 일마다 항목으로 나눠 처리(반복 · 병렬), 결과 검증, 확인 필요 표시 | 어려운 회의록 7개 예제 상태 **6/7** → **7/7** |
+| 바이브 코딩 | 터미널에서 HTTP를 보내고 응답을 보는 `turl` | 오늘 만든 웹훅을 이 도구로 부름 |
+
+한 문장으로: **원하는 결과의 모양을 먼저 정하고, LLM의 답을 그 모양(JSON)으로 받아, 코드로 확인한다.**
+
+## 2. 왜 "결과 먼저"인가
+
+| | 화면에서 노드부터 그리기 | 결과 먼저 |
+| --- | --- | --- |
+| 시작 | "어떤 노드가 필요하지?" | "끝에 무엇이 나와야 하지?" (`{title, summary, actions}`) |
+| 완료 판단 | 눈으로 "된 것 같다" | 테스트 케이스가 통과 |
+| 에이전트에게 | 막연한 부탁 | 모양이 정해진 요청문(프롬프트) |
+| 다음 시스템과 | 붙일 때마다 다시 맞춤 | 약속한 모양 그대로 |
+
+- LLM은 문장을 잘 쓰지만, 다음 시스템(메일 · 일정 · 티켓)은 **정해진 모양**만 읽습니다. 그래서 "어떤 칸에 무엇이 오나"를 먼저 정하는 것이 자동화의 시작입니다.
+- 빈 회의록에 LLM이 "회의 내용이 없으므로 …"라고 **친절하게 200으로** 답한 것이 오늘의 교훈입니다. 오류처럼 보이지 않는 실패는 결과 모양과 테스트가 있어야 잡힙니다 (빈 회의록 → 400).
+
+## 3. 효과를 숫자로
+
+| 무엇 | 전 | 후 | 바꾼 것 |
+| --- | --- | --- | --- |
+| 빈 회의록 · 제목 없음 (`lab01-challenge`) | 1/4 | **4/4** | 입력 검사(400), 제목 없으면 `회의` |
+| 참석자 뽑기 (`lab02-challenge`) | 3/4 (할 일 4개 → 3개로 줄어듦) | **4/4** | 지시문 보강 |
+| 어려운 회의록 7개 | 6/7 | **7/7** | 두 갈래 + 확인 필요 + 참석자 |
+| 앞의 테스트 (회귀) | | `lab01` 3/3 · `lab02` 6/6 · `lab03` 5/5 | 새 기능이 앞 기능을 깨지 않음 |
+
+- 참석자를 더하자 **할 일이 4개에서 3개로 줄어든** 것이 중요합니다. 하나를 고치면 다른 곳이 바뀝니다. 그래서 고칠 때마다 **앞의 테스트도 다시** 돌립니다.
+
+## 4. 회사에서는 같은 생각을 이렇게 부른다
+
+| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
+| --- | --- | --- |
+| 결과 모양부터 정하기 | 계약 우선 설계 (contract-first), 출력 스키마 | JSON Schema, OpenAPI |
+| LLM 답을 JSON으로 | 구조화된 출력 (structured output) | 모델의 JSON 모드 · 스키마 지정, 출력 파서 |
+| 파싱 실패 · 빈 입력 처리 | 입력 검증, 방어적 파싱 | 스키마 검증, 400 오류 |
+| 할 일마다 나눠 처리 | 팬아웃 · 맵 (map), 배치 처리 | n8n 항목(item), 작업 큐 |
+| 테스트 케이스로 확인 | 회귀 테스트, 평가 세트 | 테스트 파일, CI |
+| 요청문(프롬프트)으로 만들게 함 | AI 코딩 에이전트 활용 | Codex · Claude Code · Antigravity |
+
+## 5. 산업별 응용 (예)
+
+아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (특정 회사 사례가 아니라 흔한 모양).
+
+| 업무 | 오늘의 무엇을 | 이렇게 |
+| --- | --- | --- |
+| 영업 회의록 → CRM | 결과 먼저 · JSON | `{고객사, 다음 단계, 담당, 기한}`로 받아 CRM에 그대로 등록 |
+| 고객 문의 메일 분류 | JSON · 확인 필요 | `{분류, 긴급도, 확인 필요}`, 확인 필요면 사람에게 |
+| 계약서 검토 메모 | 반복 · 병렬 | 조항마다 항목으로 나눠 같은 검사를 동시에 |
+| 사내 회의 (오늘) | 전부 | 빈 회의록은 400, 제목 없으면 `회의`, 할 일 · 참석자 |
+
+**토론 거리**: 내 업무의 "회의록"에 해당하는 문서 하나를 골라, 결과 JSON의 칸을 먼저 적어 봅니다.
+
+## 6. 하지 말아야 할 때 (흔한 실수)
+
+| 하기 쉬운 일 | 왜 위험한가 | 대신 |
+| --- | --- | --- |
+| 노드부터 그리고 결과는 나중에 | 완료를 판단할 기준이 없음 | 결과 모양 · 테스트부터 |
+| LLM 답을 문장 그대로 다음 시스템에 | 매번 모양이 달라 붙일 수 없음 | JSON으로 받고 파싱 |
+| 빈 입력도 LLM에게 보냄 | "내용이 없으므로…" 같은 200 답 | 코드로 먼저 400 |
+| 고친 기능의 테스트만 돌림 | 다른 기능이 몰래 깨짐 (할 일 4 → 3) | 앞의 테스트도 함께 |
+| 에이전트의 "다 됐다"를 믿음 | 실제로는 통과하지 않을 수 있음 | 내가 `push` · `test` |
+
+## 7. 직무와 면접
+
+오늘 한 일은 **AI · LLM 애플리케이션 엔지니어, 업무 자동화(RPA · 노코드) 담당, 백엔드 엔지니어**가 날마다 하는 일입니다. 채용 공고의 "LLM 출력 구조화", "업무 자동화 워크플로우", "프롬프트 설계"가 오늘 내용입니다.
+
+<details><summary>1. "LLM 답을 다른 시스템에 넘길 때 무엇을 조심하나요?"</summary>
+
+결과 모양을 먼저 정하고 LLM에게 그 모양의 JSON으로 답하게 한 뒤, 코드로 파싱해 칸이 다 있는지 확인합니다. 빈 입력은 LLM에 보내기 전에 400으로 막습니다. 오늘 빈 회의록 · 제목 없음 케이스가 1/4에서 4/4가 됐습니다.
+</details>
+
+<details><summary>2. "기능을 하나 더했더니 다른 게 깨졌다면?"</summary>
+
+그래서 앞의 테스트를 함께 돌립니다. 오늘 참석자를 더하자 할 일이 4개에서 3개로 줄었고, 테스트가 바로 잡아 지시문을 보강해 4/4로 고쳤습니다. 기능마다 테스트 파일을 두고, 고칠 때마다 전부 다시 돌립니다.
+</details>
+
+<details><summary>3. "AI 코딩 에이전트로 만든 것을 어떻게 믿나요?"</summary>
+
+에이전트에게는 결과 모양과 테스트 파일을 요청문(프롬프트)에 적어 주고, push와 test는 내가 직접 합니다. "다 됐다"는 말이 아니라 테스트 통과 수로 판단합니다.
+</details>
+
+## 8. 최종 프로젝트로 가져갈 것
+
+- [ ] 워크플로우마다 결과 JSON 모양을 먼저 적는다 (칸 이름 · 값의 종류)
+- [ ] LLM 답은 JSON으로 받고 코드로 파싱 · 확인한다
+- [ ] 빈 입력 · 잘못된 입력은 LLM 앞에서 400
+- [ ] 정상 · 경계 · 어려운 케이스가 든 테스트 파일
+- [ ] 고칠 때마다 앞의 테스트도 함께 돌린다
+- [ ] 요청문(프롬프트)에 결과 모양 · 테스트 파일을 적는다
+
+## 9. 다음 일차와의 연결
+
+| 일차 | 오늘의 무엇을 잇나 |
+| --- | --- |
+| 67 | Agent가 Tool로 사내 데이터를 읽고 답함 — 결과 모양 · 테스트 그대로, 출처(`sources`)가 더해짐 |
+| 68 | 요청 하나에 업무 여럿 — 오늘의 "항목으로 나누기"를 업무 단위로 |
+| 72 | 단계별 시간 재기 — 오늘 병렬로 처리한 것이 실제로 얼마나 빨랐나 |
+
+## 토론 (5분)
+
+1. 오늘 결과 JSON에 칸을 하나 더 넣는다면 무엇을 넣고, 그 칸은 누가(LLM · 코드) 채워야 할까요?
+2. 빈 회의록에 "내용이 없습니다"라고 200으로 답하는 것과 400으로 거절하는 것, 내 업무에서는 무엇이 맞을까요?
+
+## 정리
+
+- [ ] 결과 먼저: 끝에 나올 모양을 먼저 정한다
+- [ ] LLM 답은 JSON으로, 코드가 확인한다 (빈 입력은 앞에서 400)
+- [ ] 반복 · 병렬로 항목마다 같은 처리, 확인 필요는 표시
+- [ ] 효과는 테스트 통과 수로 (1/4 → 4/4, 6/7 → 7/7), 고칠 때마다 앞의 테스트도
+- [ ] 최종 프로젝트에 체크리스트 6개를 가져간다
@@ -1,5 +1,7 @@
 # 7·8교시 · 바이브 코딩 (`turl`)

+> 8교시 순서: 발표 10분 → [4단계 정리](04-STAGE4-WRAPUP.md) 35분 → 다음 일차 예고 5분. 아래의 강사 정리 · 강사 바이브 코딩 · 팁은 4단계 정리 안에서 짧게 다루거나 시간이 남으면 합니다.
+
 - 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
 - 과제: [VIBE-Q-TURL](../../Last3Mon/66/VIBE-Q-TURL.md)
 - **오늘부터 7·8교시는 퀴즈 대신 매일 프로그램 하나를 바이브 코딩으로 만듭니다.** 오늘은 `turl`: curl을 터미널 화면(TUI)으로. 오늘 만든 `my-meeting` 웹훅을 이 도구로 불러 봅니다.
@@ -27,8 +27,8 @@
 | - | 13:00~14:00 | 점심 |  |
 | 5 | 14:00~14:50 | 3단계 · 반복·병렬 제어 구조와 검증, Lab 03 예제 1·2 | [3단계](03-STAGE3-ITEMS-PARALLEL-AND-VERIFY.md), [Lab 03](../../Last3Mon/66/LAB-03-Q-ITEMS-AND-PARALLEL.md) |
 | 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (어려운 회의록으로 완성) · 풀이 | [Lab 03](../../Last3Mon/66/LAB-03-Q-ITEMS-AND-PARALLEL.md) |
-| 7 | 16:00~16:50 | 바이브 코딩 · `turl` 만들기 (각자) | [VIBE-Q-TURL](../../Last3Mon/66/VIBE-Q-TURL.md), [진행](04-VIBE-CODING.md) |
-| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 67일차 예고 | [진행](04-VIBE-CODING.md) |
+| 7 | 16:00~16:50 | 바이브 코딩 · `turl` 만들기 (각자) | [VIBE-Q-TURL](../../Last3Mon/66/VIBE-Q-TURL.md), [진행](05-VIBE-CODING.md) |
+| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 다음 일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |

 ```mermaid
 flowchart LR
@@ -44,4 +44,5 @@ flowchart LR
 | `01-STAGE1-VIBE-N8N-AND-RESULT-FIRST.md` | 무엇이 바뀌나, 워크플로우는 JSON, AGENTS.md와 flow.py, 요청문 다섯 가지, 결과 먼저, 항목 흐름 |
 | `02-STAGE2-JSON-AND-PARSE.md` | LLM의 답은 글자, 모양 알려 주기, 코드로 읽기, 빈칸은 코드가, 하나 바꾸면 다른 것도 바뀐다 |
 | `03-STAGE3-ITEMS-PARALLEL-AND-VERIFY.md` | 1 → N → 1 (펼치기 · 항목마다 · 모으기), 빈 목록, 두 갈래와 Merge, 설계와 실행, 테스트로 완성 |
-| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (turl), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
+| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 면접 · 최종 프로젝트 체크리스트 |
+| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (turl), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
@@ -0,0 +1,139 @@
+# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
+
+- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY67-OVERVIEW.md)
+- 이 시간이 끝나면: 오늘 1~3단계에서 한 일(Agent와 Tool · 사내 데이터 연계 · 실행 결과 검증)이 **왜 필요했는지**, 숫자로 **무엇이 좋아졌는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
+- 숫자: 수업 준비 때 정답 워크플로우를 실행한 값입니다 (2026-10-17, gpt-4.1-mini. 강사의 수업 준비 기록).
+
+```mermaid
+flowchart LR
+  A["1. 오늘 한 장"] --> B["2. 왜 Agent에게<br/>Tool을 주나"] --> C["3. 효과를 숫자로"] --> D["4. 회사에서 부르는 이름"]
+  D --> E["5. 산업별 응용"] --> F["6. 하지 말아야 할 때"] --> G["7. 직무 · 면접"] --> H["8. 최종 프로젝트로"]
+```
+
+## 0. 이 시간 (35분)
+
+| 시간 | 절 | 하는 일 |
+| --- | --- | --- |
+| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 Agent에게 Tool을 주나 |
+| 17:15~17:20 | 3 | 오늘 숫자로 본 효과 |
+| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
+| 17:28~17:33 | 6 | 하지 말아야 할 때 |
+| 17:33~17:40 | 7 · 8 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
+| 17:40~17:45 | 9 · 토론 | 다음 일차와의 연결, 질문 둘 |
+
+## 1. 오늘 한 장
+
+| 단계 | 한 일 | 오늘 숫자 |
+| --- | --- | --- |
+| 1단계 · Agent와 Tool | IT 문의 Agent가 FAQ Tool로 답하고, 모르면 모른다고 · 출처(`sources`) | `lab01-challenge` **15/15** (5번 반복), `lab01` 6/6 |
+| 2단계 · 사내 데이터 연계 | 접수 현황 Tool, **본인 접수 건만** (`requester` ← 웹훅의 `user`) | `lab02-challenge` 예제 상태 **4/8** → **20/20**, `lab02` 8/8 |
+| 3단계 · 실행 결과 검증 | 어려운 테스트를 쓰고, 실패를 찾아 고치기 (`user` 필수 400, 번호 형식 정규화) | 어려운 케이스 예제 상태 **18/21** → **35/35** (5번 반복), `lab03` 21/21 |
+| 바이브 코딩 | 명령어 사용 예를 보여 주는 `tman` | |
+
+한 문장으로: **LLM에게 사내 데이터를 Tool로 주되, 틀리면 안 되는 값은 시스템이 정하고, 실행 결과는 테스트로 검증한다.**
+
+## 2. 왜 Agent에게 Tool을 주나
+
+| | LLM 혼자 | Agent + Tool |
+| --- | --- | --- |
+| 아는 것 | 학습할 때까지의 일반 지식 | 지금 회사의 FAQ · 접수 건 |
+| 모르는 것을 물으면 | 그럴듯하게 지어내기 쉬움 | Tool 결과에 없으면 "모른다" |
+| 출처 | 없음 | `sources`에 FAQ 번호 |
+| 위험 | 틀린 답 | **틀린 답 + 남의 데이터 조회** (권한) |
+
+- Tool을 주면 Agent는 **말만 하는 것이 아니라 일을 합니다.** 그래서 "누구의 데이터를 볼 수 있나" 같은 값은 LLM에게 맡기지 않고 웹훅이 받은 값으로 정했습니다 (본인 접수 건만, 4/8 → 20/20).
+- LLM 답은 매번 조금씩 다르므로, 같은 테스트를 **여러 번(5번)** 돌려 흔들리지 않는지 봤습니다.
+
+## 3. 효과를 숫자로
+
+| 무엇 | 전 | 후 | 바꾼 것 |
+| --- | --- | --- | --- |
+| 모르면 모른다고 · 출처 (`lab01-challenge`) | | **15/15** (5번 반복) | 지시문 · `sources`는 Tool 결과에서 |
+| 본인 접수 건만 (`lab02-challenge`) | 4/8 | **20/20** | `requester`를 LLM이 아니라 `body.user`에서 |
+| 어려운 케이스 7개 | 18/21 (`user` 없이 보내기 0/3) | **35/35** (5번 반복) | `user` 필수(400), 번호 형식 정규화 |
+| 앞의 테스트 | | `lab01` 6/6 · `lab02` 8/8 · `lab03` 21/21 | |
+
+- 어려운 케이스에서 실패한 셋은 **`user` 없이 보내기**였습니다. 정상 질문만 시험하면 이런 구멍을 못 찾습니다. 테스트는 "되는 것"이 아니라 **"실패를 찾는 일"**입니다.
+
+## 4. 회사에서는 같은 생각을 이렇게 부른다
+
+| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
+| --- | --- | --- |
+| Agent가 Tool을 골라 부름 | Tool 호출 (function calling), 에이전트 | n8n AI Agent, LLM의 tool/function calling, MCP |
+| 사내 데이터를 읽어 답 | 데이터 연계, 근거 기반 답변 | 사내 API, 데이터베이스, (71일차) RAG |
+| `requester`를 시스템이 | 인증 · 인가, 최소 권한 | SSO · OAuth, 역할 기반 접근(RBAC) |
+| 출처 `sources` | 인용, 추적성 | 답변에 문서 id · 링크 |
+| 실행 결과 검증 · 어려운 테스트 | 회귀 테스트, 적대적 테스트 | 테스트 파일, CI, LLM 평가 도구 |
+| 같은 테스트 5번 | 비결정성 측정, 흔들림 확인 | 반복 실행 (`--repeat`) |
+
+## 5. 산업별 응용 (예)
+
+아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (특정 회사 사례가 아니라 흔한 모양).
+
+| 업무 | 오늘의 무엇을 | 이렇게 |
+| --- | --- | --- |
+| 쇼핑몰 주문 문의 | Tool · 본인 것만 | 주문 조회 Tool, 주문자는 로그인 정보로, 남의 주문은 API가 403 |
+| 사내 인사 문의 | 모르면 모른다고 · 출처 | 규정 Tool 결과에 없으면 "인사팀 연결", 답에 규정 번호 |
+| 병원 예약 안내 | 데이터 연계 · 검증 | 예약 조회 Tool, 환자 확인은 시스템이, 어려운 테스트(없는 예약 번호 · 형식이 다른 번호) |
+| 사내 IT 문의 (오늘) | 전부 | FAQ · 접수 건 Tool, 본인 건만, `user` 필수, 번호 정규화 |
+
+**토론 거리**: 내 회사의 AI 기능에서 "LLM이 정하면 안 되는 값" 하나를 찾아 봅니다.
+
+## 6. 하지 말아야 할 때 (흔한 실수)
+
+| 하기 쉬운 일 | 왜 위험한가 | 대신 |
+| --- | --- | --- |
+| 사용자 이름을 LLM이 질문에서 읽게 | "나는 박서연이야"로 남의 데이터를 봄 | 웹훅 · 로그인 정보에서 |
+| 출처를 LLM이 쓰게 | 없는 번호를 지어냄 | Tool 결과에서 코드가 |
+| 정상 질문만 테스트 | `user` 없음 같은 구멍을 못 찾음 | 어려운 · 이상한 입력도 |
+| 한 번 통과로 끝 | LLM 답이 흔들림 | 5번 반복 |
+| 테스트를 통과시키려고 기대를 바꿈 | 테스트가 의미를 잃음 | 워크플로우를 고친다 |
+
+## 7. 직무와 면접
+
+오늘 한 일은 **AI · LLM 애플리케이션 엔지니어, AI 에이전트 개발자, 백엔드 엔지니어, QA · 테스트 엔지니어**가 날마다 하는 일입니다. 채용 공고의 "Tool calling", "에이전트 설계", "LLM 테스트 · 평가"가 오늘 내용입니다.
+
+<details><summary>1. "Agent에게 사내 데이터를 줄 때 무엇을 조심하나요?"</summary>
+
+틀리면 안 되는 값은 LLM이 정하지 않게 합니다. 오늘 접수 현황 Tool의 `requester`를 LLM이 아니라 웹훅의 `user`에서 받게 하자 본인 접수 건 테스트가 4/8에서 20/20이 됐습니다. 남의 건인지는 데이터 쪽이 403으로 판단합니다.
+</details>
+
+<details><summary>2. "LLM이 모르는 것을 지어내지 않게 하려면?"</summary>
+
+Tool 결과로만 답하게 하고, 결과에 없으면 정해진 "모른다" 답을 하게 합니다. 출처는 Tool 결과에서 코드가 붙입니다. 5번 반복해 15/15로 흔들리지 않는 것을 확인했습니다.
+</details>
+
+<details><summary>3. "테스트는 어떻게 쓰나요?"</summary>
+
+정상 케이스만이 아니라 실패를 찾는 케이스를 씁니다. 오늘 어려운 케이스 7개를 써 보니 `user` 없이 보내는 셋이 실패했고(18/21), `user` 필수 400과 번호 형식 정규화로 고쳐 35/35(5번 반복)가 됐습니다.
+</details>
+
+## 8. 최종 프로젝트로 가져갈 것
+
+- [ ] Agent에게 줄 Tool 목록과 Tool마다 하는 일 · 입력 · 결과
+- [ ] 권한이 걸린 값(사용자 · 계정)은 시스템이 정한다, 데이터 쪽이 403
+- [ ] 출처는 Tool 결과에서 코드가 붙인다
+- [ ] 모를 때의 정해진 답
+- [ ] 어려운 테스트(빠진 입력 · 이상한 형식 · 남의 데이터)를 쓰고 여러 번 돌린다
+
+## 9. 다음 일차와의 연결
+
+| 일차 | 오늘의 무엇을 잇나 |
+| --- | --- |
+| 68 | Agent 여럿 — 오늘의 IT Agent가 여러 전문 Agent 중 하나가 됨 |
+| 69 | 검토자 Agent — 오늘 코드로 한 검증을 역할로 나눔 |
+| 71 | RAG — 오늘의 FAQ Tool 자리에 문서 검색이 들어감 |
+| 73 | 보안 — 오늘의 "본인 건만"을 공격으로 시험 |
+
+## 토론 (5분)
+
+1. 오늘 IT Agent에게 Tool을 하나 더 준다면 무엇이고, 그 Tool에서 LLM이 정하면 안 되는 값은?
+2. 테스트를 5번 반복했는데 4번만 통과한다면, 그 기능을 내보내도 될까요?
+
+## 정리
+
+- [ ] Agent + Tool: 지금의 사내 데이터로 답하고, 출처를 남긴다
+- [ ] 틀리면 안 되는 값(누가 물었나)은 시스템이, 권한은 데이터 쪽이
+- [ ] 테스트는 실패를 찾는 일, LLM은 여러 번
+- [ ] 효과는 숫자로 (4/8 → 20/20, 18/21 → 35/35)
+- [ ] 최종 프로젝트에 체크리스트 5개를 가져간다
@@ -1,5 +1,7 @@
 # 7·8교시 · 바이브 코딩 (`tman`)

+> 8교시 순서: 발표 10분 → [4단계 정리](04-STAGE4-WRAPUP.md) 35분 → 다음 일차 예고 5분. 아래의 강사 정리 · 강사 바이브 코딩 · 팁은 4단계 정리 안에서 짧게 다루거나 시간이 남으면 합니다.
+
 - 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
 - 과제: [VIBE-Q-TMAN](../../Last3Mon/67/VIBE-Q-TMAN.md)
 - 66일차부터 7·8교시는 퀴즈 대신 **매일 프로그램 하나를 바이브 코딩**으로 만듭니다. 오늘은 `tman`: 명령어 사용 예(tldr 한국어)와 man을 탭으로 보여 주고, 설명을 한국어로 번역하는 TUI입니다.
@@ -29,8 +29,8 @@
 | - | 13:00~14:00 | 점심 |  |
 | 5 | 14:00~14:50 | 3단계 · 실행 결과 검증과 테스트, Lab 03 예제 1·2 | [3단계](03-STAGE3-VERIFY-AND-FIX.md), [Lab 03](../../Last3Mon/67/LAB-03-Q-VERIFY-AND-FIX.md) |
 | 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (어려운 테스트 쓰고 고치기) · 풀이 | [Lab 03](../../Last3Mon/67/LAB-03-Q-VERIFY-AND-FIX.md) |
-| 7 | 16:00~16:50 | 바이브 코딩 · `tman` 만들기 (각자) | [VIBE-Q-TMAN](../../Last3Mon/67/VIBE-Q-TMAN.md), [진행](04-VIBE-CODING.md) |
-| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 68일차 예고 | [진행](04-VIBE-CODING.md) |
+| 7 | 16:00~16:50 | 바이브 코딩 · `tman` 만들기 (각자) | [VIBE-Q-TMAN](../../Last3Mon/67/VIBE-Q-TMAN.md), [진행](05-VIBE-CODING.md) |
+| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 다음 일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |

 ```mermaid
 flowchart LR
@@ -46,4 +46,5 @@ flowchart LR
 | `01-STAGE1-VIBE-N8N-AGENT-AND-TOOL.md` | 워크플로우는 JSON 파일, 에이전트에게 주는 규칙(AGENTS.md), 요청문 쓰는 법, 정해진 흐름 vs Agent, Tool, 그럴듯한 답 vs 근거 있는 답 |
 | `02-STAGE2-DATA-TOOLS.md` | 데이터 API, HTTP Request Tool, `$fromAI`, 데이터 없음 처리, LLM이 정하면 안 되는 값과 권한 범위 |
 | `03-STAGE3-VERIFY-AND-FIX.md` | 테스트 케이스 = 업무 규칙, 입력 검증, 결과 검증과 담당자 연결, 반복 실행, 실패 → 원인 → 수정 루프 |
-| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tman), 발표, 강사 정리 포인트, 추가 바이브 코딩, 팁 |
+| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 면접 · 최종 프로젝트 체크리스트 |
+| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tman), 발표, 강사 정리 포인트, 추가 바이브 코딩, 팁 |
@@ -0,0 +1,138 @@
+# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
+
+- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY68-OVERVIEW.md)
+- 이 시간이 끝나면: 오늘 1~3단계에서 한 일(복합 업무 분석 · Multi-Agent 설계 · 검증과 장애 격리)이 **왜 필요했는지**, 숫자로 **무엇이 좋아졌고 무엇을 치렀는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
+- 숫자: 수업 준비 때 정답 워크플로우를 실행한 값입니다 (2026-10-18, gpt-4.1-mini, 1회. 강사의 수업 준비 기록).
+
+```mermaid
+flowchart LR
+  A["1. 오늘 한 장"] --> B["2. 왜 Agent를<br/>나누나"] --> C["3. 효과와 값을 숫자로"] --> D["4. 회사에서 부르는 이름"]
+  D --> E["5. 산업별 응용"] --> F["6. 하지 말아야 할 때"] --> G["7. 직무 · 면접"] --> H["8. 최종 프로젝트로"]
+```
+
+## 0. 이 시간 (35분)
+
+| 시간 | 절 | 하는 일 |
+| --- | --- | --- |
+| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 Agent를 나누나 |
+| 17:15~17:20 | 3 | 오늘 숫자로 본 효과와 값 |
+| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
+| 17:28~17:33 | 6 | 하지 말아야 할 때 |
+| 17:33~17:40 | 7 · 8 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
+| 17:40~17:45 | 9 · 토론 | 다음 일차와의 연결, 질문 둘 |
+
+## 1. 오늘 한 장
+
+| 단계 | 한 일 | 오늘 숫자 |
+| --- | --- | --- |
+| 1단계 · 복합 업무 분석 | 요청 하나를 업무 여럿으로 나누고, 업무마다 담당(`agent`) · 빠진 입력(`missing`)은 Code 규칙으로 | `lab01-challenge` 예제 상태 **0/4** → **4/4**, `lab01` 7/7 |
+| 2단계 · Multi-Agent 설계 | Router(코드가 나눠 보냄)로 만들고, Supervisor(Agent가 Agent를 Tool로 부름)로도 만들어 비교 | Router `lab02` **6/6**, Supervisor `lab02-challenge` 4/5 → 5/5 · 같은 테스트(`lab02`) **1/6**, 복합 요청 **9.6~10.8초** |
+| 3단계 · 검증과 장애 격리 | 한 Agent가 멈춰도 나머지 답은 내기, 어려운 테스트 | 회의록 Agent 꺼짐 `lab03-down` 예제 상태 **1/3**(500) → **3/3**, 어려운 케이스 5/7 → **7/7** |
+| 바이브 코딩 | n8n 워크플로우를 트리로 보여 주는 `tflow` (요청서 → SPEC 먼저) | |
+
+한 문장으로: **복합 요청은 먼저 업무로 나눠 분석하고, 업무마다 전문 Agent에 맡기되, 판단은 규칙으로 하고 하나가 멈춰도 전체가 멈추지 않게 한다.**
+
+## 2. 왜 Agent를 나누나
+
+| | Agent 하나가 다 | 업무별 Agent |
+| --- | --- | --- |
+| 지시문 | 모든 업무의 규칙이 한 덩어리 | 업무마다 짧고 분명 |
+| 고칠 때 | 한 곳을 고치면 다른 업무가 흔들림 | 그 Agent만 |
+| 멈출 때 | 전체가 멈춤 | 그 업무만 "지금 처리 못 함" (격리) |
+| 값 | 호출 한 번 | 나누고 · 모으는 일이 늘어남 |
+
+- **나누기는 LLM, 판단은 규칙.** 업무로 나누는 일은 글을 이해해야 하니 LLM이, "이 업무는 누가 맡나 · 무엇이 빠졌나"는 틀리면 안 되니 Code가 했습니다 (0/4 → 4/4).
+- **Router와 Supervisor는 값이 다릅니다.** Supervisor는 유연하지만 LLM이 다음 순서를 정하느라 느리고(복합 요청 9.6~10.8초), 같은 테스트에서 1/6이었습니다. 순서가 정해진 업무는 Router가 낫습니다.
+
+## 3. 효과와 값을 숫자로
+
+| 무엇 | 전 | 후 | 바꾼 것 |
+| --- | --- | --- | --- |
+| 업무마다 담당 · 빠진 입력 (`lab01-challenge`) | 0/4 | **4/4** | Code 규칙 |
+| Supervisor (`lab02-challenge`) | 4/5 | **5/5** | 지시문 고침 |
+| 회의록 Agent가 멈춤 (`lab03-down`) | 1/3 (복합 요청 500) | **3/3** | 장애 격리 (나머지 답은 냄) |
+| 어려운 케이스 7개 | 5/7 (`user` 없음, 공백만) | **7/7** | `user` 빠짐도 입력 필요, 공백 메시지 400 |
+
+**치른 값**: Supervisor로 만들면 같은 요청에 Router보다 LLM 호출이 늘고 시간이 9.6~10.8초까지 걸렸습니다. 나누는 구조는 **유연함과 속도 · 비용을 맞바꾸는** 선택입니다 (72 · 75일차에서 잽니다).
+
+## 4. 회사에서는 같은 생각을 이렇게 부른다
+
+| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
+| --- | --- | --- |
+| 요청을 업무로 나누기 | 의도 분석, 작업 분해 (task decomposition) | 분류 모델, LLM 분해 |
+| 코드가 나눠 보냄 | 라우터 패턴 (router) | n8n Switch · If, API 게이트웨이 |
+| Agent가 Agent를 부름 | 감독자 패턴 (supervisor), 오케스트레이터 | LangGraph, CrewAI, OpenAI Agents SDK, AutoGen |
+| 하나가 멈춰도 계속 | 장애 격리 (bulkhead), 우아한 저하 | 서킷 브레이커, 타임아웃 · 대체 경로 |
+| 분석표 다섯 칸 | 요구 분석, 업무 흐름 분석 | 유스케이스, BPMN |
+
+## 5. 산업별 응용 (예)
+
+아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (특정 회사 사례가 아니라 흔한 모양).
+
+| 업무 | 오늘의 무엇을 | 이렇게 |
+| --- | --- | --- |
+| 고객센터 통합 창구 | 업무 나누기 · Router | "환불하고 주소도 바꿔 주세요" → 환불 Agent · 배송 Agent, 빠진 주문 번호는 되묻기 |
+| 사내 총무 요청 | 분석표 · 빠진 입력 | 회의실 예약 · 택배 · 비품을 나눠, 회의실 이름이 없으면 `missing` |
+| 여행 예약 도우미 | Supervisor | 항공 · 숙소 · 일정 Agent를 감독 Agent가 순서 조정 (순서가 매번 다를 때) |
+| 사내 IT · 회의 (오늘) | 전부 | IT 문의 · 회의록 Agent, 회의록 Agent가 멈춰도 IT 답은 나감 |
+
+**토론 거리**: 내 업무에서 "한 문장에 업무 여럿"이 오는 창구를 하나 골라, 업무 · 담당 · 빠질 수 있는 입력을 적어 봅니다.
+
+## 6. 하지 말아야 할 때 (흔한 실수)
+
+| 하기 쉬운 일 | 왜 위험한가 | 대신 |
+| --- | --- | --- |
+| 무조건 Agent를 많이 | 호출 · 시간 · 비용만 늘어남 | 업무가 정말 다를 때만 나눔 |
+| 담당 · 빠진 입력도 LLM이 | 같은 요청에 매번 다른 판단 | 규칙(Code)으로 |
+| 순서가 정해진 일을 Supervisor로 | 느리고 흔들림 (1/6, 10초) | Router |
+| 하나가 멈추면 500 | 멀쩡한 업무까지 답을 못 함 | 장애 격리, 멈춘 업무만 안내 |
+| 정상 요청만 테스트 | `user` 없음 · 공백 같은 구멍 | 어려운 케이스 |
+
+## 7. 직무와 면접
+
+오늘 한 일은 **AI 에이전트 · 멀티 에이전트 시스템 개발자, AI 서비스 기획자, 백엔드 · 플랫폼 엔지니어**가 날마다 하는 일입니다. 채용 공고의 "멀티 에이전트 설계", "에이전트 오케스트레이션", "장애 대응 설계"가 오늘 내용입니다.
+
+<details><summary>1. "멀티 에이전트를 언제 쓰나요?"</summary>
+
+요청 하나에 성격이 다른 업무가 섞일 때 씁니다. 먼저 업무로 나누는 분석을 하고, 업무마다 전문 Agent를 둡니다. 다만 담당 · 빠진 입력 같은 판단은 Code 규칙으로 해서 0/4를 4/4로 만들었습니다. 무조건 나누지 않고, 나누는 값(호출 · 시간)을 같이 봅니다.
+</details>
+
+<details><summary>2. "Router와 Supervisor 중 무엇을 고르나요?"</summary>
+
+순서가 정해져 있으면 Router입니다. 오늘 같은 업무를 Supervisor로 만들자 같은 테스트에서 1/6, 복합 요청이 9.6~10.8초였습니다. Supervisor는 순서가 매번 달라 LLM이 정해야 할 때 씁니다.
+</details>
+
+<details><summary>3. "Agent 하나가 장애면 어떻게 하나요?"</summary>
+
+장애를 격리합니다. 오늘 회의록 Agent를 꺼 보니 처음에는 복합 요청 전체가 500(1/3)이었고, 멈춘 업무만 "지금 처리 못 함"으로 두고 나머지 답은 내게 고쳐 3/3이 됐습니다.
+</details>
+
+## 8. 최종 프로젝트로 가져갈 것
+
+- [ ] 복합 요청의 분석표 (업무 · 담당 · 입력 · 빠질 수 있는 것 · 관계)
+- [ ] 나누기는 LLM, 판단(담당 · 빠진 입력)은 규칙
+- [ ] Router와 Supervisor 중 고른 까닭 (순서가 정해졌나, 시간 · 호출 수)
+- [ ] Agent 하나가 멈췄을 때의 테스트와 결과 (장애 격리)
+- [ ] 어려운 케이스 (빠진 입력 · 공백 · 업무가 섞인 요청)
+
+## 9. 다음 일차와의 연결
+
+| 일차 | 오늘의 무엇을 잇나 |
+| --- | --- |
+| 69 | 역할 분리 — 업무별 Agent에서 역할별 Agent(작성자 · 검토자 · 정리자)로 |
+| 70 | 템플릿 · 모듈 — 비슷한 Agent를 복사하지 않고 재사용 |
+| 72 | 성능 — Supervisor가 느렸던 까닭을 단계별 시간으로 |
+| 75 | 비용 — Agent 수 · 호출 수를 토큰과 단가로 |
+
+## 토론 (5분)
+
+1. 오늘 만든 Agent 중 하나를 합친다면 무엇을 합치고, 무엇을 잃을까요?
+2. 내 업무에서 Agent 하나가 멈췄을 때 "나머지 답은 낸다"가 맞을까요, "전부 멈춘다"가 맞을까요?
+
+## 정리
+
+- [ ] 복합 요청은 분석부터: 업무 · 담당 · 빠진 입력
+- [ ] 나누기는 LLM, 판단은 규칙 (0/4 → 4/4)
+- [ ] Router와 Supervisor는 유연함과 속도 · 비용의 맞바꿈 (Supervisor 1/6 · 10초)
+- [ ] 하나가 멈춰도 전체는 멈추지 않게 (1/3 → 3/3)
+- [ ] 최종 프로젝트에 체크리스트 5개를 가져간다
@@ -1,5 +1,7 @@
 # 7·8교시 · 바이브 코딩 (`tflow`)

+> 8교시 순서: 발표 10분 → [4단계 정리](04-STAGE4-WRAPUP.md) 35분 → 다음 일차 예고 5분. 아래의 강사 정리 · 강사 바이브 코딩 · 팁은 4단계 정리 안에서 짧게 다루거나 시간이 남으면 합니다.
+
 - 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
 - 과제: [VIBE-REQ-TFLOW](../../Last3Mon/68/VIBE-REQ-TFLOW.md)(요청서) → 학생이 직접 쓰는 `SPEC.md` → [VIBE-Q-TFLOW](../../Last3Mon/68/VIBE-Q-TFLOW.md)(요구 · 단계)와 비교 → 만들기 → 수업 뒤 `VIBE-A-TFLOW.md` 공개
 - **오늘부터 바뀐 점**: 지난 이틀 VIBE-Q를 통째로 에이전트에게 주고 "만들어 줘"가 많았습니다. 그러면 결과를 판단할 기준이 학생에게 없습니다. 오늘은 사람의 말(요청서)을 **확인할 수 있는 요구**로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다.
@@ -19,8 +19,8 @@
 | - | 13:00~14:00 | 점심 |  |
 | 5 | 14:00~14:50 | 3단계 · 검증과 장애 격리, Lab 03 예제 1·2 | [3단계](03-STAGE3-VERIFY-AND-SCALE.md), [Lab 03](../../Last3Mon/68/LAB-03-Q-VERIFY-AND-ISOLATE.md) |
 | 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (어려운 테스트 · 확장 계획) · 풀이 | [Lab 03](../../Last3Mon/68/LAB-03-Q-VERIFY-AND-ISOLATE.md) |
-| 7 | 16:00~16:50 | 바이브 코딩 · 요청서 → SPEC → `tflow` 만들기 (각자) | [VIBE-REQ-TFLOW](../../Last3Mon/68/VIBE-REQ-TFLOW.md) → [VIBE-Q-TFLOW](../../Last3Mon/68/VIBE-Q-TFLOW.md), [진행](04-VIBE-CODING.md) |
-| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 69일차 예고 | [진행](04-VIBE-CODING.md) |
+| 7 | 16:00~16:50 | 바이브 코딩 · 요청서 → SPEC → `tflow` 만들기 (각자) | [VIBE-REQ-TFLOW](../../Last3Mon/68/VIBE-REQ-TFLOW.md) → [VIBE-Q-TFLOW](../../Last3Mon/68/VIBE-Q-TFLOW.md), [진행](05-VIBE-CODING.md) |
+| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 다음 일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |

 ```mermaid
 flowchart LR
@@ -36,5 +36,6 @@ flowchart LR
 | `01-STAGE1-COMPOSITE-SCENARIO.md` | 복합 요청, 업무 분석 다섯 칸, 업무 관계, LLM이 할 일과 규칙이 할 일 |
 | `02-STAGE2-MULTI-AGENT-DESIGN.md` | Agent 계약, 라우터 · 파이프라인 · Fork-Join · Supervisor, 라우터 구현, Supervisor와 비교 |
 | `03-STAGE3-VERIFY-AND-SCALE.md` | Multi-Agent 테스트, 빠진 입력, 장애 격리(`neverError`, 대체 답), 측정, 수직·수평 확장 |
-| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tflow), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
+| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 면접 · 최종 프로젝트 체크리스트 |
+| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tflow), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
 | `CONCEPT-68.md` | 개념 정리: LLM · Tool · Agent · Agent 워크플로우 · 라우터 · Supervisor (누가 다음 갈 곳을 정하나) |
@@ -0,0 +1,140 @@
+# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
+
+- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY69-OVERVIEW.md)
+- 이 시간이 끝나면: 오늘 1~3단계에서 한 일(역할 분리 · 협업 워크플로우 · 협업 검증)이 **왜 필요했는지**, 숫자로 **무엇이 좋아졌는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
+- 숫자: 수업 준비 때 정답 워크플로우를 실행한 값입니다 (2026-10-18, gpt-4.1-mini. 강사의 수업 준비 기록).
+
+```mermaid
+flowchart LR
+  A["1. 오늘 한 장"] --> B["2. 왜 역할로<br/>나누나"] --> C["3. 효과를 숫자로"] --> D["4. 회사에서 부르는 이름"]
+  D --> E["5. 산업별 응용"] --> F["6. 하지 말아야 할 때"] --> G["7. 직무 · 면접"] --> H["8. 최종 프로젝트로"]
+```
+
+## 0. 이 시간 (35분)
+
+| 시간 | 절 | 하는 일 |
+| --- | --- | --- |
+| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 역할로 나누나 |
+| 17:15~17:20 | 3 | 오늘 숫자로 본 효과 |
+| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
+| 17:28~17:33 | 6 | 하지 말아야 할 때 |
+| 17:33~17:40 | 7 · 8 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
+| 17:40~17:45 | 9 · 토론 | 다음 일차와의 연결, 질문 둘 |
+
+## 1. 오늘 한 장
+
+| 단계 | 한 일 | 오늘 숫자 |
+| --- | --- | --- |
+| 1단계 · 역할 분리 | 역할 카드(하는 일 · **하지 않는 일**), 작성자, 검토자(규칙 3 + LLM 1 + LLM 판단 재확인) | 작성자 `lab01` 5/5, 검토자 `lab01-challenge` **6/6** |
+| 2단계 · 협업 워크플로우 | 작성자 → 검토자 → 정리자(Fork-Join: `title`, `chat`) | 파이프라인 `lab02` 처음 **3/4**(검토자 거짓 경보) → 4/4, 정리자 `lab02-challenge` **4/4** (두 번) |
+| 3단계 · 협업 검증 | 검토자를 꺼 보기(fail-closed), 어려운 테스트, 단일 Agent와 비교 | 검토자 꺼짐 `lab03-down` 예제 상태 **0/2**(500) → **2/2**, 어려운 케이스 6/7 → **7/7** |
+| 바이브 코딩 | 작성자 → 검토자 → 정리자를 파이썬으로, 역할 지시문은 YAML (`tcrew`) | |
+
+한 문장으로: **역할마다 하는 일과 하지 않는 일을 정해 나누고, 검토는 규칙 먼저 · LLM은 하나만, 검토자가 없으면 내보내지 않는다.**
+
+## 2. 왜 역할로 나누나
+
+| | Agent 하나가 쓰고 스스로 검사 | 작성자 · 검토자 · 정리자 |
+| --- | --- | --- |
+| 검사 | 자기 글을 자기가 봄 ("문제없음") | 다른 역할이 봄 |
+| 지시문 | 쓰기 · 검사 · 정리가 한 덩어리 | 역할마다 짧게, 하지 않는 일까지 |
+| 고칠 때 | 전체 지시문 | 그 역할 카드만 |
+| 확인 | "다 됐다"는 자기 보고 | 검토 결과 `passed` · `codes` |
+
+- 오늘 어려운 케이스에서 **단일 Agent도 6/7**이었지만, 그것은 Agent의 **자기 보고**였습니다. 검토자가 다시 보니 5/6. 스스로 "괜찮다"고 하는 것과 남이 확인한 것은 다릅니다.
+- **검토자가 꺼지면 내보내지 않습니다 (fail-closed).** 검토 결과가 없는데 `게시 가능`이 되는 것이 가장 위험합니다 (0/2 500 → 2/2).
+
+## 3. 효과를 숫자로
+
+| 무엇 | 전 | 후 | 바꾼 것 |
+| --- | --- | --- | --- |
+| 검토자 (`lab01-challenge`) | | **6/6** | 규칙 3 + LLM 1 + LLM 판단 재확인 |
+| 파이프라인 (`lab02`) | 3/4 (검토자 거짓 경보) | **4/4** | 검토자 Code가 LLM 판단을 다시 확인 (그 문장의 낱말이 모두 사실에 있으면 뺌) |
+| 정리자 Fork-Join (`lab02-challenge`) | | **4/4** (두 번) | `title`, `chat` |
+| 검토자가 꺼짐 (`lab03-down`) | 0/2 (500) | **2/2** | fail-closed: 검토 없으면 게시하지 않음 |
+| 어려운 케이스 7개 | 6/7 (공백만) | **7/7** | 공백 사실 400 |
+
+- 검토자도 **틀립니다** (거짓 경보로 3/4). 그래서 LLM이 내린 "문제 있음" 판단을 한 번 더 확인하는 단계를 두었습니다. 검토자의 검토도 테스트로 확인합니다.
+
+## 4. 회사에서는 같은 생각을 이렇게 부른다
+
+| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
+| --- | --- | --- |
+| 역할 카드 | 역할 기반 에이전트, 페르소나 · 책임 정의 | CrewAI 역할 · 목표, AutoGen 에이전트 |
+| 작성자 → 검토자 | 생성-검토(generator-critic), 4-eyes 원칙 | LLM-as-judge, 사람 승인 단계 |
+| 규칙 먼저, LLM은 하나만 | 하이브리드 검증 | 정규식 · 스키마 검사 + LLM 평가 |
+| Fork-Join 정리자 | 병렬 처리 후 합치기 (scatter-gather) | n8n Merge, 워크플로우 엔진 |
+| 검토자가 없으면 막기 | fail-closed, 안전한 실패 | 보안 · 결재 설계 원칙 |
+| 역할 지시문을 YAML로 | 설정과 코드 분리 | 프롬프트 파일, 설정 저장소 (74일차) |
+
+## 5. 산업별 응용 (예)
+
+아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (특정 회사 사례가 아니라 흔한 모양).
+
+| 업무 | 오늘의 무엇을 | 이렇게 |
+| --- | --- | --- |
+| 보도자료 · 공지 작성 | 작성자 → 검토자 → 정리자 | 초안, 사실 · 금지어 검토, 채널별(메일 · 메신저) 정리 |
+| 보험 청구 안내문 | 규칙 먼저 · fail-closed | 금액 · 날짜는 규칙으로 대조, 검토가 실패하면 발송하지 않음 |
+| 코드 리뷰 보조 | 하지 않는 일 | 리뷰 Agent는 지적만 하고 코드를 고치지 않음 |
+| 사내 공지 (오늘) | 전부 | 공지 팀, 검토자 꺼지면 게시 안 함 |
+
+**토론 거리**: 내 업무에서 "쓰는 사람과 확인하는 사람이 달라야 하는" 문서를 하나 골라, 검토자의 하지 않는 일을 적어 봅니다.
+
+## 6. 하지 말아야 할 때 (흔한 실수)
+
+| 하기 쉬운 일 | 왜 위험한가 | 대신 |
+| --- | --- | --- |
+| Agent에게 자기 글을 검사하게 | 자기 보고는 늘 "괜찮다"에 가까움 | 다른 역할 · 규칙이 |
+| 역할 카드에 하는 일만 | 검토자가 초안까지 고쳐 씀 | 하지 않는 일도 |
+| 검토를 전부 LLM이 | 같은 초안에 매번 다른 판정 | 규칙 먼저, LLM은 뜻만 |
+| 검토자가 멈추면 그냥 게시 | 확인 안 된 글이 나감 | fail-closed |
+| 검토자의 판단을 믿기만 | 거짓 경보 (3/4) | 판단 재확인 · 테스트 |
+
+## 7. 직무와 면접
+
+오늘 한 일은 **AI 에이전트 개발자, AI 서비스 기획자, 콘텐츠 자동화 · 품질 담당**이 날마다 하는 일입니다. 채용 공고의 "역할 기반 멀티 에이전트", "LLM 평가 · 검토", "Human-in-the-loop 설계"가 오늘 내용입니다.
+
+<details><summary>1. "Agent가 쓴 글을 어떻게 검증하나요?"</summary>
+
+다른 역할(검토자)이 봅니다. 확실한 것(날짜 · 개인정보 모양)은 규칙으로, 뜻을 봐야 하는 것(없는 약속) 하나만 LLM으로 보고, LLM의 "문제 있음" 판단은 한 번 더 확인합니다. 검토자 테스트가 6/6이었고, 처음에 있던 거짓 경보(3/4)도 이렇게 고쳤습니다.
+</details>
+
+<details><summary>2. "검토 단계가 장애면요?"</summary>
+
+내보내지 않습니다 (fail-closed). 오늘 검토자를 꺼 보니 처음에는 500(0/2)이었고, 검토 결과가 없으면 게시하지 않게 해 2/2가 됐습니다. 확인 안 된 글이 나가는 것이 가장 위험하기 때문입니다.
+</details>
+
+<details><summary>3. "단일 Agent로도 되지 않나요?"</summary>
+
+오늘 어려운 케이스에서 단일 Agent도 6/7이었지만 자기 보고였고, 검토자가 다시 보니 5/6이었습니다. 역할을 나누면 호출은 늘지만 "누가 확인했나"가 분명해집니다.
+</details>
+
+## 8. 최종 프로젝트로 가져갈 것
+
+- [ ] 역할 카드 (하는 일 · 하지 않는 일 · 입력 · 결과)
+- [ ] 검토는 규칙 먼저, LLM은 뜻이 필요한 것 하나만, 판단 재확인
+- [ ] 검토 결과(`passed` · `codes`)를 결과에 남긴다
+- [ ] 검토자가 멈췄을 때의 정책 (fail-closed)과 테스트
+- [ ] 단일 Agent와 비교한 숫자 (자기 보고 vs 검토)
+
+## 9. 다음 일차와의 연결
+
+| 일차 | 오늘의 무엇을 잇나 |
+| --- | --- |
+| 70 | 템플릿 · 모듈 — 검토자를 여러 워크플로우가 같이 쓰는 모듈로 |
+| 71 | RAG 답 검사 — 오늘의 검토자 원리를 답이 근거를 따랐나 확인에 |
+| 73 | 판별 LLM — 오늘의 fail-closed를 보안 관문에 |
+| 74 | 역할 지시문을 버전으로 — 오늘 YAML로 꺼낸 지시문을 저장소에서 |
+
+## 토론 (5분)
+
+1. 검토자에게 "고쳐도 된다"고 하면 무엇이 좋아지고 무엇이 위험해질까요?
+2. 내 업무에서 검토 단계가 멈췄을 때 "그래도 보낸다"가 맞는 경우가 있을까요?
+
+## 정리
+
+- [ ] 역할마다 하는 일 · 하지 않는 일
+- [ ] 검토는 규칙 먼저, LLM은 하나만, 판단 재확인 (거짓 경보 3/4 → 4/4)
+- [ ] 자기 보고와 남의 확인은 다르다 (6/7 vs 5/6)
+- [ ] 검토자가 없으면 내보내지 않는다 (0/2 → 2/2)
+- [ ] 최종 프로젝트에 체크리스트 5개를 가져간다
@@ -1,5 +1,7 @@
 # 7·8교시 · 바이브 코딩 (`tcrew`)

+> 8교시 순서: 발표 10분 → [4단계 정리](04-STAGE4-WRAPUP.md) 35분 → 다음 일차 예고 5분. 아래의 강사 정리 · 강사 바이브 코딩 · 팁은 4단계 정리 안에서 짧게 다루거나 시간이 남으면 합니다.
+
 - 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
 - 과제: [VIBE-REQ-TCREW](../../Last3Mon/69/VIBE-REQ-TCREW.md)(요청서) → 학생이 직접 쓰는 `SPEC.md` → [VIBE-Q-TCREW](../../Last3Mon/69/VIBE-Q-TCREW.md)(요구 · 단계)와 비교 → 만들기 → 수업 뒤 `VIBE-A-TCREW.md` 공개
 - 68일차와 같은 흐름입니다: 사람의 말(요청서)을 **확인할 수 있는 요구**로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다.
@@ -21,8 +21,8 @@
 | - | 13:00~14:00 | 점심 |  |
 | 5 | 14:00~14:50 | 3단계 · 협업 검증과 역할 분리의 값, Lab 03 예제 1·2 | [3단계](03-STAGE3-VERIFY-AND-COMPARE.md), [Lab 03](../../Last3Mon/69/LAB-03-Q-TRACE-AND-COMPARE.md) |
 | 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (어려운 테스트, 단일 Agent 비교) · 풀이 | [Lab 03](../../Last3Mon/69/LAB-03-Q-TRACE-AND-COMPARE.md) |
-| 7 | 16:00~16:50 | 바이브 코딩 · `tcrew` 만들기 (각자, 요청서 → SPEC 먼저) | [VIBE-REQ-TCREW](../../Last3Mon/69/VIBE-REQ-TCREW.md) → [VIBE-Q-TCREW](../../Last3Mon/69/VIBE-Q-TCREW.md), [진행](04-VIBE-CODING.md) |
-| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 70일차 예고 | [진행](04-VIBE-CODING.md) |
+| 7 | 16:00~16:50 | 바이브 코딩 · `tcrew` 만들기 (각자, 요청서 → SPEC 먼저) | [VIBE-REQ-TCREW](../../Last3Mon/69/VIBE-REQ-TCREW.md) → [VIBE-Q-TCREW](../../Last3Mon/69/VIBE-Q-TCREW.md), [진행](05-VIBE-CODING.md) |
+| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 다음 일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |

 ```mermaid
 flowchart LR
@@ -38,5 +38,6 @@ flowchart LR
 | `01-STAGE1-ROLE-SEPARATION.md` | 왜 역할로 나누나, 역할 카드, 하지 않는 일, 규칙 검토와 LLM 검토, LLM 검토자도 틀린다 |
 | `02-STAGE2-COLLABORATION.md` | 68일차 분배와 오늘 협업의 차이, 파이프라인, 고쳐 쓰기 1회, 넘기는 값의 출처, Fork-Join |
 | `03-STAGE3-VERIFY-AND-COMPARE.md` | 협업 기록, fail-open과 fail-closed, 어려운 테스트, 단일 Agent와 비교 (측정값) |
-| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tcrew), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
+| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 면접 · 최종 프로젝트 체크리스트 |
+| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tcrew), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
 | `CONCEPT-69.md` | 개념 정리: 분배와 협업, 역할 카드, 규칙 검토와 LLM 검토, fail-open과 fail-closed, Fork-Join, 역할 팀과 단일 Agent |
@@ -0,0 +1,140 @@
+# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
+
+- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY70-OVERVIEW.md)
+- 이 시간이 끝나면: 오늘 1~3단계에서 한 일(템플릿화 · 모듈화 · 변경 관리)이 **왜 필요했는지**, 숫자로 **무엇이 좋아졌는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
+- 숫자: 수업 준비 때 정답 워크플로우를 실행한 값입니다 (2026-10-18, gpt-4.1-mini. 강사의 수업 준비 기록).
+
+```mermaid
+flowchart LR
+  A["1. 오늘 한 장"] --> B["2. 왜 복사하지<br/>않나"] --> C["3. 효과를 숫자로"] --> D["4. 회사에서 부르는 이름"]
+  D --> E["5. 산업별 응용"] --> F["6. 하지 말아야 할 때"] --> G["7. 직무 · 면접"] --> H["8. 최종 프로젝트로"]
+```
+
+## 0. 이 시간 (35분)
+
+| 시간 | 절 | 하는 일 |
+| --- | --- | --- |
+| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 복사하지 않나 |
+| 17:15~17:20 | 3 | 오늘 숫자로 본 효과 |
+| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
+| 17:28~17:33 | 6 | 하지 말아야 할 때 |
+| 17:33~17:40 | 7 · 8 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
+| 17:40~17:45 | 9 · 토론 | 다음 일차와의 연결, 질문 둘 |
+
+## 1. 오늘 한 장
+
+| 단계 | 한 일 | 오늘 숫자 |
+| --- | --- | --- |
+| 1단계 · 템플릿화 | 복사본 3개 비교(노드 9개 중 4개가 다름), 같은 것과 다른 것을 나눠 설정 표 한 곳으로, 표에 없으면 400 | 공지 키트 `lab01` 5/5, 새 종류 · 없는 종류 `lab01-challenge` 예제 상태 **1/4** → **4/4** |
+| 2단계 · 모듈화 | 공통 검사를 Sub-workflow 모듈로, 입력 · 결과 계약 | 규칙 검사 모듈 `lab02-module` 5/5 (0.1초), SMS가 같은 모듈 `lab02-challenge` **4/4** (0.9~2.9초) |
+| 3단계 · 변경 관리 | 모듈을 바꾸면 누가 영향을 받나(영향 표), 모듈 버전, 어려운 테스트 | 키트 어려운 케이스 예제 상태 **3/7** → **7/7**, `lab03-v2` 5/5, SMS 4/4 |
+| 바이브 코딩 | 템플릿 폴더 + 변수로 새 워크플로우 · 테스트 파일을 만드는 `tkit` | |
+
+한 문장으로: **복사하지 말고 같은 것은 템플릿 · 모듈로, 다른 것은 설정 표 한 곳에 두고, 고칠 때는 누가 영향을 받는지 먼저 본다.**
+
+## 2. 왜 복사하지 않나
+
+| | 복사해서 고치기 | 템플릿 · 모듈 |
+| --- | --- | --- |
+| 처음 | 빠름 | 조금 더 생각 |
+| 버그를 고칠 때 | 복사본마다 따로 (하나는 꼭 빠뜨림) | 한 곳 |
+| 새 종류 | 또 복사 | 설정 표에 한 줄 |
+| 다른 점 찾기 | 노드를 하나씩 비교 (9개 중 4개) | 설정 표를 봄 |
+| 위험 | 복사본끼리 조금씩 달라짐 ("우연히 다른 것") | 모듈 하나를 바꾸면 모두가 영향 |
+
+- 오늘 복사본 3개를 비교하니 9개 노드 중 4개가 달랐고, 그중에는 **일부러 다른 것**과 **우연히 다른 것**이 섞여 있었습니다. 템플릿화는 이 둘을 가르는 일입니다.
+- 모듈의 값: 한 곳만 고치면 되지만, **한 곳을 고치면 모두가 바뀝니다.** 그래서 3단계에서 영향 표 · 버전 · 테스트를 했습니다.
+
+## 3. 효과를 숫자로
+
+| 무엇 | 전 | 후 | 바꾼 것 |
+| --- | --- | --- | --- |
+| 새 종류(설문) · 없는 종류 (`lab01-challenge`) | 1/4 | **4/4** | 설정 표에 한 줄, 없는 종류 400 · 목록 |
+| SMS가 같은 모듈 사용 (`lab02-challenge`) | | **4/4** (0.9~2.9초) | 모듈 계약에 `max_length` 80 |
+| 키트의 어려운 케이스 7개 | 3/7 | **7/7** | `kind` 다듬기 · 한국어 별칭 · 공백 사실 400 (모듈 v2) |
+| 모듈을 바꾼 뒤 다른 사용처 (회귀) | | `lab01` 5/5 · `lab01-challenge` 4/4 · `lab03-v2` 5/5 · SMS 4/4 | 영향 표대로 다시 시험 |
+
+- 규칙 검사 모듈은 **0.1초**였습니다. LLM을 부르지 않는 모듈은 빠르고 늘 같은 결과를 냅니다. 무엇을 모듈로 뽑을지 고를 때 이 차이도 봅니다.
+
+## 4. 회사에서는 같은 생각을 이렇게 부른다
+
+| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
+| --- | --- | --- |
+| 같은 것 · 다른 것 나누기 | 템플릿화, 매개변수화 | n8n 템플릿, cookiecutter, 코드 생성기 |
+| 설정 표 한 곳 | 설정 외부화, 단일 출처 (single source of truth) | 설정 파일, 원격 설정 (74일차) |
+| Sub-workflow 모듈 | 모듈화, 재사용 컴포넌트, 공유 라이브러리 | n8n Execute Workflow, 함수 · 패키지 |
+| 입력 · 결과 계약 | 인터페이스 계약, API 스키마 | JSON Schema, OpenAPI |
+| 영향 표 · 모듈 버전 | 영향 분석, 의존성 관리, 시맨틱 버전 | 패키지 버전, 하위 호환 정책 |
+| 표에 없으면 400 | 입력 검증, 허용 목록 | 열거형(enum) 검사 |
+
+## 5. 산업별 응용 (예)
+
+아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (특정 회사 사례가 아니라 흔한 모양).
+
+| 업무 | 오늘의 무엇을 | 이렇게 |
+| --- | --- | --- |
+| 쇼핑몰 알림 (주문 · 배송 · 환불) | 템플릿 · 설정 표 | 알림 종류마다 복사하지 않고 종류 표 + 공통 흐름 |
+| 사내 교육 신청 확인 | 키트 | 과정 표에 한 줄 더하면 새 과정 확인 메일 |
+| 개인정보 검사 | 공통 모듈 | 메일 · SMS · 메신저가 같은 검사 모듈, 바꾸면 영향 표대로 다시 시험 |
+| 사내 공지 (오늘) | 전부 | 공지 키트, 규칙 검사 모듈, SMS 재사용 |
+
+**토론 거리**: 내 업무에서 "복사해서 조금씩 고친" 자동화 셋을 떠올려, 같은 것 · 다른 것 · 우연히 다른 것으로 나눠 봅니다.
+
+## 6. 하지 말아야 할 때 (흔한 실수)
+
+| 하기 쉬운 일 | 왜 위험한가 | 대신 |
+| --- | --- | --- |
+| 일단 복사 | 버그를 한 곳만 고침 | 같은 것은 템플릿 · 모듈 |
+| 다른 값을 노드마다 흩어 둠 | 무엇이 다른지 찾기 어려움 | 설정 표 한 곳 |
+| 표에 없는 값도 그냥 처리 | 엉뚱한 기본값으로 나감 | 400 + 가능한 목록 |
+| 모듈을 고치고 사용처를 안 봄 | 다른 워크플로우가 몰래 깨짐 | 영향 표 · 사용처마다 테스트 |
+| 모든 것을 모듈로 | 계약만 늘고 이해하기 어려움 | 정말 여러 곳이 쓰는 것만 |
+
+## 7. 직무와 면접
+
+오늘 한 일은 **자동화 플랫폼 엔지니어, 백엔드 엔지니어, 노코드 · RPA 운영 담당**이 날마다 하는 일입니다. 채용 공고의 "재사용 가능한 워크플로우 설계", "공통 모듈 · 컴포넌트", "변경 영향 분석"이 오늘 내용입니다.
+
+<details><summary>1. "비슷한 자동화가 여러 개 생기면 어떻게 하나요?"</summary>
+
+같은 것과 다른 것을 나눕니다. 오늘 복사본 셋을 비교하니 노드 9개 중 4개가 달랐고, 다른 값은 설정 표 한 곳에, 같은 흐름은 템플릿으로 뒀습니다. 새 종류(설문)는 표에 한 줄로 끝나고, 없는 종류는 400과 목록을 줘서 1/4가 4/4가 됐습니다.
+</details>
+
+<details><summary>2. "공통 모듈을 바꾸면 위험하지 않나요?"</summary>
+
+위험합니다. 그래서 바꾸기 전에 누가 쓰는지 영향 표를 만들고, 모듈 버전을 두고, 사용처마다 테스트를 다시 돌렸습니다. 모듈 v2로 어려운 케이스를 3/7에서 7/7로 고친 뒤 키트 · SMS 테스트도 그대로 통과하는지 확인했습니다.
+</details>
+
+<details><summary>3. "무엇을 모듈로 뽑나요?"</summary>
+
+여러 곳이 같은 일을 할 때입니다. 오늘 메일과 SMS가 같은 규칙 검사를 써서 모듈로 뽑았고, LLM 없는 규칙 모듈이라 0.1초에 늘 같은 결과였습니다.
+</details>
+
+## 8. 최종 프로젝트로 가져갈 것
+
+- [ ] 비슷한 흐름이 둘 이상이면 같은 것 · 다른 것 표
+- [ ] 다른 값은 설정 표 한 곳, 표에 없으면 400
+- [ ] 공통 모듈의 입력 · 결과 계약
+- [ ] 모듈을 쓰는 곳 목록(영향 표)과 사용처마다 테스트
+- [ ] 모듈 버전 (깨지는 변경이면 새 버전)
+
+## 9. 다음 일차와의 연결
+
+| 일차 | 오늘의 무엇을 잇나 |
+| --- | --- |
+| 71 | RAG — 색인 · 검색을 다른 문서에도 쓰는 구조로 |
+| 72 | 성능 — 모듈 호출이 더하는 시간 |
+| 74 | 버전 관리 — 오늘의 모듈 버전 · 설정 표가 릴리스 · 지시문 저장소로 |
+| 78 | 품질 규칙 — 오늘의 계약을 데이터 품질 규칙으로 |
+
+## 토론 (5분)
+
+1. 오늘 설정 표에 넣지 않고 템플릿 안에 둔 값 중, 나중에 표로 옮겨야 할 것은 무엇일까요?
+2. 모듈을 고쳤는데 사용처 하나의 테스트가 깨졌다면, 모듈을 되돌릴까요 사용처를 고칠까요?
+
+## 정리
+
+- [ ] 복사하지 말고: 같은 것은 템플릿 · 모듈, 다른 것은 설정 표
+- [ ] 표에 없으면 멈춘다 (400 + 목록)
+- [ ] 모듈은 계약으로, 고칠 때는 영향 표 · 버전 · 사용처 테스트
+- [ ] 효과는 숫자로 (1/4 → 4/4, 3/7 → 7/7, 규칙 모듈 0.1초)
+- [ ] 최종 프로젝트에 체크리스트 5개를 가져간다
@@ -1,5 +1,7 @@
 # 7·8교시 · 바이브 코딩 (`tkit`)

+> 8교시 순서: 발표 10분 → [4단계 정리](04-STAGE4-WRAPUP.md) 35분 → 다음 일차 예고 5분. 아래의 강사 정리 · 강사 바이브 코딩 · 팁은 4단계 정리 안에서 짧게 다루거나 시간이 남으면 합니다.
+
 - 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
 - 과제: [VIBE-Q-TKIT](../../Last3Mon/70/VIBE-Q-TKIT.md)
 - 오늘은 `tkit`: 템플릿 폴더를 고르고 변수를 채우면 새 파일을 만드는 TUI (cookiecutter 방식). 오늘 만든 공지 키트를 템플릿으로 만들어 새 업무 워크플로우를 찍어 냅니다.
@@ -19,8 +19,8 @@
 | - | 13:00~14:00 | 점심 |  |
 | 5 | 14:00~14:50 | 3단계 · 재사용 구조의 변경 관리, Lab 03 예제 1·2 | [3단계](03-STAGE3-CHANGE-AND-VERSION.md), [Lab 03](../../Last3Mon/70/LAB-03-Q-CHANGE-AND-VERSION.md) |
 | 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (영향 표 · 어려운 테스트) · 풀이 | [Lab 03](../../Last3Mon/70/LAB-03-Q-CHANGE-AND-VERSION.md) |
-| 7 | 16:00~16:50 | 바이브 코딩 · `tkit` 만들기 (각자) | [VIBE-Q-TKIT](../../Last3Mon/70/VIBE-Q-TKIT.md), [진행](04-VIBE-CODING.md) |
-| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 71일차 예고 | [진행](04-VIBE-CODING.md) |
+| 7 | 16:00~16:50 | 바이브 코딩 · `tkit` 만들기 (각자) | [VIBE-Q-TKIT](../../Last3Mon/70/VIBE-Q-TKIT.md), [진행](05-VIBE-CODING.md) |
+| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 다음 일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |

 ```mermaid
 flowchart LR
@@ -36,4 +36,5 @@ flowchart LR
 | `01-STAGE1-TEMPLATE.md` | 복사의 비용, 같은 것·다른 것·우연히 다른 것, 설정 표, 없는 값은 멈춤 |
 | `02-STAGE2-MODULES.md` | 모듈의 조건, Sub-workflow(Execute Workflow · Trigger), 입력으로 받기, 시험용 웹훅, 리팩터링 |
 | `03-STAGE3-CHANGE-AND-VERSION.md` | 하위 호환 변경, 깨지는 변경과 새 버전, 계약은 층마다, 영향 표 |
-| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tkit), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
+| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 면접 · 최종 프로젝트 체크리스트 |
+| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tkit), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
@@ -0,0 +1,145 @@
+# 4단계 · 정리: 오늘 한 일의 의미 · 효과 · 실전 응용
+
+- 교시: 8교시 17:10~17:45 (35분, 바이브 코딩 발표 10분 뒤) · 자료: 이 문서 + [개요](00-DAY71-OVERVIEW.md)
+- 이 시간이 끝나면: 오늘 1~3단계에서 한 일(색인 · 근거로 답하기 · 검색 품질 측정)이 **왜 필요했는지**, 숫자로 **무엇이 좋아졌고 무엇을 치렀는지**, 회사에서는 같은 생각을 **어떤 이름과 도구로** 쓰는지 말할 수 있고, 최종 프로젝트에 무엇을 가져갈지 정할 수 있다.
+- 숫자: 수업 준비 · 전날 정답 워크플로우를 실행한 값입니다 (2026-10-18 · 10-22, gpt-4.1-mini, `text-embedding-3-large`. 강사의 수업 준비 기록, [Last3Mon/71/answers](../../Last3Mon/71/answers/)).
+
+```mermaid
+flowchart LR
+  A["1. 오늘 한 장"] --> B["2. 왜 RAG인가"] --> C["3. 효과와 값을 숫자로"] --> D["4. 회사에서 부르는 이름"]
+  D --> E["5. 산업별 응용"] --> F["6. 하지 말아야 할 때"] --> G["7. 직무 · 면접"] --> H["8. 최종 프로젝트로"]
+```
+
+## 0. 이 시간 (35분)
+
+| 시간 | 절 | 하는 일 |
+| --- | --- | --- |
+| 17:10~17:15 | 1 · 2 | 오늘 한 장, 왜 RAG인가 |
+| 17:15~17:20 | 3 | 오늘 숫자로 본 효과와 값 |
+| 17:20~17:28 | 4 · 5 | 같은 생각의 업계 이름 · 도구, 산업별 응용 예 |
+| 17:28~17:33 | 6 | 하지 말아야 할 때 |
+| 17:33~17:40 | 7 · 8 | 직무와 면접 질문, 최종 프로젝트 체크리스트 |
+| 17:40~17:45 | 9 · 토론 | 다음 일차와의 연결, 질문 둘 |
+
+## 1. 오늘 한 장
+
+| 단계 | 한 일 | 오늘 숫자 |
+| --- | --- | --- |
+| 1단계 · 색인 | 정답표를 먼저 만들고, 규정 문서를 섹션 청크로 색인 · 검색, 출처에 섹션 제목 | 섹션 청크 25개, `lab01` 6/6, 섹션 출처 `lab01-challenge` 예제 상태 **2/4** → **4/4** |
+| 2단계 · 근거로 답하기 | 발췌로만 답 + 번호 출처, 관련도 기준 0.33, 답 검사 넷 → **신뢰도 기준** | 기준값 `lab03-threshold` **10/10**, 답 검사 `lab02-challenge` 예제 상태 **2/8** → **8/8** (`--repeat 3` 24/24) |
+| 3단계 · 검색 품질 | doc@1 · answer@1 · answer@3로 재고, 청크 크기 · 질문 다시 쓰기를 한 가지씩 | 24문항 answer@1 **22 → 24**, 어려운 질문 **6/8 → 7/8** (2개 고치고 1개 새로 틀림), 검색 0.9~1.6초 |
+| 바이브 코딩 | 내 md 문서를 임베딩해 SQLite에 두고 근거 문단과 답을 보여 주는 `tdoc` | |
+
+한 문장으로: **정답표로 먼저 재고, 찾은 발췌로만 답하게 하고, 관련도 기준과 답 검사를 둘 다 지난 답만 자동으로 내보낸다.**
+
+## 2. 왜 RAG인가
+
+| | LLM 혼자 | RAG (검색 + 발췌로 답) |
+| --- | --- | --- |
+| 아는 것 | 학습한 일반 지식 | **우리 회사 규정** (오늘 문서) |
+| 규정이 바뀌면 | 모델이 모름 | 문서를 다시 색인 |
+| 근거 | 없음 | 발췌 · 출처(문서 · 섹션) |
+| 모르면 | 그럴듯하게 지어내기 쉬움 | 기준 미달 · 검사 실패 → 담당자 연결 |
+| 값 | LLM 한 번 | 임베딩 · 검색 + LLM, 색인 관리 |
+
+- **검색이 틀리면 답도 틀립니다.** 그래서 답을 만들기 전에 정답표로 검색부터 쟀습니다 (doc@1 · answer@3).
+- **점수가 높아도 답이 없을 수 있습니다.** "VPN 속도", "노트북 사양"처럼 비슷한 낱말은 있는데 답이 없는 질문은 관련도 기준만으로 못 거르고, 답 검사가 잡았습니다 (2/8 → 8/8).
+
+## 3. 효과와 값을 숫자로
+
+| 무엇 | 전 | 후 | 바꾼 것 |
+| --- | --- | --- | --- |
+| 섹션 제목까지 출처 (`lab01-challenge`) | 2/4 | **4/4** | 섹션 청크 · 메타데이터 |
+| 관련 없는 질문 넘기기 (`lab03-threshold`) | | **10/10** | 관련도 기준 0.33 (규정 질문 0.46~0.62, 규정 밖 0.20~0.26 사이) |
+| 점수는 높은데 답이 없는 질문 (`lab02-challenge`) | 2/8 | **8/8** (3번 24/24) | 답 검사 넷 (모른다고 했나 · 인용 · 근거 겹침 30% · 숫자) |
+| 신뢰도 기준 충족 (`lab02` + `lab02-challenge`, 10/22) | | 13개 중 **7개** 자동 답변, 관련도 기준 미달 2 · 답 검사 미달 4 | 두 겹 모두 지나야 자동 |
+| 24문항 answer@1 | 22 | **24** | 질문 다시 쓰기 |
+| 어려운 질문 8개 | 6/8 | **7/8** | 질문 다시 쓰기 (2개 고치고 1개 새로 틀림) |
+
+**치른 값**: 질문 다시 쓰기는 LLM 호출이 하나 늘고(검색 0.9~1.6초), 어려운 질문 하나는 **오히려 새로 틀렸습니다.** 개선은 한 가지씩 바꾸고 같은 정답표로 다시 재야 압니다.
+
+## 4. 회사에서는 같은 생각을 이렇게 부른다
+
+| 오늘 한 것 | 업계 이름 | 쓰는 도구 · 표준 (예) |
+| --- | --- | --- |
+| 정답표 먼저 | 평가 세트, 검색 평가 | hit@k · recall@k, Ragas, LangSmith 평가 |
+| 섹션 청크 · 메타데이터 | 청킹, 메타데이터 필터 | 문서 로더 · 분할기, 벡터 DB 메타데이터 |
+| 임베딩 · 메모리 저장소 | 벡터 검색 | OpenAI 임베딩, pgvector, Qdrant, Pinecone, Elasticsearch |
+| 발췌로만 답 · 번호 출처 | 근거 기반 생성 (grounded generation), 인용 | RAG 프레임워크 (LlamaIndex · LangChain) |
+| 관련도 기준 + 답 검사 | 신뢰도 기준, 가드레일, 환각 탐지 | 유사도 임계값, faithfulness 지표, LLM 평가 |
+| 질문 다시 쓰기 | 쿼리 재작성 (query rewriting) | HyDE, 다중 쿼리 |
+| 담당자 연결 | Human-in-the-loop, 이관 | 상담 · 티켓 시스템 |
+
+## 5. 산업별 응용 (예)
+
+아래는 오늘 한 일을 다른 업무에 옮긴 예입니다 (특정 회사 사례가 아니라 흔한 모양).
+
+| 업무 | 오늘의 무엇을 | 이렇게 |
+| --- | --- | --- |
+| 사내 인사 · 복리후생 문의 | RAG · 출처 | 취업규칙 · 복지 안내를 색인, 답에 조항 이름, 없으면 인사팀 연결 |
+| 제품 기술 지원 | 신뢰도 기준 | 매뉴얼 검색 점수 + 답 검사를 지나야 자동 답변, 아니면 엔지니어 티켓 |
+| 금융 상품 안내 | 숫자 검사 | 금리 · 수수료 숫자는 발췌에 있는 것만, 없으면 답하지 않음 |
+| 사내 IT 규정 (오늘) | 전부 | 규정 25청크, 기준 0.33, 답 검사 넷, 질문 다시 쓰기 |
+
+**토론 거리**: 내 회사의 문서 하나를 골라, "점수는 높은데 답이 없을" 질문을 두 개 만들어 봅니다.
+
+## 6. 하지 말아야 할 때 (흔한 실수)
+
+| 하기 쉬운 일 | 왜 위험한가 | 대신 |
+| --- | --- | --- |
+| 답부터 보고 좋다고 판단 | 검색이 틀린 것을 모름 | 정답표로 검색부터 |
+| 글자 수로만 자르기 | 섹션이 잘려 출처가 흐림 | 문서 구조(섹션)대로 |
+| 기준값 하나로 끝 | 점수는 높은데 답 없는 질문이 나감 | 답 검사를 겹으로 |
+| 기준값을 어떤 질문 점수 바로 옆에 | 임베딩이 셋째 자리에서 흔들림 | 두 무리 사이 여유 있게 |
+| 개선을 여러 개 한꺼번에 | 무엇이 좋아졌는지 모름 | 한 가지씩, 같은 정답표로 |
+| 모르는 질문에도 답하게 | 지어낸 답 | 담당자 연결 + `draft` · `failed` |
+
+## 7. 직무와 면접
+
+오늘 한 일은 **RAG · 검색 엔지니어, AI · LLM 애플리케이션 엔지니어, 지식 관리(KM) · 챗봇 운영 담당**이 날마다 하는 일입니다. 채용 공고의 "RAG 파이프라인", "벡터 검색", "검색 품질 평가", "환각 줄이기"가 오늘 내용입니다.
+
+<details><summary>1. "RAG의 품질은 어떻게 재나요?"</summary>
+
+검색과 답을 따로 잽니다. 질문마다 답이 있는 문서 · 문구를 적은 정답표로 doc@1 · answer@1 · answer@3를 재고, 청크 크기나 질문 다시 쓰기를 한 가지씩 바꿔 다시 잽니다. 오늘 질문 다시 쓰기로 answer@1이 22에서 24가 됐지만, 어려운 질문 하나는 새로 틀렸습니다.
+</details>
+
+<details><summary>2. "RAG가 지어내지 않게 하려면?"</summary>
+
+두 겹의 신뢰도 기준을 둡니다. 답을 만들기 전에 관련도 기준(0.33)으로 엉뚱한 질문을 넘기고(10/10), 답을 만든 뒤 모른다고 했나 · 인용 · 근거 겹침 · 숫자 검사를 해서 하나라도 실패하면 담당자에게 넘깁니다. 점수는 높은데 답이 없는 질문이 2/8에서 8/8이 됐습니다.
+</details>
+
+<details><summary>3. "임계값은 어떻게 정하나요?"</summary>
+
+재서 정합니다. 오늘 규정 질문은 0.46~0.62, 규정 밖 질문은 0.20~0.26이라 그 사이 0.33에 두었고, 테스트 파일로 남겨 모델이나 청크를 바꿀 때마다 다시 돌립니다. 어떤 질문 점수 바로 옆에 두지 않습니다.
+</details>
+
+## 8. 최종 프로젝트로 가져갈 것
+
+- [ ] 정답표 (질문 · 답이 있는 문서 · 섹션 · 답 문구)
+- [ ] 청크 기준과 메타데이터 (출처를 섹션까지)
+- [ ] 관련도 기준을 재서 정한 근거와 테스트 파일
+- [ ] 답 검사 (모른다고 했나 · 인용 · 근거 · 숫자), 실패면 담당자 연결 + `draft` · `failed`
+- [ ] 신뢰도 기준 충족률을 갈래별로 (자동 · 관련도 기준 미달 · 답 검사 미달)
+- [ ] 검색 품질 지표 (doc@1 · answer@k)와 한 가지씩 바꾼 기록
+
+## 9. 다음 일차와의 연결
+
+| 일차 | 오늘의 무엇을 잇나 |
+| --- | --- |
+| 72 | 성능 — 검색 · 다시 쓰기 · 답 LLM의 단계별 시간 |
+| 73 | 보안 — 문서 속 "AI는 …하라"(간접 인젝션), 권한 없는 문서 |
+| 74 | 버전 — 색인 · 지시문을 버전으로, 바꾸기 전에 게이트 |
+| 77 | 로그 — 담당자 연결이 많은 질문을 모아 규정 보완 |
+
+## 토론 (5분)
+
+1. 신뢰도 기준을 더 엄격하게(예: 0.33 → 0.45) 하면 무엇이 좋아지고 누가 일이 늘까요?
+2. 답 검사에서 넘어간 질문(VPN 속도 · 노트북 사양 등)을 담당자는 어떻게 처리해야 다음에 자동으로 답할 수 있을까요?
+
+## 정리
+
+- [ ] 정답표로 검색부터 잰다
+- [ ] 찾은 발췌로만 답하고 출처를 섹션까지
+- [ ] 신뢰도 기준 = 관련도 기준(전) + 답 검사(후), 둘 다 지나야 자동 답변
+- [ ] 개선은 한 가지씩, 같은 정답표로 (answer@1 22 → 24, 어려운 질문 하나는 새로 틀림)
+- [ ] 최종 프로젝트에 체크리스트 6개를 가져간다
@@ -1,5 +1,7 @@
 # 7·8교시 · 바이브 코딩 (`tdoc`)

+> 8교시 순서: 발표 10분 → [4단계 정리](04-STAGE4-WRAPUP.md) 35분 → 다음 일차 예고 5분. 아래의 강사 정리 · 강사 바이브 코딩 · 팁은 4단계 정리 안에서 짧게 다루거나 시간이 남으면 합니다.
+
 - 교시: 7교시 16:00~16:50 (각자 만들기), 8교시 17:00~17:50 (발표 · 정리 · 강사 바이브 코딩 · 팁 · 예고)
 - 과제: [VIBE-REQ-TDOC](../../Last3Mon/71/VIBE-REQ-TDOC.md)(요청서) → 학생이 직접 쓰는 `SPEC.md` → [VIBE-Q-TDOC](../../Last3Mon/71/VIBE-Q-TDOC.md)(요구 · 단계)와 비교 → 만들기 → 수업 뒤 `VIBE-A-TDOC.md` 공개
 - 68 · 69일차와 같은 흐름입니다: 사람의 말(요청서)을 **확인할 수 있는 요구**로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다.
@@ -19,8 +19,8 @@
 | - | 13:00~14:00 | 점심 |  |
 | 5 | 14:00~14:50 | 3단계 · 검색 품질 측정과 개선, Lab 03 예제 1·2 | [3단계](03-STAGE3-RETRIEVAL-QUALITY.md), [Lab 03](../../Last3Mon/71/LAB-03-Q-MEASURE-AND-IMPROVE.md) |
 | 6 | 15:00~15:50 | 3단계 · Lab 03 과제 40분 (어려운 질문으로 고치기) · 풀이 | [Lab 03](../../Last3Mon/71/LAB-03-Q-MEASURE-AND-IMPROVE.md) |
-| 7 | 16:00~16:50 | 바이브 코딩 · `tdoc` 만들기 (각자, 요청서 → SPEC 먼저) | [VIBE-REQ-TDOC](../../Last3Mon/71/VIBE-REQ-TDOC.md) → [VIBE-Q-TDOC](../../Last3Mon/71/VIBE-Q-TDOC.md), [진행](04-VIBE-CODING.md) |
-| 8 | 17:00~17:50 | 바이브 코딩 발표 · 정리 · 강사 바이브 코딩 · 팁 · 72일차 예고 | [진행](04-VIBE-CODING.md) |
+| 7 | 16:00~16:50 | 바이브 코딩 · `tdoc` 만들기 (각자, 요청서 → SPEC 먼저) | [VIBE-REQ-TDOC](../../Last3Mon/71/VIBE-REQ-TDOC.md) → [VIBE-Q-TDOC](../../Last3Mon/71/VIBE-Q-TDOC.md), [진행](05-VIBE-CODING.md) |
+| 8 | 17:00~17:50 | 바이브 코딩 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 다음 일차 예고 | [4단계 정리](04-STAGE4-WRAPUP.md), [진행](05-VIBE-CODING.md) |

 ```mermaid
 flowchart LR
@@ -36,4 +36,5 @@ flowchart LR
 | `01-STAGE1-RAG-AND-INDEX.md` | 왜 RAG인가(네 가지 방법 비교), 임베딩과 점수 읽기(실측), 정답표 먼저(질문 종류 · 정답표도 틀림), 청크 하나의 모양 · 메타데이터, 메모리 저장소의 한살이, 요청문 좋은 예 · 나쁜 예, 확인 질문 |
 | `02-STAGE2-RAG-ANSWER.md` | LLM이 받는 발췌의 실제 모양 · 실측 답, `sources`와 `cited`, 관련도 기준 10개 · 정하는 순서 · 양쪽으로 틀림, 점수는 높은데 답이 없을 때, 답 검사 넷(계산 방법 · 결과 JSON), 넘기는 길 세 갈래, 확인 질문 |
 | `03-STAGE3-RETRIEVAL-QUALITY.md` | doc@1 · answer@1 · answer@3(아슬아슬한 1등), 재는 순서 · 실험 기록, 청크 크기(잘린 문장 · 섞인 청크 · 틀린 질문이 다름), 어려운 질문 8개와 다시 쓴 검색어, 같은 설정 다른 결과, 개선 방법 고르기 · 멈출 때, 확인 질문 |
-| `04-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tdoc), 발표, 강사 정리, 추가 바이브 코딩, 팁 |
+| `04-STAGE4-WRAPUP.md` | 8교시 35분: 오늘의 의미 · 효과 숫자 · 업계 이름 · 산업별 응용 · 면접 · 최종 프로젝트 체크리스트 |
+| `05-VIBE-CODING.md` | 7·8교시 바이브 코딩 진행 (tdoc), 발표, 강사 정리, 추가 바이브 코딩, 팁 |