16바이트 x86 어셈블리로 매트릭스 우주를 만들었어요 - 그것도 소리까지

트윗 한 줄도 안 되는 16바이트의 마법

영화 매트릭스에서 초록색 글자가 위에서 아래로 비처럼 내리는 장면, 다들 기억하시죠. 그 효과를 화면에 띄우는 코드를 짠다고 하면 보통 몇 줄이나 필요할까요? Python으로 짜면 수십 줄, C로 짜도 백 줄 가까이 될 거예요. 그런데 어떤 분이 이걸 단 16바이트의 x86 어셈블리로 구현했어요. 거기다 화면뿐 아니라 PC 스피커로 사운드까지 같이 나오게 만들었거든요.

이 작품은 Hellmood라는 데모씬(demoscene) 작가가 만든 거예요. 데모씬이 뭐냐면, 극도로 작은 코드 크기 안에서 인상적인 그래픽과 사운드를 만들어내는 일종의 예술 운동이에요. 16바이트면 트윗 한 줄도 안 되는 분량인데, 거기에 두 가지 기능을 다 넣은 게 놀라운 이유죠.

한 바이트도 낭비하지 않는 트릭들

이 프로그램은 도스(DOS) 환경의 .COM 파일로 동작해요. .COM 파일은 헤더가 따로 없어서 바이트 한 톨 한 톨이 다 코드가 되거든요. 그래서 16바이트가 정말 16바이트인 거예요. 작가가 공개한 writeup을 따라가 보면 트릭이 여러 겹 숨어있어요.

BIOS 인터럽트의 이중 활용 이 첫 번째 비밀이에요. 도스 시절에는 BIOS 인터럽트 int 10h로 화면에 글자를 찍었어요. 이 작품도 마찬가지인데, 글자 색깔과 위치를 무작위로 만들기 위해 별도의 난수 발생기를 두지 않아요. 대신 시스템 타이머의 값(int 1Ah)을 그대로 가져와서 화면 좌표와 색상으로 써먹어요. 이렇게 하면 별도 코드 없이 자연스러운 무작위성이 생기죠.

같은 데이터를 두 번 해석 하는 것도 핵심이에요. 화면에 찍히는 문자 값을 PC 스피커의 주파수 값으로도 보내요. PC 스피커는 8253 타이머 칩에 주파수 값을 넣으면 그 주파수로 소리를 내거든요. 매트릭스 글자가 바뀔 때마다 그 글자의 ASCII 값이 음정이 되는 거예요. 그래서 화면이 바뀌는 리듬에 맞춰서 묘한 음악 같은 소리가 나요.

x86 명령어의 부산물 활용 도 멋져요. 어셈블리에서 어떤 명령을 실행하면 의도한 동작 외에도 플래그 레지스터나 다른 레지스터에 부수 효과가 남거든요. Hellmood는 이걸 의도적으로 활용해요. 예를 들어 cwd 명령은 AX 레지스터를 부호 확장해서 DX에 넣는데, 이걸 이용해서 별도의 초기화 코드 없이 DX를 0으로 만드는 식이에요. 한 명령어로 두세 가지 일을 시키는 거죠.

데이터와 코드의 경계 허물기 가 가장 극적인 트릭이에요. 어떤 바이트는 명령어로 실행되다가 다음 사이클에서는 화면에 찍힐 문자로 쓰여요. 폰 노이만 구조의 본질을 가장 극단적으로 활용한 예시랄까요.

크기 제약이 만드는 예술

데모씬은 1980년대 유럽의 컴퓨터 크래커 문화에서 시작됐어요. 그 시절에는 256바이트, 64바이트 같은 극한 크기 챌린지가 인기였는데, 요즘은 그게 16바이트, 8바이트까지 내려갔어요. Pouet.net이라는 사이트에 가면 이런 작품들이 잔뜩 있어요.

크기 제약 안에서 뭔가 만드는 활동이 단순한 취미가 아닌 이유는, 이게 모든 최적화 기술의 극단을 보여주기 때문이에요. 비슷한 정신이 임베디드 개발, 게임 엔진의 핫 패스 최적화, 컴파일러 백엔드 같은 데서 살아있어요. WebAssembly로 4KB 안에 3D 데모를 만든다든가, 셰이더 코드를 1024바이트 안에 욱여넣는 1k intro 같은 것도 같은 맥락이에요. ChatGPT와 Copilot의 시대에 손으로 한 바이트씩 쥐어짜는 이런 작업이 더 귀해지는 느낌도 있어요. AI는 일반적이고 평균적인 코드를 잘 만들지만, 16바이트 안에 의미 있는 무언가를 만드는 건 여전히 사람의 영역이거든요.

한국 개발자에게는

이런 작품을 보고 "와 신기하다" 하고 끝낼 게 아니라, 우리 일에 어떻게 영감을 줄지 생각해볼 수 있어요.

첫째, 컴퓨터의 밑바닥을 한 번 들여다보세요. 평소에 Spring Boot나 React 하다 보면 컴퓨터가 어떻게 동작하는지 잊기 쉽잖아요. 이런 데모를 분석해보는 게 좋은 휴식이자 공부예요. 둘째, "제약이 창의성을 만든다"는 진리예요. 16바이트라는 극단적 제약이 오히려 더 창의적인 해법을 끌어냈거든요. 우리도 일할 때 "메모리 1MB 안에 풀어보자", "응답 10ms 안에 끝내보자" 같은 제약을 스스로 걸어보면 의외의 발견이 있어요. 셋째, 임베디드나 시스템 프로그래밍에 관심 있다면 이런 글이 좋은 입문 자료가 돼요. x86 어셈블리, 인터럽트, 하드웨어 직접 제어 같은 게 다 들어있거든요.