AI에게 기술 기사를 쓰게 하면, 매번 어딘가에 영어 직역투의 부자연스러운 일본어가 섞입니다. 이 기사에서는 그 수정 작업을 재현 가능한 리뷰로 바꾸는 Claude Code 에이전트 제작 방법을 소개합니다. 필자는 번역투·난해한 표현을 매번 수동으로 고쳐왔으나, 검출 규칙을 에이전트에 이식함으로써 그 판단을 계승할 수 있도록 했습니다.

대상 독자는 Claude Code의 .claude/agents/에 서브 에이전트(sub-agent)를 배치해 본 경험이 있으며, AI로 문장을 쓸 때마다 번역투나 난해한 표현을 수동으로 고치고 있어 그 리뷰 판단이 사람마다 달라지는 것에 어려움을 느끼는 분들입니다.

왜 AI 집필의 일본어는 항상 부자연스러워지는가

인간이 처음부터 쓴 문장에서는 잘 일어나지 않는데, AI에게 쓰게 하면 매번 발생하는 품질 저하가 있습니다. 필자의 경험으로는 그 저하를 다음 세 가지 유형으로 정리할 수 있었습니다.

1. 번역투 (Calque) — 칼크(calque, 번역 차용)란 다른 언어의 단어나 구를 어휘 단위로 그대로 번역하여 차용한 것을 말합니다 (Wikipedia: 번역 차용). AI 문장에서는 영어 표현을 한 단어씩 일본어로 치환한 부자연스러운 숙어로 나타납니다. 예를 들어 art and science를 「기예와 과학」으로, replacing yourself를 「당신 자신을 교체하는 것」으로 번역하는 등의 경우입니다.

2. 난해한 한자어·전문 용어 — 제어 공학이나 시스템 이론 용어(폐루프 제어(closed-loop control)·편차·자기 조직화)나, 딱딱한 한자어(연앙·상기)가 평이한 설명 없이 본문이나 도표에 등장합니다. 쓴 본인(AI)은 이해하고 있더라도 독자는 걸림돌을 느낍니다.

3. AI 특유의 기계적인 말투 — 「A가 아니라 B다」라는 이항 대립, 세 항목을 억지로 나열하는 구성, 「다음의 3가지 관점에서 설명하겠습니다」와 같은 메타적인 구조 선언, 과도한 과장 표현 등입니다.

이것들은 기술적으로 틀린 것은 아닙니다. 그렇기에 더 까다로우며, 문장으로서 읽기 불편할 뿐인데 리뷰를 쉽게 통과해 버려, 공개 후에 「왠지 모르게 읽기 어려운 기사」로 남게 됩니다.

이 세 가지 유형은 다음 그림과 같은 관계에 있습니다.

리뷰 지적을 「그때뿐인 수정」으로 끝내지 않기

계기는 어느 기사의 리뷰였습니다. ai-engineering-prompt-context-harness-loop라는 기사를 집필하던 중, 오너로부터 위의 세 가지 유형에 걸친 지적을 한꺼번에 받아 수십 군데를 수작업으로 고쳤습니다.

이때 고친 곳은 예를 들어 다음과 같습니다.

문제는 이러한 종류의 수정이 AI 집필 때마다 발생한다는 것이었습니다. 게다가 수정은 그때그때의 리뷰 판단에 의존하고 있어, 다음 기사로 지견이 계승되지 않습니다. 무엇을 고쳤는지는 커밋 메시지(commit message)에 흩어져 있고, 카탈로그화되어 있지도 않습니다. 리뷰어의 육안에 의존하기 때문에 놓치는 경우도 발생합니다.

그래서 「이번 지적을 단발성으로 끝내지 않고, 검출 규칙으로 묶어서 매번 자동으로 실행하자」라고 생각했습니다. 우선 지적 사항들을 Issue에 카탈로그화합니다. 포맷은 「검출의 실마리 → 수정 방침 → Before → After 사례」로 통일했습니다. 이를 통해 「왠지 읽기 불편하다」라는 개인적인 감각이, 에이전트가 재현할 수 있는 구조화된 규칙으로 변합니다.

이때 정리한 것이 다음 카테고리 그룹입니다.

FJ는 비유의 통일·형식 맞춤·1차 정보 링크 등 「이해를 돕는 일관성」을 위한 보조 규칙입니다. 본 기사에서는 번역투의 핵심(AE·K~M)에 집중하여 해설하기 위해 이러한 상세 내용은 생략합니다.

카테고리 C는 눈에 띄지 않지만 효과적입니다. 영어의 word나 term...

이를 그대로 「語(어)」라고 번역하면, 「이 어는(この語は)」, 「새로운 어로(新しい語で)」와 같이 일본어로는 다소 딱딱한 표현이 됩니다. 이를 「言葉(말)」, 「呼び名(이름)」, 「用語(용어)」로 바꾸는 것만으로도 훨씬 읽기 편해집니다.

역번역 테스트: 번역투를 반증 가능한 절차로 찾아내는 핵심 수법

카탈로그화한 검출 규칙의 중심에 둔 것이 바로 역번역 테스트 (Back-translation test) 입니다. 생각하는 방식은 매우 단순합니다.

수상한 일본어를 머릿속에서 영어로 직역해 보는 것입니다. 그 영어가 특정 관용구나 유표한 구문(정해진 표현 방식)과 그대로 일치한다면, 그것은 영어를 그대로 따라 한 직역(Calque, 칼크)일 의심이 짙습니다.

반대로, 영어로 되돌렸을 때 특정 관용구에 얽매이지 않고 일본어로서 자연스럽게 성립하는 표현이라면 문제가 없습니다. 이 한 단계를 거치는 것만으로도, "왠지 이상하다"라는 애매한 감각이 "영어의 무엇무엇을 직역한 것이다"라는 반증 가능한 판단으로 바뀝니다.

구체적인 예를 살펴보겠습니다.

예를 들어 「당신 자신을 대체하다(あなた自身を置き換える)」는 일본어만 읽으면 의미를 파악하기 어렵지만, replacing yourself로 되돌리면 "(자동화를 통해) 자신의 역할을 기계로 대체하다"라는 영어 표현이 투영되어 보입니다. 원래의 영어를 특정할 수 있는 시점에서, 이것은 직역일 의심이 짙다고 판단할 수 있습니다.

단, 이 수법에는 한계가 있습니다. AI가 일본어로 직접 생성한 문장에는 실재하는 영어 원문이 있는 것이 아닙니다. 역번역 테스트는 어디까지나 "의심을 언어화하는 휴리스틱 (Heuristic)"이며, 원문의 존재를 증명하는 것은 아닙니다. 자연스러운 일본어가 우연히 영어 관용구와 일치하는 위양성 (False positive)이 발생할 수도 있습니다. 그렇기 때문에 확신할 수 없는 부분은 지적하지 않는다(위양성을 가장 경계한다)는 자세가 전제가 됩니다.

또한, 역번역 테스트는 판단의 "절차"가 명시적이고 재현하기 쉬운 반면, 그 절차를 실행하는 것은 LLM이므로 출력은 확률적으로 흔들립니다. 절차가 언어화되어 있다는 것과 실행 결과가 매번 같다는 것은 별개라는 점을 구분해 두면, 후술할 textlint와의 차이점도 이해하기 쉬워집니다.

역번역 테스트의 장점은 판단의 근거를 말로 설명할 수 있다는 것입니다. "리듬이 나쁘니까 고쳐줘"라고 하면 작성자가 재현할 수 없지만, "이것은 cadence의 직역이니까 '전체적인 진행 방식'으로 바꾸자"라고 하면 다음에 같은 표현을 만났을 때도 똑같은 판단을 할 수 있습니다. 그래서 이 에이전트에서는 지적할지 말지 망설여진다면 반드시 "이것은 영어의 어떤 표현을 직역한 것인가?"라고 자문하고, 원래의 영어를 특정할 수 있는 경우에만 수정 대상으로 올린다는 규칙을 세웠습니다.

「채점」이 아닌 「결함 검출」——위양성을 가장 경계하는 설계

리뷰 에이전트를 만들 때 가장 먼저 정한 것이 기본 자세입니다. 문장의 아름다움을 종합적으로 채점하는 것이 아니라, 반증 가능한 결함만을 지적한다고 정했습니다. 설계의 참고로 삼은 것은 리뷰 에이전트를 검증 사이클을 통해 키워나간다는 개념입니다 (자매 글로 후술합니다).

이 자세는 세 가지 원칙으로 나눌 수 있습니다.

1. 아무 데나 빨간 펜을 들지 않는다. "문제 없음"이라고 침묵하는 것에 가치가 있습니다. 확신이 없는 부분은 지적하지 않습니다. 지적의 위양성(오검출)이야말로 이 에이전트에 대한 신뢰를 가장 크게 손상시키기 때문입니다. 빨간 줄로 가득한 리뷰는 작성자가 무엇을 고쳐야 할지 판단할 수 없게 만들어, 결국 모두 무시됩니다.

2. 지적과 조언을 분리한다. 반증 가능한 결함은 〔指摘〕 (지적, 수정 필요), 리듬이나 취향에 속하는 확신도가 낮은 제안은 〔助言〕 (조언, 임의 사항)으로 명확히 구분합니다. "고쳐야 하는 것"과 "고쳐도 좋은 것"이 섞이면 전자의 무게감이 떨어집니다.

3. 이름을 붙여주면 고칠 수 있다. 말로 표현하기 어려운 위화감도 어떤 카테고리의 결함인지 이름을 붙여주면, 작성자는 재현성 높게 고칠 수 있습니다. 그래서 지적에는 반드시 카테고리 이름(A~M)을 덧붙입니다.

이 삼원칙을 뒷받침하는 것이 앞서 말한 역번역 테스트와 명문화된 제외 기준입니다. 다음의 것들은 결함으로 취급하지 않습니다.

• 정착된 가타카나어·전문 용어 (API, 데이터베이스, 컨텍스트 윈도우 (Context Window) 등, 업계에서 널리 쓰이며 평이한 대체어가 없는 것)
• 의도적인 캐주얼한 문체·구어체·자학·비꼬기 등, 작성자가 의도적으로 흐트러뜨린 부분
• 문학적·비유적 표현으로서 독자의 이해를 방해하지 않고 효과를 높이는 것

위양성 (False Positive)을 두려워하는 태도는 AI slop (AI가 생성하는 저품질 문장)을 검출하는 공개 도구의 설계와도 맞닿아 있습니다. 그중에는 문장을 고치기 전에 먼저 비평 (critique)만을 반환하는 방식을 채택하는 것도 있습니다. "고치기 전에 먼저 결함을 지적한다"는 순서는 이 에이전트의 설계와 매우 유사합니다.

외부의 공개 지견을 통합하여 검출 카테고리를 확장한다

자신의 리뷰 경험만으로는 검출할 수 있는 패턴에 편향이 생깁니다. 그래서 공개되어 있는 일본어 교정 지견을 통합하여 카테고리를 넓혔습니다. 도입한 것은 다음의 3가지입니다.

이러한 지견들은 라이브러리로 호출하는 것이 아니라, 검출 패턴을 프롬프트의 카테고리 정의로서 도입했습니다. 외부 도구에 실행을 의존하지 않고, 어디까지나 판단 기준으로 참조하는 형태입니다. 이를 바탕으로 자신의 리뷰에는 없었던 다음의 카테고리를 신설했습니다. 모두 언어학 용어에 대응하지만, 반드시 일본어(한국어)로의 의역과 구체적인 예시를 세트로 구성했습니다.

카테고리 K: 무생물 주어 + 타동사 (False Agency). 요컨대, 사람이 하는 행위를 사물이 주어가 되어 하고 있는 것처럼 쓰는 구문입니다. 무생물 (데이터·상황·결과 등)이 본래 사람이 취하는 능동적인 동사의 주어가 되어, 실제 행위자가 숨겨지게 됩니다. 영어의 X shows, X drives를 그대로 흉내 내다 보면 발생합니다. False Agency란 "행위 주체 (agency)가 겉모습뿐이다"라는 의미로, 주어 자리에 있는 것이 실제 행위자가 아님을 가리킵니다.

카테고리 L: 명사화로 동작 주체가 사라짐. 명사화 (nominalization)란 동사를 명사로 굳히는 조작입니다. "추가하다"를 "~의 추가"로 하는 것처럼, 동작을 명사로 바꾸면 누가 무엇을 하는지가 보이지 않게 됩니다. 명사화가 많은 문장은 읽기 어려워진다는 사실이 알려져 있습니다. 명사를 동사로 되돌리면 주어와 동작이 돌아옵니다.

카테고리 M: 일어역 (문맥을 무시한 직역어). 영어 단어를 사전의 제1의미 그대로 가져다 붙인, 그 자리에 어울리지 않는 번역어입니다. "레벨이 내려가다" (본래는 "전체적인 질이 떨어지다"), "이 케이스에서는" (본래는 "이 경우에는") 등이 해당합니다.

리뷰 파이프라인으로의 편입과 역할 분담

에이전트의 정의를 쓰는 것만으로는 움직이지 않습니다. 기존의 리뷰 파이프라인에 편입시키고, 다른 리뷰어들과의 담당 범위를 결정해야 합니다.

여기서 말하는 "기존의 리뷰 파이프라인"에 대해 먼저 언급해 두겠습니다. 필자는 이전부터 기사의 기획·집필·리뷰·공개를 여러 AI 에이전트가 분담하는 편집 팀을 Claude Code 상에서 운용하고 있습니다. 그 전체상은 '1주일 만에 최강의 편집 팀을 만든 이야기'에 정리해 두었습니다. 기사 리뷰는 이 편집 팀의 /review 명령어가 담당합니다. 여러 리뷰어가 단계 (Stage)별로 나누어 기사를 보는 순차적 파이프라인이며, 이번 에이전트도 그곳에 새로운 멤버로 추가하는 형태가 됩니다.

Claude Code의 서브 에이전트는 Markdown 본문과 YAML 프론트매터 (front matter)로 정의할 수 있으며, 예를 들어 다음과 같이 작성할 수 있습니다.

---
name: natural-japanese-reviewer
description: Zenn 기술 기사의 일본어 자연스러움·이해도를 검증한다.
...

이는 정의 형식을 보여주기 위한 예시입니다. 이 에이전트는 검출과 제안에 철저하며, 기사 자체를 다시 쓰지는 않습니다. 따라서 tools

tools를 읽기 계열(Read / Grep / Glob)로 한정하여 설계하는 것이 적합합니다. 다시 쓰는 작업은 작성자(Writer)의 몫으로 남겨둡니다.

이 에이전트는 /review 순차 파이프라인의 Stage 3 (독자 관점 리뷰) 에 네 번째 멤버로 합류했습니다.

Stage 3에는 독자의 이해와 관련된 리뷰어(전제 지식, 일본어 표현, 관련 링크, 스마트폰 표시)들이 모여 있습니다. 여기서 중요한 것은 영역이 겹치는 상대와의 담당 범위를 명확히 결정하는 것입니다. 이는 중복 지적과 위양성(False Positive)을 피하기 위한 설계이기도 합니다.

junior-reviewer와의 분담. junior-reviewer는 '전제 지식의 부족, 설명의 비약, 용어 해설 유무'와 같은 이해의 비약을 확인합니다. natural-japanese-reviewer는 '일본어 표현이 번역투이거나 난해하여 이해하기 어렵다'는 표현 수준의 의역에 집중합니다. 용어를 쉽게 만드는 작업에서는 영역이 겹치므로, 중복되는 지적은 피합니다.

textlint가 있는데 왜 직접 만드는가?

답은 두 방식의 검출 방식이 다르기 때문입니다. textlint는 결정론적인 패턴 매칭(Pattern Match) 방식이고, natural-japanese-reviewer는 문맥을 이해하는 의미 기반(Semantic-based) 방식이기에 전문 영역이 겹치지 않습니다. 이 부분이 독자들이 가장 궁금해할 지점일 것입니다.

예를 들어, '당신 자신을 대체하다'가 replacing yourself의 직역임을 간파하려면, 문장의 의미를 이해하고 영어로 되돌려 보아야 합니다. 이는 패턴 매칭으로는 어렵습니다. 반면, 표기 불일치나 근사값의 아라비아 숫자화 등은 textlint가 확실하고 빠르게 잡아낼 수 있습니다.

즉, 어느 하나를 선택하는 것이 아니라 둘 다 사용하는 것이 현실적인 해답입니다. 기계적으로 검출할 수 있는 것은 textlint에 맡기고, 문맥에 의존하는 번역투 판단만을 LLM 리뷰 에이전트가 담당합니다. 역할 분담을 명문화함으로써 에이전트는 자신의 수비 범위에 집중할 수 있습니다.

요약: 리뷰 지식을 에이전트화하는 패턴

이번 개발을 되돌아보면, 본질은 자신의 리뷰 지식을 에이전트에 이식하는 패턴이었다는 것을 깨닫게 됩니다. 특정 도구의 숙련도가 주제가 아닙니다. 흐름은 다음 네 단계로 일반화할 수 있습니다.

• 실제 리뷰에서 나온 지적을 그 자리의 수정으로 끝내지 않는다.
• 지적 사항을 '검출 단서 → 수정 방침 → Before → After'의 통일된 포맷으로 카탈로그화한다.
• 설계 사상(결함 검출, 역번역 테스트)과 외부의 공개된 지식을 통합하여 정밀도를 높인다.
• 기존 리뷰어와의 역할 분담을 결정하여 파이프라인에 편입시킨다.

서두에 썼듯이, 필자는 AI 집필의 번역투나 난해한 표현을 매번 수동으로 고쳐왔습니다. 손수 고치는 작업 자체는 피할 수 없다 하더라도, '무엇을, 왜 고치는가'를 역번역 테스트와 카테고리 명칭으로 언어화할 수 있다면 그 판단은 에이전트에게 인계할 수 있습니다. 개인의 역량에 의존했던 '왠지 읽기 어렵다'라는 감각이 재현 가능한 판단 기준(언어화된 검출 규칙)으로 변한 것입니다. 실행하는 것은 LLM이기에 결과에는 변동이 있겠지만, 무엇을 왜 고치는가라는 기준 그 자체는 다음 글로 이어질 수 있습니다.

물론 검출기 자신도 LLM인 이상 만능은 아닙니다. 실제로 이 기사 자체도 natural-japanese-reviewer를 통해 번역투를 체크했습니다. AI가 쓴 문장을 AI가 판정하는 재귀적인 구조이지만, 판단 기준을 언어화해 두면 그 기준에 비추어 자신의 문장도 점검할 수 있습니다.

이 에이전트는 한 번 만들고 끝내는 것이 아니라, 새로운 지적이 나올 때마다 카테고리를 추가하며 키워나가는 것입니다. 리뷰 에이전트를 검증 사이클을 통해 육성하는 사고방식에 대해서는 자매 기사도 함께 참고해 주시기 바랍니다.

끝까지 읽어주셔서 감사합니다. 이 기사가 AI 집필의 수정 작업에 지쳐 있는 분들에게 도움이 되기를 바랍니다.

Discussion