병렬 AI 에이전트로 4일 만에 390만 단어를 번역했습니다
17년치 블로그 포스트 493개를 10개 언어로, 약 4,900개 파일, 약 390만 단어. Claude Code의 병렬 에이전트 덕분에 가능했지만, 한국어 재앙, 광둥어 어조 문제, 5시간 사용 제한은 성공 사례보다 더 많은 것을 가르쳐 줬습니다.
한 달 전, 저는 DIALØGUE에 5개 언어를 48시간 만에 추가했고 기획 문서가 빠른 AI 실행의 핵심이라는 내용을 썼습니다.
그건 UI 문자열 400개 정도인 앱 하나에 5개 언어를 추가한 이야기였습니다.
이번 주엔 훨씬 더 큰 도전을 해봤습니다. 17년 치 블로그 포스트 493개 전체를 10개 언어로 현지화하는 것이었습니다. 베트남어, 인도네시아어, 스페인어, 프랑스어, 포르투갈어, 독일어, 일본어, 한국어, 중국어(간체), 광둥어까지요.
번역된 파일 약 4,900개. 약 390만 단어. 4일.
이건 AI가 마법 같다는 이야기가 아닙니다. 수천 개의 번역 작업을 병렬 AI 에이전트에 맡겼을 때 실제로 어떤 일이 벌어지는지에 관한 이야기입니다. 잘 작동하는 오케스트레이션, 결과물을 읽기 전까지 드러나지 않는 실패들, 그리고 기계가 대규모로 글을 쓸 때의 품질 관리에 대한 불편한 진실까지요.
규모의 문제
제 블로그는 2007년까지 거슬러 올라갑니다. 어떤 포스트는 싱가포르 검색 마케팅에 관한 300단어짜리 업데이트고, 어떤 포스트는 미중 관계나 해외 이주 가이드를 다룬 5,000단어짜리 심층 분석입니다. 아카이브에는 Yahoo SEM 분석부터 북리뷰, AI 제품 출시까지 온갖 내용이 담겨 있습니다.
493개의 포스트를 전문 번역팀이 9개 언어로 수동 번역한다면 몇 주, 어쩌면 몇 달이 걸릴 겁니다. 비용은 "부담스러운" 수준에서 "집을 담보로 잡아야 하는" 수준 사이 어딘가가 될 거예요.
하지만 저는 이미 i18n 인프라를 구축해 놓은 상태였습니다. next-intl 라우팅, 로케일 인식 컴포넌트, 비영어 페이지를 위한 ISR까지 — 더 넓은 국제화 작업의 일환으로 기술 스택은 모두 준비되어 있었습니다. 필요한 건 콘텐츠뿐이었습니다.
1일차: 베트남어와 첫 번째 교훈
베트남어로 시작한 건 개인적인 이유 때문입니다. 제 모국어이거든요. 번역된 포스트 하나하나를 읽으면서 뭔가 어색한지 바로 알 수 있었습니다.
Claude Code는 한 세션 안에 493개의 포스트를 전부 번역했습니다. 과정은 깔끔해 보였습니다.
- 영어 MDX 파일 읽기
- 콘텐츠 번역, 모든 frontmatter 구조 유지
- URL, 코드 블록, 기술 용어 그대로 보존
- 번역된 파일을
content/blog/vi/YYYY/MM/DD/slug.mdx에 저장 - "Cheers, Chandler"의 베트남어식 마무리 인사로 끝내기
첫 번째 QA 점검에서 이후 모든 언어를 괴롭히게 될 패턴이 발견됐습니다. URL과 마무리 인사였습니다. 에이전트는 내부 블로그 URL을 "번역"하면서 존재하지 않는 베트남어 슬러그로 바꿔버리고, "Chandler"를 베트남어식 이름으로 대체하고, 심지어 frontmatter의 slug 필드를 통째로 빠뜨리기도 했습니다.
QA 체크리스트를 만들었습니다.
- 파일 수가 원본과 일치하는지 (493개)
- 빈 파일이나 빈껍데기 파일이 없는지
- 모든 frontmatter에
slug,title,date,categories가 있는지 - 내부 URL이 재작성되지 않았는지
- 마무리 인사가 해당 로케일 방식과 맞는지
- CJK 언어의 경우: 실제로 해당 언어의 문자가 있는지
이 체크리스트는 이후 모든 로케일 작업의 근간이 됐습니다.
2일차: 병렬 에이전트의 도약
베트남어가 완성되고 QA 체크리스트의 효과가 검증됐으니, 더 빨리 진행해야 했습니다. 이런 종류의 작업에서 Claude Code의 핵심 기능은 병렬 서브에이전트 디스패치입니다. 각각 다른 파일을 동시에 처리하는 독립적인 에이전트를 여러 개 띄울 수 있습니다.
스페인어 오케스트레이션이 어떻게 생겼는지 보여드리면 이렇습니다.
번역 에이전트 30개 디스패치 중...
├── 에이전트 1: 2007-2008 포스트 (42개)
├── 에이전트 2: 2009 포스트 (38개)
├── 에이전트 3: 2010-2011 포스트 (35개)
├── ...
├── 에이전트 28: 2025 11-12월 포스트 (12개)
├── 에이전트 29: 2026 1월 포스트 (8개)
└── 에이전트 30: 2026 2월 포스트 (9개)
각 에이전트는 포스트 묶음, 스타일 가이드, QA 체크리스트, 마무리 인사 방식을 받아 병렬로 실행하며 각자 독립적으로 파일을 작성했습니다. 각 에이전트가 서로 다른 파일을 건드리기 때문에 조율이 전혀 필요 없었습니다.
스페인어: 한 세션에 493개 포스트 번역 완료. 그다음엔 프랑스어. 그다음엔 포르투갈어. 그다음엔 독일어. 그다음엔 일본어.
대략 12시간 안에 5개 언어. 이게 바로 미래처럼 느껴지는 부분입니다. 저녁을 만드는 동안 터미널이 30개의 동시 진행 표시기로 가득 차고, 각 에이전트가 수십 년치 블로그 포스트를 처리하는 모습을 지켜보는 것이요.
실제 광둥어(zh-HK) 번역 세션이 어떻게 돌아갔는지 — 기획부터 디스패치, QA까지 — 시뮬레이션으로 보여드리겠습니다.
오케스트레이션 패턴
이 과정에서 나타난 패턴입니다.
- 모든 디렉토리를 미리 생성하기 — 대상 디렉토리가 없으면 에이전트가 조용히 실패합니다
- 연도 범위별로 묶기 — 일반 포스트는 에이전트당 10-15개, 3,000단어 이상 포스트는 에이전트당 2-3개
- 모든 디스패치에 스타일 가이드 포함하기 — 에이전트들은 공유 메모리가 없으므로 각자 전체 맥락이 필요합니다
- 각 로케일 완료 후 QA 실행하기 — 파일 수, 빈 파일, 깨진 frontmatter, URL 재작성, 마무리 인사 일관성 확인
- 누락되거나 잘못된 파일은 타겟 정리 에이전트로 수정하기 — 항상 5-15개 정도 놓치거나 잘못된 파일이 생깁니다
한국어 재앙
한국어는 당연히 수월할 거라고 생각했습니다. 다른 7개 언어와 같은 패턴이었으니까요. 에이전트를 디스패치하고, 기다리고, QA하고, 나머지를 수정하면 되는 거였습니다.
그런데 모든 로케일 중에서 가장 심각한 번역 품질 문제가 발생했습니다.
한국어 포스트의 72%가 번역이 아니라 요약이었습니다. 에이전트들이 350개 이상의 포스트를 2-3단락짜리 요약문으로 잘라버렸고, 모든 세부 내용, 모든 개성, 모든 뉘앙스가 사라졌습니다. 레이 달리오의 "원칙"에 대한 4,000단어짜리 분석이 200단어짜리 개요가 되어 있었습니다. 자세한 SEM 튜토리얼은 "이 포스트는 검색 엔진 마케팅 전략을 다룹니다"가 되어 있었습니다.
UI 문자열 파일(messages/ko.json)은 더 심각했습니다. 한국어와 영어가 뒤섞여 있었고, "Ch및ler" 같은 깨진 문자도 있었습니다. 및은 한국어로 "and"를 뜻하는 단어인데, 어떻게 된 건지 단어 중간에 삽입된 것이었습니다.
로케일 전체를 처음부터 다시 해야 했습니다. 포스트 하나하나를요. 두 번째 시도에서는 전체 내용을 보존하고 원본 포스트의 길이와 맞추라는 더 엄격한 지시를 내렸고, 결과물은 깔끔하게 나왔습니다.
교훈: 병렬 실행은 실수를 증폭시킵니다. 프롬프트에 미묘한 결함이 있으면, 30개의 에이전트가 같은 실수를 30배 더 빠르게 저지릅니다. QA는 선택 사항이 아닙니다. "완료"와 "재앙" 사이를 구분하는 유일한 것입니다.
중국어 문제: 올바르게 하기까지 43번의 커밋
중국어 간체(zh)는 가장 공수가 많이 든 로케일이었습니다. 품질 문제 때문이 아니라 — 번역 자체는 좋았습니다 — 43번의 별도 커밋에 걸쳐 493개 포스트를 번역했다는 게 세션이 계속 한계에 부딪혔다는 걸 말해줍니다.
Claude Code는 Anthropic의 API 위에서 실행되고, 사용량 제한이 있습니다. Max 티어에 Sonnet 4.6을 써도 수십 개의 병렬 에이전트를 디스패치하는 장시간 세션은 결국 5시간 냉각 기간에 걸리게 됩니다. 중국어의 경우, 그 말은 파도처럼 번역을 나눠야 한다는 뜻이었습니다. 포스트 50개 번역하고, 제한에 걸리고, 기다리고, 이어가고, 또 제한에 걸리고.
중국어 번역은 CJK 콘텐츠 특유의 실패 패턴 때문에 QA도 가장 많이 필요했습니다.
- 잘못된 문자 체계의 문자 혼용 (일본어 한자가 중국어 간체에 섞이는 경우)
- 블로그가 아니라 공문서처럼 읽히는 지나치게 격식체인 문체
- 중국어 구두점 대신 서양식 구두점 사용 (，vs. , 그리고 。vs. .)
- 번역하면 안 되는 이름을 번역하는 경우 ("Claude"는 중국어로도 "Claude"이지, 克劳德가 아닙니다)
광둥어 어조 문제
광둥어 어조(zh-HK)로 번체 중국어를 추가하면서 전혀 다른 과제에 직면했습니다. 번역에는 광둥어 특유의 조사들이 필요했습니다 — 嘅(소유격), 咗(과거 시제), 喺(~에/~에서), 啲(조금), 冇(없다) — 그리고 광둥어 글쓰기의 특징인 가볍고 대화적인 어조를 유지해야 했습니다.
표준 만다린 번역은 홍콩에서 딱딱하게 느껴집니다. "本网站提供中文版本"은 문법적으로 올바른 만다린이지만, 광둥어 독자는 "呢個網站有中文版本"을 기대합니다. 의미는 같지만, 완전히 다른 어조입니다.
어려운 건 번역의 정확성이 아니라 어조의 진정성입니다. 모델은 문법적으로 올바른 광둥어를 만들 수 있지만, 구어체 조사와 코드 믹싱 패턴을 사용하라고 명시적으로 지시하지 않으면 만다린 어조로 돌아가 버립니다.
광둥어 QA 점검에는 모든 파일에서 광둥어 특유의 조사가 있는지 grep으로 확인하는 작업이 포함됐습니다. 493개 중 493개 통과. 하지만 messages/zh-HK.json UI 문자열 파일 전체는 수동으로 다시 써야 했습니다. 첫 번째 버전이 약 70%가 영어였거든요. 에이전트가 번역 대부분을 건너뛰어버린 것이었습니다.
OpenAI Codex로 시도해 본 것
독일어 번역 중 어딘가에서 Claude Code의 사용량 제한에 걸렸고, 기다리는 동안 OpenAI Codex를 써보기로 했습니다. ChatGPT Plus 한 달 무료 사용권이 있었는데, Codex 접근권이 포함돼 있었습니다.
좋은 점: Codex는 탄탄한 기획 문서를 만들어냅니다. 코드베이스에 대한 초기 분석과 번역 접근 방식 제안은 잘 구성되어 있었고 합리적이었습니다. 응답 속도도 빨랐습니다. 그리고 지시를 잘 따릅니다. 오히려 너무 잘 따르는 게 장점이 될 수도 있습니다.
나쁜 점: 제가 사용한 버전(gpt-5.2-codex)은 병렬 서브에이전트를 실행할 수 없었습니다. 포스트를 순차적으로 — 하나씩 — 처리했습니다. 493개 포스트에는 현실적이지 않습니다. 또 짧은 단위로만 작업했습니다. 5-10개 포스트를 완성하고 나면 피드백을 요청하며 멈춰버렸고, 다음 묶음을 시작하려면 매번 "계속해"라고 해야 했습니다.
세션 중간에 gpt-5.3-codex가 나와서 전환해봤습니다. 나아지긴 했지만, 여전히 병렬 실행은 없었습니다. 핵심적인 아키텍처 차이 — Claude Code는 30개 이상의 독립 에이전트를 동시에 디스패치할 수 있고, Codex는 단일 순차 프로세스로 작동한다는 것 — 가 대규모 콘텐츠 작업에서 Claude Code를 압도적으로 빠르게 만들어줍니다.
솔직한 비교: Codex는 집중적인 단일 파일 작업에는 좋습니다. 반응성이 있고 지시를 잘 따릅니다. 하지만 제가 필요했던 것 같은 대규모 병렬 실행 — 9개 로케일에 걸쳐 4,437개 파일 — 에서는 Claude Code의 에이전트 아키텍처가 완전히 다른 차원에 있습니다.
모든 것을 살린 체크리스트
모든 로케일은 같은 QA 파이프라인을 거쳤습니다.
✓ 파일 수: 493/493
✓ 빈 파일: 0
✓ 작은 파일 (<100 바이트): 0
✓ 누락된 slug: 0
✓ 재작성된 URL: 0
✓ 깨진 frontmatter: 0
✓ 잘못된 마무리 인사: 0
✓ 해당 언어 문자 존재: 493/493
CJK 언어에는 다음을 추가했습니다.
✓ 광둥어 조사 (嘅/咗/喺/啲/冇): 493/493
✓ 문자 체계 혼용 오염 없음: 통과
✓ 중국어 구두점: 통과
이 체크리스트가 없었다면 한국어 요약본들을 그대로 프로덕션에 배포했을 겁니다. 70%가 영어인 광둥어 UI를 배포했을 겁니다. 존재하지 않는 번역된 슬러그로 연결되는 깨진 내부 링크가 있는 블로그 포스트들을 배포했을 겁니다.
체크리스트는 관료적인 절차가 아닙니다. 직접 읽을 수 없는 수천 개의 파일을 프로덕션 파이프라인이 생성할 때, 유일하게 믿을 수 있는 QA입니다.
최종 수치
| 언어 | 11개 (영어 + 번역 10개) |
| 번역된 포스트 | 언어당 493개 × 10 = 약 4,900개 파일 |
| 단어 수 | 약 390만 개 |
| 달력 기준 일수 | 4일 (2월 24일~27일) |
| UI 문자열 파일 | 10개 로케일 JSON 파일 (각 약 475개 키) |
| 이메일 템플릿 | 10개 로케일 |
| 여정 데이터 | 마일스톤 + 학습 경로 JSONB로 번역됨 |
| 사용량 제한에 걸린 횟수 | 잃어버림 |
| 전체 로케일 재작업 횟수 | 1회 (한국어) |
실제로 배운 것들
1. 스타일 가이드가 전부입니다. 광둥어 어조, 한국어 격식 수준, 포르투갈어의 "Abraço" 마무리 인사 — 이건 장식이 아닙니다. "번역됨"과 "현지화됨"의 차이입니다. 스타일 가이드 없이는 공문서처럼 읽히는 문법적으로 올바른 콘텐츠가 나옵니다.
2. 병렬 에이전트는 힘의 배수인 동시에 위험의 배수입니다. 30개 에이전트가 올바르게 실행될 때는 한 시간 안에 언어 하나가 완성됩니다. 30개 에이전트가 같은 실수를 저지를 때는 350개의 잘린 포스트와 전체 재작업이 기다립니다.
3. 규모에서 QA는 선택 사항이 아닙니다. 번역된 포스트 4,437개를 직접 검토할 수는 없습니다. 하지만 가장 흔한 실패를 잡아내는 구조적 검사는 자동화할 수 있습니다. 누락된 파일, 깨진 frontmatter, 재작성된 URL, 잘못된 마무리 인사, 잘린 내용 등이요.
4. 가장 어려운 건 번역이 아니라 어조입니다. 어떤 LLM이든 텍스트를 번역할 수 있습니다. 원문을 쓴 사람처럼 들리게 만드는 것 — 따뜻함, 가벼움, 지적 호기심을 9개 언어와 17년에 걸친 진화하는 글쓰기 스타일 전체에 걸쳐 유지하는 것 — 은 명시적인 지시와 반복적인 수정이 필요합니다.
5. 사용량 제한은 실질적인 제약입니다. 최고 티어에서도 장시간의 병렬 에이전트 세션은 제한에 걸립니다. 중단을 미리 계획하세요. 멈춘 곳에서 다시 시작할 수 있도록 작업을 구조화하세요.
6. 실제 독자와 테스트하세요. 베트남어 번역은 직접 QA할 수 있었습니다. 한국어나 일본어는 구조적 검사에 의존하고 모델을 믿어야 했습니다. 알고 있는 한계입니다. 직접 읽지 못하는 언어의 품질을 진지하게 고려한다면, 원어민 독자에게 샘플을 점검해달라고 요청하세요.
그럴 만한 가치가 있었을까요?
제 블로그는 이제 11개 로케일에서 독자들에게 그들의 모국어로 도달합니다. 호치민시에 있는 베트남 마케팅 전문가는 싱가포르 검색 시장에 대한 제 2011년 분석을 베트남어로 읽을 수 있습니다. 일본의 AI 연구자는 Sydney를 만드는 것에 관한 제 2024년 포스트들을 일본어로 읽을 수 있습니다. 홍콩의 광둥어 사용자는 마치 자신들을 위해 쓰인 것처럼 들리는 콘텐츠를 받게 됩니다. 번역된 것처럼이 아니라요.
모든 번역이 완벽한가요? 아닙니다. 이 규모에서의 기계 번역에는 거친 부분이 있습니다. 어떤 은유는 제대로 전달되지 않습니다. 어떤 문화적 참조는 단어 대 단어 치환을 넘어서는 현지화가 필요합니다.
하지만 대안은 493개의 포스트가 영어로만 존재해, 전 세계 인터넷 사용자의 약 20%에게만 접근 가능한 상태였을 겁니다. 이제는 60% 이상이 접근할 수 있습니다.
4일. 390만 단어. 인프라가 갖춰졌습니다. 제가 영어로 쓰는 모든 새 포스트는 배포 프로세스의 일환으로 10개 언어로 번역됩니다.
진짜 질문은 AI 번역이 완벽한지가 아닙니다. 완벽이 접근 가능성의 적인지 여부입니다.
감사합니다, Chandler
