George Hotz의 말이 맞다. 코딩 에이전트들이 쓰레기(Slop)의 바다를 만들어내고 있다.

George Hotz의 말이 맞았습니다. 우리는 '영원한 슬롭템버(Eternal Sloptember)'에 갇혀 있으며, 여러분이 사랑하는 모든 오픈 소스 프로젝트들은 기계가 생성한 터무니없는 결과물(nonsense)에 잠겨 있습니다.

최근 저는 업무 중에 수많은 풀 리퀘스트(Pull Request)를 거절하고 있습니다. 코드가 작동하지 않아서가 아닙니다. 마치 사양(specification)을 믹서기에 넣고 돌린 다음, 그 결과물로 나온 '작동하는' 코드를 쏟아낸 것 같으며, 그 누구도 이를 유지보수할 의도가 없어 보이기 때문입니다.

논지 (The Thesis)

2026년 5월, George Hotz는 완벽한 제목인 "The Eternal Sloptember"를 발표했습니다. 과거 Usenet은 'Eternal September'를 겪었습니다. 당시 AOL은 커뮤니티가 사회화할 수 있는 속도보다 더 빠르게 아무것도 모르는 신규 유입자들로 네트워크를 가득 채웠습니다. 우리는 현재 동일한 상황에 처해 있습니다. 다만 그 신규 유입자들이 리뷰 피드백을 반영하며 업데이트하지 않는, 지칠 줄 모르는 코딩 에이전트(coding agents)들이라는 점이 다를 뿐입니다.

문제는 에이전트가 작성한 코드가 컴파일(compile)되지 않는 것이 아닙니다. 컴파일은 잘 됩니다. 문제는 그 코드가 아키텍처적으로는 완전히 멍청하면서도, 아주 '자신만만하게' 컴파일된다는 점입니다.

쌓여가는 증거들 (The Evidence Is Piling Up)

Linus Torvalds는 부적절한 시점에 제출된 AI 생성 커널 패치(kernel patches)를 되돌리겠다고 위협했으며, 사소한 AI 생성 수정 사항들에 대해 더 엄격한 태도를 취하고 있습니다. 이 사실을 잘 새겨 들어보십시오. 지구상에서 가장 숙련된 리뷰 프로세스를 가진 프로젝트인 Linux 커널조차 AI가 주도하는 사소한 수정 사항들의 범람으로 인한 비대화(bloat) 문제를 겪고 있습니다.

제가 Andrej Karpathy를 엄청나게 존경하고, 저 또한 TensorAgentCompiler를 실행하면서 온갖 지저분한 스파게티 코드(spaghetti code)를 추가한 적이 있지만, "지저분하지만 생산적인" 방식은 결국 '추가하기는 쉽지만 변경하기는 불가능한' 코드베이스를 만드는 길이라는 점을 지적하지 않을 수 없습니다. 터보차저를 장착한 기술 부채(Technical debt)인 셈입니다. 🚀

리뷰어들이 따라잡을 수 없는 이유 (Why Reviewers Can't Keep Up)

여기에 아무도 말하고 싶어 하지 않는 구조적인 문제가 있습니다:

→ 에이전트(Agents)는 인간이 의미 있게 검토할 수 있는 속도보다 10~50배 더 빠르게 코드를 생성합니다.
→ 리뷰 피로(Review fatigue)는 실재합니다. 오늘 벌써 8번째 AI 생성 PR(Pull Request)을 마주하면, 당신은 훑어보기 시작할 것입니다.
→ 이 쓰레기(Slop)는 언뜻 보기에 합리적으로 보이기 때문에, 게으른 리뷰를 통과합니다.
→ 병합된 각각의 쓰레기 PR은 다음 리뷰어를 위한 기본 복잡도(Baseline complexity)를 높입니다.

이것은 래칫(Ratchet)과 같습니다. 오직 한 방향으로만 작동합니다. 각각의 "충분히 괜찮은" 병합은 다음 리뷰를 더 어렵게 만들고, 이는 다음의 게으른 승인을 더 가능성 있게 만듭니다.

불편한 중간 지대 (The Uncomfortable Middle Ground)

저는 AI 비관론자가 아닙니다. 저는 항상 코딩 로봇을 활용합니다. 이들은 보일러플레이트(Boilerplate), 테스트, 그리고 탐색적 프로토타이핑(Exploratory prototyping)에 매우 놀라운 도구입니다.

물론, 제가 에디터 내에서 에이전트를 활용하는 것 — 즉, 코드가 분기되기 전에 제가 모든 줄을 분석하는 것 — 과, 유지 관리자들이 쉬는 동안 프로젝트에 PR을 여는 독립적인 에이전트 사이에는 분명한 차이가 있습니다. 전자는 도구입니다. 후자는 오염 물질입니다. 😤

Karpathy가 주장하는 생산성 향상은 코드를 작성하는 사람의 마음속에서만 존재합니다. 다운스트림(Downstream)에 있는 다른 모든 사람들에게는 부정적입니다. 그것은 외부 효과(Externality)이며, 우리는 오픈 소스에서 외부 효과의 가격을 책정하는 데 매우 서툽니다.

실제로 도움이 되는 것 (What Actually Helps)

저에게도 만능 해결책(Silver bullet)은 없습니다. 하지만 제 영역에서 무엇이 효과가 있는지는 알고 있습니다:

→ 모든 PR에 대한 의무적인 인간의 증명(Attestation) — "나는 이것을 읽었고, 이해했으며, 책임을 집니다"
→ 항상 더 작은 차이(Diffs)를 유지할 것 — 만약 에이전트가 600줄을 생성했다면, 나누거나 다시 작성하십시오.
→ 에이전트의 출력을 _기여(Contribution)_가 아닌 _초안(Draft)_으로 취급할 것
→ 생성된 코드의 통계적 패턴을 표시(Flag)하는 리뷰 도구

도구보다 중요한 것은 문화적 변화입니다. 우리는 "에이전트가 이것을 30초 만에 작성했다"는 것을 기술의 과시로 간주해서는 안 되며, 오히려 문제의 징후로 간주해야 합니다.

진짜 질문 (The Real Question)

Hotz의 진단은 정확합니다. 쓰레기(Slop)의 바다는 이미 도래했습니다. 제가 더 불확실하게 느끼는 점은, 우리가 이에 대해 빠르게 문화적 면역 반응을 발달시킬 것인지, 아니면 모든 새로운 코드베이스가 작성된 첫날부터 마치 상속받은 레거시(Legacy)처럼 느껴질 때까지 단순히 이 부패에 적응해 버릴 것인지 하는 점입니다. 🫠

그래서 저는 이것이 궁금합니다. 여러분의 팀은 이미 에이전트가 생성한 코드의 품질 문제로 한계에 부딪혔나요, 아니면 문제가 심각해지기 전에 툴링(Tooling)이 따라잡을 것이라고 생각하시나요?