금색의 갓슈벨!! 한글패치 제작기 — 대사 엔진과 타이틀을 다시 읽다

저희가 작업한 게임은 게임보이 어드밴스용 일본판 金色のガッシュベル!! うなれ!友情の電撃입니다. 배포 정보에 적힌 개발사는 Banpresto입니다. 대사를 한국어로 바꾸려면 일본어 글자를 한글로 치환하는 것만으로 충분할 줄 알기 쉽습니다. 실제로는 대사 글꼴과 타이틀 이미지가 별도 경로였고, 짧아진 번역문의 남는 공간을 잘못 채웠을 때 게임 진행도 멈췄습니다. 이 글은 원본의 글자와 문장 위치를 확인하고, 실패한 설계를 고쳐 공개 패치에 이르기까지 남긴 작업 기록입니다.

1. 일본판 원본과 패치 범위

배포 대상 원본은 Konjiki no Gash Bell!! Unare! Yuujou no Zakeru (Japan)입니다. 게임 헤더에는 GASH-ZAKERU, 게임 코드에는 A4GJ가 기록돼 있습니다. 일본판 원본의 크기는 8,388,608바이트이고 배포 정보에 실린 CRC32는 64fab050입니다. CRC32는 파일 내용에서 계산하는 짧은 식별값으로, 이름이 같은 다른 판본에 패치를 잘못 적용하지 않도록 확인하는 데 씁니다. 작업 후 파일은 16,777,216바이트입니다. 용량 증가는 대사 글꼴과 글자 코드 표를 기존 자리 밖으로 옮긴 설계와 연결됩니다.

공개된 v1.9 패치의 안내 범위는 스토리 대사, 인게임 선택지, 시스템 메시지, 술법 이름과 승패 안내입니다. 배포 정보에는 1,736개 문자열 중 1,725개의 번역, 한글 619종이라는 집계가 남아 있습니다. 반면 메뉴 항목과 전투 중 고정 표시는 대사 엔진이 아닌 그래픽 글자라 같은 작업만으로는 바뀌지 않습니다. 타이틀 화면은 후속 그래픽 작업 기록과 공개 화면에서 한글 로고 및 한글 버튼 안내를 확인할 수 있습니다. 초기에 작성된 릴리스 문서에는 타이틀을 미포함으로 적었으나, 뒤에 작성된 타이틀 작업 기록과 실제 공개 화면이 보여 주는 상태는 다릅니다.

2. 대사 글자를 그리는 자리 찾기

처음 만든 글꼴은 8×8 픽셀 그림을 일반적인 타일 방식으로 옮기는 설계였습니다. 타일은 게임 화면의 작은 그림 조각입니다. 이 게임의 실제 대사 엔진은 글자 하나를 타일 하나로 복사하지 않았습니다. 글자 폭에 맞춰 그림 조각을 여러 위치에 합성한 다음 화면 메모리에 보냈습니다. 초기 글꼴은 픽셀의 4비트 묶음 순서도 거꾸로 쓰고, 글자색과 배경색까지 원본과 반대로 놓았습니다. 그 상태로는 글자를 다시 그려도 정상 대사창이 나오지 않았습니다.

대사창의 화면 메모리에 값이 쓰이는 순간을 따라가니, 원본 글리프는 12×12 픽셀 크기였습니다. 글리프는 글자 하나의 실제 그림입니다. 저장 공간은 글리프당 96바이트이고, 각 픽셀에 4비트를 할당하는 4bpp 형식에서 글자 잉크가 색상 번호 15를 사용했습니다. 대사 엔진이 두 바이트 글자 코드를 표에서 순서대로 찾고, 찾은 순번으로 글리프를 고른다는 점도 확인했습니다. 일본어 글자 ‘母’의 원본 그림을 풀어 화면에서 관찰한 픽셀과 맞춰 보니 정확히 일치했습니다. 주소 추정만으로 끝내지 않고 실제 그려진 글자로 경로를 검산한 셈입니다.

원본 코드 표에는 일본어 글리프 815개와 끝 표시가 있었습니다. 처음에는 이 공간을 한글로 덮는 방법을 검토했지만, 그러면 미번역 일본어가 남은 장면의 글자가 사라집니다. 원본 글리프를 보존하고 게임 파일을 확장해 새 표와 새 폰트를 놓았습니다. 코드에 적힌 표·폰트 주소 네 곳을 새 위치로 바꾼 뒤 Galmuri11 글꼴을 12×12, 4bpp 대사용 그림으로 만들었습니다. 원본 일본어와 새 한글이 한 화면에서 공존할 수 있도록 한 선택입니다. 초벌 작업에서 11픽셀 크기로 만든 글자 ‘서’가 ‘시’처럼 보인 문제는 렌더링 크기를 12로 바꾸고 흐림 처리를 끄면서 바로잡았습니다.

3. 문장과 스크립트를 구별하기

폰트를 찾아도 일본어 문장의 위치를 함부로 바꾸면 안 됐습니다. 이 게임에서는 화면에 보여 줄 문장 바로 뒤에 게임 진행 명령이 놓입니다. 초기에 일본어 인코딩에서 자주 쓰이는 바이트 범위를 기준으로 문장을 찾았는데, 우연히 같은 범위의 값으로 시작하는 명령까지 일본어로 잘못 읽었습니다. 특정 스크립트 구간을 번역 데이터로 덮자 스토리 진입 시 화면이 검게 멈췄습니다. 원본과 여러 중간 버전을 비교하고 변경 범위를 나누어 재현하니 문제 구간은 파일 위치 0x7E06B2–0x7E0752, 160바이트였습니다. 그 안의 INITMDL 명령 주변을 글자로 해석한 것이 원인이었습니다.

추출 기준을 바꿨습니다. 실제 대사 엔진이 인식하는 두 바이트 코드 표에 있는 글자만 이어 붙이고, 끝 표시로 경계를 확인했습니다. 그 결과 문장 1,736개와 문자 18,190자를 다시 추출했고, 앞서 잘못 짚은 명령 구간을 문장으로 가져오는 경우는 없었습니다. 포인터는 게임 코드가 텍스트 위치를 가리키는 주소값입니다. 이 게임에서는 여러 명령에 그 주소가 흩어져 있어 문장을 큰 빈 공간으로 옮기는 대신 원래 자리에서 정해진 바이트 수 안에 교체했습니다. 번역이 짧아도 종료 표시와 그 뒤에 이어지는 명령의 위치를 지켜야 했습니다.

번역 작업에서는 문장을 하나씩 떼어 번역했을 때 화자와 말투가 어긋나는 문제도 확인했습니다. 대화 장면을 묶고 화자를 구분해 초벌 번역한 다음, 길이 제한을 검사하고 이름 표기 문제는 사람의 검수 대상으로 남겼습니다. 작업 문서에는 이 단계에서 1,204줄을 변경하고 검증에 실패한 110줄은 이전 문장을 유지했다고 기록돼 있습니다. 길이 제한은 한국어 글자 수만 세는 문제가 아닙니다. 제어코드도 자리를 차지하며, 이름표처럼 원본이 6바이트인 칸에는 긴 이름을 그대로 넣을 수 없습니다. 그래서 표시할 이름과 실제 본문을 구분해 다뤘습니다.

4. 타이틀은 대사와 다른 그림이었다

타이틀의 일본어 로고는 대사 폰트로 그린 문장이 아니었습니다. 배경 그림 조각을 비디오 메모리로 보내 화면에 조립한 것이어서, 대사용 글리프 코드 표를 고쳐도 로고는 변하지 않습니다. 작업 기록에서는 메인 로고가 있는 배경과 글자 위의 검은 사선 무늬가 있는 배경을 따로 분석했습니다. 로고·번개·배경 타원이 연결된 그림이라 글자색만 골라 교체하는 방식도 맞지 않았습니다. 원래 화면의 사용 중인 타일 범위 안에 새 글자를 배치하고, 타원과 부제 배너는 기존 화면의 배치에 맞춰 다시 그렸습니다. 원본 느낌을 해치지 않기 위해 느낌표 ‘!!’는 그대로 두었습니다.

깜빡이는 ‘ボタンを押してください’ 안내도 처음에는 움직이는 스프라이트로 생각했지만, 조사 결과 다른 배경 레이어의 타일 30개를 켜고 끄는 화면이었습니다. 그 출처를 확인한 뒤 ‘버튼을 눌러 주세요’로 고쳤습니다. 시작할 때 회전하며 나타나는 로고는 정지 화면과 또 다른 그림 블록을 씁니다. 정지 화면만 고치면 회전하는 동안에는 일본어가 보이므로, 움직이는 장면의 메인 로고와 부제도 별도로 확인했습니다. 각 그림을 고칠 때 원본 게임 파일의 바이트가 실제 화면 메모리에 올라온 바이트와 같은지 대조한 뒤 기록해, 엉뚱한 그림을 건드리지 않도록 했습니다.

다만 같은 원리로 메뉴 전체가 번역되는 것은 아닙니다. 스토리·통신 등의 메뉴 라벨은 글자 코드가 아닌 그림 스프라이트이고, 전투 중 라이프·하트·HP 같은 글자도 이미지로 존재합니다. 공개 배포 정보는 이들 그래픽을 미포함 대상으로 적고 있습니다. 타이틀 한글화가 확인되었다는 사실과 메뉴·전투 표시가 남아 있다는 사실은 구분해야 합니다.

5. 화면이 깨지고 대사가 멈춘 이유

초기의 화면 깨짐은 폰트를 놓을 자리부터 잘못 잡은 탓이었습니다. 11,776바이트짜리 한글 폰트를 원본의 작은 구역에 그대로 덮었는데, 그 자리는 대사용 일본어 폰트가 아니라 타이틀 화면의 그림과 이어진 곳이었습니다. 그 결과 타이틀의 버튼 안내와 저작권 표시 부근에 글자 픽셀 대신 체커보드처럼 깨진 띠가 생겼습니다. 원본 그림 구역을 복구하고 글꼴을 확장된 파일 끝쪽으로 옮기니 타이틀이 다시 정상으로 나왔습니다. 화면에서 보기에는 단순한 그림 깨짐이지만, 수정해야 할 곳은 그림 색상이 아니라 잘못 가리킨 데이터 위치였습니다.

다른 오류는 대사가 멈추는 문제였습니다. 실제 시험에서 ‘내가 이제 학교 가서’ 다음 문장으로 넘어가지 않았고, 다음 장면은 이름표만 보인 채 본문이 비었습니다. Start를 누르면 전투 장면으로 잘못 이동하는 현상까지 나왔습니다. 원인은 번역이 짧을 때 남는 원본 문장 자리를 0바이트로 채운 데 있었습니다. 게임은 그 0바이트를 문장 끝으로 읽고, 원래 끝까지 남은 공간을 문장 뒤의 스크립트 명령처럼 읽었습니다. 수정 후에는 화면에 보이는 문장과 끝 제어코드 사이를 글자용 공백 코드로 채우되, 원래 문자열의 끝 위치와 그 뒤 명령은 그대로 두었습니다. 오프닝 장면에서 앞뒤 대사가 연속해서 진행되는지 다시 확인했습니다.

이 두 사고는 독립적이었습니다. 타이틀 그림만 복원한 시험판에서도 스토리 진입 문제가 남았고, 스크립트 구간만 옮긴 시험에서는 문제가 재현됐습니다. 그래서 화면에 드러난 증상 하나를 고친 뒤 전체가 해결됐다고 판단하지 않고, 원본과 중간 결과를 나눠 비교했습니다. 글자 그림, 문장 데이터, 게임 명령을 서로 다른 영역으로 취급해야 했던 이유입니다.

6. 검증한 범위와 남은 부분

원본 글리프의 복원 결과를 실제 화면 픽셀과 대조했고, 대사 변경 뒤에는 오프닝의 연속 문장과 이름표를 화면에서 확인했습니다. 타이틀은 그림 레이어를 합성한 결과를 화면 캡처와 비교하고, 회전하며 등장하는 구간도 다시 캡처했습니다. 버튼 안내는 일본어 원본 그림의 저장 위치를 확인한 뒤 한글판 화면을 재구성해 검토했습니다. 원본과 수정본을 별도로 살펴야 했던 이유는 글씨가 보인다는 것과 게임이 계속 진행된다는 것이 같은 검증이 아니기 때문입니다.

공개 정보의 번역 집계는 1,725/1,736개 문자열입니다. 따라서 ‘완전 한글화’라고 부르지 않습니다. 남아 있는 메뉴·전투 그래픽 글자 역시 문장 번역률에 포함해 해결됐다고 주장할 수 없습니다. VS 통신 대전 화면은 통신 상대가 없어 실전 화면까지 확인하지 못했습니다. 전투 대사 다수가 확인된 대사 경로를 쓴다는 기록은 있지만, 그것만으로 도달하지 못한 통신 장면을 검증한 것으로 바꿔 말할 수 없습니다.

7. 원본 확인과 패치 적용

현재 배포 정보에는 v1.9 패치가 BPS 형식이라고 기록돼 있습니다. BPS는 원본 파일과 수정된 파일의 차이를 담는 패치 파일 형식입니다. 일본판 원본의 SHA-256은 86902c2df04d780a8fdfa059c5a78af59de3700f663516b7d2ca57fd0ea73931이며, v1.9 BPS 패치의 SHA-256은 9f38df3fcee1e885fbb0fffac64909dc860492edce7a789483c0ef62f6f3f9ff입니다. SHA-256은 파일 내용을 긴 값으로 식별해 판본이나 다운로드 파일이 달라졌는지 확인할 때 씁니다. 먼저 본인이 정품에서 직접 만든 원본 파일의 판본·해시를 확인하고, 운영자의 한글패치 배포 사이트에서 받은 BPS 파일을 해당 원본에 적용해야 합니다. 다른 지역판이나 수정된 원본에는 맞는 결과를 보장할 수 없습니다.

이 글과 배포 페이지는 ROM, BIOS 또는 게임 데이터를 제공하지 않으며 이를 받을 곳도 안내하지 않습니다. 게임 개발사 Banpresto와 원작·게임의 각 저작권자에게 해당 권리가 있습니다. 적용 절차에서 무엇이 패치이고 무엇이 원본 파일인지 혼동되면 레트로 게임 한글패치 적용 가이드를, 원본 확보와 저작권 문제는 에뮬레이션 법률 가이드를 먼저 확인하세요.