프로그래머의 미덕으로서의 게으름과, LLM이 그 미덕을 결여할 때 소프트웨어 공학에 어떤 문제가 생기는지를 살펴본다.
Apr 12, 2026
그의 고전 Programming Perl — 한 세대의 기술자들에게 애정을 담아 "낙타 책"으로 알려진 — 에서 Larry Wall은 프로그래머의 세 가지 미덕을 게으름, 조바심, 오만함이라고 유명하게 썼다:
좋은 소프트웨어 설계에 대해 이야기하려면, 좋은 소프트웨어 설계의 기반인 게으름, 조바심, 오만함에 대해 이야기해야 한다. 우리 모두는 더 높은 수준의 추상화를 정의했어야 할 때 단지 반복문이나 서브루틴만으로도 충분했을 상황에서 잘라 붙이기의 함정에 빠진 적이 있다. 물론, 어떤 사람들은 반대로 잘라 붙이기를 했어야 할 때 점점 더 높아지는 고수준 추상화 더미를 정의하는 극단으로 가기도 했다. 하지만 일반적으로는, 우리 대부분은 추상화를 덜 쓰는 것보다 더 쓰는 쪽을 생각할 필요가 있다.
이 미덕들 가운데, 나는 언제나 게으름이 가장 심오하다고 느껴왔다. 그 혀를 찌르는 듯한 자기비하 속에는 단지 추상화의 필요성만이 아니라 그 미학에 대한 논평도 담겨 있기 때문이다. 게으름은 우리를 시스템을 가능한 한 단순하게(하지만 그보다 더 단순하지는 않게!) 만들도록 이끈다 — 그리고 그 뒤에 더 많은 일을 훨씬 더 쉽게 할 수 있게 해주는 강력한 추상화를 발전시키도록 만든다.
물론, 여기에는 암묵적인 윙크가 있다. 게으르기 위해서는 많은 일이 필요하다는 것이다. 프로그래머가 겉보기에 게으른 hammock-driven development에 몰두하고 있을 때, 우리는 사실 문제를 머릿속에서 이리저리 뒤집어 보고 있다. 우리는 이러한 추상화를 개발하는 어려운 지적 작업을 수행하는데, 그 이유의 일부는 현재의 나 자신을 희생하더라도 미래의 나 자신의 가상적인 시간을 최적화하고 있기 때문이다. 이 계산을 제대로 해내면 그것은 장관이다. 추상화는 우리 자신뿐 아니라 우리 뒤에 오는 모든 이들에게도 도움이 되기 때문이다. 즉, 우리의 게으름은 소프트웨어를 더 쓰기 쉽게, 시스템을 더 조합하기 쉽게 만들어 — 더 많은 사람들이 더 많은 소프트웨어를 작성할 수 있게 한다.
이상적으로는, 추상화의 혜택을 받는 이들이 게으름의 미덕을 다시 앞으로 전달하기를 바랄 것이다 — 자신들이 얻은 새로운 힘을 이용해 자신들이 만드는 추상화에도 직접 수고를 들이는 것이다. 그러나 지난 20년 동안 소프트웨어 제작이 넓어지면서 생긴 결과 중 하나는, 이제 점점 더 많은 사람들이 그 안에 포함되지만 그들이 자신을 프로그래머라고 부를 가능성은 낮고 — 그들에게는 게으름의 미덕이 본래 의도를 잃는다는 점이다.
더 나쁜 것은, 현대적 추상화가 허용하는 엄청난 생산성이 일종의 거짓된 근면함을 강조하는 분위기를 낳았다는 점이다. 경멸적인 의미에서 이는 brogrammer의 부상이었고, 아이러니한 게으름과 hammock-driven development라는 미덕은 코드를 박살내듯 써내려가는 것에 대한 hustle porn에 밀려났다.
이 바싹 마른 부싯깃 위로 LLM이라는 번개가 떨어졌다. 소프트웨어 제작에 대해 어떤 성향을 갖고 있든, LLM은 그것을 (훨씬) 더 큰 힘으로 적용할 수 있게 해주므로, LLM이 brogrammer 집단에게 아나볼릭 스테로이드 역할을 해왔다는 사실은 그다지 놀라운 일이 아니다.
새로 얻은 근육에 도취된 그들은 그 이야기를 좀처럼 멈추지 못하는 듯하다. 예를 들어, 유명 brogrammer인 Garry Tan을 보자. 그는 자신의 LLM 사용에 대해 유난히도 견디기 힘들 정도로 떠들어대며, 하루에 3만 7천 줄의 코드를 작성하는 속도를 자랑했다(그리고 "여전히 더 빨라지고" 있다고 한다):
(비교를 위해 말하자면, DTrace 전체는 — 어떻게 세느냐에 따라 다르지만 — 대략 6만 줄의 코드 정도다.)
게으름이 프로그래머의 미덕이라면, 이런 식으로 소프트웨어를 생각하는 것은 분명 악덕이다. 그리고 문학을 무게로 평가하는 것과 마찬가지로, 그 오류는 초보 프로그래머에게조차 분명하다.
그토록 부산한 에너지로 Tan이 만들고 있던 결과물 자체에 대해서는, 나는 대체로 무시하고 있었다. 하지만 폴란드 소프트웨어 엔지니어 Gregorein은 그것을 분해해 보았고, 그 결과는 예상 가능하면서도, 우스우면서도, 교훈적이었다. Tan의 "뉴스레터-블로그-무언가"를 한 번 로드했더니 여러 개의 테스트 하네스(!), Hello World Rails 앱(?!), 몰래 끼어든 텍스트 에디터, 그리고 같은 로고의 서로 다른 변형 여덟 개가 포함되어 있었는데 — 그중 하나는 바이트가 0개였다.
여기서 문제는 이러한 이슈들 자체가 아니다(모두 고칠 수 있다!). 그리고 그것들을 만들어낸 방법론이 소프트웨어 공학의 미래를 대표한다는 믿음조차도 아니다(물론 그것도 충분히 짜증나는 일이다!).
문제는 LLM이 본질적으로 게으름의 미덕을 결여하고 있다는 점이다. 일은 LLM에게 아무 비용도 들지 않는다. LLM은 자신(혹은 누구든)의 미래 시간을 최적화해야 할 필요를 느끼지 않으며, 기꺼이 쓰레기의 케이크 층 위에 더 많은 것을 계속 쏟아붓는다. 제어하지 않으면 LLM은 시스템을 더 좋게 만드는 것이 아니라 더 크게 만든다 — 어쩌면 일그러진 허영 지표에는 호소할지 모르지만, 중요한 모든 것의 대가를 치르면서 말이다. 그런 의미에서 LLM은 우리의 인간적인 게으름이 얼마나 본질적인지를 드러낸다. 우리의 유한한 시간은, 투박한 추상화의 결과로 우리의 (인간적인!) 시간을 낭비하고 싶지 않기 때문에, 우리로 하여금 날카롭고 명료한 추상화를 발전시키도록 강제한다. 최고의 엔지니어링은 언제나 제약에서 태어나며, 우리 시간의 제약은 우리가 받아들이려는 시스템의 인지 부하에 한계를 둔다. 이것이 바로 본질적인 복잡성에도 불구하고 우리가 시스템을 더 단순하게 만들도록 이끄는 것이다. 내가 강연 The Complexity of Simplicity에서 더 자세히 설명했듯이, 이것은 중대한 작업이며 — 시간이나 부하의 제약 아래서 작동하지 않는 LLM이 스스로의 의지로 그것을 수행하리라 기대할 수는 없다.
물론 그렇다고 해서 LLM이 우리의 미래에서 중요한 역할을 하지 못하리라는 뜻은 아니다. LLM은 소프트웨어 공학을 위한 경이로운 도구이지만, 우리의 Oxide에서의 LLM 사용 지침에 설명되어 있듯이 — 그저 도구일 뿐이다. 우리는 그것을 프로그래머의 게으름 가운데 아이러니하지 않은(그리고 미덕도 아닌!) 측면 — 이를테면 기술 부채 같은 까다로운 문제를 다루는 데 — 에 활용할 수 있고, 혹은 우리의 엔지니어링 엄밀성을 높이는 데 사용할 수도 있지만, 그것은 반드시 우리의 미덕 있는 게으름에 봉사해야 한다. 즉, 우리 자신뿐 아니라 우리 뒤에 올 소프트웨어 엔지니어 세대에도 도움이 되는, 더 단순하고 더 강력한 시스템을 만들어내기 위해서다.
