오래된 게임을 뜯어보는 일은 단순한 추억팔이가 아니다. 제약이 심했던 하드웨어 위에서 개발자들이 어떤 트릭으로 풍부한 화면과 '살아 있는 느낌'을 만들어냈는지를 보여주는 교과서이기 때문이다. 한 개발자가 자신이 어릴 적 좋아했던 2001년작 경영 시뮬레이션 'Fast Food Tycoon 2'(유럽명 Pizza Connection 2)를 역공학으로 해부한 기록은, 리버스 엔지니어링 방법론과 구형 2D 렌더링 설계를 동시에 들여다볼 수 있는 흥미로운 사례다.
AI 에이전트를 리버스 엔지니어링 도구로 쓰다
주목할 점은 해부 과정 자체다. 작성자는 Ghidra로 fastfood2.exe의 4,046개 함수를 약 9.5MB 분량의 C 유사 코드(함수 주소, 필드 오프셋, 상수, 호출 관계 포함)로 디컴파일한 뒤, 이를 SQLite에 적재하고 관련 함수를 긴 텍스트를 읽지 않고도 찾을 수 있도록 스크립트로 감쌌다. 그리고 GPT-6.1 Sol Medium을 돌리는 에이전트 루프로 분석을 자동화했다.
핵심 기법은 정적 분석과 동적 분석의 결합이다. 윈도우의 ReadProcessMemory API로 실행 중인 게임 메모리를 읽어 화면에 보이는 값(현금, 카메라 위치, 선택된 건물 등)과 대조하고, 해당 값을 바꾸는 함수를 디컴파일 코드에서 역으로 조회했다. 조작 측면에서는 실행 파일을 디스크에서 수정하지 않은 채 윈도우 메시지 핸들러를 패치해 게임의 UI 스레드에 명령을 주입했고, 크롤러로 인터페이스를 눌러보며 미지의 조작 방법을 발견했다. 메모리 관찰과 코드 역추적, UI 자동화를 묶은 이 구조는 AI 에이전트가 비정형 역공학 작업에서도 실제 레버리지가 된다는 점을 보여준다.
도시 한 장면은 그림 한 장과 수백 개의 스프라이트
렌더링 설계는 지금 봐도 영리하다. 베를린 맵 파일 ber.tga에는 도로와 부지, 브란덴부르크 문의 그림자만 담겨 있고 건물·사람·차량은 없다. 렌더러는 장면을 메모리 버퍼에 그리되, 먼저 사람이 이동했거나 카메라가 움직여 다시 칠해야 할 화면 영역만 계산한다. 이 '더티 리전' 방식 덕분에 최근 0.6초 동안 바뀐 픽셀(자동차, 보행자, 흔들리는 나무 꼭대기, 깜빡이는 간판)만 갱신되고 대부분의 화면은 손대지 않는다. 매 프레임 전체를 다시 그리지 않는 이 최소 갱신 원칙은 오늘날 UI 프레임워크의 부분 리렌더링과 본질적으로 같은 아이디어다.
픽셀마다 16비트 색상값과 별도의 조명 바이트를 들고 다니는 구조도 눈에 띈다. 색과 빛을 끝까지 분리해 두었다가, 최종 단계에서 둘을 합치며 반복 디더 패턴으로 중간 음영을 표현한다. 가려진 사람을 벽 너머로 비치게 하려고 그리기 전에 임시 픽셀값으로 형태를 표시해 두고, 이후 패스에서 몸은 노란 윤곽, 생각 아이콘은 흰 윤곽을 둘러 가시성을 유지하는 등 여러 패스로 겹침 순서를 제어한다.
데이터로 구동되는 낮과 밤
하루의 밝기는 25개의 시간별 값 테이블로 정의된다. 야간 70에서 새벽에 급상승해 주간 251까지 올랐다가 해질 무렵 떨어진다. 가로등은 object ID의 하위 3비트(id & 7)로 8가지 임계값 오프셋을 가져, 소규모 그룹으로 나뉘어 켜진다. 기본 밝기 설정에서 표준 가로등은 대략 18:25~18:30에 켜지고 05:35~05:40에 꺼지며, 빛 웅덩이는 최소 160을 유지해 밤새 보도가 밝다. 피자 가게는 h_pizz_a1.m.spr 조명 마스크를 써서 같은 위치의 기존 빛값과 비교해 더 밝은 쪽을 남기므로, 건물은 어두워져도 창문과 간판은 환하게 빛난다. 하드코딩 대신 테이블과 ID 기반 규칙으로 분위기를 제어한 전형적인 데이터 주도 설계다.
움직이는 모든 것은 스프라이트 시트와 명명된 애니메이션 시퀀스를 담은 .ani 파일에 들어 있다(내부 텍스트 상당수가 개발사 언어인 독일어다). 보행자는 다음 노드와 현재 노드의 위치 부호로 방향 애니메이션을 고르고, 각 시퀀스에 프레임당 이동량이 함께 저장돼 있다. 예컨대 웨이트리스의 gehen4는 매 프레임 (+1.25, 0), gehen3는 (+0.884, +0.442)만큼 움직여 발과 바닥이 어긋나지 않는다. 심부름꾼이 초당 27픽셀로 가장 빠르고 관광객은 16.2, 유명인은 13.8픽셀이다. 실내 식당 뷰는 같은 렌더 과정을 쓰되 실내 조명은 시각과 무관하게 248로 고정되고, 의자 등받이가 카메라를 향할 때 의자·인물·등받이 순으로 그려 앉은 자세를 자연스럽게 표현한다.
디테일은 보이지 않는 곳에 있었다
세부 설계는 '진짜 같은 도시'라는 인상이 어디서 오는지 알려준다. 시민은 생성될 때 일정을 받고 이 일정은 매일 초기화되지 않아, 특정 극장에 배정된 사무직은 계속 그곳으로 돌아온다. 게임이 내부적으로 스스로를 'Pizza3'라 부르는 흔적(도시 설정 파일의 'Init-File für Pizza3-Stadt')도 남아 있다. 가장 인상적인 것은 피자 채점 로직이다. 피자를 24개 구역으로 나눠 토핑 분포의 고름을 보고, 반대편 대칭 조각을 확인하며, 재료 궁합과 고객군별 평가를 따진다. 심지어 재료 무게 기반 표절 검사까지 있어, 경쟁사 레시피를 재배치하는 꼼수는 '비독창적'으로 판정돼 여피·고스·관광객 상대 +30점, 거물 상대 +5점의 맛 점수를 놓친다.
이 모든 정교함에 비해 게임 내 안내는 빈약했고, 대신 약 100쪽짜리 매뉴얼이 동봉됐다고 한다. 실무자 관점에서 이 해부기가 주는 교훈은 분명하다. 최소 갱신, 색과 빛의 분리, ID·테이블 기반의 데이터 주도 규칙 같은 20년 전의 설계 원칙은 여전히 유효하며, AI 에이전트는 문서가 사라진 블랙박스 바이너리를 체계적으로 이해하는 실용적 도구가 될 수 있다는 점이다. 다만 이는 저자 개인이 호기심을 따라 진행한 비공식 분석이라는 한계가 있어, 세부 수치나 동작은 특정 버전과 관찰 환경에 한정된 결과로 받아들이는 편이 안전하다.