조지 호츠의 경고: AI 에이전트는 아직 프로그래머가 아니다

• 조지 호츠는 AI 에이전트의 소프트웨어 개발 도입을 업계 역사상 가장 비싼 실수 중 하나로 보고 있음

  • 그의 주장은 꽤 세다. “에이전트는 프로그래밍을 못 한다”는 쪽임
  • 더 정확히는, 프로그래밍 분포를 흉내 내는 고도화된 통계 모델이라서 출력은 점점 그럴듯해지지만, 깨진 부분은 점점 더 찾기 어려워진다는 얘기임

• 본인도 처음부터 반AI 입장이었던 건 아니라고 함

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

• 실제 사용 경험은 냉정했음. 초반은 빠른데, 끝마무리가 슬롯머신 같다는 평가임

  • tinygrad 일부를 에이전트로 작성했고, USB-PCIe 칩 리버싱에도 써봤다고 함
  • 하지만 매번 “그냥 내가 직접 했으면 더 낫고 빨랐겠다”는 느낌이 남았다고 함
  • 에이전트는 초반 진척을 앞당겨주지만, 마지막 polish 단계에서 레버를 당기며 운 좋게 맞기를 바라는 구조가 된다는 표현이 핵심임

• 그는 “너가 잘못 쓰고 있는 것”이라는 반박도 미리 차단함

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

• 흥미로운 지점은 “개발자 지위 불안” 프레임을 거부한다는 점임

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

• 큰 조직일수록 더 크게 다칠 수 있다는 분석도 나옴

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

• 그는 앞으로 “코드, 앱, 기능”의 양은 폭증하겠지만 품질은 암흑기가 될 수 있다고 봄

  • 표현이 거칠지만 메시지는 명확함. 버킷째 쏟아지는 AI 산출물의 시대가 온다는 것
  • 애플이 엔지니어들에게 AI 사용을 밀고 있다는 얘기를 예로 들며, 추상론 말고 “2년 뒤 macOS가 더 좋아질까 나빠질까?”라고 묻는 부분이 꽤 날카로움

• 더 무서운 건 기존 품질 신호가 무력해진다는 점임

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

• 결론적으로 그는 LeCun과 Marcus 쪽 관점에 가까워졌다고 함

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

---

기술 맥락

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

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

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

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