AI 시대의 '게으름'은 '과도한 결과물 생성'인 것 같다: 분석

안녕하세요. 가슴이 작은 문조(文鳥)가 되고 싶은 사람입니다.

최근에 본 포스트에서 본 영상이 궁금해졌습니다.

Shopify의 Tobi Lütke 씨가 팟캐스트에서 이런 내용을 말하고 있습니다.

과거의 게으름 → 결과물을 내지 않는 사람
현재의 게으름 → 결과물을 너무 많이 내서 주변 사람들의 확인 작업을 늘리는 사람

원 자료는 Shane Parrish의 팟캐스트 'The Knowledge Project'에서 2026년 9월 15일에 공개된 회차입니다.

요약 기사는 아마 이것일 겁니다: Shopify CEO Warns AI 'Slop Grenades' Shift Work To Coworkers (Shopify CEO가 AI '슬롭 그레네이드'로 업무를 동료에게 전가하는 것에 대해 경고하다)

Shippify 하면 AI 활용에 적극적인 이미지가 연상되었기 때문에, 그 회사 사람이 '너무 많이 내는 것이 게으름'이라고 말하는 것이 흥미하다고 생각했습니다.

한편 같은 시기에 lauren 씨(@poteto)가 직접 만든 스킬 모음집인 pstack을 사용해 월 약 2000 PR을 실제 서비스에 올린 이야기도 화제가 되었습니다.

'너무 많이 내는 것이 게으름'과 '월 2000 PR'은 언뜻 보면 모순되지 않나? 라는 의문이 들었고, 알아봤더니 결국 같은 이야기를 하고 있다는 생각이 들어 정리해 보았습니다.

에세이입니다. 실례가 되었다면 죄송합니다.

먼저 핵심 내용을 말씀드립니다.

• AI 시대의 게으름은 '내지 않는 것'이 아니라 '너무 많이 내는 것'이 된 것 같다.
• 작은 수정 사항을 AI로 고칠 수 있는 것은 좋지만, 리뷰, QA, 재작업 비용은 후속 담당자가 지불하고 있다.
• 고객 가치와 팀 전체의 비용으로 ROI를 판단하지 않으면, 모르는 사이에 프로젝트 지연 요인이 될 수 있다.
• 월 2000 PR을 내는 사람은 확인 비용을 타인에게 전가하지 않고 시스템으로 낮추고 있다.
• 고객 가치에 책임을 지고 '내도 괜찮습니다'라고 말할 수 있는 사람을 늘리고, 그 승인 수준이 깊고 폭넓을수록 다른 팀원의 확인 비용은 줄어든다는 설이다.

계속 내용이 궁금하신 분들은 다음 내용을 참고해 주세요.

영상 자막은 다음과 같았습니다.

The failure case now of lazy work is not lack of output. It's actually over output now.
(게으른 작업의 현재 실패 사례는 결과물의 부족이 아니다. 실제로는 과도한 결과물이다.)

Shopify 내부에서는 이를 slop grenade라고 부른다고 합니다. 직역하면 '슬롭 수류탄'. AI로 만든 것을 스스로 확인하지 않고 동료에게 던져, 확인이나 수정의 부담을 받는 쪽에 전가하는 것을 의미합니다.

이름이 너무 흉악하다

Lütke 씨는 두 가지 예를 들었습니다.

예시 1: AI 에이전트에게 코드 변경을 요청한다
→ 내용을 제대로 읽지 않고 PR을 승인한다
→ 결국 리뷰는 동료가 하게 된다...

문서 공유 같은 것에서도 단순히 길기만 하면 인지 부하가 높아져 의사 결정에 시간이 걸린다는 경험이 있어서 공감했습니다.

AI 코딩 시의 코드 주석 등도 지나치게 긴 것은 일단 읽어버리기 때문에 너무 길면 좋지 않다는 느낌은 영상을 보기 전부터 있었습니다.

Shopify에서는 사내 AI 에이전트를 통해 생성되는 PR이 전체의 최대 절반 정도가 있다고 합니다. 그렇게까지 AI를 활용하는 회사가 다음에 직면한 문제가 '과도함'이었다는 것은 상당히 시사적이라고 생각합니다.

poteto 씨는 Cursor의 엔지니어이며, 자신만의 스킬 모음집인 pstack을 공개했습니다.

본인의 가이드 기사에 따르면, 8월에 실제 서비스에 올라간 PR은 2,462건이었다고 합니다.

숫자만 보면 Lütke 씨가 말하는 '과도함'의 전형처럼 보입니다. 하지만 내용을 읽어보면 오히려 반대되는 것을 하고 있다는 인상을 받고, 성과를 내기 위해 해야 할 일에 대한 주장은 Lütke 씨와 비슷합니다.

가이드 1부의 제목은 Verification is all you need입니다. AI에게 코드를 작성시키기 전에 먼저 검증 시스템을 만들라는 이야기로 시작됩니다.

・PR은 작고 자립적으로, 리뷰하기 쉬운 단위로 나눈다
・문제가 발견되면 PR뿐만 아니라 AI가 작동하는 환경 자체를 고친다

팀 전체에서 하루에 수백 개의 PR이 들어오는 상황에서, 본인은 자신을 '정원사'에 비유하며 코드를 지키고 리팩토링하거나 린트(lint) 및 체크를 추가하여 품질을 유지하고 있다고 합니다.

그리고 정말 대단하다고 생각한 것은, 에이전트 이전에는 PR 수 같은 것을 신경 쓴 적이 없었다. 그것은 허영의 지표였다 라는 점도 본인이 작성했습니다.

~~뭔가 지나치게 코드 줄 수를 보여주는 기사들도 있잖아~~~

참고:

Lütke 씨가 수류탄을 던지는 사람 이야기와 poteto 씨의 이야기를 나란히 놓고 보면, 이렇게 된다고 생각합니다.

슬롭 수류탄을 던지는 사람 → 타인에게 확인 비용을 전가함
poteto 씨 → 확인 비용을 스스로 지불하고, 시스템으로 주변의 몫까지 낮추고 있음

두 경우 모두 아웃풋은 많이 나옵니다. 다른 점은 아웃풋의 질(≒아웃컴)과 팀 전체의 확인 비용입니다.

아웃풋의 가치 = 고객에게 전달되는 가치 - 타인에게 발생시킨 확인 비용

뒤쪽 항목이 앞쪽 항목보다 커지면, 가치는 마이너스가 됩니다. 게다가 본인은 '많이 냈다'는 실감을 가지고 있기 때문에, 마이너스를 내고 있다는 사실을 깨닫기 어렵습니다.

일단 엄청 큰 PR을 던지는 사람

AI가 짧게 만들어주는 것은 주로 '코드를 작성하는' 공정입니다. 그 부분이 0에 가까워져도, 리뷰와 QA는 0이 되지 않습니다.

'AI로 간단히 고쳤어요!'의 간단히

은 코딩 부분에서만 해당하며, 그 뒤에는 리뷰할 사람의 시간, QA할 사람의 시간, 반려되었을 때의 재작업 시간이 있습니다.

구현 비용이 0으로 보여도, 팀의 비용은 0이 아닐 수 있습니다.

이는 직종을 가리지 않고 나타나는 현상으로, 부탁받지 않은 리팩토링을 덧붙이거나, AI가 작성한 테스트를 거의 읽지 않고 장황한 케이스를 대량으로 추가하는 경우입니다. 본인은 '좀 좋게 했다'라든가 'AI가 덤으로 내놓았으니 그냥 넣자'라는 생각일지라도, 리뷰하는 쪽은 읽을 양과 생각할 양이 늘어날 뿐이라는 경우가 있습니다.

그래서 직종이나 공정을 가리지 않고, 성과를 내기 위한 후속 비용을 예측하고 있는가 (나오는 성과는 같더라도 비용을 줄이려는 의식이 있는가)

라고 생각합니다.

어떤 PR이 타당한지 판단할 수 있는 사람은 그 코드베이스나 사양에 어느 정도 정통해야 합니다.

거기에 '간단히 수정했으니 봐주세요'가 날아옵니다. 리뷰 자체는 10분이라도, 지금 작업의 맥락을 한 번 내려놓고 PR의 맥락을 머릿속에 넣었다가 다시 돌아오기 때문에, 30분 집중이 끊기는 일은 보통 발생합니다.

리뷰를 하는 쪽의 노력도 당연히 있을 것이라고 생각하지만요.

리뷰 대기 중인 PR이 쌓여가는 문제입니다.

제약 이론(Constraint Theory)이라는 생각이 있는데, 간단히 말하면 병목 현상 외의 공정을 아무리 빠르게 해도 전체는 빨라지지 않고, 병목 현상 앞에 재고가 쌓일 뿐

라는 것입니다.

AI로 만드는 공정이 빨라져서 리뷰와 QA가 병목 현상이 되면, 바로 이런 일이 발생합니다. 리뷰 대기 PR이나 QA 대기 PR은 세상에 내놓아야 비로소 가치가 있습니다.

그대로 재고 상태로 두어도 가치는 0입니다.

오히려

• main이 진행되어 충돌(conflict)이 일어난다
• 그 사이에 사양이 바뀐다
• 만든 본인도, 왜 이렇게 했는지 잊는다

'지금은 볼 수 없습니다'라고 답하는 것에도 은근히 커뮤니케이션 비용이 들기 때문에 보게 됩니다.

하나하나가 작더라도 쌓여가는 누적 효과로 메인 프로젝트는 지연될 수도 있습니다.

프로토타입으로 전달할지, PR로 전달할지를 구분한다

AI로 만든 작동하는 것을 보여주고 궤도 수정할 수 있는 것은 분명 AI의 장점입니다. 따라서 사양의 초안(叩き台)으로 간주하고, 프로토타입이라면 리뷰나 QA가 필요 없다고 생각합니다. 그런 의미에서도 검증 환경을 가볍게 사용할 수 있는 체제는 더욱 중요해질 것입니다.

검증을 사람에게서 시스템으로 옮긴다

사람이 매번 보지 않아도, 과거의 결정 프로세스나 판단 지표를 축적하고 시스템화함으로써 인지 부하(cognitive load)를 낮춥니다.

AI가 리스크를 평가하게 하여 리뷰 필요 여부를 결정한다

PR마다 AI가 리스크를 평가하여, 리뷰어 필수 여부를 결정하는 시스템입니다.

저위험 (리뷰 불필요, 나중에 추출해서 확인)
・문구 또는 스타일 수정
・DB 스키마에 건드리지 않음
...

모든 PR을 같은 무게로 리뷰하는 것이 아니라, 되돌리기 쉬움
과 고장 났을 때의 영향
으로 분류하는 이미지가 있다고 생각했습니다.

병목 현상인 리뷰 앞에서 재고를 분류하고, 정말 사람의 눈이 필요한 것만 흘려보내는 이미지입니다. 물론 판정 기준을 정하는 것은 인간이고, 저위험이라서 머지해도 좋다라고 결정한 책임도 인간에게 남습니다. 문제가 생기면 확인 공수를 늘리고 싶어지지만, 엣지 케이스일수록 탐지 비용이 들기 때문에 균형이 최근 중요하다고 생각합니다.

1년 반 전에 Cursor가 시장을 석권하고 있는 이유를 조금 생각해 보는 글에서, Cursor의 강점은 만드는 사람 자신이 사용자이자 도메인 전문가라는 것이라고 썼습니다. 엔지니어가, 엔지니어를 위한 도구를 만들고 있습니다.

poteto 님은 바로 그런 Cursor 사용자이며, 백그라운드는 UX 디자이너 출신이고 React 코어 팀 소속인 것 같습니다. 코딩 에이전트는 자신의 작업 도구 그 자체이기 때문에, AI의 결과물이 맞는지, 사용하는 사람에게 기쁜지 여부를 스스로 판별할 수 있습니다. 검증 시스템을 만들어 기계가 판단하게 하는 것입니다.

AI 시대에 가치가 올라가는 것은 인정할 수 있는 깊이를 가진 사람이라고 썼는데, poteto 님은 그 극단적인 예로 가로와 세로 모두 깊이가 있습니다.

깊이가 있다
→ AI의 결과물을 스스로 승인할 수 있다
→ 타인의 시간을 사용하지 않고 내보낼 수 있다
...

pstack의 사상을 보면

• 도메인 전문가(사용자 관점)
• UX 디자이너(사용하기 쉬운 기능을 결정)
• 엔지니어(만드는 사람)

로서, 각 공정에서 잘 안 되었을 경우 그 결과가 아니라 판단 지표를 남기면서 점진적으로 맡기는 범위를 넓혀가는 방식을 취하고 있는 것 같습니다.

자신이 가장 잘 아는 코드베이스에서 만들 때, 만드는 사람과 사용자가 같다는 의미인데,

대부분의 엔지니어는 자신 자신이 아닌 누군가의 업무를 위해 시스템을 만듭니다. 코드로 올바른지는 판단할 수 있어도, '현장 사람에게 정말 기쁜가'는 엔지니어링만으로는 판별하기 어려운 경우가 많습니다.

① 먼저 자신이 승인할 수 있는 범위를 넓힌다
② 승인할 수 없는 부분은 검증 시스템에 맡긴다
③ 그 결과로, 내보낼 양이 늘어난다

라는 순서입니다. 순서를 거꾸로 해서 양부터 시작하면 아마 폭발물 장인(スロップ手榴弾職人)이 될 것 같습니다.

스테이크홀더에게 승인을 받을 때 하나하나 답을 받는 것보다는, 승인에 이르는 판단 기준이나 사고 과정을 남겨가는 팀이 앞으로 강하지 않을까 이번에 생각했습니다.

신뢰받는 Tech Lead가 '이건 급합니다, 고객에게 마이너스 영향은 없습니다'라고 말하면, 대체로 바로 릴리스가 승인되는 식의 것이 존재한다고 생각합니다.

이 사람은 고객 경험까지 고려해서 말하고 있으니 아마 괜찮을 거야

같은 판단이 있습니다. 신뢰가 있으면 확인 비용이 거의 0이 된다는 의미에서도, 앞으로 성과를 내나가는 데 있어서 신뢰는 중요하다고 생각했습니다.

작업에 책임지다 → '말한 대로 만들었습니다'
고객 가치에 책임지다 → '이건 릴리스해도 괜찮습니다. 고객에게 마이너스는 없고 기뻐할 것입니다'

전자의 아웃풋은 뒤에서 누군가가 고객 영향 여부를 확인해야 합니다. 후자는 그 확인을 본인이 끝마치고 있습니다.

고객이나 도메인을 이해하고, 변경의 영향 범위를 스스로 추정할 수 있는 것.

신뢰는 한 번에 만들어지지 않기 때문에, 점진적으로 신뢰를 쌓아 넓혀갈 수밖에 없을까 싶습니다.

이게 통하면 OK라는 시스템을 갖추는 것도 더 중요해질 것 같습니다.

2월경에 쓴 글에서 AI는 날마다 정밀도가 높아지고 효율적이라는 느낌을 썼지만, 아직 패러다임 시프트가 일어나지 않았다는 인상을 줬습니다.

지금 어떻게 생각하냐면, 근본적으로는 아직 변하지 않은 것 같습니다. 책임은 여전히 인간이 지고 있고, 승인이 병목 현상인 것도 바뀌지 않았습니다.

다만, Opus 5.5 정도부터 AI의 아웃풋 정밀도가 상당히 높아졌다는 체감이 있습니다. 한 번에 기대하는 것이 나오는 확률이 명확하게 늘어났습니다.

Lütke 씨가 문제에 이름을 붙여 공유하거나, poteto 님이 검증 시스템에 투자하고 있는 것도 그렇지만, Shopify에서는 사내 AI 에이전트가 매일 밤 그날 잘 안 되었던 것을 되돌아보고 자신의 지시 파일을 스스로 고치는 시스템까지 있다고 합니다. 팀은 'dreaming'이라고 부른다고 합니다. 인간의 리뷰에 의존하는 것이 아니라, AI 측의 품질을 높여 확인 비용을 줄이는 방향의 시도가 점점 늘어날 것 같은 세계선입니다.

패러다임 시프트를 일으킨다기보다는, 무엇이 병목 현상인지가 명확해지고 검증 비용을 시스템이나 체제로 낮추는 노력이 시작되고 있는 것이 아닐까 생각했습니다.

작업뿐만 아니라 고객 가치에 책임져서 '내보내도 괜찮습니다'라고 말할 수 있는 사람을 늘려가는 것.

그를 위해서는 개인의 의식과 환경 조성 양쪽 모두 중요합니다.

중간부터 너무 아웃풋 많이 내서 관계없어졌음ㅋ

여러 가지 써봤지만,

자신 외의 다른 사람의 부하를 줄여주려고 AI 결과물을 제대로 리뷰하고 동작 확인까지 했더니, 어느새 '내가 병목 현상이 되고 있다'는 느낌이 들기도 합니다.

AI 정밀도가 상당히 높아진 것도 있어, 모든 것을 같은 무게로 볼 필요가 없을지도 모릅니다. 그 의미에서 이번 조사는 꽤 참고가 되었습니다.

리뷰를 줄이면 처리량(throughput)은 올라가지만, 리뷰는 팀원들에게 지식을 확산시키는 장소이기도 하므로 공유의 장소를 너무 줄이면 '시스템은 돌아가고 있지만 아는 사람이 극도로 적은' 상태가 될 수도 있다고 생각합니다.

비용 절감 (리뷰를 줄여 처리량을 높이는 것)
↕
지식 표준화

이 균형을 어떻게 맞추는지 잘 모르겠습니다.

이 글도 너무 길어서 읽는 사람의 인지 부하(cognitive load)를 높이고 있다는 설루

이상,