aio-01d4-stu/Lecture/78/00-DAY78-OVERVIEW.md

# 78일차 개요 · 데이터 품질 검증 자동화와 품질 관리 Workflow

> 노코드 멀티 에이전트 워크플로우 설계 및 운영 · 2026-11-03
> 30장 · 각 장은 가로줄(`---`)로 나뉩니다. 1교시에는 1~6장을 보고, 나머지 장은 각 단계 강의(1 · 3 · 5교시) 때 함께 띄웁니다.
> 숫자는 모두 강사 노트북 실측입니다 (65일차 n8n 2.42.6, 78일차 판 데이터 API의 FAQ 배치 셋 · 직원 CSV · 접수 건, OpenAI `gpt-4.1-mini`(LLM 검사, temperature 0), 11/01 정답 워크플로우를 학생 순서대로 1회).

| 장 | 범위 | 띄우는 때 |
| --- | --- | --- |
| 1~6 | 표지 · 목표 · 시간표 · 같은 배치, 다른 판정 · 일하는 순서 · 실습 15개 | 1교시 시작 |
| 7~14 | 1단계 · 품질 규칙 | 1교시 강의 |
| 15~21 | 2단계 · 품질 게이트 | 3교시 강의 |
| 22~28 | 3단계 · 품질 관리 | 5교시 강의 |
| 29~30 | 바이브 코딩 · 정리와 예고 (8교시 35분 정리는 [04-STAGE4-WRAPUP](04-STAGE4-WRAPUP.md)) | 7교시 · 8교시 |

---

## 1 / 30 · 표지

```mermaid
flowchart LR
  B[("들어오는 데이터<br/>FAQ · 직원 · 접수 건")] --> R["규칙<br/>무엇이 나쁜가"] --> G["게이트<br/>막기 · 격리 · 알림"] --> M["관리<br/>스키마 · 고쳐서 다시 · 추세"]
  classDef d fill:#0F3D3E,stroke:#0F3D3E,color:#fff
  classDef o fill:#F2A541,stroke:#F2A541,color:#fff
  class B d
  class R,G,M o
```

**78일차**

# 데이터 품질 검증 자동화와 품질 관리 Workflow

규칙은 말로 정하고 · 나쁜 데이터는 막고 알리고 · 고치는 것은 사람이

<sub>노코드 멀티 에이전트 워크플로우 설계 및 운영 · 2026-11-03</sub>

---

## 2 / 30 · 오늘 할 수 있게 될 세 가지

| | 목표 | 내용 |
| --- | --- | --- |
| 1 | **규칙을 세운다** | 나쁜 데이터를 눈으로 찾고, 규칙과 오류 코드로 바꾸고, 경계에서 시험하고, 이미 있는 데이터와 맞춰 보고, 보낸 사람에게 고칠 것을 돌려준다 |
| 2 | **막는다** | 검사를 불러 나쁜 배치는 거절하고 나쁜 줄은 격리하고, 규칙으로 못 잡는 것은 LLM에게, 기준의 대가를 재고, 기록 · 알림을 남기고, LLM 호출을 숫자로 본다 |
| 3 | **관리한다** | 규칙을 스키마(데이터)로 꺼내 넓히고, 고친 줄을 다시 넣어 격리함을 비우고, 새 스키마로 늘리고, 품질 보고서 · 데이터셋별 품질을 본다 |

---

## 3 / 30 · 오늘의 시간표

| 교시 | 시간 | 내용 |
| --- | --- | --- |
| 1 | 09:00~09:50 | 개요 · **1단계 강의** · 품질 규칙 |
| 2 | 10:00~10:50 | **Lab 01 실습 5개** · 눈으로 · 기준 검사 · 검사 워크플로우 · 경계 · 이미 있는 데이터 · 고침 목록 |
| 3 | 11:00~11:50 | **2단계 강의** · 품질 게이트 |
| 4 | 12:00~12:50 | **Lab 02 실습 5개** · 배치 게이트 · 격리 · LLM 검사 · 기준을 바꾸면 · 기록 · 알림 · LLM 호출 수 |
| - | 13:00~14:00 | 점심 |
| 5 | 14:00~14:50 | **3단계 강의** · 품질 관리 |
| 6 | 15:00~15:50 | **Lab 03 실습 5개** · 스키마 검사 · 고쳐서 다시 · 새 스키마 · 품질 보고서 · 데이터셋별 |
| 7 | 16:00~16:50 | 바이브 코딩 `tcheck`: 요청서 → TODO → SPEC → IMP-PLAN → 만들기 → 설치 |
| 8 | 17:00~17:50 | 발표 · **4단계 정리** (의미 · 효과 · 회사에서 쓰는 법) · 79일차 예고 |

---

## 4 / 30 · 오늘의 출발점: 같은 배치, 다른 판정

77일차에 와이파이 FAQ 한 줄이 답 못 한 질문 34건을 풀었습니다. 그래서 콘텐츠 담당자가 FAQ를 배치로 보내기 시작했습니다. 첫 배치 B-1, 13줄.

| 질문 | 규칙표를 들고 눈으로 | 팀의 기준 검사 · 가져오기 |
| --- | --- | --- |
| 넣어도 되는 줄? | **2줄** (분명히 나쁜 8 · 판단 보류 3) | **10줄** 통과 |
| 개인 전화번호 FAQ-109 | 나쁨 | 통과 |
| 바깥 링크 FAQ-110 | 나쁨 | 통과 |
| 실제로 FAQ에 들어간 것 | — | **12줄** (FAQ-003이 둘, 전화번호 · 단축 링크까지) |

나쁜 FAQ는 **답을 못 하는 것보다 나쁩니다** — 틀린 답을 자신 있게 보여 줍니다.

---

## 5 / 30 · 일하는 순서 (오늘은 "규칙 → 요청문 → 검사 → 확인")

```mermaid
flowchart LR
  A["① 먼저 보기<br/>눈 · call · test(전)"] --> B["② 규칙 · 요청문"] --> C["③ 에이전트<br/>my-work · check"] --> D["④ 내가<br/>push · test -v · quality"]
  D -->|"✘ has none of [코드]"| C
  D -->|✔| E["⑤ QUALITY.md 한 줄"]
```

| 누가 | 무엇을 |
| --- | --- |
| 나 | 나쁜 데이터를 찾고 규칙으로 정하기, 기준 정하기, 나쁜 데이터를 **고치기** |
| CLI 에이전트 | `AGENTS.md`대로 워크플로우 JSON, `check` |
| `flow.py` | `test --webhook`(기준과 비교), `quality`(FAQ · 격리함 · 기록 · 알림), `diff` |

---

## 6 / 30 · 실습 15개 (Lab마다 예제 3 · 과제 2)

| | 예제 1 | 예제 2 | 예제 3 | 과제 1 | 과제 2 |
| --- | --- | --- | --- | --- | --- |
| Lab 01 | 눈으로 검사 · 기준 검사 (에이전트 없이) | 검사 워크플로우 | 경계에서 재 보기 (에이전트 없이) | 이미 있는 데이터 | 고침 목록 |
| Lab 02 | 배치 게이트 · 격리 | LLM 검사 | 기준을 바꾸면 (에이전트 없이) | 품질 기록 · 알림 | LLM 호출 수 · 늘 같은가 |
| Lab 03 | 스키마 검사 | 고쳐서 다시 넣기 | 스키마만 바꾸면 (에이전트 없이) | 품질 보고서 | 데이터셋별 품질 |

---

## 7 / 30 · 1단계 · 데이터 품질이란

> 생활 속 예: 식당 주방의 아침 식재료 검수 — 상자가 비어 있지 않다고 받는 게 아니라, 라벨 · 온도 · 날짜 · 주문한 물건인지를 본다.

| 품질 차원 (업계에서 쓰는 말) | 뜻 | 오늘 B-1에서 |
| --- | --- | --- |
| 완전성 (completeness) | 빠진 칸이 없나 | 빈 제목 · 빈 답 · 빈 키워드 |
| 유효성 (validity) | 형식 · 길이 · 값의 범위 | id 두 자리 · 300자 넘는 답 |
| 고유성 (uniqueness) | 겹치지 않나 | 같은 배치에 FAQ-102가 둘 |
| 일관성 (consistency) | 이미 있는 데이터와 맞나 | 이미 있는 FAQ-003 · 같은 제목 |
| 정확성 (accuracy) | 내용이 맞나 | 토너 제목에 메일함 답 (LLM) |
| 안전 (보안 · 개인정보) | 내보내도 되나 | 개인 휴대전화 · 단축 링크 |

---

## 8 / 30 · 규칙은 말이 먼저

> 생활 속 예: 벽에 붙은 검수 기준표 — "라벨 없는 고기는 반품, 냉장품은 5도 이하". 주방장이 바뀌어도 판정이 같다.

| | 기준 검사 (`base-faq-check`) | 오늘의 규칙 (AGENTS.md 3절) |
| --- | --- | --- |
| 규칙 수 | 3 (빈 값만) | 10 (+ 과제에서 이미 있는 데이터 · LLM) |
| B-1 통과 | 10/13 | **5/13** — 눈으로 찾은 8줄과 같은 줄이 나쁨 |
| 목록이 아닌 본문 | 500 (Code가 터짐) | **400** |
| `lab01` 테스트 | 1/5 | **5/5** |

- 기준이 틀린 계산을 한 게 아니라 **규칙이 없었습니다.** 규칙을 요청문에 적으면 에이전트도 같은 판정을 냅니다.

---

## 9 / 30 · 오류 코드: 기계와 사람이 함께 읽는다

> 생활 속 예: 반품 상자에 붙이는 사유 스티커 — "온도"라고 짧게 붙여 두면 월말에 셀 수 있고, 납품업체에는 사유서로 풀어 쓴다.

| 같은 줄 | 코드 (기계가 셈) | 말 (사람이 고침, 과제 2) |
| --- | --- | --- |
| FAQ-103 | `title_missing` | 제목을 써 주세요 |
| FAQ-109 | `pii` | 개인 전화번호 · 메일 주소를 빼고 IT 포털 안내로 바꿔 주세요 |
| FAQ-003 | `exists_id` | 이미 있는 id입니다. 새 id를 쓰거나 … |

- 코드는 짧고 바뀌지 않음 → `codes`로 세고 Lab 03 보고서의 "가장 흔한 문제"가 됩니다. 말은 표 하나에서 — LLM으로 만들지 않습니다.

---

## 10 / 30 · 규칙은 Code가 확인한다

> 생활 속 예: 온도는 온도계가, 무게는 저울이 — 주방장의 감으로 재지 않는다.

| 판정 | 누가 | 까닭 |
| --- | --- | --- |
| 빈 값 · 길이 · 형식 · 중복 · 전화번호 형식 | **Code** | 정해진 답, 늘 같게, 0.1초 |
| 이미 있는 데이터 | Code + 데이터 API | 목록을 읽어 비교 |
| 답이 질문에 맞나 | **LLM** (Lab 02) | 뜻은 규칙으로 못 잼 |

- 13줄 검사 0.1초, LLM 없음. LLM에게 "이 FAQ 괜찮아?"를 물으면 날마다 판정이 다를 수 있고 줄마다 돈이 듭니다 (75일차).

---

## 11 / 30 · 경계에서 재 보기 (Lab 01 예제 3)

> 생활 속 예: 냉장고 온도 딱 5도 — 4도와 8도는 누구나 판정하지만, 5도와 5.1도는 기준표의 말("이하")이 정한다.

| 경계 | 규칙의 말 | 내 검사 | 기준 |
| --- | --- | --- | --- |
| 제목 40자 · 41자 | 40자 **넘으면** | ✔ 통과 · 막음 | ✘ 둘 다 통과 |
| 공백만 있는 제목 | 공백 = 빈 값 | ✔ 막음 | ✘ 통과 |
| `01012345678` · `02-123-4567` | 하이픈 **없어도** 휴대전화 | ✔ 막음 · 통과 | ✘ 둘 다 통과 |
| `intra.example.com.evil.io` | 호스트가 **정확히** | ✔ 막음 | ✘ 통과 |

- **6/6 대 0/6.** 강사의 첫 판도 `evil.io`를 통과시켰습니다 — "앞이 같나"만 보고 "끝나나"를 안 봄.

---

## 12 / 30 · 이미 있는 데이터와 맞춰 보기 (Lab 01 과제 1)

> 생활 속 예: 상자를 받기 전에 냉장고를 연다 — 어제 받은 우유가 그대로면 같은 칸에 넣지 않는다.

| 줄 | 배치 안만 보면 | 이미 있는 FAQ와 맞추면 |
| --- | --- | --- |
| FAQ-003 "VPN 접속 오류 (새 판)" | 통과 | `exists_id` (오류) |
| FAQ-112 "VPN 접속 오류" | 통과 | `same_title` (오류) + `keyword_used:vpn` (**경고**) |
| B-1 통과 | 5줄 | **3줄** |

- 오류는 막고, 경고는 알리고 통과. 모든 것을 막으면 아무것도 못 넣고, 다 통과시키면 검사가 의미 없습니다 (참조 무결성).

---

## 13 / 30 · 보낸 사람에게 돌려준다 (Lab 01 과제 2)

> 생활 속 예: 반품 사유서 — "3번 상자 · 라벨 없음". 다음 납품이 나아지는 것은 사유서 덕분이다.

```text
"message": "B-1: 13줄 중 3줄 통과, 10줄 고칠 것"
{"row": 3, "id": "FAQ-103", "codes": ["title_missing"], "fix": ["제목을 써 주세요"]}
{"row": 9, "id": "FAQ-109", "codes": ["pii"], "fix": ["개인 전화번호 · 메일 주소를 빼고 IT 포털 안내로 바꿔 주세요"]}
```

- 업계 이름: **데이터 계약**(data contract) — 보내는 쪽과 받는 쪽이 모양 · 규칙을 미리 약속하고, 어기면 이유와 함께 돌려보냄.
- 워크플로우는 **고쳐 주지 않습니다.** 빈 제목을 짐작해 채우면 틀린 FAQ가 "검사를 통과한 FAQ"가 됩니다.

---

## 14 / 30 · 1단계 정리 · 규칙

| 정한 것 | 오늘 |
| --- | --- |
| 무엇이 나쁜가 | 차원 여섯 · 코드 열둘 (AGENTS.md 3절) |
| 경계의 말 | 넘으면 · 공백 · 형식 · 정확히 |
| 막을 것 · 알릴 것 | 오류 vs 경고 |
| 누구에게 무엇을 | 기계에는 코드, 사람에게는 말 |

- 숫자: 기준 1/5 → 5/5, 경계 6/6 대 0/6, B-1 통과 10 → 5 → 3, 고침 목록 10줄.

---

## 15 / 30 · 2단계 · 검사와 게이트는 다른 일

> 생활 속 예: 검수(무엇이 상했나)와 반품 결정(그래서 트럭을 돌려보내나)은 다른 일이다.

```mermaid
flowchart LR
  W(["배치"]) --> C["검사<br/>my-faq-check 를 부름"] --> G{"나쁜 줄 비율<br/>≤ 기준?"}
  G -->|아니오| R(["422 · 아무것도 안 넣음"])
  G -->|예| S["줄마다<br/>ok → FAQ · 아니면 → 격리함"]
```

- 규칙을 다시 쓰지 않고 **검사를 부릅니다** — 규칙은 한 벌 (77일차 요약이 보고서를 부른 것처럼).

---

## 16 / 30 · 배치 게이트 · 줄 게이트 · 격리 (Lab 02 예제 1)

> 생활 속 예: 열에 일곱이 상했으면 트럭째 반품, 대부분 괜찮으면 좋은 것만 냉장고에, 이상한 것은 보류 칸에 사유를 붙여.

| 배치 | 기준 가져오기 | 내 가져오기 |
| --- | --- | --- |
| B-1 (나쁜 줄 10/13) | 12줄 넣음 | **422** · 0.7692 > 0.3 |
| B-2 (메일 주소 1) | 10줄 넣음 | 9줄 · FAQ-209 격리 · `score` 0.9 |
| B-3 (답 "짧") | 6줄 넣음 | 5줄 · FAQ-305 격리 |

- 격리함 = 버리지 않고 **이유와 함께** 보관 (76일차 DLQ와 같은 생각). 업계 이름: quarantine · dead-letter.

---

## 17 / 30 · LLM 검사 · 뜻은 LLM이 (Lab 02 예제 2)

> 생활 속 예: 무게 · 온도는 기준표로, "주문한 맛이 맞나"는 주방장이 한 숟가락 — 단, 이미 상한 것은 맛보지 않는다.

| | 규칙만 | + LLM |
| --- | --- | --- |
| FAQ-210 "모니터 밝기" · 답은 연차 휴가 | 넣음 | **격리** `llm_mismatch` |
| B-2 결과 | 9줄 · 0.9 | 8줄 · 0.8 |
| B-2 시간 | 1.4초 | **9.3초** (규칙을 통과한 9줄 × 1번) |

- 판정을 읽을 수 없으면 **넣지 않음** (fail-closed, 73일차). LLM이 막은 줄은 FAQ-210 **하나** — 드문 줄을 위해 줄마다 1초.

---

## 18 / 30 · 기준은 고르는 값 (Lab 02 예제 3)

> 생활 속 예: 반품 기준을 "열에 여덟까지"로 풀면 보류 칸이 넘치고, "하나도 안 돼"로 조이면 트럭이 다 돌아간다.

| 배치 | 기준 | 결과 |
| --- | --- | --- |
| B-1 | 0.3 | 거절 |
| B-1 | 0.8 | 받음 — 넣음 **2** · 격리 **11** (사람이 11줄을 봄) |
| B-2 | 0.05 | 거절 — 멀쩡한 9줄도 돌아감 |
| B-2 | 0.1 | 받음 — **같으면 통과** |

- 앞 배치가 넣은 FAQ가 다음 배치의 판정을 바꿉니다 (`same_title` · `exists_id`) — 실험은 하나씩 떼어서.

---

## 19 / 30 · 품질 기록 · 알림 (Lab 02 과제 1)

> 생활 속 예: 검수 일지와 사장님 호출 — 일지가 쌓여야 "요즘 그 업체가 나빠졌다"를 말하고, 트럭째 반품한 날은 바로 전화한다.

| 배치 | 응답 | 기록 | 알림 |
| --- | --- | --- | --- |
| B-1 | 422 | `rejected: true` · 0 | `batch_rejected` |
| B-2 | 200 · 0.8 | 8 · 2 · 0.8 | `low_quality` (0.9 미만) |

- 거절도 기록해야 보고서에 "가장 나쁜 배치"가 생깁니다. 알림은 곁가지 — 응답은 그대로 (`Result again`).

---

## 20 / 30 · LLM을 몇 번 · 늘 같은가 (Lab 02 과제 2)

> 생활 속 예: "오늘 맛보기 몇 번 했지? 상한 것까지 맛본 건 아니지? 어제와 오늘 판정이 같나?"

| 배치 | 줄 | `llm_calls` | 세 번 |
| --- | --- | --- | --- |
| B-1 (거절) | 13 | **0** | 같음 |
| B-2 | 10 | **9** | FAQ-210만 · 9.4 · 8.1 · 7.6초 |
| B-3 | 6 | **5** | 같음 |

- `--repeat`로 같은 배치를 연달아 보내면 2/6 — 판정이 흔들린 게 아니라 이미 넣은 FAQ 때문에 `exists_id`. "늘 같은가"는 **처음 상태에서** 세 번.

---

## 21 / 30 · 2단계 정리 · 게이트

| 정한 것 | 오늘 |
| --- | --- |
| 배치 · 줄의 두 관문 | 0.3 · `ok` |
| 버리지 않기 | 격리함 + 이유 |
| LLM은 어디에 | 규칙을 통과한 줄에만, 모르면 넣지 않음 |
| 기준의 대가 | 거절 ↔ 격리 ↔ 사람의 일 |
| 남기기 | 품질 기록 · 알림 · `llm_calls` |

- 숫자: 기준 0/6 → 5/6 → 6/6, B-1 12줄 → 0줄, FAQ-210 격리, 격리 13, LLM 9 · 5 · 0.

---

## 22 / 30 · 3단계 · 스키마: 규칙을 데이터로

> 생활 속 예: 품목마다 다른 검수 카드 — 채소 · 고기 · 생선마다 주방장을 두지 않고, 카드를 바꿔 들면 한 사람이 다 검수한다.

```json
{"name": "employee", "key": "email", "fields": {
  "dept": {"type": "enum", "required": true, "values": ["영업팀", "재무팀", "인사팀", "개발팀", "IT팀", "총무팀"]},
  "joined": {"type": "date", "required": true}, "phone": {"type": "phone", "required": false}, …}}
```

- 직원 CSV 9줄 → **4줄 통과** (메일 형식 · `마케팅팀` · `2026-13-01` · 이름 빈칸 · 메일 중복). 같은 워크플로우로 FAQ B-3 → 5/6.
- 업계 이름: JSON Schema · 테이블 정의 · Great Expectations의 "기대값".

---

## 23 / 30 · 스키마로 되는 것 · 안 되는 것

> 생활 속 예: 검수 카드에는 무게 · 온도 · 라벨 칸이 있지만, "이 납품업체와 이미 계약한 품목인가"는 장부를 봐야 안다.

| 규칙 | 스키마로 | 따로 |
| --- | --- | --- |
| 필수 · 길이 · 형식 · 목록 · 날짜 · 중복 | ✔ | |
| 답 안의 개인정보 · 바깥 링크 | | Code (Lab 01) |
| 이미 있는 데이터 | | Code + 데이터 API |
| 답이 질문에 맞나 | | LLM |

- 모양은 스키마로 **넓게**, 그 데이터만의 규칙은 Code로 **깊게**.

---

## 24 / 30 · 되돌림 고리 (Lab 03 예제 2)

> 생활 속 예: 라벨을 붙여 다시 가져온 고기를 받았으면 보류 칸의 옛 쪽지를 뗀다 — 안 떼면 내일 또 전화한다.

```mermaid
flowchart LR
  Q[("격리함<br/>FAQ-209 · 210")] -.->|사람이 고침| F(["B-2-fix"]) --> I["가져오기"] --> X["넣은 id만<br/>격리함에서 뺌"] --> Q
```

| | 고치기 전 | 고친 뒤 |
| --- | --- | --- |
| 넣기 | 2줄 · `score` 1 | 같음 |
| 격리함 | **2** (해결된 줄이 남음) | **0** |

---

## 25 / 30 · 스키마만 바꾸면 (Lab 03 예제 3)

> 생활 속 예: 디저트를 시작해 생크림이 들어온다 — 주방장을 새로 뽑지 않고 "생크림 카드" 한 장.

| 접수 건 9줄 | FAQ 검사 | 스키마 검사 (고치지 않음) |
| --- | --- | --- |
| 통과 | 0줄 (칸이 달라 모두 나쁨) | **2줄** |
| 이유 | `id_format` · `answer_missing` 9 | `T-12` · `urgent` · **2월 30일** · 3자 제목 · 연락처 형식 · 중복 · 요청자 빈칸 |

- 워크플로우를 한 줄도 고치지 않았습니다 — `ticket.json` 한 장. 그래서 **스키마 변경 = 규칙 변경**, 리뷰가 필요 (74일차 관문).

---

## 26 / 30 · 품질 보고서 · 품질도 정의가 먼저 (Lab 03 과제 1)

> 생활 속 예: 월말 검수 일지 정리 — "이번 달 어땠어?"에 늘 같은 방식으로 답한다.

| 칸 | 값 | 정한 것 |
| --- | --- | --- |
| 배치 · 평균 | 4 · **0.6583** | 거절(0)도 넣음 (빼면 0.8778) |
| 가장 나쁜 배치 | B-1 | 같으면 먼저 나온 것 |
| 가장 흔한 문제 | `pii` 2 | 같으면 코드 글자순 |
| 추세 | 좋아짐 | 마지막 − 첫 > 0.05 |

- 함정: 추세가 "13줄 거절 → 고친 2줄"을 비교한 것 — 숫자는 정의대로지만 **무엇을 비교했는지** 함께 말한다.

---

## 27 / 30 · 데이터셋별 · 평균이 가리는 것 (Lab 03 과제 2)

> 생활 속 예: 한 달 평균은 "괜찮다"인데 업체별로 나누면 생선 가게만 절반이 반품 — 전화할 곳은 생선 가게.

| 데이터셋 | 평균 | 가장 흔한 문제 |
| --- | --- | --- |
| employee (HR-1) | 0.4444 | `bad_format:email` |
| ticket (TK-1) | **0.2222** ← 가장 손볼 곳 | `bad_format:contact` |
| faq (B-3) | 0.8333 | `answer_too_short` |
| 전체 | 0.5 | — |

- 검사도 같은 모양으로 기록하니 보고서를 고치지 않고 셋이 보임. 섞은 추세는 뜻이 없음 — 추세는 데이터셋 안에서.

---

## 28 / 30 · 식당 주방으로 본 오늘 하루

> 생활 속 예: 오늘 만든 것이 모두 식당 주방에 있다 (3단계 8절 표).

| 오늘 | 주방 |
| --- | --- |
| 품질 규칙 · 오류 코드 | 검수 기준표 · 반품 사유 스티커 |
| 경계 | 냉장고 온도 딱 5도 |
| 이미 있는 데이터 · 고침 목록 | 냉장고 먼저 열기 · 반품 사유서 |
| 배치 게이트 · 격리 · 기준 | 트럭째 반품 · 보류 칸 · 반품 기준 |
| LLM 검사 · 호출 수 | 맛보기 · 맛보기 횟수 |
| 품질 기록 · 알림 | 검수 일지 · 사장님 호출 |
| 스키마 · 새 스키마 · 되돌림 | 품목별 검수 카드 · 생크림 카드 · 보류 칸 쪽지 떼기 |
| 보고서 · 데이터셋별 | 월말 일지 정리 · 업체별 성적표 |

---

## 29 / 30 · 7교시 바이브 코딩 · `tcheck`

요청서(인사팀 · 콘텐츠 담당의 말 ①~⑫) → `Doc/TODO.md` → `SPEC.md` → `IMP-PLAN.md` → 단계별로 → `uv tool install`.

| 오늘 n8n에서 | `tcheck`로 터미널에서 (보내기 전에) |
| --- | --- |
| `my-check` (스키마) | `tcheck check` — **같은 배치면 같은 판정** |
| 배치 게이트 | `tcheck gate --max-invalid 0.3` — 거절이면 종료 코드 4 |
| 격리 | `--out` 깨끗한 줄 · `--rejects` 나쁜 줄 + 이유 |
| 내용 규칙 · 고침 목록 · 품질 기록 | `--content answer` · `--fix` · `--log` (나중 단계) |
| (없음) | CSV · JSON · 요청 파일, TUI 탭 · 거르기 · 내보내기 |

- 강사 본: 직원 · 접수 건 · FAQ B-3의 `rows` · `codes`가 `my-check` 응답과 **모두 같음**, 직원 `tcheck gate` → 종료 코드 4, 테스트 22개 3초 (n8n 없이).

---

## 30 / 30 · 오늘의 정리 · 79일차 예고

| 단계 | 오늘 숫자 |
| --- | --- |
| 규칙 | 기준 10/13 통과 · 1/5 → 규칙대로 5/13 · 5/5, 경계 6/6 대 0/6, 이미 있는 데이터 3/13, 고침 목록 10줄 |
| 게이트 | 기준 가져오기 12줄 넣음 → B-1 거절 · B-2 9줄 · LLM이 FAQ-210, 기준 0.8이면 격리 11, LLM 호출 9 · 5 · 0 |
| 관리 | 직원 4/9 · 접수 건 2/9 (워크플로우 그대로), 격리 2 → 0, 평균 0.6583, ticket 0.2222가 가장 손볼 곳 |

- 8교시 [4단계 정리](04-STAGE4-WRAPUP.md): 의미 · 효과 · 업계 이름 · 면접 · 최종 프로젝트 체크리스트.
- 79일차 (11/4): **운영 데이터 기반 Workflow Ops Assistant** — 77일차 실행 기록 · 78일차 품질 기록 · 76일차 알림을 한데 모아, 운영자가 "지금 무엇이 문제야?"라고 물으면 숫자로 답하는 도우미를 만든다.