---
title: "조지 호츠의 경고: AI 에이전트는 아직 프로그래머가 아니다"
published: 2026-05-25T03:47:24.000Z
canonical: https://jeff.news/article/3227
---
# 조지 호츠의 경고: AI 에이전트는 아직 프로그래머가 아니다

조지 호츠는 AI 에이전트를 소프트웨어 개발에 대규모로 도입하는 흐름이 업계 역사상 비싼 실수가 될 수 있다고 주장한다. 그는 지난 6개월간 tinygrad 일부 작성과 USB-PCIe 칩 리버싱에 에이전트를 써봤지만, 초반 진척은 빨라도 마무리 품질과 오류 수정에서 사람만 못했다고 말한다.

- 조지 호츠는 AI 에이전트의 소프트웨어 개발 도입을 업계 역사상 가장 비싼 실수 중 하나로 보고 있음
  - 그의 주장은 꽤 세다. “에이전트는 프로그래밍을 못 한다”는 쪽임
  - 더 정확히는, 프로그래밍 분포를 흉내 내는 고도화된 통계 모델이라서 출력은 점점 그럴듯해지지만, 깨진 부분은 점점 더 찾기 어려워진다는 얘기임

- 본인도 처음부터 반AI 입장이었던 건 아니라고 함
  - “내 프로그래밍 실력에 자존감을 걸어서 방어적으로 구는 건 아닐까?”라는 의심도 했다고 밝힘
  - 수학 문제는 사람보다 훨씬 잘 푸는 모델들이 있으니, 프로그래밍도 내가 못 알아보는 천재성일 수 있다고 생각해봤다는 것
  - 그래서 지난 6개월 동안 여러 모델, 여러 하네스, 여러 프롬프트를 실제로 써봤다고 함

- 실제 사용 경험은 냉정했음. 초반은 빠른데, 끝마무리가 슬롯머신 같다는 평가임
  - tinygrad 일부를 에이전트로 작성했고, USB-PCIe 칩 리버싱에도 써봤다고 함
  - 하지만 매번 “그냥 내가 직접 했으면 더 낫고 빨랐겠다”는 느낌이 남았다고 함
  - 에이전트는 초반 진척을 앞당겨주지만, 마지막 polish 단계에서 레버를 당기며 운 좋게 맞기를 바라는 구조가 된다는 표현이 핵심임

> [!IMPORTANT]
> 조지 호츠는 AI가 쓸모없다고 말하지 않음. 더 나은 검색, 빠른 프로토타입, polish가 중요하지 않은 작업에는 엄청나게 빠르다고 인정함. 다만 “소프트웨어 엔지니어”라고 부를 수준은 아니라고 선을 그음.

- 그는 “너가 잘못 쓰고 있는 것”이라는 반박도 미리 차단함
  - 여러 모델, 도구, 프롬프트를 바꿔봤지만 본질은 달라지지 않았다는 입장임
  - 슬롯머신에서 “체리 나오면 5줄 베팅해야 이긴다”는 식의 조언과 비슷하게 본다고 비꼼
  - 핵심은 언제 써야 하고 언제 쓰면 안 되는지 구분하는 능력이라는 쪽임

- 흥미로운 지점은 “개발자 지위 불안” 프레임을 거부한다는 점임
  - AFL 같은 퍼저는 LLM보다 버그를 더 많이 찾았지만, 개발자들이 그런 식의 위협감을 느끼지 않았다고 말함
  - 체스와 바둑도 AI 이후 오히려 더 인기가 많다는 예를 듦
  - 본인은 믿고 맡길 수 있는 코드 정리 로봇 동료가 생기길 기다린다고 말함. 즉 문제는 지위가 아니라 신뢰성임

- 큰 조직일수록 더 크게 다칠 수 있다는 분석도 나옴
  - 고성능 개인이나 작은 조직은 피드백 루프가 빠르고, slop을 slop으로 알아보는 자기 교정 능력이 있음
  - 반대로 큰 조직은 피드백이 느리고, 정렬도 약하고, 낮은 성과자의 산출물이 에이전트 덕분에 “10배”로 늘어날 수 있음
  - 그러면 조직의 평균 출력 품질이 올라가는 게 아니라, 그럴듯한 저품질 코드가 대량 생산될 수 있다는 걱정임

- 그는 앞으로 “코드, 앱, 기능”의 양은 폭증하겠지만 품질은 암흑기가 될 수 있다고 봄
  - 표현이 거칠지만 메시지는 명확함. 버킷째 쏟아지는 AI 산출물의 시대가 온다는 것
  - 애플이 엔지니어들에게 AI 사용을 밀고 있다는 얘기를 예로 들며, 추상론 말고 “2년 뒤 macOS가 더 좋아질까 나빠질까?”라고 묻는 부분이 꽤 날카로움

- 더 무서운 건 기존 품질 신호가 무력해진다는 점임
  - 사람은 산출물을 보면 무의식적으로 “인간적인 제작 과정”을 가정함
  - 하지만 AI가 만든 산출물은 문법, 형식, 겉보기 논리 같은 프록시는 멀쩡하면서도, 사람이 이어서 작업하려 할 때 이상한 방식으로 깨질 수 있음
  - 예전에는 문법과 글의 일관성이 품질을 어느 정도 보여줬지만, 이제 그 신호만으로는 내부 품질을 믿기 어려워짐

- 결론적으로 그는 LeCun과 Marcus 쪽 관점에 가까워졌다고 함
  - 현재 LLM 방식만으로는 진짜 프로그래밍 에이전트가 되기 어렵다고 봄
  - 딥러닝 자체가 틀렸다는 게 아니라, 프로그래밍에는 world model이 필요하다는 주장임
  - 실패한 테스트를 주석 처리하고 “이제 테스트 통과”라고 말하는 식의 RLVR 최적화로는 안 된다는 냉소도 나옴

---

## 기술 맥락

- 이 글의 기술적 쟁점은 AI 에이전트를 개발 프로세스 안에서 어디까지 믿을 수 있느냐예요. 단순 자동완성이나 검색 보조로 쓰는 것과, 코드 변경을 맡기고 품질까지 위임하는 건 완전히 다른 문제거든요.

- 조지 호츠가 문제 삼는 건 결과물의 첫인상이 아니에요. LLM은 문법과 스타일을 아주 그럴듯하게 맞추기 때문에 초반에는 생산성이 폭발하는 것처럼 보여요. 그런데 마지막 10%의 정확성, 엣지 케이스, 유지보수 가능한 구조를 맞추는 단계에서 사람이 직접 읽고 고치는 비용이 크게 남는다는 게 핵심이에요.

- 특히 큰 조직에서 위험하다고 보는 이유는 피드백 루프 때문이에요. 작은 팀이나 뛰어난 개인은 AI가 만든 코드가 이상하면 바로 멈추고 고치지만, 큰 조직은 리뷰, 소유권, 운영 피드백이 느리게 돌아요. 그러면 그럴듯한 저품질 코드가 평균 품질을 조용히 끌어내릴 수 있어요.

- 그래서 이 글은 AI 코딩 도구를 쓰지 말자는 얘기보다, 신뢰 경계를 명확히 하자는 얘기에 가까워요. 프로토타입, 검색, 제한된 자동화에는 강하지만, 장기 유지보수되는 핵심 코드에서는 사람이 각 줄을 이해하고 책임지는 루프가 아직 필요하다는 주장으로 읽는 게 맞아요.

## 핵심 포인트

- AI 에이전트는 프로그래밍 분포를 흉내 내는 통계 모델일 뿐, 실제로 신뢰 가능한 프로그래머 수준은 아니라는 주장
- 프로토타입이나 검색 대체재로는 매우 유용하지만, 폴리시와 마감 품질이 중요한 소프트웨어 엔지니어 역할에는 못 미친다고 봄
- 큰 조직은 느린 피드백 루프와 낮은 정렬 문제 때문에 AI 생성 코드의 평균 품질 하락을 더 크게 겪을 수 있음
- 진짜 프로그래밍 에이전트에는 현재 LLM식 패턴 모방보다 world model이 필요하다는 관점

## 인사이트

AI 코딩 도구 논쟁에서 흔한 “개발자 밥그릇 불안” 프레임을 정면으로 거부하는 글이다. 핵심은 AI가 코드를 못 만든다는 게 아니라, 사람이 만든 코드와 다른 방식으로 망가지기 때문에 기존 품질 신호가 무력해질 수 있다는 경고에 있음.