Vibe Coding에 대한 논쟁이 다시 불붙고 있다. Brad Traversy는 최근 자신의 글에서 "모델이 좋아진 건 맞다. 그런데 모델이 좋아졌다고 판단의 필요성이 사라지진 않는다"고 선을 그었다. AI 코딩 도구에 대한 낙관론이 퍼지는 시점에, 실제 프로덕션에서 무엇이 깨지고 있는지를 살펴볼 필요가 있다.
문제는 모델 품질이 아니다
Claude Opus, GPT-5.5 같은 최신 모델은 실제로 이전 세대보다 훨씬 낫다. 첫 시도 성공률이 올라갔고, 환각도 줄었다. 그러나 dev.to에 공개된 'AI Agents in Practice' 시리즈가 분석한 TechNova 사례는 다른 이야기를 한다. 고객 지원 에이전트는 데모에서 완벽하게 작동했다. 화요일에 배포됐고, 금요일에 이미 출고된 상품에 환불을 23건 처리했다. 모델은 저하되지 않았다. 코드도 깨지지 않았다. 에이전트는 데모에서 했던 것과 똑같이 행동했다—자신 있게, 유창하게, 그리고 틀리게.
프로덕션에서 깨지는 첫 번째 이유: 에이전트는 시스템 상태를 모른다
데모의 주문은 항상 취소 가능한 상태였다. 프로덕션의 주문은 pending → confirmed → picked → packed → shipped → delivered를 거친다. 에이전트의 cancel_order 툴은 shipped 상태의 주문에도 기꺼이 호출된다. API가 성공을 반환하든 부분 성공을 반환하든, 에이전트는 구별하지 못한다. 에이전트는 주문의 실제 상태를 읽고 허용 여부를 판단하는 게 아니라, 사용자의 요청을 읽고 관련 있어 보이는 툴을 고른다. 이 둘은 전혀 다른 행동이다.
두 번째 이유: 에이전트는 언제 멈춰야 할지 모른다
cancel_order가 성공을 반환했다면 취소가 실제로 된 건가? issue_refund가 성공을 반환했다면 돈이 실제로 이동한 건가? 데모에서는 엔지니어가 채팅창을 닫아서 에이전트를 멈췄다. 프로덕션에는 엔지니어가 없다. 에이전트 스스로 완료 여부를 판단한다. 그 판단의 결과가 '정상 완료', '오류 완료', '부분 완료 후 추가 툴 호출 시도', '포기 후 사과 메시지' 중 어느 것인지—외부에서는 모두 동일하게 보인다. 모두 "완료됐습니다" 메시지로 끝난다.
세 번째 이유: 에이전트에게는 '하지 말아야 한다'는 경로가 없다
에이전트에게 주어진 툴은 취소와 환불뿐이었다. '이 케이스는 처리하면 안 된다'는 툴은 없었다. 에스컬레이션 경로도 없었다. 요청이 취소처럼 보이면 에이전트의 선택지는 취소, 환불, 또는 둘 다다. '사람에게 넘기기' 버튼도, '내 범위 밖이다'라는 경로도 설계되지 않았다. 에이전트의 가능한 결과는 주어진 툴의 집합이고, 그 툴들은 에이전트가 항상 올바른 판단을 내린다는 전제 위에 설계됐다.
시스템 프롬프트에 모든 걸 쑤셔 넣는 함정
세 가지 문제를 발견하면 흔히 드는 반응이 있다. "그냥 에이전트한테 알려주면 되지 않나?" 실제로 많은 팀이 시스템 프롬프트에 규칙을 계속 추가한다. 'shipped 주문은 취소하지 마라', '환불 전 상태 확인 먼저', '$100 이상은 에스컬레이션'... 일주일 지나면 시스템 프롬프트는 서로 모순되는 영어 규칙들의 집합이 된다. 이 구조의 근본 문제는 규칙이 자연어로 인코딩됐다는 점이다. 코드가 아니다. 파싱되지 않는다. 강제되지 않는다. 에이전트는 규칙을 이해한 게 아니라 읽은 것이다.
에이전트의 자기 보고는 출발점일 뿐이다
'The Agent's Word Is Not Enough' 시리즈(EthereaLogic.ai)는 거버넌스의 세 번째 레이어—외부 검증—를 다루며 이 문제를 다른 각도에서 보여준다. 2026년 4월 20일, GovForge 프로젝트의 AI 에이전트는 1,361개의 테스트가 모두 통과했다고 보고했다. 같은 시점 CI는 1,152개를 보고했다. 에이전트가 거짓말한 게 아니다. 둘 다 옳다. 에이전트는 로컬 환경에서, CI는 클린 러너에서 각각 다른 환경 변수로 실행됐다. 핵심은 이것이다: 에이전트의 자기 보고는 시작점이지 결론이 아니다. CI가 클린 환경에서, 에이전트가 설정하지 않은 툴로, 에이전트가 덮어쓸 수 없는 리포트를 생성할 때 비로소 신뢰할 수 있는 검증이 된다.
지금 팀에 필요한 판단 기준
세 기사가 공통으로 가리키는 방향이 있다. Vibe Coding이 프로덕션에서 깨지는 건 모델의 실력 문제가 아니다. 에이전트가 시스템 상태를 알 수 없고, 멈춰야 할 시점을 판단할 수 없고, 그 자기 보고를 신뢰할 구조가 없는 것이 문제다. Brad Traversy의 표현을 빌리면, "AI가 타이핑을 담당한다. 생각은 여전히 네가 담당해야 한다." 이건 초보자 교육 조언이 아니다. 시스템 설계 원칙이다. 에이전트에게 툴을 줄 때, 그 에이전트가 '하지 말아야 한다'는 경로를 가지고 있는지, 비가역적 액션 전에 상태를 검증하는지, 외부 CI가 에이전트의 주장을 독립적으로 검증하는지—이 세 질문이 없으면 데모는 성공하고 프로덕션은 조용히 깨진다.
전망: AI-First 워크플로우의 다음 과제
모델이 계속 좋아질수록 역설적으로 이 문제는 더 커진다. 에이전트가 더 유창하게 '완료됐습니다'를 말할수록, 그 주장을 의심할 구조적 장치가 없으면 피해는 더 빠르게 쌓인다. 다음 단계는 에이전트의 능력을 높이는 것이 아니라, 에이전트가 틀렸을 때 그것을 잡아낼 레이어를 설계하는 것이다. 상태 검증 로직, 에스컬레이션 경로, 외부 CI 검증—이 세 레이어를 프로덕션 전에 설계하지 않으면, 빠른 에이전트는 그냥 빠른 실수 기계다.