조지 Хот츠, 코딩 에이전트가 소프트웨어 개발에서 '가장 비용이 많이 드는 실수' 중 하나일 것이라고 말함

조지 호츠(George Hotz)가 지적하는 AI 코딩 에이전트의 근본적 한계는 LLM의 작동 원리 자체에 뿌리를 두고 있다. 현재의 코딩 에이전트는 트랜스포머 기반 LLM이 토큰 단위로 다음 단어를 예측하는 방식으로 코드를 생성하며, 여기에 ReAct(Reasoning + Acting) 패턴이나 도구 호출(tool calling) 능력을 결합해 파일 편집, 명령 실행, 테스트 등을 자동화한다. 문제는 이 모델들이 "그럴듯한 코드"를 생성하는 데 최적화되어 있을 뿐, 실제 시스템의 불변 조건(invariants), 동시성 문제, 메모리 안전성, 엣지 케이스 등 디테일에 대한 깊은 인과 추론은 약하다는 점이다. 호츠는 코마(Comma.ai)에서 자율주행 시스템을 직접 만든 경험을 바탕으로 6개월간 코딩 에이전트를 테스트한 결과, 빠른 프로토타이핑에는 강하지만 점점 더 발견하기 어려운 미묘한 버그를 양산한다고 결론지었다.

이런 한계가 현업 개발자에게 미치는 영향은 양면적이다. 단기적으로는 보일러플레이트 코드 작성, 간단한 CRUD, UI 컴포넌트 스캐폴딩 같은 영역에서 생산성이 크게 오르지만, 중장기적으로는 "겉으로는 동작하지만 잠재적 결함을 안고 있는 코드"가 코드베이스에 누적되는 기술 부채 문제가 심각해진다. 특히 LLM이 만들어낸 코드는 사람이 직접 작성한 코드보다 컨텍스트가 얕고 일관성이 떨어져, 리뷰어가 정신적 모델을 따라가기 어렵다. 호츠의 우려는 단순한 러다이트적 거부가 아니라, 자동 완성을 넘어 "에이전트가 자율적으로 PR을 만들고 머지하는" 워크플로우가 정착될 경우 소프트웨어 산업 전체의 코드 품질이 구조적으로 저하될 수 있다는 경고에 가깝다. 반면 안드레이 카르파시(Andrej Karpathy) 같은 옹호론자들은 "vibe coding"이라는 표현으로 이런 흐름을 긍정적으로 평가하고 있어, AI 커뮤니티 내부의 의견 분열이 점점 깊어지고 있다.

한국 개발자 관점에서 실무적으로 취해야 할 액션은 명확하다. 첫째, 코딩 에이전트를 "주니어 개발자의 초안 작성 도구"로 포지셔닝하고, 절대로 리뷰 없이 머지하지 않는 가드레일을 팀 차원에서 명문화해야 한다. 둘째, 에이전트가 생성한 코드에 대해서는 단위 테스트뿐 아니라 속성 기반 테스트(property-based testing), 퍼징(fuzzing), 정적 분석(예: Semgrep, CodeQL) 등 다층 검증을 강화해 "그럴듯하지만 틀린 코드"를 걸러내는 체계를 갖춰야 한다. 셋째, 개발자 본인의 디버깅·시스템 설계 역량을 의식적으로 단련해야 한다 — 에이전트가 만든 버그는 결국 사람이 잡아야 하며, 호츠의 표현대로 "점점 더 찾기 어려운 버그"를 추적하려면 오히려 더 깊은 펀더멘털이 요구되기 때문이다. 넷째, 보안·인증·결제·데이터 마이그레이션처럼 되돌리기 어려운 영역에서는 에이전트 자율 실행을 제한하고, 사람이 한 줄씩 검토하는 휴먼 인 더 루프(human-in-the-loop)를 유지하는 것이 안전하다.