한글패치 만드는 법 — 처음부터 끝까지

한글패치는 게임의 복사본이 아닙니다. 번역가의 작업물 — 번역한 줄들에, 어느 줄이 어디에 붙는지 말해 줄 만큼의 정보를 더한 것 — 을 다른 사람이 자기 게임 사본에 적용할 수 있는 형태로 만든 것입니다. 시장마다 부르는 이름이 다릅니다. 한국에서는 한글패치, 러시아에서는 русификатор, 중국에서는 汉化죠. 결과물은 어디서나 같고, 그것을 만드는 일도 같습니다.

패치에는 두 종류가 있고, 그 갈림길이 모든 것을 정한다

텍스트를 건드리기 전에, 여러분이 만드는 것이 둘 중 무엇인지 정하세요. 이후의 거의 모든 결정이 여기서 따라 나옵니다.

런타임 오버레이는 게임이 돌아가는 동안 번역합니다. 무언가가 게임과 나란히 로드되어 — 엔진 안의 플러그인, 게임 메모리를 읽는 텍스트 후크, 픽셀을 읽는 화면 캡처 — 각 줄이 그려지기 직전에 잡아채 번역으로 바꿔치기합니다. 디스크의 게임은 아무것도 달라지지 않습니다. Unity에서는 XUnity.AutoTranslator가 잘 알려진 예이고, RPG Maker에서는 MTool이 이 방식으로 작동합니다.

패치된 빌드는 번역을 게임 자체의 파일에 넣습니다. 엔진이 실제로 불러오는 데이터에서 텍스트를 읽어 내고, 번역하고, 다시 써 넣으면, 옆에서 아무것도 돌지 않아도 혼자 실행되고 플레이되는 게임 폴더가 남습니다. RuneTranslate가 만들어 내는 것이 이것이고, Translator++도 자기가 해석하는 엔진에서는 이것을 만듭니다.

솔직한 맞바꿈을 그대로 적자면:

• 오버레이는 게임별 작업이 필요 없습니다 — 엔진에 후크가 걸리거나 걸리지 않거나 둘 중 하나죠 — 대신 아무것도 남지 않습니다. 모든 줄이 플레이할 때마다, PC마다 다시 번역되고, 플레이어마다 오버레이를 직접 설치하고 설정해야 합니다.
• 오버레이는 텍스트가 그려지는 순간에만 닿습니다. 아트워크에 구워진 텍스트, 후크가 걸린 컴포넌트를 거치지 않는 텍스트, 자체 렌더러가 그리는 텍스트는 번역되지 않은 채 남습니다.
• 패치된 빌드는 내보내기 단계와 테스트 한 바퀴를 요구하고, 게임이 업데이트되면 다시 해야 합니다. 대신 돌려받는 것은 영구적입니다. 파일이 번역을 담고 있으니 게임은 그냥 번역된 상태이고, 오프라인에서도, 여러분의 작업을 적용한 누구에게나 그렇습니다.
• 패치된 빌드는 편집 가능한 기록을 남깁니다. 여섯 달 뒤에 나쁜 줄 하나를 나머지를 다시 번역하지 않고 고칠 수 있습니다 — 오버레이에는 고칠 것이 없고, 비울 캐시만 있습니다.

해석할 수 없는 엔진에서 혼자 쓰려고 한 번 번역하는 것이라면 오버레이도 합리적인 답이고 부끄러울 것이 없습니다. 작업을 다른 사람에게 건넬 생각이라면 패치된 빌드를 원하게 됩니다 — 패치는 파일로 존재할 때만 공유할 수 있기 때문입니다.

시작하기 전에 필요한 것

• 여러분이 소유한 게임 사본. 설치되어 있고 플레이할 수 있어야 합니다. 먼저 몇 분이라도 해 보세요 — 맥락을 본 적이 없으면 번역이 제대로 읽히는지 판단할 수 없습니다.
• 어떤 엔진을 쓰는지에 대한 지식. 텍스트가 어떻게 나오고 어떻게 다시 들어가는지가 전부 여기서 정해집니다.
• 여러분이 실제로 읽는 대상 언어. 기계 번역은 초안까지만 줍니다. 패치를 주지는 않습니다.
• 게임 사본 하나를 더 둘 디스크 공간. 패치된 빌드는 별도 폴더이고, 원본은 절대 수정되지 않습니다.

엔진을 알아내는 일은 보통 게임 폴더를 들여다보는 것으로 끝납니다. JSON 파일이 든 www/data나 data 폴더면 RPG Maker MV나 MZ, <Game>_Data 폴더면 Unity, game/*.rpy나 .rpa 아카이브면 Ren'Py, .xp3 아카이브면 Kirikiri입니다. 해석 가능한 것들의 전체 목록과 각각을 알아보는 단서는 엔진 페이지에 있습니다 — RuneTranslate는 17개 엔진과 형식을 다루고, 폴더를 지정하면 감지는 자동입니다.

작업 흐름

엔진과 무관하게, 패치를 만드는 일은 같은 순서의 같은 다섯 단계입니다. 3단계를 건너뛰고 싶어집니다. 그러지 마세요.

1. 추출 — 게임 자체의 파일에서 번역 가능한 문자열을 전부 읽어 내 작업할 수 있는 목록으로 만듭니다.
2. 번역 — 그 목록을 기계 제공자에 돌려 완성된 초안을 받습니다.
3. 검수 — 기계가 어김없이 틀리는 줄들을 훑습니다. 이름, 경칭, 용어, 플레이스홀더가 들어간 모든 것.
4. 내보내기 — 번역을 게임 형식에 다시 써 넣고 플레이 가능한 빌드를 만듭니다.
5. 테스트 — 그 빌드를 실행해 실제로 플레이해 봅니다.

추출

추출은 엔진 지식이 밥값을 하는 자리입니다. 대사가 평범한 텍스트 파일에 있는 경우는 드뭅니다. RPG Maker는 이벤트 명령 코드에, Unity는 바이너리 에셋 파일 안의 TextAsset 페이로드와 MonoBehaviour 필드에, Kirikiri는 암호화된 아카이브 안의 스크립트에, Unreal은 .pak 안의 .locres 테이블에 담아 둡니다. 좋은 추출기는 무엇을 건네지 않아야 하는지도 압니다 — 씬 이름, 변수 키, 비교 피연산자, 에셋 경로는 전부 문자열처럼 생겼고 번역하면 전부 게임을 망가뜨립니다. 아트워크에 그려 넣은 텍스트는 별도의 도구가 필요한 별도의 문제입니다. 이미지 번역을 보세요.

번역

직접 손대기 전에 기계 초안 전체를 받아 두세요. 빈 칸을 노려보는 대신 이미 있는 텍스트를 고치게 되니까요. RuneTranslate는 제공자 9종을 함께 담습니다 — Google, 무료 DeepL, DeepL Classic / 차세대는 API 키가 전혀 필요 없고, DeepL API, OpenAI, Anthropic Claude, DeepSeek, 모든 OpenAI 호환 엔드포인트, Ollama나 LM Studio를 통한 로컬 모델이 나머지입니다. 무료 등급은 그 전부와 모든 엔진을 열어 주며, 제한하는 것은 처리량과 프로젝트를 한 번에 하나보다 많이 두는 것입니다. 어떤 제공자가 어떤 게임에 맞는지는 제공자 비교에서 다룹니다.

검수

패치를 적용할 값어치가 있게 만드는 단계입니다. 기계 출력은 유창하면서도 예측 가능한 자리에서 자신 있게 틀리므로, 처음부터 끝까지 읽는 대신 그 자리들을 의도적으로 훑으세요:

• 캐릭터 이름. 기계는 볼 때마다 다르게 옮기고, 때로는 이름을 단어로 번역해 버립니다. 표기를 한 번에 정하세요.
• 경칭과 말투. -상 / -짱을 살릴지 뺄지는 줄마다가 아니라 프로젝트 전체의 결정입니다. 어떤 인물이 존댓말을 쓰는지도 마찬가지입니다.
• 용어. 스킬, 아이템, 지명, 시스템 등 게임이 만들어 낸 모든 것. 메뉴와 툴팁과 전투 로그에서 스킬 하나가 세 가지로 적히면 고장 난 게임처럼 읽힙니다.
• 플레이스홀더와 제어 코드. \C[1], {player}, [name] 같은 것은 온전히 살아남아야 합니다. 번역된 플레이스홀더는 오타가 아니라 크래시나 빈칸입니다.
• 그대로 돌아온 줄들. 대개 의성어이고, 대개 제공자가 그 줄을 포기했다는 신호입니다.

용어 일관성

문장이 어색해서보다 일관성 때문에 버려지는 패치가 더 많습니다. 플레이어는 뻣뻣한 문장은 용서하지만, 한 대화 안에서 같은 인물이 유우키, 유키, 눈으로 불리는 것은 용서하지 않습니다. 누가 말하는지 따라갈 수 없게 되기 때문입니다. 해법은 용어집입니다. 원본 용어와 그것이 반드시 되어야 할 정확한 대상 용어의 목록을 번역 전에 적용해, 제공자가 즉흥적으로 지어낼 기회를 아예 주지 않는 것입니다. 첫 한 시간에 만나는 이름들로 일찍 만들고, 진행하면서 더하세요 — 용어집 가이드가 태그 마스킹과 어떻게 맞물리는지, 왜 마지막의 찾아 바꾸기 작업이 아니라 처음에 있어야 하는지를 다룹니다.

폰트

일본 게임은 일본어 폰트를 담고 있고, 일본어 폰트에는 한글, 키릴, 그리스 문자, 태국어, 그리고 폴란드어·터키어·베트남어의 악센트 글자가 없는 경우가 잦습니다. 그런 언어로 번역하면 게임이 빈 네모를 그립니다 — 번역은 올바른데 폰트가 그리지 못하는 것뿐입니다. 어떤 엔진은 알아서 처리됩니다. Ren'Py 내보내기는 감당할 수 있는 폰트를 함께 담고 게임의 폰트를 그것으로 다시 매핑합니다. 자동이 아닌 곳에서는 내보낸 빌드 안의 폰트 파일을 교체하면 대개 해결됩니다. 진짜 물음표는 완전히 다른 고장입니다 — 그건 빠진 글자가 아니라 엔진 자신의 문자열 인코딩이 그 글자를 거부하는 것이고 — 엉뚱한 해법을 찾아 나서기 전에 이 구분을 알아 두는 편이 좋습니다. 두 경우 모두 FAQ에서 다룹니다.

빌드 테스트하기

오류 없이 끝난 내보내기는 테스트된 패치가 아닙니다. 실행해서 조용히 깨지는 것들을 확인하세요:

• 게임이 타이틀 화면까지 가고 새 게임이 시작되는지. 여기서 실패하는 빌드는 보통 애초에 텍스트가 아니었던 줄 — 번역되어 버린 식별자 — 때문입니다.
• 메시지 상자가 텍스트를 담고 있는지. 번역문은 일본어보다 길어지니, 상자 밖으로 삐져나가거나 잘리는 줄이 없는지 보세요.
• 메뉴, 아이템 이름, 툴팁 — 긴 단어가 고정 폭 버튼을 넘치는 자리들.
• 원본 게임의 세이브 파일이 여전히 불러와지는지, 그리고 패치된 빌드에서 만든 새 세이브도 불러와지는지.
• 도입부만이 아니라 게임 깊숙한 장면 하나까지. 추출 누락은 오류가 아니라 번역되지 않은 구간으로 나타납니다.

작업물 공유하기

여기가 여러분의 패치를 남에게 건넬 수 있는지 없는지를 정하는 부분입니다. 여러분이 만든 것은 번역 — 줄들 — 입니다. 게임은 여러분의 것이 아니고, 번역된 사본을 묶어 배포하는 것은 남의 게임을 배포하는 일입니다. 정직한 형태의 패치는 작업물만 담고, 받는 사람이 각자 이미 소유한 사본에 적용하는 것입니다.

RuneTranslate는 정확히 그것을 .rtpatch 파일로 내보냅니다. 유닛 id와, 각 번역이 매칭되는 원문 줄과, 여러분의 번역이 담깁니다. 게임 파일도, 에셋도, 실행 파일도 없습니다 — 파일에는 여러분의 텍스트뿐이고, 그래서 메시지에 첨부할 만큼 작고 누구에게 건네도 안전합니다.

받는 사람 쪽은 세 단계입니다:

1. 같은 게임을 자기가 설치한 사본에서 프로젝트로 만듭니다. 그러면 같은 줄들이 그 사람 PC에서 추출됩니다.
2. 여러분의 .rtpatch를 가져오면 그 줄들이 여러분의 번역으로 채워집니다.
3. 자기 게임 파일에서 자기 몫의 플레이 가능한 빌드를 내보냅니다.

매칭은 유닛 id가 먼저이고, id가 어긋났을 때는 — 게임 업데이트나 추출기 변경 때문에 — 원문 줄 자체로 매칭하는 방식으로 물러납니다. 그 대비책이 게임이 패치된 뒤에도 한글패치를 계속 쓸 수 있게 해 줍니다. 가져오기는 무엇을 적용하기 전에 엔진과 대상 언어가 일치하는지 확인하므로, Unity 게임용으로 만든 패치가 실수로 Ren'Py 프로젝트에 들어갈 수 없습니다. 무료 등급에서는 패치 공유가 3일 단위로 내보내기 한 번, 가져오기 한 번으로 제한됩니다. 패치를 만드는 나머지 과정은 기능 제한이 없습니다.

같은 파일이 팀으로 함께 작업하는 방법이기도 하고 — 한 사람은 이야기를, 다른 사람은 메뉴를 번역하고 패치를 하나의 프로젝트로 합칩니다 — 게임이 업데이트되었을 때 자기 작업을 지키는 방법이기도 합니다. 새 버전에서 다시 추출하고, 예전 패치를 가져오면, 실제로 바뀐 줄만 손보면 됩니다.

게임 자체를 재배포해도 되는지는 권리자가 정할 일이지, 여러분이나 저희가 정할 일이 아닙니다. 패치를 공유하고, 어느 버전의 게임에 맞춰 만들었는지 알려 주고, 게임은 각자 가져오게 하세요.

엔진별 세부 사항

위의 내용은 일의 모양입니다. 엔진마다 다른 것은 텍스트가 어디에 사는지, 내보내기가 무엇을 만들어 내는지, 무엇이 손에 닿지 않는지이고 — 내보내기에 놀란 뒤가 아니라 시작하기 전에 읽어 둘 값어치가 있습니다: Unity, RPG Maker, Ren'Py, 나머지 열네 개는 전체 엔진 목록.

RuneTranslate는 Windows 10과 11에서, 그리고 Wine이나 Proton을 통해 Linux와 Steam Deck에서 실행됩니다. 첫 실행 때 무료 Patreon 로그인이 필요하고, 무료 등급은 모든 엔진과 모든 제공자를 엽니다. 사람들이 먼저 손을 뻗는 오버레이나 툴킷과 저울질하고 있다면, 비교가 각 접근이 실제로 무엇을 주는지 정리해 둡니다.