AI 번역 사후 교정 (Post-Editing): 고객을 잃기 전까지는 아무도 말해주지 않는 것들

지난해 저는 한 시니어 개발자가 모든 문자열을 GPT-4로 돌리고 20분간의 "정상 작동 확인 (sanity check)"을 거친 뒤, 일본 시장용으로 현지화된 SaaS 제품을 출시하는 것을 지켜보았습니다. 출시 3주 후, 일본인 원어민 사용자가 온보딩 흐름의 CTA(Call to Action)가 "구멍(hole)에 이메일 주소를 삽입해 주세요"라고 직역되었다는 지원 티켓을 제출했습니다. 모델이 欄 (field/blank) 대신 穴 (hole/cavity)를 선택한 것입니다. 기술적으로는 방어 가능할지 모르나, 재앙적인 오류였습니다. 이것이 바로 사후 교정 (post-editing)이 메워야 할 간극이며, 대부분의 AI 워크플로우는 이를 하나의 규율이 아닌 단순한 형식적인 절차로 취급합니다.

진짜 문제는 정확도가 아니라, 신뢰도 측정의 오차 (Confidence Miscalibration)입니다

AI로 번역된 콘텐츠를 출시해 본 모든 개발자는 잘못된 번역을 잡아내는 것이 가장 어려운 부분이라고 생각합니다. 하지만 그렇지 않습니다. 현대의 프런티어 모델 (frontier models)은 주요 언어 쌍 사이에서 문장 수준의 정확도를 90% 이상 유지합니다. 진짜 어려운 점은 남은 오류들이 일반적인 검토 전략을 무력화하는 방식으로 분포되어 있다는 것입니다.

AI 번역 오류는 특정 영역에 집중됩니다: 관용구 (idiomatic expressions), 어조의 모호성이 있는 도메인 특화 용어 (일본어의 경어/반말, UI 카피에서의 프랑스어 tu/vous 구분), 숫자 및 단위, 그리고 원문 자체가 의도적인 모호성을 가진 모든 것 (마케팅 카피, 제품명, 슬로건) 등이 이에 해당합니다. 또한 이 영역들은 모든 것이 유창해 보이기 때문에, 20분짜리 검토자가 가장 빠르게 훑고 지나가는 구간이기도 합니다.

해결책은 "더 주의 깊게 검토하라"가 아닙니다. 모델이 완벽하게 해낸 문장에 인간의 주의력이 낭비되기 전에, 위험도가 높은 세그먼트 (segments)를 먼저 드러내는 분류 시스템 (triage system)을 구축하는 것입니다. 만약 위험 점수 산정 (risk scoring) 없이 사후 교정을 하고 있다면, 당신은 "저장" 버튼과 "본 서비스를 이용함으로써 귀하는 당사의 이용 약관에 동의하게 됩니다"라는 문장에 동일한 노력을 기울이고 있는 것입니다.

무엇이든 사후 교정하기 전에 세그먼트 위험 모델을 구축하세요

사람이 번역 결과물에 손을 대기 전에, 각 세그먼트(segment)를 실패 확률에 따라 분류하세요. 이를 위해 별도의 머신러닝 (ML) 모델이 필요한 것은 아닙니다. 규칙 기반 분류기 (rule-based classifier)만으로도 가치의 80%를 얻을 수 있습니다.

고위험 신호 (High-risk signals):

• 모델이 인식하도록 학습되지 않은 고유명사 (귀사의 제품명, 경쟁사 이름, 내부 전문 용어)
• 원문이 5 토큰 (tokens) 미만인 세그먼트 (문맥이 부족하여 모델이 추측을 하게 됨)
• 숫자, 통화, 날짜 또는 단위가 포함된 세그먼트
• 마케팅 또는 감성적인 언어 (최상급, 유머, 은유)
• 변수나 포맷 문자열이 포함된 UI 문자열 ({username}, %d items)

저위험 신호 (Low-risk signals):

• 절차적 지침 텍스트 ("버튼을 클릭하세요", "비밀번호를 입력하세요")
• 표준 패턴을 따르는 에러 메시지
• 번역 메모리 (TM)에 확립된 번역이 있는 상용구 법률 문구

고위험 세그먼트는 자격을 갖춘 전문 검수자에게 배정하세요. 저위험 세그먼트는 용어집 (glossary) 및 번역 메모리 (TM)를 활용한 자동 일관성 검사로 배정하세요. 이렇게 하면 품질이 중요한 부분은 희생하지 않으면서 사후 교정 (post-editing) 작업량을 60% 줄일 수 있습니다.

용어집 강제 적용은 스타일 가이드가 아니라 인프라입니다

제가 본, 그렇지 않으면 견고했을 AI 번역 파이프라인 (pipeline)을 망가뜨리는 패턴이 하나 있습니다. 팀이 용어집을 만들고, 이를 구글 문서 (Google Doc)에 넣은 뒤, 번역가들에게 "참고하세요"라고 말하는 것입니다. 이는 시간이 지나면서 용어집을 내재화하는 인간 번역가에게는 통할 수 있습니다. 하지만 요청마다 상태가 유지되지 않는 (stateless) 모델을 사용하고, 사후 교정자가 세그먼트당 30초밖에 할애할 수 없는 AI 워크플로 (workflow)에서는 통하지 않습니다.

용어집 강제 적용은 기계가 읽을 수 있어야 하며 자동으로 확인되어야 합니다. 구체적으로는 다음과 같습니다:

1. 번역 전 주입 (Pre-translation injection): 용어집을 매 번역 호출 시마다 산문(prose) 형태가 아닌, 시스템 프롬프트(system prompt) 또는 구조화된 컨텍스트 블록(structured context block)으로 제공하십시오. 모델이 패턴 매칭(pattern-match)을 수행할 수 있는 구조화된 용어 목록 형태로 제공해야 합니다.
2. 번역 후 검증 (Post-translation verification): 출력물에 대해 정규 표현식(regex) 또는 자연어 처리(NLP) 검사를 실행하여, 모든 원문 언어의 용어집 항목이 승인된 대상 언어의 대응어로 매핑되었는지 확인하십시오. 불일치 사항은 사람이 검토하는 도중이 아니라, 검토 전 단계에서 미리 표시(flag)해야 합니다.
3. 용어집 버전 관리 (Version your glossary): 용어가 변경될 때(예: "workspace"를 "hub"로 리브랜딩할 때), 어떤 번역 자산이 오래되었는지(stale) 파악해야 합니다. 용어집 항목을 살아있는 문서(living document)가 아닌, 타임스탬프가 포함된 데이터베이스 레코드(database records)처럼 취급하십시오.

대규모로 깔끔한 현지화(localization)를 배포하는 팀들은 더 주의 깊게 검토하는 것이 아닙니다. 그들은 위반 사항을 구조적으로 놓칠 수 없게 만들었습니다.

편집 거리의 함정 (The Edit Distance Trap)

사후 교정(post-editing) 워크플로우에는 유혹적인 지표가 하나 있습니다. 바로 편집자가 기계 번역(MT) 결과물을 얼마나 많이 수정했는지 추적하는 것입니다. 편집 거리(edit distance)가 낮으면 = 기계 번역 품질이 좋음 = 인간의 작업량이 적음이라는 공식입니다. 이는 전체적인 관점에서는 맞지만, 세그먼트(segment) 단위에서는 위험합니다.

편집자들은 틀렸지만 '그럭저럭 통하는' 문장들을 그대로 두는 법을 배웁니다. 왜냐하면 그것을 수정하는 데 노력이 들고, 그 세그먼트가 일단 '제 역할을 하기' 때문입니다. 시간이 흐르면서, '틀렸지만 통하는' 문장들이 쌓이면 마치 해당 언어를 제3외국어로 사용하는 사람이 번역한 것 같은 제품이 됩니다. 원어민 사용자들은 이를 말로 설명하기 전부터 이미 느낍니다.

이에 대한 대응책은 다음과 같습니다. 편집 거리가 '0'인 세그먼트들을 주기적으로 샘플링하여

번역된 자산을 최종 승인하기 전에, 다음 순서대로 검토를 진행하십시오:

자동화된 점검 (반드시 통과해야 하는 항목)

• 모든 용어집 (Glossary) 용어가 승인된 대상 언어 대응어와 일치하는지 확인
• 포맷 문자열 (Format strings) 및 변수 유지 여부 확인 ({name}, %s 등)
• 숫자, 통화, 날짜가 원문과 일치하는지 (또는 로캘 (Locale) 규칙에 따라 올바르게 현지화되었는지) 확인
• 출력물에 번역되지 않은 원문 언어 문자열이 없는지 확인
• UI 문자열의 경우 글자 수 제한 준수 여부 확인 (해당하는 경우)

사람에 의한 검토 (고위험 세그먼트 대상)

• 고유 명사 및 브랜드명이 올바르게 처리되었는지 확인
• 말투/격식 (Register/formality)이 대상 시장의 관습과 일치하는지 확인
• 관용구 (Idiomatic expressions)가 직역된 형태가 아닌, 자연스러운 대상 언어 대응어로 해결되었는지 확인
• CTA (Call to Action) 및 감성적/마케팅 문구가 단순 이중 언어 구사자가 아닌, 원어민 (Native speaker)에 의해 검토되었는지 확인
• 자연스러움을 확인하기 위해 편집 거리(Edit distance)가 '0'인 샘플에 대한 스팟 체크 수행

최종 단계

• 향후 세그먼트를 위해 변경 사항을 번역 메모리 (Translation memory)에 역전파 (Back-propagated)
• 이상 세그먼트 (높은 편집 거리, 특이한 오류)를 모델 프롬프트 (Model prompt) 개선을 위해 플래그(Flag) 처리

이것이 전부는 아닙니다. 하지만 실제 프로덕션 (Production) 단계까지 도달하는 오류 유형들을 방지하기 위한 최소한의 조치입니다.

AI Handler가 이를 다루는 방식

AI Handler를 구축하면서 저는 번역 워크플로우를 사후 고려 사항이 아닌, 일급 시민 (First-class) 유스케이스로 생각해야만 했습니다. 제가 계속해서 마주했던 문제는, "용어집을 사용하고, 출력물을 검토하며, 민감한 콘텐츠는 번역가를 고용하라"는 표준적인 조언들이 맞기는 하지만, 번역이 병렬로 실행되는 20가지 AI 작업 중 하나인 실제 개발 워크플로우 내에서는 실행 가능한(Actionable) 수준이 아니라는 점이었습니다.

AI Handler의 접근 방식은 사후 교정 (Post-Editing)을 수동 검토 단계가 아닌 구조화된 파이프라인 단계 (Pipeline stage)로 취급하는 것입니다. 즉, 어떤 세그먼트 (Segment)가 인간 검토자에게 도달하기 전에 위험 점수 산정 (Risk scoring)이 자동으로 이루어지며, 용어집 준수 (Glossary enforcement)는 번역 결과물이 확정되기 전에 모든 출력물에 적용되는 컴파일된 규칙 세트 (Compiled rule set)로 작동하고, 편집 거리 (Edit distance)의 이상 징후는 조용한 품질 저하가 아닌 워크플로우 경고 (Workflow alerts)로 나타납니다.

제가 다른 곳에서는 본 적 없는, 현재 구축 중인 구체적인 기능은 세그먼트 수준의 신뢰도 감사 추적 (Segment-level confidence audit trail)입니다. 모든 번역된 세그먼트에는 왜 해당 세그먼트가 플래그 (Flagged) 처리되었는지 또는 통과되었는지, 어떤 용어집 용어들이 확인되었는지, 그리고 모델의 지시 문맥 (Instruction context)이 무엇이었는지에 대한 메타데이터 (Metadata)가 포함됩니다. 운영 환경 (Production)에서 문제가 발생했을 때 (반드시 발생하게 됩니다), 무슨 일이 일어났는지 파악하기 위해 완성된 번역문을 뚫어지게 쳐다보는 대신, 파이프라인 내에서 결정이 내려진 정확한 지점으로 추적해 올라갈 수 있습니다.

목표는 번역에서 인간의 판단을 제거하는 것이 아닙니다. 인간의 판단이