제작 에이전트와 검수 에이전트를 분리하니 실패 지점이 보였다
답부터 말하면 제작자와 검수자를 나누는 이유는 문장을 더 매끈하게 만들기 위해서가 아니다.
공개를 막아야 할 오류를 이름 붙이고, 수정한 뒤에만 통과시키기 위해서다.
2026년 9월 23일의 독립 검수 기록에서는 구체적인 수정 요구 4건이 나왔다.
제작자가 고친 뒤 같은 범위로 다시 검수했고, 그제야 판정이 REVISE에서 PASS로 바뀌었다.
왜 잘 쓰는 에이전트에게 검수까지 맡기면 안 될까?
문제는 작성자가 자신의 전제를 이미 알고 있다는 점이다.
문장이 자연스러우면 빠진 조건도 머릿속에서 자동으로 보완한다.
검수자는 그 전제를 공유하지 않아야 한다.
원고와 근거 파일을 대조하고, 현재형 주장인지 과거 기록인지, 절차가 실제로 끝까지 이어지는지 따로 확인해야 한다.
2026년 9월 14일 결정 기록도 이 구분을 택했다.
익명 비교에서 deep(장시간 작업하는 제작 에이전트) 제작본은 사실 정확성과 유용성이 각각 5 대 4로 앞섰고, 리드(작업을 나누고 검증하는 주 에이전트) 제작본은 가독성이 4 대 3으로 앞섰다.
그래서 제작은 deep, 검증은 리드가 맡는 구조로 정했다.
이 수치는 모델의 보편적 우열이 아니다.
당시 여섯 글로 누가 더 잘 쓰는지를 비교한 운영 기록이며, 검수를 분리하면 오류가 준다는 증거는 아니다.
같은 조건의 재평가도 아직 하지 않았다.
| 구분 | 제작자가 주로 보는 것 | 독립 검수자가 확인할 것 | 통과 조건 |
|---|---|---|---|
| 원고 | 설명의 흐름과 독자 질문 | 주장과 근거의 일치 | 근거 없는 현재형 주장이 없음 |
| 절차 | 단계가 자연스럽게 읽히는지 | 실제 실행에 빠진 단계가 없는지 | 같은 경로를 끝까지 따라갈 수 있음 |
| 용어 | 문맥 안에서 이해되는지 | 식별자·버전·범위가 일관적인지 | 같은 대상을 같은 이름과 범위로 설명함 |
| 판정 | 초안 완성 | REVISE 또는 PASS | PASS 전에는 발행하지 않음 |
독립 검수는 실제로 무엇을 잡았나?
한 번의 검수에서 잡힌 수정 항목은 네 가지였다.
맞춤법보다 주장 범위와 실행 조건에 가까운 문제였다.
| 적발 유형 | 검수에서 발견한 문제 | 수정한 내용 |
|---|---|---|
| 시점 범위 | 하네스 구조 일부만 과거 관찰로 표시해 나머지가 현재 사실처럼 읽힘 | 에이전트 수, 프롬프트 파일, 에디션, 기여 순위와 README 인용까지 2026-09-09 dev 브랜치의 역사적 관찰로 묶음 |
| 실행 절차 | API 키 위치를 확인하고 다시 로그인하라고 했지만, 활성 환경에서 키를 먼저 해제하는 단계가 빠짐 | 개인 환경의 키를 해제하고 셸·IDE 재주입을 확인한 뒤 로그인하도록 순서를 명시함 |
| 식별자 근거 | 표의 축약 모델명과 본문의 긴 모델명이 달라 같은 파일인지 검증한 것처럼 보임 | 축약 표기와 Q8 표기가 과거 본문에서 온 것임을 밝히고 digest를 확인하지 않았다고 적음 |
| 보안 범위 | '목록에 없으면 못 보고', '안 막히면 아무 일도 일어나지 않는다'는 두 문장이 deny 목록·훅·분류기의 판정을 한 층으로 뭉침 | deny 목록 층과 원격 전용 훅으로 범위를 좁히고, 미차단 명령은 실행 결과와 오류를 확인하도록 고침 |
네 항목은 서로 다른 글에서 나왔다.
그래도 공통점은 있다고 본다.
문장은 자연스러웠지만 주장에 붙은 시점·범위·순서·식별자가 빠져 있었다.
그중 훅과 벤치마크 항목은 새로 쓴 문장이 아니라 원문에 남아 있던 표현이었다.
다른 날짜의 검수에서는 무엇이 나왔나?
같은 구조의 기록 두 건을 더 확인했다.
모두 초안의 완성도 점수가 아니라, 근거와 수정 범위를 다시 확인한 사례다.
| 검수 시각 | 오류 유형 | REVISE에서 확인한 문제 | PASS 조건 |
|---|---|---|---|
| 2026-09-23 02:53→02:59 KST | 조건 누락 | 금리 글에서 우대금리 종료 시점이 빠짐 | 종료 조건을 두 문장으로 보완하고, 그 두 문장을 제거했을 때 이전 SHA-256 해시가 복원되는지 확인함 |
| 2026-09-28 KST | 출처·산술·시의성 | 원문 PDF 수치와 계산을 다시 확인하고, 공식 원문이 없는 최신 수치와 미지원 주장을 구분해야 했음 | 81.5%·78.8%와 100-80=20을 재확인하고, 4분기 수치는 언론 보도로 한정하며 확인할 수 없는 60.4%는 제외함 |
첫 사례는 수정 문장뿐 아니라 변경 범위까지 해시로 확인했다.
두 번째 사례는 숫자가 맞아도 출처의 시점과 공개 상태가 다르면 같은 사실로 묶지 않았다.
REVISE와 PASS 사이에는 무엇이 있어야 하나?
검수 의견만 받았다고 게이트가 끝난 것은 아니다.
수정 사실을 다시 확인하지 않으면 REVISE는 조언 목록으로 남는다.
당시 후속 검수는 새 자료를 넓히지 않았다.
처음 검토한 파일과 이미 지정된 근거 로그만 다시 읽었다.
네 수정이 재생성된 결과물에 들어갔는지 확인하고, 이전 지적이 남아 있지 않을 때 PASS를 냈다.
내 기준에서는 이 제한이 중요하다.
재검수 때 새 문제를 끝없이 찾기 시작하면 게이트가 아니라 범위가 계속 움직이는 감사가 된다.
발행 게이트는 어떤 순서로 만들면 될까?
- 제작자는 원고와 근거 파일을 함께 넘긴다.
근거가 없는 수치는 미확인으로 남긴다. - 검수자는 제작자의 설명이 아니라 실제 원고와 근거를 읽는다.
판정은 PASS와 REVISE 중 하나만 쓴다. - REVISE에는 고칠 위치, 문제인 주장, 통과 조건을 적는다.
“더 명확하게” 같은 문장만 남기지 않는다. - 제작자는 지적된 범위만 고치고 결과물을 다시 만든다.
수정하면서 새 측정값을 만들지 않는다. - 검수자는 같은 근거 범위에서 수정 반영을 확인한다.
PASS가 기록되기 전에는 발행 단계로 넘기지 않는다.
이 구조는 F1의 차량 검사와 닮았다.
차를 만든 팀이 빠르다고 말하는 것과 규정을 통과하는 것은 다른 일이다.
다만 글 검수에는 하나의 고정 규정집이 없으므로, 무엇을 통과 조건으로 삼을지 작업 시작 전에 적어야 한다.
언제 이 결론이 뒤집히나?
이번 글에서 확인한 표본도 2026년 9월 23일 두 건과 9월 28일 한 건, 세 차례 검수 기록뿐이다.
오류 유형의 빈도나 검수 정확도로 일반화할 수 없다.
정확한 검수 비용과 시간은 이 기록에서 측정하지 않았다.
사람 검수와 비교한 누락률도 없고, 같은 원고를 게이트 유무로 나눈 A/B 결과도 없다.
따라서 역할 분리가 항상 더 싸거나 모든 오류를 잡는다고 말할 수는 없다.
짧고 되돌리기 쉬운 내부 메모라면 별도 검수 비용이 더 클 수 있다.
반대로 보안 절차, 가격, 모델 식별자처럼 틀린 문장이 그대로 복사될 글이라면 PASS 전 발행 차단의 가치가 커진다.
omo 하네스의 역할·모델 라우팅 구조를 먼저 보면 제작 역할을 어떻게 나누는지 이해하기 쉽다.
보안 주장의 범위를 잡는 사례는 Claude Code 훅의 로컬 적용 범위에 남아 있다.
감점제 brutal-review는 프롬프트로 점수를 매기는 리뷰어를 다룬 글이다.
이번 글은 점수보다 REVISE→수정→PASS가 발행을 막는 게이트라는 점이 다르다.
결론 · PASS가 발행을 막아야 한다
제작과 검수 분리는 역할 수를 늘리는 일이 아니라 발행 조건을 분명히 만드는 일이다.
되돌리기 어려운 글일수록 독립 검수가 구체적인 수정 요구를 남기고, 같은 범위의 재검수에서 PASS를 받아야 다음 단계로 보낸다.
지금 할 일은 발행 명령 앞에 PASS가 없으면 중단 조건을 두고, 원고와 근거 파일을 함께 넘기는 것이다.
댓글
댓글 쓰기