영원한 Sloptember — AI 코딩 에이전트가 개발자를窒息시키는 방법

영원한 Sloptember — AI 코딩 에이전트가 개발자를질식시키는 방법

"AI 에이전트로 tinygrad 일부를 작성하고 USB → PCIe 칩을 리버스했다. 직접 했을 때 더 낫고 빨랐을 수 있다는 의심이 남았다."

조지 홀츠페이스(geohot)가 자신의 블로그에 올린 이 한 마디가, 지금 업계에서 가장 뜨거운 논쟁에 불을 붙였다. AI 에이전트로 소프트웨어 개발을 자동화하겠다는 꿈이, 사실은 "영원한 Sloptember"라는명즈카나이 악몽에 가까울 수 있다는 이야기다.

---

Sloptember란 무엇인가

Sloptember는 Slop(형편없는 산출물)과 September(끝없는 반복)를 결합한 신조어다. AI 에이전트가 코드를 작성할 때, 초반에는 빠르게 진척되는 듯 보이지만 결국 슬롯머신 레버를 당기듯 같은 행동을 반복하면서 끝에 도달하지 못한다는비우이다.

특정 에이전트 실행 환경에서 6개월간 실전 프로젝트를 진행한 개발자의 증언은 씁쓸하다.

> "초반 진척을 빠르게 만들지만, 마무리에서는 슬롯머신 레버처럼 반복 시드에 기대게 하며 끝까지 못 감"

여기에geohot의 딥러닝 프레임워크tinygrad 일부 작성과 하드웨어 리버스 엔지니어링 경험이 가와졌다. 직접 했을 때보다 느리고 결과도 뒤떨어졌다는 결론. 그것도 여러 모델, 여러 하네스, 여러 프롬프트를 시도한 후 나온 결론이다.

---

에이전트는 정말 코딩을 하는가

이 글의 가장봉리한 통찰은 이것이다.

> "AI 에이전트는 프로그래밍을 수행하기보다 프로그래밍의 분포를 흉내 내는 정교한 통계 모델에 가깝다"

무슨 뜻인가 하면, 에이전트는 실제 프로그램의 동작 원리를 이해하고 쓰는 것이 아니라, 훈련 데이터에출현과던코도의 패턴을 결합할 뿐이라는 것이다. 그래서 출력물은 "깨져 있지만 점점 더 탐지하기 어려운 방식으로" 깨진다. 통계 모델이 더 정확해질수록 이런 문제는 더 알아보기 어려워진다.

이는 단순한 성능 문제가 아니다. 성격의 문제다.

---

왜 초반만 빠른가

AI 에이전트의 작동 방식을 생각해보면 답이 보인다.

에이전트는 처음에 가장 가능해 보이는 방향으로 코드를 생성한다. 검색으로 찾은 유사 패턴, 기존 코드베이스의 구조적인 류추, 훈련 데이터의 빈도 높은 표현. 이 조합은 초기 단계에서 빠른 진척을 만들어낸다.

하지만 소프트웨어 개발의 후반부는 수정과 디버깅의 영역이다. 특정 상황에 맞는 미수정, 엣지 케이스 처리, 다른 모듈과의정합. 이 단계에서 에이전트는 자신이 만든 코드를 전체 맥락에서 평가하고 올바른 방향으로수정하는 능력이 부족하다.

결국 에이전트가 반복해서 하는 일은 레버를 다시 당기는 것뿐이다. 이미 생성한 코드를 약간씩 바꿔가며 "다음에는 될지도 모른다"는 기대로 또 다른 시도를 시작한다.

---

대규모 조직일수록 더 큰 피해

이 글의또일개 중요한 주장은 조직 규모와 품질 피해의 관계다.

고성과 개인은 자신이 만든 코드를 직접 점검하고, 산출물이 허술할 때 바로 알아본다. 각 줄을 주의 깊게 읽고 이해하는 방식을 유지한다.

반면 대규모 조직은 다르다.

• 피드백 루프가 느리다

• 자기 점검 없이 "10배 산출"을 추구한다

• 하위 성과자가 에이전트로 대량 생산을 하면 평균 산출 품질이 뚝 떨어진다

AFL(컴파일러 퓨징)은 LLM보다 더 많은 버그를 찾았지만, 개발자들은 지위 상실을 두려워하지 않았다. 체스와 바둑도 AI 이후 오히려 더 인기를 얻었다. 이 비교는 단순한 반론이 아니라, AI 비판을 지위 불안으로만 설명할 수 없다는 것을 보여준다.

---

실제로 유용한 경우와 그렇지 않은 경우

geohot조차 인정하는 것은 있다. AI는 검색과 빠른 프로토타입에는 유용하다는 점이다.

> "많은 검색에서는 더 나은 Google처럼 작동하고, 완성도를 신경 쓰지 않는 빠른 프로토타입에는 매우 빠름"

그러나 소프트웨어 엔지니어로서의 역할에는 회의적이다.

> "함께 일했던 어떤 회사의 기준에도 가깝지 않으며, 핵심은 언제 쓰고 언제 쓰지 않을지 아는 데 있다"

이 구분이 중요하다. AI 에이전트를 Stack Overflow 강화판으로 쓰는 것은 생산적이다. 하지만 전체 프로젝트의 핵심 로직을 에이전트에게 맡기는 것은 다른 문제다.

---

펩타이드 비유가타타적인 이유

글의 후반부에서 나오는 비유가 인상적이다.

> "AI는 펩타이드이고, 코드베이스는 몸이다. 이 방식이 얼마나 유지보수 가능한지 말 그대로 아무도 모른다. 괜찮을 수도 있고, 완전한 난장판이 될 수도 있다."

회색시장에서 펩타이드를 투여받는 사람들이 있다. 수십 년간 사용되지 않은 물질을, 아무도Long-term 효과를 모르는 채로. 몸에 무슨 일이 일어날지 아무도 모른다.

AI 코딩 에이전트도 비슷하다. 지금 당장은 원하는 결과가 나올 수 있다. 하지만 그 코드베이스가 3년 뒤에도 유지보수 가능한 상태일지, 아니면 이해 불가능한 스파게티로 남을지, 아무도 모른다.

---

##"LeCun/Marcus 논쟁"에 온 입장

글쓸이는 딥러닝의 핵심 인물 중 하나인 Yann LeCun과 Gary Marcus의 논쟁에서후자 입장에 가깝다고 밝혔다.

> "이런 모델은 프로그래밍을 할 수 없고, 과정이 중요하다는 결론으로 이어진다"

이는 현재 LLM의 아키텍처적 한계에 대한 인식이다. 딥러닝이 전체 해법이 아니라는 것이 아니라, 현재 형태의 에이전트 방식에는 한계가 있다는 것이다.

실제 프로그래밍 에이전트에는 무엇이 필요한가. 글은 세계 모델(World Model)을 제시한다.

> "failing test를 주석 처리한 뒤 모든 테스트가 통과한다고 말하는 식의 RLVR이 아니라, 세계 모델이 필요하다"

---

개발자가 취할 수 있는 태도

이 글에서 제시하는 실천적 조언은 다음과 같다.

첫째, 에이전트를만능 도구로 보지 말 것. 에이전트는 초기 뼈대나 검색에는 유용할 수 있지만, 전체 프로젝트의핵심 로직을 맡기기에 현재의 신뢰 수준은 충분하지 않다.

둘째, 코드의 마찰을 소중히 여길 것. 올바른 문제를해쿠 소프트웨어는 식별하기 어렵다. 그 설계를 선택했다는 사실이 시간이 지난 뒤에야 드러나기도 한다. 에이전트가 이 마찰을 덮어버린다면, 우리는 코스트를 뒤로 미루는 것일 뿐이다.

셋째, 언제 에이전트를 쓰지 않을지를 배울 것. 이것이 가장 어렵고 가장 중요한 선택이다.

---

정리

geohot의 글은 "AI 에이전트는 망했다"는 흑백논리가 아니다. 현재 형태의 에이전트 코딩 방식이 가진 구조적 한계를 솔직하게 그린 것이다.

영원한 Sloptember는 끝없는 반복과 형편없는 결과의 악순환이다. 이것을 끊는 방법은 간단하다. 에이전트를 적합한 용도에 적당한 크기로 쓰는 것. 그리고 인간 엔지니어만이 할 수 있는 "올바른 문제를 푸는 것"의 가치를 다시 인정하는 것이다.

---

📚 출처

• geohot.github.io - 영원한 Sloptember

• GeekNews - 영원한 Sloptember

• HN Discussion

---

📚 출처

• https://news.hada.io/topic?id=29879