고작 16MHz로 심시티를 돌렸던 1989년 개발자들의 천재적인 꼼수

요약 최신 PC는 저렴한 모델조차 최소 4코어에 기가헤르츠(GHz) 단위의 연산 속도를 자랑하지만, 과거에는 지금보다 1,000배 이상 느린 사양에서도 온전한 게임이 구동되곤 했습니다. 레트로 게임의 기술적 성취를 논할 때 보통 '둠(Doom)'이나 '퀘이크(Quake)' 같은 3D 액션 게임의 그래픽을 먼저 떠올리지만, 연산량이 엄청난 도시 건설 시뮬레이션 장르의 고전적인 성취도 그에 못지않게 놀랍습니다. 1989년 출시된 오리지널 '심시티(SimCity)'의 권장 사양에는 당시 16MHz 클럭으로 작동하던 인텔 386SX CPU가 적혀 있었습니다. 현대에는 단순한 방치형 게임도 수 GHz의 성능을 요구하는 마당에, 고작 16MHz로 도시 전체의 경제와 인프라를 시뮬레이션할 수 있었던 비결은 무엇이었을까요? 2008년 '마이크로폴리스(Micropolis)'라는 이름으로 GPL 라이선스 공개된 심시티 오픈소스 코드를 뜯어보면 그 핵심 비결이 드러납니다. 도시 시뮬레이션의 핵심인 s_sim.c 파일의 Simulate() 함수는 매 프레임마다 호출되어 범죄 스캔, 화재 분석, 세금 징수 등의 하위 시스템을 갱신합니다. 하지만 1989년 당시의 빈약한 CPU로 이 모든 연산을 매 프레임마다 전부 처리하는 것은 불가능했습니다. 개발진이 택한 해결책은 간단했습니다. 바로 '모든 함수를 매 프레임마다 호출하지 않는 것'이었습니다. 심시티 코드는 deltaTime 대신 0부터 15까지 반복 순환하는 'mod16' 매개변수를 활용했습니다. 이 숫자에 따라 특정 프레임마다 시뮬레이션의 일부 작업만 번갈아 가며 실행하도록 분산 처리한 것입니다. 이 방식 덕분에 연산 부담은 획기적으로 줄어들었고, 플레이어 조작에 반응하는 데 최악의 경우 15프레임 정도의 지연이 발생하지만, 빠른 반응이 필수적인 슈팅 게임과 달리 도시 시뮬레이션에서는 이러한 시간차가 오히려 자연스러운 현실감으로 작용했습니다. 이처럼 작업을 여러 프레임에 나누어 분산 처리하는 기법은 현대 게임 개발에서도 널리 쓰이고 있습니다. 레이싱 게임 '아세토 코르사'가 반사 표현용 큐브맵의 6개 면을 한 번에 다 갱신하지 않고 품질 설정에 따라 프레임당 일부만 갱신하거나, 언리얼 엔진의 '루멘(Lumen)'이 매 프레임 모든 조명을 다시 계산하지 않는 것 역시 같은 원리입니다. 고전 명작이 남긴 영리한 최적화 발상은 오늘날의 개발자들에게도 여전히 큰 영감을 주고 있습니다.