소형 태양광 범선에서 작업하는 Hundred Rabbits의 Devine이 현대 소프트웨어 스택의 취약성과 연결 의존성, 데이터 보존 문제를 항해의 제약 속에서 체감한 경험을 바탕으로, 가상 머신과 최소주의 컴퓨팅, Forth 등 오래된 아이디어를 탐구해 자급적이고 회복력 있는 개인용 컴퓨팅을 모색한 여정을 공유한다.
This is a blog post based on a transcript of a talk by Devine on November 26th 2022. Watch the video version on (YouTube). The slideshow presentation was made using Adelie.
Thank you to Matt Mascarenhas for providing us with an auto-transcript, it would have taken us ages to put this text together without it.
While we are grateful to have had the opportunity to give this presentation, an event in 2025 has resulted in us distancing ourselves from the conference responsible for hosting this talk. Below is a text by Devine explaining the situation.
Click to expand February 2025._몇 달 전, Handmade Seattle 컨퍼런스 참석자들은 2024년 11월 컨퍼런스가 사회정의 인식에 대한 언급과 조금 더 다양한 구성의 연사진을 포함하도록 방향 전환한 데 대해 불만을 표했습니다. 그 대가로 평소의 ‘바이트를 올바른 순서로 꾸려 넣는’ 유형의 발표가 줄었다는 것이었죠. 저는 그런 종류의 발표를 자주 하는 사람으로서 전혀 문제 삼지 않습니다.
어쨌든, 컨퍼런스 주최자는 티켓 소지자의 기대에 부합하지 못한 발표자 구성에 대해 사과하며, 다음 해엔 이 문제를 해결하겠다고 약속했습니다. 덧붙여, 자유/오픈 소스 소프트웨어 개발자는 더 이상 연사로 환영하지 않겠다고 했습니다.
사과문이 올라왔을 때 저는 채팅방에 있었고, 이번 선택이 정말 저수준 발표의 부족 때문이었는지, 혹은 다른 이유가 있었는지 그저 물었습니다. 오래 지나지 않아 온갖 편협한 이들이 나타나 컨퍼런스의 ‘좋았던 옛날’을 한탄하며 트랜스젠더를 향한 매우 혐오스러운 말들을 쏟아냈고, 개입 없이 몇 시간이나 불타올랐습니다. 흔히 보는 광경이죠.
예상 못 했던 건, 몇 달간 잠수하던 컨퍼런스 주최자가 마침내 침묵을 깨고 저를 공개적으로 비난하며 사태의 전개에 일부 책임을 돌렸고, 합의했던 여비 지원을 지급하지 않겠다고 한 일이었습니다. 이후 저는 유튜브, 비메오, 그리고 그들의 웹사이트에서 제 발표 영상의 삭제를 요청했습니다._
Reposted from xxiivv.com
나는 Hundred Rabbits라는 작은 스튜디오에서 일한다. 태양광으로 구동되는 작은 범선에서 운영되는, 두 명으로 이뤄진 작은 집단이다. 우리가 쓰는 모든 장비는 기증받거나 누군가 버린 기기들이다. 우리의 철학은 ‘빠른 소프트웨어를 만들려면 느린 컴퓨터가 필요하다’는 것이고, 가능한 한 이 철학을 실천하려 노력해 왔다. 우리는 항해를 하며 시간을 보내고, 회복탄력성(resilience)에 관한 실험을 한다. 그 대상은 컴퓨터에만 국한되지 않고, 식량 안보, 보존, 위기 상황에서 오늘날에도 활용할 수 있는 과거 기술의 연구까지 아우른다.
우리는 7년 전 항해를 시작했고, 태평양 전역을 돌았다. 멕시코, 프랑스령 폴리네시아, 뉴질랜드, 피지, 일본을 거쳐 러시아 해안을 따라 올라가다 알래스카를 스치고 캐나다 서부로 돌아왔다. 우리는 항해를 하며 미술, 음악, 비디오게임을 계속 만들 수 있으리라 생각했지만, 금세 우리가 당연하게 여겨온 기술 — 우리가 가진 그 모든 기술 — 이 서구권을 떠날 준비가 되어 있지 않다는 사실이 드러났다.
멕시코에서 줄을 풀어 떠나는 순간, 우리 기기들이 고장나기 시작했다. 2022년 Handmade Seattle 개막 연설에서 Abner는 룸바가 고장나기 시작하는 이야기를 했다. 집에서 룸바가 고장 나면 빗자루를 들면 되지만, 범선에서는 위치를 찾고 날씨를 아는 등 생존에 직접적인 영향을 미치는 장치들이 제대로 작동하는 것에 의존해야 한다. 그런데 그 모든 기술이 룸바와 같은 스택 위에 구축되어 있다.
우리가 믿고 의존하던 많은 도구들이 망가졌다. 애플 제품이든, 구독 서비스나 DRM을 요구하는 소프트웨어든. 예술가로서 우리는 시간을 들여 기술을 갈고닦는다. 포토샵 일러스트레이터가 되는 식으로. 그런데 인터넷 연결이 끊겨 소프트웨어가 잠겨버리면, 내가 내 것이라고 여겼던 그 기술은 사실 누군가가 온전히 소유한 것이었고, 언제든 빼앗길 수 있다는 사실을 깨닫게 된다.
수년간 그런 소프트웨어에 비용을 지불해 왔어도, 인증을 받기 위해 접속할 수 없는 순간 그 기술은 사라진다. 우리는 예상하지 못했고, 무서웠다.
요즘엔 모든 것이 클라우드 위에서 돌아간다. 2016년 초 미국 연안을 따라 항해할 때, 우리는 컨퍼런스에 들러 기술 업계의 동향을 보곤 했다. 부스의 사람들과 이야기하면 그들은 제품을 소개하려 들었지만, 우리는 중간에 말을 끊고 “오프라인에서 작동하나요?”라고 물을 수밖에 없었다. 열에 아홉은 “아... 아니요, 죄송해요. 클라우드에서 돌아갑니다.”라고 했다.
우리가 쓸 수 있는 것을 만드는 사람이 아무도 없는 듯했다. 슬픈 깨달음이었다. 나는 프로그래밍을 사랑하지만, 한동안은 우리의 새로운 삶과 전혀 양립할 수 없어 보였다.
더 이야기하기 전에, 서구권을 떠난 곳에서 현대 스택을 사용하려 할 때 어떤 모습인지 먼저 그려보겠다.
열대의 작은 범선에 두 사람이 있다. 마르케사스 같은 곳, 남태평양의 어떤 섬. 그 섬들은 무성한 숲에 덮여 있고, 필요한 것은 비와 해만이다. 그런데 우리는 같은 공간에서, Xcode를 업데이트하려고(당시 11GB) 지퍼백에 넣은 스마트폰을 마스트 꼭대기까지 올려 한 칸짜리 신호를 잡으려 애쓰고 있다. 2GB짜리 모바일 데이터가 들어 있는 카드 뭉치가 있었지만, Xcode는 다운로드가 끊기면 재개가 되지 않았다. 우리는 카드의 코드를 교체할 수 있었고, 10초 안에 교체하면 타임아웃으로 간주되어 이어받기가 되었다. 문제는 다운로드가 16시까지 끝나지 않으면 해가 지고, 태양광 패널이 더는 배터리를 충전하지 않아 노트북이 꺼진다는 점이다. 다운로드는 7GB에 도달했지만 업데이트까지 3시간이 더 필요하다. 끝나지 않을 것이고, 우리는 데이터만 날릴 것이다.
이건 최악이었다. 우리는 대안을 찾기 시작했다…
Note: 2016년, 우리는 iOS용 게임을 내고 있었고 Xcode, 아이폰, 맥북 프로를 사용했다. Rek는 Krita나 Gimp 같은 도구를 접해본 적이 없어 포토샵으로 그림을 그렸다. 그때도 리눅스를 알고는 있었지만, 고려할 만큼 익숙하진 않았다. 예술가로서 리눅스는 우리에게 맞지 않는다고 생각했다(분명히, 틀렸다). 우리는 늘 도시에 살며 인터넷 연결과 가까이 있었다. 집의 빠르고 안정적인 연결에서 Xcode를 업데이트하는 건 문제도 아니었다. 다운로드 크기를 신경 쓸 필요가 없었기 때문에 본 적도 없다. 육지에서는 전기가 무한히 있는 듯했고, 대역폭도 있었다. 자원이 희소해지자 다운로드 크기 같은 세부 사항, 그날 햇빛이 얼마나 들지에 집중해야 했다. 첫해에는 항해에 온 신경을 쏟느라, 여행 중 iOS 개발을 하는 게 말이 되는지 생각해볼 틈이 없었다. 캐나다를 떠날 때 우리는 다소 순진했고, 모르는 걸 몰랐다. 지금, 2023년에 Rek는 주로 손으로 그리고 Gimp로 작업한다. 우리는 둘 다 리눅스(만자로)를 쓰고, 스마트폰은 없다. 우리의 위태로운 시작에 대한 자세한 내용은 도구 생태계를 보라.
우리가 과거에 만든 소프트웨어가 점차 쓸 수 없게 되는 걸 알아차렸다. 우리는 몬트리올에서 자랐고, 친구들 중 많은 이들이 유비소프트 같은 AAA 스튜디오에서 일하며 3년짜리 수명을 가진 F2P 게임을 만들었다. 우리가 과거에 애플 스택, 일렉트론, 유니티3D로 만든 프로젝트도 3~4년의 수명을 가졌지만, 슈퍼 마리오 같은 게임과 그 시대의 다른 작품들은 지금도 플레이할 수 있다. 우리는 암흑기에 있다. 게임 개발자와 예술가가 수년을 들여 만든 게임이 빠르게 비트로트 속으로 사라진다. 우리는 다시는 플레이스테이션에서 Scott Pilgrim을 플레이할 수 없을 것이다.
온라인을 보니, 같은 걱정을 하는 사람들이 있었다.
위 이미지에는 디지털 데이터 보존에 대한 네 가지 철학이 있다. 모두 결함이 있다. 데이터 보존은 비교적 새로운 분야이며, 100년 뒤 어떤 데이터를 복구할 수 있을지 알 수 없다. 우리가 살펴본 실험들만 봐도 전망이 밝지 않다. BBC는 가장 오래 버틴 책 중 하나인 Domesday Book을 모방하려는 프로젝트를 진행했다. 수백 년 전 수도사들이 쓴 책이다. BBC의 생각은 이랬다. 지금도 이 책이 남아 있고 읽을 수 있다. 우리에게도 그런 것을 만들 기술이 있을까? 천 년 후 사람들이 오늘날 우리의 삶을 볼 수 있도록 기록할 수 있을까? 그들은 음악, 영화, 과학 논문이 담긴 BBC Domesday 디스크를 만들었다. 그런데 10년 뒤 읽을 수 없게 됐다. 디스크를 해독·복원하는 법을 사람들이 잊어버린 것이다. 장기적으로 데이터를 보존할 진정한 방법이 없어 보였고, 그래서 우리만의 작은 실험을 해보기로 했다.
미리 말하지만, 지금부터 쓰는 내용은 매우 순진한 접근이다. 나는 그림을 그리고 음악을 만든다. 조사를 시작했을 때 내가 찾는 것을 찾기 위한 어휘조차 없었다. 가상 머신이 뭔지도, 컴파일러가 뭔지도 몰랐다. 프로그래밍이 무엇인지 어렴풋이 알 뿐이었다. 스위프트와 Objective-C를 썼지만, 그것이 프로세서와 어떻게 연결되는지 개념이 없었다. 마치 어떤 서비스를 배우는 느낌이었다. ‘포토샵하기’를 배우는 것처럼. 그건 기술을 배우는 게 아니다. 포토샵을 쓴다고 해서 그림 그리기를 배우는 게 아니다. 남의 놀이터 규칙 안에서 조작하는 법을 배울 뿐이다. 그리고 그 양탄자가 발밑에서 휙 사라지면, 할 말도, 할 수도 없다. 애초에 어떻게 작동하는지 이해하지 못했기 때문에 복제할 수도 없다.
우리는 결국 ‘가상 머신’이라는 단어를 접했다. 슈퍼 마리오 브라더스 NES 파일은 컴퓨터에 넣어 실행할 수 있고, 내 폰에서도, 옛 컴퓨터에서도, 슈퍼패미컴에서도 실행할 수 있다. 심지어 닌텐도64에서 슈퍼패미컴 에뮬레이터를 돌려 그 위에서 마리오를 실행할 수도 있다. 데이터 보존에 좋은 방법처럼 보였다. 우리는 소프트웨어를 완전히 포기하지 않고, 가상 머신을 이용해 그 영역에서 무엇을 할 수 있을지 보기로 했다.
하드웨어는 믿을 수 없을 정도로 싸고, 그 때문에 전자폐기물이 전 세계를 뒤덮고 있다. 그리고 그 모든 것이 가져다 쓰라고 우리 앞에 널려 있다. 누구나 서랍에 옛 기기를 한가득 가지고 있다. 슈퍼패미컴, 플레이스테이션, 드림캐스트 같은 것들. 더는 개발이 이뤄지지 않아 ‘구식’으로 취급되는 기기들이다. 우리는 그런 기기에 두 번째 삶을 줄 수 있지 않을까 생각했다. 이걸 어떻게 할 수 있을지 알아보는 과정은 우리를 흥미로운 곳으로 데려갔다. 우리는 오래된 전자기기를 재활용하는 방법에 관심을 갖게 됐다. 경쟁이 없어 보였다. 모두가 하는 걸 하면 모두와 경쟁해야 한다. 예컨대 iOS 10용 소프트웨어를 만들면 시장은 이미 포화 상태다. 하지만 오늘 아타리용 게임을 낸다면 큰 반향을 얻을지도 모른다. 더는 아무도 이 기기들에 목적을 부여하지 않는다. 우리는 완전히 엇나간 일을 해보려 했다. 시작으로, 닌텐도 DS용 게임을 만들어보는 것이 목표였다.
학문적 배경 없이 바깥에서 VM을 들여다보면 가장 먼저 찾게 되는 게 JVM이다. 나는 자바를 써본 적이 없지만, 친구(진짜 프로그래머)들에게 “나 JVM 만들 거야! 이게 우리 문제를 해결할 것 같아!”라고 떠들고 다녔다. 돌아온 대답은 JVM은 너무 분열되어 있고, 우리가 찾는 게 아니란 것이었다. 소프트웨어가 딸린 게 아니라 논문만 잔뜩 있었다.
자바 생태계를 기웃거렸지만 영 알아먹을 수가 없었다.
우리는 일렉트론이 아닌, 다양한 기기에서 돌아갈 수 있는, 일종의 교차 플랫폼 위에서 장난스러운 작은 프로젝트들을 만들고 싶었다. 늘 최신의 현대적인 것을 목표로 삼는 대신, 과거로 점점 더 멀리 거슬러 올라가며 실행될 수 있는 VM 같은 것을 만들 수 있지 않을까 했다.
세상에는 빠른 컴퓨터가 정말 많다. 처음 NES 게임을 만들었을 때, 60fps로 화면에 엄청나게 많은 것을 그릴 수 있다는 사실에 놀랐다. 나는 현대 기술이 더 낫고 더 빠르며, 8비트 시대의 것들은 이미 해결된 문제들이라 그 문제 공간을 완전히 탐색했다고 믿고 있었다.
그렇지 않았다. 과거에는 잊힌 아이디어가 많았고, 나는 그것을 탐험하는 일을 내 임무로 삼았다. 코로나로 모두가 집에 갇혀 있던 때, 컴퓨터가 어떻게 작동하는지 알아내기에 완벽한 시간이기도 했다. 과거로 돌아가 사람들이 어떻게 했는지, 어떤 아이디어가 잊혔는지 살펴보려 했다.
한때 컴퓨터는 몹시 장난기 가득했지만, 지금은 차갑고 사람들을 겨냥한 도구처럼 느껴진다. Microsoft Bob에 있던 그 장난스러움과 견줄만한 것을 오늘날 찾기 어렵다. 지금 Microsoft Bob을 만든다면 아마 온갖 걸 팔아치우려 들 것이다. 우리 사회에는 이런 장난스러운 것을 탄생시킬 시스템이 없는 듯하다.
이런 일을 하면서 깨달은 점은, 하드웨어와 소프트웨어를 직접 맞춤화하면 애정이 생긴다는 것이다.
기성품, 예컨대 아이폰처럼 바꿀 수 없는 것을 사면 덜 애지중지하게 되고, 결국 서랍에 처박히기 쉽다. 예전에 라디오셱에 가면 컴퓨터 부품을 살 수 있었고(예: Altair), 직접 맞춤화가 가능했다. 그러면 그 전체를 이해할 수 있었다. 맞춤 제작하거나 거의 밑바닥부터 만든 기기는 지금도 사랑받는다. 하지만 너의 낡은 아이폰6는 어디 있는지도 모르겠고, 설령 알아도 아마 쓸 수 없을 것이다. 아이폰6 같은 기기는 수리할 수 없게, 해독 불가능한 방식으로 고장 나도록 설계되어 있다.
우리는 가능한 한 폭넓게 접근 가능하게 만들려 하기보다, 단 한 사람을 위해 설계하면 무엇을 할 수 있을지 보기로 했다. 확장(스케일)되도록 설계되지 않은, 일종의 개인용 컴퓨팅이다.
러스트 같은 언어의 매력은 이해하지만, 나는 배우지 않을 것이다. 컴퓨터로 문제를 해결할 수 있다고 확신하는 사람에게는 내 얘기가 전혀 관련 없을 수도 있다. 나는 ‘강요당해 컴퓨터를 써야 한다면 그것은 절대 장난스러울 수 없다’고 생각한다. 어떤 작가가 말했다. “강요된 놀이란, 놀 수 없는 것이다.”
나는 스마트폰이 없다. 시애틀을 걷다 보니 길거리에 라임 스쿠터가 줄지어 있었다. 스쿠터를 쓰려면 메뉴를 보기 위해 QR 코드를 스캔해야 한다. 기술을 쓰기 위해 사람들에게 강요된 현실의 한 층이 있다.
내가 말하는 건 그런 게 아니다. 우리가 하려는 것은 개인용 컴퓨터에 가까운 것, 당신이 ‘놀 수 있도록’ 맞춤 설계된 것이다.
VM을 찾기 시작하며 과거를 들여다보았고, Smalltalk로 이어졌다. 나는 What the Dormouse Said라는 책을 읽었는데, 스탠퍼드의 역사와 사람들이 컴퓨터에 품었던 유토피아적 아이디어를 다룬다. 내가 컴퓨터에 관심을 갖기 훨씬 전 이야기다. 당시의 비전을 배우는 것은, 오늘날 무엇을 할 수 있을지에 대한 낙관을 줬다.
그때 처음 가상 머신, 바이트코드라는 개념을 접했다. 앞서 말했듯, 필요한 어휘 없이 온라인에서 정보를 찾는 일은 정말 어렵다. 개인용 컴퓨팅을 배우는 데 스몰토크를 익히는 시간을 들이지 않고서는 방법이 없었다.
그 길로 가기 시작하면, 사람들이 반드시 리스프 머신을 해봐야 한다고 말한다. 나는 Symbolics와 LVP에 대해 공부했다. 전체 시스템을 들여다볼 수 있고, 매우 개인적인 방식의 컴퓨팅을 추구한 시스템을 알게 됐다.
오늘날로 치면 브라우저와 비슷하다. 좋아하는 웹사이트에 가서 오른쪽 클릭으로 검사하기. 요즘은 점점 덜하지만, 한동안은 웹사이트를 검사해 어떻게 만들어졌는지 볼 수 있었다. 이건 힘을 실어주는 일이었고, 그 시대를 상징했다.
이건 VM에서는 그대로 통하지 않지만, Niklaus Wirth가 Oberon이라는, 책과 함께 온 전체 운영체제를 썼다는 점에서 관련이 있다.
오베론 책은 정말 좋다. 특히 백지 상태로, 프로그래밍에 대한 선지식이나 기대 없이 접근한다면 더더욱. 책은 운영체제를 처음부터 만드는 방법을 설명한다. Pascal 같은 언어를 쓰는데, 읽기 쉽고, 다른 ALGOL 계열보다 아름답다. 가장 먼저 가르치는 것 중 하나가 그림 그리는 법인데, 시각적 성향이 강한 나에게 특히 흥미로웠다.
책에서 Wirth는 P-machine을 언급한다. 나는 가상 머신이 무엇인지 감을 잡아가고 있었는데, 그가 잠깐 이렇게 말한다. “아, 그러고 보니 가상 머신을 타깃으로 하는 파스칼 컴파일러를 썼었지.” ‘언어가 가상 머신을 타깃으로 할 수 있다고?! 뭐?’ 그리고 그가 컴파일러를 플랫폼 간에 쉽게 이식할 수 있었던 이유는, 그것을 구동하는 옵코드가 극도로 단순하고 개수가 아주 적었기 때문이다.
그때 생각했다. 바로 이게, 내가 매력을 느끼는 데이터 보존의 길이라고.
나는 파스칼을 배웠다.
파스칼은 아름다운 언어다. 위 이미지는 매킨토시 에뮬레이터에서 실행 중인 모습이다. 리눅스도, 거대한 QEMU 이미지도 아닌, 작은 창에서 전체 운영체제를 돌릴 수 있다는 점이 마음에 들었다. 금세 망가뜨렸다가도 빠르게 다시 시작할 수 있는, 작고 자급적인 시스템. 에뮬레이터 속도를 128배로 올려 60fps로 3D를 돌릴 수도 있었다. 오늘날 컴퓨터가 얼마나 빠른지 보여주는 증거였다.
그 과정은 C의 역사로 이어졌다.
나는 내 플랫폼을 Plan 9로 모두 옮겼다. Plan 9에는 자체 C 컴파일러가 있고, C89와도 조금 다르다. 일종의 ‘타협 없는’ 시스템이다.
만든 이들이 돈을 벌 목적으로 만든 게 아니라는 게 정말 느껴진다. 사랑의 산물이다. 개인용 컴퓨팅이 무엇이 될 수 있는지에 대한 낙관을 줬다.
Plan 9은 VM 위에서 돌지 않지만, 다른 시스템에 영감을 주었다. Plan 9에서 얻은 교훈은 Inferno라는, VM 위에서 돌아가는 시스템의 탄생으로 이어졌다.
VM이 무엇인지 이해하기 시작한 듯했다. 전체 운영체제가 VM 위에서 돌아간다면, 바로 그게 내가 하고 싶은 일이다.
Inferno 같은 것은 규모가 꽤 크다. 하지만 오후 한나절이면 이 가상 머신의 전체 C 코드를 훑을 수 있었다. 위 이미지는 그가 가진 옵코드다.
부분적으로는 애플 뉴튼을 구동하던 실제 하드웨어에서 영감을 받았다.
한나절이면 돌려보고, 정확히 어떻게 돌아가는지 이해할 수 있었다. Dis 가상 머신을 타깃으로 하는 컴파일러를 살펴보면, 어떻게 연산을 제한된 수의 동작으로 줄였는지 볼 수 있었다.
과거에 타임셰어링 시스템에서 벗어나기 위해 애썼던 사람들은, 지금 우리가 어떻게 다시 그 ‘벽 뒤에서 일어나는 컴퓨팅’ 상태로 속아 빠져들었는지 보고 웃거나 울 것이다. 당신에게 터미널이 있지만, 권한은 거기서 끝난다.
아무도 내게서 빼앗을 수 없는 방식으로 컴퓨터를 하고 싶었다.
누군가는 주말 동안 운영체제 전체를 썼다는 글을 읽었지만, 나는 그 생각을 내가 보는 것들에 맵핑하지 못했다. 다리를 놓아줄 무언가가 빠져 있었다.
현대 스택은 우리에게 잘 맞지 않는다. 배 위의 제약에 맞지 않는다. 우리는 180와트의 태양광만 있다. 이번 여름 내내 6볼트 배터리 두 개로 지냈는데, 정말 작은 용량이다. 이런 길을 택하면 사람들은 매번 태양광 패널을 더 달라거나, 배터리를 더 사라고 한다. 너무 현대적인 문제 해결 방식이다. 실제로 이런 기술(특히 하이테크)은 문제를 잘 해결하지 못한다. 오히려 많은 문제를 만든다. 범선에서는 그게 아주 즉각적이다. 태양광을 더 달면 바람받이가 커지고, 무엇인가 날아가 사지를 자를 위험이 커진다. 배터리를 더 싣으면 배가 무거워져 폭풍우에서 도망치기 어려워진다.
범선이 가진 한계는 우리의 창의력을 위한 공간이 되었고, 그 제약은 우리에게 놀이터가 되었다.
나는 Plan 9, 오베론, 리스프 머신을 만들 수 있는 프로그래머가 아니지만, 간단한 NES 게임을 쓰고 포팅할 수는 있었다. NES 게임 안에서 NES 게임을 쓸 수는 없었다. 그게 너무 아쉬웠다. 완전히 부트스트랩된 무언가를 원했다.
6502를 살펴본 뒤, 코모도어 64 에뮬레이터가 엄청 복잡하다는 걸 알았다. 내가 이해할 수 있는 한계를 넘어섰다. 단순한 시스템처럼 보이지만, 그것의 에뮬레이터를 쓰는 일은 주말 프로젝트로 끝날 일이 아니었다. 나는 주말에 끝낼 수 있는 것을 찾고 있었다.
6502에는 니모닉이 아주 많다. 6502를 VM으로 구현하려 하면, 순진한 구현은 일주일, 혹은 다른 일을 전혀 하지 않으면 주말에 끝낼 수 있다. 내 C 지식은 매우 제한적이었지만, 다행히 도움을 받았다. 이 명령어 집합을 더 줄일 수 있을지 궁금했다…
그 과정에서 복잡성과 단순성이 무엇인지 생각하게 됐다. 수학자 Kolmogorov는 어떤 시스템의 복잡도 지수는 특정 문자열을 생성할 수 있는 프로그램의 길이라고 말했다. 나는 그 관점을 좋아한다. 요즘의 복잡성과 단순성은 뒤엉켜 있다. 하드웨어를 잘 모르면, 모두가 프로그래머를 편하게 만들려 하고 실제 빠른 제품을 만드는 데 집중하지 않는 듯 보인다.
내가 아는 취미 프로그래머 대부분은 타입 시스템, 메모리 안전성 같은 온갖 ‘보조 바퀴’를 쓴다(농담이다. 큰 팀이라면 제발 타입 시스템을 쓰라). 나는 혼자 작업할 때 문제 공간을 가능한 한 작게 줄이고 싶다. 프로그래밍을 그다지 좋아하지 않고, 미래에는 아마 더 싫어할 것이기에, 미래의 내가 주말 안에 내 전체 시스템을 다시 구현할 수 있기를 바란다.
그렇다면 어디로 가야 할까? 6502는 내가 하려던 범위를 벗어난다. 이미 두 번이나 해봤고, 또 할 기운이 없을 것 같다.
벨 연구소가 있던 바로 그 시대로 돌아가 보자. 아이들에게 프로그램 카운터가 무엇인지, 프로그램 안에서 데이터가 어떻게 움직이며 바이트코드를 어떻게 탐색하는지 가르치기 위해 ‘종이 컴퓨터’를 만들던 시절이었다.
종이와 펜만 있으면 아무도 당신에게서 종이 컴퓨터를 빼앗을 수 없다. 느리고 고통스럽긴 해도 문제를 풀 수 있다. 쉽게 이식 가능한 형태의 컴퓨팅이다.
BBC의 Domesday 프로젝트를 보다가, Alan Kay(스몰토크)도 내가 하려던 것과 맞닿은 프로젝트를 했다는 걸 알았다. 그는 이렇게 생각했다. “스몰토크는 VM이다. 얼마나 작은 VM이 스몰토크-72를 돌릴 수 있을까?”
그는 The Cuneiform Tablets of 2015라는 논문을 썼고, 컴퓨터에 대해 바이럴하게 퍼진 표현을 남겼다. “리스프는 프로그래밍의 맥스웰 방정식이다” 같은 말. 미니멀리스트 괴짜인 나는 이 말이 마음에 들었다. 내가 원하던 바였다. 하지만 리스프를 들여다보니, 설계상 가비지를 만들어내는 언어는 내가 찾는 것이 아니었다. 그 논문은 더 마음에 들었지만, 레지스터 머신이었고, 스몰토크와 어떻게 연결되는지 보이지 않았다.
그래서 ChifirVM은 내가 찾는 것과 정확히 일치하진 않았다. 하지만 세상에는 다른 방식의 컴퓨팅이 아주 많다. 나는 즉시 단일 명령어 집합 컴퓨터(OISC), 예컨대 SUBLEQ로 빠져들었다. 끔찍한 타르 웅덩이 같다고 생각했지만, 15분이면 구현할 수 있었다. 미래의 나를 위해 15분이면 구현할 수 있는 것 위에서 돌아가는 시스템을 만드는 건 정말 친절한 일일 것이다.
문제는, 실제로 쓸모 있는 것을 작성하려면 필요한 툴체인이 거대하다는 점이었다. 어떤 이들은 C 컴파일러를 Subleq까지 내리기도 했지만, 그러면 복잡성을 전부 컴파일러로 떠넘기는 셈이고, 내 문제는 해결되지 않는다.
내가 사랑하는 컴퓨팅 패러다임들이 있었다. 아주 순수하고, 아주 아름다웠다. 하지만 동시에 실리콘에 너무 잘 맞지 않아 내겐 실용적이지 않았다.
Thue(내가 가장 좋아하는 것 중 하나)는 연산자가 하나뿐이고, 대체 규칙만 있는 에소테릭 언어다. 축적기(어큐뮬레이터)는 문자들의 열이고, 각 줄마다 하나씩 있는 규칙은 왼쪽의 것을 오른쪽의 것으로 바꾸는 것이다. 매우 느리지만 극도로 강력하며, 30분이면 구현할 수 있다.
FRACTRAN도 또 다른 OISC 시스템이다. 연산은 하나, 곱하기. 그 원시 값은 바이트나 쇼트가 아니라 분수다. 소수 인코딩을 사용하는데, 내가 아는 가장 아름다운 수학적 개념 중 하나였다.
한동안 나는 이게 나의 기반이라고 생각했다. 분수로 컴퓨터를 만들겠다고. 단 하나의 문제는… 실리콘에 잘 맞지 않는다는 것이다.
SKI 계산법은 아름답다. 수학적 우아함이 있다. 나는 그 굴로 들어갔다가 간신히 살아 돌아왔다.
모두에게 리스프 샛길을 추천한다. 그리고 SKI를 배우고, 스멀리언을 읽고, 제품을 만들기보다 창조적이고 예술적인 방식으로 소프트웨어를 탐구하는 사람들의 글을 읽어보길 바란다. 나는 거의 이것을 나의 기반으로 삼을 뻔했다. 하지만 VM 계층에서의 가비지 컬렉션은 나쁜 아이디어였다.
Brainfuck은 명령이 7개다. 구현에 45분, 길어야 한 시간이면 된다.
우리는 추상화 사슬을 거슬러 올라가고 있다. 내가 본 패턴은 이랬다. 니모닉이나 복잡성을 줄이면 줄일수록 느려진다. 놀랍게도 브레인퍽은 빨랐다. 구현이 작은 시스템에서도 만델브로트를 돌릴 수 있었다. 하지만 내가 하고 싶은 프로그래밍은 아니었다. 그래서 또 다른 시스템으로 이어졌다…
Chuck Moore는 내가 읽은 스탠퍼드 관련 책들에 나오지 않았다. 아마 아웃사이더였을 것이다. FPGA에는 익숙하지 않았지만, 사람들은 그것으로 실험적 컴퓨팅 시스템을 만들고 있었다. 중요하지 않았다. FPGA는 ‘끈적한 젤’ 같아서 마음대로 모양을 낼 수 있다.
누군가 J1이라는 FPGA 시스템을 만들었는데, Forth 시스템이다. 옵코드가 아주 적었지만, 내가 본 바이트코드 매핑 중 가장 아름다웠다. 스택 머신의 프리미티브가 서로 결합될 수 있도록 구현되어, 바이트의 비트를 묘하게 토글하는 조합으로 아주 흥미로운 에소테릭 스택 조작자를 만들 수 있었다.
나는 한눈에 반했다.
16비트 Forth 시스템이고, 한 단어에 담을 수 있는 가장 큰 리터럴은 35k 고정 정도다. 산술은 매우 아름다웠지만, 전체 시스템이 실행할 수 있는 최대 프로그램 크기는 4KB였다.
내가 염두에 둔 것은 4KB보다 조금 더 컸다. 그래도 아주 많이는 아니다. 전체 주소 공간을 가질 수 있다면 64가 정말 좋겠다. 6502의 복잡함은 원치 않았다.
CHIP-8은 흥미로운 시스템이다. 게임잼에서 이것으로 무언가를 만드는 활기찬 커뮤니티가 있다.
스펙은 꽤 단순하여, 아마 종이 두 장, 양면이면 다 들어갈 것이다. 내가 좋아하는 방식으로 종이 컴퓨터 같다. 하지만 범용 구동 VM으로 설계된 것은 아니다. Pong 규모의 것을 만드는 데 적합하다. 키보드는 숫자만 있는 16진 키패드 같은 것이다. 나는 그 안에서 그것 자신을 빌드할 수 있는 무언가를 만들 계획이었기에, 키보드, 커서—내게 맞는 키보드가 필요했다. 이상한 키보드로는 곤란했다.
Machine Forth는 그 뒤에 발견했다. Chuck Moore는 Forth를 만들고, 그게 너무 복잡하다고 생각했다. ‘뭘 복잡하다는 거지? 문법도 없고, 그냥 공백으로 구분하는 언어인데. Forth 시스템 구현은 정말 빠른데.’ 하고 생각했다. 하지만 Chuck Moore는 특유의 방식대로 그 ‘군더더기’ 없이 하길 원했다. 더 줄여서 32개, 혹은 24개의 옵코드만 있는 Machine Forth를 만들었다.
나는 계속 Forth를 보게 됐지만, 한동안 그 아름다움을 이해하지 못했다. 방금 리스프에서 넘어왔다면, Forth로 떨어질 때 채찍처럼 휘청인다. 비슷한 아름다움이 있다. 리스프가 전위 표기라면, Forth는 후위 표기다. 그런 마음가짐으로 보면 누구든 무엇이든 될 수 있는데, 왜 굳이 ALGOL이 되려 하는가?
Forth와 Lisp 사이를 오가며 결심하지 못했다. Forth를 사랑하는 사람들을 많이 봤지만, 그들은 정말 못 팔았다. 리스프는 복사/붙여넣기 가능한 코드를 찾기 힘들다. 다들 괴상한 매크로와 라이브러리를 쓰고, 이식성이 없다.
Forth에는 다른 문제가 있었다. 만나는 사람마다 Forth가 최고라며 꼭 쓰라고 하는데, “두 점 사이의 거리는 어떻게 계산하죠?” 같은 질문을 하면, 돌아서는 길에 ‘다들 Forth를 좋아하긴 하는데, 실제로는 안 쓰나 보네’라는 생각이 들곤 했다. 코드를 찾기가 어려웠다. Forth가 이식성이 낮다는 건 알지만, Forth를 배우며 Forth를 구현해 보고는 다시 러스트로 돌아가는 학습기 말고, 실제 사용 사례를 찾기 어려웠다.
Forth의 작동 방식은 아주 단순하다. 스택에 값을 올리고, 토큰을 만나면 스택에서 값을 꺼내 처리하는 식. 연산자 우선순위 같은 게 없다.
내가 하고 싶은 일의 기반으로 아주 좋아 보였다.
Machine Forth는 금속에 바짝 붙은(low-level) 것이고, Forth의 핵심은 어셈블리와 매우 가까운 무엇이다. 하지만 나는 정확히 어셈블리에 매핑되는, ‘하나의 토큰이 1바이트 혹은 1쇼트’가 되는 무엇을 원했다.
그래서 한동안 옵코드를 잔뜩 골라 친구들에게 보여줬더니 “이건 별로야”라는 반응이 돌아왔다. 내가 믿는 사람들이었다. 혼자였다면 아마 포기했을 테고, 여전히 자바스크립트를 쓰고 있었을지도 모른다. 그들은 엄청나게 인내심이 있었다. 내가 하려는 것을 이해하고 있었다. Sigrid, Alderwick, Andrew 같은 분들은 내 멍청한 질문에도 무한한 인내로 “내 방식은 아니지만, 네 시스템을 개선하는 데 쓸 수 있는 방법이 있어”라고 조언해 주었다.
결국 나는 마음에 드는 ‘냅킨 정의’의 시스템을 얻었다. 이 과정 내내 목표는 티셔츠 한 장에 들어갈 수 있는 시스템을 만드는 것이었다. 특히 범선에서는 컴퓨터를 잃어버릴 수도 있다. 그렇다고 모든 문서를 보존하고 싶진 않았다.
항해를 시작했을 때 나는 루비를 조금 했다. 자급자족하기 위해 필요한 루비 문서를 모두 모으려 하니 양이 압도적이었다.
아무것도 하지 않느라 바쁨처럼 50일 내리 바다에 있으면 StackOverflow에 접속할 수 없다. 질문은 답을 얻지 못한 채 남는다. 내일 그 사이트가 영영 사라진다고 상상해 보라. 바다 위, 인터넷 없이 다각형 채우는 법을 찾아보려 해도 할 수 없다. 하지만 인쇄본이 있다면? 어떤 언어는 이를 훨씬 쉽게 만들고, 어떤 언어는 아주 어렵게 만든다. C 배경이 없어, C 문서 없이 항해를 떠나는 건 매우 어려웠다. 그런데 C 문서는 방대하고 투박하다.
아마 언젠가 그 책도 잃어버리겠지만, 미래의 내게 그 티셔츠만 있다면 괜찮을 것이다. 나는 할 수 있는 모든 것을 티셔츠에 들어가도록 줄이려 했다. 그게 내가 허용할 수 있는 대역폭의 전부였다.
왼쪽의 6502에 익숙하다면(위 이미지), 세로로 늘어선 명령들의 연속처럼 보일 것이다. 내가 만든 작은 언어도 꽤 비슷하다. 1:1로 매핑할 수 있고, 결과 바이트코드 크기도 거의 같다.
이런 어셈블리 언어처럼 세로로 길게 문자를 읽는 데 익숙할 것이다. 하지만 나는 Forth의 아름다움을 가져와, 조금은 ‘글을 쓰는 것’처럼 장황하게 읽히는 언어를 만들고 싶었다.
매일 아침 프로그램을 열 때, 주석을 안 남겨둔 자신을 미워하지 않게. 코드 자체가 좀 더 읽기 쉽고, 스스로를 설명하도록.
내가 가장 먼저 한 일은 그 언어로 어셈블러를 만드는 것이었다. 쉬웠다. 언어가 아주 단순하니, 어셈블러 자체도 단순해진다. 그 언어로 자체 어셈블러를 실행할 수 있는 VM의 x86 애플리케이션을 생성했다.
어셈블러는 3000바이트다.
컴퓨터라 부르기엔 빈약하지만, 바이트코드는 실행한다. 나는 컴퓨터로 풀던 문제를 32가지로 줄인 듯했고, 이 32가지는 아마 Fractran이나 Subleq 같은 더 미니멀한 시스템으로도 구현할 수 있을 것이다.
자바스크립트에서 문자열을 정수로 바꾸는 작은 함수가 실제로는 어떻게 동작하는지, 어셈블리로 직접 쓰다 보면 ‘마법’이 걷힌다. 사람들은 종종 마법을 사랑한다고 하지만, 사실 그렇지 않다. 특히 무너질 때는 더더욱. 나는 마법을 좋아하지 않는다.
더글라스 애덤스가 말했다. “잘못될 수도 있는 것과 절대 잘못될 리 없는 것의 가장 큰 차이는, 절대 잘못될 리 없는 것이 잘못되면 보통 손댈 수도, 고칠 수도 없게 된다는 것이다.” 프로그래밍에서 내가 처한 상황이 그랬다. 나는 전부 이해하고, 전부 들여다볼 수 있기를 원했다.
그다음으로 그리기 루틴 등을 만들기 시작했다. Basic의 구현, 게임, 다른 에뮬레이터 구현도 만들었다.
나는 이 작은 언어로 2년째 글을 쓰고 있다.
한 좌담에서 Robert Nystrom은 모두 자기만의 프로그래밍 언어와 시스템을 만들라고 권했다. 컨퍼런스 참석자 중 많은 이들이 이 견해에 동의했지만, 다른 곳에서는 대체로 곱게 보지 않는다. 내가 처음 이 얘기를 꺼냈을 때, 사람들은 날 비웃었다. 나는 그림을 좋아했고, 사람들은 ‘네가 컴퓨터에 대해 뭘 안다고?’라고 생각했다.
나는 모두의 프로그래밍 언어를 보고 싶다. 새로운 사람을 만나면 이렇게 묻고 싶다. “옵코드는 몇 개예요?”
그건 그 사람의 사고방식을 말해준다.
우리는 우리가 만드는 게임을 담기 위해 맞춤 설계된 작은 시스템을 만들었다. 다른 누구에게는 낯설 것이다. 괜찮다. 이 아이디어를 팔려는 게 아니다. 우리가 원하는 건 모두가 ‘남의 아이디어’—유물로 어지러운—에 업혀 가기보다 자신만의 개인용 컴퓨터를 시도해 보길 바라는 것이다. 우리는 아직 할 수 있는 것의 표면조차 긁지 못했다고 생각한다.
많은 사람들이 ‘8비트로는 할 건 다 해봤다’고 말하겠지만, NES가 나왔을 당시 지금 우리가 가진 대부분의 게임 장르는 존재하지도 않았다. 탐험할 공간은 엄청나게 남아 있다. 다만 모두가 VR, AR 등 다른 곳으로 옮겨갔을 뿐이다.
나는 이 발표 전체를 흑백으로 만들었고, 시스템도 흑백으로 만들 수 있었다. 하지만 4색으로 만들었다. 4색이 주는 힘을 상상해 보라.
1비트만으로도 충분히 환기적(evocative)일 수 있다. 화면이 늘 시각적으로 바쁘지 않아도 된다. ‘이 모든 기능이 필요해’, ‘이것도, 저것도 해야 해’라는 극대주의는 피곤하다. 부동소수점 없이 사는 법을 배우는 건 꽤 괜찮다. 정말 단순한 시스템에는 아름다움이 있다. 언제나 모두의 용례에 맞춰 규모를 키우려는 건 어리석다.
마지막으로, 내 시도가 데이터 보존의 최선의 해법이라고 생각하지 않는다. 5년 뒤에도 이 시스템을 쓸 수 있을지조차 모르겠다. 하지만 최소한 보존을 시도하는 한 방법이다.
Permacomputing은 퍼머컬처에서 영감을 얻었고, 목표는 회복탄력성을 구축하는 것이다. 퍼머컬처의 회복탄력성은 다양한 아이디어를 시도하고, 무엇이 남는지 보는 데서 온다. 우리가 모두 같은 언어, 같은 생태계에 올라타면, 누군가가 그것 전체를 사버리는 순간 시스템은 아주 취약해진다. 그러면 애초에 결코 우리의 것이 아니었던 시스템만 남는다.
읽어 주셔서 감사합니다.
