버그를 이용해 음악을 만들었다고? — Roland MT-32의 '의도된 결함'과 레거시 시스템의 함정
30년 전 하드웨어 펌웨어의 버그가 어떻게 게임 사운드의 표준이 되었고, 현대의 에뮬레이션 환경에서 왜 충돌을 일으키는지 분석합니다.
레트로 게임을 복원하다 보면 기묘한 현상을 발견하게 됩니다. 최신 사양의 에뮬레이터를 사용하고 하드웨어 역시 개선된 최신 리비전 모델을 구했음에도 불구하고, 정작 게임 속 음악이 엉망으로 들리거나 아예 출력되지 않는 경우가 발생합니다.
그 원인은 초기 Roland MT-32 모델에 존재했던 ‘펌웨어 버그’에 있습니다. 당시 게임 개발자들이 이 버그를 의도적으로 이용해 사운드를 설계했기 때문입니다. 결과적으로 버그가 수정된 ‘신형’ 모델에서는 오히려 소리가 잘못 출력되는 역설적인 상황이 벌어집니다 [4].
이는 레거시 시스템 유지보수에서 매우 위험한 함정을 시사합니다. ‘문서화되지 않은 하드웨어 버그’가 소프트웨어의 핵심 기능으로 고착화되면, 해당 버그는 더 이상 수정 대상이 아니라 반드시 준수해야 할 ‘스펙’이 된다는 사실입니다.
MIDI의 황금기와 Roland MT-32의 등장
1987년에 출시된 Roland MT-32는 당시 기준으로 매우 혁신적인 제품이었습니다. 아마추어 음악가와 게이머를 위한 보급형 MIDI 합성 모듈이었으며, 당시 게임 산업에 지대한 영향을 미쳤습니다.
당시에는 범용 표준인 ‘General MIDI(GM)’가 확립되기 전이었으므로, MT-32는 독자적인 악기 맵핑과 SysEx(System Exclusive) 메시지를 사용했습니다 [4]. 호환성 측면에서는 비효율적이었으나, 당시 Roland의 시장 영향력이 매우 컸기에 가능했던 구조입니다.
특히 AdLib과 같은 경쟁 제품보다 음질이 월등히 뛰어났기에, Sierra의 어드벤처 게임을 비롯한 많은 명작이 MT-32를 표준으로 삼아 사운드를 설계했습니다 [3]. 당시의 위상은 다음 문구에서 잘 드러납니다.
“it became more famous along with its compatible modules as an early de facto standard in computer music.” [4]
(컴퓨터 음악의 초기 사실상 표준으로서 호환 모듈들과 함께 매우 유명해졌습니다.)
하드웨어 인터페이스의 늪: MPU-401과 UART 모드
MT-32를 실제 시스템에 연결할 때 직면하는 가장 큰 장벽은 MPU-401 인터페이스 표준입니다. 이 인터페이스에는 ‘Intelligent Mode’와 ‘UART Mode’라는 두 가지 동작 방식이 존재합니다.
Intelligent Mode는 일종의 MIDI 코프로세서 역할을 수행합니다. CPU가 세부 타이밍을 계산할 필요 없이 “특정 틱 뒤에 이 노트를 연주하라”는 명령만 내리면 하드웨어가 이를 처리합니다. 반면 UART 모드는 단순하며, 컴퓨터 CPU가 실시간으로 모든 타이밍을 계산하여 데이터를 전송해야 합니다 [3].
문제는 비용 절감 과정에서 발생했습니다. 사운드 블래스터와 같은 후기 모델들은 고가의 코프로세서를 제거하고 UART 모드만 지원하기 시작했습니다 [3]. 그러나 초기 Sierra 게임들은 Intelligent Mode만을 사용하도록 설계된 경우가 많았습니다. 결국 하드웨어는 최신이지만 소프트웨어는 구형 인터페이스를 요구하며 상호 호환되지 않는 상황이 발생한 것입니다 [3].
치명적 함정: ‘버그’가 ‘스펙’이 되는 순간
MT-32는 시간이 흐르며 펌웨어가 업데이트된 ‘New’ 모델(및 MT-100)로 리비전되었습니다. 엔지니어 관점에서는 기존 버그를 수정하고 성능을 개선하는 것이 당연한 조치였습니다.
하지만 여기서 문제가 발생합니다. 초기 ‘Old’ 모델 펌웨어의 특정 버그들을 게임 개발자들이 의도적으로 이용해 사운드를 디자인했기 때문입니다 [4]. 개발자들은 해당 버그를 통해 발생하는 특유의 소리를 음악적 요소로 활용하여 게임에 그대로 반영했습니다.
그 결과는 다음과 같습니다.
“There were known bugs in the ‘old’ model’s firmware that were deliberately exploited by the game authors to get the best sounds.” [4]
(초기 모델 펌웨어의 알려진 버그들이 최상의 사운드를 얻기 위해 게임 제작자들에 의해 의도적으로 이용되었습니다.)
버그가 수정된 신형 모델에서 게임을 실행하면 제작자가 의도한 소리가 나지 않거나, 악기가 잘못 매칭되며, 심지어 소리가 출력되지 않는 경우도 발생합니다 [4]. 하드웨어 관점에서는 ‘정상적인 수정(Bug-fix)’이었으나, 소프트웨어 관점에서는 ‘치명적인 회귀 버그(Regression)’가 된 셈입니다.
참고로 기기의 리비전을 구분하는 방법이 있습니다. 기기 뒷면에 Phono 잭이 없고 좌우 출력 잭만 분리되어 있다면, 해당 기기는 위에서 언급한 ‘버그’를 포함한 구형 모델입니다 [4].
현대의 해결책: SoftMPU에서 HardMPU까지
이러한 레거시 문제를 해결하기 위해 현대의 엔지니어들은 소프트웨어와 하드웨어 양면에서 ‘에뮬레이션’ 전략을 사용합니다.
먼저 SoftMPU가 있습니다. 이는 DOS 상에서 TSR(Terminate and Stay Resident) 프로그램으로 동작하며, 소프트웨어적으로 MPU-401 인터페이스를 흉내 내는 에뮬레이터입니다 [1].
다만 소프트웨어 에뮬레이션은 CPU 부하를 유발하고 메모리 드라이버(EMS/XMS)와 충돌할 가능성이 있습니다. 이를 해결하기 위해 등장한 것이 HardMPU입니다. Atmega 마이크로컨트롤러를 사용하여 ISA 버스 수준에서 MPU-401의 동작을 하드웨어적으로 완벽하게 재현한 장치입니다 [3].
결국 하드웨어 레지스터 수준까지 정확하게 모사해야만, 당시 소프트웨어가 하드웨어를 정상적으로 인식하고 동작하게 됩니다.
짚고 넘어갈 한계와 안티패턴
여기서 “최신 General MIDI(GM) 패치를 적용해 호환성을 높이면 되지 않는가”라는 의문이 생길 수 있습니다. 실제로 Roland에서 제공하는 패치를 적용하면 대부분의 음악을 재생할 수 있습니다.
하지만 이는 완전한 해결책이 아닙니다. GM 패치를 적용하는 순간, MT-32 전용으로 정교하게 설계된 게임 특유의 고유한 사운드 색깔이 사라지기 때문입니다 [1]. 레트로 컴퓨팅에서 ‘호환성’이란 단순히 소리를 출력하는 것이 아니라, ‘당시의 경험을 그대로 재현하는 것’을 의미합니다.
핵심 요약
- 하드웨어의 버그가 소프트웨어의 기능으로 고착되면, 그 버그는 결함이 아니라 준수해야 할 ‘스펙’이 됩니다.
- 레거시 시스템 복구 시에는 모델명뿐만 아니라 하드웨어 리비전과 펌웨어 버전을 반드시 확인해야 합니다.
- 물리적 인터페이스의 동작 모드(Intelligent vs UART) 차이가 소프트웨어 실행 여부를 결정하는 핵심 요인이 됩니다.
- 진정한 하위 호환성은 때로 ‘의도적인 결함까지 동일하게 재현하는 것’을 의미합니다.
Roland MT-32의 사례는 엔지니어에게 중요한 교훈을 줍니다. 현재 사소하게 여기며 방치하거나 수정하는 결함이, 먼 미래의 누군가에게는 반드시 재현해야만 하는 ‘핵심 기능’이 될 수 있다는 점입니다. 이는 시스템 설계와 유지보수에 있어 세심한 기록과 문서화가 왜 중요한지를 다시금 일깨워줍니다.
참고 자료 (References)
1. [linuxjedi.co.uk] The Roland MT-32: The Ultimate late-80s Gaming Sound — https://linuxjedi.co.uk/the-roland-mt-32-the-ultimate-late-80s-gaming-sound 2. [dosdays.co.uk] DOS Days – MT-32 Game Compatibility Chart — https://www.dosdays.co.uk/topics/mt32_game_compat.php 3. [smbaker.com] Vintage MIDI: Roland MT-32, Roland SC-55, HardMPU, and an Xi 8088 — https://www.smbaker.com/vintage-midi-roland-mt-32-roland-sc-55-hardmpu-and-an-xi-8088 4. [en.wikipedia.org] Roland MT-32 — https://en.wikipedia.org/wiki/Roland_MT-32
관련 글 추천
- https://infobuza.com/2026/06/15/20260615-enyz7w/
- https://infobuza.com/2026/06/14/20260614-o5dzre/
FAQ
최신 Roland MT-32 모델에서 게임 음악이 제대로 출력되지 않는 이유는 무엇인가요?
초기 모델의 펌웨어에 있던 버그를 게임 개발자들이 의도적으로 이용해 사운드를 설계했기 때문입니다. 신형 모델에서는 이 버그들이 수정되어 오히려 제작자가 의도한 소리가 나지 않거나 출력되지 않는 현상이 발생합니다.
Roland MT-32의 구형 모델과 신형 모델을 외관으로 구분하는 방법이 있나요?
기기 뒷면을 확인했을 때 Phono 잭이 없고 좌우 출력 잭만 분리되어 있다면 버그를 포함하고 있는 구형 모델입니다.
MPU-401 인터페이스의 'Intelligent Mode'와 'UART Mode'의 차이점은 무엇인가요?
Intelligent Mode는 하드웨어가 직접 타이밍을 처리하는 코프로세서 역할을 수행하지만, UART 모드는 컴퓨터 CPU가 실시간으로 모든 타이밍을 계산하여 데이터를 전송해야 하는 단순한 방식입니다.
SoftMPU와 HardMPU는 각각 어떤 역할을 하나요?
SoftMPU는 DOS 상에서 소프트웨어적으로 MPU-401 인터페이스를 흉내 내는 에뮬레이터이며, HardMPU는 Atmega 마이크로컨트롤러를 사용하여 ISA 버스 수준에서 MPU-401의 동작을 하드웨어적으로 재현한 장치입니다.
General MIDI(GM) 패치를 적용하면 모든 호환성 문제가 해결되나요?
대부분의 음악을 재생할 수는 있지만 완전한 해결책은 아닙니다. GM 패치를 적용하면 MT-32 전용으로 정교하게 설계된 게임 특유의 고유한 사운드 색깔이 사라지기 때문입니다.
