{"title":"잃어버린 게으름의 위험 — Bryan Cantrill이 LLM 시대에 다시 꺼내는 프로그래머의 미덕","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/peril-of-laziness-lost/","section":"posts","date":"2026-04-27T18:56:36+09:00","lastmod":"2026-04-27T18:56:36+09:00","description":"Bryan Cantrill이 Larry Wall의 '게으름·조급함·자만'이라는 프로그래머의 세 미덕을 다시 꺼내, LLM이 왜 좋은 추상화를 만들지 못하는지 진단한다. Garry Tan의 '하루 37,000줄' 자랑과 DTrace 60,000줄을 나란히 놓으면, 시간 제약이 없는 생성기가 만든 코드가 어떻게 쓰레기 레이어케이크가 되는지가 드러난다.","summary":"Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다.\n원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12)\nTL;DR 요약 세 가지 미덕: Larry Wall의 Programming Perl(\u0026ldquo;Camel Book\u0026rdquo;)이 말한 Laziness, Impatience, and Hubris는 좋은 소프트웨어 설계의 토대였다. 진짜 게으름: 문제를 머릿속에서 굴리고 또 굴려, 미래의 개발자에게 도움이 되는 강력한 추상화를 만들어내는 지적 노동이다. LLM의 결함: 일에 비용이 들지 않으니 \u0026ldquo;쓰레기의 레이어케이크에 더 많은 것을 기쁘게 쌓아 올린다\u0026rdquo; — 시간 희소성을 겪지 않기에 게으름의 미덕이 작동하지 않는다. 숫자 대비: Garry Tan이 자랑한 하루 37,000줄(여전히 가속 중) vs DTrace 전체 약 60,000줄. 폴란드 엔지니어 Gregorein의 분석은 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(하나는 0바이트)을 발견. 결론: \u0026ldquo;최고의 엔지니어링은 항상 제약에서 태어난다.\u0026rdquo; LLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야지, 자율 개발자로 풀어주어선 안 된다. Oxide의 LLM 가이드라인(RFD 0576)이 그 사례. 시작점 — Larry Wall이 정의한 세 미덕 Cantrill은 Programming Perl(통칭 \u0026ldquo;Camel Book\u0026rdquo;)의 한 줄을 다시 끌어옵니다.\n","content":"Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다.\n원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12)\nTL;DR 요약 세 가지 미덕: Larry Wall의 Programming Perl(\u0026ldquo;Camel Book\u0026rdquo;)이 말한 Laziness, Impatience, and Hubris는 좋은 소프트웨어 설계의 토대였다. 진짜 게으름: 문제를 머릿속에서 굴리고 또 굴려, 미래의 개발자에게 도움이 되는 강력한 추상화를 만들어내는 지적 노동이다. LLM의 결함: 일에 비용이 들지 않으니 \u0026ldquo;쓰레기의 레이어케이크에 더 많은 것을 기쁘게 쌓아 올린다\u0026rdquo; — 시간 희소성을 겪지 않기에 게으름의 미덕이 작동하지 않는다. 숫자 대비: Garry Tan이 자랑한 하루 37,000줄(여전히 가속 중) vs DTrace 전체 약 60,000줄. 폴란드 엔지니어 Gregorein의 분석은 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(하나는 0바이트)을 발견. 결론: \u0026ldquo;최고의 엔지니어링은 항상 제약에서 태어난다.\u0026rdquo; LLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야지, 자율 개발자로 풀어주어선 안 된다. Oxide의 LLM 가이드라인(RFD 0576)이 그 사례. 시작점 — Larry Wall이 정의한 세 미덕 Cantrill은 Programming Perl(통칭 \u0026ldquo;Camel Book\u0026rdquo;)의 한 줄을 다시 끌어옵니다.\n\u0026ldquo;Laziness, Impatience, and Hubris, the basis of good software design.\u0026rdquo; — Larry Wall\n오해하기 쉬운 단어들입니다. 여기서 말하는 **게으름(Laziness)**은 일을 안 하는 게 아니라, 다시는 같은 일을 안 하기 위해 한 번 제대로 추상화하는 노력입니다. 문제를 머릿속에서 몇 번이고 굴려보고, 후대의 개발자가 같은 고생을 반복하지 않도록 강력한 추상을 짜내는 일 — 그게 미덕으로서의 게으름입니다.\n조급함과 자만도 같은 결입니다. *\u0026ldquo;이건 더 빠르게 돌아야 한다\u0026rdquo;*는 조급함이 최적화를 낳고, *\u0026ldquo;내가 만든 게 다른 사람도 쓸만해야 한다\u0026rdquo;*는 자만이 API의 품질을 끌어올립니다.\n세 미덕의 공통분모는 자기 자신과 타인의 시간에 대한 자각입니다.\nLLM에는 무엇이 빠져 있는가 — 시간 제약의 부재 Cantrill의 진단은 단순합니다.\n\u0026ldquo;LLMs inherently lack the virtue of laziness.\u0026rdquo;\n이유는 윤리도 정렬도 아닌 물리학에 가깝습니다. LLM에게 코드 한 줄을 더 만드는 것은 비용이 거의 0입니다. 사람은 *\u0026ldquo;이걸 또 짜기 싫다\u0026rdquo;*는 감각이 추상화를 강제하지만, LLM은 그 감각이 없습니다. 그래서:\n\u0026ldquo;will happily dump more and more onto a layercake of garbage.\u0026rdquo;\n기쁘게, 망설임 없이, 쓰레기의 레이어케이크 위에 더 많은 쓰레기를 쌓는다. 추상화의 압력이 없으니 단순화도 없고, 단순화가 없으니 우아함도 없습니다.\n이는 모델 능력의 문제가 아닙니다. 더 똑똑한 모델이 와도 시간이 비용이 되지 않는다는 구조는 그대로입니다.\n사례 연구 — Garry Tan의 \u0026ldquo;하루 37,000줄\u0026rdquo; Cantrill이 직접 겨눈 사례는 벤처 캐피털리스트 Garry Tan입니다(\u0026ldquo;brogrammer-of-note\u0026quot;라는 표현으로 호명). Tan은 LLM과 함께 작업하며 하루 37,000줄의 코드를 생산한다고 자랑했고, \u0026ldquo;still speeding up\u0026rdquo; — 여전히 가속 중이라고 덧붙였습니다.\n비교점이 강렬합니다.\n코드베이스 라인 수 기간 DTrace 전체 약 60,000줄 다년간의 시스템 엔지니어링 Garry Tan의 하루 산출 약 37,000줄 24시간 DTrace가 무엇인지 알면 이 비교의 무게가 더 분명해집니다 — Solaris의 동적 트레이싱 시스템, Cantrill 본인을 포함한 팀이 수년간 다듬어 온, 실시간 운영체제 관측의 정수.\nGregorein의 검시 — 무엇이 들어 있었나 폴란드 엔지니어 Gregorein이 Tan이 만든 코드를 뜯어보고 정리한 결과는 생성기가 엔지니어가 아닌 이유를 그대로 보여줍니다:\n여러 개의 중복된 테스트 하니스 Hello World Rails 템플릿 (그대로 들어 있음) 내장된 텍스트 에디터 8개의 로고 변형 — 그중 하나는 0바이트 각 항목이 무엇을 의미하는지 보면, 이는 LLM이 만들 수 있는 잘못의 카탈로그에 가깝습니다 — 중복, 보일러플레이트의 잔재, 무의미한 컴포넌트의 첨가, 무의미한 산출물(0바이트 로고)의 자동 생성.\n양은 미덕의 부재를 가립니다. 줄 수는 늘었지만, 엔지니어링은 없습니다.\n진짜 문제는 버그가 아니라 방법론 Cantrill의 핵심 통찰은 여기입니다.\n개별 버그가 문제가 아니다. 방법론 자체가 문제다.\n사람의 시간 제약은 단순함과 명료함을 향해 손을 강제로 끌어당깁니다. 시간이 없으니까 — 그래서 더 적은 코드, 더 명확한 이름, 더 견고한 추상이 살아남습니다.\n제약이 사라진 LLM은 그 반대 방향으로 갑니다. 더 많은 레이어, 더 많은 옵션, 더 많은 방어적이지만 무의미한 코드. 이것이 \u0026ldquo;Cantrill의 The Complexity of Simplicity 강연이 말한 그 대비입니다.\n\u0026ldquo;The best engineering is always borne of constraints.\u0026rdquo;\n제약이 곧 엔지니어링의 산파라는 명제. LLM은 제약이 없는 환경을 만들고, 그래서 최고의 엔지니어링이 일어날 조건을 무너뜨립니다.\n그래서 LLM을 어떻게 다뤄야 하는가 — Oxide의 답 Cantrill은 LLM 자체를 폐기하라고 말하지 않습니다. 자기 회사 Oxide Computer Company의 LLM 가이드라인 — RFD 0576 — 을 사례로 듭니다. 핵심:\nLLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야 한다. 자율 개발자가 아니다.\n활용의 방향은 비미덕적 게으름(non-virtuous laziness)을 처리하는 데 있습니다 — 즉:\n기술 부채(technical debt)를 정리하는 노가다 보일러플레이트의 기계적 변환 단조로운 마이그레이션 이런 곳에서 LLM은 사람이 하기 싫지만 필요한 일을 떠맡아 줍니다. 반면 추상화의 결정, 이름 짓기, 무엇을 만들지 않을지에 대한 판단은 사람의 미덕적 게으름이 다뤄야 할 영역으로 남깁니다.\n핵심 어휘 정리 Virtuous Laziness — 같은 일을 두 번 하지 않기 위해 추상화를 만들어내는 지적 게으름 Non-virtuous Laziness — 단순히 일을 회피하는 게으름; LLM에 위임 가능한 영역 Layercake of Garbage — 압력 없이 쌓이는 코드층; LLM이 만들기 쉬운 산출물의 형태 Constraint-borne Engineering — 제약이 만든 엔지니어링; 시간·메모리·인지 한계가 단순함을 강제 실행 체크리스트 — LLM을 미덕 안에 두는 법 *생산량(라인 수)*을 자랑·평가 지표에서 분리할 것 — 양은 미덕의 부재를 가린다 LLM 산출물에 대해 추상화 압력을 사람이 별도로 가할 것(리뷰·압축·삭제 라운드) Hello World 템플릿, 중복 테스트 하니스, 0바이트 자동 산출물 — 이런 패턴을 LLM 결과물의 카나리아로 삼을 것 LLM에 위임할 영역(비미덕적 게으름)과 위임하지 않을 영역(추상화 결정·명명·범위 결정)을 명시적으로 구분 회사 단위의 LLM 사용 가이드라인을 문서화 — Oxide RFD 0576 같은 사례 참조 왜 이 글이 중요한가 대부분의 LLM 비판은 환각, 보안, 정렬 같은 출력의 문제에 머무릅니다. Cantrill의 글은 한 층 아래를 겨눕니다 — 생성 자체의 경제학이 만들어내는 구조적 결함.\n역사적 토대 — Larry Wall이 정의한 프로그래머의 미덕이 왜 1990년대 책의 농담이 아니라 공학의 본질이었는지 메커니즘적 진단 — 시간 비용의 부재가 어떻게 추상화 실패로 이어지는지 실증 사례 — 37,000줄 vs 60,000줄, 그리고 그 안의 8번째 0바이트 로고 건설적 출구 — LLM을 어디에 쓰고 어디에 쓰지 말지에 대한 Oxide의 답 도구는 미덕을 보조할 때만 가치를 만든다. 미덕을 대체하려는 순간, 도구는 쓰레기의 레이어케이크를 가속한다.\n핵심 결론 좋은 소프트웨어 설계의 토대는 게으름·조급함·자만이라는 시간과 자기 자각의 미덕이다 LLM에는 시간 비용이 없으므로 추상화를 강제하는 압력이 발생하지 않는다 결과는 쓰레기의 레이어케이크 — 양은 늘지만 엔지니어링은 없다 Garry Tan의 하루 37,000줄과 DTrace 전체 60,000줄의 대비, 그리고 0바이트 로고를 포함한 8개 변형이 그 증거다 진짜 문제는 개별 버그가 아니라 방법론 — 제약 없는 생성은 단순함을 밀어낸다 LLM은 비미덕적 게으름의 처리에 쓰고, 추상화·명명·범위 결정은 사람의 미덕 안에 남길 것 (Oxide RFD 0576) 당신의 코드베이스는 줄 수가 늘고 있는가, 아니면 후대의 엔지니어를 위한 게으름이 자라고 있는가.\n","wordCount":992,"tags":["Bryan Cantrill","Larry Wall","Programming Perl","Laziness","LLM","AI","Oxide","DTrace","Garry Tan","Code Quality","소프트웨어공학"],"categories":["AI"],"frameworks":["Three Programmer Virtues","Constraint-Driven Engineering","Virtuous Laziness"],"mental_models":["Generation without Time Cost","Quantity vs Quality of Code","Layercake of Garbage"],"philosophy_type":"engineering-ethics","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["Larry Wall의 '게으름·조급함·자만'은 좋은 소프트웨어 설계의 토대였고, 진짜 게으름은 추상화를 위해 머리를 쥐어짜는 지적 노동이다","LLM에는 시간 비용이 없어 게으름의 미덕이 작동하지 않으며, 결과는 '쓰레기의 레이어케이크'다","Garry Tan은 '하루 37,000줄, 여전히 가속 중'이라고 자랑했지만 DTrace 전체 코드베이스가 약 60,000줄이다","Polish 엔지니어 Gregorein이 Tan의 코드를 뜯어보니 중복 테스트 하니스, Hello World Rails 템플릿, 내장 텍스트 에디터, 8개 로고 변형(그중 하나는 0바이트)이 들어 있었다","최고의 엔지니어링은 항상 제약에서 태어난다 — LLM은 인간의 미덕적 게으름을 보조하는 도구여야지 자율 개발자가 아니다"],"related":["posts/probabilistic-engineering-24-7-employee","posts/fowler-fragments-cognitive-debt-system-3","posts/zero-alignment-maggie-appleton"]}