--- title: "게으름의 미덕을 잃어버린 위험 — LLM 시대의 소프트웨어 엔지니어링" published: 2026-04-12T19:44:40.000Z canonical: https://jeff.news/article/1702 --- # 게으름의 미덕을 잃어버린 위험 — LLM 시대의 소프트웨어 엔지니어링 Bryan Cantrill이 래리 월의 '프로그래머의 미덕적 게으름'을 LLM 시대에 재해석한 글. LLM은 시간과 인지 부하의 제약이 없어서 시스템을 더 단순하게 만들 동기가 없고, 방치하면 쓰레기 레이어케이크만 쌓인다고 경고함. Garry Tan의 하루 37,000줄 사례를 반면교사로 제시. - **래리 월의 "프로그래머의 세 가지 미덕" 중 게으름(laziness)이 가장 심오한 덕목이라는 이야기** — 프로그래밍에서의 게으름은 단순한 태만이 아니라, 시스템을 가능한 한 단순하게 만들려는 추상화의 미학 - 해먹 위에서 멍 때리는 것처럼 보이는 "해먹 주도 개발(hammock-driven development)"은 사실 머릿속에서 문제를 계속 뒤집어보는 고된 지적 노동 - 지금의 자기 시간을 써서 미래의 자기(와 후대 개발자들)의 시간을 최적화하는 것. 이 계산이 맞아떨어지면 추상화가 빛남 - **LLM이 이 "게으름의 미덕"을 파괴하고 있다는 게 Bryan Cantrill의 핵심 주장** - 지난 20년간 현대적 추상화의 생산성 향상이 오히려 "가짜 근면함"을 부추김 — 코드를 얼마나 빨리 찍어내느냐를 자랑하는 "브로그래머(brogrammer)" 문화의 부상 - LLM은 이 브로그래머 문화에 아나볼릭 스테로이드를 꽂아준 격 - 대표적인 예시가 Y Combinator CEO Garry Tan — **하루에 37,000줄의 코드를 작성한다**고 자랑하면서 "아직 더 빨라지고 있다"고 함 - 비교를 위해, DTrace 전체가 약 60,000줄임. Tan은 이틀이면 DTrace 분량을 찍어내는 셈 > [!IMPORTANT] > Garry Tan이 만든 "뉴스레터-블로그-뭐시기"를 폴란드 개발자 Gregorein이 분석했더니 — 한 번 로드에 테스트 하네스 여러 개, Rails Hello World 앱, 텍스트 에디터 하나가 딸려 나오고, 같은 로고가 8개 변형으로 포함되어 있었음(그중 하나는 0바이트). - **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을 활용하자는 방향이거든요 ## 핵심 포인트 - 프로그래머의 게으름은 추상화의 미학 — 미래의 시간을 최적화하기 위한 지적 노동 - LLM이 '브로그래머' 문화에 아나볼릭 스테로이드를 꽂아줌 - Garry Tan이 하루 37,000줄을 자랑했지만, 결과물에 테스트 하네스와 Hello World 앱이 딸려 나옴 - LLM에는 게으름의 미덕이 없음 — 비용 0이라 시스템을 크게만 만들 뿐 좋게 만들지 않음 - LLM은 도구로서 기술 부채 해결이나 엔지니어링 엄밀성 향상에 활용해야 함 ## 인사이트 코드 생성 속도를 자랑하는 시대에 '얼마나 적게 쓰느냐'가 진짜 역량이라는 역설을 DTrace 창시자가 설득력 있게 풀어냄. LLM 도입 가이드라인을 고민하는 팀에게 좋은 프레임워크를 제공하는 글.