35년 전 게임 한글화 이야기에서 가장 흥미로운 대목은 AI가 4,448개 문장을 빠르게 번역했다는 사실이 아니다. 더 본질적인 변화는, 원래는 손댈 엄두가 잘 나지 않던 고전 게임 현지화가 이제는 추출, 구조 해석, 재조립, 렌더링, 검수까지 이어지는 복원 파이프라인의 문제로 다뤄지기 시작했다는 점이다. 키란디아의 전설 2는 독자적인 PAK, EMC, DLG 포맷과 ASCII 전제 엔진 때문에 오랫동안 한글화가 어려웠다. 한국어는 2바이트 EUC-KR이고, 게임은 처음부터 그런 입력을 상정하지 않았기 때문이다.
그래서 이 작업은 번역 파일 하나 만드는 일로 끝나지 않는다. 먼저 게임 파일을 Python 도구로 해부해야 했다. PAK 아카이브를 열고 닫고, EMC 스크립트를 파싱하고, DLG 대화 구조를 JSON으로 풀어내고, 다시 한글 데이터를 넣은 .KMC, .DLK, .KOR 파일로 재조립하는 흐름이 필요했다. 특히 EMC는 단순 텍스트 교체가 통하지 않았다. TEXT 청크만 갈아끼우는 것처럼 보여도, 실제로는 바이트코드가 문자열 오프셋을 참조하고 있어 오프셋을 다시 계산하며 파일 전체를 조립해야 했다. 추출보다 재패킹이 더 어렵고 더 중요했던 셈이다.
폰트 문제도 컸다. 게임에는 한글 폰트가 없었기 때문에 The Dig 한국어판의 비트맵 폰트를 가져와 활용했고, ScummVM 쪽에서는 기존 ChineseFont와 MultiSubsetFont 구조를 재사용해 영문과 한글을 함께 렌더링하도록 연결했다. 이 선택이 실용적이다. 완전히 새로운 렌더러를 처음부터 만든 것이 아니라, 이미 존재하는 1바이트·2바이트 처리 체계를 한국어에 맞게 이어 붙였다. 그 결과 게임은 ASCII와 EUC-KR을 같은 슬롯 안에서 다룰 수 있게 되었고, 패치 파일은 OTHER.PAK 하나로 묶는 형태까지 정리됐다.
디버깅 과정은 더 상징적이다. 게임에 한글이 나오는 대신 모든 대사가 '가가가가'로 보이는 문제가 발생했는데, 원인은 하나가 아니었다. 줄바꿈 계산이 ASCII 폰트 기준으로 이루어져 EUC-KR 2바이트 문자를 중간에서 끊어버리는 버그가 있었고, 동시에 한국어 언어 인덱스가 일본어 스크립트 쪽으로 잘못 매핑되는 문제도 있었다. 둘 다 증상은 비슷하게 보이기 때문에 하나만 고쳐서는 변화가 없었다. 오래된 소프트웨어를 다룰 때 단일 증상 뒤에 복수 원인이 숨어 있는 전형적인 사례다.
이 장면에서 AI의 위치가 분명해진다. AI는 초벌 번역을 빠르게 만들고, Python 빌드 도구와 ScummVM C++ 패치를 작성하고, 포맷 파싱 로직을 구현하는 데 큰 역할을 했다. 하지만 방향을 잡고, 재료를 모으고, 실제 게임을 실행해 증상을 확인하고, 번역의 톤과 맥락을 검수하고, PR 형태를 정리하는 일은 여전히 사람이 맡았다. 결국 가치가 발생한 지점은 'AI가 대신 했다'가 아니라, 사람이 리더가 되어 복원 루프를 설계하고 AI를 그 안에 배치했다는 데 있다.
고전 게임 한글화의 병목은 이제 문장 수만의 문제가 아니다. 텍스트를 어떻게 꺼내고, 어떤 구조로 다시 넣고, 미완성 상태에서도 어떻게 플레이 가능하게 만들며, 엔진 차원의 제약을 어디까지 다룰지를 설계하는 일이 더 중요해지고 있다. 그런 관점에서 보면 이번 사례는 번역 자동화의 성공담이라기보다, 오래된 디지털 자산을 다시 실행 가능한 상태로 복원하는 엔지니어링 모델에 가깝다.