다음에 올 것을 만들어가는 기술에 대한 심층 기사.

기계 번역의 저자원 언어 문제

1,600개 이상의 언어를 번역하는 일이 영어 중심 MT보다 왜 근본적으로 어려운지, 그리고 새로운 접근법이 격차를 어떻게 줄이는지 살펴봅니다.

책이 밝게 진열된 책장과 어둠 속으로 사라지는 수백 권의 책

지구상에서 쓰이는 언어는 대략 7,000개입니다. 구글 번역은 그중 약 130개를 지원하고, 대부분의 상용 MT 시스템은 30개 미만의 언어를 제대로 처리합니다. 요루바어, 케추아어, 크메르어를 쓰는 사람이라면 기계 번역 경험이 '겨우 쓸 만하다'에서 '어이없을 정도로 틀린다' 사이를 오갈 겁니다. 불편하지만 사실은, 지난 10년간 NLP의 발전 대부분이 영어 중심으로 이루어졌고 고자원 언어와 저자원 언어 사이의 격차는 줄어들기는커녕 점점 벌어지고 있다는 점입니다.

Meta가 최근 추진 중인 1,600개 이상의 언어를 아우르는 '옴니링구얼 기계 번역'은 이 상황을 바꾸려는 가장 야심 찬 시도 중 하나입니다. 하지만 여기에 얽힌 기술적 난제들은 언어 모델을 만드는 방식에 깔린 근본적인 가정을 드러내고, 단순히 규모를 키우는 것만으로는 문제가 해결되지 않는 이유를 보여줍니다.

'저자원' 언어란 무엇인가

MT 연구에서 '고자원' 언어쌍이란 수백만 개의 병렬 문장, 즉 두 언어 사이에서 전문 번역가가 번역한 텍스트가 있다는 뜻입니다. 영어–프랑스어, 영어–중국어, 영어–스페인어 같은 쌍은 EU 의회, UN, 뉴스 기관, 수십 년간의 전문 번역 작업에서 나온 방대한 병렬 코퍼스를 갖고 있습니다. 이런 쌍으로 학습한 모델은 놀라울 만큼 잘 동작합니다.

'저자원' 언어는 병렬 문장이 수천 개밖에 없거나 아예 없을 수도 있습니다. 베냉에서 약 200만 명이 쓰는 폰어는 영어와의 병렬 데이터가 사실상 전무합니다. 말리에서 약 1,400만 명이 쓰는 밤바라어는 그보다 조금 나은 편이지만, 기존 MT 시스템이 필요로 하는 양에 비하면 여전히 몇 자릿수나 부족합니다. 많은 언어의 경우 사용 가능한 가장 큰 텍스트 코퍼스가 성경 번역본과 위키백과 몇 개 문서가 전부입니다.

자원 격차는 데이터 양의 문제만이 아닙니다. 데이터의 다양성 문제이기도 합니다. 저자원 언어에 병렬 텍스트가 존재하더라도 대개 종교 서적이나 정부 문서에 집중되어 있습니다. 모델은 격식 있고 반복적인 문장은 잘 번역하지만, 일상 대화나 기술 용어, 학습한 좁은 영역에서 벗어나는 내용에서는 무너집니다.

규모만 키워서는 해결되지 않는 이유

현대 머신러닝의 직관은 이렇습니다. 데이터를 더 모으고, 모델을 더 키우면 결과가 좋아진다. 영어 중심 과제에서는 이 방식이 엄청난 성과를 냈습니다. 수조 개의 영어 토큰으로 학습한 GPT 계열 모델은 놀랍도록 유창한 텍스트를 만들어냅니다. 하지만 이 접근법은 저자원 MT에서 세 가지 치명적인 실패 지점을 가집니다.

  • 데이터 자체가 없습니다. 아무도 상당한 양을 공개한 적이 없다면, 인터넷에서 폰어–영어 병렬 텍스트를 긁어올 수는 없습니다. 대규모 MT 학습 세트의 대부분을 만드는 웹 크롤링은 본질적으로 인터넷 점유율이 큰 언어 쪽으로 편향되어 있습니다.
  • 토크나이저가 무너집니다. 대부분의 언어 모델은 영어(또는 소수의 고자원 언어)로 학습된 토크나이저를 씁니다. 영어 기반 BPE 토크나이저에 암하라 문자나 버마어 텍스트를 넣으면 글자가 터무니없이 긴 토큰 시퀀스로 쪼개집니다. 암하라어 단어 하나가 8~12개의 토큰을 차지하기도 합니다. 그 결과 모델은 컨텍스트 윈도우의 대부분을 입력을 인코딩하는 데 써버리고, 실제로 이해하는 데 쓸 여유가 거의 남지 않습니다.
  • 전이 학습에는 한계가 있습니다. mBERT나 XLM-R 같은 다국어 모델은 여러 언어로 학습하면 저자원 언어에도 도움이 된다는 것을 보여줍니다. 모델이 구조적 유사성을 포착하기 때문입니다. 하지만 이런 전이는 서로 관련 있는 언어 사이에서 가장 강합니다. 프랑스어를 잘 아는 모델은 그 지식의 일부를 아이티 크리올어로 옮길 수 있지만, 중국어나 나바호어에는 거의 옮기지 못합니다.

피벗 언어 문제

수백 개 언어를 지원한다고 주장하는 대부분의 MT 시스템은 실제로 모든 것을 영어를 거쳐 번역합니다. 스와힐리어를 태국어로 옮기고 싶다고요? 시스템은 스와힐리어 → 영어 → 태국어 순으로 번역합니다. 이런 '피벗' 방식은 실용적입니다. 영어와 주고받는 번역 모델만 만들면 되니까요. 그러나 오류가 누적되고, 미묘하지만 문화적 평탄화라는 부작용을 낳습니다.

피벗 언어로 영어를 거치면 영어로 깔끔하게 대응되지 않는 개념이 사라집니다. 일본어는 동사 활용으로 여러 단계의 존대를 표현합니다. 요루바어는 성조의 차이로 뜻이 달라집니다. 타밀어에는 듣는 사람을 포함하는지 여부에 따라 나뉘는 '우리'(포괄형과 배제형)가 있습니다. 이런 정보가 영어라는 병목을 지나면 손실됩니다. 영어에는 이런 구분이 없어서 모델이 이를 보존할 방법이 없기 때문입니다.

영어를 거치지 않는 직접 번역, 예컨대 스와힐리어에서 태국어로 바로 옮기면 정보가 더 많이 보존됩니다. 하지만 가능한 모든 언어쌍마다 직접 번역 모델을 만드는 것은 조합상 불가능합니다. 1,600개 언어라면 방향이 있는 번역쌍만 256만 개가 필요합니다. 사용자가 많은 상위 100개 언어만 직접 다루더라도 여전히 9,900쌍이 필요합니다.

최신 접근법은 무엇이 다른가

현재 세대의 대규모 다국어 MT 모델은 피벗 전략과 근본적으로 다른 방식을 택합니다. 언어쌍마다 모델을 따로 만드는 대신, 모든 언어를 동시에 아우르는 공유 표현을 학습하는 단일 모델을 만듭니다. 핵심 혁신은 몇 가지 범주로 나뉩니다.

언어 중립적 토큰화

토크나이저 문제는 영어 편중 코퍼스 대신 균형 잡힌 다국어 코퍼스로 토크나이저를 학습시키는 방식으로 해결되고 있습니다. Meta의 접근법은 문자 단위 폴백을 써서 어떤 언어도 비정상적으로 긴 토큰 시퀀스를 갖지 않도록 합니다. 언어 균형을 명시적으로 맞춰 학습한 SentencePiece 모델은 훨씬 공평한 토큰화를 만들어냅니다. 의미가 비슷한 요루바어 문장과 영어 문장은 대략 비슷한 수의 토큰을 소비하게 됩니다.

이 문제는 생각보다 중요합니다. 어떤 언어의 토크나이저 효율이 4배 떨어진다면, 모델은 그 언어를 처리할 용량이 사실상 4배 적은 셈입니다. 토큰화를 고치는 것이 저자원 언어 성능을 높이는 가장 효과가 큰 개선입니다.

야생에서 병렬 데이터 채굴하기

가장 영리한 기술적 기여 중 하나는 자동 병렬 데이터 마이닝입니다. 아이디어는 이렇습니다. 어떤 언어의 문장이든 공유 임베딩 공간에 매핑하는 다국어 문장 인코더를 학습시킵니다. 그다음 웹을 크롤링하여 서로 다른 언어이면서 비슷한 벡터로 매핑되는 문장들을 찾습니다. 이 문장들은 서로의 번역일 가능성이 높습니다.

LASER 같은 도구에서 선구적으로 시도되고 이후 연구에서 확장된 이 기법은 CCNet이나 OSCAR 같은 웹 크롤링 데이터에서 수억 개의 병렬 문장을 뽑아냈습니다. 노이즈가 많아서 추출된 쌍 중 20~30% 정도만 실제로 병렬인 것으로 보입니다. 하지만 필터링 휴리스틱으로 정밀도를 높일 수 있고, 엄청난 양이 노이즈를 상쇄합니다. 일부 언어의 경우, 이 자동 마이닝으로 얻은 병렬 데이터가 기존의 사람이 큐레이션한 데이터셋을 모두 합친 것보다 많아졌습니다.

역번역과 자기 학습

역번역은 기존의 (불완전한) MT 모델로 단일 언어 텍스트를 목표 언어로 번역한 뒤, 그렇게 만든 합성 병렬 쌍으로 더 나은 모델을 학습시키는 기법입니다. 부트스트래핑이라고 할 수 있고, 놀랄 만큼 잘 작동합니다.

순환 구조는 이렇습니다. 가능한 병렬 데이터로 초기 모델을 학습시키고, 그 모델로 단일 언어 데이터를 번역하고, 나쁜 번역을 걸러낸 뒤, 실제 데이터와 합성 데이터를 합쳐 다시 학습시키고, 이를 반복합니다. 매 반복마다 모델이 좋아지고, 좋아진 모델은 더 나은 합성 데이터를 만들며, 이는 다음 반복을 또 개선합니다. 병렬 문장이 수천 개뿐인 언어에서도 역번역은 학습 데이터를 10~50배로 불릴 수 있습니다.

# Simplified back-translation loop
def back_translate_cycle(model, parallel_data, monolingual_target, rounds=3):
for round in range(rounds):
# Generate synthetic source from monolingual target text
synthetic_pairs = []
for target_sent in monolingual_target:
source_sent = model.translate(target_sent, direction='reverse')
score = model.score_pair(source_sent, target_sent)
if score > QUALITY_THRESHOLD:
synthetic_pairs.append((source_sent, target_sent))
# Combine real and synthetic data
combined = parallel_data + synthetic_pairs
# Retrain model on combined data
model = train_mt_model(combined)
print(f'Round {round+1}: {len(synthetic_pairs)} synthetic pairs added')
print(f'BLEU score: {evaluate(model, test_set)}')
return model

평가는 생각보다 어렵다

BLEU 점수는 MT 품질의 표준 지표지만 저자원 언어에서는 심각한 문제가 있습니다. BLEU는 모델 출력과 참조 번역 사이의 n-gram 겹침을 측정합니다. 영어는 어순이 비교적 고정되어 있고 형태 변화가 적어서 이 지표가 꽤 잘 작동합니다. 하지만 터키어나 핀란드어처럼 교착어에서는 한 단어가 영어의 한 구절에 해당하는 의미를 담기 때문에, BLEU는 다른 형태소를 쓴 올바른 번역에 감점을 줍니다.

참조 번역의 문제도 있습니다. 평가에 쓰는 참조 번역은 누가 만들었을까요? 고자원 언어에는 전문 번역가가 있습니다. 많은 저자원 언어의 '골드 스탠더드' 참조 번역은 선교사, 격식체로 작업하는 정부 번역가, 또는 대학원생이 만든 것입니다. 이런 참조 번역은 기술적으로는 맞지만 문체가 어색할 수 있고, 더 자연스러운 번역을 만드는 모델이 오히려 낮은 점수를 받기도 합니다.

COMET이나 BLEURT 같은 새로운 지표는 신경망 모델로 번역 품질을 추정하고 사람의 판단과 더 잘 맞습니다. 하지만 이들 역시 주로 고자원 언어 데이터로 학습되어 구조가 많이 다른 언어에는 잘 일반화되지 않을 수 있습니다. 일부 팀은 가장 중요한 언어쌍에 대해 원어민과 함께 사람이 직접 평가하기 시작했지만, 이 방식은 1,600개 언어로 확장할 수 없습니다.

문화적, 윤리적 측면

1,600개 언어를 위한 MT를 만드는 일은 단순한 엔지니어링 과제가 아닙니다. 누가 이익을 얻는지, 언어를 어떻게 표현할지 누가 결정하는지, 그리고 모델이 잘못되었거나 편향된 번역을 담고 있을 때 무슨 일이 생기는지에 대한 질문을 던집니다.

많은 멸종 위기 언어의 주된 화자는 농촌 지역의 고령 공동체 구성원입니다. 그들은 기계 번역 API를 사용하는 사람들이 아닙니다. 직접적인 수혜자는 연구자, NGO, 정부일 가능성이 높으며, 이는 상황에 따라 좋을 수도(정보 접근성 향상) 문제가 될 수도(감시, 강제 동화) 있습니다. 공동체의 의견 없이 개발된 원주민 언어 MT는 불편한 역사를 가지고 있습니다.

언어 표준화 문제도 있습니다. 많은 저자원 언어는 방언 차이가 크고 단일한 '표준형'이 없습니다. MT 모델이 하나의 방언을 기준으로 삼으면(대개 학습 데이터에 가장 많이 나타난 방언), 다른 방언 화자를 암묵적으로 소외시킵니다. 이건 가설이 아닙니다. 자원이 더 많은 언어에서도 이미 일어나고 있습니다. 아랍어 MT 모델은 현대 표준 아랍어는 잘 처리하지만, 실제로 수억 명이 쓰는 이집트, 레반트, 걸프 방언에는 어려움을 겪습니다.

개발자에게 의미하는 것

글로벌 사용자를 대상으로 소프트웨어를 만든다면, MT의 현 상태는 아키텍처와 제품 결정에 실질적인 영향을 줍니다.

  • MT 품질이 균일하다고 가정하지 마세요. 앱이 현지화를 위해 구글 번역이나 비슷한 API를 쓸 수 있습니다. 프랑스어 품질은 훌륭하지만, 암하라어는 간신히 쓸 만한 수준일 수 있습니다. 상위 10개 언어만이 아니라 지원한다고 밝힌 모든 언어를 원어민과 함께 테스트하세요.
  • MT 실패를 우아하게 처리하도록 설계하세요. 번역문 옆에 원문을 함께 보여주세요. 사용자가 잘못된 번역을 신고할 수 있게 하세요. 콘텐츠가 기계 번역되었다는 사실을 숨기지 마세요. 사용자는 어차피 알아챌 것이고, 사람이 번역한 품질인 척했다는 걸 알게 되면 더 신뢰하지 않을 겁니다.
  • 토큰화 비용을 고려하세요. 다국어 환경에서 MT뿐 아니라 언어 모델을 쓴다면, 영어가 아닌 언어는 더 많은 토큰을 소비한다는 점을 기억하세요. 4K 컨텍스트 윈도우에는 영어보다 태국어나 아랍어 텍스트가 훨씬 적게 들어갑니다. 이를 감안해 예산을 잡으세요.
  • 다국어 테스트 데이터에 투자하세요. 저자원 언어를 지원할 때 가장 어려운 부분은 모델이 아니라 출력이 맞는지 아는 일입니다. 품질을 검증해 줄 수 있는 원어민과 관계를 맺으세요. 자동화된 지표는 여러분을 오도할 수 있습니다.

앞으로의 길

옴니링구얼 MT를 향한 움직임은 여러 한계에도 불구하고 분명 흥미롭습니다. 5년 전만 해도 병렬 문장이 1만 개인 언어의 번역 모델을 만드는 것은 연구의 호기심 거리에 불과했을 겁니다. 오늘날에는 역번역, 다국어 전이, 자동 병렬 마이닝 같은 기법 덕분에 완벽하지는 않더라도 실제로 쓸 만한 수준에 도달할 수 있게 되었습니다.

남은 과제는 기술만큼이나 사회적인 것입니다. 멸종 위기 언어의 학습 데이터를 얻으려면 웹 크롤링이 아니라 공동체와의 협력이 필요합니다. 대규모로 품질을 평가하려면 새로운 지표와 원어민의 참여가 필요합니다. MT 도구가 단순히 지원 언어 목록을 채우는 데 그치지 않고, 실제로 그 언어를 쓰는 공동체에 도움이 되도록 하려면 지속적인 소통이 필요합니다.

그래도 방향은 옳습니다. 언어가 정보 접근의 장벽이 되어서는 안 되며, 같은 30개 언어를 계속 최적화하는 대신 1,600개 언어를 위한 번역 시스템을 만들려고 한다는 사실 자체가 우선순위의 의미 있는 전환입니다. 엔지니어링은 어렵습니다. 토큰화 문제 하나를 제대로 찾아 해결하는 데만 수년이 걸렸습니다. 하지만 기술 업계에서 언어가 무시되어 온 수십억 명에게 이 작업은, 영어–프랑스어 BLEU 점수를 0.1% 더 올리는 것보다 훨씬 중요합니다.