잔상기록

개인정보 처리방침 및 쿠키 안내

retrace — Wed, 23 Sep 2026 18:55:51 +0900

시행일: 2026년 9월 23일

이 안내는 잔상기록(https://retrace.tistory.com) 방문자가 블로그 운영자의 직접적인 개인정보 처리와 쿠키 사용을 확인할 수 있도록 작성했습니다. 블로그 운영자 표기는 retrace이며, 문의는 retrace.kr@gmail.com으로 보내 주세요.

1. 티스토리 플랫폼 이용

잔상기록은 카카오가 제공하는 티스토리 서비스에서 운영됩니다. 티스토리 이용 과정에서 단말기 정보, IP 주소, 쿠키, 방문 일시와 서비스 이용 기록 등이 자동으로 생성·수집될 수 있습니다. 회원 계정, 플랫폼 로그, 플랫폼 쿠키의 처리와 보유 기간은 블로그 운영자가 별도로 정하거나 전부 열람하지 않습니다. 이 정보의 상세 내용과 권리 행사는 카카오 개인정보처리방침과 티스토리 개인정보처리방침 통합 안내를 확인해 주세요.

2. 댓글·방명록·이메일 문의

방문자가 댓글이나 방명록에 직접 게시한 닉네임과 내용은 블로그에 공개될 수 있습니다. 운영자는 댓글과 방명록을 관리하고 문의에 답하기 위해 해당 게시 내용을 확인합니다. 공개 게시물에는 비밀번호, 연락처, 주소, 계정 정보 등 민감한 정보를 적지 마세요.

이메일로 문의하면 회신을 위해 발신 이메일 주소와 문의 내용을 받습니다. 문의 정보는 답변과 후속 처리가 끝난 뒤 더 이상 보관할 필요가 없을 때 삭제합니다. 이 블로그가 관리하는 댓글·방명록 또는 문의 내용의 열람·정정·삭제를 요청하려면 위 이메일로 해당 글의 주소와 요청 내용을 보내 주세요. 티스토리 계정이나 플랫폼 로그 관련 요청은 카카오 고객센터에 문의해 주세요.

3. 광고 쿠키와 맞춤형 광고

이 블로그에서 Google AdSense 광고 태그가 작동하거나 Google 광고가 게재되는 경우, Google 및 광고 요청에 포함된 제3자 광고 기술 제공업체가 쿠키 또는 유사 기술을 사용해 광고를 제공·측정할 수 있습니다. Google과 제3자 업체는 방문자의 이 사이트 또는 다른 사이트 방문 기록을 바탕으로 광고를 맞춤 설정할 수 있습니다. Google의 광고 쿠키는 광고 측정과 이미 본 광고의 반복 노출 조절에도 사용될 수 있습니다.

Google 맞춤형 광고는 Google 광고 설정에서 관리할 수 있습니다. 일부 제3자 광고 쿠키의 맞춤형 광고 사용은 aboutads.info 선택 도구에서도 거부할 수 있습니다. Google의 쿠키 사용에 관한 자세한 내용은 AdSense 쿠키 안내와 Google 광고의 개인정보 고지 항목을 확인해 주세요.

4. 쿠키 설정

티스토리와 광고 서비스는 서비스 제공을 위해 브라우저에 쿠키를 저장하거나 읽을 수 있습니다. 방문자는 브라우저 설정에서 쿠키를 차단하거나 삭제할 수 있습니다. 쿠키를 차단하면 로그인이나 일부 서비스 기능이 제한될 수 있습니다. 광고 맞춤 설정은 위 Google 광고 설정에서 별도로 관리할 수 있습니다.

5. 방침 변경

블로그에서 사용하는 광고 서비스나 개인정보 처리 방식이 바뀌면 이 안내를 수정하고 시행일을 갱신하겠습니다. 티스토리 플랫폼 자체의 처리 방식은 카카오 개인정보처리방침을 따릅니다.

[PSP] 데프잼 파이트 포 뉴욕 테이크 오버 한글패치

retrace — Sun, 20 Sep 2026 19:25:10 +0900

원본 정보

항목	정보
게임명	Def Jam: Fight for NY - The Takeover
플랫폼	PSP
지역	USA
Disc ID	ULUS-10100
기준 파일명	Def Jam - Fight for NY - The Takeover (USA).iso

스크린샷

패치 파일

Def_Jam_FFNY_The_Takeover_Korean_v1_0.xdelta

8.49MB

패치정보

Original USA ISO
Filename : Def Jam - Fight for NY - The Takeover (USA).iso
Size     : 1,576,894,464 bytes
CRC32    : A5B5EC8F
SHA-256  : 46B5AD696561DA4007D80ACA34E3DF1D533FE7000CE5ADA976368E891F2788A8
Patched Korean v1.0 ISO
Size     : 1,609,680,896 bytes
CRC32    : 8D1D8359
SHA-256  : 3C54435177FC8B8384ED2DA7F074A59DFE791DA0AB05989B280EB6FE20F8959B

<GBA> 동년배 DEMO v0.42

retrace — Sun, 20 Sep 2026 14:53:49 +0900

자작게임 《동년배》의 GBA 버전 첫 번째 데모입니다.

아직 초기 버전이라 플레이 분량은 짧지만, 실제 GBA 롬으로 제작해 에뮬레이터에서 즐길 수 있도록 만들었습니다.

40세 아재의 일상을 다룬 생활형 어드벤처 게임으로, 앞으로 캐릭터와 장소, 이야기를 조금씩 추가해 나갈 예정입니다.

이번 버전은 정식 데모보다는 게임의 기본적인 분위기와 진행 방식을 확인하는 프로토타입에 가깝습니다.

게임 정보

제목: 동년배
버전: DEMO v0.01
기종: Game Boy Advance (GBA)
장르: 생활형 어드벤처
제작: retrace

다운로드

Dongnyeonbae_v0.4.2.gba

1.00MB

스크린샷

[PS2] 신 귀무자 한글패치 v2.1

retrace — Sat, 19 Sep 2026 23:05:14 +0900

패치 정보

게임명
신 귀무자 DAWN OF DREAMS
플랫폼
PlayStation 2
기준 버전
일본판 The Best
패치 버전
v2.1
한글화 제작자
retrace (막타/월스트리트김)

업데이트 정보

<v2.1>

1. 스킬 설명 48쪽, 일기·문서·비망록·힌트 71쪽 한글화
2. 메뉴 글자 잘림·가격 위치·하단 버튼 안내 수정
3. 띄어쓰기와 연성·아이템 안내 문구 수정

<v2.0>

기존 v1.0은 영어판을 기준으로 한글화하여 영어 음성에서는 자막 싱크가 정상적이었으나, 일본어 음성에서는 일부 자막이 어긋나는 현상이 있었습니다. 대부분 일본어 음성으로 플레이하시는 점을 고려하여, 이번에는 일본판 원문을 기준으로 컷신과 인게임 음성 자막을 새로 재작업하였습니다. 기타 간헐적 메모리 문제로 인한 텍스트 미출력, UI 디자인 변경 등 많은 부분 수정하였습니다.

※ v2.0은 일본어 음성 + 한국어 시스템 언어 기준으로 제작되었습니다. 영어 음성으로도 플레이할 수 있지만, 일부 인게임 자막의 싱크가 맞지 않을 수 있습니다.

1. 번역 전면 개편

기존 영어판 기준 번역을 일본판 원문 기준으로 재작업
일본어 대사의 의미와 흐름을 반영하여 번역 개선

2. 자막 및 음성 싱크 개선

일본어 음성 기준 컷신 및 인게임 자막 싱크 최적화
스테이지 도입부 및 종료부 스크롤 자막 겹침 수정
본부에서 나갈때 대화 자막 누락 수정

3. 메뉴 및 UI 개선

게임 중 메뉴 아이템 선택 화면의 정렬 및 디자인 개선
장비 강화 화면의 설명 출력 오류 수정
미노키치 대화 선택지 간헐적 공백 발생 오류 수정

4. 설정 한국어 디폴트

설정에서 시스템언어 바꾸지 않아도 한국어 디폴트 유지

<V1.0>

최초 배포

게임 소개

PS2 황혼기에 출시된 작품으로, 기존 귀무자 시리즈보다 조작 방식이 현대적인 형태로 변화했습니다.
기존의 탱크식 조작이 아닌 자유 이동 방식을 사용하며, 오른쪽 아날로그 스틱으로 시점을 자유롭게 조작할 수 있습니다.
당시 PS2 게임 중에서도 그래픽이 좋은 편이고 전투 역시 빠르고 시원한 편입니다.
출시 시기 때문인지 상대적으로 많이 알려지지는 않았지만, 플레이해본 분들 사이에서는 좋은 평가를 받는 작품입니다.

한글화 범위

컷신 자막
인게임 대사
메뉴 및 각종 UI
아이템명 및 설명
장비
스킬
게임 진행에 필요한 각종 안내문
(단,이미지로 뜨는 기술설명 부분은 미번역)

게임 진행에 필요한 부분을 전반적으로 한글화했습니다.

적용 시 주의사항

에뮬 사용시 그래픽은 VULKAN으로 해주세요. OPENGL로 하면 글자 거의 안보이는 경우가 있습니다.

스크린샷

다운로드

일본판(PlayStation 2 the Best) - Disc 1: SLPM-74232/ Disc 2: SLPM-74233

<원본에 적용>

Shin_Onimusha_KOR_v2_1_Original.zip

15.31MB

<기존 2.0 한글패치 롬에 적용>

Shin_Onimusha_KOR_v2_0 to v2_1_Update.zip

6.81MB

※ 블로그 오류로 확장자가 사라지는 경우엔 . zip 확장자를 넣으시면 됩니다

패치정보

Disc 1
패치: Shin_Onimusha_KOR_v2.1_From_Original_Disc1.xdelta
적용 전: 4,674,224,128 bytes
CRC32: DEE93128
SHA256: B2334DB96EE41B6D2275B32088BDAE3E85CE313F06909486877F721E3A6E951C
적용 후 v2.1: 4,674,224,128 bytes
CRC32: F6673633
SHA256: 732531454C26B80C41AB056DABFDA15201B8E0A014F6C458FD67D104D7B4C3ED

Disc 2
패치: Shin_Onimusha_KOR_v2.1_From_Original_Disc2.xdelta
적용 전: 4,674,224,128 bytes
CRC32: EDE05373
SHA256: 0F4F679638EF3AB5EF6EB9415E21E4993BCE72FE89650A785443B9159AE868EA
적용 후 v2.1: 4,674,224,128 bytes
CRC32: 032AE718
SHA256: 7F756E3B93E1655CF689B153690FB09B5685B39328CCA481D968CD42044DA3FD

PS2 신귀무자 한글패치 업데이트 예정사항

retrace — Fri, 18 Sep 2026 16:01:24 +0900

현재 1.0은 시스템 언어에서 영어를 선택했을때 영역을 한글화한 방식이라, 영어 음성 기준으로 플레이할 때는 큰 문제가 없지만 일본어 음성으로 플레이하면 일부 동영상 자막 타이밍이 맞지 않는 부분이 있었습니다.

(일본음성과 영어음성 타이밍이 차이가 꽤 있네요)

이번에 업데이트 시 시스템 언어 일본어 쪽에도 현재 한글화된 메뉴, 인게임 대사, 아이템, 장비 등의 내용을 동일하게 적용하고, 동영상 자막은 일본어 음성 타이밍에 맞춘 버전을 별도로 적용할 예정입니다.

반대로 시스템 언어 영어를 선택하면 기존처럼 영어 음성에 맞는 자막 타이밍이 나오도록 복원하구요.

즉

일본어 시스템 언어 + 일본어 음성

영어 시스템 언어 + 영어 음성

두 조합 모두 한글로 플레이할 수 있도록 수정 중입니다.

이와 함께 1.0 이후 확인된

최초 빈 메모리카드 안내 문구 잘림 수정,

일부 상황에서 간헐적으로 텍스트가 정상 출력되지 않는 문제 안정화,

일본어 시스템 언어에서 음성을 영어로 변경했을 때 '영어'라는 문구가 표시되지 않던 문제 등 자잘한 부분도 함께 수정됩니다.

패치는 저녁쯤 나올거 같은데 혹시 테스트 상 문제가 확인되면 좀 더 걸릴 수도 있을거 같습니다.

지금도 플레이에는 크게 문제는 없으나 이왕이면 1.1 업데이트 후 패치 하시는걸 추천드립니다.

[FC] 피구왕 통키2 한글패치 v1.3

retrace — Wed, 16 Sep 2026 18:20:14 +0900

기본 정보

사용 AI: Codex
게임명 : 피구왕 통키2 (Honoo no Toukyuuji - Dodge Danpei 2)
제작자 : retrace(막타/월스트리트김)
플랫폼 : 패미컴
장르 : 스포츠
패치버전 : v1.3

한글화 소개

먼저 저해상도 FC 게임인 만큼 폰트 가독성에 특히 신경을 썼습니다.
가능한 한 글자가 또렷하게 보이도록 여러 차례 수정했고, 원작과 비슷하게 폰트에 그림자를 넣어 배경에 묻히지 않도록 조정했습니다.

캐릭터 이름은 일본 원작 기준을 선호하시는 분들도 계시겠지만, 국내에서는 애니메이션판 이름이 훨씬 익숙하다고 생각해 통키, 맹태, 민대풍 등 국내 방영판 기준으로 통일했습니다.

평소에는 제가 예전에 직접 플레이했던 게임이나 좋아하던 게임을 주로 작업했는데, 이번 피구왕 통키2는 처음 접해본 게임이라 상대적으로 직접 플레이하며 검수한 양이 많지는 않습니다.

제가 발견한 부분은 없으나 혹시 플레이 중 오역이나 미번역, 글자 깨짐 등 문제가 보이면 알려주세요.
제보해주신 내용은 모아두었다가 추후 한 번에 수정해보겠습니다.

패치 내용

v1.3

1. 경기 중 표시 이름을 나통키 / 오맹태 / 남타이거로 수정 (대사 중 호명은 통키 / 맹태 / 타이거 기존 그대로 유지)

2. 더블 히트, 라인 크로스 발생 시 일부 글자가 오타로 보이던 문제 일괄 수정

3. 경기 종료 후 미나 대사의 점이 Q로 표시되던 문제 등

v1.2
1. 간헐적 경기 중 색 네모와 대사창 밖 글자 잔상 수정
2. 경기 종료, 능력 상승, 응원 문구 및 시간 표시의 글꼴 오류 수정

v1.1
1. 일대일 모드 한글화
2. 일본 원작기준으로 남아 있던 인명과 필살슛 명칭을 국내판 방송판 기준으로 추가
3. 시합 파트의 미번역 문구, 경기 중 글자 깨짐·창 넘침·선택 메뉴 및 아웃 표시 오류 수정

v1.0
최초배포

스크린샷

호환 에뮬레이터

Mesen을 기준으로 제작 및 테스트했으며, FCEUmm / Nestopia 계열에서도 동작하도록 고려했습니다.
MMC5 확장 CHR 뱅킹/ExRAM 기능 지원이 부족한 에뮬레이터에서는 정상 작동 하지 않을 수 있습니다.

패치 다운로드

※ 블로그 첨부 오류로 다운로드 시 확장자가 사라지는 경우가 있습니다. 이 경우 파일명 뒤에 .ips을 붙여주시면 됩니다.

1. 원본용(일본판 .NES에 적용)

DodgeDanpei2_KOR_v1_3.ips

1.14MB

원본 용량: 513KB
원본 CRC32: 646666F2
패치후 CRC32: 6B370295

2. 기존 1.2 패치롬에 적용

DodgeDanpei2_KOR_1_2_to_1_3.ips

0.18MB

정렬(alignment)과 패딩(padding)이 게임 파일 분석을 어렵게 만드는 이유

retrace — Tue, 15 Sep 2026 21:08:59 +0900

정렬과 패딩은 바이트를 관찰해 판별한다

헥스 에디터에서 반복되는 00이나 FF가 보인다고 곧바로 패딩이라고 결론낼 수는 없다. 00은 문자열 종료 표식, 길이 필드의 일부, 정렬을 맞추는 빈 공간일 수 있고, FF도 실제 데이터나 미사용 영역일 수 있다. 먼저 포인터가 가리키는 위치와 여러 레코드의 경계를 비교한다.

정렬(alignment)은 어떤 주소가 정해진 경계에 놓이도록 하는 규칙이다. 패딩(padding)은 다음 경계를 맞추려고 레코드 뒤에 실제로 들어간 여분의 바이트다. 모든 게임 파일이 문자열을 2바이트나 4바이트로 정렬하는 것은 아니다. 디스크 섹터 경계 정렬은 레코드 정렬과 별개의 규칙이다.

4바이트 정렬 예시

파일 오프셋 0x120에서 시작하는 레코드가 5바이트라고 가정한다. 레코드 끝 다음 주소(end-exclusive)는 0x125다. 다음 레코드가 4바이트 경계에서 시작해야 한다면, 끝 주소에 더할 패딩은 (-end_offset) % 4로 계산한다. 이 예에서는 3바이트를 더해 다음 레코드가 0x128에서 시작한다.

start = 0x120
record_length = 5
end_exclusive = start + record_length   # 0x125
padding = (-end_exclusive) % 4          # 3
next_start = end_exclusive + padding    # 0x128

이 계산은 위치를 예측할 뿐, 그 세 바이트가 반드시 00이라는 뜻은 아니다. 실제 패딩 값은 원본의 여러 레코드에서 확인한다. 문자열 길이에 종료 바이트를 포함하는지, 길이 필드가 헤더까지 세는지도 파일 포맷마다 다르다.

정렬 단위를 찾는 절차

포인터 테이블이나 레코드 인덱스가 가리키는 시작 오프셋을 여러 개 기록한다.
각 레코드의 끝 주소와 다음 시작 주소 사이 간격을 계산한다. 반복해서 같은 경계가 나오면 2·4·8 등의 정렬 가설과 맞춰 본다.
문자열 길이가 다른 레코드도 비교한다. 길이가 달라도 다음 주소가 경계에 맞으면 정렬 가설이 강해지지만, 한 사례만으로 확정하지 않는다.
포인터가 파일 시작 기준인지, 섹션 시작 기준인지, 블록 기준인지 확인한다. 기준 주소를 잘못 잡으면 나머지 포인터도 일정하게 어긋난다.
복사본에서 한 레코드만 수정한 뒤 길이 필드, 포인터, 다음 레코드의 시작과 내용을 다시 읽는다.

데이터 길이 필드가 이미 레코드 끝을 지정한다면 별도 종료 바이트를 찾지 못할 수 있다. 반대로 종료 코드가 레코드 경계를 정해도 정렬 때문에 그 뒤에 여분 바이트가 올 수 있다. 경계 규칙을 구분해 추출기에 기록해야 번역문을 늘렸을 때 다음 항목을 덮어쓰지 않는다.

AI 분석 결과는 오프셋으로 검증한다

AI에게 반복되는 00을 패딩이라고 이름 붙이게 하기보다, 원본 오프셋·포인터 값·레코드 길이·다음 시작 주소를 함께 주고 가능한 가설별 계산을 비교하게 한다. 여러 레코드에서 계산 결과가 같은 경계를 예측하는지 확인한 뒤에만 추출·삽입 규칙으로 고정한다.

메뉴용 폰트와 대사용 폰트를 분리해야 하는 이유

retrace — Tue, 15 Sep 2026 21:08:39 +0900

폰트를 꼭 나눠야 하는 것은 아니다

메뉴용 폰트와 대사용 폰트를 분리할지는 화면 이름만으로 정할 수 없다. 먼저 각 화면이 같은 폰트 로더와 문자 테이블을 쓰는지, 두 글꼴이 동시에 메모리에 올라가는지 확인한다. 한 아틀라스(atlas)에 글자가 들어 있어도 화면이 다른 문자 코드표나 별도 렌더링 경로를 쓰면 그 글자를 찾아 그리지 못할 수 있다.

글리프(glyph)는 문자 하나를 그리는 모양과 위치 정보다. 아틀라스는 여러 글리프의 픽셀을 한 이미지나 타일 영역에 모아 둔 것이다. 글리프 수와 실제 메모리 사용량은 같지 않다. 글리프 크기, 픽셀당 비트 수, 정렬, 팔레트, 압축 방식이 영향을 준다.

분리 여부를 판단하는 네 가지 확인

메뉴, 대사, 전투, 이름 입력에서 한글 한 글자와 영문·숫자가 실제로 어떤 폰트 테이블과 그리기 코드를 통과하는지 확인한다.
화면별로 필요한 고유 글리프 집합을 만든다. 공통 글리프와 특정 화면에서만 쓰는 글리프를 나누면 중복 저장량을 계산할 수 있다.
각 폰트 데이터의 크기 제한과 로드·해제 시점을 확인한다. 화면 전환 뒤 이전 폰트가 메모리에 남는지도 실제 실행에서 본다.
두 화면이 동시에 표시될 수 있는지 확인한다. 대화 중 메뉴 오버레이가 뜬다면 두 폰트의 동시 적재량이 필요하다.

메모리 계산 예시

압축 전 4bpp(픽셀당 4비트) 이미지라고 가정하면, 512×256 아틀라스는 약 64KiB, 512×512 아틀라스는 약 128KiB다. 메뉴용 64KiB와 대사용 128KiB를 분리해 둘 다 동시에 올리면 픽셀 데이터만 약 192KiB가 필요하다. 두 화면이 서로 배타적이고 이전 아틀라스를 해제한다면 순간 최대치는 약 128KiB다.

이 수치는 픽셀 배열만 계산한 예다. 팔레트, 글리프 표, 정렬 여유, 압축 해제 버퍼와 다른 런타임 할당은 포함하지 않는다. 실제 예산은 게임이 메모리를 할당하는 방식과 원본 데이터 형식으로 확인한다.

통합하거나 분리할 기준

같은 로더와 문자 테이블을 쓰고, 모든 화면의 글리프가 정해진 용량에 들어가며, 필요한 동안 함께 유지해도 메모리 예산을 넘지 않으면 공유 폰트가 간단하다.
화면마다 문자 코드표·글리프 크기·저장 형식이 다르거나, 화면이 서로 배타적이고 이전 아틀라스를 확실히 해제할 수 있다면 분리할 근거가 있다.
두 폰트가 동시에 필요한데 둘 다 별도 고정 영역을 차지한다면, 분리는 메모리를 줄이지 않고 오히려 중복 글리프 때문에 사용량을 늘릴 수 있다.

결정 뒤에는 메인 메뉴, 긴 대사, 이름 입력, 메뉴와 대사가 겹치는 화면을 각각 실행해 한글·영문·숫자의 글리프가 모두 올바른지 확인한다. 화면 전환 뒤에만 글자가 사라지거나 다른 모양으로 바뀌면 용량보다 로더, 코드표, 폰트 포인터를 먼저 조사한다.

한글 문장 길이가 맞아도 화면이 넘치는 이유

retrace — Tue, 15 Sep 2026 21:08:18 +0900

글자 수와 렌더링 폭은 다른 값이다

문자열이 원문보다 짧아도 대사창을 넘칠 수 있다. 화면에 쓰는 폭은 글리프의 advance(다음 글자를 놓을 때 커서가 이동하는 거리), 글자 간격, 선택적인 kerning(특정 글자쌍 조정값)에 따라 결정된다. 저장된 문자열의 바이트 수나 글자 수만으로는 화면 폭을 알 수 없다.

한 줄의 예상 폭은 다음처럼 계산할 수 있다.

text_width = sum(glyph_advances) + sum(pair_kerning) + letter_spacing * (glyph_count - 1)

실제 잉크 픽셀은 글리프의 좌우 bearing 때문에 advance 범위 밖으로 조금 삐져나올 수도 있다. 따라서 폭 계산은 잘림 후보를 찾는 기준이고, 화면 캡처 확인을 대신하지 않는다.

숫자로 보는 간단한 예

한 줄이 16글자이고 14글자의 advance가 8px, 나머지 2글자가 9px라고 가정한다. 글자 사이에 1px 간격이 15번 들어가면 예상 폭은 14×8 + 2×9 + 15×1 = 145px다. 창의 실제 사용 가능 폭이 144px라면 1px가 넘는다. 화면에서는 마지막 글자가 잘리거나 엔진의 줄바꿈 규칙에 따라 다음 행으로 넘어갈 수 있다.

고정폭 게임은 글자 수×셀 너비로 먼저 위험을 추릴 수 있다. 가변폭 폰트는 실제 글리프 테이블에서 advance를 읽어야 한다. 두 방식이 섞였는지 한글·영문·숫자를 각각 확인한다.

사용 가능 폭과 행 수를 계산한다

대사창의 전체 너비에서 좌우 테두리와 내부 여백을 빼고, 같은 줄을 차지하는 이름표·초상화·아이콘이 있으면 그 영역도 뺀 값이 본문 사용 가능 폭이다. 이름이 별도 줄에 나오는 화면에서는 이름표 폭을 빼지 않는다. 창의 모양만 보고 영역을 추정하지 말고 게임 좌표나 화면 픽셀로 측정한다.

각 번역 행을 예상 폭과 비교하고, 최대 행 수와 페이지 넘김·대기 토큰을 따로 기록한다. 원문의 줄바꿈을 그대로 복사하면 한국어에서 불필요한 공백이 생길 수 있고, 토큰을 지우면 대사 진행이 바뀔 수 있다.

작은 계산 스크립트

아래 예시는 advance 값이 이미 조사된 경우 폭 초과 후보를 찾는다. 실제 인덱싱에서는 게임의 문자 인코딩에 맞춰 글리프별 advance를 가져와야 한다.

advances = [8] * 14 + [9] * 2
letter_spacing = 1
usable_width = 144
text_width = sum(advances) + letter_spacing * (len(advances) - 1)
print(text_width, text_width > usable_width)  # 145 True

게임 안에서 확인할 문장

가장 긴 대사와 가장 긴 선택지
한글·영문·숫자와 아이템명이 섞인 행
이름표나 초상화가 본문 공간을 줄이는 화면
페이지 넘김·대기 코드가 포함된 대사
세이브 후 다시 표시되는 이름 입력·상태창

자동 계산으로 표시한 후보를 게임에서 실제로 띄워 잘림, 줄바꿈, 페이지 전환을 확인한다. 넘치는 문장을 줄일 때는 말투와 아이템명, 숫자, 선택지의 뜻을 유지한다. 글꼴 크기나 폭을 통째로 바꾸면 다른 메뉴와 화면까지 영향을 받으므로, 원인이 확인된 문자열·메트릭·창 영역부터 조정한다.

문자열을 바꿨는데 게임이 계속 원문을 보여주는 이유

retrace — Tue, 15 Sep 2026 21:07:56 +0900

번역 파일을 수정했고 저장도 성공했는데 게임 화면에는 원문이 그대로 나오는 경우가 있습니다. 실제 원인은 게임이 수정한 자산에 도달하지 못한 것일 수 있습니다. 파일의 존재와 게임의 사용은 같은 사실이 아닙니다.

자산 도달성은 네 단계로 나눠 본다

문자열이 화면에 나타나려면 저장, 조회, 로드와 변환, 소비라는 연결이 필요합니다. 파일 안에 번역문이 있는지 확인하는 것은 저장 단계의 증거일 뿐입니다. 게임이 올바른 경로와 오프셋을 읽고 압축과 인코딩 변환을 끝낸 뒤 현재 화면이 소비해야 합니다.

Store: 번역문이 올바른 레코드에 들어갔는가
Lookup: 인덱스·경로·포인터가 그 레코드를 가리키는가
Load/Transform: 압축 해제·인코딩 변환·캐시 갱신이 성공하는가
Consume: 현재 화면이 그 문자열을 읽어 그리는가

원문이 남는 대표적인 경로

같은 문장이 여러 복사본으로 존재하거나 메뉴용과 대사용 문자열이 다른 뱅크에 있을 수 있습니다. 언어 선택에 따라 별도 리소스를 읽거나 이전에 로드한 캐시를 계속 사용할 수도 있습니다. 중복 문자열, fallback 언어, region 파일, 실행 파일이 참조하는 경로를 차례로 확인해야 합니다.

AI에게 “왜 원문이 나오지?”라고만 묻지 말고 수정 파일의 해시, 번역문 readback, 포인터 변화, 로드 로그, 화면에서 확인한 문장을 단계별로 제공하세요. 한 문장에 눈에 띄는 표식을 넣고 화면까지 따라가면 소비 경로 문제와 삽입 문제를 구분할 수 있습니다.