AI에게 문서나 앱을 만들게 하면, 그럴싸한 결과물이 순식간에 나옵니다. 문제는, 실수도 똑같이 "그럴싸하다"는 것입니다.

• 숫자의 근거가 한 세대 전의 계산 결과 그대로 남아 있음
• 표의 굵은 글씨(＝최상이라고 여겨지는 값)가 본문의 결론과 정반대인 대상에 붙어 있음
• "수정했습니다"라고 선언된 추가 내용이, 치환 실수로 인해 실제로는 들어있지 않음

이것들은 모두 제 환경에서 실제로 일어난 일입니다. 그리고 까다로운 점은, 만든 본인(AI)에게 재검토를 시켜도 통과되어 버린다는 것입니다. 자신의 선입견과 함께 검토하기 때문입니다. 인간 작성자가 자신의 원고에서 오타를 못 보고 지나치는 것과 동일한 구조가 AI에게도 그대로 일어납니다.

이 기사는 그 해결책으로서 도달한, 「집필 AI와 검수 AI를 별개의 인격으로 세우는」 체계의 설계와, 그대로 사용할 수 있는 검수 에이전트 정의(Claude Code용)에 관한 이야기입니다.

해결책은 프롬프트가 아니라 「체계」

처음에는 집필 프롬프트를 다듬어서 대처하려고 했습니다. "출력 전에 재검토해", "수치를 재확인해". 효과는 한정적이었습니다. 작성한 모델 자신의 컨텍스트에는 "자신이 올바르게 작성했다는 전제"가 스며들어 있기 때문입니다.

효과가 있었던 것은 인간 조직과 같은 발상이었습니다. 집필과 교열을 별개의 인격으로 나누는 것입니다.

집필 담당(author)
↓ 결과물
검수 담당(reviewer)…… 내용·수치·논리의 독립 검사
...

Claude Code라면, 이것은 ~/.claude/agents/에 Markdown 파일을 두는 것만으로 실현할 수 있습니다. 프론트매터(Frontmatter)에 이름과 설명을, 본문에 일본어 직무 기술서를 작성합니다. 그것만으로 메인 대화와 독립된 컨텍스트를 가진 별개의 인격으로서 기동할 수 있습니다.

포인트는, 검수를 통과하지 못한 것은 "완성"이라고 부르지 않는다라는 규칙을 집필 담당의 정의 파일 자체에 써넣는 것입니다. 체계는 대화 속의 약속이 아니라, 정의 파일이라는 형태로 영속됩니다(대화의 기억은 사라지지만, 파일은 남습니다).

실례: 판매 개시 직후에 일어난 사고와, 체계를 구축한 후의 변화

솔직하게 쓰겠습니다. 이 체계는 사고가 나기 전이 아니라 후에 구축했습니다.

개인 개발한 데스크톱 앱(Booth에서 판매 중)에서, 판매 개시 직후에 파괴적인 조작(파일 삭제 계열)의 확인 다이얼로그가 프레임워크의 사양 때문에 실제로는 한 번도 표시되지 않았던 것이, 개발 환경에서 실제 파일이 확인 없이 삭제되는 실질적인 피해 사고로 발각되었습니다. 제작자 테스트에서는 "확인이 뜨는 것을 전제로 한 조작 순서"로만 다루기 때문에 계속해서 빠져나갔던 것입니다. 다행히 결함 버전의 다운로드는 0건이라 고객 피해는 없었고, 그날 안에 수정 버전으로 교체되었습니다만——정말 식은땀이 나는 경험이었습니다.

이 사고를 계기로 대응을 "고치고 끝"내는 것이 아니라, ① 규칙으로 명문화 → ② 정적 검사(Static Inspection)에 추가 → ③ 해당 사고 클래스를 매번 실측하는 출하 게이트(Shipping Gate)에 추가, 라는 삼중 구조로 만들었습니다. 확인 다이얼로그는 현재 출하할 때마다 적대적 QA(파괴하는 것만을 목적으로 샌드박스에서 날뛰는 에이전트)가 실제로 조작하여 검증하고 있습니다.

체계를 구축한 직후의 효과도 구체적이었습니다. "이 앱을 처음 접하는 실제 이용자로서, 처음부터 끝까지 사용해 보고 보고하라"라는 리뷰어 AI를 처음 투입했더니, 제작자 테스트를 전부 통과했던 상태에서 실제 결함이 5건 나왔습니다. 설정이 재시작 시 되돌아가는 케이스, 아무 말 없이 실패하는 조작——모두 "만든 본인은 절대로 밟지 않을" 종류의 결함이었으며, 이번에는 사용자에게 전달되기 전에 잡아낼 수 있었습니다.

리포트 작성에서도 같은 형식이 통한다

문서 측면에서도 검수 AI는 동일하게 기능합니다. 제 환경에서 검수 AI가 실제로 검출한 것들(일반화하여 작성합니다):

표시 로직의 버그: 표의 "최상"을 나타내는 굵은 글씨가 일률적으로 "절댓값 최소"로 붙어 있어, "이상치에 가까울수록 좋다"는 열에서는 본문의 결론과 정반대인 대상이 강조됨 -
선언된 수정의 미구현: "◯◯를 추가했다"라고 된 변경 사항이, 치환 대상 문자열의 미묘한 불일치로 인해 빗나가 실제 본문에는 존재하지 않음 -
그림과 본문의 모순: 본문의 설명이 생성된 그림을 실제 데이터와 대조했을 때 성립하지 않음

모두 작성자의 자기 신고 리뷰에서는 절대 나올 수 없는 지적입니다. 독립적으로 재계산·재대조하기 때문에 발견되는 것입니다.

검수 AI의 설계 원칙은 3가지

시행착오 끝에, 검수 에이전트의 직무 기술에서 결정적으로 효과가 있었던 것은 다음 3가지였습니다.

① 자신의 언어로 재요약하는 것을 의무화한다. 검수 보고서의 서두에 "대상 각 장을 자신의 언어로 1~2문장으로 요약할 것. 요약할 수 없는 장이 있다면 그것 자체가 가장 중요한 지적 사항(독자도 이해하지 못함)"이라고 적는다. 이는 "읽었다는 증명"입니다. 이것이 없으면 검수 AI는 대상을 훑어본 채 그럴듯한 일반론적인 지적만을 나열합니다.

② 수치는 「확인했다」가 아니라, 독립적으로 재계산한 숫자를 내놓게 한다. "최소 N건, 소스 데이터로부터 재계산하여 대조 로그(본문 값 vs 재계산 값 표)를 첨부할 것". 대조 로그를 의무화하면 검수의 질이 눈에 띄게 달라집니다.

③ 판단 가능성 테스트. "각 장에 대해 『이것을 읽은 사람은 내일 무엇을 결정할 수 있는가』를 한 문장으로 쓰시오. 쓰지 못하는 장은 불합격". 결과물이 "그럴듯하지만 쓸 수 없는" 상태로 떨어지는 것을 방지하는 마지막 보루입니다.

그리고 또 하나, 운용상의 가장 중요한 사항. 검수 AI도 내버려 두면 칭찬하고 싶어 합니다. 직무 기술서의 서두에 "당신의 업무는 통과시키는 것이 아니라 탈락시키는 것", "칭찬은 불필요, 지적만 할 것"이라고 명시하십시오. 사양하는 검수는 검수 누락과 같습니다.

비용에 대해서도 솔직히 말씀드리면, 검수 1회 순환은 나름대로 토큰과 시간을 소모합니다. 모든 결과물에 적용하는 것이 아니라, 「외부로 나가는 것」 한정이 현실적인 운용 방식입니다.

여기까지라면 체계를 직접 구축할 수 있을 것입니다. 여기서부터는 「그대로 사용할 수 있는 파일과 운용 규칙」——검수 에이전트 정의 전문, 검수 측의 품질을 담보하는 6가지 항목(복수 리뷰어 운용의 최소 기준), 15분 도입 절차입니다.

그대로 사용 가능: 리포트 검수 에이전트 정의 (전문)

~/.claude/agents/report-reviewer.md

로 저장하십시오. 어떤 프로젝트에서든 실행할 수 있습니다.

---
name: report-reviewer
description: 리포트·문서 검수 전담. 형식·수치 재계산·도표 대조·판단 가능성 테스트를 수행함. 생성·개정 시마다 사용.
...

커스터마이징해야 할 3곳

• 절차 2의 「형식」: 당신의 문서 양식(장 구성·정형 문구)이 있다면 구체적으로 작성한다. 없다면 이대로 두어도 좋다.
• 절차 5의 질문: 독자를 구체화하면(예: 「경영 회의에 참석하는 부장님은」 등) 지적이 날카로워진다.
• 재계산 건수와 소스: 데이터가 작다면 「전수 조사」로 높인다. 소스의 형식(CSV/DB/API)을 명시한다.

검수 측의 품질을 담보하는 6가지 항목 (복수 리뷰어 운용의 최소 기준)

검수 AI를 여러 명 세우는 경우(리뷰 패널 방식), 리뷰어 스스로 태만해지는 것을 방지하는 공통 규칙이 필요합니다. 각 리뷰어의 프롬프트에 다음 내용을 붙여넣으십시오. 저의 운용 방식에서는 이것으로 "읽은 척하는 리뷰"가 사라졌습니다. 위의 에이전트 정의와 겹치는 항목이 있지만, 이것은 "어떤 관점의 리뷰어에게도 공통으로 부과하는 최소 기준"이라는 위치에 있습니다.

리뷰어 자신의 검수 기준 (충족하지 못하는 보고는 재실행시킬 것):
1. 서두에 대상의 핵심 결론을 자신의 언어로 3줄 요약하여 작성한다.
작성할 수 없다면 「요약 불가능」이 해당 보고의 가장 중요한 지적 사항이 된다.
...

보충 팁:

• 검산 계열의 리뷰어에게는 반드시 데이터 경로와 실행 환경을 전달하며 "검산하라"고 적는다. 전달하지 않으면 일반론만 답변합니다.
• 처음 보는 사람의 가독성을 보는 리뷰어에게는 의도적으로 배경 정보를 주지 않는다 (첫 독서 경험을 재현하기 위함입니다).
• 2회차 이후의 검수에서는 "이전 지적 사항은 반영된 것으로 되어 있으나, 맹신하지 말고 실물을 확인하라"고 적는다.

선언된 수정 사항이 구현되지 않은 사고는 이 방법으로 잡아낼 수 있습니다.

15분 도입 절차

• 배치 (2분): 위의 정의를 ~/.claude/agents/report-reviewer.md에 저장.
• 첫 검수 (10분): 가지고 있는 문서로 실행——

"report-reviewer로서, ◯◯(경로)를 검수하라. 수치 소스는 ◯◯. 실행 환경은 ◯◯"

※ 에이전트 목록에 나타나지 않는 경우 Claude Code를 재시작하십시오.

• 지적 사항 처리 (3분): 지적 사항을 「즉시 수정」과 「다음으로 미룸」으로 분류하고, 수정했다면 재검수합니다.

중대한 지적이 0이 될 때까지 배포하지 않는다——이를 완료의 정의로 삼으십시오.

익숙해지면 집필 측에도 전담 에이전트(양식 계약을 직무에 포함한 author)를 세워,

"author → reviewer를 거친 후 인간에게 보여준다"를 표준 흐름으로 만들면 체계가 완성됩니다.

예고

집필 담당·결점 찾기 감사인(예상 문답 자동 생성)·PDF 레이아웃 검수까지 포함된 완전 키트를,

반응을 보고 Booth에서 출시할 예정입니다. 이 기사가 도움이 되었다면, '좋아요'를 통해 알려주세요. 향후 판단을 위한 중요한 자료가 됩니다.

Discussion