저수준 프로그래밍이 왜 중요한지, 그리고 궁극적으로는 더 나은 ‘새로운 고수준’ 도구와 플랫폼을 만들기 위해 저수준 지식이 왜 필요한지를 논한다.
URL: https://bvisness.me/high-level/
Handmade 커뮤니티를 들어본 적이 있다면, 아마 우리는 어떤 의미에서든 “저수준 프로그래밍”에 관한 커뮤니티라고 생각할 것이다. 우리는 어쨌든 Handmade Hero에서 영감을 받은 커뮤니티다. Handmade Hero는 게임과 엔진을 처음부터 만들어 가는 법을 배우는 시리즈다.
Handmade 커뮤니티의 우리는 소프트웨어 산업의 현주소를 종종 한탄한다. 현대 소프트웨어는 믿기 힘들 만큼 느리고 비대하다. 컴퓨터는 10년 전보다 문자 그대로 열 배나 강력해졌는데, 소프트웨어가 너무 형편없다는 이유만으로 예전보다 더 나쁘게 돌아간다. 손끝에 쥔 미친 성능에도 불구하고 실제 사용자 경험은 수년간 꾸준히 악화되어 왔다. 최악은, 사람들의 기대치가 바닥을 쳤고 모두가 이게 정상이라고 생각한다는 점이다.
(한 번에 앱 12개! 상상이나 되나?)
Handmade 쪽 사람들은 저수준 프로그래밍이 더 나은 소프트웨어를 만드는 열쇠라고 생각하는 듯하다. 하지만 겉으로 보면 이건 잘 이해가 되지 않는다. 평균적인 프로그래머에게 이게 어떻게 실용적일까? 정말로 모두가 UI 프레임워크와 메모리 할당기를 처음부터 만들어야 한다고 기대하나? 정말로 라이브러리를 절대 쓰지 말아야 한다고 생각하나? 설령 평균적인 프로그래머가 그런 방식으로 일할 수 있다 해도, 실제로 뭔가가 나아질까, 아니면 소프트웨어 세계가 더 파편화되기만 할까?
나는 진심으로, 저수준 프로그래밍이 소프트웨어 산업의 더 나은 미래로 가는 길이라고 믿는다. 하지만 앞의 비판들은 타당하며, Handmade 프로그래머에게도 심각한 고민거리여야 한다. 그렇다면 연결고리는 무엇일까? “저수준”이 소프트웨어의 더 나은 미래에서 어떤 역할을 할까?
2019년, 메이커이자 유튜버인 Simone Giertz가 “Truckla”를 공개했다.
Simone은 테슬라 픽업 트럭을 원했지만, 당시 사이버트럭은 아직 소문에 불과했고, 그녀는 참을성이 바닥나 있었다. 그래서 어떤 합리적인 사람이라면 당연히 할 법한 일을 했다. 테슬라 모델 3를 픽업 트럭으로 개조하기로 한 것이다.
결과는 말이 필요 없다. Truckla는 멋지게 생겼고, 완벽히 주행하며, 현대적인 EV로서의 기능도 그대로다. 이건 결코 작은 성취가 아니다. 당연히 세단의 지붕을 잘라내고 픽업이라고 부를 수는 없다. 그녀와 팀은 차체 구조가 건전한지, 여전히 충전이 가능한지, 소프트웨어가 의도대로 동작하는지까지 모두 보장해야 했다. Truckla는 진정한 창의성과 장인정신이 들어간 인상적인 공학적 성취다.
그런데도, Truckla는 여전히 꽤 형편없는 픽업 트럭이다! 적재함이 작고, 무거운 짐을 많이 실을 수 없으며, 바닥부터 트럭으로 설계된 차량보다 효율도 떨어질 가능성이 크다. 픽업 트럭을 살 생각이라면 Truckla를 사지는 않을 것이다! (사이버트럭도 안 살 거 같긴 하지만, 그건 별개의 얘기다.)
Truckla는 결함 있는 아이디어를 훌륭하게 실행한 사례다. 좋은 픽업 트럭을 만들고 싶다면, 프레임에서부터 시작해야 한다.
소프트웨어 세계에서 “프레임”에 해당하는 것은 기술 스택이다. 소프트웨어는 자동차가 프레임에 의해 형태가 결정되듯이, 프로그래밍 언어, 프레임워크, 라이브러리, 플랫폼에 의해 형태가 결정된다. 세단을 트럭으로 개조하면 나쁜 트럭이 나오듯, 잘못된 스택에서 시작하면 나쁜 소프트웨어가 나온다. 어떤 공학적 노력으로도 이를 구할 수 없다.
예로, 누구나 한 번쯤은 상호작용해 본 프로그램을 보자.
이것은 뉴 레딧(New Reddit)이다. 대략 10년 전쯤 배포된 새 프런트엔드인데… 그다지 사랑받지 못한다. 너무 많은 사람들이 싫어해서 올드 레딧(Old Reddit)이 아직도 살아 있고, 덕분에 10년 간격으로 만들어진 기능적으로 동일한 소프트웨어 두 개를 비교할 수 있는 독특한 기회가 생겼다.
2023년에 나는 뉴 레딧에서 끔찍한 렉을 겪고 있었다. 댓글 편집기는 굼떴고, UI는 펼치고 접는 동작이 느렸으며, 툴팁에 마우스를 올리는 것만으로도 페이지 전체가 덜컥거렸다. 전형적인 현대 소프트웨어의 모습이다. 반면 올드 레딧은 신선한 공기 같았다. 모든 것이 즉각 반응했다. 미적으로는 낡았지만, 그걸 제외하면 올드 레딧이 모든 면에서 더 나았다.
그럼 사고 실험을 하나 해보자. 댓글 하나를 접는 데 얼마나 일이 많아야 할까?
아주 쉬운 질문이다. 일어나야 하는 일, 일어나야 마땅한 일은 DOM 요소 몇 개를 숨기거나 제거하고, 텍스트 몇 개를 “접힘(collapsed)”으로 바꾸는 것뿐이다. 잘 작성된 레딧 프런트엔드는 대체로 정확히 이렇게 해야 한다. 그런데 뉴 레딧은 무엇을 했을까?
끔찍하다. 30단계 깊이의 콜스택, 렌더링 중간에 레이아웃 계산, 무슨 이벤트나 애니메이션 프레임워크… 그리고… 잠깐만, 저거 jQuery인가?
내 실수다. 이건 사실 올드 레딧의 프로파일이다. 뉴 레딧은 이거다:
당시 뉴 레딧은 댓글 하나를 접는 데 거의 200ms가 걸렸다. DOM 작업은 거의 보이지 않는데 순수 자바스크립트만 200ms다. 품질 좋은 소프트웨어를 신경 쓰는 사람이라면 턱이 바닥에 떨어져야 정상이다. 몇 번의 DOM 호출이면 될 일을 위해 엄청난 낭비가 벌어진 것이다. 그리고 사용자로서 그게 느껴진다. 보기 싫고 강렬한 버벅임.
반면 올드 레딧은 대략 10ms 정도로 일을 끝냈다. 더 개선할 수는 있겠지만 10ms면 충분히 괜찮다. 반응성이 좋고 사이트를 60fps로 유지한다. 결국 UI 속도에서 올드 레딧이 뉴 레딧보다 20배 빠른 명확한 승자다.
이제 우리는 턱을 주워 담고 질문해야 한다. 대체 어떻게 여기까지 온 걸까? 뉴 레딧 개발자들이 그냥 멍청하고 게으른 JS 광신도라서 루브 골드버그 장치 만들듯이 일을 한 걸까?
어쩌면, 솔직히 그럴 수도 있다. 하지만 게으름만으로는 전부를 설명할 수 없다. 뉴 레딧의 진짜 문제는 그들이 사용한 스택이었다.
그럼 레딧의 스택은 무엇이었나? 2023년 무렵 뉴 레딧은 상태 관리로 Redux를 사용하는 React 앱이었다. (요즘은 Web Components로 다시 쓴 것처럼 보인다.) React와 Redux는 물론 웹 플랫폼 위에 놓인다. HTML, CSS, JavaScript. 이 플랫폼은 어떤 브라우저 엔진에 의해 구현되고, 그 엔진은 운영체제 위에서 실행되며, 최종적으로 사용자의 물리 하드웨어 위에서 돌아간다(하드웨어 자체도 극도로 복잡하지만, 어디선가 멈춰야 한다).
내 마지막 직장에서 나는 정확히 같은 스택을 쓰는 애플리케이션을 작업했다. 직원 스케줄링 프로그램으로, 관리자가 시급제 근로자를 위한 주간 근무표를 만들 수 있었다. 대략 2016년에 우리는 낡은 Backbone.js 프런트엔드를 React+Redux로 새로 교체했는데, 아마 당시 유행하던 선택이었기 때문일 것이다.
그 결과, 나는 React+Redux 앱이 어떻게 구성되는지 속속들이 알게 되었다. 그리고 앱의 형편없는 성능을 개선하려고 많은 시간을 썼다. 나는 크롬 프로파일러와 React 프로파일러 안에서 살다시피 하며 느린 함수를 꾸준히 추적하고 불필요한 React 업데이트를 억제했다. Redux 셀렉터를 위한 캐시 시스템 전체가 있었고, 캐시 미스율이 높은 셀렉터를 찾기 위해 로깅을 추가하기도 했다. 소스 코드를 파싱해 셀렉터 의존성 그래프를 그리는 스크립트를 만들어 앱 번들을 더 작은 조각으로 쪼갤 지점을 찾기도 했다. 하지만 불행히도 내 노력은 큰 차이를 만들지 못했다. 앱이 복잡해질수록 성능은 계속 추락했다.
빠른 React+Redux 앱을 만들려 하면, 항상 프레임워크와 싸우게 된다. 이 두 라이브러리는 늘 불필요한 일을 하고, 당신의 일은 그 일을 다시 “억제”해서 겨우 용인 가능한 수준으로 돌려놓는 것이다. 하지만 때로는 치료가 독보다 더 나쁘다. 비싼 shouldComponentUpdate를 쓰느냐, 비싼 React 리렌더를 감수하느냐. 모든 것이 항상 업데이트되길 원하고, 앱이 커질수록 업데이트의 빈도와 복잡성이 늘어나서 결국엔 구제할 수 없게 된다.
뉴 레딧은 이를 완벽히 보여줬다. 댓글을 접으면 Redux 액션이 디스패치되고, 전역 Redux 스토어가 업데이트되며, 페이지의 모든 Redux-connected 컴포넌트가 업데이트되고, 그 자식들도 함께 업데이트된다. 즉, 댓글 하나를 접는 동작이 페이지의 거의 모든 React 컴포넌트를 업데이트하게 만든다. 이 정도 낭비는 캐싱, DOM diff, shouldComponentUpdate로도 구할 수 없다.
결국 나는 이 스택 위에서 빠른 앱을 만드는 건 불가능하다는 결론에 도달했다. 그 뒤로도 똑같은 방식으로 고통받는 웹 앱을 많이 마주쳤다. 거듭해서, 느리면 아마 React를 쓰고 있고, 정말 느리면 아마 Redux를 쓰고 있다. 문제는 스택이다. 이것 말고 합리적인 결론이 없다.
다행히도 React+Redux만이 가능한 스택은 아니다. 우리는 모든 지점에서 대안을 선택할 수 있다.
이 모든 선택은 실제로 하나의 트리를 이룬다. 이 트리의 모든 노드는 소프트웨어를 구축할 때 선택할 수 있는 유효한 스택이다. 무엇보다 중요한 점은, 이 트리에서 어떤 선택을 하느냐에 따라 어떤 종류의 소프트웨어에 더 적합한지가 달라진다는 것이다. 따라서 다양한 선택지에 익숙하면 문제마다 더 나은 선택을 할 수 있다.
불행히도, 나는 뉴 레딧의 개발자들이 트리를 이렇게 봤을 것이라 상상한다:
선택지가 많지 않다. 결정적으로 그들에게 최선이었을 선택(올드 레딧처럼 DOM을 직접 조작하는 것)이 아예 선택지로 올라오지도 않았다. 무슨 이유에서든, 그들은 그걸 옵션으로 고려조차 하지 않았던 것 같다. 으, 징그러, 올드 레딧이 하던 걸 그대로 하면 안 되지! jQuery를 쓸 수는 없잖아!
그들의 세계관은 너무 고수준이었다. React만 알면 선택지가 없다. React를 쓰거나, React 위의 메타 프레임워크를 쓸 뿐이다. 하지만 더 저수준으로 내려갈수록 트리는 더 크게 열린다. 더 낮은 수준으로 내려가면 다른 선택지에 접근할 수 있고, 다른 선택이 더 잘 맞는 상황을 알아챌 수 있다.
따라서 우리가 저수준을 신경 쓰는 첫 번째 이유는, 저수준이 더 나은 선택을 가능하게 해주기 때문이다. 올바른 프레임, 올바른 스택에서 _시작_함으로써 더 나은 소프트웨어를 만들 수 있다. 저수준 프로그래밍은 Truckla가 아니라 트럭을 만들 수 있게 해준다.
하지만… 이것만으로는 충분하지 않지 않은가? 소프트웨어 산업은 몇몇 프로그래머가 더 나은 선택을 한다고 해서 구원받지 않는다. 물론 도움이 되겠지만, 답과는 거리가 멀다.
여기서 불편한 질문이 생긴다. 이 트리 안에 좋은 옵션이 하나도 없다면 어떨까? 우리가 만들고 싶은 종류의 소프트웨어에 실제로 적합한 선택지가 없다면?
예컨대 앱이 하드웨어에 직접 접근하길 원하면서도, 크로스플랫폼 UI가 필요하다면 선택지가 무엇이 있나? Qt를 쓸 수는 있지만, 느낌이 매우 구식이고 소프트웨어 아키텍처에 대해 강한 의견을 강요하는 편이다. 게임 엔진도 많은 앱엔 어색한 선택이다. 렌더링 파워는 충분하지만 2D UI에 대해서는 제공하는 것이 적다. Flutter 같은 비교적 신참도 있지만, Flutter는 Dart에 올인해야 하고, 우리는 모두 Dart가 성능 집약적 애플리케이션에 맞는 도구가 아니라는 걸 안다. 그럼 어떻게 해야 할까? 시장에 좋은 선택지가 없다면 결국 직접 만들어야 한다.
우리의 트리는 위쪽이 지나치게 무겁다. 오늘날의 소프트웨어 개발 지형을 둘러보면, 말도 안 될 정도로 많은 자바스크립트 라이브러리와 프레임워크, 계속 늘어나는 브라우저 API, 그리고 브라우저 밖에서는 Web 호환 프레임워크(즉, 같은 제약을 받는 것들) 외에는 거의 개발이 없다. 만약 이 트리가 실제 나무라면 대략 이렇게 생겼을 것이고, 이는 건강한 나무가 아니다.
실제로 이 비유는, 죽었거나 죽어가는 가지가 얼마나 많은지까지 고려하면 더 잘 들어맞는다. 요즘 JS 프레임워크 수명은 얼마나 될까? 2년? 운이 좋으면 5년? 그보다도 더 흔하게는, 개발자가 한 달 만에 세상에서 사라져버리기도 한다.
우리는 정말로 소프트웨어 산업의 미래가 이 트리를 더 키가 크고 길쭉하게 만드는 것이라고 상상하나? 위에 더 올리는 것? 프레임워크 위에 프레임워크? HTML과 CSS가 수년째 명백히 잘못된 선택이었는데도, 미래에도 여전히 정교한 애플리케이션을 HTML/CSS로 만들 거라고 상상하나? 현대 브라우저는 사실상 운영체제 그 자체인데도, 앞으로도 브라우저 위에, 운영체제 위에 앱을 계속 올려 얹어 배포할 거라고 상상하나?
계속 쌓기만 하면 이 트리는 자기 무게에 눌려 무너진다. 가지치기가 필요하고, 더 낮은 곳에서 새로운 가지를 키워야 한다.
그런데 누가 그걸 할까? 누가 소프트웨어 산업의 미래를 만들까?
특정한 유형의 사람이 필요하다. 소프트웨어 혁신을 향한 내재적인 추진력과 열정이 있어야 한다. 동시에 저수준 지식도 있어야 한다. 앞선 사람들과 다른 선택을 하고, 아직 탐험되지 않은 트리의 부분을 탐험할 수 있어야 한다.
이 두 원의 교집합은 극히 작다. 두 범주에 동시에 속하는 사람이 너무 적어서, 그 영역에서 혁신이 거의 일어나지 않는다. 사실 저수준 프로그래머 자체가 얼마나 적은지 생각하면, 이 그림은 꽤 후하게 그린 편이다.
반면 소프트웨어 산업에는 혁신 의지가 있는 사람이 실제로 많다. 문제는, 그들이 모두 자바스크립트 프레임워크를 만들고 있다는 것이다.
그들은 의미 있는 변화를 만들기 위해 필요한 저수준 지식을 갖고 있지 않다. 이것이 현실이다. 트리의 꼭대기에서만 만든다면, 중요한 결정들은 이미 모두 내려진 상태다. Truckla를 다른 색으로 칠하는 것과 같다. 아무 차이가 없다!
그래서 내가 저수준이 소프트웨어 산업의 미래에 결정적이라고 믿는 두 번째 이유는, 그것이 단순히 원을 확장해 주기 때문이다. 혁신 의지가 있는 사람들 중 일부를 끌어와서, 실제로 의미 있게 혁신할 수 있도록 무장시킬 수 있다. 우리는 더 많은 사람이 이 저수준 공간을 탐험해야 하고, 많은 사람에게 저수준 지식은 전에 상상도 못 했던 가능성을 보게 해줄 것이라고 나는 확신한다.
자기 텍스트 에디터를 만드는 모든 사람이 프로그래밍의 미래에 대한 훌륭한 아이디어를 갖는 것은 아니다. 자기 컴파일러를 만드는 모든 사람이 프로그래밍 언어에 대한 훌륭한 아이디어를 갖는 것도 아니다. 하지만 그들 중 _일부_는 그럴 것이다. 그리고 소프트웨어 산업에 변화를 만들기 위해서는 그런 소수면 충분하다.
정리하자. 우리가 저수준을 신경 쓰는 첫 번째 이유는 저수준 지식이 더 나은 엔지니어링 선택으로 이어지기 때문이다. 두 번째 이유는 장기적으로 저수준 지식이 더 나은 도구와 더 나은 프로그래밍 방식으로 가는 길이기 때문이다. 즉, 미래의 플랫폼을 만들기 위한 _필수 조건_이다.
하지만 여기에는 아직 큰 문제가 하나 있다. 오늘날의 저수준 프로그래밍은 정말로 끔찍하다.
저수준 프로그래밍은 너무 좌절스럽고 너무 어렵다. 오늘날의 고수준 도구를 사용하는 경험과 비교하면, 저수준 프로그래밍의 _경험_은 상대가 되지 않는다. 우리가 문제라고 보는 바로 그 도구들 말이다.
React 앱을 만들고 싶다면, 구글에 “how to build react app”만 검색해도 아름답게 정리된 웹 페이지가 나온다. 데모, 설치 가이드, 문서, 리소스가 있고, 5분 안에 앱을 띄우게 해주는 명령도 있다. 에디터에서 코드 한 줄을 바꾸면 브라우저에서 즉시 새로고침되어 피드백 루프가 짧아지고, 학습이 재미있어진다. 그리고 온라인에는 더 많은 리소스가 있다. 개발 도구, 라이브러리, 튜토리얼 등등. 누구나 쉽게 시작할 수 있다.
저수준 공간은 전혀 그렇지 않다. 운이 좋으면 비싼 책이나 강의를 찾을 수 있을지도 모른다. 하지만 더 흔하게는, 시스템의 모든 속성을 고통스러울 정도로 나열한 거대한 매뉴얼을 받게 된다. 학습에는 완전히 무가치하고 참고용으로도 거의 쓰기 어렵다. 그리고 그건 운이 좋은 경우다. 위키 하나거나, 미로 같은 man 페이지뿐일 가능성이 크다. 전문용어로 가득한 난공불락의 벽이다. 어떤 경우엔 존재하는 문서가 Linux Kernel Mailing List뿐이기도 하고, 질문에 답해줄 수 있는 단 한 사람이 지난 10년 사이에 번아웃으로 사라지지 않았기를 기도해야 한다.
이건 초보자에게만 나쁜 게 아니라 _모든 사람_에게 나쁘다. 저수준 지식의 상태가 이렇다면, 어떻게 누구에게 저수준 프로그래밍을 하라고 기대할 수 있나? 더 넓은 산업은 말할 것도 없다.
그리고 이야기는 여기서 끝나지 않는다. 저수준 _도구_도 끔찍하다. 브라우저에서는 개발자 도구를 열고 Performance로 가서 “Record”를 누르면, 애플리케이션이 한 모든 일의 완전한 타임라인을 얻는다. 모든 자바스크립트 함수, 모든 네트워크 요청, 모든 렌더된 프레임이 한 타임라인에 상관관계로 묶여 있어, 전체를 이해할 수 있다. 개발자의 꿈이며, 클릭 한 번이다! 하지만 저수준 공간에는 이런 도구가 없다. 괜찮은 프로파일러가 몇 개 있긴 하지만, 대개 이상한 플래그 조합으로 커맨드라인 프로그램을 돌리고, 다른 도구로 파이프 처리하고, PDF 같은 걸 눈을 가늘게 뜨고 봐야 한다.
미친 점은 그럴 이유가 전혀 없다는 것이다. 네이티브 개발에도 웹과 같은 종류의 “개발자 도구”를 충분히 만들 수 있다. 유용한 정보를 강조하도록 설계된 프로파일러를 만들 수 있다. 네트워크/파일 I/O, 프로세스 간 통신을 보여주는 GUI도 가능하다. 대화형 문서와 라이브 리로딩도 가능하다. 초보자를 돕는 에디터 플러그인과 언어 서버도 가능하다. 원재료는 이미 다 있다. 우리는 고수준 감각을 가진 누군가가 와서 꿈의 도구들을 만들어 주기만을 기다리고 있을 뿐이다.
하지만 그걸 만들기 전까지, 왜 누구에게 저수준 프로그래밍을 배우라고 기대해야 할까? 어떻게 기대할 수 있을까?
이제 우리는 Handmade로 돌아가서, Handmade Hero가 왜 특별했는지 보게 된다. 대부분의 프로그래머는 게임 엔진을 보고 초천재만이 만들 수 있다고 생각한다. 엔진 없이 게임을 만드는 건 미친 짓이라고 여긴다. 하지만 Handmade Hero는 그런 걸 신경 쓰지 않았다. Casey는 그냥 앉아서 C 컴파일 방법을 보여주고, 화면에 픽셀을 찍는 법을 보여줬고, 얼마 지나지 않아 당신은 게임을 갖게 된다. 세상에서 가장 정교한 게임은 아닐지라도, 어쨌든 게임이다.
Handmade Hero는 저수준과 고수준 사이의 장벽을 부쉈다. Casey는 게임을 만들었고, 그리고 엔진도 만들었다. 신비감은 벗겨지고, 게임이 어떻게 만들어지는지에 대한 실제 이해로 대체되었다. 많은 사람이 Handmade Hero를 끝까지 보고 나면 같은 반응을 한다. “어, 이거 생각보다 어렵지 않네!” 온라인의 비관론자들에도 불구하고, 자기 엔진을 만드는 것이 _충분히 가능_하다는 사실이 드러난다.
개인적으로 나는 많은 “저수준” 분야에서 이것이 사실임을 느꼈다. “저수준” 프로그래밍은 불가능하지 않다. 오히려 많은 경우, 내가 예전에 했던 고수준 웹 개발보다 _더 단순_하다! 오늘날의 “고수준” 프레임워크와 도구는 너무 복잡하고 너무 잘못 설계되어 있어서, 저수준 대응물보다 더 이해하기 어렵고 다루기 어렵다. 그런데 Svelte, Symfony, Kubernetes 같은 현대의 온갖 것들은 문서가 있다! 개발 도구가 있다! 이상하게도 사람들은 그걸 무서워하지 않는다!
저수준 프로그래밍은 인위적으로 끔찍해졌다. 나는 정말 그렇게 믿는다. 그리고 이렇게일 필요가 없다는 것도 안다.
그래서 저수준 프로그래밍에 대한 마지막 질문은 이것이다. 우리는 왜 이것을 “저수준”이라고 부를까?
어떤 “고수준” 도구의 의도는 프로그래머로서의 의도를 더 쉽게 표현하도록 만드는 것이다. “고수준” 도구는 어려운 디테일을 추상화해 우리가 정말로 중요하게 여기는 것에 집중하도록 한다. 그리고 많은 경우 이는 성공했다. 프로그래밍 언어의 진화에서, 게임 엔진의 확산에서, 그리고 그렇다, 웹 개발에서도 우리는 그것을 봤다.
하지만 주목하라. 이것은 스택에서 도구가 어디에 위치하느냐의 문제가 아니다. 위에 얼마나 많은 레이어를 더 얹었느냐의 문제가 아니다. “고수준”이란 프로그래머의 의도를 표현하는 방식에 관한 것이다. 프로그래머가 목표를 달성하는 데 쓸 수만 있다면, 스택에서의 위치는 궁극적으로 중요하지 않다.
그렇다면 “저수준”은 무엇을 의미하나? 결론은 피할 수 없다. 우리가 어떤 것을 “저수준”이라 부르는 이유는, _사용하기 끔찍하기 때문_이다. 우리는 그것들을 직접 사용하지 않기 때문에 “저수준”이 된다! 우리가 그것들을 카펫 아래로 쓸어 넣고, 그 위에 추상화를 쌓기 때문에, 그것들은 우리가 더는 만지고 싶지 않은 “저수준”이 되어 버린다!
오늘날 왜 어떤 것들은 “저수준”일까? 아직 아무도 그것들을 고수준으로 만들어주지 않았기 때문이다.
내가 소프트웨어 산업의 더 나은 미래를 상상할 때, 나는 모두가 자기 텍스트 에디터, 자기 디버거, 자기 UI 프레임워크를 만드는 미래를 상상하지 않는다. 대신, 스택의 더 아래쪽에서 만들어진 새로운 “고수준” 도구들이 있는 미래를 상상한다. 오늘날 우리가 기대하는 고수준의 이점을 제공하는, 그리고 과거의 제약적 결정들로부터 자유롭기 때문에 오늘날의 도구보다 _더 많은 것_을 할 수 있는, 그런 새 도구들 말이다. 우리는 과거로부터 배우되, 위에 더 쌓아 올리는 대신 단단한 토대 위에 세우는 새로운 플랫폼, 새로운 도구, 새로운 라이브러리를 만들 수 있다.
고품질 소프트웨어를 진정으로 중요하게 여기는 개발자들에게, 스택의 더 아래에서 만들어진 도구들은 초능력이 될 수 있다. 이 프로그래머들은 웹이 결코 허락하지 않는 방식으로 소프트웨어를 미세 조정할 수 있다. 그리고 월급 받으려고 대충 찌꺼기를 문밖으로 밀어내고 싶은 게으른 레딧 개발자에게도? 뭐, 최소한 그들의 찌꺼기는 더 단순하고, 더 작고, 더 효율적인 플랫폼에서 돌아갈 수 있다. 결국에는 순이익이다.
Handmade 커뮤니티는 오늘날 그 벤 다이어그램의 정확히 한가운데에 있다. 우리는 저수준 전문성을 가진 사람들이 있다. 소프트웨어를 더 낫게 만들고자 하는 추진력을 가진 사람들도 있다. 그러므로 우리의 일은 저수준 코드를 그냥 쓰면서 ‘작동 원리를 아니까 우월하다’고 뿌듯해하는 것이 아니다. 우리의 일은 소프트웨어 산업 나머지에게 제공할 새로운 고수준을 만드는 것이다.
저수준 프로그래밍은 그 자체로 목표가 아니다. 고수준 프로그래밍—새로운 종류의 고수준 프로그래밍—이 목표이며, 저수준은 그곳으로 가는 방법이다.
이 글은 2023년에 Handmade 커뮤니티에 했던 내 발표를 바탕으로 각색한 것이다. 원래 발표는 여기에서 볼 수 있다.
