AI 2대로 크로스 리뷰하여 기술 기사의 맹점을 찾아내기

서론

개인이 Zenn에 기술 기사를 작성할 때, Claude Code와 Codex CLI를 역할 고정 방식으로 크로스 리뷰 (Cross-review) 시키는 운용 방식을 사용하고 있습니다. 본 기사는 해당 운용을 통해 실제로 찾아낸 지적 패턴과, 하네스(Harness)화하기 전에 겪었던 실패의 기록입니다.

여기서 말하는 Codex CLI는 구형 Codex 언어 모델이 아니라, OpenAI의 openai/codex 리포지토리에서 공개된 로컬 실행 코딩 에이전트(Coding Agent)를 가리킵니다.

단 한 대의 AI에게 쓰게 하고 바로 공개하던 시절에는, 공개 후에 "이 부분은 사실 오인(Fact error)이었다", "마무리가 AI스러웠다"라고 깨닫는 일이 계속되었습니다. 같은 AI에게 "당신이 작성한 이 기사를 리뷰해줘"라고 부탁해도, 직전의 컨텍스트 (Context)에 휘말려 자연스럽게 판정해 버립니다. 작성 측과 다른 AI를 거치는 게이트 (Gate)를 공개 전에 반드시 두는 방식으로 바꾸자, 자신의 맹점이 언어화되어 남게 되었습니다.

참고로, 동일 시리즈의 선행 글인 "Claude Code 운용을 몇 달 만에 재검토하여 rules와 skills로 나눈 이야기"에서는 크로스 리뷰를 운용 변천의 한 요소로서 가볍게 언급했습니다. 본 기사에서는 그 부분을 단독 테마로 분리하여, 과거의 handoff (핸드오프) 과정에서 찾아낸 지적 패턴 4종과, 하네스화하기 전에 겪었던 실패 3종을 1차 정보 수준에서 깊이 있게 다룹니다.

왜 1대만으로는 부족한가

자신이 쓴 기사를 스스로 교정할 수 없는 것과 동일한 구조적 문제가 AI 1대에게도 존재합니다. 작성 직후의 컨텍스트에 따라 읽기 때문에, 사실 오인, 정형화된 마무리 문구, 홍보성 내용 등을 "자연스럽다"라고 판정합니다.

실례를 3가지 나열합니다.

사실 오인 (Fact error): 어떤 비교 기사에서 "한쪽 리포지토리에는 1종류만 존재한다"라고 주장했습니다. 작성자는 셀프 리뷰를 통과했지만, 다른 AI에게 맡겼더니 "현재의 기본 브랜치(Default branch)에는 양쪽의 파생형이 존재한다. 구형 커밋을 암묵적으로 참조한 채 본문에서 단정적으로 말하고 있다"라고 지적받았습니다. 같은 AI에게 재독하게 해도 처음의 전제를 끌어오는 쪽으로 치우칩니다.

참조 링크의 404: 동일한 기사의 참조 링크가 GitHub의 blob/<기본 브랜치명> 형식으로 작성되어 있었으나, 대상 리포지토리의 기본 브랜치명과 일치하지 않아 전부 404 에러가 발생했습니다. 작성한 AI는 "일반적인 이름이니까 자연스럽다"라고만 판정했습니다. 이 또한 작성자와 다른 AI가 기계적으로 Git 호스팅의 실태를 확인했기에 잡아낼 수 있었습니다.

도메인 용어 누락: 다른 기사에서 업무 도메인 고유의 어휘를 포함한 Enum 명칭(DomainSpecificTraining, ApplicationProcess 상당)을 샘플 코드에 사용했습니다. 작성한 AI는 "업무 캘린더 샘플로서 자연스럽다"라고 판정했지만, 다른 AI가 "특정 도메인의 어휘가 드러나 있다"라고 검출했습니다. 이를 EventCategory.Work / Meeting / Training과 같은 범용 명칭으로 교체했습니다.

역할을 고정한다 (작성자 ≠ 리뷰어)

크로스 리뷰의 규칙은 심플합니다.

• Codex가 작성한 기사는 Claude Code가 리뷰한다
• Claude Code가 작성한 기사는 Codex가 리뷰한다
• 같은 AI가 셀프 리뷰한 경우, 공개 전 체크로서는 유효하지만 "상호 리뷰 완료"로는 취급하지 않는다

.claude/rules/cross-agent-review.md에 이 역할 분담표를 규칙으로 고정해 두었습니다. 고정한 이유는 세션마다 "이번에는 누가 쓸 차례였지"를 확인하는 비용을 없애고 싶었기 때문입니다. 역할이 정해져 있으면, 쓰기 시작하기 전에 "이것은 다른 AI에게 넘기기 위한 초안이다"라고 인식한 상태에서 출력을 할 수 있습니다.

공개 전에 갖춰야 할 게이트 조건도 4가지로 고정했습니다.

• 작성자 측의 셀프 체크 또는 /article-review 상당의 과정이 완료됨
• 다른 한쪽의 AI에 의한 리뷰 요청 또는 리뷰 결과가 기록됨
• 중대한 지적 사항이 남아 있지 않음
• 사용자가 공개를 명시함

published: true로의 변경은 이 4가지 조건이 갖춰질 때까지 금지한다고 운용 규칙으로 묶어두고 있습니다. AI 측이 "공개해도 좋다"라고 판단하게 하지 않는 것이 핵심입니다.

handoff 파일에 리뷰 결과를 반드시 남기는 게이트

구두나 세션 내의 대화로 리뷰를 완결 지으면, 나중에 "이것을 언제 통과시켰더라", "무엇이 지적 사항이었고 무엇이 임의 개선 사항이었나"를 추적할 수 없게 됩니다. CLAUDE_CODE_HANDOFF.md

단일 handoff 파일에 작성·의뢰·결과를 시계열로 쌓아가는 방식으로 정립했습니다.

1건 분량의 구조는 다음과 같습니다.

## 20XX-XX-XX 추가 (X에 의한 <기사 슬러그> 초안·Y 리뷰 의뢰)
- 대상 기사: `articles/<slug>.md`
- 상태: `published: false`
...

리뷰어는 결과를 동일한 파일의 바로 아래에 추가합니다.

Codex 리뷰 결과 (20XX-XX-XX):
- 공개 여부: 🔴 수정 필수 / 🟢 공개 가능
- 중대 지적 사항 1: <내용과 해당 행>
...

「수정 가능한 범위: 원칙적으로 대상 기사만」을 명시하는 이유는, 리뷰어가 지적을 하는 김에 다른 파일까지 수정해 버리는 사고를 방지하기 위해서입니다. 리뷰와 수정의 권한을 분리하지 않으면, 누가 무엇을 바꿨는지 추적할 수 없게 됩니다.

handoff에 쌓는 부수적인 효과로, 훗날 기사를 쓸 때 사용할 소재가 수중에 늘어납니다. 본 기사의 실례 섹션도 과거의 handoff에서 지적 패턴을 추출하여 구성했습니다.

실제로 발견된 지적 패턴

하네스(Harness)화한 이후에 걸러지는 지적 사항을 4가지 유형으로 분류합니다.

1. 사실 오인

• 「A에는 X밖에 없다」라고 썼으나, 현재의 기본 브랜치(Default branch)에는 X'도 공존하고 있었다
• 참고 링크의 기본 브랜치 차이로 인한 404 오류
• 라이브러리의 버전 기술이 실제 코드 (package.json)와 일치하지 않음

작성한 AI는 이를 「자연스러운 전제」로 통과시키지만, 다른 AI가 gh api나 cat package.json을 통해 기계적으로 확인하면 걸러냅니다.

2. 기밀 유지 리스크

• 업무 도메인 고유의 Enum 명칭 (DomainSpecificTraining, ApplicationProcess 상당)이 드러남
• isOnsite와 같이 실제 운영에서 사용하는 어휘에 가까운 변수명
• 「어느 업무 시스템에서」라고 일반화하려 했으나, 코드 단편을 통해 구체적인 내용이 보임

이는 작성 측 AI가 「샘플로서 자연스럽다」고 통과시키는 패턴입니다. 다른 AI에게 검토를 맡기면 「업무 고유의 어휘로 보인다」고 검출할 수 있습니다.

3. AI스러운 맺음말

AI 고유의 문제라기보다, 흔한 블로그 글(こたつ記事) 같은 정형화된 표현을 AI가 재생하는 패턴입니다.

• 「쿼터 절감의 힌트가 되기를 바랍니다.」
• 「참고해 보세요」 계열의 마무리
• 「어떠셨나요...」 계열의 질문

작성한 AI는 「독자에게 말을 거는 자연스러운 마무리」라고 판정하지만, 다른 AI에게 통과시키면 AI 특유의 정형화된 표현으로 걸러집니다. 기사 말미는 특히 이 패턴이 나오기 쉬운 부분입니다.

4. 검색성과 코드 블록의 형식

• 제목에 기술 스택 명칭 (ASP.NET Core MVC 등)이 포함되지 않아 검색성이 낮음
• 코드 블록에 Zenn의 언어:파일명 지정(예: csharp:Xxx.cs)이 되어 있지 않음
• :::message alert의 사용 빈도가 너무 많거나 너무 적음

이는 「공개한 후에 가독성 문제로 깨닫게 되는」 유형의 지적입니다. 공개 전에 다른 AI의 리뷰를 거치면, 제목 설계·코드 블록의 파일명 부여·강조 정도를 조절할 기회가 늘어납니다.

하네스화 전에 겪었던 실패

크로스 리뷰 운용을 정립하기 전, 다음과 같은 함정에 빠진 적이 있습니다.

구두로 끝내고 기록이 남지 않음: 동일한 세션 내에서 리뷰를 끝내고 수정도 그대로 반영해 버려서, 무엇이 지적 사항이었고 무엇이 임의 개선 사항이었나를 나중에 추적할 수 없게 되었습니다. handoff 파일에 남기는 방식으로 바꾼 것은 이것이 직접적인 이유입니다.

리뷰어가 대상 외 범위까지 수정함: 「지적하는 김에, 이 기사도 좀 정리해 둘게요」를 허용해 버려서, 다른 기사의 형식이 나도 모르는 사이에 바뀌어 있었던 적이 있습니다. 수정 가능한 범위: 원칙적으로 대상 기사만을 handoff에 명시한 후에는 멈췄습니다.

같은 AI에게 자기 리뷰(Self-review)를 시키고 만족함: 「Claude Code가 Claude Code의 출력을 리뷰」, 「Codex가 Codex의 출력을 리뷰」하는 것을 상호 리뷰로 취급하던 시기가 있었습니다. 이는 공개 전 체크에는 유효할지 몰라도, 다른 AI에 의한 검출 능력은 얻을 수 없습니다. 역할을 고정하는 것을 규칙화한 이후부터는, 한 대의 AI로 작성했을 때는 알아채지 못했던 지적 사항들이 안정적으로 걸러지기 시작했습니다.

요약

요점은 세 가지입니다.

• 1대의 AI로 작성하고 자기 검토(Self-review)를 수행하는 운영 방식에는 구조적으로 탐지할 수 없는 맹점(사실 오인, 상투적인 결론 문구, 도메인 어휘 누락)이 존재한다.
• 작성자와 다른 AI를 역할 고정 (Role-fixing) 상태의 리뷰어로 설정하고, 그 결과를 handoff 파일에 남기는 게이트(Gate) 단계에 배치한다. 단, 공개 여부를 결정하는 권한은 AI에게 넘기지 않으며, 4가지 조건(셀프 리뷰, 상호 리뷰 기록, 중대한 지적 사항 없음, 사용자의 명시적 승인)을 인간이 통제한다.

개인 기사를 2대의 AI 크로스 리뷰(Cross-review)에 태우는 가치는 품질 향상보다도 자신의 맹점이 언어화되어 남는다는 점에 있습니다. handoff에 쌓인 지적 로그는 다음 기사를 작성할 때의 관점 리스트로서 그대로 사용할 수 있습니다.

참고 링크

• Claude Code 공식 문서

• OpenAI Codex CLI / Codex coding agent

• 본 기사의 운영 규칙 본체: harness17/zenn-articles
  .claude/rules/cross-agent-review.md

• 관련 기사: 동일 시리즈의 Claude Code 운영 변천 기사 (동일 프로젝트에서 선공개)