어제와 오늘 linenoise (http://github.com/antirez/linenoise), readline을 대체하기 위해 만들어진 작고 단순한 라인 에디팅 라이브러리와 함께 시간을 보냈다.
몇 개의 풀 리퀘스트를 머지하고 이슈를 수정하며 동시에 약간의 리팩터링을 진행했다. 일종의 니르바나 같은 느낌이었다. 작고, 스스로 완결되며, 유용한 코드에 대한 완전한 통제감이었다.

단순한 코드에는 특별한 무언가가 있다. 여기서 말하는 단순함은 복잡성이나 오버 엔지니어링에 맞서기 위한 단순함이 아니다. 그 자체로서, 자기 목적적인 단순함, 아름다움과 이해하기 쉬움, 우아함 외에는 다른 목표가 없는 단순함이다.

어쨌든 프로그래밍 세계는 언제나 작은 프로그램에 매료되어 왔다. 수십 년 동안 프로그래머들은 6502 어셈블리부터 오늘날의 JavaScript 콘테스트에 이르기까지 1K나 4K라는 제약 속에서 도전해 왔다.
난독화 C 콘테스트조차 결국 미니멀리즘이라는 큰 요소를 담고 있다.

왜 작은 코드 조각을 해킹하는 일이 그토록 멋진 것일까? 물론 작고 단순하다는 것 자체가 두 가지 장점이다. 완전히 이해하고 지배할 수 있다. 영리함을 발휘할 수도 있다. 작은 코드는 코딩에서의 영리함이 보상을 받는 세상에서 유일한 곳이기 때문이다. 대규모 프로젝트에서는 장기적으로 뻔하고 명확한 것이 훨씬 낫다. 하지만 나는 그 이상의 무언가가 있다고 믿는다. 작은 프로그램은 완벽해질 수 있다는 것이다. 몇 개의 단어로 이루어진 소네트처럼 완벽해질 수 있다. 크기와 범위의 제약은 “더 나아질 수 있다”는 함정을 피하게 해주는 지적 책략이다. 그 ‘더 나음’이 실제로 측정 가능하거나 자명하지 않을 때 말이다. 이런 엄격한 제약 하에서는 프로그램이 하지 않는 것보다 하는 것이 훨씬 더 흥미롭다. 사실 제약이야말로 해결책의 창의성을 위한 가장 비옥한 토양이다. 그렇지 않다면 대체로 쓸모없을 창의성이겠지만, 규모가 커지면 모든 것을 처리하는 더 올바르고, 더 잘 이해되며, 정석적인 방법이 항상 존재하기 때문이다.

마이크로소프트 초기 시절 빌 게이츠의 인터뷰가 있다. 그는 유명한 Microsoft BASIC 인터프리터를 작성할 때 느꼈던 이런 감정을 묘사한다. 그때의 제약은 오늘날 우리가 재미로, 콘테스트에서, 혹은 그 자체를 위해 스스로에게 부과하는 제약과 동일했다. 자신의 창작물에서 완벽함을 경험할 수 있었던 프로그래머 세대가 있었다. 공간과 시간이 극도로 부족했던 그 영역에서는 어떤 변경이 실제로 프로그램의 개선으로 이어졌는지 측정하고 이해하는 것이 명백했다. 낭비나 불필요한 복잡성이 들어설 자리는 없었다.

오늘날의 소프트웨어는 어떤 면에서 소프트웨어의 또 다른 현실이 승리한 결과다. 복잡성의 층위가 쌓여 비전문가의 손에서도 수많은 가능성을 끌어내는 놀라운 기기와 인프라 기술을 만들어냈다. 하지만 소프트웨어가 완벽해질 수 있었던 옛 시절로부터 여전히 지켜야 할 무언가가 있을지도 모른다. 자신이 만들고 있는 것이 단순히 동작하는 코드 더미가 아니라 구조를 가지고 있다는 느낌 말이다. 충분히 멀리서 보면 당신의 거대한 프로그램도 사실 다시 아주 작게 보인다. 그리고 적어도 그 규모에서는 완벽함을 닮아야 한다. 혹은 적어도 그것을 지향해야 한다.