AI가 검사자 역할을 할 때 절대 시키면 안 되는 네 가지

문제: 검사자가 작가로 변하는 순간

AI로 글을 만드는 흔한 구조는 두 단계다. 한 모델이 초안을 쓰고, 다른 모델이 그 초안을 검사한다. 필자가 운영하는 콘텐츠 파이프라인도 이 형태다. 초안은 한 모델이 쓰고 검사는 다른 모델이 맡는, 초안자 ≠ 검사자라는 규칙을 지킨다.
이 구조에서 가장 흔히 예상되는 실패는 검사자가 조용히 작가로 변하는 것이다. "이 문장이 어색하니 이렇게 고치는 게 낫다"며 통째로 다시 써서 돌려주는 경우다. 얼핏 친절해 보이지만 이건 검사가 아니라 재작성이다. 검사자가 재작성을 하면 그 결과물은 아무도 검사하지 않은 새 글이 되어버린다. 검사 단계 자체가 무력화된다.

이 글은 필자가 docs/content-generation-contract.md라는 문서에 명문화한 "검사자가 절대 하면 안 되는 일"을 독자가 자기 파이프라인에 그대로 적용할 수 있게 정리한 것이다. 이 계약은 블로그 에이전트와 쇼츠 에이전트가 공통으로 참조하는 정본으로 신설했고, 두 위험 — 초안자의 할루시네이션과 검사자의 월권 — 을 동시에 막는 것을 목표로 한다.

---

왜 위험한가: 검사자의 월권과 초안자의 할루시네이션

멀티모델 파이프라인의 위험은 크게 두 갈래다.

• 초안자의 할루시네이션: 원문에 없는 사실, 지어낸 수치, 없던 경험을 그럴듯하게 만들어낸다.
• 검사자의 월권: 판정만 해야 할 검사자가 재작성을 하거나 새 사실을 덧붙인다.

두 번째가 특히 교묘하다. 검사자가 "더 매끄럽게" 고치면서 원문에 없던 문장을 넣으면, 그 새 문장은 어떤 검증도 거치지 않은 채 최종본에 남는다. 즉 검사자가 스스로 새로운 할루시네이션의 출처가 되는 것이다. 검사자에게 재작성 권한을 주면 그 재작성분을 다시 검증할 단계가 추가로 필요해질 수 있고, 검사와 재작성이 뒤섞이면 통과를 미루는 왕복이 늘어날 위험이 있다.
그래서 필자는 계약 문서에 최우선 불변식으로 할루시네이션 제로를 걸었다. 문체가 좋든 훅이 강하든, 무근거 주장이 하나라도 있으면 그것으로 통과를 막는다. 문장력으로 상쇄할 수 없는 최상위 규칙이라는 뜻이다. 계약 문서에서 이 규칙은 문체·훅 같은 다른 품질 기준보다 위 서열에 놓여, 아무리 잘 쓴 글이어도 근거 없는 주장 하나로 되돌려진다.

---

검사자에게 시키면 안 되는 네 가지

계약 문서에 명시한 검사자의 절대 금지 항목은 다음과 같다. 참고로 검사자는 이 금지선 안에서 4축 점검을 수행하도록 계약에 정해져 있다.

1. 재작성: 검사자는 원문을 고쳐 쓰지 않는다. 문제를 지적할 뿐 대신 써주지 않는다.
2. 원문에 없는 사실 추가: 검사 과정에서 새 수치·사례·주장을 보태지 않는다.
3. 취향 트집: "내 스타일이면 이렇게" 같은 개인 선호를 지적으로 포장하지 않는다. 사실·근거 문제를 우선하고, 단순 선호는 지적으로 올리지 않기를 권한다.
4. 무한 왕복: 같은 지적을 반복하며 통과를 미루는 핑퐁을 하지 않는다.

이 네 가지를 말로만 금지하면 지켜지기 어렵다. 핵심은 출력 스키마로 강제하는 것이다. 검사자의 출력은 "지적 + 원문 인용"만 담을 수 있게 형식을 제한했다. 재작성한 문장을 담는 전용 필드가 없으면 검사자가 완성된 대체 문장을 정식으로 제출할 통로가 사라져 재작성이 억제된다.

{
  "verdict": "revise",
  "issues": [
    { "claim": "월 300만원 수익", "source_quote": "(원문에 근거 없음)" }
  ]
}

위 스키마에서 검사자는 문제가 된 주장(claim)과 그 근거가 원문 어디에 있는지(source_quote)만 적는다. 근거를 못 찾으면 그 자리에 "근거 없음"이 남고, 그 항목 하나만으로 verdict는 revise로 강제된다. 스키마 어디에도 "고쳐 쓴 문장"을 넣는 칸은 두지 않았다는 점이 핵심이다.

---

claim-to-source 추적: 무근거 주장 잡는 절차

할루시네이션 제로를 실행하는 구체적 방법이 claim-to-source 추적이다. 검사자가 밟는 순서는 이렇다.

1. 초안에서 사실 주장(수치·사례·인용·경험)을 하나씩 뽑아낸다.
2. 각 주장에 대해 원문(source) 어느 문장이 근거인지 찾아 인용한다.
3. 근거 문장을 못 찾은 주장이 하나라도 있으면 즉시 verdict = revise로 판정한다.
4. 지적 목록을 구조화 JSON으로 출력한다. 이때 고쳐 쓴 문장은 넣지 않는다.

이 절차의 핵심은 3번이다. 무근거 주장이 단 하나라도 있으면 문체·훅이 아무리 좋아도 통과시키지 않는다. 예외를 두지 않는 대신, 판정 기준을 "원문에 근거가 있는가"라는 검증 가능한 형태로 고정했다.

검사 통과했는데 없던 수치가 있다	검사자가 새 사실 추가	최종본 주장별로 원문 인용 매칭
검사 결과물이 초안과 통째로 다르다	검사자가 재작성함	diff로 문장 단위 변경량 확인
계속 revise만 나오고 진행 안 됨	취향 트집·무한 왕복	지적이 사실 근거 문제인지 선호 문제인지 분류

---

적용 체크리스트

자기 파이프라인에 옮길 때 확인할 항목이다.

• 초안자와 검사자를 서로 다른 모델(또는 사람)로 분리했는가?
• 검사자 출력에 재작성 문장을 담을 전용 칸이 없도록 스키마를 제한했는가?
• 검사자가 각 주장의 근거를 원문에서 인용하게 만들었는가?
• 무근거 주장 1개 → 자동 revise 규칙을 넣었는가?
• 같은 지적 반복 시 종료 조건(왕복 상한)을 정했는가?
• 규칙을 정본 문서 한 곳에 두고, 각 에이전트에는 포인터 한 줄만 두어 드리프트를 막았는가?

마지막 항목은 실전에서 중요하다. 필자는 규칙 본문을 계약 문서 한 곳에만 두고, 블로그 에이전트와 쇼츠 에이전트의 AGENTS.md에는 그 문서를 가리키는 포인터 한 줄만 추가했다. 이는 GLOBAL-RULES를 다루던 방식과 같다. 규칙을 여러 곳에 복사하면 한쪽만 고쳤을 때 서로 어긋나는 드리프트가 생기기 때문이다.

---

한계와 주의사항

이 방식이 만능은 아니다. 몇 가지 한계를 명확히 해둔다.

• 검사자도 틀린다. 검사자가 근거 있는 주장을 근거 없다고 오판할 수 있다. 무근거 판정이 반복되면 사람이 한 번 더 확인해야 한다.
• "근거 없음"이 항상 거짓은 아니다. 원문 범위 밖의 상식·공개 사실은 원문에 인용 문장이 없어도 참일 수 있다. 이 경우 원문 범위를 어디까지로 볼지 사전에 정해야 한다.
• 스키마 제한만으로 완벽하지 않다. 재작성 전용 필드를 없애 재작성을 억제해도, 검사자가 지적 문구(claim이나 설명) 안에 슬쩍 완성 문장을 끼워 넣는 우회가 가능하다. 지적은 문제 서술까지만 쓰도록 예시를 함께 제공하는 게 좋다.
• 이 글의 규칙은 필자가 계약 문서로 명문화한 설계다. 다양한 도메인·모델에서의 운영 결과는 이 기록의 범위 밖이므로, 작은 테스트 케이스로 먼저 돌려보고 확대하기를 권한다.

정리하면, 검사자에게 시키면 안 되는 일은 재작성·새 사실 추가·취향 트집·무한 왕복 네 가지다. 이 금지를 말이 아니라 출력 스키마와 자동 판정 규칙으로 강제할 때 비로소 검사 단계가 제 역할을 한다.