AI 시대의 소프트웨어 개발에서 인간 프로그래머가 가진 ‘게으름’이라는 미덕이 사라질 위험에 대해, 소프트웨어 엔지니어 브라이언 캔트릴(Bryan Cantrill) 씨가 자신의 블로그에서 논했습니다.
The peril of laziness lost | The Observation Deck https://bcantrill.dtrace.org/2026/04/12/the-peril-of-laziness-lost/
프로그래밍 언어 Perl의 창시자로 알려진 래리 월(Larry Wall) 씨는 저서에서 프로그래머의 세 가지 미덕으로 ‘게으름’, ‘조바심’, ‘자만심’을 꼽았습니다. 여기서 말하는 ‘게으름’은 단순한 손쉬운 작업을 의미하는 것이 아니라, ‘미래의 자신이나 타인의 작업을 줄이기 위해 더 나은 추상화나 단순한 설계를 고민하는 자세’를 뜻합니다.
캔트릴 씨에 따르면, 이러한 의미의 게으름은 사실 큰 지적 노력을 수반합니다. 코드를 작성하지 않고 문제를 머릿속에서 여러 번 되새기는 ‘해먹 기반 개발(Hammock Driven Development)’ 같은 시간 역시 미래의 부담을 줄이기 위해 필요한 작업이라고 봅니다.
한편 캔트릴 씨는 지난 20년간 소프트웨어를 만드는 사람들의 층이 넓어져 자신을 프로그래머라고 부르지 않는 사람들도 개발에 참여하게 되었다고 언급했습니다. 그러면서 게으름이라는 단어에 담겨 있던 아이러니와 설계 사상이 전달되기 어려워지고, ‘많은 코드를 작성하는 것’을 성과로 보는 풍조가 강해졌다고 주장했습니다.
그리고 LLM(대규모 언어 모델)이 등장하면서 이러한 경향이 더욱 가속화되었습니다. LLM은 이용자의 개발 태도를 더 강력하게 실행할 수 있기 때문에, 코드 양을 자랑하는 개발 문화에게는 ‘근육 강화제’처럼 작용한다고 캔트릴 씨는 지적합니다. DTrace 전체도 세는 방식에 따라 약 6만 줄 정도라고 보충하며, 단순히 코드 줄 수를 쌓아 올리는 것의 위험성을 강조했습니다. 문학 작품을 무게로 평가하는 것과 같아, 코드 양을 생산성 지표로 취급하는 발상은 초보자도 오류임을 알 수 있을 것이라고 말했습니다.
예를 들어, Y 콤비네이터의 게리 탄(Garry Tan) CEO가 “하루 3만 7천 줄의 코드”를 작성했다고 X(구 트위터)에 게시했습니다.
> Absolutely insane week for agentic engineering
> 37K LOC per day across 5 projects
> Still speeding up pic.twitter.com/VR3utsduYx https://t.co/VR3utsduYx
> — Garry Tan (@garrytan) March 30, 2026 https://twitter.com/garrytan/status/2038555792052506941?refsrc=twsrc%5Etfw
하지만 폴란드의 소프트웨어 엔지니어 그레고레인(gregorein) 씨가 탄 씨의 ‘newsletter-blog-thingy’를 조사한 결과, 한 번 로드에 여러 개의 테스트 하네스, Hello World Rails 앱, 끼어든 텍스트 에디터, 같은 로고의 8가지 변형 등이 포함되어 있었다고 합니다.
> so... I audited Garry's website after he bragged about 37K LOC/day and a 72-day shipping streak.
> here's what 78,400 lines of AI slop code actually looks like in production.
> a single homepage load of https://t.co/9qJh8Oaz8c https://t.co/9qJh8Oaz8c downloads 6.42 MB across 169 requests.
> for a… https://t.co/GPAeX8fyOl https://t.co/GPAeX8fyOl pic.twitter.com/i0NkfGmhwd https://t.co/i0NkfGmhwd
> — gregorein (@Gregorein) March 31, 2026 https://twitter.com/gregorein/status/2038953944475472316?refsrc=twsrc%5Etfw
캔트릴 씨는 개별 문제는 수정 가능하다고 하면서도, 문제의 본질은 이러한 실수 자체가 아니라 ‘LLM을 사용해 대량의 코드를 생성하는 방법론이 불필요한 것을 쌓아 올리는 방향으로 흐르기 쉽다는 점’이라고 봅니다. 즉, LLM에는 프로그래머의 미덕인 ‘게으름’이 본질적으로 결여되어 있다는 것이 캔트릴 씨의 주장입니다. LLM에게 작업량은 인간처럼 비용이 들지 않으며, 미래의 자신이나 타인의 시간을 절약하려는 동기도 없습니다.
따라서 캔트릴 씨는 LLM을 방치하면 시스템을 더 좋게 만드는 대신, 기존의 혼란 위에 더 많은 코드를 쌓아 올릴 가능성이 있다고 경고합니다. 코드 줄 수 같은 겉보기 지표에는 호소하기 쉬운 반면, 설계의 단순함, 인지 부하의 낮음, 미래의 유지보수성 같은 진정으로 중요한 것을 해칠 위험이 있다는 것입니다.
캔트릴 씨는 “인간에게는 시간과 인지 부하라는 제약이 있기 때문에, 복잡한 시스템 앞에서 더 명확한 추상화나 단순한 구조를 추구하는 동기가 생긴다”고 말하며, “훌륭한 엔지니어링은 제약에서 태어나는 것이며, 시간이나 부하의 제약이 없는 LLM이 스스로 같은 판단을 내릴 것이라고 기대할 수 없다”고 강조했습니다.
다만 캔트릴 씨는 LLM 자체를 부정하는 것은 아닙니다. LLM은 소프트웨어 엔지니어링에서 강력한 도구이며, 기술 부채 대응이나 개발의 엄격함을 높이는 데 활용할 수 있다고 말합니다. 캔트릴 씨는 LLM을 인간의 ‘게으름’을 대체하는 존재로 다뤄서는 안 된다며, “LLM은 인간의 좋은 게으름에 따르게 해야 할 도구이며, 단순히 코드를 늘리는 것이 아니라 더 단순하고 강력한 시스템을 만들고 미래의 개발자에게도 도움이 되는 방식으로 사용해야 한다”고 주장했습니다.