25MHz CPU에서 교통 시뮬레이션을 돌린 피자 타이쿤의 기발한 트릭

1990년대 게임이 알려주는 최적화의 정수

피자 타이쿤(Pizza Tycoon, 유럽에서는 Pizza Connection)은 1994년에 출시된 경영 시뮬레이션 게임이에요. 플레이어가 피자 가게를 운영하면서 도시 전체의 경제 시스템과 상호작용하는 게임인데요, 이 게임에는 놀라운 기술적 디테일이 숨어 있어요. 바로 도시 안에서 차량과 보행자가 실제로 도로를 따라 이동하는 교통 시뮬레이션을 25MHz짜리 CPU 위에서 구현했다는 거예요. 요즘 기준으로 보면 스마트워치보다도 느린 프로세서인데, 어떻게 이게 가능했을까요?

핵심 아이디어: 전부 시뮬레이션하지 않는다

교통 시뮬레이션이라고 하면 보통 모든 차량의 위치를 매 프레임마다 계산하는 걸 떠올리잖아요. 하지만 25MHz CPU에서 그렇게 하면 게임이 슬라이드쇼가 돼버려요. 피자 타이쿤 개발팀이 선택한 전략은 "보이는 것만 시뮬레이션한다"는 거였어요.

이게 뭐냐면, 화면에 보이지 않는 차량은 실제로 이동 계산을 하지 않아요. 대신 차량이 화면 밖으로 나가면 그냥 사라지고, 화면 안으로 들어올 때 도로 입구에서 새로 생성되는 방식이에요. 플레이어 입장에서는 차들이 계속 도로를 달리고 있는 것처럼 보이지만, 실제로는 "무대 위에 있는 배우"만 연기하고 나머지는 대기실에서 쉬고 있는 거죠. 이런 기법을 요즘 게임 개발에서는 "컬링(culling)"이라고 부르는데, 보이지 않는 것은 처리하지 않는 최적화의 기본 중의 기본이에요.

도로 네트워크와 경로 탐색

도시의 도로는 노드(교차로)와 엣지(도로 구간)로 이루어진 그래프 구조로 표현돼요. 이건 자료구조 시간에 배우는 그래프(Graph)와 완전히 같은 개념이에요. 차량이 A 지점에서 B 지점으로 이동할 때 최단 경로를 찾아야 하는데, 여기서 재미있는 점은 매번 다익스트라(Dijkstra) 같은 경로 탐색 알고리즘을 돌리지 않았다는 거예요.

대신 차량에게는 아주 단순한 규칙만 부여했어요. 교차로에 도착하면 갈 수 있는 방향 중 하나를 랜덤하게(혹은 가중치를 두고) 선택하는 거예요. 목적지를 정해놓고 최적 경로를 계산하는 게 아니라, 그냥 "돌아다니는 것처럼 보이게" 만든 거죠. 이게 90년대 하드웨어에서 할 수 있는 현실적인 타협이었어요. 플레이어는 차들이 목적지를 향해 가고 있다고 자연스럽게 가정하니까, 실제로는 랜덤하게 움직여도 큰 위화감이 없었거든요.

충돌 처리: 간단하지만 효과적인 방법

차량끼리 겹치면 안 되니까 충돌 처리도 필요한데, 이것도 아주 단순하게 해결했어요. 각 도로 구간에 "슬롯" 개념을 도입해서, 한 슬롯에는 한 대의 차량만 들어갈 수 있게 한 거예요. 앞 슬롯이 차 있으면 뒤 차는 그냥 멈추는 거죠. 물리 엔진 같은 복잡한 계산 없이도 자연스러운 교통 흐름이 만들어지는 거예요. 이건 마치 배열의 각 인덱스에 하나의 값만 넣을 수 있는 것과 같은 원리예요. 자료구조 하나로 물리 시뮬레이션을 대체한 셈이죠.

신호등도 있었는데, 이것도 단순한 타이머 기반이에요. 일정 프레임마다 빨강-초록이 토글되고, 빨간불이면 교차로 진입 슬롯을 막아버리는 거예요. 복잡한 교통 신호 로직 없이 타이머 하나로 꽤 그럴듯한 도시 교통 흐름을 만들어낸 거죠.

현대 게임 개발에도 통하는 교훈

"하드웨어가 좋아졌으니까 이런 트릭은 필요 없는 거 아니야?"라고 생각할 수 있는데, 전혀 그렇지 않아요. 현대 오픈월드 게임에서도 이런 최적화 기법은 핵심이거든요. GTA 시리즈나 시티즈: 스카이라인 같은 게임도 화면 밖 차량은 단순화된 시뮬레이션으로 처리하고, LOD(Level of Detail) 시스템으로 먼 곳의 오브젝트는 대충 그려요. 피자 타이쿤이 1994년에 쓴 기법의 정신이 30년이 지난 지금도 똑같이 적용되고 있는 거예요.

모바일 게임 개발에서는 이런 사고방식이 더더욱 중요해요. 스마트폰 CPU와 배터리 제약 안에서 부드러운 게임플레이를 제공하려면, "안 보이는 건 계산하지 않는다"는 원칙이 생존 전략이거든요.

한국 개발자에게 주는 시사점

이 사례는 게임 개발자뿐 아니라 모든 소프트웨어 엔지니어에게 의미가 있어요. 최적화의 핵심은 "더 빠른 알고리즘을 찾는 것"이 아니라 "애초에 안 해도 되는 일을 안 하는 것"이거든요. 백엔드에서 불필요한 DB 쿼리를 줄이거나, 프론트엔드에서 뷰포트 밖의 컴포넌트를 렌더링하지 않는 것(가상 스크롤, lazy loading)도 같은 철학이에요.

또 하나 배울 점은, 완벽한 시뮬레이션보다 "충분히 그럴듯한" 근사치가 실용적일 때가 많다는 거예요. 머신러닝 추론 최적화에서 양자화(quantization)를 쓰거나, 실시간 시스템에서 근사 알고리즘을 쓰는 것도 같은 맥락이죠. "정확하지 않아도 사용자가 차이를 느끼지 못하면 된다"는 실용주의가 25MHz CPU 위에서 빛을 발했던 거예요.