할로윈이 다가온다: 6일 만에 1982년 Atari 게임을 명세서, 리마스터, NES 및 SNES 게임으로 '바이브코딩'하기

내 아타리 2600 Haunted House 리마스터 작업의 '바이브코딩' 측면을 정리해 본다. 어떤 툴을 썼고, 작업이 어떻게 진행됐는지에 대한 이야기다. 여기서 진짜 흥미로운 건 픽셀 따위가 아니라, LLM이 4KB짜리 ROM을 다른 기기에서도 돌아갈 수 있는 '명세서'로 탈바꿈시켰다는 점이다.

사용 툴. 주로 Claude Opus 5.5(마지막 며칠은 Fable 5.1)를 쓴 Claude Code. 에뮬레이션은 Stella, 리마스터링은 Python과 numpy, NES는 ca65, SNES는 C와 PVSnesLib, 검증용으로 FCEUmm과 snes9x 코어, 브라우저 버전은 Emscripten과 Pyodide, 빌드와 페이지 호스팅은 GitHub Actions를 썼다. 난 코드를 직접 짠 게 아니라, 감독하고 플레이하면서 맘에 드는 거랑 아닌 걸 골라냈을 뿐이다.

1단계: 게임을 바꾸지 말고 읽어라. 리마스터 버전은 에뮬레이터에서 원본 ROM을 수정 없이 돌린다. 그리고 매 프레임마다 2600의 128바이트 RAM을 읽어서 NES나 SNES 게임으로 화면을 다시 그린다. 이게 가능하려면 각 바이트가 뭘 의미하는지 다 알아야 한다. 시작점은 Brandon Roberts가 주석을 달아둔 디스어셈블리였는데, 거기엔 RAM 주소 13개만 이름이 붙어 있었다. Claude는 실험을 통해 나머지를 다 매핑했다. 프레임 사이에 바이트를 찔러보고, 게임이 어떻게 반응하는지 보고, 그 읽기 작업이 맞다는 걸 증명하는 체크 코드를 짰다.

2단계: 게임 전체를 블랙박스로 만들어라. Claude는 RAM 맵에서 멈추지 않고 게임을 Python 모델로 다시 짰다. Haunted House 한 프레임을 게임 순서 그대로 약 850줄로 구현했고, 몬스터랑 사운드 모델도 따로 만들었다. 테스트는 봇이 9가지 변형을 다 플레이하게 하면서 실제 게임 옆에서 모델을 같이 돌리는 방식이다. 매 프레임마다 모델에 실제 RAM 값을 던져주면, 모델은 게임 상태의 모든 바이트를 똑같이 뱉어내야 한다. 449,945 프레임 동안 완벽하게 해냈다. 몬스터 모델만 해도 30,000 프레임 넘게 검증했고, 9개 게임 규칙은 117개의 장면 체크로 확인했다. 체크가 제대로 작동하는지 확인하려고 일부러 규칙을 하나씩 깨뜨려 봤는데, 16개 중 14개는 즉시 잡아냈고 나머지 2개는 더 긴 실행 시간이 필요하거나 게임 플레이 중에 발생할 수 없는 상황이었다. 이 과정에서 원본 게임의 버그도 하나 찾아냈다. 몬스터 그리는 코드가 서브루틴에서 리턴을 안 하고 밖으로 튀어 나가서 스택이 RAM을 침범하고, 결국 6502가 조이스틱 바이트를 명령어로 실행해 버리는 현상이었다.

3단계: 명세서를 쓰고, 그걸 바탕으로 빌드해라. 모델에서 나온 게임 명세서는 약 650줄짜리 평문인데, 모든 규칙은 어떻게 증명되고 검증됐는지 표시해 뒀다. 포팅 규칙은 간단했다. 아타리 코드는 절대 보지 말고, 오직 명세서와 모델만 보고 짤 것. NES 게임은 MMC3 카트리지용 6502 어셈블리 약 9,000줄, SNES 게임은 C 언어 약 4,700줄이다. 각각 에뮬레이터에서 Python 모델과 똑같은 입력을 넣고 매 프레임 상태를 비교하는 체크 코드가 있다. NES 체크는 프레임이 밀려도 실패 처리된다. 원본 저택을 그대로 쓴 '충실한' 비공개 빌드는 엔진이 2600이랑 똑같이 돌아간다는 걸 증명한다. 공개용 빌드에는 더 커진 저택, 지하실, 4개 층, 그리고 우리가 직접 만든 아트와 음악이 들어갔다.