AI 번역 비교: Gemini vs GPT-4 vs DeepSeek, .po 파일 번역 성능은?

역사상 가장 강력한 AI 모델 세 가지를 바로 사용할 수 있습니다. WordPress .po 문자열을 각 모델에 붙여넣습니다. 그중 두 가지는 웹사이트를 망가뜨립니다.

이는 가상 시나리오가 아닙니다. "영어를 잘한다"는 것이 "Gettext를 잘한다"는 의미라고 가정하는 개발자에게 매일 일어나는 일입니다. 사실 WordPress 로컬라이제이션 파일을 번역하는 것은 특수한 작업이며, 각 대규모 언어 모델은 이를 매우 다르게 처리합니다.

Gemini 2.0 Flash, GPT-4, DeepSeek에 동일한 .po 문자열 세트를 실행하여 어떤 모델이 가장 정확하고 코드에 안전한 번역을 생성하는지 알아봤습니다. 결과는 놀라웠습니다.

테스트 설정: 번역 대상

프로덕션 WooCommerce 스토어와 인기 WordPress 테마에서 실제 문자열 200개를 선택했습니다. 테스트 세트는 다음과 같은 까다로운 항목을 의도적으로 포함했습니다.

• 간단한 UI 문자열 ("장바구니에 담기", "검색 결과")
• printf 변수가 포함된 문자열 (%s, %d, %1$s of %2$s)
• HTML 마크업이 포함된 문자열 (<strong>, <a href>, <br/>)
• 폴란드어(3개 형태) 및 아랍어(6개 형태)를 대상으로 하는 복수형 (msgid_plural)
• "Post"가 블로그 게시물을 의미하거나 "게시하다"라는 동사를 의미할 수 있는 컨텍스트 (msgctxt)가 있는 문자열

각 모델은 소스에 나타나는 모든 변수와 HTML 태그를 정확하게 유지하면서 이러한 Gettext 항목을 영어에서 터키어로 번역하라는 동일한 프롬프트를 받았습니다.

그런 다음 각 출력을 자리 표시자 무결성, HTML 구조, 복수형 개수, 문자 인코딩을 확인하는 유효성 검사 도구를 통해 실행했습니다.

1라운드: 간단한 UI 문자열

세 가지 모델 모두 기본적인 문자열을 잘 처리했습니다. "Add to Cart"는 모두 "Sepete Ekle"가 되었습니다. "Log In"은 올바르게 렌더링되었습니다. 여기서는 놀라운 점이 없었습니다.

하지만 이 간단한 범주에서도 패턴이 나타났습니다. GPT-4는 때때로 소스에 없는 정중한 표현을 추가했습니다. 간결한 "Delete"는 더 격식 있는 표현으로 바뀌었고, 3~4자가 추가되었습니다. 버그는 아니지만 버튼 너비가 고정된 UI 레이아웃에서는 문제가 될 수 있습니다.

DeepSeek는 약간 더 문자 그대로의 번역을 생성했는데, 이는 간결성이 중요한 UI 요소에 더 적합합니다.

Gemini는 소스 문자열의 어조와 길이에 가장 일관되게 맞춰 균형을 맞췄습니다.

판결: 간단한 문자열

세 가지 모두 통과. 사소한 스타일 차이만 있음.

2라운드: Printf 변수 및 위치 인수

여기서 실제 차이점이 나타납니다. 일반적인 WordPress 문자열을 살펴보겠습니다.

msgid "Page %1$s of %2$s"
msgstr ""

다음은 각 모델이 터키어로 번역했을 때 생성한 결과입니다.

# Gemini 2.0 Flash
msgstr "Sayfa %1$s / %2$s"

# GPT-4
msgstr "Sayfa %1$s / %2$s"

# DeepSeek
msgstr "%1$s / %2$s. Sayfa"

세 가지 모두 변수를 기술적으로는 그대로 유지했습니다. 하지만 DeepSeek는 문장 구조를 재정렬하여 "Sayfa"를 끝으로 옮겼습니다. 문법적으로는 창의적이지만 의미가 변경됩니다. 이제 사용자는 "페이지 1/10" 대신 "1/10. 페이지"로 읽게 됩니다.

이제 더 위험한 예를 살펴보겠습니다.

msgid "Hello %s, you have %d new messages"
msgstr ""

# Gemini 2.0 Flash
msgstr "Merhaba %s, %d yeni mesajiniz var"

# GPT-4
msgstr "Merhaba %s, %d yeni mesajınız var"

# DeepSeek
msgstr "Merhaba % s, % d yeni mesajınız var"

바로 이거입니다. DeepSeek는 %s 및 %d 내부에 공백을 추가하여 % s 및 % d로 바꿨습니다. PHP의 sprintf()는 이를 인식하지 못합니다. 웹사이트에서 치명적인 오류가 발생하거나 사용자에게 원시 변수 문자열이 표시됩니다.

이는 저희가 문서화한 가장 흔한 번역 오류입니다. 자리 표시자 내부에 공백 하나가 웹사이트를 망가뜨리는 정확한 이유를 이해하려면 코드 변수 손상 방지 방법에 대한 심층 분석을 읽어보세요.

판결: 변수

Gemini와 GPT-4는 신뢰할 수 있습니다. DeepSeek는 사후 처리가 없으면 위험합니다.

3라운드: HTML 마크업 보존

WordPress 문자열에는 인라인 HTML이 자주 포함됩니다. 실제 예는 다음과 같습니다.

msgid "Click <a href=\"%s\">here</a> to view your <strong>order</strong>."
msgstr ""

# Gemini 2.0 Flash
msgstr "<a href=\"%s\">Buraya</a> tıklayarak <strong>siparişinizi</strong> görüntüleyin."

# GPT-4
msgstr "Siparişinizi görüntülemek için <a href=\"%s\">buraya</a> tıklayın.</strong>"

# DeepSeek
msgstr "<a href=\"%s\">buraya</a> tıklayarak <strong>siparişinizi</strong> görüntüleyin."

GPT-4는 미묘하지만 중요한 오류를 저질렀습니다. 닫는 </strong> 태그를 문장 끝으로 옮겼습니다. 이는 여는 <strong> 태그와는 거리가 멉니다. 결과적으로 페이지의 "order" 뒤에 오는 모든 내용이 굵게 표시되어 아래 전체 레이아웃에 영향을 미칠 수 있습니다.

Gemini와 DeepSeek는 이 경우 HTML 구조를 올바르게 보존했습니다. 하지만 전체 200개 문자열 테스트에서 DeepSeek는 자체 닫힘 태그 내부에 공백을 추가했습니다(<br />가 <br / >가 됨) (3건).

판결: HTML

Gemini가 가장 일관성이 높습니다. GPT-4와 DeepSeek는 모두 특정 조건에서 구조적 HTML 오류를 일으킵니다.

4라운드: 복수형

복수형 처리는 대부분의 번역 도구가 완전히 실패하는 부분입니다. 영어에는 복수형이 2개 있습니다. 터키어에도 2개가 있습니다. 하지만 폴란드어에는 3개, 아랍어에는 6개가 있습니다.

이 문자열을 폴란드어(nplurals=3)에 대해 테스트했습니다.

msgid "%d item in your cart"
msgid_plural "%d items in your cart"

Gemini는 각 숫자 범위에 맞게 활용된 세 개의 msgstr 항목을 올바르게 생성했습니다. GPT-4도 세 개의 형태를 생성했지만 때때로 1형과 2형을 동일한 텍스트로 축소했는데, 이는 폴란드어 문법적으로 올바르지 않습니다. DeepSeek는 nplurals=3 요구 사항을 완전히 무시하고 두 개의 형태만 생성했습니다.

이것이 왜 중요한지, WordPress가 Plural-Forms 헤더를 사용하는 방법에 대한 자세한 설명은 Gettext 복수형에 대한 가이드를 참조하세요.

판결: 복수형

Gemini가 선두입니다. GPT-4는 검토하면 허용됩니다. DeepSeek는 복수형이 2개 이상인 언어에서는 실패합니다.

5라운드: 컨텍스트 구분

Gettext의 msgctxt 필드는 번역가에게 단어가 어떻게 사용되고 있는지 알려줍니다. "Post"라는 단어는 다음을 의미할 수 있습니다.

• 블로그 게시물 (명사)
• 댓글을 게시하다 (동사)
• 우편/게시 (명사, 영국 영어)

msgctxt "verb: to publish"
msgid "Post"
msgstr ""

msgctxt "noun: blog entry"
msgid "Post"
msgstr ""

Gemini는 둘을 올바르게 구별하여 동사에는 "Yayinla"(게시), 명사에는 "Yazi"(기사/항목)를 생성했습니다. GPT-4도 이를 올바르게 처리했습니다. DeepSeek는 둘 다 "Gonderi"(일반 명사)로 번역하여 msgctxt 힌트를 무시했습니다.

컨텍스트 인식은 사치스러운 기능이 아닙니다. "게시" 버튼이 댓글을 게시하지만 번역에 "기사"라고 표시되면 사용자는 클릭하기를 주저할 것입니다. WordPress 로컬라이제이션의 AI 안전성이 정확히 이러한 종류의 컨텍스트 이해에 달려 있는지 논의했습니다.

판결: 컨텍스트

Gemini와 GPT-4는 msgctxt를 잘 처리합니다. DeepSeek는 이를 무시합니다.

점수표

원시 모델 출력이 결코 충분하지 않은 이유

저희 테스트에서 최고 성능을 보인 Gemini조차도 절대적으로 완벽하지는 않습니다. 200개의 문자열에서 2건의 간격 문제를 일으켰고, 소스에 없는 불필요한 마침표를 문자열에 한 번 추가했습니다.

이것이 사후 처리 유효성 검사가 필수적인 이유입니다. 어떤 모델을 사용하든 출력은 다음을 통해 실행해야 합니다.

1. % s를 다시 %s로 수정하는 자리 표시자 정규화
2. 번역된 문자열이 소스와 동일한 문자로 끝나는지 확인하는 구두점 일치
3. 올바른 수의 msgstr 항목을 확인하는 복수형 적용
4. 소스의 모든 %s 및 %d가 대상에 나타나는지 확인하는 변수 개수 유효성 검사

이것이 구문 잠금의 원리입니다. 구문 잠금은 AI 모델과 최종 .po 파일 사이에 있는 유효성 검사 계층으로, 최고의 모델조차도 때때로 만드는 모든 오류를 잡아냅니다.

워크플로에 사용할 도구를 평가하는 경우 PO 파일 편집 및 번역을 위한 상위 5가지 무료 도구에 대한 요약에서 AI 전용 솔루션 외의 상황을 다룹니다.

결론

Gemini 2.0 Flash는 현재 WordPress .po 파일 번역에 가장 신뢰할 수 있는 모델입니다. 경쟁 제품보다 변수, HTML, 복수형, 컨텍스트를 더 잘 처리합니다. GPT-4는 확실한 차선책이지만 HTML 출력 및 복수형에 대한 신중한 검토가 필요합니다. DeepSeek는 일반적인 코딩 작업에서는 강점을 보이지만 많은 사후 처리 없이는 Gettext 번역에 적합하지 않습니다.

하지만 핵심은 모델만으로는 충분하지 않다는 것입니다. Gemini조차도 엣지 케이스를 잡기 위한 유효성 검사 계층이 필요합니다. 전문 로컬라이제이션 도구와 원시 API 호출의 차이점은 AI 모델이 아닙니다. 모델이 실행되기 전과 후에 일어나는 모든 것입니다.

SimplePoTranslate는 구문 잠금이 있는 컨텍스트 인식 AI 파이프라인에 래핑된 Gemini를 기본 엔진으로 사용하여 모든 변수, 태그 및 복수형을 자동으로 잡아내고 수정합니다. 최고의 모델과 프로덕션 준비를 위한 안전망을 결합한 것입니다.

직접 차이점을 확인하고 싶으신가요? SimplePoTranslate.com에서 .po 파일을 업로드하고 최대 100개의 문자열을 무료로 번역해 보세요.