AI 코딩 에이전트 한계 2026 George Hotz slop 리스크 리뷰 기준

2026년 5월 24일 George Hotz는 “The Eternal Sloptember”라는 글에서 AI 에이전트의 소프트웨어 개발 도입이 업계의 비싼 실수가 될 수 있다고 주장했다. 핵심은 AI가 아예 쓸모없다는 말이 아니라, 빠른 앞단 진척이 마지막 polish와 품질 검증 비용을 숨긴다는 비판이다.

AI 코딩 에이전트를 쓰면 처음 80%는 정말 빨라 보인다. 파일을 찾고, 패치를 만들고, 테스트 명령을 제안하고, 문서까지 정리한다. 문제는 마지막 20%다. 이상한 edge case, 기존 코드 스타일, 보이지 않는 부작용, 실패한 테스트, 미묘한 책임 경계가 남는다. 이 구간에서 사람이 읽지 않으면 산출물은 기능이 아니라 slop이 될 수 있다.

내 블로그 파이프라인도 작은 버전의 같은 문제를 매일 보여준다. AI가 초안은 빠르게 만든다. 하지만 frontmatter, FAQ, 출처, 관련 글 URL, 중복 발행 가드, Rank Math 메타, 공개 URL 200 확인은 따로 봐야 한다. 초안은 빠르지만 발행은 검증 루프가 끝나야 닫힌다. 코드도 똑같다. “거의 됐다”는 말은 소프트웨어에서 제일 비싼 향수다. 냄새는 좋은데 잔금이 세다.

AI 코딩 에이전트는 빠른 프로토타입과 제한된 자동화에는 강하다. 하지만 팀 코드베이스에 넣을 때는 산출량보다 diff 이해, 테스트 실패 설명, rollback 가능성, 리뷰 책임자를 먼저 봐야 한다.

지금 결론

George Hotz의 글은 강한 의견문이다. 실증 벤치마크나 논문이 아니라, tinygrad 일부 코드 작성과 USB-PCIe 칩 리버싱을 AI 에이전트로 시도한 경험, 주변 개발자와 조직 관찰을 바탕으로 쓴 주장이다. 그래서 그대로 신앙처럼 받아들이면 곤란하다. 하지만 팀 운영 기준으로 번역하면 꽤 쓸모 있는 경고가 된다.

Hotz가 인정하는 유용한 구간도 있다. 검색 대체, 빠른 프로토타입, polish가 중요하지 않은 작업에서는 AI가 빠르다고 말한다. 문제는 이 유용함을 “소프트웨어 엔지니어 대체”로 확대하는 순간이다. 특히 대기업처럼 feedback loop가 느리고, 산출물 검수 능력이 사람마다 크게 다른 조직에서는 평균 코드 품질이 흔들릴 수 있다.

TECHTAEK식 결론은 이렇다. AI 코딩 에이전트를 끄자는 게 아니다. 역할을 좁히고, 리뷰 게이트를 분명히 하고, 팀의 검증 능력보다 큰 권한을 주지 말자는 것이다. AI는 속도 가속기다. 그런데 브레이크 없는 가속기는 교통수단이 아니라 사고 예고편이다.

Hotz가 말한 slop 리스크

Hotz의 핵심 비판은 AI 에이전트가 프로그래밍의 통계적 분포를 흉내 내는 모델이며, 출력이 점점 더 알아채기 어려운 방식으로 망가진다는 점이다. 이 표현은 거칠지만 중요한 질문을 남긴다. 사람이 보기에는 그럴듯한 코드가 실제로는 잘못된 추론, 숨은 부작용, 테스트 우회, edge case 누락을 품고 있을 수 있다.

그가 말한 “frontloads all the progress”도 실무에서 자주 보인다. AI는 초반 진척을 빠르게 만든다. 빈 파일이 생기고, 함수가 채워지고, README가 업데이트되고, 테스트 이름도 생긴다. 그래서 사람은 “거의 다 됐다”고 느낀다. 하지만 마지막 polish는 단순한 마감 장식이 아니다. 실제 사용자가 밟을 예외, 운영자가 볼 로그, 다음 개발자가 이해할 diff가 이 구간에 있다.

slop의 무서운 점은 문법이 틀린 코드가 아니라는 점이다. 오히려 문법은 맞고, 이름도 괜찮고, 구조도 그럴듯하다. 그래서 리뷰어가 피곤한 날에는 지나갈 수 있다. 예전에는 이상한 코드가 딱 봐도 이상했지만, 이제는 이상한 코드가 면접 복장까지 갖춰 입고 온다. 겉은 단정한데, 속으로는 회의실 예약을 다 꼬아놓는 타입이다.

개인 고성과자와 큰 조직의 차이

Hotz는 고성과자들이 AI 산출물을 slop으로 알아보고 직접 보정할 수 있다고 본다. 이 사람들은 AI가 만든 코드를 한 줄씩 읽고, 언제 믿고 언제 버릴지 조정한다. 즉 AI가 빠른 초안 도구가 되더라도 최종 품질 책임은 여전히 사람이 잡고 있다.

문제는 큰 조직이다. feedback loop가 느리고, 사람마다 검증 능력 차이가 크고, 산출량을 성과처럼 보기 쉽다. 누군가는 AI로 10배 산출물을 낸다. 그런데 그 10배가 10배 가치인지, 10배 검수 부채인지 확인하는 시스템이 없다면 평균 품질은 내려갈 수 있다.

이건 꽤 현실적인 걱정이다. AI 도입 초기에 조직은 “얼마나 많이 만들었는가”를 보기 쉽다. PR 수, 기능 수, 자동화 건수, 문서 수가 늘어난다. 하지만 더 중요한 지표는 “얼마나 덜 깨졌는가”, “리뷰 시간이 얼마나 늘었는가”, “운영 장애가 줄었는가”, “다음 사람이 코드를 이해하는가”다.

조직 상황	AI가 잘 맞는 구간	위험한 구간
개인 고성과자	빠른 탐색, 초안, 테스트 아이디어	검수 없이 merge
작은 팀	프로토타입, 내부 도구, migration script 초안	ownership 불명확한 자동 PR
대기업	반복 작업 보조, 문서 검색, 제한된 codegen	산출량 KPI 중심 대량 코드 생성
레거시 조직	test 추가, 영향 범위 탐색	큰 리팩터링 자동화
신입 온보딩	설명, 예제, 작은 task 분해	모르는 코드를 AI가 대신 완성

팀 리뷰 기준은 이렇게 바꿔야 한다

AI 코딩 에이전트를 팀에 넣는다면 리뷰 기준을 바꿔야 한다. 첫 번째 기준은 diff 이해다. PR 작성자는 AI가 만든 코드라도 본인이 모든 변경을 설명할 수 있어야 한다. “AI가 이렇게 했습니다”는 리뷰 답변이 아니다. 그건 범인 진술도 아니고 알리바이도 아니다.

두 번째 기준은 실패 케이스 설명이다. 어떤 테스트가 있었고, 어떤 edge case를 확인했고, 어떤 부분은 아직 사람이 봐야 하는지 명시해야 한다. 성공한 테스트 목록만으로는 부족하다. 실패했거나 확인하지 못한 영역이 더 중요하다.

세 번째 기준은 변경 범위 제한이다. AI는 가끔 친절하게 주변 파일까지 고친다. 이 친절은 위험하다. 요청한 문제와 직접 관련 없는 리팩터링, 이름 변경, 스타일 변경, 구조 변경은 별도 PR로 분리해야 한다.

네 번째 기준은 rollback 가능성이다. 특히 DB migration, auth, billing, infra, data pipeline은 되돌릴 방법 없이 AI 산출물을 넣으면 안 된다. 빠른 변경보다 빠른 복구가 더 중요하다.

다섯 번째 기준은 reviewer load다. AI로 PR 수가 늘었는데 리뷰 인력과 기준이 그대로라면 병목은 옮겨간 것뿐이다. 코딩 시간이 줄어도 리뷰 시간이 폭증하면 팀 전체 생산성은 좋아지지 않는다.

AI를 써도 좋은 작업과 조심할 작업

AI 코딩 에이전트가 잘 맞는 작업은 있다. 새 API 사용법을 탐색하거나, boilerplate를 만들거나, 테스트 케이스 초안을 뽑거나, 작은 내부 도구의 첫 버전을 만드는 일은 효과가 좋다. 문서 검색과 예제 생성도 강하다.

조심할 작업은 품질 책임이 큰 작업이다. 결제, 인증, 권한, 데이터 마이그레이션, 운영 장애 복구, 복잡한 레거시 리팩터링은 검증 비용이 크다. 여기서는 AI가 도와도 사람의 설계와 리뷰가 중심이어야 한다.

특히 레거시 코드에서는 “작동하는 이유를 아무도 모르는 코드”가 많다. AI는 이런 코드를 보고도 자신 있게 수정할 수 있다. 자신감은 좋지만, 레거시에서는 겸손이 더 비싸다. AI가 제안한 수정이 맞아 보여도 기존 테스트, git log, 장애 기록, 운영자 기억을 같이 봐야 한다.

작업 유형	추천 사용법	리뷰 강도
문서 검색	공식 문서 요약과 예제 찾기	낮음
프로토타입	버릴 수 있는 첫 버전 만들기	중간
테스트 초안	edge case 후보 생성	중간
버그 수정	재현, 원인 후보, 작은 patch	높음
레거시 리팩터링	영향 범위 분석 보조	매우 높음
결제/권한/데이터	설계 리뷰와 체크리스트 보조	최고

도입 전 체크리스트

첫째, AI PR에는 작성자 책임을 명시한다. “AI-assisted”라고 표시할 수는 있지만, 책임은 사람에게 있어야 한다. AI가 만든 코드를 사람이 이해하지 못하면 merge하지 않는다.

둘째, PR 템플릿에 AI 사용 섹션을 추가한다. 어떤 도구를 썼는지, 어떤 파일을 AI가 수정했는지, 사람이 어떤 부분을 직접 검토했는지, 테스트와 미검증 영역은 무엇인지 적는다.

셋째, 위험 영역을 정한다. auth, payment, migration, infra, privacy, compliance, production script는 AI 자동 수정 제한 영역으로 두는 편이 안전하다. 여기서는 AI가 초안을 내도 사람 설계 리뷰가 먼저다.

넷째, 리뷰 시간을 측정한다. AI 도입 후 PR 수가 늘었는지보다 리뷰 시간이 늘었는지, revert가 늘었는지, 장애가 늘었는지 봐야 한다. 생산성은 산출량이 아니라 유지 가능한 변경량이다.

다섯째, 작은 성공 루프부터 만든다. 내부 도구, 테스트 생성, 문서 업데이트, low-risk refactor처럼 실패 비용이 낮은 곳에서 시작한다. 성공하면 범위를 늘리고, 실패하면 룰을 강화한다. AI 도입은 용기가 아니라 계단이다.

FAQ

Q. George Hotz 말처럼 AI 코딩 에이전트는 쓰면 안 되나?

그렇게 단순하게 읽으면 안 된다. Hotz도 검색, 빠른 프로토타입, polish가 중요하지 않은 작업에서는 AI가 유용하다고 인정한다. 핵심은 “언제 쓰고 언제 믿지 않을지”를 구분하는 것이다.

Q. slop은 정확히 무엇을 뜻하나?

여기서는 겉으로 그럴듯하지만 품질이 낮고, 유지보수나 확장 과정에서 문제를 일으키는 AI 산출물을 뜻한다. 문법은 맞고 테스트 일부도 통과할 수 있지만, 사람이 이해하고 책임지기 어려운 코드가 대표적이다.

Q. AI가 만든 PR을 어떻게 리뷰해야 하나?

작성자가 diff를 설명할 수 있어야 하고, 테스트 통과뿐 아니라 미검증 영역과 실패 케이스를 적어야 한다. 변경 범위가 요청보다 넓으면 분리하고, 위험 영역은 설계 리뷰부터 진행하는 편이 안전하다.

Q. 팀에서 AI 사용을 금지하는 게 더 안전한가?

대부분의 팀에서는 금지보다 게이트가 낫다. AI를 막으면 비공식 사용이 생길 수 있고, 좋은 활용까지 놓친다. 대신 위험 영역, PR 템플릿, 리뷰 기준, rollback 규칙을 명확히 두는 편이 현실적이다.

Q. AI 코딩 에이전트 도입 성과는 무엇으로 봐야 하나?

PR 수보다 cycle time, review time, revert rate, 장애 건수, 테스트 커버리지, 코드 이해 가능성을 봐야 한다. 산출량만 보면 slop도 성과처럼 보인다.

AI 코딩 에이전트 한계 2026 – George Hotz의 slop 리스크와 팀 리뷰 기준