AI 에이전트에게 자기 결과물을 검토하라고 하면 거의 항상 "문제없다"고 답한다. 만든 과정을 기억하는 쪽은 결과를 그 의도대로 읽기 때문이다. 이 글은 만드는 에이전트(maker)와 검사하는 에이전트(checker)를 나누고 그 사이를 루프로 묶는 Maker–Checker 구조를, 실제로 운영 중인 교육 영상 제작 파이프라인과 HWP→DOCX 변환 파이프라인의 에이전트 정의를 근거로 정리한 것이다.
역할을 한눈에
| 역할 | 하는 일 | 쓸 수 있는 도구 | 하지 않는 일 |
|---|---|---|---|
| Maker | 결과물을 만들고, 지적받은 항목만 고친다 | 읽기, 쓰기, 실행, 검색 | 자기 결과를 "검수됨"이라 부르기, 배포 |
| Checker | 파일만 보고 PASS/FAIL을 판정한다 | 읽기, 실행(측정 스크립트) | 파일 수정, 렌더, 업로드 |
| Orchestrator | 둘을 부르고, 루프 횟수를 세고, 통과하면 배포한다 | 전부 | 판정 바꾸기 |
| 사람 | 루프가 끝나지 않을 때 결정한다 | — | — |
핵심은 세 가지다. checker는 만든 과정을 모르고, 고칠 권한이 없고, 판정 기준을 미리 받는다.
원칙 1: checker는 만든 과정을 모른다
영상 파이프라인의 checker 정의는 이렇게 시작한다.
You are the checker in a maker/checker pipeline for educational YouTube videos.
You did not make the video; assume nothing about how it was made.
Judge only from the files in the project folder.
maker가 "3번 장면은 일부러 이렇게 했다"고 설명하면 checker는 그 설명을 믿고 넘어가기 쉽다. 그래서 checker의 입력은 결과물 폴더뿐이다. maker의 설명은 "어디를 보면 되는지"를 알려 주는 용도로만 쓰고, 판정의 근거로 쓰지 않는다.
같은 이유로 checker는 새로 띄운다. maker와 같은 대화에서 검토를 시키면 이미 본 의도가 판단에 섞인다.
원칙 2: 검사하는 쪽은 고칠 수 없다
Claude Code 서브에이전트는 정의 파일의 tools로 쓸 수 있는 도구를 제한한다.
---
name: video-checker
description: CHECKER for the topic-video-youtube skill. (...) Read-only; never edits files,
never renders, never uploads, never reads video files.
tools: Bash, Read, Grep, Glob
---
Edit와 Write가 없으니 checker는 문제를 찾아도 직접 고칠 수 없다. 고칠 수 있으면 checker가 슬쩍 고치고 PASS를 주는 일이 생기고, 그러면 무엇이 바뀌었는지 아무도 모른다.
반대로 maker 정의에는 "자기 작업을 검수됐다고 말하지 않는다", "업로드하지 않는다"를 적는다. 되돌리기 어려운 일(업로드, 발행, 삭제)은 checker가 PASS를 준 뒤 오케스트레이터만 한다.
원칙 3: 측정을 먼저, 판단은 그다음
checker가 눈으로만 보면 매번 기준이 달라진다. 그래서 숫자로 잴 수 있는 것은 스크립트가 먼저 잰다. 영상 checker는 장면별 음량, 첫머리 소리 처짐, 자막과 소리의 시작 차이, 화면 숫자와 내레이션의 일치 같은 항목을 스크립트로 재고, 결과를 보고서에 그대로 옮긴다. 정의에는 "FAIL을 누그러뜨리지 않는다(Do not soften a FAIL)"가 적혀 있다.
측정만으로 끝내면 안 되는 경우도 있다. HWP→DOCX 변환 checker 정의의 한 줄이 그 이유를 말한다.
Automated checks prove presence, not visibility.
글자가 XML 안에 있어도 잘리거나, 흰 바탕에 흰 글씨거나, 도형 뒤에 숨어 있을 수 있다. 그래서 자동 검사를 통과해도 페이지 이미지를 눈으로 비교하는 단계를 반드시 거친다. 측정은 놓치는 것을 줄이고, 눈 검사는 측정이 볼 수 없는 것을 잡는다.
원칙 4: FAIL과 WARN의 기준을 미리 정한다
"괜찮아 보인다"는 판정이 아니다. 무엇이 FAIL이고 무엇이 WARN인지 정의에 적어 둔다.
| 파이프라인 | FAIL | WARN |
|---|---|---|
| 교육 영상 | 측정 항목 FAIL, 사실이 SPEC과 다름, 화면 숫자가 내레이션과 다름, 금지 항목 등장 | 장면 음량이 다른 장면보다 2~4 dB 차이 나는 것 같은 측정 WARN |
| HWP→DOCX | 글자·표·병합 누락, 색·테두리 누락, 머리말 누락, 잘림·겹침 | 작은 위치 차이, 셀 안 줄바꿈 차이, maker가 기록한 결정 사항 |
규칙은 단순하게 둔다. FAIL이 하나라도 있으면 전체 FAIL, WARN만 있으면 메모를 붙여 PASS. WARN을 FAIL로 올리기 시작하면 루프가 끝나지 않는다.
원칙 5: 고칠 수 있게 보고한다
checker 보고서는 maker가 다시 전체를 살펴보지 않고 바로 고칠 수 있어야 한다. 영상 checker의 보고 형식은 이렇다.
판정: PASS | FAIL
측정: (측정 스크립트 출력 줄)
문제 (심각한 것부터):
- [FAIL|WARN] s07: 무엇이 틀렸는지 — 근거(타임코드, 대본 문장, 화면 글자) — 고칠 곳(SCRIPT.md / scenes.json / prompts/07)
확인하지 못한 것: (예: 렌더된 영상은 보지 않음)
문제마다 위치(장면 번호), 근거, 고칠 파일이 붙는다. 마지막 줄의 "확인하지 못한 것"은 PASS가 무엇을 보장하지 않는지를 사람에게 알려 준다. 이 줄이 없으면 PASS를 "전부 확인됨"으로 읽게 된다.
루프 운영: 같은 maker, 좁은 재검수, 최대 3번
판정 뒤의 흐름도 정해 둔다. 영상 스킬의 규칙을 정리하면 다음과 같다.
FAIL이면
- 문제 목록을 같은 maker에게 이어서 보낸다(Claude Code에서는 SendMessage). 새 maker를 띄우면 스킬 문서를 처음부터 다시 읽어 느리다.
- maker는 지적된 항목만 고치고, 항목마다 무엇을 바꿨는지 목록으로 돌려준다.
- maker는 측정 FAIL에 반박하지 않는다. 판정이 틀렸다고 생각하면 이유를 한 줄 남기고 오케스트레이터에게 맡긴다.
- checker는 지적했던 항목과 바뀐 부분만 다시 본다. 전부 다시 보면 매번 새 문제가 나와 끝나지 않는다.
횟수 제한
- 최대 3번 돈다. 그래도 FAIL이면 남은 문제를 사람에게 보고하고 멈춘다. 같은 문제가 반복되면 maker가 고칠 수 없는 원인(잘못된 입력, 도구 한계)일 가능성이 크다.
검수 위치
- 비싼 단계 앞에 둔다. 영상은 렌더 전에 대본·타이밍·사실·발음을 검수한다. 렌더 뒤에 문제를 찾으면 고칠 때마다 렌더를 다시 해야 한다.
checker 정의 시작 템플릿
새 파이프라인에 붙일 때는 아래 틀에서 시작한다.
---
name: <작업>-checker
description: CHECKER for <작업>. Independently verifies <결과물> against <기준 파일>
and returns PASS/FAIL with concrete issues. Read-only; never edits files.
tools: Bash, Read, Grep, Glob
---
You did not make this output; assume nothing about how it was made.
Judge only from the files on disk. Never modify, regenerate or publish anything.
## 1. Measured checks (run first, copy the lines, do not soften a FAIL)
## 2. Visual / semantic checks (what measurement cannot see)
## 3. Verdict rules
- FAIL: <목록>
- WARN: <목록> — WARNs alone give PASS with notes.
## 4. Re-check after a fix: only the reported issues and the parts the maker says it changed.
## Report format
판정 / 측정 / 문제(위치 — 근거 — 고칠 곳) / 확인하지 못한 것
자주 하는 실수
- checker에게 수정 권한을 준다. 고친 내용이 기록되지 않고 판정을 믿을 수 없게 된다.
- maker의 설명을 checker 입력으로 넘긴다. checker가 의도를 읽고 결과를 너그럽게 본다.
- 기준 없이 "검토해 줘"라고만 한다. 판정이 실행마다 달라지고 루프가 수렴하지 않는다.
- 재검수 때 전부 다시 본다. 매번 새로운 사소한 지적이 나와 끝나지 않는다.
- 횟수 제한이 없다. 고칠 수 없는 문제에서 토큰만 쓰며 계속 돈다.
- 배포 뒤에 검수한다. 되돌리기 어려운 결과가 이미 밖에 나가 있다.
점검표
- checker 정의에 "만든 과정을 가정하지 않는다"가 있다
- checker의
tools에 Edit·Write가 없다 - maker 정의에 "자기 결과를 검수됐다고 하지 않는다", "배포하지 않는다"가 있다
- 측정 스크립트가 있고 checker가 그 출력을 그대로 보고한다
- 측정이 못 보는 것(보이는지, 뜻이 맞는지)을 보는 단계가 있다
- FAIL과 WARN의 목록이 정의에 적혀 있다
- 보고서에 위치·근거·고칠 곳과 "확인하지 못한 것"이 있다
- 재검수 범위가 지적 항목과 바뀐 부분으로 제한된다
- 루프 최대 횟수와, 넘었을 때 사람에게 넘기는 규칙이 있다
- 검수가 비싸고 되돌리기 어려운 단계 앞에 있다
Maker–Checker 루프의 힘은 에이전트를 둘로 늘린 데서 나오지 않는다. 검사하는 쪽이 만든 과정을 모르고, 고칠 수 없고, 정해진 기준으로만 판정하게 만든 데서 나온다.
댓글 0개
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.