게으름의 미덕을 잃어버린 위험 — LLM 시대의 소프트웨어 엔지니어링

• 래리 월의 "프로그래머의 세 가지 미덕" 중 게으름(laziness)이 가장 심오한 덕목이라는 이야기 — 프로그래밍에서의 게으름은 단순한 태만이 아니라, 시스템을 가능한 한 단순하게 만들려는 추상화의 미학

  • 해먹 위에서 멍 때리는 것처럼 보이는 "해먹 주도 개발(hammock-driven development)"은 사실 머릿속에서 문제를 계속 뒤집어보는 고된 지적 노동
  • 지금의 자기 시간을 써서 미래의 자기(와 후대 개발자들)의 시간을 최적화하는 것. 이 계산이 맞아떨어지면 추상화가 빛남

• LLM이 이 "게으름의 미덕"을 파괴하고 있다는 게 Bryan Cantrill의 핵심 주장

  • 지난 20년간 현대적 추상화의 생산성 향상이 오히려 "가짜 근면함"을 부추김 — 코드를 얼마나 빨리 찍어내느냐를 자랑하는 "브로그래머(brogrammer)" 문화의 부상
  • LLM은 이 브로그래머 문화에 아나볼릭 스테로이드를 꽂아준 격
  • 대표적인 예시가 Y Combinator CEO Garry Tan — 하루에 37,000줄의 코드를 작성한다고 자랑하면서 "아직 더 빨라지고 있다"고 함
  • 비교를 위해, DTrace 전체가 약 60,000줄임. Tan은 이틀이면 DTrace 분량을 찍어내는 셈

• LLM에는 본질적으로 "게으름의 미덕"이 없다 — 이게 Cantrill 글의 핵심 논점
  • LLM에게 작업은 비용이 0에 가까움. 자기 미래 시간을 최적화할 동기가 없음
  • 그래서 방치하면 쓰레기 레이어케이크 위에 계속 덧쌓기만 함 — 시스템을 더 크게 만들 뿐, 더 좋게 만들지 않음
  • "하루 37,000줄" 같은 허영 메트릭(vanity metrics)에는 어필하겠지만, 정작 중요한 것들은 다 놓침
• 인간의 유한한 시간이야말로 좋은 엔지니어링의 제약 조건
  • 시간이 유한하니까 인지 부하(cognitive load)를 줄이려 하고, 그래서 시스템을 단순하게 만들게 됨
  • 시간이나 부하 제약 없이 돌아가는 LLM에게 이런 단순화를 자발적으로 기대할 수 없음
• 그렇다고 LLM이 쓸모없다는 건 아님 — Cantrill이 Oxide에서 만든 LLM 사용 가이드라인을 언급
  • LLM은 도구일 뿐. 기술 부채 같은 비미적(non-virtuous) 게으름을 해결하는 데 활용하거나, 엔지니어링 엄밀성을 높이는 방향으로 써야 함
  • 핵심은 인간의 미덕적 게으름에 봉사하는 방향으로 LLM을 활용하는 것 — 더 단순하고 강력한 시스템을 만들기 위해

---

기술 맥락

• Bryan Cantrill은 Sun Microsystems에서 DTrace를 만든 사람이고 지금은 서버 하드웨어 회사 Oxide Computer를 이끌고 있어요. "소프트웨어의 복잡성"에 대해 수십 년간 생각해온 사람이 LLM 시대에 던지는 경고라서 무게감이 있어요
• 여기서 말하는 "해먹 주도 개발"은 Rich Hickey(Clojure 창시자)의 유명한 강연 "Hammock Driven Development"에서 온 개념이에요. 코딩 전에 충분히 생각하는 시간이 결국 더 나은 설계를 만든다는 건데, LLM 시대에는 "생각 안 하고 바로 코드 생성"이 너무 쉬워진 게 문제라는 거예요
• Cantrill이 언급하는 Oxide의 LLM 사용 가이드라인은 "AI를 완전히 거부하지도 않고, 무조건 수용하지도 않는" 실용적 입장이에요. 코드 생성보다는 코드 리뷰, 기술 부채 분석, 테스트 작성 같은 "지루하지만 가치 있는 작업"에 LLM을 활용하자는 방향이거든요