크림슨 슈라우드 한글패치 제작기 — 글꼴부터 3DS 파일별 패치까지

《크림슨 슈라우드》는 마츠노 야스미가 각본을 쓴 3DS 테이블톡 RPG입니다. 게임 개발사 표기는 Level-5 / Nex Entertainment입니다. 이 글은 미국 eShop판을 대상으로 만든 한국어 패치의 제작 기록입니다. 완성된 문장만 보면 글을 바꿔 넣은 것처럼 보이지만, 실제 작업에서는 3DS 안의 여러 파일을 읽고 다시 만들 수 있어야 했고 글꼴과 화면 폭을 별도로 확인해야 했습니다. 원본 판본을 구별하는 값부터 글자가 화면에 나타날 때까지 거친 단계를 설명합니다.

1. 미국판 원본과 파일 구조

작업 대상은 3DS 《Crimson Shroud》 미국 eShop판입니다. 원본의 Title ID는 00040000000BBF00, 파일 크기는 256,760,128바이트, SHA-256은 e32a09252acad8c6e35eda359b9bc42d50a7bc85814356461af04b8ed9fbcae1입니다. SHA-256은 파일 전체에서 계산하는 지문이므로 이름이나 지역 표기가 같더라도 이 값이 다르면 같은 입력이라고 단정할 수 없습니다. 배포 패키지도 이 원본 값을 명시해 다른 판본을 실수로 바꾸지 않도록 했습니다.

게임의 3DS 컨테이너에서 RomFS(게임의 자료 파일 영역)를 풀어 보면 ap4/bcs.fa라는 묶음이 나옵니다. 그 안에는 2,296개의 항목이 있습니다. 화면 문장은 그 안의 메시지 컨테이너에, 글자 모양은 별도의 글꼴 데이터에 들어 있습니다. 메시지 컨테이너란 문장과 게임이 해석하는 제어 표식을 함께 담는 형식입니다. 게임의 한국어 화면을 만들려면 텍스트만 찾아 바꾸는 것으로는 부족합니다. 묶음 파일을 해제하고 다시 묶은 뒤 RomFS와 3DS 컨테이너까지 재조립해야 합니다.

저희는 내용을 바꾸기 전에 추출한 묶음과 RomFS를 그대로 재조립해 원본 바이트와 일치하는지 확인했습니다. 변경 전 데이터를 왕복시켜 동일한 결과가 나오지 않는다면, 이후에 생기는 오류가 번역 때문인지 포장 과정 때문인지 구별할 수 없습니다. 원본을 그대로 다시 빌드하는 단계에서는 3DS 입력 파일까지 비트 단위로 동일하게 재현했습니다. 작업 로그의 RomFS 원본 길이는 0xF337000바이트입니다. 이 과정은 게임 콘텐츠를 새로 작성한 일이 아니라, 바꾸지 않은 자료가 변형 없이 돌아오는지 확인한 절차입니다.

2. 글꼴을 넣을 자리와 글자 모양

원본 영어 문장이 담긴 곳을 찾아도 한국어 음절을 그릴 글자가 없으면 화면에는 제대로 나오지 않습니다. 글리프는 화면에 그리는 글자 한 칸의 그림이고, 글리프 슬롯은 그 그림을 글꼴 파일에서 찾아가는 자리입니다. 제작 과정에서는 기존 영문 글리프 셀을 그대로 복사하고, 한국어용 글리프를 뒤에 추가했습니다. 문장에 들어간 한국어와 기호를 위해 추가한 글리프는 2,423개이며, 본문·시스템·보조 글꼴 각각에 필요한 자리를 마련했습니다. 기존 영어까지 무작정 덮어쓰면 바꾸지 않은 화면도 깨질 수 있기 때문입니다.

글꼴 시트는 RGBA4444 형식으로 저장됩니다. 색의 빨강·초록·파랑·투명도를 각각 제한된 단계로 기록하는 방식이며, 이 게임에서는 투명도가 잉크의 진하기를, RGB가 글자색과 곱해지는 음영을 담당했습니다. 처음에는 잉크 진하기를 반전한 값을 RGB에 넣어 글자 몸통이 검고 가장자리가 밝아지는 결함이 생겼습니다. 실제 영문 글꼴을 다시 조사하니 본문 글꼴의 몸통은 흰색에 가깝고 흐린 테두리 부분만 어두웠습니다. 그 규칙을 따라 수정했습니다. 반면 시스템 글꼴은 전체가 흰색이었습니다. 같은 게임의 글꼴이라도 두 시트의 픽셀 처리 방식이 같지 않았던 것입니다.

한글 비트맵의 원본 서체로는 OFL-1.1 라이선스의 NeoDunggeunmo를 사용했습니다. 본문용은 16픽셀, 시스템용은 14픽셀의 픽셀 글자를 렌더링했습니다. 본문 셀의 크기는 18×19픽셀입니다. 이 작은 셀에서 안티앨리어싱을 적용한 고딕체는 회색으로 뭉개졌지만 픽셀형 글자는 형태를 유지했습니다. 아래 글꼴 비교 이미지는 글자 모양을 검토하기 위해 만든 화면이며 게임 속 스크린샷은 아닙니다.

3. 문장을 넣을 자리와 화면 용량

배포 대상으로 분류한 한국어 문자열은 3,262개입니다. 원문이 같으면 번역문도 같도록 대응표를 만들고, 용어집에는 636개 항목을 등록했습니다. 초벌 번역에는 기계번역을 사용했으며, 만들어진 문장은 원문 대조와 의미 검수를 거쳤습니다. 특히 영문판을 번역 대상으로 삼되 무기·방어구·아이템·마법·기술 이름은 일본어 원문의 이름을 따르도록 기준을 나누었습니다. 등장인물과 지명은 영문판을 따랐습니다. 한국어 표현이 화면 안에 들어가는지만 보는 것과 어느 판본의 명칭을 기준으로 삼는지는 다른 문제였기 때문입니다.

포인터 테이블은 문장이 저장된 위치를 가리키는 주소 목록입니다. 이 작업의 공개 기록은 포인터의 특정 오프셋보다 메시지 묶음과 화면 배치 검증을 자세히 남깁니다. 그래서 확인하지 못한 포인터 주소를 여기에 나열하지 않습니다. 실제 화면의 용량은 문자 수만으로 판단하지 않았습니다. 글꼴의 각 글자가 차지하는 가로 폭과 원문이 나누어 쓴 줄을 함께 비교했습니다. 원본 영어에서 손으로 줄을 나눈 항목 800개를 같은 규칙으로 다시 줄바꿈했을 때 원본 배치가 재현되는지 확인한 뒤, 화면 종류 16개 그룹별로 허용 폭을 계산했습니다.

제어 표식도 문장의 일부로 다뤄야 했습니다. 문장을 넘기는 표식, 버튼 입력을 기다리는 표식, 줄 높이를 지정하는 표식의 순서가 달라지면 글자가 남아 있어도 화면 동작이 바뀝니다. 원문에 있던 구조적 줄바꿈 540곳은 번역문으로 옮기고, 문장 중간의 장식적 줄바꿈만 다시 배치했습니다. 반대로 원문에 줄바꿈이 없는 도움말·아이템·기술·유닛 정보에는 새 줄을 강제로 넣지 않았습니다. 그 영역은 실제 기기에서 임의로 나눈 화면보다 원문의 한 줄을 유지한 화면이 더 읽기 좋았습니다.

4. 실기에서 드러난 줄바꿈 사고

컴퓨터에서 검사를 통과한 뒤 실제 기기 화면을 보면서 줄바꿈에 관한 잘못된 가정을 발견했습니다. 제어 표식 <br>을 일반적인 줄바꿈으로 해석했지만, 이 게임에서는 다음 메시지로 넘기는 기능이었습니다. 실제 줄바꿈은 그 뒤에 놓인 \n입니다. 번역문 처리 과정에서 그 \n을 장식적인 줄바꿈으로 분류해 없애면서, 두 문장이 한 줄로 합쳐져 상단 화면의 오른쪽 밖으로 흘러갔습니다. 작업 기록에는 영향을 받은 대화 항목이 338개로 남아 있습니다.

수정할 때는 단순히 한글 문장을 더 짧게 자르지 않았습니다. 먼저 표식의 역할을 고치고, 원문이 다음 메시지를 시작하는 지점의 줄바꿈을 번역문으로 옮겼습니다. 줄바꿈 자체를 잘못 이해한 상태에서 글자 수만 줄이면 다른 문장에서 같은 문제가 다시 일어납니다. 기존 영어에서 수동 줄바꿈된 800개 항목의 배치를 재현하는 검사도 이 결정의 근거가 됐습니다. 화면을 보고 규칙을 다시 세운 뒤 그 규칙을 전체 항목에 적용한 사례입니다.

메뉴나 타이틀 화면도 텍스트와 이미지의 차이를 구별해 기록했습니다. 아래 배포본 캡처의 타이틀 로고는 원본 로고입니다. 로고 이미지까지 한국어로 다시 그렸다고 말할 수 없습니다. 본문의 메시지와 글꼴 작업이 확인되는 범위이며, 그래픽에 이미 그려진 문자를 모두 번역했다는 기록은 없습니다. 대화 상자 밖에 보이는 원본 그래픽을 새 한국어 자산으로 오인하지 않도록 이 화면을 함께 남깁니다.

5. 검증 기록과 검증하지 못한 범위

검증은 각기 다른 질문을 맡았습니다. 원본을 그대로 해제하고 다시 합쳤을 때 같은 파일인지, 번역문마다 제어 표식이 같은 순서로 남았는지, 실제 배포 글꼴이 번역문의 글자를 모두 그릴 수 있는지 확인했습니다. 3,262개 배포 문자열은 모두 한국어로 분류됐고, 번역 결과를 봉인한 뒤 그 버전 그대로 의미 검수를 진행했습니다. 검사 결과는 6,471건의 통과 판정과 50개 항목에 적용된 예외 45건, 미해결 결함 0건입니다. 예외는 그 문장과 묶여 있어서 문장을 고치면 기존 허용 기록을 그대로 사용할 수 없도록 했습니다.

개발 과정에서는 검증 조건을 일부러 위반하는 56개 사례도 시험했습니다. 배포 형식을 바꾼 뒤에는 실제 3DS 리팩을 실행하고 RomFS의 73개 파일 및 ExeFS의 4개 파일을 기존 배포 빌드와 대조했습니다. 이 검사는 만들어진 파일의 일치성을 뜻합니다. 게임 전체를 처음부터 끝까지 플레이해서 모든 장면을 확인했다는 뜻은 아닙니다. 제작 기록에도 에뮬레이터 전 구간 플레이는 빌드 과정에 포함되지 않았다고 명시돼 있습니다. 제어 표식 사이의 글을 서로 바꾸되 두 부분을 비워 두지 않는 오류는 구조 검사만으로 잡지 못하며 의미 검수에 의존합니다. 이 한계도 결과와 함께 읽어야 합니다.

6. 파일별 패치의 배포와 적용

v1.0 번역은 2026년 8월 15일 공개됐고, 2026년 9월 8일부터 같은 번역 내용이 PC RomForge용 파일별 xdelta ZIP으로 배포됩니다. xdelta는 원본 파일과 바뀐 파일의 차이만 담는 패치 형식입니다. 배포 ZIP 안의 실제 차이 파일은 romfs/ap4/bcs.fa.xdelta 하나이고 설명서가 함께 들어갑니다. 3DS의 자료 영역인 RomFS 안의 묶음 파일만 바뀌며, 실행 영역인 ExeFS에는 적용할 차이 파일이 없습니다. 기존 배포 빌드 크기는 260,745,536바이트인 반면 파일별 패치 ZIP은 1,036,905바이트입니다. 이 수치는 서로 다른 형태의 산출물 크기이지 모든 3DS 게임의 압축률을 뜻하지 않습니다.

적용할 때는 한글패치 배포 사이트에서 해당 ZIP을 받고, 사용자가 정품에서 직접 만든 원본을 PC RomForge의 ‘3DS → 리팩’ 메뉴에 입력해야 합니다. 이 ZIP은 일반 단일파일 패치 메뉴에 넣는 통짜 패치가 아닙니다. 이름만 비슷한 다른 지역판을 쓰지 말고 위 원본의 Title ID와 SHA-256을 먼저 확인하십시오. ZIP의 SHA-256은 8c9e210e97a68c71e8871d4bff41c01e32d2d84fc44b24bcf29b5bd7b58a7565입니다. 재빌드 산출물의 RSA 서명을 소매 기기가 받아들이지 않으므로, 실행에는 sighax/boot9strap 계열 사용자 지정 펌웨어 환경이 필요하다는 배포 안내도 확인해야 합니다.

저희는 원본 ROM·BIOS나 완성된 게임 파일을 배포하지 않으며 이 글은 그 파일을 구하는 곳을 안내하지 않습니다. 배포 패키지의 용도는 사용자가 준비한 일치하는 원본의 변경 부분을 재구성하는 것입니다. 리팩 검증에서 파일의 일치성을 확인한 것과 플레이 전 구간의 품질을 확인한 것은 별개의 주장입니다. 패치 제작과 적용의 일반적인 구분은 한글패치 이해하기, 원본과 저작권에 관한 기준은 에뮬레이션과 저작권에서 설명합니다.