압축된 텍스트를 찾았다고 바로 수정하면 안 되는 이유

게임 파일에서 문장처럼 보이는 데이터가 발견되면 곧바로 바꾸고 싶어집니다. 하지만 텍스트가 압축되어 있다면 파일에서 보이는 바이트와 runtime이 읽는 문자열은 서로 다른 표현입니다. 압축 스트림의 일부를 평문처럼 수정하면 해제가 실패하거나 뒤에 있는 모든 레코드의 경계가 무너질 수 있습니다.

파일 안에는 여러 경계가 겹쳐 있다

디스크나 ROM의 바깥에는 아카이브 컨테이너가 있고 그 안에 압축 블록, 헤더, 인덱스, 패딩이 들어갈 수 있습니다. 압축을 푼 뒤에야 string pool이나 pointer table이 나타나는 구조도 있습니다. 텍스트 저장 위치와 게임이 압축을 푸는 시점은 별개의 질문입니다.
압축 데이터는 우연히 ASCII나 일본어 코드와 비슷한 바이트를 포함할 수 있습니다. AI가 문자열 패턴을 발견했다고 해도 실제 텍스트 레코드라는 증거는 아닙니다. 압축 해제 결과와 runtime 소비 경로가 연결되는지 확인해야 합니다.

먼저 압축과 해제의 왕복을 만든다

수정 전에 원본 블록을 해제하고 다시 압축했을 때 동일한 결과 또는 허용된 차이가 나오는지 확인합니다. 원본 크기, 해제 후 크기, 압축 방식, 블록 경계, 체크섬과 오프셋을 기록합니다. 이 왕복이 되지 않으면 번역문을 넣기 전에 도구부터 고쳐야 합니다.

1. 컨테이너에서 블록의 시작과 끝을 식별합니다.
2. 압축 해제 결과의 레코드와 문자열 경계를 확인합니다.
3. 한 개의 짧은 문자열만 바꿔 재압축합니다.
4. 헤더 크기와 인덱스, 다음 블록 위치를 다시 계산합니다.
5. 같은 로더를 통해 새 블록을 읽는지 확인합니다.

AI에게 파일 일부만 보여주면 압축 여부를 확정하지 못한 채 익숙한 포맷으로 설명할 수 있습니다. 모르는 부분은 “압축된 것으로 추정”이라고 남기고, 해제 성공과 재압축 후 readback을 별도 증거로 요구해야 합니다.