99% 어셈블리어로 만든 전설, 롤러코스터 타이쿤의 최적화 비밀

게임개발 · 어셈블리어 · 최적화 · 소프트웨어공학

전설이 된 코드

롤러코스터 타이쿤과 어셈블리어가 만든 최적화의 기적

1999년의 PC에서 수천 명의 손님과 수십 개의 놀이기구를 동시에 굴린 게임. 그리고 그 중심에는 지금 봐도 믿기 어려운 선택, 거의 전부를 저수준 코드로 밀어붙인 개발 방식이 있었습니다. 롤러코스터 타이쿤은 단순한 명작 게임이 아니라, 지금도 개발자들이 최적화와 시스템 설계를 이야기할 때 빠지지 않는 사례입니다.

롤러코스터 타이쿤 · 크리스 소이어 · 어셈블리어 · x86 · 게임 최적화 · OpenRCT2 · 데이터 레이아웃 · 비트시프트 · 1인 개발

핵심만 먼저 보면

• 롤러코스터 타이쿤은 단순한 추억의 게임이 아니라 최적화 설계의 대표 사례로 자주 언급됩니다.
• 크리스 소이어는 당시 하드웨어 한계 속에서 원하는 시뮬레이션을 구현하기 위해 매우 낮은 수준의 제어를 선택했습니다.
• 이 게임의 강점은 “어셈블리어를 썼다”에서 끝나지 않습니다. 데이터 구조, 수식, 길찾기, 군중 처리까지 전부 성능 중심으로 설계됐다는 점이 핵심입니다.
• 반대로 이런 방식은 훗날 이식성과 유지보수성에서 큰 대가를 남겼고, 그래서 OpenRCT2 같은 재구현 프로젝트가 더욱 의미를 가지게 됐습니다.
• 결국 이 사례가 남기는 질문은 하나입니다. 우리는 추상화 아래에서 실제 비용 구조를 얼마나 이해하고 있는가.

목차

1. 왜 롤러코스터 타이쿤은 아직도 전설인가
2. 어셈블리어란 무엇인가
3. 1990년대 하드웨어가 만든 선택
4. 크리스 소이어의 1인 개발 방식
5. 최적화의 황금 표준으로 불리는 이유
6. 예시 어셈블리 소스가 왜 도움이 되는가
7. 성능을 위해 게임 디자인까지 바꾼 사례
8. 어셈블리어의 대가와 OpenRCT2
9. 현대 개발자가 얻을 수 있는 교훈

왜 롤러코스터 타이쿤은 아직도 전설인가

롤러코스터 타이쿤은 단순히 재미있는 테마파크 경영 게임이 아닙니다. 이 게임은 거대한 공원을 보여주면서도 손님들의 이동, 기구의 상태, 수익과 동선, 만족도와 혼잡도 같은 여러 시스템을 동시에 굴립니다. 그런데 놀라운 점은 이 복잡한 구조가 1999년의 PC 환경에서도 상당히 부드럽게 돌아갔다는 것입니다.

 

지금처럼 강력한 CPU와 대용량 메모리, 정교한 컴파일러가 보편적이지 않던 시절에 이 정도 규모의 시뮬레이션을 구현했다는 것만으로도 이미 대단하지만, 이 작품이 더 특별한 이유는 그 구현 방식에 있습니다. 롤러코스터 타이쿤은 “고수준 언어와 대규모 팀”이라는 현대적 방식과는 다른 길을 택했고, 그 결과 지금도 개발자 사이에서 최적화의 전설로 불립니다.

롤러코스터 타이쿤의 진짜 무게감은 단순히 “혼자 만들었다”가 아닙니다. 제약이 심한 시대에, 성능과 설계를 같은 손으로 끝까지 밀어붙였다는 데 있습니다.

어셈블리어란 무엇인가

CPU는 본질적으로 0과 1로 이뤄진 기계어만 이해합니다. 어셈블리어는 그 기계어를 사람이 그나마 읽을 수 있도록 바꿔놓은 가장 낮은 단계의 프로그래밍 언어입니다. 우리가 흔히 사용하는 C, C++, Java, C#, Python 같은 언어가 “무엇을 할지”를 상대적으로 높은 수준에서 표현한다면, 어셈블리어는 어느 레지스터에 무엇을 넣고, 어떤 메모리를 읽고, 어떤 순서로 연산할지까지 매우 세밀하게 지시합니다.

 

쉽게 비유하면 고수준 언어는 이미 만들어진 블록을 조립하는 방식에 가깝고, 어셈블리어는 그 블록의 모양과 내부 구조까지 직접 깎는 일에 가깝습니다. 그래서 성능은 강력하지만, 생산성과 유지보수성은 매우 낮습니다.

어셈블리어를 이해할 때 핵심

• 추상화가 적기 때문에 시스템 비용이 그대로 보입니다.
• 메모리 사용량과 연산 단위에 민감한 최적화가 가능합니다.
• 반면 코드 가독성, 재사용성, 협업 효율은 크게 떨어집니다.

1990년대 하드웨어가 만든 선택

지금 기준으로는 “왜 굳이 그렇게까지?”라는 질문이 자연스럽습니다. 하지만 1990년대 후반 PC 환경은 지금과 완전히 달랐습니다. CPU 성능은 훨씬 낮았고, 메모리도 넉넉하지 않았으며, 오늘날처럼 컴파일러가 광범위한 최적화를 대신해 주는 시대도 아니었습니다.

 

이런 환경에서 수천 명의 손님, 복잡한 기구 상태, 대규모 공원 화면을 동시에 유지하려면 단순히 코드를 잘 짜는 수준을 넘어 무엇을 어떤 형태로 저장하고 계산할지까지 매우 집요하게 설계해야 했습니다. 당시 크리스 소이어에게 저수준 제어는 취향의 문제가 아니라, 원하는 수준의 결과를 내기 위한 현실적인 선택에 가까웠습니다.

구분	고수준 언어 중심 개발	저수준 어셈블리 중심 개발
개발 속도	상대적으로 빠름	매우 느림
성능 통제력	컴파일러 의존	개발자가 직접 제어
메모리 제어	추상화 계층 존재	바이트 단위 설계 가능
이식성	상대적으로 유리	특정 아키텍처에 종속
유지보수성	상대적으로 쉬움	매우 어려움

크리스 소이어의 1인 개발 방식

크리스소이

롤러코스터 타이쿤의 가치가 더 크게 느껴지는 이유는, 이 게임이 단지 특정 언어를 썼기 때문만은 아니라는 점입니다. 크리스 소이어는 게임 디자이너이면서 동시에 핵심 프로그래머 역할을 함께 수행했고, 그래서 “게임이 어떻게 느껴져야 하는가”와 “그걸 어떤 비용으로 구현할 것인가”를 같은 머리에서 통합해 판단할 수 있었습니다.

 

현대의 대규모 개발이 역할 분업과 문서 중심으로 흘러간다면, 그의 방식은 작동하는 구조를 먼저 만들고 그 위에 쌓아 올리는 바텀업 접근에 가까웠습니다. 이 방식은 위험하지만, 성능 최적화와 시스템 일관성을 동시에 잡는 데는 매우 강력합니다.

이 방식이 강력했던 이유

• 게임 디자인과 기술 판단이 분리되지 않았습니다.
• 성능 문제를 발견하면 구조를 즉시 바꿀 수 있었습니다.
• 결국 “재미”와 “속도”를 같은 관점에서 설계할 수 있었습니다.

최적화의 황금 표준으로 불리는 이유

1. 값의 크기에 따라 자료형을 더 잘게 나눴다

최신 개발에서는 그냥 넉넉한 자료형을 쓰는 일이 흔하지만, 롤러코스터 타이쿤은 값의 범위에 맞춰 필요한 크기만 사용하는 식의 세밀한 선택이 보입니다. 전체 공원 가치처럼 큰 값은 더 크게, 매점 가격처럼 범위가 작은 값은 더 작게 다루는 식입니다. 이런 선택은 지금 보면 소소해 보일 수 있지만, 수많은 값이 동시에 움직이는 시뮬레이션에서는 누적 효과가 분명합니다.

2. 곱셈과 나눗셈을 비트시프트 친화적으로 설계했다

2, 4, 8 같은 값은 비트시프트로 빠르게 계산할 수 있습니다. 더 흥미로운 점은 단순히 코드 레벨에서만 그런 최적화를 한 것이 아니라, 아예 게임 안의 수식이 이런 계산 방식과 잘 맞도록 설계된 흔적이 보인다는 것입니다. 이건 “코드를 빨리 짰다”가 아니라 설계 자체가 CPU 친화적이었다는 뜻에 가깝습니다.

3. 데이터 레이아웃 자체가 성능의 핵심이었다

진짜 무서운 부분은 명령어 하나하나보다 데이터 구조입니다. 무엇을 어떻게 저장하고, 어떤 순서로 읽고, 얼마나 자주 접근할지 자체가 성능을 좌우합니다. 롤러코스터 타이쿤이 전설이 된 이유는 단지 저수준 언어를 썼기 때문이 아니라, 데이터를 CPU가 좋아하는 방식으로 최대한 빽빽하게 설계했다는 데 있습니다.

좋은 최적화는 “코드 몇 줄을 빨리 돌게 만드는 것”보다, 애초에 어떤 데이터와 규칙을 어떤 구조로 배치할지를 잘 정하는 것에서 시작됩니다.

예시 어셈블리 소스가 왜 도움이 되는가

이런 글에서 예시 어셈블리 소스를 넣는 것은 분명 도움이 됩니다. 다만 중요한 점은, 이 예시가 실제 Chris Sawyer의 원본 소스가 아니라 본문에서 설명한 최적화 감각을 이해하기 위한 개념 예시라는 점을 분명히 해야 한다는 것입니다.

주의

아래 코드는 원본 RollerCoaster Tycoon 소스가 아닙니다.
비트시프트, 플래그 검사, 짧은 분기, 단순 상태 갱신이 어떤 느낌인지 보여주기 위한 이해용 x86 스타일 예시입니다.

assemblylang_example_x86.asm 개념 이해용 예시

; -----------------------------------------
; 이해용 예시: 손님의 상태 일부를 매우 저수준으로 갱신하는 느낌
; 실제 RCT 원본 소스 아님
; -----------------------------------------

section .data
assemblylang_guest_hunger      db 48      ; 0~255 범위
assemblylang_guest_flags       db 00000101b
assemblylang_guest_happiness   db 120

section .text
global assemblylang_update_guest_state

assemblylang_update_guest_state:
    ; eax, ebx 사용 예시
    xor eax, eax
    xor ebx, ebx

    ; hunger 값을 읽음
    mov al, [assemblylang_guest_hunger]

    ; /8 대신 >> 3 사용
    shr al, 3

    ; 배고픔 단계가 6 이상이면 행복도 감소
    cmp al, 6
    jl assemblylang_check_flags

    mov bl, [assemblylang_guest_happiness]
    sub bl, 2
    mov [assemblylang_guest_happiness], bl

assemblylang_check_flags:
    ; bit 2 = 지도 보유
    mov al, [assemblylang_guest_flags]
    test al, 00000100b
    jz assemblylang_done

    nop

assemblylang_done:
    ret

위 예시에서 중요한 포인트는 문법 자체보다도 감각입니다. 작은 자료형, 비트 단위 플래그, 짧은 분기, 곱셈/나눗셈 대신 시프트 활용 같은 요소가 저수준 최적화의 분위기를 보여줍니다. 본문에 이런 예시가 들어가면 독자는 “어셈블리어로 작성됐다”는 문장을 더 구체적으로 이해하게 됩니다.

성능을 위해 게임 디자인까지 바꾼 사례

손님은 항상 똑똑하게 목적지를 찾지 않는다

공원 경영 게임이라면 손님이 가고 싶은 놀이기구를 정하고, 그곳까지 효율적으로 길을 찾을 것 같지만, 이런 구조는 수천 명이 동시에 움직일 때 계산 비용이 너무 큽니다. 롤러코스터 타이쿤은 여기서 정면돌파 대신 우회를 택했습니다.

손님은 늘 완전한 목적지 기반 탐색을 하지 않고, 길을 따라다니다가 흥미로운 시설을 발견하는 식으로 움직입니다. 플레이어 입장에서는 다소 단순해 보일 수 있어도, 엔진 입장에서는 프레임을 지키는 매우 현실적인 선택이었습니다.

정말 중요한 경우에만 더 비싼 길찾기를 쓴다

물론 모든 상황을 그렇게 처리한 것은 아닙니다. 정비공이 고장 난 기구로 이동하거나, 손님이 출구를 찾아야 하는 경우처럼 중요한 순간에는 더 전통적인 길 찾기가 필요합니다. 다만 여기서도 탐색 깊이에 제한을 둬서, 하나의 길 찾기 요청이 프레임 전체를 무너뜨리지 않게 했다는 점이 중요합니다.

군중은 서로 부딪히지 않는다

현실적인 군중 시뮬레이션을 하려면 사람끼리 충돌과 회피를 계산해야 합니다. 하지만 그건 엄청난 비용을 부릅니다. 롤러코스터 타이쿤은 이 문제도 정면으로 풀지 않았습니다. 손님은 서로 물리적으로 막지 않고, 대신 너무 붐비면 불만이 쌓이도록 해 플레이 경험은 유지하면서 계산량은 줄였습니다.

이 지점이 특히 중요한 이유

• 모든 문제를 복잡한 알고리즘으로 풀지 않았습니다.
• 게임 경험을 해치지 않는 선에서 계산량을 과감하게 줄였습니다.
• 즉, 최적화가 코드 레벨이 아니라 게임 디자인 레벨까지 내려가 있었습니다.

어셈블리어의 대가와 OpenRCT2

이런 방식은 당시 최고의 성능을 끌어내는 데는 강력했지만, 시간이 지나 플랫폼이 달라질수록 큰 약점이 되기도 합니다. 특정 아키텍처에 강하게 종속된 저수준 코드는 새로운 환경으로 옮길 때 그대로 재사용하기가 매우 어렵습니다.

 

그래서 훗날 원작의 구조를 현대 환경으로 이어가기 위해 팬과 개발자들이 큰 역할을 하게 되었고, 그 대표적인 사례가 바로 OpenRCT2입니다. 이 프로젝트는 단순한 모드가 아니라, 원작 계열 게임의 동작을 분석하고 현대 환경에서 더 편하게 즐길 수 있도록 이어주는 재구현 프로젝트라는 점에서 의미가 큽니다.

성능을 위해 가장 낮은 수준까지 내려간 선택은 훗날 유지보수성을 희생시켰지만, 역으로 그 덕분에 OpenRCT2 같은 집요한 재구현 프로젝트가 더 큰 기술적 가치를 갖게 되었습니다.

현대 개발자가 얻을 수 있는 교훈

이 사례를 보고 “역시 어셈블리어가 정답이다”라고 결론 내리면 오해입니다. 오늘날 대부분의 소프트웨어는 고수준 언어와 성숙한 툴체인 위에서 개발하는 편이 훨씬 합리적입니다. 생산성, 유지보수성, 협업성, 이식성을 무시할 수 없기 때문입니다.

하지만 롤러코스터 타이쿤이 지금도 강하게 남는 이유는 따로 있습니다. 성능 문제는 마지막에 튜닝 몇 번 해서 해결되는 것이 아니라, 처음에 데이터와 규칙을 어떻게 설계하느냐에서 이미 절반 이상 결정된다는 점을 분명하게 보여주기 때문입니다.

 

그리고 한 가지 더 있습니다. 좋은 개발자는 단순히 프레임워크를 잘 쓰는 사람이 아니라, 그 아래에서 실제로 어떤 비용이 발생하는지 상상할 수 있는 사람에 가깝습니다. 결국 롤러코스터 타이쿤이 남긴 가장 큰 유산은 “낮은 수준을 무조건 쓰라”가 아니라, 하드웨어와 런타임 비용을 이해하는 감각을 잃지 말라는 말에 더 가깝습니다.

마무리, 전설은 언어보다 설계에서 나온다

롤러코스터 타이쿤은 오래된 명작 게임이면서 동시에, 제약이 심한 시대에 얼마나 집요한 설계와 최적화가 가능한지를 보여주는 작품입니다.

그래서 이 게임은 지금도 개발자에게 질문을 던집니다. 당신은 코드만 보고 있는가, 아니면 그 아래의 비용 구조까지 보고 있는가. 이 질문이야말로 롤러코스터 타이쿤이 아직도 전설로 남아 있는 진짜 이유일 것입니다.

참고 및 출처

• Chris Sawyer 공식 FAQ 기준으로 RollerCoaster Tycoon은 99% x86 assembler/machine code와 소량의 C로 작성되었다고 소개됩니다.
• Lars Tofus, The gold standard of optimization: A look under the hood of RollerCoaster Tycoon
• OpenRCT2 프로젝트 및 재구현/역분석 관련 공개 자료
• 업로드한 원고 내용을 바탕으로 전체 흐름과 표현을 재구성했습니다.

태그

#롤러코스터타이쿤 #어셈블리어 #크리스소이어 #x86 #게임개발 #게임최적화 #데이터레이아웃 #비트시프트 #OpenRCT2 #소프트웨어공학