Bryan Cantrill(Oxide Computer Company 공동창업자, DTrace 공저자)이 The Observation Deck 블로그에 올린 2026년 4월 12일 글은, LLM이 코드를 쏟아내는 시대에 가장 손쉽게 잊히는 미덕 — 프로그래머의 게으름 — 을 다시 꺼냅니다. 단순한 노스탤지어가 아니라, 무한 생성기에는 좋은 추상화를 만드는 압력이 존재하지 않는다는 인프라적 진단입니다.
원문: The Peril of Laziness Lost — Bryan Cantrill (2026-04-12)
시작점 — Larry Wall이 정의한 세 미덕
Cantrill은 Programming Perl(통칭 “Camel Book”)의 한 줄을 다시 끌어옵니다.
“Laziness, Impatience, and Hubris, the basis of good software design.” — Larry Wall
오해하기 쉬운 단어들입니다. 여기서 말하는 **게으름(Laziness)**은 일을 안 하는 게 아니라, 다시는 같은 일을 안 하기 위해 한 번 제대로 추상화하는 노력입니다. 문제를 머릿속에서 몇 번이고 굴려보고, 후대의 개발자가 같은 고생을 반복하지 않도록 강력한 추상을 짜내는 일 — 그게 미덕으로서의 게으름입니다.
조급함과 자만도 같은 결입니다. *“이건 더 빠르게 돌아야 한다”*는 조급함이 최적화를 낳고, *“내가 만든 게 다른 사람도 쓸만해야 한다”*는 자만이 API의 품질을 끌어올립니다.
세 미덕의 공통분모는 자기 자신과 타인의 시간에 대한 자각입니다.
LLM에는 무엇이 빠져 있는가 — 시간 제약의 부재
Cantrill의 진단은 단순합니다.
“LLMs inherently lack the virtue of laziness.”
이유는 윤리도 정렬도 아닌 물리학에 가깝습니다. LLM에게 코드 한 줄을 더 만드는 것은 비용이 거의 0입니다. 사람은 *“이걸 또 짜기 싫다”*는 감각이 추상화를 강제하지만, LLM은 그 감각이 없습니다. 그래서:
“will happily dump more and more onto a layercake of garbage.”
기쁘게, 망설임 없이, 쓰레기의 레이어케이크 위에 더 많은 쓰레기를 쌓는다. 추상화의 압력이 없으니 단순화도 없고, 단순화가 없으니 우아함도 없습니다.
이는 모델 능력의 문제가 아닙니다. 더 똑똑한 모델이 와도 시간이 비용이 되지 않는다는 구조는 그대로입니다.
사례 연구 — Garry Tan의 “하루 37,000줄”
Cantrill이 직접 겨눈 사례는 벤처 캐피털리스트 Garry Tan입니다(“brogrammer-of-note"라는 표현으로 호명). Tan은 LLM과 함께 작업하며 하루 37,000줄의 코드를 생산한다고 자랑했고, “still speeding up” — 여전히 가속 중이라고 덧붙였습니다.
비교점이 강렬합니다.
| 코드베이스 | 라인 수 | 기간 |
|---|---|---|
| DTrace 전체 | 약 60,000줄 | 다년간의 시스템 엔지니어링 |
| Garry Tan의 하루 산출 | 약 37,000줄 | 24시간 |
DTrace가 무엇인지 알면 이 비교의 무게가 더 분명해집니다 — Solaris의 동적 트레이싱 시스템, Cantrill 본인을 포함한 팀이 수년간 다듬어 온, 실시간 운영체제 관측의 정수.
Gregorein의 검시 — 무엇이 들어 있었나
폴란드 엔지니어 Gregorein이 Tan이 만든 코드를 뜯어보고 정리한 결과는 생성기가 엔지니어가 아닌 이유를 그대로 보여줍니다:
- 여러 개의 중복된 테스트 하니스
- Hello World Rails 템플릿 (그대로 들어 있음)
- 내장된 텍스트 에디터
- 8개의 로고 변형 — 그중 하나는 0바이트
각 항목이 무엇을 의미하는지 보면, 이는 LLM이 만들 수 있는 잘못의 카탈로그에 가깝습니다 — 중복, 보일러플레이트의 잔재, 무의미한 컴포넌트의 첨가, 무의미한 산출물(0바이트 로고)의 자동 생성.
양은 미덕의 부재를 가립니다. 줄 수는 늘었지만, 엔지니어링은 없습니다.
진짜 문제는 버그가 아니라 방법론
Cantrill의 핵심 통찰은 여기입니다.
개별 버그가 문제가 아니다. 방법론 자체가 문제다.
사람의 시간 제약은 단순함과 명료함을 향해 손을 강제로 끌어당깁니다. 시간이 없으니까 — 그래서 더 적은 코드, 더 명확한 이름, 더 견고한 추상이 살아남습니다.
제약이 사라진 LLM은 그 반대 방향으로 갑니다. 더 많은 레이어, 더 많은 옵션, 더 많은 방어적이지만 무의미한 코드. 이것이 “Cantrill의 The Complexity of Simplicity 강연이 말한 그 대비입니다.
“The best engineering is always borne of constraints.”
제약이 곧 엔지니어링의 산파라는 명제. LLM은 제약이 없는 환경을 만들고, 그래서 최고의 엔지니어링이 일어날 조건을 무너뜨립니다.
그래서 LLM을 어떻게 다뤄야 하는가 — Oxide의 답
Cantrill은 LLM 자체를 폐기하라고 말하지 않습니다. 자기 회사 Oxide Computer Company의 LLM 가이드라인 — RFD 0576 — 을 사례로 듭니다. 핵심:
LLM은 인간 주도의 미덕적 게으름 안에서 도구로 다뤄져야 한다. 자율 개발자가 아니다.
활용의 방향은 비미덕적 게으름(non-virtuous laziness)을 처리하는 데 있습니다 — 즉:
- 기술 부채(technical debt)를 정리하는 노가다
- 보일러플레이트의 기계적 변환
- 단조로운 마이그레이션
이런 곳에서 LLM은 사람이 하기 싫지만 필요한 일을 떠맡아 줍니다. 반면 추상화의 결정, 이름 짓기, 무엇을 만들지 않을지에 대한 판단은 사람의 미덕적 게으름이 다뤄야 할 영역으로 남깁니다.
핵심 어휘 정리
- 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의 글은 한 층 아래를 겨눕니다 — 생성 자체의 경제학이 만들어내는 구조적 결함.
- 역사적 토대 — Larry Wall이 정의한 프로그래머의 미덕이 왜 1990년대 책의 농담이 아니라 공학의 본질이었는지
- 메커니즘적 진단 — 시간 비용의 부재가 어떻게 추상화 실패로 이어지는지
- 실증 사례 — 37,000줄 vs 60,000줄, 그리고 그 안의 8번째 0바이트 로고
- 건설적 출구 — LLM을 어디에 쓰고 어디에 쓰지 말지에 대한 Oxide의 답
도구는 미덕을 보조할 때만 가치를 만든다. 미덕을 대체하려는 순간, 도구는 쓰레기의 레이어케이크를 가속한다.
핵심 결론
- 좋은 소프트웨어 설계의 토대는 게으름·조급함·자만이라는 시간과 자기 자각의 미덕이다
- LLM에는 시간 비용이 없으므로 추상화를 강제하는 압력이 발생하지 않는다
- 결과는 쓰레기의 레이어케이크 — 양은 늘지만 엔지니어링은 없다
- Garry Tan의 하루 37,000줄과 DTrace 전체 60,000줄의 대비, 그리고 0바이트 로고를 포함한 8개 변형이 그 증거다
- 진짜 문제는 개별 버그가 아니라 방법론 — 제약 없는 생성은 단순함을 밀어낸다
- LLM은 비미덕적 게으름의 처리에 쓰고, 추상화·명명·범위 결정은 사람의 미덕 안에 남길 것 (Oxide RFD 0576)
당신의 코드베이스는 줄 수가 늘고 있는가, 아니면 후대의 엔지니어를 위한 게으름이 자라고 있는가.