코드 양이 적다는 것은 단순한 미학적 취향일까, 아니면 실질적인 가치가 있는 선택일까. 블로거 ratfactor는 "작은 것"에 끌리는 개발자들의 심리를 짚으면서, 작은 프로그램과 작은 프로그래밍 언어가 왜 흥미롭고 또 의미 있는지를 여러 사례를 통해 풀어낸다. 그의 출발점은 소박하다. 어떤 코드가 2,000줄이나 20,000줄이면 읽을 엄두가 나지 않지만, 200줄이라면 읽어볼 마음이 생긴다는 것이다. 더구나 2,000줄은 될 거라 예상했던 기능이 20줄로 구현돼 있다면, 그 20줄은 오히려 강렬한 호기심의 대상이 된다.
작다는 사실이 증명하는 것
필자가 DOM diffing 라이브러리를 조사하던 중 발견한 Luke Jackson의 ijk는 단 25줄짜리 소스였고, 그 작음 자체가 즉각적인 흥미를 불러일으켰다. 더 극단적인 사례도 있다. Forth 구현에 관한 그의 글에 Philippe Brochard가 46바이트짜리 "Forth"로 응답한 것이다. 거의 아무도 날것의 기계어를 즐겨 읽지는 않지만, 바로 그 점이 핵심이라고 그는 말한다. 46바이트라면 겁나지 않는다. 노력을 들이면 언젠가 작동 원리를 파악할 수 있으리라는 확신이 든다.
반대로 밀도가 지나쳐 두려움을 주는 코드도 있다. Roger K.W. Hui가 J 구현 논문의 부록 "Incunabulum"에서 소개한, Arthur Whitney가 하루 오후에 한 페이지로 써 내려간 배열 언어 인터프리터 조각이다. 122줄의 극도로 난해한 C 코드로, Hui조차 그 구조와 스타일을 파악하는 데 일주일을 들였다고 한다. 2026년 7월 추가된 사례는 더 놀랍다. Geo Carncross가 소개한 kOS는 Whitney의 k 언어와 kdb 데이터베이스, GUI와 윈도우 매니저까지 담아 90KB 부팅 이미지로 구성되며, GUI와 윈도우 매니저는 60줄의 C, kdb는 100줄의 C로 알려져 있다.
코드 골프의 진짜 의미
필자는 코드 골프가 단순한 오락을 넘어 의미를 지닌다고 주장한다. 명함 한 장에 들어가는 레이트레이서를 보면, 레이트레이서란 명함에 담길 수 있는 것이라는 사실 자체를 깨닫게 된다. 이는 그 프로그램의 최소 복잡도에 관한 엄연한 사실이다. 그는 이를 콜모고로프 복잡도, 즉 어떤 결과물을 출력하는 가장 짧은 프로그램의 길이라는 개념과 연결한다. 이 관점에서 코드 골퍼들은 인류를 위해 각 프로그램의 최소 복잡도 버전을 제시하는 셈이다. Justine Tunney 덕분에 우리는 가비지 컬렉션을 갖춘 LISP가 436바이트까지 줄어들 수 있음을 알고, Frank Force 덕분에 3D 브라우저 게임이 2KB의 JavaScript에 담길 수 있음을 안다.
중요한 포인트는 이 미니어처들을 직접 해독할 필요는 없다는 데 있다. 미니어처는 "이 개념이 명함에, 그리고 내 머릿속에 들어갈 만큼 작아질 수 있다"는 사실을 증명하는 역할이면 충분하다. 실제 학습은 읽기 좋은 다른 버전으로 하면 된다. 다만 미니어처도 가르쳐 주는 것이 많은데, 그중 일부는 "어떻게 하면 프로그램을 작게 만드는가"에 관한 것이다.
언어의 크기와 표현력
논의는 작은 언어로 옮겨 간다. 일반적으로 언어가 작을수록 표현력은 떨어진다. 가장 단순한 쪽 끝에는 어셈블리가 있는데, 사실상 옵코드 니모닉의 나열일 뿐이어서 CISC와 RISC의 구문이 거의 같다는 점이 역설적으로 그 언어성의 빈약함을 증명한다. 반면 구문이 극도로 작으면서도 강력한 언어로 필자는 Forth, Lisp, Tcl을 꼽는다. Forth의 유일한 구문 요소는 공백 문자이고, Lisp(특히 Scheme)은 작은 핵심에 거대한 표현력을 담으며, Tcl은 모든 것이 문자열이라는 발상 위에서 자신만의 언어를 구성하게 해준다. 세 언어 모두 핵심 구문은 색인 카드 한 장에 담기지만, 이를 능숙하게 다루려면 기존 Algol 계열 절차적 언어와는 근본적으로 다른 사고 전환이 필요하다.
그래서 작으면서도 희생을 요구하지 않는 대안으로 그는 Lua를 든다. 핵심 언어 설명이 27쪽에 불과하다는 것이다. C 역시 작지만 안전하게 다루기는 쉽지 않고, Zig는 C를 닮았으되 효과적으로 쓰려면 꽤 많은 부분을 알아야 하는 사실상 큰 언어라고 평가한다. JavaScript의 핵심은 함수·배열·객체 정도로 Lua와 비슷한 규모라고 본다. 방향 선택의 기준에 대해 그는 David Ungar의 Self 강연을 인용한다. 시스템이 이상하게 동작해 아무도 이유를 모르게 되느니, 조금 지나치게 단순해서 사람이 코드를 두 번 쓰더라도 낫다는 것, 즉 단순함이 표현력을 이긴다는 것이다.
실무자에게 남는 것
마지막으로 그는 언어의 체감 크기를 좌우하는 표준 라이브러리 문제도 짚는다. JavaScript의 함수형 라이브러리 Ramda를 배우는 일은 새 언어를 배우는 것과 다름없었고, 결국 전부 익히지 못했다는 고백은 라이브러리에도 동일한 크기 대 표현력의 긴장이 존재함을 보여준다. 그의 조언은 "Ramda는 조금만 써도 멀리 간다"는 것이다. 또한 좋은 문서가 컴파일러와 함께 설치되고 초보자도 이해할 수 있는 오류 메시지를 제공한다면, 텍스트 파일 기반 언어도 자족적 학습 환경, 즉 마이크로월드가 될 수 있다고 본다.
이 글은 벤치마크나 성능 수치를 제시하는 분석이 아니라, 한 개발자의 취향과 통찰을 엮은 에세이에 가깝다. 소개된 436바이트 LISP나 100줄 kdb 같은 수치 중 일부는 필자 자신도 전해 들은 것이어서 확정된 사실로 받아들이기보다 참고로 두는 편이 좋다. 그럼에도 실무적으로 되새길 만한 교훈은 분명하다. 작게 만드는 일은 단지 과시가 아니라 어떤 개념의 최소 복잡도를 드러내고, 큰 시스템을 손에 잡히는 크기로 만들어 접근 가능하게 한다. 도구를 고를 때 무조건 표현력이 풍부한 쪽을 택하기보다, 팀이 끝까지 이해하고 통제할 수 있는 단순함을 먼저 따져보라는 권유로 읽을 수 있다.