3줄 요약
- 발행글 12편을 서브에이전트 2기에게 6편씩 나눠 같은 평가축(고유성·구체성·정확성과 시의성·구조·진정성, 각 5점)으로 감사시켰고, 평균은 25점 만점에 15.1점이었다(2026-08-16).
- 두 기는 서로의 결과를 보지 못한 채 각자 독립적으로 같은 결론에 도달했다 — "재방문할 이유가 없다."
- 그런데 잡아낸 결함은 달랐다. 감사 A는 사이트 내부 가격 모순(월 약 2만원 대 약 29,000원)을, 감사 B는 통계 재활용(같은 수치 하나가 서로 다른 세 주장에 근거로 쓰인 것)을 잡았다.

이 글대로 하면 무엇이 달라지는가: "내 글 어때?"라고 물어 좋은 말을 듣는 대신, 점수와 인용이 붙은 결함 목록을 받아 무엇부터 고칠지 정할 수 있게 된다.

자기가 쓴 콘텐츠를 자기가 검사하면 왜 뚫리는가?

검사자가 작성 시의 판단 맥락을 그대로 갖고 있으면, 오류를 오류가 아니라 이미 내린 결정으로 인식하기 때문이다. 이 실패는 순서대로 일어난다.

오진 1단계. 글을 쓴 세션에 그대로 "이 글 문제 없나 검토해 줘"라고 시켰다. 돌아온 답은 대체로 통과였다. 왜 틀렸나. 그 세션은 어떤 수치를 왜 그렇게 썼는지, 어떤 표현이 왜 괜찮다고 판단했는지를 컨텍스트에 갖고 있다. 검사 시점에도 그 판단이 남아 있으면 검사자는 작성자의 결정을 다시 승인하게 된다. 자기비판을 요구해도 마찬가지다. 비판의 근거로 삼을 기준 자체가 작성 시의 기준이다. 진짜 원인. 문제는 성실성이 아니라 컨텍스트의 공유였다. 대책. 검사를 신선한 컨텍스트를 가진 별도 에이전트에게 맡긴다. 작성 맥락이 없는 에이전트는 글을 처음 읽는 독자와 같은 위치에서 판단한다.

교차 감사(cross audit)란 작성 맥락을 공유하지 않는 둘 이상의 검사자에게 같은 평가축을 주고 서로의 결과를 보지 못한 상태로 판정하게 하는 방식이다. 핵심은 기수가 아니라 컨텍스트 격리에 있다.

교차 감사 하네스는 어떻게 설계했는가?

평가축을 숫자로 고정하고, 좋게 봐주려는 기울기를 세 조항으로 막고, 반환 형식을 못 박았다. 아래가 실제로 쓴 하네스의 골격이다.

# 대상 (이 목록 밖은 읽지 마라)
| # | URL | 제목 |
|---|---|---|
| 1 | ... | ... |
받은 문서의 제목이 위 표와 다르면 잘못 받은 것이다. 그 사실을 보고에 적고 다시 받아라.

# 평가축 (각 5점, 합 25점)
1. 고유성 — 다른 데서 못 읽는 내용인가
2. 구체성 — 읽은 사람이 자기 환경에서 해 볼 수 있는가
3. 정확성과 시의성 — 수치·버전·주장에 근거와 시점이 있는가
4. 구조 — 첫 화면에서 결론이 잡히는가
5. 진정성 — 겪지 않은 일을 겪은 것처럼 쓰지 않았는가

# 판정 규율
1. 좋게 봐주지 말 것.
   - 애매하면 감점 방향으로 판단한다.
   - "괜찮은 편이다" 같은 정성적 호평 대신 축별 점수와 근거를 낸다.
2. 경미한 발견도 전부 보고하고 확신도를 붙일 것.
   - "이 정도는 넘어가도 된다"는 판단을 감사자가 대신 하지 않는다.
   - 각 발견에 확신도(높음/중간/낮음)를 표기한다.
3. 본문 인용 1개 필수.
   - 모든 지적에는 해당 문장을 그대로 인용한다.
   - 인용 없는 지적은 채택하지 않는다.

# 반환 (본문을 붙여넣지 마라)
- 글별: 축5 점수 · 합계 · 발견 목록(인용 + 확신도)
- 마지막: 6편 전체를 관통하는 결론 1문단

세 조항은 각각 다른 기울기를 막는다. 1번은 감사자가 무난한 호평으로 흐르는 것을, 2번은 감사자가 중요도 필터링을 대신 해 버리는 것을, 3번은 감사가 인상 비평이 되는 것을 막는다. 특히 2번은 리뷰형 위임에서 반복 확인된 성향에 대한 보정이다. 감사자에게 중요도를 걸러 내게 하면 경미해 보이는 발견이 조용히 사라지고, 그 판단은 후속 검증 단계(메인 세션)의 몫이어야 한다.

이 감사를 그대로 재현하려면 무엇을 하는가?

절차는 여덟 단계다. 순서를 바꾸면 비용이나 정확도 중 하나를 잃는다.

1. 감사 대상 목록을 URL과 제목 쌍으로 만든다. URL만 주면 캐시가 엉뚱한 문서를 돌려줘도 알아채지 못한다. 실측에서 이 한 줄 차이가 도구호출 22회와 11회를 갈랐다.
2. 편수를 나눈다. 12편을 2기에 6편씩 배분했다. 기수는 특별한 규정이 없으면 5기 이내로 잡는다.
3. 팬아웃 전에 대화를 압축한다. 에이전트를 여러 기 띄우기 전에 압축해 두면 이후 확인 턴이 전부 싸진다. 띄운 뒤에 압축하면 늦다.
4. 하네스를 위 골격대로 쓴다. 평가축·판정 규율 3조항·반환 형식을 그대로 넣는다.
5. 백그라운드로 띄우고 상태를 되묻지 않는다. 완료 알림은 자동으로 온다. 확인 턴 하나가 전체 컨텍스트를 다시 태운다.
6. 결과가 오면 점수표부터 본다. 축별 점수가 있으므로 어느 축이 낮은지가 바로 보인다. 우리 경우 평균 15.1/25였다.
7. 메인이 한두 항목을 직접 재확인한다. 감사자의 완료 보고를 그대로 믿지 않는다.
8. 개선점을 운영 로그에 남긴다. 이번 감사의 개선점은 "다음 감사부터 글 목록은 URL과 제목 쌍으로 제공"이었고, 그대로 고정 조항이 됐다.

3번과 5번은 감사 자체의 품질과 무관해 보이지만 비용에 직접 걸린다. 이 감사 2기가 쓴 토큰과 도구호출의 실측치는 서브에이전트 1기의 실제 단가에 정리했다.

서로 다른 두 기가 같은 결론에 도달했다는 것은 무엇을 뜻하는가?

결론이 특정 감사자의 취향이 아니라 콘텐츠 전반의 구조적 문제라는 신호로 읽었다. 두 기는 서로의 감사 결과를 볼 수 없는 상태에서 각자 다른 6편을 검토했다. 그런데도 둘 다 같은 문장으로 결론을 냈다 — "재방문할 이유가 없다." 서로 다른 글, 서로 다른 지적 사항을 보고도 같은 문장에 도달했다는 것은 그 결론이 특정 지적 하나에 기댄 것이 아니라는 뜻이다. 평균 점수는 25점 만점에 15.1점이었다.

반대로 두 기의 결론이 갈렸다면 어떻게 하는가. 점수 자체가 갈릴 때는 각 기가 인용한 근거 문장을 대조한다. 판정 규율 3번(본문 인용 필수)이 여기서 값을 한다. 인용이 없으면 대조할 것이 없어 어느 쪽이 맞는지 판단할 방법이 없다.

두 기가 각각 잡아낸 서로 다른 결함은 무엇이었는가?

담당 편수를 나눴기 때문에 두 기가 본 글 자체가 달랐고, 그만큼 잡아낸 결함의 종류도 달랐다.

감사 A가 잡은 것은 한 사이트 안에서의 자기모순이고, 감사 B가 잡은 것은 출처 없는 수치의 돌려쓰기다. 두 결함의 공통점은 한 편만 읽어서는 드러나지 않는다는 것이다. 가격 모순은 두 편을 나란히 대조해야 보이고, 통계 재활용은 같은 숫자가 세 곳에 등장한다는 것을 기억하고 있어야 보인다. 그래서 감사자에게 여러 편을 함께 주는 설계 자체가 이 결함들을 잡아낸 조건이었다.

감사 결과를 그대로 믿지 않으려면 무엇을 해야 하는가?

감사자가 완료를 보고해도 메인이 기계로 다시 센다. 사람이 읽어야만 판정되는 완료 기준은 조용한 실패를 만든다. 실제로 발행 에이전트가 "성공"을 보고했는데 오브젝트 키 접두어를 잘못 붙여 이미지가 전부 404였던 사고가 있었다. 데이터베이스 삽입은 성공했고 로그도 성공이었다. 그 뒤로 제작·발행·검사를 서로 다른 에이전트로 갈랐다.

감사와 검증에 쓰는 확인 목록은 아래와 같다.

• [ ] 완료 기준을 기계가 셀 수 있는 형태로 썼는가(grep -c로 세는 패턴, HTTP 상태 코드 확인 등)
• [ ] 감사자가 인용한 문장이 실제로 그 글에 있는가(한두 건 표본 확인)
• [ ] 감사자가 받은 문서의 제목이 요청한 제목과 같은가
• [ ] 발견 목록에 확신도가 붙어 있는가
• [ ] 점수만 있고 근거 인용이 없는 항목은 채택 보류로 뺐는가
• [ ] 감사자가 지적하지 않은 축에 대해서도 메인이 한 건은 직접 봤는가

# 감사자 보고를 기계로 재확인하는 최소 검사 예
grep -c "McKinsey\|Gartner\|Harvard" 대상.md     # 외부 기관 통계 인용 0건인가
grep -n "한 적이 있었다\|직접 써보니" 대상.md      # 창작 체험담 문형이 남았는가
curl -o /dev/null -w "%{http_code}\n" <이미지 URL>  # 200인가 (재시도 후 판정)

마지막 줄에 "재시도 후 판정"을 붙인 이유가 있다. 다른 배치에서 개발 서버 첫 컴파일 지연 때문에 curl이 상태 코드 000을 돌려준 사례가 있었다. 한 번의 깨끗한 실행만으로 통과를 선언하지 않는다는 규율이 여기에도 적용된다.

기계 검증을 완료 기준에 넣으면 부수 효과가 하나 더 있다. 다른 배치에서 완료 기준에 특정 패턴이 0행인지 세는 검사와 색상 값 화이트리스트 검사를 넣었더니, 에이전트가 스스로 규격 이탈과 컴파일 실패를 잡아 왔다. 기계로 검사할 수 있는 완료 기준이 품질을 만든다. 또 하네스에 "왜 이렇게 했는지 주석으로 남길 것"을 요구했더니 지시에 없던 실제 문제까지 스스로 발견해 보고하는 일이 있었다. 판단 근거를 적게 하면 판단이 정교해진다.

이 하네스가 잡지 못하는 것은 무엇인가?

나눈 경계를 넘어서는 모순이다. 12편을 6편씩 갈랐기 때문에, A가 맡은 글과 B가 맡은 글 사이에 있는 자기모순은 원리상 어느 쪽도 볼 수 없다. 감사 A가 가격 모순을 잡은 것은 그 두 글이 마침 같은 기에 배정됐기 때문이다. 만약 한 기가 12편을 전부 봤다면 교차 결함이 더 잘 보였을 수 있지만, 그러면 이번 설계의 다른 이득(독립 결론의 상호 검증)을 잃는다. 이 절충을 어떻게 보완할지가 다음 라운드 하네스의 과제로 남았다.

두 번째 한계는 외부 요인이다. 감사 A는 CDN 캐시 오류로 3편을 엉뚱한 글과 대조할 뻔했다. 제목 대조로 스스로 교정했지만 그 과정에서 도구호출이 두 배가 됐다. 대상 문서가 캐시나 리다이렉트를 거쳐 전달되는 환경이라면, 목록에 검증 가능한 식별자를 함께 넣지 않은 감사는 잘못된 대상을 감사하고도 그 사실을 모를 수 있다.

세 번째는 비용이다. 이 방식은 감사 대상 원문을 에이전트가 처음부터 다시 읽는 것을 전제하므로, 짧은 글 한두 편을 보는 데 쓰기에는 과하다. 반대로 원문이 크고 반환할 결론이 작은 감사에서는 격리 이득이 커진다. 이번 감사의 전체 결과와 그 뒤 무엇을 바꿨는지는 AI 두 기에게 발행글 12편을 감사시킨 결과에서 다뤘다.

자주 묻는 질문

Q. 감사자를 2기로 나눈 이유는 무엇인가?
A. 결론이 특정 감사자의 개인적 판단인지 구조적 문제인지 구분하기 위해서다. 서로의 결과를 보지 못하는 두 기가 같은 결론을 내면 구조적 문제일 가능성이 높다고 판단했다. 실제로 두 기 모두 "재방문할 이유가 없다"로 수렴했고 평균은 15.1/25였다.

Q. 자기 검사와 교차 감사의 차이는 무엇인가?
A. 자기 검사는 작성 시의 판단 맥락을 그대로 갖고 있어 오류를 이미 내린 결정으로 인식한다. 교차 감사는 작성 맥락이 없는 별도 에이전트가 맡아 처음 읽는 독자의 위치에서 판단한다.

Q. "본문 인용 1개 필수" 조항은 왜 넣었나?
A. 인용 없는 지적은 인상 비평이 되기 쉽고 검증도 어렵기 때문이다. 인용을 요구하면 지적이 구체적인 문장에 묶이고, 두 기의 판정이 갈렸을 때 근거 문장을 대조할 수 있다.

Q. 감사 결과가 서로 다르게 나오면 어떻게 하나?
A. 각 기가 인용한 근거 문장을 대조해 다시 검토한다. 이번 사례에서는 결론이 같았고 잡아낸 결함만 달랐다. 결함이 다른 것은 담당 편수를 나눈 설계의 결과이지 판정의 불일치가 아니다.

Q. 이 하네스를 다른 콘텐츠 감사에도 쓸 수 있나?
A. 판정 규율 3조항(좋게 봐주지 않기·경미한 발견도 보고·본문 인용 필수)과 반환 형식은 콘텐츠 유형과 무관하게 옮길 수 있다. 평가축의 구체적 항목은 감사 대상에 맞게 바꾸고, 나눈 경계를 넘는 모순은 이 방식으로 잡히지 않는다는 점을 감안해 배분을 설계한다.