8.8 KiB
8.8 KiB
7·8교시 · 바이브 코딩 (tcheck)
- 교시: 7교시 16:00
16:50 (각자 만들기), 8교시 17:0017:50 (발표 10분 · 4단계 정리 35분 · 예고 5분) - 과제: VIBE-REQ-TCHECK(요청서, 요청의 말 ①~⑫) → VIBE-Q-TCHECK의 8단계:
Doc/TODO.md→Doc/SPEC.md→Doc/IMP-PLAN.md(엔진 · TUI 단계) → 단계별 구현 → 확인 →uv tool install→ 다른 폴더에서 사용 → 수업 뒤VIBE-A-TCHECK.md공개 - 요구 14개(R1~R14). 50분 안에는 엔진 1단계(R1 · R2 · R3 · R4 · R12 · R13) + 엔진 2단계(R5 · R6 · R7) + TUI 1단계(R11) + 설치(R14), 나머지(R8 내용 규칙, R9 고침 목록, R10 품질 기록)는 IMP-PLAN의 다음 단계로 집에서.
- 72일차
tbench부터 77일차tlog와 같은 흐름입니다: 사람의 말(요청서)을 확인할 수 있는 요구로 바꾸는 일을 학생이 먼저 하고, VIBE-Q는 그 다음 단계(비교 대상)로 씁니다. 에이전트에게는 처음 요청 한 번과 "확인했고 commit 했어. 다음 단계." 한 줄만 씁니다. - 오늘은
tcheck: CSV · JSON(오늘 요청 파일 모양 포함)을 데이터 API의 스키마로 검사해 n8nmy-check와 같은 판정을 내고, 깨끗한 줄 · 나쁜 줄을 따로 내보내고, 배치 게이트를 종료 코드로 알리고, TUI로 탭을 나눠 보는 도구. 오늘 n8n 워크플로우로 한 일을 보내기 전에, 내 노트북에서.
flowchart LR
R["요청서 → TODO · SPEC ·<br/>IMP-PLAN 20분"] --> A["7교시<br/>엔진 1 · 2 · TUI · 설치 30분"] --> B["발표<br/>10분"] --> C["4단계 정리<br/>35분"] --> F["79일차 예고<br/>5분"]
생활 속 예 · 주머니에 넣는 검수 카드. 오늘 주방(n8n)에 검수 기준표와 반품 칸을 만들었습니다. 납품업체가 "보내기 전에 창고에서 미리 검수하고 싶다"고 합니다. 같은 검수 카드를 주머니에 넣어 창고에서 쓰게 하면 됩니다. 핵심은 창고와 주방의 판정이 "같다"는 것입니다.
이 문서는 7 · 8교시 진행 문서입니다. 8교시의 정리 35분은 04-STAGE4-WRAPUP으로 합니다.
1. 7교시 · 각자 만들기 (50분)
| 시간 | 단계 | 확인 |
|---|---|---|
| 16:00~16:09 | 0 준비 · 1 요청서 → Doc/TODO.md (에이전트 없이) |
할 일 ①~⑫ · 꼭 / 나중 |
| 16:09~16:15 | 2 Doc/SPEC.md → VIBE-Q 요구 표(R1~R14)와 비교 · commit |
요구마다 확인 방법 (직원 4/9 · 접수 건 2/9 · 줄마다 코드, 종료 코드) |
| 16:15~16:20 | 3 Doc/IMP-PLAN.md (엔진 1~3단계 · TUI 1단계 · 설치) · commit |
단계마다 체크리스트 |
| 16:20~16:44 | 4 구현: 엔진 1단계 → 엔진 2단계 → TUI 1단계, 막히면 5 문제 해결 팁 | 단계마다 pytest · 직접 실행 · commit |
| 16:44~16:50 | 6 확인 · 7 uv tool install --editable . · 8 다른 폴더에서 tcheck |
tcheck check …/employees-new.json --url http://localhost:8800 = my-check의 판정 |
| 볼 것 | 막혔을 때 한마디 |
|---|---|
| TODO · SPEC 없이 VIBE-Q를 통째로 붙여 넣었나 | "요청서로 Doc/TODO.md부터. 직원 4/9가 SPEC에 없으면 맞았는지 모릅니다" |
| IMP-PLAN이 한 덩어리 · 첫 요청에 14개 | "엔진 1단계만. 단계마다 확인 · 체크 · commit" |
| 판정이 n8n과 다름 | "어느 줄 · 어느 코드가 다른지 붙여 주고, AGENTS.md 3절 스키마 표 그대로" |
필드 이름이 코드에 (if name == "email") |
"스키마의 fields를 돌며 type마다" — 오늘 Lab 03 예제 3 |
2026-02-30 · 2026-13-01이 통과 |
"실제 있는 날짜인지까지" |
빈 전화번호가 bad_format |
"선택 칸은 비었으면 형식을 보지 않음" |
| 테스트가 진짜 API를 부름 | "가짜 서버(http.server)와 스키마 · n8n 결과 사본으로" |
gate가 늘 0 |
"넘으면 거절, 거절이면 종료 코드 4, 같으면 통과" |
| 실행해 보지 않고 다음 요청 | "에이전트가 됐다고 해도 직접 uv run tcheck …; echo $?" |
정답 예(R1~R14를 모두 넣은 tcheck와 정답본 VIBE-A-TCHECK.md)는 수업 뒤 공개됩니다.
2. 8교시 · 발표 (10분)
- 1~2명.
tcheck check --json과my-check의 판정이 같다는 것을 보여 줄 수 있는 사람,tcheck gate의 종료 코드 4를 보여 줄 수 있는 사람을 먼저 고릅니다. - 3분 발표 · 2분 질문: 내 SPEC과 VIBE-Q가 달랐던 곳 / IMP-PLAN을 어떻게 나눴나 / 처음 요청 · 고쳐 달라는 요청문 / 에이전트가 틀린 곳(판정이 달랐던 줄) / 시연.
3. 강사 정리 (8교시 4단계 정리 안에서)
| n8n (오늘 Lab) | tcheck | |
|---|---|---|
| 읽기 | 웹훅 본문 (items · csv) |
파일: .csv · JSON 목록 · {"items"} · 요청 파일 (R1) |
| 규칙 | my-check의 Check rows (스키마) |
checks.check — 같은 타입 판정, 같은 코드 (R2 · R3 · R4) |
| 내용 규칙 | my-faq-check (Lab 01) |
--content answer (R8) |
| 게이트 | my-faq-import의 Batch ok? (Lab 02) |
tcheck gate · 종료 코드 4 (R7) |
| 격리 | /quarantine |
--out · --rejects (R6) |
| 고침 목록 | Lab 01 과제 2 | --fix (R9) |
| 품질 기록 | Lab 03 과제 2 | --log (R10) |
- 풀이 거리: 강사 본은 직원 HR-1 · 접수 건 TK-1 · FAQ B-3에서
rows·codes·valid가my-check와 하나도 다르지 않았습니다. Pythonre의\w는 한글도 맞아 메일 판정이 JavaScript와 다를 수 있었고(re.ASCII), 날짜를 꼴만 보면 2월 30일이 통과합니다. "같은 규칙을 두 곳에 쓰면 반드시 어긋난다 — 그래서 n8n 안에서는 검사를 다시 부르고, 밖에서는 테스트로 같은 판정을 확인한다." - 같은 FAQ B-1을
tcheck --schema faq --content answer로 보면 Lab 01 예제 2의 8줄과 같은 줄이 나쁩니다 — 코드 이름만 다릅니다 (title_missing↔missing:title).
4. 강사 바이브 코딩 (시간이 남으면 · 수업 뒤, 15분)
| 주제 | 요청문 요지 | 보여 줄 것 |
|---|---|---|
| pre-commit 훅 | "저장소에 faq/*.json을 커밋할 때 tcheck gate --schema faq --content answer가 4면 커밋을 막는 pre-commit 훅" |
보내기 전 검사를 개발 흐름에 |
| 스키마 버전 비교 | "tcheck diff-schema old.json new.json: 같은 파일로 두 스키마의 판정이 달라지는 줄" |
스키마 변경 = 규칙 변경, 리뷰 근거 |
| 이미 있는 데이터 | "--existing http://localhost:8800/faq-all로 exists_id · same_title" |
Lab 01 과제 1을 도구로 |
걸린 시간과 결과를 Last3Mon/78/VIBE-A-TCHECK.md에 적어 둡니다.
5. 보충 · 팁 (읽을거리, 4단계 정리 7절과 함께)
| 팁 | 설명 |
|---|---|
| 요청서 → 요구가 먼저 | 확인 방법(기대 판정 · 종료 코드 · JSON 칸)이 있는 요구가 있어야 에이전트의 "완료"를 판단할 수 있음 |
| 기대 판정은 이미 있다 | 오늘 cases/lab03.json · lab03-schema.json의 판정을 SPEC과 테스트에 그대로 |
| n8n의 답을 사본으로 | call my-check의 응답을 tests/data/에 두면 n8n 없이도 "같은가"를 시험 |
| 규칙은 한 곳 | 판정 함수는 checks.py에만, JSON · 파일 · 게이트 · 화면은 부르기만 |
| 필드 이름을 코드에 쓰지 않기 | 스키마가 늘어도 코드는 그대로 |
| 정규식도 정의 | 다른 언어와 판정을 맞출 때는 \w · \d의 뜻까지 |
| 종료 코드로 말한다 | 0 · 1 · 2 · 4 — 스크립트 · pre-commit · CI가 다음 일을 정함 |
단계마다 git commit |
에이전트가 망가뜨려도 돌아갈 곳 |
6. 79일차 예고 (5분)
- 오늘: 들어오는 데이터를 규칙으로 검사하고 · 막고 · 격리하고 · 기록했습니다. 다음 수업(79일차, 11/4): 운영 데이터 기반 Workflow Ops Assistant 구현 — 77일차 실행 기록, 오늘의 품질 기록, 76일차 알림을 한데 모아, 운영자가 "지금 무엇이 문제야?"라고 물으면 숫자로 답하는 도우미를 만듭니다.
- 바이브 코딩: 오늘
tcheck와 77일차tlog는 지우지 마세요. 79일차tops에서 씁니다.
확인 (강사)
- 16:00 요청서 → TODO(에이전트 없이) → SPEC → IMP-PLAN 20분을 지켰다, 16:20부터 엔진 1단계.
- 7교시 시작 전 n8n에
my-check(Lab 03 예제 1 이상)가 게시돼 있어 판정 비교를 할 수 있다. - 수업 뒤: 요청이 있을 때 학생 저장소에 정답(LAB-A ·
answers/· VIBE-A ·tcheck/)을 올린다. - 발표자 1~2명, 강사 정리 표, 팁, 예고.
- 수업이 끝날 때 학생들의 데이터 API가 처음 상태인지 (
quality --reset,doctor).