AI 번역이 싸졌는데 왜 현지화 비용은 그대로인가
LLM이 등장하면서 초벌 번역 단가는 사실상 바닥으로 내려갔습니다. 예전에는 단어당 100~150원을 지불하던 작업이 지금은 API 호출 몇 번으로 끝납니다. 그런데 실제로 다국어 제품을 운영하는 팀에 물어보면 현지화 총비용은 기대만큼 줄지 않았다고 답합니다. 이유는 단순합니다. 번역 단계는 전체 현지화 공정에서 비용의 일부일 뿐이기 때문입니다.
현지화 비용 구조를 뜯어보면 초벌 번역이 차지하는 비중은 30~40% 수준이고, 나머지는 검수, 수정 반영, 빌드 확인, 재배포, 그리고 오역 발견 후 되돌리는 공수입니다. 번역 단가만 90% 줄여도 전체 비용은 30% 남짓 줄어드는 데 그칩니다. 나머지 공정이 여전히 수작업이라면 오히려 더 많은 번역물이 쏟아져 들어와 검수 병목이 심해지기도 합니다.
콘텐츠 유형별로 요구 품질이 다르다는 점도 자주 간과됩니다. 제품 UI 문자열은 짧고 문맥이 없어서 오역 확률이 높은 대신 수정 비용이 낮습니다. 도움말 문서는 분량이 많지만 오역이 곧 문의 증가로 이어집니다. 계약서와 약관은 한 문장의 오역이 법적 책임으로 직결되고, 마케팅 문구는 정확도보다 현지 정서에 맞는 재창작(트랜스크리에이션)이 필요합니다. 이 네 가지에 같은 품질 기준과 같은 프로세스를 적용하면 어느 한쪽은 반드시 과잉이거나 부족합니다.
무엇보다 제품 문서는 한 번 번역하고 끝나지 않습니다. 주 1회 릴리스하는 SaaS 제품이라면 UI 문자열이 매주 20~50개씩 바뀝니다. 전체를 다시 번역하면 비용과 리드타임이 폭증하고, 바뀐 것만 골라내는 작업을 사람이 하면 누락이 발생합니다.
파이프라인으로 만들지 않으면 반복되는 문제
현지화를 프로젝트가 아니라 상시 운영되는 파이프라인으로 설계해야 합니다.
추출: 번역 대상만 정확히 분리하기
코드의 하드코딩 문자열, CMS 콘텐츠, 마크다운 문서는 저장 위치와 형식이 모두 다릅니다. 첫 단계는 각 소스에서 번역 대상 텍스트만 구조적으로 추출하는 것입니다. Next.js 기반 프로젝트라면 `messages/ko.json` 같은 메시지 카탈로그가 이미 추출 결과물 역할을 하므로, 여기에 CMS와 문서 소스를 같은 스키마로 합류시키는 설계가 유리합니다.
증분 처리와 번역 메모리
원문에 콘텐츠 해시를 붙여 두면 변경된 항목만 번역 큐에 들어갑니다. 여기에 번역 메모리(TM)를 붙이면 과거에 승인된 동일·유사 문장을 재사용할 수 있습니다. 제품 문서처럼 반복 표현이 많은 콘텐츠에서는 TM 매치율이 40~60%까지 나오고, 그만큼 LLM 호출과 검수 대상이 줄어듭니다.
용어집과 스타일 가이드는 데이터로 관리
용어 규칙을 프롬프트 문자열에 직접 써넣는 방식은 초기에는 편하지만 곧 한계에 부딪힙니다. 용어가 200개를 넘어가면 프롬프트가 비대해지고, 누가 언제 무엇을 바꿨는지 추적할 수 없습니다. 용어집은 별도 테이블로 관리하고, 번역할 문장에 실제로 등장하는 용어만 골라 프롬프트에 주입하는 방식이 정확도와 토큰 비용 양쪽에서 유리합니다.
번역 금지 항목 잠금
브랜드명, 제품명, 법률 고지 문구, API 파라미터명은 절대 번역되면 안 됩니다. 이런 항목은 사전에 플레이스홀더로 치환한 뒤 번역이 끝나고 복원하는 방식이 안전합니다. 프롬프트로 "번역하지 마세요"라고 지시하는 것만으로는 수백 건 중 몇 건이 반드시 새어 나갑니다.
품질을 측정 가능한 형태로 바꾸기
전량 검수에서 위험 기반 샘플링으로
모든 문장을 사람이 보는 방식은 물량이 늘어나는 순간 무너집니다. 대신 위험도로 등급을 나눕니다. 계약서·결제·보안 안내는 전량 검수, 제품 UI는 신규 문자열 전량 + 수정 문자열 샘플링, 블로그와 도움말은 자동 검증 통과 시 샘플 10~20%만 검수하는 식입니다.
자동 검증으로 걸러낼 수 있는 것들
사람이 볼 필요 없이 기계가 확실히 잡아내는 항목이 생각보다 많습니다.
이 네 가지만 자동화해도 실무에서 발견되는 결함의 상당수가 사람 손에 닿기 전에 걸러집니다.
LLM 심사의 유효 범위
LLM-as-judge는 "이 번역이 자연스러운가", "원문 의미를 빠뜨렸는가" 같은 판단에서 유용하지만 한계가 분명합니다. 점수 절대값은 프롬프트와 모델 버전에 따라 흔들리므로 합격/불합격 기준선으로 쓰기보다 검수 우선순위를 매기는 정렬 도구로 쓰는 편이 안전합니다. 도메인 지식이 필요한 오역이나 법률적 뉘앙스는 여전히 사람이 봐야 합니다.
검수 인력 배치
모든 언어에 동일한 검수 인력을 두는 것은 낭비입니다. 매출 기여도와 사용자 수 상위 2~3개 언어에 상주 검수자를 두고, 나머지는 자동 검증 + 분기별 감사로 운영하는 구성이 현실적입니다.
시스템에 붙일 때의 엔지니어링 이슈
문맥 정보를 함께 넘기기
`button.save`라는 키에 "저장"만 던져 주면 모델은 이것이 버튼인지 메뉴인지 알 수 없습니다. 키 경로, 화면 이름, 문자열 최대 길이, 스크린샷 캡션 같은 메타데이터를 함께 넘기면 오역이 눈에 띄게 줄어듭니다. i18n 키를 처음부터 `settings.account.deleteButton`처럼 위계가 드러나게 설계해 두는 것이 나중에 큰 차이를 만듭니다.
번역만으로 해결되지 않는 영역
복수형 규칙은 언어마다 다릅니다. 영어는 2개 형태, 러시아어는 4개 형태를 요구하므로 문자열을 이어 붙이는 방식으로는 대응할 수 없고 ICU MessageFormat 같은 표준을 써야 합니다. 날짜, 통화, 숫자 구분 기호는 번역이 아니라 포맷터의 영역이며, 어순이 바뀌는 언어에서는 문장을 조각내어 조립하는 코드가 반드시 깨집니다.
배포 파이프라인과의 연결
번역이 비어 있는 키가 있으면 CI에서 빌드를 실패시키거나 최소한 경고를 띄워야 합니다. 릴리스 전 커버리지 체크를 자동화하면 "영어만 나오는 화면"이 프로덕션에 올라가는 사고를 구조적으로 막을 수 있습니다.
어디서부터 시작할 것인가
우선순위는 감이 아니라 데이터로 정합니다. 트래픽·매출 기여도가 높은 언어, 그리고 오역 시 손실이 큰 콘텐츠 유형부터 착수합니다. 대개 제품 UI와 결제·온보딩 흐름이 첫 번째 대상입니다.
초기 3개월 로드맵 예시
성과는 세 가지 지표로 봅니다. 수정률(사람이 손댄 문장 비율)은 파이프라인 품질을, 리드타임(원문 변경부터 번역 배포까지 걸린 시간)은 운영 속도를, 언어별 이탈률과 전환율은 현지화가 실제 사업 성과로 이어졌는지를 보여줍니다.
---
POLYGLOTSOFT는 next-intl 기반 다국어 웹 서비스와 앱을 직접 설계·운영하며 쌓은 경험을 바탕으로, 콘텐츠 추출부터 LLM 번역, 자동 검증, CI 연동까지 이어지는 현지화 파이프라인 구축을 지원합니다. 기존 시스템의 i18n 구조 진단, 용어집 설계, 품질 게이트 자동화까지 단계별로 함께 진행할 수 있습니다. 다국어 서비스 확장을 준비 중이시라면 [문의하기](https://polyglotsoft.dev/ko/support/contact)를 통해 현재 구조에 맞는 접근 방식을 상담해 보시기 바랍니다.