ROM 쓰기: 읽을 수 있는 코드에서 허용된 변경을 증명하는 코드로

ROM writes: from readable code to code that proves the change is allowed

첫 문제는 raw hex의 의미가 보이지 않는다는 것이었다

슈퍼패미컴 마도물어에서 가장 먼저 나온 요구는 기계어를 사람이 읽을 수 있게 만들자는 것이었다.

이 단계에서 필요한 것은 명령어와 피연산자를 코드로 표현하고, 분기 주소나 명령어 길이를 검사하는 어셈블러였다. 생성된 바이트가 무슨 명령인지 설명할 수 있게 됐지만, 그 바이트를 ROM의 어디에 써도 되는지는 아직 다른 문제였다.

충돌이 반복되자 모든 쓰기 경로를 하나로 모았다

2월 21일 Git 기록에는 ROM 영역 충돌과 추적되지 않은 쓰기를 찾는 검사가 들어왔다. 이 검사가 경고만 내는 동안에는 새 구현이 추적기를 우회할 수 있었다. 다음 날 프롬프트는 리뷰를 더 꼼꼼히 하자는 수준을 넘어, 우회 자체가 어렵도록 구조를 바꾸라고 요구했다.

Git 기록에서는 이 요구가 TrackedRom 도입(64931ec)으로 이어진다. ROM을 바꾸는 모든 코드가 같은 기록 경로를 지나도록 만들어, 새 기능이 검사 밖에서 조용히 쓰는 경우를 막는 것이었다.

Expected Write는 겹치지 않는 것보다 한 단계 더 물었다

같은 날 이어진 질문은 “어디에 썼는가”만 기록하지 않고 “쓰기 전 원본이 무엇이어야 하는가”를 선언하게 했다.

그 결과는 TrackedRom Expect(76bcb0e)로 남았다. 여기서 서로 다른 검사가 나뉜다.

• 쓰기 추적은 어느 기능이 어느 범위를 바꿨는지와 기능끼리 겹치는지를 본다.
• Expected Write는 쓰기 직전의 원본 바이트가 선언한 값이나 빈 공간 조건과 맞는지 본다.
• typed ISA는 새로 만드는 실행 바이트가 선언한 CPU 명령으로 해석되는지 본다.

세 검사는 함께 쓰이지만 서로 대신할 수 없다. 충돌이 없더라도 잘못된 원본 버전에 쓸 수 있고, 예상한 빈 공간에 썼더라도 잘못 인코딩된 명령어일 수 있다.

한 프로젝트의 장치가 공용 방법으로 옮겨 갔다

세가 새턴 마도물어에서는 슈퍼패미컴판의 구조를 가져오되 디스크 쓰기에 맞게 다시 만들었다.

그날 Git 기록에는 TrackedDisc(911758c)가 들어왔다. 7월 게임기어판에서는 공용 원리를 더 짧게 다시 설명했다.

게임기어판에는 원본 바이트, 빈 공간과 빌드 후 미추적 쓰기를 확인하는 게이트가 차례로 들어갔다. 7월 메가드라이브판에서는 raw bytes나 외부 asm 파일을 최종 빌드 입력으로 두지 말자는 요구가 다시 나왔다.

8월에는 프로젝트마다 있던 ISA 구현을 공용 라이브러리로 모으기 시작했다.

retro-typed-isa의 Git 기록에는 여러 CPU 프로필과 Expected Write 검증 규칙이 8월 7일에 함께 들어왔다. 이후 슈퍼패미컴·드림캐스트·게임기어·메가드라이브 프로젝트가 공용 구현으로 옮겨 갔다. 이 흐름은 “hex 대신 enum” 한 번으로 끝나지 않았다. 읽을 수 있는 명령, 쓰기 경로의 단일화, 원본 사전조건, 프로젝트 간 공용 검사 규칙이 각각 다른 실패를 거치며 추가됐다.

실행 확인: 사람이 옮겨 적던 HITL에서 재현 가능한 관찰로

Runtime checks: from HITL a person transcribed to reproducible observation

초기 HITL은 사람에게 디버거 조작을 많이 맡겼다

2월 슈퍼패미컴판에서는 에이전트가 절차를 적고, 사람이 Mesen에서 장면을 만든 뒤 값과 결과를 답변 파일에 옮겼다.

이 방식은 사람이 알고 있는 게임 상태를 조사에 넣는 데는 효과가 있었다. 반면 같은 장면을 다시 만들거나 JP와 KR을 맞춰 비교하려면 저장 상태, 조작 순서, 메모리 값과 스크린샷을 계속 주고받아야 했다. 관찰 전에는 완료를 말할 수 없다는 경계도 사람이 따로 세워야 했다.

초기 HITL의 교훈은 사람이 에뮬레이터를 오래 조작해야 한다는 것이 아니었다. 정적 빌드 성공과 실제 소비 경로의 확인은 다른 증거라는 점, 그리고 사람만 알고 있는 장면 조건을 조사에 넣어야 한다는 점이었다.

emucap은 그 관찰을 에이전트가 다룰 수 있게 하려는 데서 시작했다

6월 23일 첫 프롬프트에는 사람이 특정 시점을 표시하고, 에이전트가 그 전후 상태와 화면을 읽는 도구라는 목적이 구체적으로 적혀 있다.

같은 날 Git 기록에는 ROM 해시가 붙은 기록 묶음과 Mesen2 회고 덤프가 생겼고, 이어서 메모리 읽기·스크린샷·상태 확인을 제공하는 라이브 제어가 들어왔다. 다음 날에는 입력, 세이브 상태, 브레이크포인트와 프레임 진행까지 확장됐다.

화면 캡처 도구에서 비교 실험 도구로 넓어졌다

개발 하루 뒤의 프롬프트는 같은 입력과 상태에서 원본과 패치판이 처음 갈라지는 지점을 찾도록 요구했다.

이에 따라 상태 덤프, 세이브 상태 이분, JP·KR 교차 비교가 추가됐다. 사람이 화면 두 장을 보고 “다르다”고 말하는 데서 끝나지 않고, 동일한 시작점과 진행량 아래에서 메모리·레지스터·DMA의 첫 차이를 좁혔다.

마지막에는 스크린샷보다 실험 기록의 연결이 중요해졌다

7월 PCE-CD판에서 나온 프롬프트는 캡처 파일을 많이 남기는 것과, 무엇을 바꾼 뒤 어떤 상태에서 무엇이 달라졌는지 기록하는 일을 구분했다.

emucap에는 6월 말부터 실행 입력, 상태와 화면을 한 실험에 묶는 tracking이 들어와 있었다. 8월에는 정해진 구간만 녹화하고, 특정 사건이 몇 번째 발생할 때 멈추거나, 준비 구간과 관찰 구간에서 받을 이벤트를 따로 정하는 기능까지 추가됐다.

도구가 맡는 부분이 늘어도 사람은 “두 번째 실패 뒤에만 나오는 힌트”, “초록 뿌요에게 아이스스톰을 쓴 장면”, “이 문장이 정상이라면 다음 화면은 무엇이어야 하는가”를 알려 준다. 에이전트와 도구는 그 상태를 재현하고, 원본과 패치판을 맞추고, 관찰을 실험 기록으로 남긴다. 사람이 매번 주소와 레지스터 값을 옮겨 적는 일은 도구로 넘어갔다.

런타임 자산: 파일에 들어간 것과 게임이 쓴 것을 가르다

Runtime assets: separating what went into the file from what the game used

실행 관찰을 자동화해도 한 질문은 남는다. 패치한 글꼴이나 문장이 ROM에 들어 있다는 사실만으로는 게임이 그 데이터를 읽었다고 할 수 없다. 읽었다고 해도 다른 로드가 바로 덮을 수 있고, RAM에 남아 있어도 화면을 그리는 코드가 다른 버퍼를 볼 수 있다. 이 차이는 emucap이 생기기 전부터 여러 게임에서 반복해서 드러났다.

한 번 쓴 데이터가 다음 상태에서도 남는지 물었다

슈퍼 나조 뿌요 2에서는 퍼즐 조건 글자를 VRAM에 한 번 넣어 현재 화면을 맞추는 시도가 있었다. 사람은 이 게임에서 한 판에 2~6개의 조건이 차례로 바뀐다는 규칙을 알고 있었다.

사람의 지적 뒤 초점은 첫 화면의 모양에서 데이터의 수명으로 옮겨 갔다. 4월에 만든 고정 덮어쓰기는 당장의 조건을 보여 줬지만, 6월 동적 확인에서는 게임의 일본어 CHR 로드가 더 늦게 와서 한국어를 다시 덮는 경우가 확인됐다. Git 이력의 97a944b는 30프레임 동안 반복하는 임시 방식 대신, 조건 화면이 실제로 살아 있는 동안만 한국어 DMA를 보내는 게이트로 바뀐 기록이다. 중요한 것은 몇 번 덮어썼느냐가 아니라 어느 상태가 시작되고 끝날 때 자산이 유효해야 하는지였다.

캐시는 파일보다 게임 진행 순서에 묶여 있었다

세가 새턴 와쿠와쿠판에서는 캐릭터마다 필요한 글자가 달라 세 개의 ROM을 만드는 우회가 한때 구현됐다. 각 파일을 따로 켜면 글자가 나왔지만, 플레이어가 캐릭터를 바꿀 때마다 패치를 바꾸는 결과였다.

세 산출물은 기술적으로 가능했지만 한 게임 안에서 캐릭터가 바뀌는 경험을 충족하지 못했다. 이어진 질문은 파일 교체가 아니라 실제 적재 시점을 겨냥했다.

캐릭터 선택, 캐릭터 OPEN, 게임 맵과 던전 진입은 서로 다른 상태였다. 캐릭터 선택에서 브레이크포인트가 안 걸렸다고 로더가 없다고 결론 내릴 수 없었다. Git 이력에는 루트별 세 벌의 글꼴을 만든 뒤 로드 시점을 추적하고, 결국 세 벌 구조를 걷어 내 한 ROM의 단일 글리프 표로 돌아간 과정이 남아 있다. 캐시를 비우고 첫 실행만 맞추는 실험은 캐릭터를 바꾸고 다시 들어오는 플레이를 증명하지 못했다.

저장 공간과 실행 중 글리프 자리는 서로 다른 한계였다

PC-98판에서는 외자 188칸이 보이자 이를 게임 전체의 글리프 저장 한계로 오해할 수 있었다. 사람은 그 숫자가 어디에서 생겼는지 다시 물었다.

디스크에 넣을 수 있는 글꼴의 총량, BIOS 외자 영역에 한 번에 등록할 수 있는 수, 현재 화면에서 동시에 필요한 글자는 같은 숫자가 아니었다. 이 구분이 생기자 “188자 안으로 번역을 줄인다”가 아니라, 디스크의 글꼴을 장면에 맞춰 실행 중인 슬롯으로 공급하는 방향을 조사할 수 있었다. 사람이 제공한 것은 캐시 주소가 아니라, 188이라는 수치가 게임 전체의 한계라는 설명이 정말 맞는지 되묻는 기준이었다.

프로젝트에서 반복된 구분이 스킬의 한 축이 됐다

7월 스킬 재구성 때 이 문제를 폰트나 압축의 부속 항목으로 두지 말자는 질문이 나왔다.

8분 뒤 Git 이력의 1224270은 런타임 자산 도달성(runtime asset reachability) 문서를 새로 만들었다. 여러 프로젝트의 표현을 합치면 확인할 연결은 다음과 같다.

1. ROM이나 디스크의 어느 자산을 빌드가 바꿨는가.
2. 파일표, 포인터, 장면 분기가 그 자산을 고르는가.
3. 실제 로더와 압축 해제 코드가 기대한 데이터를 RAM이나 VRAM으로 보냈는가.
4. 다른 화면이나 캐시 갱신 뒤에도 필요한 동안 그 데이터가 남는가.
5. 마지막 렌더러가 그 메모리를 읽어 화면에 썼는가.

한 화면이 맞았다는 사실은 그 실행 경로와 그 시점까지를 증명한다. 다른 캐릭터, 재진입, 오버레이 교체나 두 번째 로드는 자산의 선택과 수명을 바꿀 때만 별도 확인이 필요하다. 파일 수만큼 실행할 필요는 없지만, 다른 소비 경로를 같은 사례로 대신해서도 안 된다.

사람은 여기서 주소를 대신 찾지 않았다. 캐릭터를 바꾸면 어떤 화면을 거치는지, 조건문이 언제 갱신되는지, 같은 듯 보이는 장면이 실제로는 다른 진입 경로인지 알려 줬다. 에이전트는 그 게임 지식을 바탕으로 첫 번째로 끊긴 연결을 찾고, 정적 범위와 실행 증거를 나눠 기록했다.

PoC: 한글 한 글자에서 완성을 막는 조건으로

PoC: from one Korean glyph to the condition that blocks completion

한 글자 PoC가 증명하는 범위가 너무 넓게 쓰였다

한글 한 글자를 띄우는 PoC는 렌더 경로, 글리프 형식이나 인코딩의 일부를 빠르게 확인할 수 있다. 하지만 전체 번역에 필요한 글리프 수, 재배치, 동적 적재와 다른 화면의 렌더러까지 증명하지는 못한다. 6월에 스킬을 검토하면서 이 차이를 실제 프로젝트 사례로 다시 물었다.

이 프롬프트는 PoC를 없애자는 말이 아니다. PoC가 답해야 할 질문이 “한글을 띄울 수 있는가”에서 “완성할 때 실제로 막힐 조건을 넘을 수 있는가”로 바뀌었다.

게임 프로젝트에서는 가장 어려운 조건을 먼저 지정했다

게임기어판을 다시 시작할 때도 같은 질문이 구체적으로 나왔다.

PC-98판에서는 188칸의 외자 영역에 한 글자를 넣는 시연보다 전체 번역에서 요구할 글리프 양을 먼저 문제 삼았다.

전체 문장을 넣자 빌드와 화면이 무너졌고, 188이라는 숫자가 디스크에 저장할 수 있는 총 글리프 수가 아니라 동시에 등록되는 외자 슬롯의 한계라는 점을 다시 조사하게 됐다. 필요한 글자를 동적으로 공급하는 구조를 먼저 마련한 뒤에야 번역 검수를 계속할 수 있었다. 작은 성공을 더 많이 보여 주는 것보다 전체 수요를 한 번 넣어 본 실패가 설계를 더 크게 바꾼 사례다.

슈퍼 뿌요뿌요 2에서도 한 글자가 보인다는 사실보다 전체 글리프 수요를 처리할 수 있는지를 먼저 물었다.

전체 범위: 눈앞의 성공을 늘리기 전에 분모부터 세다

Full scope: counting the denominator before adding local wins

초기 프로젝트에서는 실행 중 발견한 문자열과 화면을 목록에 하나씩 더하는 일이 많았다. 새 단서를 찾는 데는 쓸 만하지만 “얼마나 남았는가”에는 답하지 못한다. 작품의 전체 구조를 먼저 세고 자동 추출 결과가 그 구조를 설명하는지 비교하면서 조사 방식이 달라졌다.

사람이 아는 작품의 크기가 추출기의 첫 검사가 됐다

메가드라이브 마도물어의 초기 추출은 5층 부근까지만 설명했다. 사람은 주소나 파일 형식을 제시하지 않고 게임의 실제 층수를 알려 줬다.

다섯 층 분량의 추출과 11층·지하 4층짜리 작품이 동시에 맞을 수는 없다. 어느 뱅크가 빠졌는지 곧바로 답하지 않았지만, 추출 완료라는 판단을 철회하고 다른 뱅크와 참조 경로를 다시 보게 했다.

PC-98판에서도 정돈된 추출표가 먼저 나왔다. 후보를 거르는 동안 세 편짜리 RPG의 이야기가 460개 안팎으로 줄어들자 사람이 수치 자체를 의심했다.

같은 날 Git 기록에서 뒤이은 변화가 보인다. 메시지를 포인터 차이마다 잘못 잘라 445개로 축소했던 파서를 고치자 1,514개가 나왔고(a5be2f5), 512개짜리 포인터 표 뒤에 있던 메뉴·아이템 텍스트 구역까지 찾으면서 MENUDAT의 전체 구조가 다시 바뀌었다(2f92054, 70845ea). “상식적으로 적다”는 느낌이 최종 증거는 아니지만, 그럴듯한 오답을 완료로 굳히지 않는 강한 경보였다.

전체 초벌은 번역 완료가 아니라 기술 수요를 드러냈다

슈퍼 뿌요뿌요 2에서는 앞 장의 “전체 한글 빌드” 질문 뒤 273개 초벌 대사와 433자 글리프 수요를 한꺼번에 넣었다. Git 이력의 7949b92가 그 전체 이야기 빌드다. 작은 시연에서는 숨었던 누락 글자와 대사창 감김이 이때 드러났다.

대사 전체가 빌드됐다고 게임 전체가 목록에 들어오지는 않았다. 첫 메뉴에서 찾아낸 그래픽 글자 세 개를 보고 사람이 다시 범위를 넓혔다.

다음 Git 기록 951c0a7은 모드 선택, 옵션과 하위 메뉴를 별도 한글화 표면으로 정리했다. 번역 문장 수, 필요한 글리프 수와 한글화할 화면 수는 서로 다른 분모였다. 어느 하나가 100%라고 다른 두 범위까지 끝난 것은 아니다.

1,100개 파일은 1,100번 실행하라는 뜻이 아니었다

전체를 놓치지 말라는 원칙과 emucap을 함께 쓰자 반대쪽 문제가 생겼다. 모든 파일을 실제로 한 번씩 띄우려는 접근이었다.

며칠 뒤에는 작은 성공을 계속 더하는 방식 자체를 문제로 설명했다.

8월 6일 Git 기록 eae22e8은 런타임 확인을 파일 수가 아니라 소비 경로로 묶도록 스킬을 고쳤다. 먼저 정적으로 파일·엔트리의 전체 목록을 만들고, 같은 선택 규칙과 로더와 렌더러를 쓰는 항목끼리 묶는다. 그 공통 경로는 대표 사례로 실행해 확인하되, 각 파일이 실제로 그 그룹에 속한다는 사실은 전체 정적 검사로 닫는다. 크기 경계, 별도 압축, 다른 캐시나 렌더러를 쓰는 예외만 따로 실행한다.

“전수”라는 말도 무엇을 보느냐에 따라 달라졌다.

사람이 1,100개 파일을 대신 실행하는 것이 해법은 아니었다. 사람이 알려 준 층, 메뉴, 캐릭터, 엔딩과 숨은 모드는 전체 목록이 설명해야 할 기준이 됐다. 에이전트는 그 기준에서 파일과 소비자를 역으로 찾아 분모를 만들고, 빠진 영역과 아직 분류하지 못한 영역을 따로 남겼다.

원본과 빌드: 작업 폴더의 성공을 다시 만들 수 있는 결과로

Original and build: from a working folder that happens to run to a result that can be remade

조사 중에는 짧은 스크립트와 손으로 고친 산출물이 빠르게 답을 줄 때가 있다. 문제는 그 결과가 최종 빌드의 입력으로 남을 때다. 같은 기능을 두 코드가 따로 만들고, 어제 생성한 파일을 오늘 다시 패치하면 현재 소스만으로 화면의 출처를 설명할 수 없다. 여러 프로젝트의 프롬프트는 특정 언어를 선호한다는 말보다 최종 결과를 만드는 경로를 하나로 닫으라는 요구로 바뀌었다.

단발성 조사는 주 빌드의 두 번째 구현이 될 수 없었다

세가 새턴 마도물어에서는 폰트와 시퀀스 수정이 여러 도구에 흩어지자, 코드베이스로 같은 실험을 계속 실행할 수 있게 하라는 요구가 나왔다.

메가드라이브판에서는 어느 구현이 기준인지 더 짧게 못박았다.

최종 ROM을 만드는 구현이 이미 Rust 쪽에 있었으므로 이를 기준으로 삼았다. Git 이력에는 TTF와 번역에서 ROM을 만드는 빌드(1b0e2c3), 파생 데이터를 다시 만드는 init 명령(c3a17fa), 뒤이어 레거시 스크립트를 제거한 기록(bafeba4)이 이어진다. 조사용 스크립트는 쓸 수 있어도 그 스크립트만 아는 변경을 배포 산출물에 남기지는 않았다.

참고 패치는 단서로 남기고 최종 입력에서 뺐다

게임기어판의 초기 한국어 빌드는 영어 패치 ROM을 먼저 요구했다. 영어판에서 훅과 여유 공간을 찾기는 쉬웠지만, 일본 원본에서 영어판을 거쳐 한국어판으로 온 변경 중 무엇이 필요한지 설명하기 어려웠다.

다음 날 Git 이력에는 일본판 원본에서 한국어 렌더러, 재배치 대사와 UI 그래픽을 만드는 변경이 차례로 들어왔다. 영어 패치는 버리지 않고 변경 위치와 구현 후보를 찾는 비교 자료로 남겼다. 달라진 점은 사용자가 준비해야 할 빌드 입력이었다. 참고 자료의 산출물을 다시 패치하는 대신, 확인한 일본판 원본과 프로젝트가 소유한 입력만으로 결과를 만들게 됐다.

따로 성공한 기능은 한 산출물에서 다시 만났다

폰트, 대사, 그래픽과 엔딩이 각자 되는 격리 빌드는 서로의 주소와 글리프 공간을 침범하는지 알려 주지 않는다. 슈퍼 나조 뿌요 2에서 사람은 그래서 한 파일을 요구했다.

PCE-CD판에서는 이미 대사, 그래픽, 자막과 크레딧이 따로 진행되고 있었다. 사람은 통합 결과가 왜 없는지부터 물었다.

Git 이력의 431ff52는 번역, 글꼴, 그래픽, 자막, 크레딧과 검사를 한 빌드에 모았고, 33bd4b0은 같은 원본 확인 경로에서 BPS까지 만들게 했다. 7월 18일에는 이 반복 문제가 create-kr-patch에도 반영돼, 완성에 필요한 변경이 하나의 주 빌드에 들어가야 한다는 규칙 d17b119가 추가됐다.

잘 보이는 ROM의 출처도 다시 만들 수 있어야 했다

메가드라이브판에서 화면 문제가 해결된 뒤에는 현재 실행 중인 ROM이 깨끗한 소스에서 나왔는지를 사람이 다시 물었다.

그 뒤 Git 이력에는 지정한 일본판 원본과 깨끗한 커밋에서 ROM과 BPS를 다시 만들고 빌드 근거를 묶은 기록이 이어졌다. 화면이 맞는지와 그 화면을 낸 파일의 출처를 각각 확인했다. 작업 폴더에 우연히 남아 있던 ROM이 잘 돌아가도, 같은 원본과 현재 소스로 다시 만들 수 없다면 다음 수정의 기준으로 쓸 수 없다.

사람의 문장 검수는 기술 수용량을 확인한 뒤 본격화했다

원본 기반 통합 빌드는 사람의 검수를 뒤로 미루기 위한 핑계가 아니었다. 이미 다듬은 문장을 글리프 공급이나 디스크 배치 실패 때문에 버리지 않도록 순서를 잡는 일이었다. PS1판에서는 이를 아주 짧게 지시했다.

PC-98판에서도 앞 장에 인용한 “사람 검수는 글리프와 관련된 확신이 있어야 진행될 수 있다”는 질문이 같은 역할을 했다. 초벌 전체는 글리프 수와 최대 문장 폭을 재는 기술 입력으로 먼저 쓸 수 있다. 말투와 의미를 다듬는 전수 검수는 그 수요가 실제 빌드와 주요 소비 경로에서 받아들여지는지 확인한 뒤 진행한다. 이름, 용어와 문맥처럼 기술 설계 전에 결정해야 할 사항은 먼저 정한다. 기술 설계 전에 필요한 사람 판단까지 미루지는 않았다.

그래서 “됐다”는 말도 하나로 쓰기 어려워졌다.

번역 작업: 원문을 지키는 자동화와 문장을 고르는 판단을 나누다

Translation: separating automation that protects the source from judgement that picks the words

번역 파일은 처음부터 원문 위치와 제어코드를 기억해야 했다

세가 새턴 마도물어의 텍스트 추출 프롬프트에는 이후 공용 스킬로 옮겨 간 요소가 이미 들어 있다.

단순 순번 대신 원본 파일과 위치를 가리키는 식별자를 두고, 원문 바이트와 제어코드를 번역문과 분리했다. 나중에 새 문자열이 발견되더라도 기존 번역의 신원을 잃지 않고, 알 수 없는 토큰을 한국어 문장처럼 바꾸지 않기 위한 구조였다.

번역 검수는 원문·현재 번역·이유·제안을 함께 보게 했다

슈퍼패미컴판의 전수 검수에서는 규칙으로 문장을 일괄 변경하지 말고, 항목별로 판단할 자료를 남기도록 했다.

이 구조에서 에이전트는 대량으로 후보를 찾고 제안을 만들 수 있다. 사람은 원문과 장면을 읽고 제안을 채택하거나 다시 쓴다. 문장 상태가 raw → in progress → needs review → needs human review → complete로 나뉜 것도 기계 작업과 사람의 승인을 한 상태로 뭉개지 않기 위해서였다.

화면 제약은 문장을 몰래 버리는 이유가 되지 않았다

새턴 와쿠와쿠판에서는 넘치는 문장을 자동으로 자르거나 줄바꿈을 다시 배치하면 빌드는 쉽게 통과할 수 있었다. 사람은 조용히 뜻이 사라지는 기본값을 막았다.

드림캐스트판에서는 공유 타일 충돌을 이유로 번역을 줄이는 타협보다 글리프 공급 구조를 더 조사하게 했다.

이 원칙은 문장을 절대로 고치지 말라는 뜻이 아니다. 창을 넓히거나 페이지를 나누고 글리프를 늘리는 기술적 선택을 먼저 조사한 뒤, 의미나 말투를 줄여야 할 때는 사람이 그 손실을 보고 결정하라는 뜻으로 정리됐다.

자동화의 경계는 검출과 수정 사이에 놓였다

드림캐스트판의 번역 검사 프롬프트는 이유와 제안은 출력하되 자동으로 원문을 덮지 못하게 했다.

PS1판에서 잘못 추출된 경계를 자동 수정으로 덮으려는 흐름이 생겼을 때도 같은 태도가 반복됐다.

7월에는 이 판단이 스킬에 들어갈 문장인지 직접 확인했다.

8월의 새턴 와쿠와쿠판 전수 검토에서도 같은 구분이 실제 작업 지시로 돌아왔다.

사람이 오탈자 후보를 손으로 전수 검색할 필요는 없다. 자동화가 전체 범위를 검사하고 원문 위치, 제어코드, 폭과 누락을 지키게 한 뒤, 사람은 실제 문장과 화면에 손실이 생기는 선택을 맡는다.

글꼴과 의성어는 실제 장면에 맞춰 골랐다

Fonts and onomatopoeia were chosen to fit the actual scene

문장이 자연스럽고 글자가 선명해도 화면 전체는 어색할 수 있다. 제목과 본문이 같은 무게로 보이거나, 원본에서 움직이던 의성어가 반듯한 메뉴 글자처럼 서거나, 장식에 불과한 글자까지 바꾸면서 여백이 무너지기도 했다. 사람은 어느 화면인지, 무슨 동작인지, 원본에서 글자가 몇 칸을 쓰고 어떤 방향으로 놓였는지를 프롬프트에 적었다. 이 정보는 곧 구현 조건이 됐다.

한 글꼴로 한국어판 전체를 통일하지 않았다

슈퍼 나조 뿌요 2에서는 게임하기 / 데이터 삭제 메뉴의 커서와 기준선이 어긋나 보이자 새 글꼴을 시험했다.

같은 변경이 오버월드의 저장/아이템까지 번지자 사람은 그 화면에는 기존 글꼴을 남기라고 지정했다.

크기와 여백을 조정한 후보도 실제 화면에서 좋아지지 않으면 채택하지 않았다.

최종 구현은 본문, 퍼즐 조건, 모드 선택 제목과 항목, 첫 실행 안내, 저장·불러오기, 옵션 도움말, 효과음 글자와 에디터의 작은 안내문을 서로 다른 프로필로 나눴다. 같은 인상이 필요한 곳은 한 프로필을 함께 쓰고, 타일 크기와 역할이 다른 곳만 독립적으로 조정했다.

세가 새턴 마도물어의 레벨업 글자도 글꼴 견본만 보고 고르지 않았다. 원본 배경 위에서 획이 묻히자 후보에 빠진 요소를 사람이 짚었다.

후보를 다시 만들 때는 12~16픽셀, 윤곽선과 자간을 한꺼번에 비교했다. 실제 배경에서 제목과 본문이 제 역할로 읽히는지를 사람이 골랐고, 코드는 그 선택을 화면별 설정으로 보존했다.

의성어는 읽는 말이면서 움직이는 그림이었다

슈퍼 나조 뿌요 2의 스토리에는 대사 데이터가 아니라 스프라이트로 그린 ガッ과 パチ가 있었다. 첫 장면이 음식을 먹는 동작임을 사람이 알려 주면서 ガッ의 한국어는 음역이 아니라 덥석으로 정해졌다.

パチ는 원본부터 반시계 방향으로 기울어 있었다. 한국어를 넣을 때도 그 동세를 버리지 않았다.

첫 후보는 외곽선 때문에 ㅉ이 뭉쳐 깨진 타일처럼 보였다. 사람은 원본이 두 글자로 읽힌다는 점까지 들어 크기를 다시 지정했다.

구현에서는 덥과 석의 간격을 좁히고, 짝을 키운 뒤 약 30도 기울였다. 원본 오브젝트의 반복도 그대로 두어 화면에서는 짝짝이 된다. 먹는 동작, 두 인물의 박수, 글자의 반복과 기울기라는 장면 정보가 최종 단어와 그래픽 배치를 함께 결정했다.

모든 비한국어 요소를 바꾸지는 않았다

화면에 일본어 코드가 있다고 모두 문장은 아니었다. 세가 새턴 마도물어의 OCR을 시작할 때부터 화살표와 뿌요 모양을 글자 후보에서 분리하라는 설명이 있었다.

슈퍼 나조 뿌요 2의 결과 화면에서는 영문 LEVEL을 이미 읽을 수 있었고, 뒤의 일본어 べつの만 한국어에 걸렸다.

최종 화면도 LEVEL별 HI-SCORE처럼 영문 표시는 유지하고 일본어 세 칸을 별과 공백으로 바꿨다. 드림캐스트판의 규칙 화면에서는 반대 이유로 일본어 장식을 남겼다. 별 그림 위의 한국어가 짧아져 여백이 크게 보였고, 그 글자가 플레이에 필요한 정보를 더 주지도 않았다.

셋의 이유는 달랐다. 첫 사례는 애초에 문자가 아니었고, 둘째는 이미 기능하는 영문과 한국어를 한 화면에서 조합했으며, 셋째는 장식 교체가 정보는 늘리지 않고 구도만 해쳤다. 사람은 화면 요소가 전달하는 정보와 역할을 먼저 분류한 뒤 무엇을 번역할지 정했다.

재사용: 결과물을 가져오기보다 검증할 방법을 가져오다

Reuse: taking the way to verify rather than the result

선행 프로젝트는 강한 단서였지만 대상 게임의 사실은 아니었다

2월 슈퍼 나조 뿌요 2를 조사할 때 같은 제작사의 프로젝트 코드를 참고하되, 그 구조에 맞춰 결론을 끼워 넣지 말라는 프롬프트가 먼저 나왔다.

이 원칙은 선행 작업을 버리라는 말과 다르다. 어디를 먼저 볼지, 어떤 실패를 예상할지, 어떤 검사를 빌드에 둘지는 재사용할 수 있다. 주소, 빈 공간, 인코딩 폭, 글리프 수와 소비 경로는 새 원본에서 다시 확인해야 한다.

영어 패치의 레이아웃도 한국어의 정답은 아니었다

게임기어판은 영어 패치에서 많은 구조를 찾았지만, 영어에 맞춘 좁은 줄 간격이 한국어에는 맞지 않았다.

선행 패치는 주소와 변경 지점을 찾는 비교 자료로 유용했다. 다만 선행 패치가 바꾼 화면 밀도, 폰트 높이, 줄 수와 커서 위치까지 물려받으면 한국어에는 새 문제가 될 수 있었다. 이 경험은 “영어판을 베이스로 쓰는가”보다 “영어판에서 무엇을 빌렸고, 일본 원본과 어떤 차이를 다시 검사했는가”를 묻게 했다.

공용 방법도 특정 도구 이름에 묶지 않았다

스킬을 다듬을 때는 emucap이나 특정 에뮬레이터를 반드시 쓰라는 식으로 일반화하지 않도록 했다.

필요한 것은 메모리 읽기, 상태 재현, 쓰기 추적 같은 기능과 거기서 얻은 증거다. 지금 환경에서 emucap이 그 능력을 가장 잘 제공할 수는 있어도, 방법론 자체가 한 도구의 명령어나 경로를 정답으로 삼으면 다른 플랫폼에서 바로 낡는다.

이후 스킬의 플랫폼 문서가 실제 프로젝트와 어긋날 때도 사례를 그대로 공용 규칙으로 덧붙이지 않았다. PC-98의 HDM 크기, 새턴의 VDP1·VDP2 텍스트 경로, 드림캐스트의 PVR과 아카이브 내 raw 폰트처럼 대상마다 갈린 사실은 적용 조건과 근거를 붙였다. 한 게임에서 확인한 수치는 사례로 남기고, 여러 대상에 적용할 수 있는 판정 질문만 공용 전략으로 올렸다.

스킬: 프로젝트에서 반복된 철학이 공용 원칙이 되기까지

Skill: how philosophy repeated across projects became a shared principle

스킬이 생기기 전부터 원칙은 프롬프트에 있었다

create-kr-patch 스킬의 첫 패키징은 Git 기록상 6월 17일이다. 그러나 스킬의 내용이 그날 새로 생긴 것은 아니다. 앞선 프로젝트 프롬프트에 흩어져 있던 판단이 먼저 있었다.

스킬은 에이전트가 실수하니 나중에 붙인 벌점표가 아니다. 사람이 여러 게임에서 반복해 온 작업 철학을 다른 프로젝트에서도 다시 쓰도록 정리했다.

중심 철학은 사람을 반복 조작에서 빼고 판단에 남기는 것이었다

6월 29일 프롬프트는 스킬과 emucap이 공유할 방향을 직접 설명한다.

여기서 “사람의 개입 최소화”는 사람의 취향과 게임 지식을 제거한다는 뜻이 아니다. 파일을 하나씩 열고, 디버거 값을 옮기고, 이미 정해진 오류를 손으로 찾는 반복을 줄이자는 뜻이다. 에이전트가 상황에 맞는 도구를 고르고 조사하되, 플레이 경험을 바꾸는 선택은 사람이 할 수 있게 증거와 후보를 내놓는 방향이다.

스킬은 모든 작업 순서를 고정하지 않도록 계속 다듬었다

7월에는 무엇을 공용 규칙으로 강제할지 범위를 좁혔다.

이 질문에 따라 특정 언어, 라이브러리, 에뮬레이터나 고정된 조사 순서보다 조건부 실패 기준이 남았다. 예를 들어 원본과 다른 값을 기대하지 않은 곳에 썼거나, 필요한 문자가 매핑되지 않았거나, 제어코드가 바뀌었다면 빌드는 실패해야 한다. 어느 디스어셈블러를 쓰고 저장 경로부터 볼지 소비 경로부터 볼지는 대상의 증거에 따라 에이전트가 고른다.

실제 프로젝트의 반례가 스킬을 계속 고쳤다

스킬이 생긴 뒤에도 프로젝트는 스킬을 적용받기만 하지 않았다. 새 게임에서 맞지 않는 부분을 다시 스킬 쪽으로 돌려보냈다.

• 게임기어판은 영어 패치의 줄 간격을 그대로 물려받는 위험을 드러냈다.
• PCE-CD판은 선행 도구의 2048바이트 오프셋과 raw 2352바이트 섹터의 차이, 원본 라운드트립의 필요를 보여 줬다.
• PC-98판은 디스크 저장 공간, 인코딩 공간과 런타임 외자 슬롯이 서로 다른 상한임을 보여 줬다.
• 다른 새턴 타이틀에서는 한 프로젝트의 VDP2 텍스트 방식이 VDP1 스프라이트 텍스트에 그대로 적용되지 않았다.
• 다른 드림캐스트 타이틀에서는 뿌요뿌욘의 PVR 사례와 달리, 게임 아카이브 속 raw 글리프 배열이 본문 렌더 경로였다.

이 사례들은 “게임기어에서는 항상 이렇게 한다” 같은 새 명령으로 들어가지 않았다. 먼저 어떤 대상에서 확인됐는지와 다른 대상에 옮길 수 없는 범위를 적고, 공통 문서에는 렌더 경로와 저장·적재·소비를 따로 확인하라는 질문만 남겼다.

스킬도 적용 결과를 보고 다시 범위를 고쳤다

7월에는 자동화가 선택까지 대신하지 않게 하는 원칙을 더 분명히 했다.

8월에는 앞의 전체 범위 장에서 본 1,100개 파일 문제가 새 반례가 됐다. “런타임 증거가 중요하다”를 “모든 파일을 한 번씩 플레이한다”로 읽자 오히려 전체 구조를 보지 못했다. 이에 따라 스킬은 전체 목록을 정적으로 닫고, 같은 소비 경로는 대표·경계 사례로 실행하며, 예외만 따로 확인하도록 다시 고쳐졌다.

스킬은 다음과 같은 순환을 거쳐 바뀌었다.

1. 게임 프로젝트에서 같은 판단이 반복된다.
2. 여러 대상에도 필요한 조건만 공용 스킬로 옮긴다.
3. 새 프로젝트가 과한 일반화나 빠진 경계를 드러낸다.
4. 사례의 적용 범위를 남기고 공용 원칙을 다시 좁히거나 보강한다.

스킬을 읽는 것만으로 대상 게임의 답이 나오지는 않는다. 스킬은 사람이 매번 되풀이한 금지선과 증거 조건을 잊지 않게 한다. 프로젝트별 프롬프트는 그 안에 현재 게임의 장면, 원본, 난도와 취향을 채운다.

같은 시기에도 여러 흐름이 겹쳐 움직였다

Several threads moved at once, even within the same months

앞의 흐름을 날짜순으로 다시 놓으면 한 단계씩 차례로 발전한 이야기가 아니라는 점이 더 분명하다. 어떤 프로젝트는 쓰기 안전성이 먼저 필요했고, 다른 프로젝트는 전체 번역 수요나 게임의 진행 순서를 먼저 알아야 했다.

이 표의 행은 성숙도 등급이 아니다. 2월의 Expected Write가 7월의 한 명령 빌드보다 덜 발전한 방법인 것도 아니고, 6월의 emucap이 수동 HITL을 쓸모없게 만든 것도 아니다. 서로 다른 문제를 푸는 장치가 필요한 시점에 생겼고, 뒤의 프로젝트가 앞의 원칙을 새 조건에서 다시 시험했다.

시기를 가로질러 공통으로 바뀐 것은 사람에게 묻는 내용이었다. 처음에는 실행 결과와 주소를 많이 받았다. 점차 사람이 아는 작품의 전체 구조, 반드시 유지할 플레이 경험, 번역에서 받아들일 수 있는 손실과 정상 장면을 먼저 받고, 주소 탐색·전체 파일 검사·재현 빌드는 도구와 에이전트가 맡게 됐다.

이 변화 속에서 사람이 한 일

What the person did through these changes

대화를 통틀어 사람의 역할을 한두 개 직함으로 고정하기는 어렵다. 기술 문제가 달라질 때마다 개입하는 지점도 달랐다. 다만 사람이 계속 붙잡은 것은 직접 코드를 얼마나 쓰느냐보다 “무엇을 게임으로 받아들일 것인가”였다.

작품의 실제 크기와 빠진 장면을 알려 줬다

자동 추출이 5층까지만 보였을 때 이 게임은 11층과 지하 4층까지 있다고 알려 줬고, PC-98판에서 스토리 460개는 너무 적다고 지적했다. 두 번째 실패에서만 나오는 힌트, 특정 주문, 캐릭터 선택 뒤 던전처럼 자동화가 모르는 게임 상태도 사람이 제공했다. 이런 정보는 주소 정답이 아니라 조사해야 할 모집단과 소비 경로를 바꾸는 입력이었다.

게임 지식은 번역표 바깥의 정답지였다

자연스러운 문장이 항상 맞는 문장은 아니었다. 메가드라이브판에서는 영어판이 비슷한 절임을 한 단어로 뭉개도, 실제 게임에는 회복량이 다른 두 아이템이 따로 있었다.

PCE-CD판에서는 화면의 번역보다 일본어 음성이 먼저 오역을 드러냈다.

반대로 슈퍼 나조 뿌요 2의 왼오오오왼은 문장처럼 읽으면 지나친 축약 같지만 실제 퍼즐 답과 맞았다.

세 프롬프트가 가져온 근거는 각각 아이템 효과, 들리는 음성과 퍼즐 규칙이었다. 사람은 마음에 드는 표현을 고른 데 그치지 않고, 번역 파일 밖에서 그 문장이 맞는지 판정할 자료를 제공했다. 에이전트는 그 지점을 원문 위치와 같은 항목의 다른 출현 장면으로 넓혀 확인했다. 이때 사람의 역할은 모든 문장을 직접 쓰는 것이 아니라, 그럴듯한 오답과 작품 안에서 실제로 성립하는 말을 가르는 데 있었다.

기술적 우회가 플레이 경험을 바꾸면 멈췄다

캐릭터별 ROM 세 개가 각각 실행돼도 한 게임으로 배포할 수 없다고 판단했고, 공간이 부족하다는 이유로 번역을 줄이기 전에 글리프 공급과 페이지 구조를 더 조사하게 했다. 사람이 한 일은 어려운 구현을 대신 푸는 것이 아니라, 기술적으로 편한 결과가 애초 목표를 바꾸는 순간을 알아보는 것이었다.

반복되는 실패에서 공통 금지선을 뽑았다

한 번의 충돌을 고치는 데서 멈추지 않고 모든 쓰기를 추적하게 했고, 예상한 원본에만 쓰도록 Expected Write를 붙였다. 수동 HITL이 반복되자 관찰 도구를 만들었고, 한 글자 PoC가 반복되자 가장 어려운 완성 조건과 통합 빌드를 스킬에 넣었다. 사람의 철학이 스킬로 갔다는 것은 이런 식으로 국소 수정이 공용 경계로 바뀐 과정을 뜻한다.

문장과 화면의 선택은 끝까지 사람이 했다

자동화는 누락, 폭, 제어코드, 원문 불일치와 수정 후보를 전체에서 찾았다. 어떤 말투가 인물에게 맞는지, 뜻을 줄일지 페이지를 늘릴지, 한글 그래픽이 원작 화면과 어울리는지는 사람이 원문과 실제 장면을 보고 정했다. 메뉴마다 같은 글꼴을 쓸지, 의성어를 어느 방향으로 기울일지, 읽을 수 있는 영문이나 장식 글자를 그대로 둘지도 이 판단에 포함됐다. 가능한 답이 여러 개일 때 플레이 경험을 고르는 일은 끝까지 사람에게 남았다.

반복 작업은 사람에게 남기지 않았다

사람이 1,100개 파일을 하나씩 실행하거나, 매번 메모리 값을 답변 파일에 옮기거나, 어떤 주소를 늘려야 하는지 대신 역공학하는 것은 목표가 아니었다. 그런 반복은 추출기, 빌드 검사, typed ISA, Expected Write와 emucap으로 옮겼다. 사람에게 질문할 때는 기술 조사를 대신해 달라고 하기보다 다음처럼 선택의 근거가 필요한 지점을 묻는 편이 맞았다.

다음 프로젝트에서 쓸 수 있는 프롬프트의 형태

Prompt shapes for the next project

이 기록에서 유용한 프롬프트는 구현 방법을 미리 단정한 문장보다, 사람이 알고 있는 게임의 조건과 자동화가 증명해야 할 범위를 함께 주는 문장이었다. 상황별로 압축하면 다음과 같다.

이 문장들은 그대로 복사하는 주문보다 빈칸을 채우는 골격에 가깝다. 사람이 게임의 범위와 선택 기준을 주면, 에이전트가 거기에 맞는 조사와 도구를 고른다. 2월부터 8월까지 반복 조작과 기술적 전수 작업은 시스템으로 옮겨 갔고, 사람만이 제공할 수 있는 게임 지식과 선택 기준은 프롬프트에 더 구체적으로 남았다.