어제와 오늘 저는 linenoise에 시간을 들일 수 있었습니다. (http://github.com/antirez/linenoise) linenoise는 readline을 대체할 수 있도록 설계된 단순하고 작은 라인 편집 라이브러리입니다. 저는 몇 가지 풀 리퀘스트를 병합하고 이슈를 수정하면서 동시에 리팩토링을 하고 있었습니다. 그때 저는 일종의 열반과 같은 느낌을 경험했습니다. 작고, 자체 완결적이며, 유용한 코드를 완전히 장악하고 있다는 느낌이었습니다.

단순한 코드에는 특별한 무언가가 있습니다. 여기서 말하는 단순함은 복잡성이나 과도한 엔지니어링에 대항하기 위한 단순함이 아닙니다. 그보다는 단순함 그 자체, 즉 스스로 목적이 되어 아름다움과 이해 가능성과 우아함만을 추구하는 그런 단순함입니다.

어쨌든 프로그래밍 세계는 항상 작은 프로그램에 매혹되어 왔습니다. 수십 년 동안 프로그래머들은 6502 어셈블러에서 오늘날의 자바스크립트 콘테스트에 이르기까지 1K 또는 4K의 제약 속에서 도전해 왔습니다. 난독화된 C 콘테스트조차도 그 핵심에는 미니멀리즘이 크게 자리하고 있습니다.

작은 코드 조각을 해킹하는 일은 왜 이토록 멋질까요? 일단 작고 단순하다는 점이 좋은 이유입니다. 코드 전체를 이해하고 완전히 장악할 수 있습니다. 작은 코드는 세상에서 유일하게 코딩의 영리함이 보답을 받는 곳입니다. 대규모 프로젝트에서는 명확함이 장기적으로 훨씬 낫기 때문입니다. 하지만 저는 그 이상이 있다고 믿습니다. 작은 프로그램은 완벽해질 수 있다는 것입니다. 몇 개의 단어로 이루어진 소네트처럼 완벽해질 수 있습니다. 크기와 범위의 제약은 '이게 더 나을 수도 있다'는 함정을 피하기 위한 지적인 전략입니다. 그 '더 나음'이 실제로 측정 가능하거나 분명하지 않을 경우에 말이죠. 이러한 엄격한 제약 아래에서는 프로그램이 하지 못하는 일보다 하는 일이 훨씬 더 흥미로워집니다. 실제로 제약은 창의적인 해결책을 위한 더 비옥한 토양이 됩니다. 제약이 없다면 쓸모없을지도 모를 해결책들 말입니다. 규모가 커지면 어떤 일을 하든 언제나 더 정확하고, 더 잘 이해되고, 더 표준적인 방법이 존재하기 때문입니다.

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

오늘날의 소프트웨어는 어떤 면에서 소프트웨어의 또 다른 현실이 승리한 것입니다. 복잡성의 층위는 우리에게 놀라운 기기와 인프라 기술을 제공했고, 이는 비전문가의 손에서도 수많은 가능성을 활용하게 해 줍니다. 하지만 소프트웨어가 완벽해질 수 있었던 고대의 시대에서 여전히 보존해야 할 무언가가 있을지도 모릅니다. 자신이 만드는 것이 단지 동작하는 코드 더미가 아니라 어떤 구조를 가지고 있다는 느낌 말입니다. 충분히 줌 아웃하면 여러분의 대규모 프로그램은 다시 아주 작아 보입니다. 그리고 적어도 이 규모에서는 완벽함과 닮아야 하며, 최소한 완벽함을 지향해야 합니다.