프로그래머의 미덕과 LLM의 역설

래리 월(Larry Wall)은 프로그래밍 관련 고전 『Programming Perl』(흔히 "Camel Book"으로 불림)에서 프로그래머의 세 가지 미덕을 언급했습니다. 바로 게으름, 성급함, 그리고 자만심이죠.

> 좋은 소프트웨어 설계를 이야기하려면 게으름, 성급함, 자만심을 빼놓을 수 없습니다. 우리 모두 복사-붙여넣기의 함정에 빠진 경험이 있습니다. 심지어 단순한 루프나 함수 정도만 만들어도 될 상황에서 말이죠. 물론 반대 극단으로 치달아 쓸데없이 복잡한 추상화를 만들어버리는 사람들도 있습니다. 하지만 일반적으로 우리 대부분은 더 적은 추상화보다는 더 많은 추상화를 고려해야 합니다.

게으름의 진정한 의미

이 세 가지 미덕 중에서도 게으름이 가장 깊이 있다고 봅니다. 표면적인 자조 속에는 단순한 추상화의 필요성을 넘어, 그것의 미학에 대한 통찰이 담겨 있거든요.

게으름은 우리를 시스템을 최대한 단순하게 만들도록 몬답니다. 물론 "그 이상 단순할 수 없는 수준까지만"이라는 단서가 붙지만요. 우리는 강력한 추상화를 개발함으로써 더 많은 것을 훨씬 더 쉽게 할 수 있게 됩니다.

여기서 재미있는 점은 "게으르다"는 것이 사실 엄청난 노력을 요구한다는 겁니다. 프로그래머들이 "해먹 구동 개발(hammock-driven development)"처럼 보이는 게으름에 빠져있을 때, 실제로는 문제를 계속해서 뒤집고 뒤집으며 생각하고 있거든요.

우리가 이런 추상화를 개발하기 위해 힘들게 지적 노동을 하는 이유는 뭘까요? 미래의 자신(그리고 다른 사람들)의 시간을 절약하기 위해서입니다. 현재의 노력이 클지라도, 나중에 훨씬 더 큰 이득을 얻기 때문입니다.

이런 계산이 제대로 맞아떨어질 때는 정말 아름답습니다. 우리의 게으름이 소프트웨어를 더 쉽게 만들고, 시스템을 더 잘 조합하게 해줍니다. 결국 더 많은 사람들이 더 많은 것을 만들 수 있게 되는 거죠.

게으름의 변질

지난 20년간 소프트웨어 개발의 범위가 넓어지면서 문제가 생겼습니다. 자신을 "프로그래머"라고 부르지 않는 사람들이 소프트웨어를 만들기 시작한 겁니다. 이들에게 게으름이라는 미덕은 원래의 의미를 잃어버렸습니다.

더 심각한 건, 현대적 추상화가 가져온 엄청난 생산성이 오히려 "거짓 근면함"을 부추겼다는 점입니다. 그렇게 탄생한 게 바로 "브로그래머(brogrammer)" 문화거든요. 우아한 게으름과 사려 깊은 개발 방식은 사라지고, 코드를 "부수고 부셔서" 자랑하는 "허슬 포르노(hustle porn)"가 판을 쳤습니다.

LLM: 게으름을 없애는 촉매

이제 여기에 LLM이라는 번개가 떨어졌습니다. 어떤 개발 철학을 가졌든 간에, LLM은 그것을 훨씬 더 큰 힘으로 증폭시킵니다. 그래서 LLM이 브로그래머들의 스테로이드 역할을 했던 건 당연한 결과입니다. 새로운 힘에 도취된 그들은 자신들의 성과에 대해 자꾸만 자랑하고 싶어 합니다.

가장 좋은 예가 바로 개리 탠(Garry Tan)입니다. 그는 LLM 사용에 대해 정말 지나칠 정도로 자랑했는데, 하루에 37,000줄의 코드를 작성한다며(그리고 "아직도 속도를 높이고 있다"고) 뽐냈습니다. 참고로 DTrace 전체 코드가 어떻게 세는지에 따라 약 60,000줄입니다.

이렇게 소프트웨어를 생각하는 방식은, 프로그래머의 미덕으로서의 게으름의 정반대입니다. 책을 무게로 평가하는 것처럼 터무니없으니까요. 심지어 초보 프로그래머도 이 오류를 알아챌 수 있을 겁니다.

현실적 결과

탠이 이렇게 열광적으로 만든 결과물이 뭘까요? 저는 관심을 두지 않았는데, 폴란드의 소프트웨어 엔지니어 그레고린(Gregorein)이 분석했습니다. 결과는 예상 가능하면서도 우습고, 동시에 깨달음을 줍니다:

탠의 "뉴스레터-블로그-따위"를 한 번 로드했더니 테스트 하니스가 여럿(!) 들어있었고, Hello World Rails 앱이 있었으며(?!), 그 사이에 몰래 들어온 텍스트 에디터까지 있었습니다. 그리고 같은 로고의 변형이 8개나 있는데, 그중 하나는 0바이트였습니다.

문제는 이런 작은 오류들 자체가 아닙니다. 이들은 모두 고칠 수 있으니까요. 진짜 문제도 "이 방식이 소프트웨어 엔지니어링의 미래"라고 믿는 신념도 아닙니다(물론 그것도 짜증 나긴 합니다).

근본적인 문제: LLM은 게으를 수 없다

핵심은 이겁니다. LLM은 본질적으로 게으름의 미덕을 가질 수 없습니다.

LLM에게는 일하는 것이 아무것도 아닙니다. 자신이나 남의 시간을 절약하려는 필요성을 느끼지 않고, 기꺼이 쓰레기를 계속 쌓아 올립니다. 제약이 없으면 LLM은 시스템을 더 낫게 만들지 못하고 오히려 더 크게 만듭니다. 허영심 있는 메트릭을 만족시킬 수는 있겠지만, 정말 중요한 모든 것을 희생하는 대가로요.

이것이 우리의 게으름이 얼마나 본질적인지를 보여줍니다. 우리에게는 제한된 시간이 있으니까 정확한 추상화를 개발할 수밖에 없거든요. 어설픈 추상화의 결과에 우리의 시간을 낭비하고 싶지 않으니까 말입니다.

최고의 엔지니어링은 항상 제약 속에서 탄생합니다. 그리고 우리의 시간이라는 제약이 바로 우리가 수용할 수 있는 시스템의 인지적 부하에 한계를 그어줍니다. 바로 이것이 우리를 더 단순한 시스템을 만들도록 몬답니다. 본질적으로 복잡하더라도 말입니다.

이는 정말 큰 노력이 필요한 작업이고, 우리는 LLM이 이를 대신할 수 있을 거라고 기대할 수 없습니다.