본문 바로가기
게임개발/가마수트라

언리얼 엔진에서 효과적인 현지화를 위한 개발자 가이드

by 아수랑 2025. 1. 25.
728x90

이 글에서는 위자드 오브 레전드 2 개발을 기반으로 언리얼 엔진 로컬라이제이션의 복잡성을 자세히 설명하는 인사이트를 공유합니다.

관련 분야: 프로덕션
작성자: Shayan Aminnezhad


소개

로컬라이제이션은 게임 개발에서 가장 중요하지만 종종 과소평가되는 측면 중 하나입니다. 전 세계 시청자가 증가함에 따라 플레이어는 자신의 모국어로 게임을 경험하기를 기대하기 때문에 효과적인 로컬라이제이션은 사치가 아닌 필수가 되었습니다. 하지만 로컬라이제이션은 단순히 텍스트를 번역하는 것뿐만 아니라 여러 언어에서 원활하고 원활한 경험을 제공하기 위해 기술적 문제, 문화적 뉘앙스, 워크플로 최적화를 해결해야 하는 과제를 해결해야 합니다.

이 글에서는 위자드 오브 레전드 2를 제작한 경험을 바탕으로 언리얼 엔진에서 로컬라이제이션의 복잡한 과정을 안내하고 인사이트를 공유하고자 합니다. 텍스트 수집 및 관리부터 잘못된 서식, 성별에 따른 언어, 폰트 처리와 같은 문제를 극복하는 방법까지 지연을 유발할 수 있는 주요 영역과 이를 완화하는 방법을 중점적으로 다뤄보겠습니다.

이 글은 입문서가 아니므로 언리얼의 기본 로컬라이제이션 툴에 익숙해야 합니다. 로컬라이제이션이 처음이라면 아래 리소스를 통해 기본을 익힐 수 있습니다. 준비가 되었다면 로컬라이제이션 프로세스를 보다 효과적으로 계획하는 데 도움이 되는 실제 도전 과제와 모범 사례를 살펴보겠습니다.

 

심층적인 현지화 - 이 동영상 시리즈에서는 언리얼의 현지화 파이프라인을 사용하는 데 필요한 모든 기본 사항을 다룹니다.

현지화 친화적인 UI를 만드는 방법

유니코드에 대해 알아야 할 최소한의 지식 - 유니코드에 익숙해지려면 이 글을 읽어보세요.

 

텍스트 수집

텍스트 수집은 간단합니다. 로컬라이제이션 대시보드를 열고 “텍스트 수집” 버튼을 누르면 완료됩니다!

하지만 상당한 시간이 소요되는 두 가지 주요 문제가 있습니다:

반응형


1. 관련 없는 텍스트

언리얼은 관련 없는 텍스트를 많이 수집합니다. 저희의 경우, 수집 결과에 나타난 텍스트의 약 80%가 관련 없는 텍스트였습니다. 이러한 텍스트는 게임 콘텐츠가 아닌 엔진 현지화를 위한 것으로 보였지만, 필터 환경설정에 관계없이 표시되었습니다.

이 문제를 해결하려면 텍스트 수집 명령이 텍스트를 찾는 위치를 필터링해야 합니다. 개발 후반 단계에서는 이 작업이 어려울 수 있으며, 필터가 모든 게임 콘텐츠를 포함하도록 하는 것이 어렵습니다.


2. 잘못된 텍스트 유형

또 다른 일반적인 문제는 잘못된 유형의 텍스트가 많이 발생하는 것입니다. 언리얼에서 현지화 가능한 모든 텍스트는 FText 유형이어야 하지만, 개발자는 종종 FString을 대신 사용합니다. 더 나쁜 것은 처음에는 FText를 사용하다가 나중에 FString을 사용하여 값을 변경하는 것인데, FText와 FString 간 변환이 매우 쉽기 때문에 쉽게 할 수 있습니다.

팀 전체가 처음부터 언리얼의 현지화 원칙을 숙지하고 현지화 프로세스를 감독할 사람을 지정하는 것이 좋습니다. 주기적으로 “텍스트 수집” 명령을 실행하고 필터가 대부분의 텍스트를 커버하는지 확인해야 합니다. 프로젝트의 규모가 커지면 로컬라이제이션이 필요한 텍스트를 찾기가 훨씬 더 어려워집니다.

나중에 AI가 텍스트를 다른 언어로 번역할 수 있도록 파이프라인을 자동화하여 QA 팀이 다른 언어로 게임을 테스트하는 동안 로컬라이즈되지 않은 텍스트를 발견할 수 있도록 하는 방법을 설명하겠습니다.


FText 대 FString 지옥

앞서 언급한 튜토리얼을 보셨다면, FString을 FText로 변환하거나 그 반대로 변환하는 것이 좋지 않다는 것을 알고 계실 것입니다. 하지만 변환이 너무 쉽기 때문에 다시 한 번 알려드리고 싶습니다!

FText를 FString으로 형변환하여 함수에 전달한 다음 함수 내부에서 다시 FText로 형변환하는 경우가 몇 가지 있었습니다. 원본 스트링에 액세스하거나 네트워크를 통해 다른 언어의 클라이언트로 전송하지 않는 한 텍스트는 일반 FText 로 보입니다.


텍스트 유형을 FString 에서 FText 로, 또는 그 반대로 변경하면 블루프린트 시스템에서도 자동으로 FString 에서 FText 로의 형변환이 이루어집니다. 따라서 이러한 변환을 계속 주시하고 발견 즉시 수정하세요.

화면에 디버그 텍스트를 출력하는 등 FString 을 FText 로 변환하는 것이 타당한 경우도 몇 가지 있지만, 일반적으로는 위험 신호입니다.

728x90


인간의 언어는 엉망입니다!

저희는 개발 후반부에 성별 커스터마이징을 도입하기로 결정했습니다. 게임플레이 관점에서 보면 여성 모델을 만들고 플레이어가 마법사의 성별을 선택할 수 있는 UI를 추가하면 되는 간단한 문제처럼 보였습니다. 다 된 거죠? 안타깝게도 아니죠!

페르시아어와 쿠르드어처럼 성 중립적인 언어도 있지만 프랑스어와 스페인어처럼 성 중립적이지 않은 언어도 있습니다. 성별 커스터마이징을 도입하면 런타임에 성별이 결정되기 때문에 캐릭터와 관련된 모든 문장을 다시 번역해야 했고, 텍스트도 성별에 따라 동적으로 제작해야 했습니다[1]. 

언리얼은 이미 {var}|gender(남성, 여성, 중성) 구문을 지원합니다. ETextGender를 FormatText 함수의 var 파라미터에 전달하면 완벽하게 작동합니다. 하지만 저희는 이 기능을 사용하지 않았습니다.

개발 언어가 대부분 성 중립적인 영어였기 때문입니다. 하지만 언리얼의 구조체를 사용하여 성별을 지원하려면 모든 텍스트에 성별에 대한 {var}를 정의해야 했습니다. 이렇게 하면 필요한 경우 다른 언어에서 사용할 수 있는 FormatText 함수에 ETextGender를 전달할 수 있었을 것입니다. 이 접근 방식은 잊어버리기 쉽고 개발 후반부에 구현하려면 상당한 노력이 필요합니다.

대신 원본 텍스트에 없는 사용자 정의 구문을 작성하고 구문을 파싱하여 캐릭터의 성별에 따라 올바른 문자열을 선택할 수 있는 프로세서를 구현했습니다. 덕분에 영어 텍스트를 깔끔하게 유지할 수 있었습니다. 이 구조체는 언리얼 구조체 [남성|여성]과 매우 유사합니다.

게다가 이 구조는 유연합니다. 저희는 필요하지 않았지만, [header: masculine|feminine|neuter]와 같은 헤더를 도입하여 화자와 대상의 성별을 다르게 지원할 수 있습니다.

해결해야 할 또 다른 문제는 복수형과 단수형입니다. 언리얼의 {번호} {번호}|복수(one=,few=,many=,other=) 구문을 사용하는 것이 좋습니다.

특정 언어의 경우 다른 문제가 발생할 수 있습니다. 예를 들어 터키어에서는 퍼센트 기호가 숫자 앞에옵니다(예: 5% 대신 %5). 또한 중국어와 같이 단어가 공백으로 구분되지 않는 언어에서는 텍스트 강조 표시가 작동하지 않을 수 있습니다. 이러한 문제는 발견하기 어렵기 때문에 시간을 할애하여 처리해야 합니다.


글꼴 (Fonts)

다양한 언어의 글꼴을 처리하는 것은 정말 골치 아픈 일이 될 수 있습니다.

게임의 모든 언어를 지원하는 단일 글꼴을 만들고 싶을 수도 있습니다. 하지만 이는 좋은 생각이 아닙니다. 예를 들어 중국어에 사용되는 글꼴이 영어 글꼴과 겹칠 수 있고, 이를 병합하면 불일치가 발생할 수 있기 때문입니다. 글꼴을 깔끔하게 분리하더라도 글꼴이 지원할 수 있는 글리프 수에는 제한이 있습니다.

또 다른 접근 방식은 언리얼 에셋 현지화를 사용하여 글꼴 에셋의 현지화된 버전을 만드는 것입니다. 안타깝게도 이 접근 방식에는 단점이 있습니다. 게임 언어를 변경하면 게임 내 텍스트가 즉시 변경되지만 언리얼은 게임을 다시 시작할 때만 현지화된 폰트 에셋을 로드합니다. 따라서 플레이어가 게임을 다시 시작하거나 원래 언어로 다시 전환할 때까지 물음표가 표시됩니다.

더 나은 해결책은 언리얼의 폰트 핸들러 기능을 사용하여 현재 로캘에 따라 특정 폰트를 선택할 수 있도록 하는 것입니다. 이 방법이 효과적이긴 하지만 이상적이지는 않습니다. 예를 들어, 설정 메뉴에서 각 언어의 이름을 현재 언어와 네이티브 스크립트(예: “페르시아어(فارسی)”)로 모두 표시하고 싶을 수 있습니다. 로캘을 기준으로 글꼴만 선택한 경우에는 모든 글꼴에서 페르시아어 문자를 지원해야 하거나 물음표가 표시됩니다.


가장 좋은 방법은 무엇인가요?

제가 찾은 가장 좋은 방법은 유니코드 범위를 사용하고 각 글꼴을 특정 범위에 할당하는 것입니다.

기본 글꼴은 모든 유럽 언어를 지원했지만 중국어와 일본어는 좀 더 까다로웠습니다. 한자의 유니코드 범위가 혼합되어 있고 중국어 간체, 중국어 번체, 일본어가 모두 같은 범위를 사용하기 때문에 각 언어에 별도의 글꼴을 사용하는 것은 불가능했습니다. 저희는 중국어와 일본어를 모두 지원한다고 약속한 다양한 글꼴을 사용해 보았지만, 테스트 결과 누락된 문자를 발견했습니다. 일부 글꼴은 괜찮았지만 중국 사용자는 읽을 수 없는 글꼴도 있었습니다. 결국 번역가들이 나서서 표준 중국어 글꼴을 제공하는 아래 링크를 제공했습니다(https://github.com/wordshub/free-font).

 

번역 파이프라인

번역팀과 함께 일하는 것은 어려운 관리 및 소프트웨어 개발 작업입니다.

프로그래머는 팀과 번역팀 간의 커뮤니케이션을 원활하게 하는 파이프라인을 만들어야 합니다. 각 팀의 구조가 다르기 때문에 구체적인 내용은 다루지 않겠지만 몇 가지 일반적인 조언을 드리도록 하겠습니다.

가장 먼저 번역팀에서 사용 중인 소프트웨어를 이해해야 합니다. 인코딩이 파이프라인 전체에서 일관성을 유지하는지 확인하세요. 그렇지 않으면 캐리지 리턴 대신 숫자가 표시되거나 이전에 번역된 텍스트가 손상되는 등의 문제가 발생할 수 있습니다. 좋은 경험 법칙은 변환을 직접 처리하는 것입니다. 예를 들어 Excel을 사용하는 경우 CSV 대신 Excel 파일을 제공하세요(특히 Microsoft Excel은 CSV를 가져올 때 인코딩을 요청하지 않으므로!). 워크플로에 따라 일부 변환기를 작성하거나 직접 형식을 만들어야 할 수도 있습니다(예: 버전 관리 또는 태그 지정용).

이상적인 워크플로우는 번역 팀에 단일 파일을 제공하고 번역 후 동일한 파일을 검색하는 것입니다. 하지만 번역 마감일은 대개 출시일 이전이기 때문에 일부 콘텐츠가 준비되지 않을 수 있습니다. 이러한 경우 문자열 테이블을 사용하여 텍스트를 작성하고 콘텐츠가 준비되면 현지화된 텍스트에 대한 문자열 테이블을 참조할 수 있습니다. 그러나 번역이 진행됨에 따라 팀에서 일부 텍스트가 누락되었음을 깨닫고 추가 파일을 제공해야 할 수도 있습니다. 여러 파일을 관리하는 방법은 파이프라인에 따라 다르지만 이에 대비하세요.

강력한 파이프라인을 구축하려면 시간이 많이 걸리고 여러 번 수정해야 할 수도 있지만 프로세스 속도를 크게 높일 수 있습니다.

언리얼의 현지화 대시보드에서 제공되는 명령을 사용하여 시작할 수 있습니다. 이러한 명령은 엔진을 열지 않고도 Python 스크립트에서 쉽게 호출할 수 있습니다. 문서 마지막에 간단한 예제를 첨부했습니다.

이러한 빌딩 블록을 사용하면 모든 종류의 흥미로운 작업을 할 수 있습니다. 예를 들어 매일 밤 텍스트를 내보내고 변환한 다음 번역 팀에 자동으로 업로드할 수 있습니다. 로컬라이제이션 마감일이 지나면 병합 파이프라인을 조정하여 단어 수를 확인할 수 있습니다. 새 텍스트가 추가된 경우 병합이 진행되지 않도록 할 수 있습니다.

또 다른 유용한 방법은 모든 텍스트를 수집하고 AI 번역 서비스를 사용하여 번역한 다음, 번역 팀에 보내기 전에 내부 QA 팀이 게임을 테스트하고 현지화되지 않은 텍스트를 식별하도록 하는 것입니다.

마지막으로, 텍스트 컴파일은 게임을 빌드할 때 트리거되지 않으므로 수동으로 트리거하거나 더 나은 방법은 빌드 파이프라인에서 CompileText를 자동으로 호출하도록 구성해야 한다는 점에 유의하세요.


플랫폼 고려 사항

PlayStation 및 Xbox와 같은 플랫폼에 게임을 퍼블리싱할 계획이라면 하드웨어, 소프트웨어 및 개념이 플랫폼마다 다르게 언급된다는 점에 유의하세요. 플랫폼 소유자는 지원하는 모든 언어에서 표준을 따르기를 기대하며, 그렇지 않을 경우 게임이 거부될 수 있습니다. 예를 들어 모든 플랫폼에서 단순히 “컨트롤러”라는 단어를 사용할 수는 없습니다. “컨트롤러"라는 용어는 플랫폼마다 다르게 불리기 때문에 게임에서는 플랫폼별 용어에 따라 이를 지칭해야 합니다.

현재 플랫폼을 매개변수로 사용하여 플랫폼에 따라 적절한 용어를 선택하는 구조를 만들거나 각 플랫폼마다 다른 텍스트를 사용할 수 있습니다.

이러한 용어를 각 플랫폼별로 다른 언어로 번역할 수 있는 예상 번역과 함께 표를 만들어 로컬라이제이션 프로세스 초기에 제공하는 것이 좋습니다. 나중에 모든 텍스트를 검토하는 것은 시간이 많이 걸리고 오류가 발생하기 쉽습니다.

 


결론

로컬라이제이션은 어렵고 시간이 많이 소요될 수 있으므로 이에 대한 준비가 필요합니다. 로컬라이제이션은 최신 게임 개발에서 필수적인 부분입니다. 플레이어는 자신의 모국어로 게임을 즐기기를 기대하며, 출시 시 이를 제공하지 못하면 부정적인 리뷰와 기회를 놓칠 수 있습니다. 이 글이 도전 과제와 해결 방안에 대한 귀중한 인사이트를 제공하고, 로컬라이제이션에 대한 명확한 이해를 바탕으로 접근하는 데 도움이 되었기를 바랍니다.

로컬라이제이션 작업에 행운을 빌며 큰 성공을 기원합니다!


* 원문:

 

Featured Blog | A developer's guide to effective localization in Unreal Engine

This article shares insights based on the development of Wizard of Legend 2, detailing the complexities encountered in Unreal Engine localization.

www.gamedeveloper.com

 

댓글