게으름의 위험이 사라진 이유

^{source https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/}

래리 월은 고전 Programming Perl에서, 한 세대의 기술자들이 애정 어린 마음으로 "낙타책"이라 부르던 그 책에서, 프로그래머의 세 가지 미덕으로 게으름, 조바심, 오만을 꼽은 것으로 유명하다: 좋은 소프트웨어 설계를 이야기하려면, 그 토대가 되는 게으름, 조바심, 오만을 이야기하지 않을 수 없다. 우리 모두 더 높은 수준의 추상화를 만들었어야 할 순간에, 기껏해야 루프나 서브루틴 하나로 정리했어야 할 코드를 복붙으로 때워버린 적이 있다. 물론 반대로, 그냥 복붙했으면 될 일을 점점 더 거대한 고수준 추상화 더미로 만들어버리는 사람들도 있다. 그래도 대체로 보면, 우리 대부분은 추상화를 덜 쓰는 쪽보다 더 쓰는 쪽을 고민해야 한다.

이 미덕들 가운데서도 나는 늘 게으름이 가장 깊다고 느꼈다. 약간은 농담 섞인 자기비하처럼 들리지만, 그 안에는 추상화의 필요성뿐 아니라 추상화의 미학에 대한 이야기까지 들어 있다. 게으름은 우리가 시스템을 가능한 한 단순하게, 하지만 그 이상으로 단순하지는 않게 만들도록 밀어붙인다. 그리고 그렇게 만들어낸 강력한 추상화 덕분에 우리는 훨씬 더 많은 일을, 훨씬 더 쉽게 해낼 수 있다.

물론 여기에는 은근한 농담이 숨어 있다. 게으르려면 오히려 엄청난 노력이 든다는 점이다. 프로그래머가 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 사용 가이드라인에도 적어두었듯, 어디까지나 도구일 뿐이다. 우리는 LLM을 프로그래머의 게으름 가운데 아이러니하지도 않고, 미덕이라고 부르기도 어려운 부분에 투입할 수 있다. 예를 들어 technical debt 같은 까다로운 문제를 다루는 데 도움을 받거나, 엔지니어링 공학을 끌어올리는 데 활용할 수도 있다. 하지만 그 모든 활용은 결국 우리 자신의 미덕 있는 게으름을 위해서여야 한다. 우리 자신뿐 아니라, 앞으로 올 다음 세대 소프트웨어 엔지니어들에게도 도움이 되는 더 단순하고 더 강력한 시스템을 만들어내기 위해서다.