게으름의 미덕을 잃는 위험

• 프로그래밍에서의 게으름은 단순한 태만이 아니라, 추상화와 단순함을 추구하는 지적 미덕으로 정의됨
• 진정한 게으름은 문제를 깊이 숙고해 미래의 시간을 절약하는 과정이며, 이는 후대 개발자에게도 이익을 줌
• 현대의 고수준 추상화와 ‘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) 와 같은 비생산적 게으름의 문제를 해결하거나, 엔지니어링 엄격성을 강화하는 데 활용 가능함
  • 그러나 그 사용 목적은 반드시 ‘미덕적 게으름’ 을 실현하는 방향이어야 함
    • 즉, 더 단순하고 강력한 시스템을 만들어, 미래 세대의 개발자들에게 도움이 되는 결과를 남겨야 함

[GN⁺]

Hacker News 의견들

• 내 분야인 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라고도 부름
    위키 문서 참고
  • 소프트웨어의 진정한 아름다움은 올바른 추상화에 있음
    운영체제, RDBMS, 클라우드 오케스트레이션 같은 혁신이 그 예임
    하지만 대부분의 코드는 단순한 비즈니스 로직이라 추상화가 오히려 방해됨
    그래서 나는 “세 가지 실사용 사례가 입증되기 전엔 플랫폼을 만들지 말라”는 원칙을 둠
  • 두 번 이상 작성하는 건 낮은 기준이라, Perl의 인용문과도 충돌하지 않는다고 생각함
  • 두 번째 작성은 문제를 더 잘 이해한 상태에서 개선할 기회임
    세 번째에 추상화를 시도할 때는 Second-System Effect를 경계해야 함 — 과도한 자신감이 복잡한 시스템을 낳음
  • 1991년 Programming Perl 이후 생긴 추상화 레이어의 폭증은 놀라울 정도임

• 독일 장군 Kurt von Hammerstein-Equord의 유명한 인용문을 공유함
  똑똑하고 부지런한 사람은 참모, 멍청하고 게으른 사람은 일상 업무, 똑똑하고 게으른 사람은 리더,
  그리고 멍청하고 부지런한 사람은 위험하므로 절대 책임을 맡기면 안 된다고 함

  • “나 같은 90% 게으른 부류는 어디 있나?”라며 농담 섞인 반응을 남김

• LLM으로 20만 LOC를 썼다고 자랑하는 것도 어리석지만, 그걸 보고 “저 코드 멍청하네”라고 비웃는 것도 똑같이 잘못된 태도라고 생각함
  결국 중요한 건 코드 출력이 아니라 가치 창출임
  Garry Tan이 실제로 가치 있는 걸 만들었는지는 모르겠음

  • 코드 품질이 중요하지 않다고 생각하면 큰일임
    Horizon IT 스캔들 같은 사례를 보면, 나쁜 코드가 실제 피해를 낳음
    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 이야기처럼, 코드를 줄이는 것이 진짜 진보일 때가 많음

• 이런 리더십과 함께 일할 수 있다면 얼마나 좋을까 하는 생각이 듦
  정말 이해력 있는 리더와 일하는 건 큰 행운임