AI 에이전트 도입은 대형 조직에 더 위험하다: George Hotz (geohot.github.io) ↗

• George Hotz는 AI 에이전트를 소프트웨어 개발에 무분별하게 도입하는 일이 업계의 큰 실수가 될 수 있다고 봄
• 핵심 주장은 “에이전트는 프로그래밍을 하는 게 아니라 프로그래밍처럼 보이는 결과를 흉내 낸다”는 것
• 문제는 결과물이 점점 그럴듯해져서 깨진 부분을 찾기 어려워진다는 점. 문법이 맞고 테스트가 일부 통과해도 품질을 믿기 어려워짐
• AI는 검색, 빠른 프로토타입, 완성도 신경 안 쓰는 일회성 작업에는 매우 유용하지만, 회사의 소프트웨어 엔지니어 기준에는 아직 못 미친다는 주장
• George Hotz는 iPhone 첫 탈옥, comma.ai, tinygrad로 유명한 해커/엔지니어. 이 글은 AI agent 코딩 열풍에 대한 강한 반대 글

왜 에이전트가 코딩을 잘하는 것처럼 보이나?

• Hotz는 처음엔 본인도 “내가 프로그래머라서 방어적으로 보는 건가?”라고 의심했다고 말함
• AI가 어려운 수학 문제는 풀 수 있으니, 프로그래밍도 잘하는데 본인이 못 알아보는 것 아닐까 생각했다는 것
• 그래서 6개월 동안 실제로 써봤다고 함. tinygrad 일부를 에이전트로 만들고, USB와 PCIe 사이를 연결하는 칩 분석에도 사용
• 결론은 매번 비슷했음. 초반 진행은 빠른데, 마지막 완성도에서 계속 막힘
• Hotz의 비유는 slot machine. 처음엔 많이 만든 것처럼 보이지만, 마지막 polish를 위해 레버를 계속 당기게 됨

AI가 유용한데도 엔지니어는 아닌 이유는?

• Hotz는 AI가 쓸모없다고 말하지 않음. 대부분의 검색에는 더 나은 Google이고, 빠른 프로토타입에는 엄청나게 빠르다고 인정
• 다만 “프로토타입”과 “제품 코드”는 다름. 프로토타입은 돌아가는 그림만 보여줘도 되지만, 제품 코드는 유지보수와 디버깅이 가능해야 함
• 문제는 에이전트 결과물이 사람이 만든 코드와 다른 방식으로 깨진다는 점
• 예전에는 문법, 변수명, 테스트 결과 같은 단서로 대략 품질을 짐작할 수 있었음
• AI 결과물은 겉보기 단서가 좋아도 내부 의도나 구조가 비어 있을 수 있음. 사람이 그 위에서 이어서 만들려고 할 때 이상함이 드러남

구분	AI 에이전트가 잘하는 일	위험한 일
검색	빠른 정보 탐색	깊은 판단을 대신 맡기기
프로토타입	대충 돌아가는 첫 버전	오래 유지할 제품 코드
반복 작업	좁은 범위의 자동화	전체 설계와 품질 책임
테스트	단순 케이스 생성	실패 테스트를 없애고 통과했다고 말하는 식의 우회

왜 대형 조직이 더 크게 다칠 수 있나?

• Hotz는 고성과 개인이나 작은 팀보다 대형 조직이 더 위험하다고 봄
• 잘하는 사람들은 에이전트 결과물을 그대로 믿지 않음. 한 줄씩 읽고, 이해하고, 어디서 슬롭이 나왔는지 확인함
• 반대로 큰 조직은 피드백 루프가 느리고, 이해관계도 덜 정렬되어 있음
• 하위 성과자들이 에이전트로 10배 많은 산출물을 내기 시작하면, 조직 전체의 평균 품질이 오히려 떨어질 수 있다는 주장
• 코드, 앱, 기능은 더 많이 나오지만 좋은 제품은 줄어드는 상황. Hotz는 이를 “슬롭은 넘치고, 품질 좋은 보석은 줄어드는 시대”로 봄

진짜 프로그래밍 에이전트에는 무엇이 필요한가?

• Hotz는 이제 LeCun, Marcus 쪽 주장에 가까워졌다고 말함. 현재 LLM 구조만으로는 프로그래밍을 제대로 못 한다는 쪽
• 이유는 과정이 중요하기 때문. 프로그래밍은 단순히 다음 코드를 그럴듯하게 쓰는 일이 아니라, 상태와 의도와 결과를 계속 맞추는 작업
• 그는 진짜 프로그래밍 에이전트에는 world model(세상이 어떻게 움직이는지 내부적으로 예측하는 모델)이 필요하다고 봄
• 지금 방식의 RLVR(검증 가능한 보상으로 모델을 훈련하는 방식)만으로는 부족하다는 비판도 있음
• 실패한 테스트를 주석 처리하고 “이제 테스트 통과”라고 말하는 식의 행동은 진짜 이해가 아니라 결과 맞추기일 뿐이라는 것

AI 에이전트는 정말 프로그래밍을 못 하나?

Hotz의 주장은 “아예 아무 코드도 못 만든다”가 아님. 빠른 프로토타입과 좁은 작업은 매우 잘함. 다만 회사에서 믿고 맡길 소프트웨어 엔지니어 기준에는 아직 못 미치고, 특히 완성도와 유지보수 구간에서 문제가 커진다는 뜻임.

왜 큰 회사가 더 위험한가?

큰 회사는 코드가 들어간 뒤 사용자 피드백까지 시간이 오래 걸림. 또 작성자, 리뷰어, 제품 책임자가 분리되어 있어 품질 책임이 흐려지기 쉬움. 이런 환경에서 에이전트가 만든 그럴듯한 코드는 더 늦게, 더 비싸게 문제를 드러낼 수 있음.

그러면 AI 코딩 도구를 쓰지 말아야 하나?

아님. Hotz도 검색과 빠른 프로토타입에는 매우 유용하다고 봄. 핵심은 언제 쓰고 언제 안 쓸지 아는 것임. 일회성 스크립트나 버리는 실험에는 좋지만, 오래 갈 제품 코드는 사람이 이해하고 책임질 수 있어야 함.

1인기업 관점

이 글은 지금 만들던 AI slop 얘기랑 거의 같은 방향인 듯. 1인기업은 대형 조직보다 피드백이 빠르니 오히려 에이전트를 잘 쓸 수 있지만, 대신 본인이 한 줄씩 이해 못 하는 코드는 바로 부채가 될 가능성이 큼. 프로토타입은 에이전트로 빨리 만들되, 사용자에게 계속 남을 핵심 코드는 직접 읽고 줄이는 루틴이 필요할 듯. 기능 10개 더 만드는 것보다 슬롭인지 아닌지 알아보는 눈이 더 중요해지는 느낌임.

---

관련: George Hotz의 이전 글 모델 경쟁 다음은 앱과 취향: George Hotz와 더 빨리 만들수록 검증은 줄고 기능만 늘어난다도 같이 보면 좋습니다.