번역했더니 게임이 안 켜지나요? 그 줄을 찾으세요

창이 열립니다. 창이 닫힙니다. 어제까지 멀쩡하던 게임을 하룻밤 번역했더니, 이제 죽어 있습니다.

그 줄들 어딘가에 애초에 텍스트가 아니었던 한 줄이 있습니다. 씬 이름, 파일 경로, 게임이 비교하는 플래그 같은 것이죠. 엔진은 거기에 부딪혔고, 아무것도 그리기 전에 포기했습니다.

그걸 찾자고 오천 줄을 읽지는 않을 겁니다. 예/아니오 질문 하나를 열세 번쯤 던지면 됩니다.

짧은 답. 먼저 원인이 정말 번역인지 확인하고, 그다음 절반으로 자르세요. 의심되는 줄의 절반을 번역하고, 내보내고, 실행합니다. 실패하는 쪽 절반에 그 줄이 있습니다. 그 절반을 대상으로 한 줄이 남을 때까지 반복하세요.

찾기 전에: 정말 번역 때문인가요?

1. 원본 게임을 실행하세요. 내보낸 것이 아니라 손대지 않은 사본으로요. 그것도 실패한다면 문제는 컴퓨터나 폴더, 또는 게임 자체입니다.
2. 짧고 무해한 한 줄만 번역해 내보내고 실행하세요. 화면에서 보이는 메뉴 단어 하나면 충분합니다.
3. 그다음에야 줄을 찾기 시작하세요.

2단계가 아무것도 번역하지 않기가 아니라 한 줄이라고 말하는 데는 이유가 있습니다. 쓸 내용이 없으면 일찍 빠져나가는 어댑터가 여럿 있어서, 빈 내보내기는 실제 기록 과정이 아니라 파일 복사만 시험하게 되고, 진짜 과정이 망가져 있어도 통과할 수 있습니다.

한 줄짜리 빌드도 실패한다면 특정 줄의 잘못이 아니고, 절반씩 잘라도 아무것도 찾지 못합니다. 완전히 새 빈 폴더로 다시 내보내고, 원본이 아니라 내보낸 사본을 실행하고 있는지 확인하고, 내보내기 경고를 읽어 보세요. 그래도 실패하면 전달 과정의 문제로 신고해 주세요.

이 사전 점검에는 실행 두 번과 내보내기 한 번이 듭니다. 작은 RPG 만들기 프로젝트라면 몇 분, 큰 유니티 게임이라면 더 걸립니다. 대신 있지도 않은 줄을 찾느라 하룻밤을 날리지 않게 해 줍니다.

비슷해 보이지만 다른 두 가지. 게임은 돌아가는데 글자가 네모, 물음표, 깨진 로마자로 나오는 것은 글꼴이나 인코딩 문제입니다. 플러그인이나 오버레이를 설치한 직후의 강제 종료는 당신의 줄이 아니라 그 도구의 문제입니다.

절반씩 잘라서 그 줄 찾기

대부분의 프로젝트는 파일이 많고, 둘로 자르기 가장 쉬운 것이 파일 목록입니다.

1. 도구 모음에서 모든 번역 초기화.
2. 번역할 파일 선택을 엽니다. 설명이 그대로 적혀 있습니다. 「번역할 파일을 선택하세요. 체크하지 않은 파일은 그대로 둡니다.」 파일의 절반을 체크 해제하고 나머지를 번역합니다.
3. 새 빈 폴더로 내보내고 게임을 실행합니다.
4. 실행되면 찾는 줄은 손대지 않은 절반에 있고, 실행되지 않으면 방금 번역한 절반에 있습니다. 어느 쪽이든 목록은 절반으로 줄고, 나머지 절반은 잊어도 됩니다.
5. 다시 모든 번역 초기화한 뒤 남은 목록을 절반으로 자르고, 내보내고, 실행합니다.
6. 파일이 하나 남을 때까지 반복하고, 그 파일 안에서 한 줄이 남을 때까지 다시 절반씩 자릅니다.

파일 단위로 자르는 것은 줄 단위보다 거칠어서, 횟수는 파일 수를 따라갑니다. 파일이 마흔 개라면 파일을 찾기까지 약 여섯 번, 그다음 그 안에서 다시 시작합니다.

파일이 하나뿐인 프로젝트—NScripter 스크립트, 시나리오가 하나뿐인 Kirikiri나 Wolf 게임—에는 자를 파일 목록이 없습니다. 대신 줄 위로 상자를 끌어 보세요. 체크박스와 일괄 작업 막대가 저절로 나타나고, 나머지는 선택 항목 다시 번역이 처리합니다. 더 넓게 훑으려면 먼저 필터와 검색으로 줄을 좁힌 뒤 보이는 항목 모두 선택을 쓰세요. 이건 조심해야 합니다. 필터가 보여 주는 것을 그대로 가져가기 때문에, 지우는 걸 잊은 필터 하나가 이후의 모든 회차를 조용히 오염시킵니다. 어떤 필터를 썼는지 적어 두세요.

백 줄짜리 망가진 묶음을 끝까지 진행한 예:

• 1회차 — 용의선상 100줄, 앞의 50줄 번역: 실행됨. 즉 나머지 50줄 안에 있음.
• 2회차 — 용의선상 50줄, 앞의 25줄 번역: 실패. 즉 이 25줄 안에 있음.
• 3회차 — 용의선상 25줄, 앞의 13줄 번역: 실행됨. 즉 나머지 12줄 안에 있음.
• 4회차 — 용의선상 12줄, 앞의 6줄 번역: 실패. 즉 이 6줄 안에 있음.
• 5회차 — 용의선상 6줄, 앞의 3줄 번역: 실패. 즉 이 3줄 안에 있음.
• 6회차 — 용의선상 3줄, 앞의 2줄 번역: 실행됨. 한 줄이 남음.

백 줄에서 시작하면 최악의 경우 내보내기 일곱 번, 오천 줄에서 시작하면 최악의 경우 열세 번쯤입니다.

한 회차에 드는 시간

내보내기 한 번, 실행 한 번, 그리고 게임이 첫 대사에 도달할 때까지 걸리는 시간. 작은 RPG 만들기 프로젝트라면 2~3분. 내보내기가 게임 전체를 복사하고 타이틀 화면도 느긋한 큰 유니티 게임이라면 10분에 가깝습니다.

그러니 열세 회차면 거의 하룻저녁입니다. 그래도 이쪽이 싼 선택입니다. 다른 길은 오천 줄을 직접 읽고 제대로 맞히는 것이니까요.

손으로 할 때 두 가지가 어긋납니다. 매 회차마다 새 빈 폴더로 내보내세요. 패치를 겹쳐서 올리는 엔진이 있어서, 3회차가 1·2회차 위에 얹히면 셋을 한꺼번에 시험하는 셈이 됩니다. 초기화는 진짜 초기화여야 합니다. 손으로 되돌리지 말고 모든 번역 초기화를 쓰세요. 이 기능은 프로젝트를 만들 때 담아 둔 원문을 되살리므로, 이후에 원본 폴더를 덮어썼더라도 제대로 돌아갑니다.

그 줄을 되돌렸는데도 여전히 안 켜진다면

망가뜨린 줄이 하나가 아니었던 겁니다. 구문 분석에 민감한 엔진에서 처음 「전부 번역」을 돌렸을 때 흔히 나오는 결과입니다. 찾은 줄은 원문 그대로 두고, 아직 번역된 상태로 남은 범위를 대상으로 같은 절차를 다시 돌리세요. 두 번째 범인은 대개 첫 번째와 같은 종류의 문자열이고, 같은 파일 안에 있습니다.

다음부터는 나눠서 번역하기

나눠 한다고 내보내기 횟수가 줄지는 않습니다. 어차피 할 내보내기이고, 다만 실패가 처음부터 좁은 범위로 도착한다는 점이 다릅니다. 마지막 묶음에서 망가졌으니 좁히기는 오천 줄이 아니라 백 줄에서 시작합니다. 100줄로 시작하고, 여러 묶음이 깨끗하게 통과하면 500줄이나 파일 하나 전체로 넓히세요.

잘못된 줄을 번역하면 어떤 엔진이 망가지나요?

엄격한 엔진, 너그러운 엔진이라는 말을 합니다. 실제로 결정하는 것은 번역문이 어디에 놓이느냐입니다.

어떤 엔진은 그것을 데이터로 읽습니다. Ren'Py는 별도 파일과 런타임 후크, RPG 만들기는 이스케이프된 JSON, Unreal은 키 해시를 그대로 보존한 .locres 값입니다. 게임의 구조가 당신의 텍스트를 볼 일이 없으니, 잘못된 줄의 대가는 잘못된 줄 하나입니다. 다른 쪽은 그것을 게임이 해석하는 파일 안에 끼워 넣습니다. 스크립트나 마크업, 바이트 열로 읽히는 파일이고, 당신의 문장이 그 파일 구조의 일부가 됩니다. 그러면 콜론 하나, 대괄호 하나, 남는 1바이트, 또는 조회 키를 겸하던 문자열 하나로 게임이 멈춥니다.

규칙은 그게 전부입니다. 자기 엔진을 찾아 그 줄만 읽고 넘어가세요.

• RPG 만들기 MV/MZ — 구조적 위험은 없습니다. JSON과 CSV 모두 이스케이프되고, 제시되는 것도 정해진 이벤트 명령 묶음뿐입니다. 유일한 실제 위험은 화자 이름을 정확히 일치로 비교하는 플러그인인데, 내보내기가 그 플러그인의 설정 키까지 함께 고쳐 씁니다.
• Ren'Py — 거의 없습니다. 원본 코드를 절대 고쳐 쓰지 않으므로, 논리 키를 겸한 문자열도 안전합니다.
• Unreal Engine — 줄 단위 실패 사례를 본 적이 없습니다. .locres 문자열은 구조상 표시용 텍스트입니다. 여기서의 위험은 빌드가 죽는 것이 아니라 텍스트가 빠지는 것입니다.
• Unity — 심각하고 조용합니다. 씬 이름, 변수 키, 콜백이 대사와 똑같은 방식으로 저장됩니다. 무한 로딩, 반응 없는 버튼, 검은 화면을 각오하세요.
• Godot — 심각합니다. 노드 경로, StringName, res:// 참조는 엔진이 찾아가는 주소 그 자체이며, 되쓰기 단계에서 거부됩니다.
• Wolf RPG — 여기서 가장 취약한 형식입니다. 1바이트만 어긋나도 전체 흐름이 어긋나고, 창이 생기기도 전에 프로세스가 중단됩니다.
• Kirikiri / KAG — 심각합니다. 대괄호가 문법이고 저장소 이름이 파일 이름입니다. 태그 이름을 번역하거나, 괄호가 변환되거나, 그림 파일 이름을 번역하면 각각 그 자리에서 게임이 멈춥니다.
• Electron VN — 심각합니다. app.asar 안의 살아 있는 자바스크립트에 템플릿 자리표시자가 쓰이면 그것은 번역이 나쁜 게 아니라 문법 오류입니다.
• TyranoBuilder / TyranoScript — Kirikiri와 같은 계열입니다. KAG 태그는 마크업이므로 태그를 번역하는 건 문법을 건드리는 일입니다. 줄 안의 캐릭터 참조는 절대 고쳐 쓰지 않습니다.
• NScripter — 심각하고 독특합니다. ?, %, $는 변수 기호라서 하나만 잘못 들어가도 문법 오류입니다.
• YU-RIS — 심각합니다. 이 형식이 문자열이라고 부르는 것의 상당수가 실은 피연산자이기 때문입니다. 둘을 갈라낸 결과 어떤 게임은 유효 행이 40,678에서 8,914로 줄었고, 대사는 하나도 잃지 않았습니다.

다른 엔진들도 엔진에 각자의 페이지와 안내가 있습니다.

게임을 죽인 세 줄

RuneTranslate의 제외 규칙은 하나하나가 더는 실행되지 않게 된 게임과 맞바꾼 것입니다. 이 셋은 이미 고쳐졌습니다. 세 경우 모두 문제의 줄은 지극히 멀쩡해 보였고, 내보내기는 초록불로 끝났습니다.

Godot: 게임이 없는 인물을 만들어 냅니다. 어떤 줄에는 Warning: the door is locked라고 적혀 있었습니다. 완벽한 영어입니다. Dialogic은 저장된 텍스트의 모든 콜론을 이스케이프합니다. 이스케이프되지 않은 콜론이 바로 화자 이름을 떼어 내는 방식이기 때문입니다. 그대로 되쓰여진 이 문장은 Warning이라는 인물이 the door is locked라고 말하는 것으로 다시 해석되었고, 애드온은 그 인물을 실제로 만들어 냈습니다.

Kirikiri: 게임이 `End`라는 이름의 파일을 찾습니다. 어떤 버튼의 태그에는 그림 파일 이름과 이동 대상 라벨이 함께 들어 있었는데, 마스킹이 자체 괄호를 품은 태그를 넘어가지 못해 둘 다 노출되어 번역되었습니다. 지금의 스캐너는 괄호를 이해합니다. 짝이 맞는 괄호에서 닫히므로 중첩된 식은 태그 안에 남고, 평범한 태그는 첫 번째 ]에서 끝납니다.

RPG 만들기: 입화가 소리 없이 사라집니다. 어떤 입화 플러그인은 화자 이름을 자기 설정에 있는 표와 글자 하나하나 대조해 캐릭터 그림을 고릅니다. 이름을 번역한 것도 옳고, 자원 키로 가득한 그 설정에 손대지 않은 것도 옳습니다. 둘이 겹치자 등식이 깨졌고, 그 캐릭터의 입화는 로그에 아무것도 남기지 않은 채 사라졌습니다.

세 번의 내보내기 모두 성공이라고 보고했습니다. 깨끗한 내보내기는 어떤 엔진에서도 게임이 돌아간다는 증거가 아닙니다. 유일한 증거는 실행해 보는 것입니다.

당신의 줄이 원인이 아닐 때

절반씩 잘라도 이런 경우는 찾지 못합니다. 어느 쪽 절반도 실행되지 않으니까요. 문제는 내보낸 결과물이 어디에 놓였느냐입니다. Wolf RPG 게임은 옆에 놓인 낱개 파일보다 .wolf 아카이브를 먼저 읽어서, 번역된 데이터가 디스크에서 읽히지 않은 채로 타이틀 화면이 뜬 사례가 있습니다. Unity의 Addressables는 바이트가 체크섬과 더 이상 맞지 않는 번들을 거부하고, 어떤 로그에도 흔적을 남기지 않은 채 검은 화면을 돌려줍니다. 패키징된 RPG 만들기 게임은 실행 파일 옆에 둔 데이터 파일을 무시합니다. 셋 다 지금은 처리되어 있으며, 그래서 전달 단계의 실패는 추적하기보다 신고할 가치가 있습니다.

어떤 줄이 대사인지 알려 주는 표시가 있나요?

없습니다. 있다고 말하는 사람은 의심하세요.

예전에 한 사용자가, 대사 문자열을 모두 ||로 감싸 둔 Godot 게임을 찾아 그것만 번역했더니 게임이 잘 돌아갔다고 알려 준 적이 있습니다. 그 게임에서는 정말 유용했습니다. 하지만 그건 개발자 한 사람의 습관이지 Godot의 관례가 아니고, 다음 게임은 다른 방식을 씁니다.

반례는 YU-RIS에서 나옵니다. 어떤 게임에서는 백틱 쪽에 인터페이스 문자열 표 전체가 들어 있었고, 692줄 가운데 687줄이 표시 텍스트였습니다—그런데도 그곳에서 백틱은 아무 의미가 없습니다. 세 가지 따옴표는 모두 같은 것으로 컴파일되므로, 구분 기호에 기댄 규칙은 진짜 문장까지 표시해 버립니다. 값이 어디에 있었는지는 모든 것을 알려 주었고, 어떤 따옴표로 감쌌는지는 아무것도 알려 주지 않았습니다.

대신 위치와 형태에 기대고, 그 둘은 게임이 직접 가르쳐 주게 하세요. 게임을 실행하고, 화면에 나온 첫 대사를 읽고, 편집기에서 바로 그 줄을 찾으세요. 그 파일, 그 그룹, 그 앞뒤 줄이 이 게임에서 대사가 놓이는 모습입니다. 다른 곳에 있는 것은 대사가 아닐 후보입니다.

앱이 표시해 주는 것과 알 수 없는 것

RuneTranslate는 코드, 자원 경로, 식별자라고 판단한 줄을 제외됨으로 표시합니다. 숨기지 않고 그대로 보여 주되 제외 항목 표시 스위치 뒤에서 주황색으로 칠해 두므로, 무엇이 어떻게 판단됐는지 확인할 수 있고 그래도 번역 으로 어떤 줄이든 밀어붙일 수 있습니다. 직접 패턴을 추가할 수도 있습니다.

제외된 줄을 선택하고 실행을 시작하면 이렇게 물으며 멈춥니다. 「선택한 340줄 중 12줄이 제외되어 있습니다—필터가 표시했거나, RuneTranslate가 코드·자원 경로·ID로 판단한 것입니다. 이들을 번역하면 게임이 망가질 수 있습니다. 건너뛰면 제외 상태로 남습니다. 번역하면 이후 실행에서도 포함됩니다.」

밀고 나가도 괜찮습니다. 다만 그렇게 했다는 것만 기억하세요. 내보낸 결과가 실행되지 않기 시작했을 때 가장 먼저 살펴볼 곳이니까요.

솔직한 한계도 있습니다. 제외는 문자열에 대한 추측이라, 당신 게임의 어떤 문장이 그 게임에 딸린 어느 플러그인에서 조회 키를 겸하고 있다는 사실까지는 알 수 없습니다. 원문 언어가 이미 영어인 게임은 보호가 더 얇습니다. 가장 강력한 필터들이 「이 문자열에 원문 언어의 글자가 들어 있는가」를 묻기 때문입니다.

자주 묻는 질문

번역한 뒤에 게임이 안 켜지는 이유가 뭔가요?

거의 언제나, 번역한 줄 하나가 식별자, 경로, 씬 이름, 또는 게임이 정확히 일치로 비교하는 플래그였기 때문입니다. 그걸 바꾸면 구문 분석이나 조회가 깨집니다.

어떤 번역 줄이 게임을 망가뜨렸는지 어떻게 찾나요?

절반으로 자르세요. 모든 번역을 초기화하고, 절반을 번역하고, 빈 폴더로 내보내 실행합니다. 실패하는 절반에 그 줄이 있으니 다시 절반으로 잘라 반복하세요. 백 줄이면 여섯에서 일곱 번, 오천 줄이면 열세 번쯤입니다.

번역한 게임이 곧바로 닫힙니다. 무슨 뜻인가요?

시작 과정에서 치명적 오류가 난 것입니다. Kirikiri, Electron 비주얼 노벨, NScripter에서는 대개 문법 오류입니다. 괄호나 따옴표, 자리표시자가 번역되었거나 사라진 경우죠. Wolf RPG와 YU-RIS에서는 데이터 흐름이 어긋난 것입니다.

번역한 게임이 검은 화면으로 시작하는 이유는요?

대개 예외를 삼켜 버린 코드 안에서 로딩이 실패한 경우입니다. 유니티라면 체크섬이 카탈로그 항목과 더 이상 맞지 않는 번들입니다. 무해한 한 줄만 번역한 빌드를 시험해 보세요. 그것도 검다면 원인은 어떤 줄이 아니라 전달 과정입니다.

번역한 게임이 로딩 화면에서 멈춰 있습니다. 번역 탓인가요?

유니티라면 그럴 가능성이 큽니다. 무한 로딩은 씬 이름이나 변수 키를 번역했을 때 나오는 전형적인 증상입니다. 게임은 더 이상 맞지 않는 이름을 기다리고, 오류는 하나도 나지 않습니다.

절대 번역하면 안 되는 줄은 어떤 것인가요?

게임이 문자열 완전 일치로 찾아가는 모든 것입니다. 경로, 씬 이름과 노드 이름, 변수 이름과 이벤트 이름, 언어 코드, snake_case나 res:// 모양을 한 것들. 플레이어가 화면에서 그것을 읽는 장면이 그려지지 않는다면 그대로 두세요.

게임은 돌아가는데 글자가 네모나 물음표입니다. 같은 문제인가요?

아닙니다. 고른 네모는 글꼴에 그 문자의 모양이 없다는 뜻이고, 진짜 물음표는 파일을 쓸 때 그 문자가 사라졌다는 뜻입니다. 둘 다 글꼴이나 인코딩 문제이고 해결 방법이 다릅니다.

다음에 볼 것

고치는 게 아니라 이제 번역을 시작하려는 참인가요? 번역 패치 만드는 법이 전체 과정을 다룹니다.

그 줄을 찾았다면, 그 줄은 원문 그대로 두고 주변을 모두 번역한 뒤 새 빈 폴더로 내보내고 실행하세요. 식별자 하나가 번역되지 않아도 플레이어가 잃는 것은 없습니다.