에이전트가 실패한 테스트를 주석 처리한 뒤 “모든 테스트가 통과했습니다”라고 보고합니다. 농담 같지만, 해커이자 개발자인 George Hotz가 6개월간 AI 코딩 에이전트를 직접 써보고 내린 결론입니다. 그리고 비슷한 시기, 학술 연구가 이 직관을 데이터로 뒷받침했습니다.

Hotz는 자신의 블로그에 “The Eternal Sloptember”를 발표하며 코딩 에이전트 도입이 소프트웨어 개발 역사에서 가장 값비싼 실수 중 하나가 될 것이라고 주장했습니다. 같은 시기 EURECOM 연구팀은 논문 “Constraint Decay”를 통해 LLM 에이전트가 구조적 요구사항이 쌓일수록 성능이 급격히 떨어진다는 사실을 100개 태스크 실험으로 입증했습니다.

출처: The Eternal Sloptember – George Hotz

• Constraint Decay: The Fragility of LLM Agents in Backend Code Generation – EURECOM / University of Basilicata

슬롯머신 레버를 당기는 개발자

Hotz는 6개월간 tinygrad 일부를 에이전트로 작성하고, USB-PCIe 칩 펌웨어를 에이전트와 함께 리버스 엔지니어링했습니다. 그가 관찰한 패턴은 일정했습니다.

에이전트는 초반에 빠르게 진척을 만들어냅니다. 뼈대가 세워지고, 기능의 윤곽이 잡힙니다. 그런데 마지막 다듬기 단계에 이르면 슬롯머신 레버를 당기는 것처럼 됩니다. 될 수도 있고 안 될 수도 있고, 반복해봐야 알 수 있습니다. 결국 “내가 직접 했으면 더 빠르고 낫게 했을 것”이라는 의심이 매번 들었다고 합니다.

그가 말하는 핵심 문제는 탐지 난이도입니다. LLM이 만들어내는 코드는 문법도 맞고 구조도 그럴싸해 보입니다. 하지만 실제로 빌드하고 실행하고 인간의 방식으로 상호작용해보면, 통계적으로는 미묘한 차이가 현실에서 명확한 결함으로 드러납니다. 예전에는 품질의 신호였던 문법이나 코드 스타일 같은 지표가 이제는 아무 의미가 없다는 게 그의 결론입니다.

제약이 쌓이면 성능이 무너진다

Constraint Decay 논문은 이 직관을 실험으로 확인했습니다.

연구팀은 8개 웹 프레임워크에 걸쳐 80개의 신규 생성 태스크와 20개의 기능 구현 태스크를 준비했습니다. 모든 태스크에 동일한 API 명세를 제공하고, 제약을 하나씩 추가해가며 성능을 측정했습니다. 제약의 종류는 네 가지, 프레임워크 선택, 아키텍처 패턴, 데이터베이스, ORM 통합입니다.

수치는 뚜렷했습니다. 제약이 없을 때는 잘 동작하던 에이전트가 구조적 요구사항이 쌓일수록 성능이 가파르게 떨어졌습니다. 상위권 에이전트도 평균 30포인트의 통과율 하락을 보였고, 하위권 에이전트는 사실상 0에 수렴했습니다.

어디서 가장 많이 실패했을까요? 약 45%의 실패가 데이터 레이어에서 나왔습니다. 쿼리 구성 오류와 ORM 런타임 위반이 주요 원인입니다. 또 흥미로운 점은 프레임워크 민감도입니다. Flask처럼 규칙이 명시적이고 단순한 환경에서는 상대적으로 잘 동작했지만, FastAPI나 Django처럼 규약이 복잡하고 암묵적인 환경에서는 성능이 크게 떨어졌습니다.

대형 조직이 더 위험한 이유

Hotz는 한 가지 역설적인 관찰을 덧붙입니다. 에이전트의 피해는 실력 좋은 개발자보다 큰 조직에 더 크게 돌아간다는 것입니다.

뛰어난 개발자는 슬롭이 슬롭임을 알아봅니다. 에이전트 출력을 한 줄씩 읽고 검증하는 습관이 있고, 언제 믿고 언제 의심해야 하는지를 압니다. 반면 대형 조직의 하위 성과자들은 그 자기 검증 능력이 없는 채로 에이전트로 10배의 산출물을 만들어냅니다. 코드베이스의 평균 품질은 떨어지지만 양은 폭발적으로 늘고, 문제는 점점 더 깊숙이 쌓입니다.

Karpathy도 비슷한 우려를 인정했습니다. AI 에이전트의 생산성 향상을 긍정적으로 평가하면서도, 에이전트가 만들어낸 코드를 직접 보면 “심장이 살짝 내려앉는다”고 표현했습니다. 비대하고, 복사-붙여넣기가 많고, 어색한 추상화가 가득하다는 것입니다.

프로토타입과 프로덕션 사이

두 자료가 공통으로 말하는 것은 에이전트가 쓸모없다는 이야기가 아닙니다. 오히려 어디에 쓸모 있고 어디에 없는지가 생각보다 훨씬 명확하다는 것입니다.

빠른 프로토타입, 완성도보다 속도가 중요한 작업, 제약이 느슨한 초기 구조 설계 등에서는 에이전트가 실질적으로 빠릅니다. 그러나 구조적 요구사항이 정해진 프로덕션 백엔드, 기존 코드베이스와의 통합, 세부 완성도가 요구되는 마무리 작업에서는 인간의 검증이 여전히 핵심입니다.

Constraint Decay 논문은 이 경계선을 수치로 보여줬습니다. 그리고 Hotz는 그 경계선 안팎을 직접 살아본 경험으로 증언합니다.

참고자료: George Hotz says coding agents will be “one of the most costly mistakes” in software development – The Decoder