# 게으름의 미덕을 잃는 위험 > Clean Markdown view of GeekNews topic #28471. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28471](https://news.hada.io/topic?id=28471) - GeekNews Markdown: [https://news.hada.io/topic/28471.md](https://news.hada.io/topic/28471.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-13T10:32:44+09:00 - Updated: 2026-04-13T10:32:44+09:00 - Original source: [bcantrill.dtrace.org](https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/) - Points: 2 - Comments: 1 ## Topic Body - 프로그래밍에서의 **게으름**은 단순한 태만이 아니라, **추상화와 단순함을 추구하는 지적 미덕**으로 정의됨 - 진정한 게으름은 **문제를 깊이 숙고해 미래의 시간을 절약하는 과정**이며, 이는 후대 개발자에게도 이익을 줌 - 현대의 고수준 추상화와 **‘brogrammer’ 문화**는 이러한 미덕을 잃게 하고, **가짜 근면함**으로 대체됨 - **LLM**은 이 경향을 극대화해, 코드의 양을 가치로 착각하게 만드는 **과잉 생산의 도구**로 작용함 - 인간의 유한한 시간에서 비롯된 **미덕적 게으름**을 유지하며, LLM을 **단순하고 지속 가능한 시스템 설계**에 활용해야 함 --- ### 프로그래머의 미덕으로서의 게으름과 그 상실의 위험 - **Larry Wall**이 『Programming Perl』에서 제시한 프로그래머의 세 가지 미덕인 **게으름(laziness)**, **성급함(impatience)**, **오만(hubris)** 중 게으름이 가장 깊은 의미를 지닌다고 강조함 - 게으름은 단순한 자기비하가 아니라, **추상화의 필요성과 미학**을 내포한 개념임 - 시스템을 가능한 한 단순하게 만들고, 강력한 추상화를 통해 더 많은 일을 더 쉽게 할 수 있도록 하는 동력임 - 진정한 게으름은 **‘hammock-driven development’** 처럼 겉보기에는 쉬는 것 같지만, 실제로는 문제를 깊이 숙고하며 미래의 시간을 절약하기 위한 **지적 노동**을 수행하는 과정임 - 올바른 추상화가 만들어지면, 그것은 개발자 자신뿐 아니라 **후대의 개발자들**에게도 이익을 줌 - 이러한 게으름은 소프트웨어를 더 쉽게 작성하고, 시스템을 더 쉽게 구성할 수 있게 함 - ## 게으름의 미덕이 사라진 시대 - 지난 20년간 소프트웨어 제작의 폭이 넓어지면서, **프로그래머로 자처하지 않는 사람들**이 늘어남 - 이들에겐 게으름의 미덕이 본래 의미를 잃게 되었음 - 현대의 고수준 추상화가 가져온 **생산성의 폭발**은 오히려 **가짜 근면함(false industriousness)** 을 조장함 - 이는 **‘brogrammer’ 문화**와 **‘hustle porn’** 으로 나타나, 아이러니한 게으름 대신 **코드를 무한히 쏟아내는 행태**로 대체됨 - ## LLM이 불러온 새로운 과잉 - **LLM(대규모 언어 모델)** 의 등장은 이러한 경향을 극대화함 - LLM은 인간의 창작 태도를 증폭시키는 도구로, **‘brogrammer’ 문화의 스테로이드** 역할을 함 - 예시로 **Garry Tan**은 LLM을 이용해 하루 **37,000줄의 코드**를 작성했다고 언급함 - 비교를 위해 **DTrace 전체 코드베이스**가 약 60,000줄 수준임 - 그러나 이러한 접근은 **게으름의 미덕이 결여된 악덕**으로, 코드의 양으로 소프트웨어의 가치를 평가하는 오류를 드러냄 - ## LLM의 한계와 인간 게으름의 가치 - LLM은 **노동 비용이 0**이기 때문에, 미래의 시간 절약을 고려하지 않고 **무한히 복잡한 시스템을 생성**함 - 결과적으로 시스템을 더 크고 복잡하게 만들며, **허영심 기반의 지표**를 만족시키지만 **본질적 품질**을 해침 - 인간의 게으름은 **유한한 시간이라는 제약**에서 비롯되며, 이는 **명확한 추상화와 단순화된 시스템 설계**를 강제함 - 최고의 엔지니어링은 항상 **제약에서 탄생**하며, 인간의 시간 제약이 **인지 부하를 제한**하고 단순함을 추구하게 함 - LLM은 이러한 제약이 없기 때문에, 스스로 단순함을 추구할 동기가 없음 - ## LLM을 도구로서 활용하는 방향 - LLM은 여전히 **소프트웨어 엔지니어링의 강력한 도구**로서 중요한 역할을 할 수 있음 - **Oxide**의 LLM 사용 지침에 따르면, LLM은 **도구일 뿐**이며 인간의 미덕을 대체할 수 없음 - LLM은 **기술 부채(technical debt)** 와 같은 비생산적 게으름의 문제를 해결하거나, **엔지니어링 엄격성**을 강화하는 데 활용 가능함 - 그러나 그 사용 목적은 반드시 **‘미덕적 게으름’** 을 실현하는 방향이어야 함 - 즉, **더 단순하고 강력한 시스템**을 만들어, **미래 세대의 개발자들**에게 도움이 되는 결과를 남겨야 함 ## Comments ### Comment 55183 - Author: neo - Created: 2026-04-13T10:32:45+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47743628) - 내 분야인 **Computational Fluid Dynamics**에서도 LOC 자랑처럼 테스트 수가 많다고 자랑하는 사람들이 있음 하지만 자세히 보면 그 테스트들은 별로 엄격하지 않고, 내가 수동으로 만든 테스트보다 훨씬 허술함 **100만 개의 쉬운 테스트**는 코드의 핵심 부분을 커버하지 않으면 아무 의미가 없음 - 나도 테스트를 직접 작성해야 한다는 걸 깨달았음 그리고 **Claude**가 코드가 안 될 때 테스트를 “고쳐버리는” 걸 막기 위해 항상 `git diff`로 테스트 변경을 확인함 테스트를 엄격히 관리하면 Claude가 어려운 논문 알고리즘도 잘 구현해줘서 시간 절약이 되지만, **보살핌이 많이 필요함** - 이건 일종의 **reward hacking** 같음 테스트라는 보상 함수를 모델이 “승리 선언”용으로 악용하는 셈임 아마 RL 사전학습 데이터에 이런 패턴이 들어있을 수도 있다고 추측함 - LLM이 멍청하지 않은 테스트를 생성하게 하는 건 정말 어려움 `assert(1==1)` 같은 쓸모없는 테스트가 수백 개 생김 그래서 “이런 테스트는 만들지 말라”는 **금지 리스트**를 따로 관리해야 함 - 30년간 직접 코딩하다가 이제는 전적으로 **AI 코딩**으로 전환했는데, 사람들이 AI가 생성한 코드의 LOC나 기능을 자기 공으로 삼는 게 이상하게 느껴짐 하루에 수십만 줄을 “코딩했다”고 자랑하는 건 결국 **프롬프트 몇 줄** 친 거 아닌가 싶음 - 이건 스펙트럼 같음 직접 승인한 수정은 어느 정도 공을 인정할 수 있지만, 완전한 **vibe-coded 앱**은 거의 관여하지 않음 나는 중간쯤에 있음 — AI가 만든 코드를 전부 리뷰하진 않지만, 아키텍처 설계와 리팩터링 방향은 내가 주도함 결과물은 내가 직접 만들었을 때와 비슷하지만 훨씬 빠르게 완성됨 - Meta에는 이제 **AI 사용량 리더보드**가 있어서, Claude 토큰을 가장 많이 소비하는 사람을 보여준다고 함 Meta가 Claude를 쓰니 Anthropic 입장에서는 꽤 기쁠 듯함 - 사실 LOC가 많다는 건 **나쁜 결과의 신호**일 수도 있음 - 어떤 사람들은 LoC가 품질 지표로 무의미하다고 주장함 이제는 구현·테스트·유지가 전부 **에이전트가 담당**하는 시대이기 때문임 LoC는 단지 에이전트가 얼마나 요구사항을 밀어붙일 수 있는지를 보여주는 **능력의 지표** 정도로 봄 인간의 비판적 리뷰는 여전히 피드백으로 주입 가능함 - “**추상화를 더 많이 써야 한다**”는 말은 예전엔 맞았을지 몰라도, 지금은 오히려 반대라고 느낌 나는 **WET(Write Everything Twice)** 철학을 좋아함 — 두 번 써보고 세 번째에야 추상화를 고려함 - 이건 흔히 **Rule of Three**라고도 부름 [위키 문서](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)) 참고 - 소프트웨어의 진정한 아름다움은 **올바른 추상화**에 있음 운영체제, RDBMS, 클라우드 오케스트레이션 같은 혁신이 그 예임 하지만 대부분의 코드는 단순한 비즈니스 로직이라 추상화가 오히려 방해됨 그래서 나는 “**세 가지 실사용 사례**가 입증되기 전엔 플랫폼을 만들지 말라”는 원칙을 둠 - 두 번 이상 작성하는 건 낮은 기준이라, Perl의 인용문과도 충돌하지 않는다고 생각함 - 두 번째 작성은 문제를 더 잘 이해한 상태에서 개선할 기회임 세 번째에 추상화를 시도할 때는 **Second-System Effect**를 경계해야 함 — 과도한 자신감이 복잡한 시스템을 낳음 - 1991년 *Programming Perl* 이후 생긴 **추상화 레이어의 폭증**은 놀라울 정도임 - 독일 장군 **Kurt von Hammerstein-Equord**의 유명한 인용문을 공유함 똑똑하고 부지런한 사람은 참모, 멍청하고 게으른 사람은 일상 업무, 똑똑하고 게으른 사람은 리더, 그리고 **멍청하고 부지런한 사람은 위험**하므로 절대 책임을 맡기면 안 된다고 함 - “나 같은 **90% 게으른 부류**는 어디 있나?”라며 농담 섞인 반응을 남김 - LLM으로 20만 LOC를 썼다고 자랑하는 것도 어리석지만, 그걸 보고 “저 코드 멍청하네”라고 비웃는 것도 똑같이 잘못된 태도라고 생각함 결국 중요한 건 **코드 출력이 아니라 가치 창출**임 Garry Tan이 실제로 가치 있는 걸 만들었는지는 모르겠음 - 코드 품질이 중요하지 않다고 생각하면 큰일임 [Horizon IT 스캔들](https://en.wikipedia.org/wiki/Horizon_IT_scandal) 같은 사례를 보면, 나쁜 코드가 실제 피해를 낳음 Garry의 프로젝트를 분석한 폴란드 개발자 Gregorein의 리뷰에 따르면, 그 앱에는 **테스트 하니스, Hello World 앱, 중복 로고 파일** 등 엉망진창이 포함되어 있었음 이런 코드가 보안 공격 표면을 넓히지 않았을까 우려됨 - Garry는 단순한 개발자가 아니라 **YC의 CEO**임 LOC를 신경 쓰는 게 아니라 **AI 홍보용 게시물**을 올린 것임 - 진짜 지표는 **가치 – 비용**임 AI는 개발·운영 비용을 줄이지만, 보안·법적 리스크 같은 **숨은 비용**을 늘림 AI 찬양론자들은 전자만 강조함 - 20만 LOC를 읽어가며 나쁜 아이디어임을 증명할 시간은 없음 그건 **vibe coder**가 증명해야 할 일임 LOC로 자랑하는 건 여전히 어리석다고 생각함 - “가치 창출”이라는 말 자체가 위험할 수 있음 화석연료 기반 성장처럼, 단기적 가치가 장기적 비용을 초래할 수도 있음 - 최근 몇 개의 PR을 보며 **LLM이 잘못된 해결책**을 내놓는 걸 자주 봄 예를 들어 이미 존재하는 JSON 파서를 두고 직접 파서를 구현하는 식임 인간이라면 “이건 너무 비효율적이야”라고 느꼈겠지만, **LLM은 게으름이 없어서** 잘못된 방향으로 열심히 일함 - 또 프로젝트 내 중복 함수를 전혀 인식하지 못함 `formatTimestamp` 같은 함수가 세 개나 존재하는 걸 **grep 한 번이면 알 수 있는데도** 무시함 - LLM이 **게으르지 않다**는 말에 공감함 다만 이게 영구적인 문제인지, 다음 모델 업그레이드나 **CICD 파이프라인**에서 해결될지는 모르겠음 나는 기능 완료 후 “버그나 리팩터링할 부분이 있는지 확인하라”고 프롬프트를 주는데, 나중엔 자동으로 **최근 커밋을 분석해 단순화 제안**을 하는 단계가 생길 수도 있을 듯함 - 하지만 “X를 찾아라”라고 하면 LLM은 항상 뭔가를 찾아냄 그래서 **종료 조건 정의**가 어렵다는 문제가 있음 - 결국 문제는 도구의 본질이 아니라 **사용 방식의 한계**임 “추가하라”고만 하면 무조건 추가하고, “줄이라”고 하면 LOC를 줄임 큰 작업을 맡기고 리뷰를 생략하면 **코드 슬롭**이 쌓이기 쉬움 - LLM은 단순한 콘솔 출력 프로그램 대신 **풀 SPA**를 만드는 경향이 있음 또 `spec.md` 파일을 간결하게 유지하지 못함 “이 문서를 업데이트하고 주변 내용을 단순화하라”고 하면 오히려 더 복잡하게 만듦 결국 **사람이 직접 요약**해야 읽기 좋은 문서가 나옴 LLM 출력물을 편집하는 건 고통스럽고, 직접 작성해야 이해도 유지됨 - LLM과 vibe coder들에게 소프트웨어 개발의 고전 교훈을 가르칠 때임 [Negative 2000 Lines of Code](https://www.folklore.org/Negative_2000_Lines_Of_Code.html) 이야기처럼, **코드를 줄이는 것이 진짜 진보**일 때가 많음 - 이런 리더십과 함께 일할 수 있다면 얼마나 좋을까 하는 생각이 듦 정말 **이해력 있는 리더**와 일하는 건 큰 행운임