AI 에이전트가 프로덕션에서 망하는 이유, 모델 문제가 아니었다

AI 에이전트를 처음 프로덕션에 올렸을 때, 나는 모델만 좋으면 다 된다고 생각했다. 어차피 추론 능력이 전부 아닌가. 그런데 실제로 운영을 시작하자마자 터진 문제들은 전혀 다른 곳에서 왔다. 루프를 도는 에이전트, 엉뚱한 파라미터로 툴을 부르는 에이전트, 컨텍스트가 가득 찬 채로 처음 한 일을 까먹는 에이전트. 모델 품질 문제가 아니었다. 인프라 문제였다.

올해 클라이언트 23건의 에이전트 장애를 분석한 결과, 4가지 패턴이 전체의 90%를 차지했다. 흥미로운 건, 이 4가지 모두 모델을 교체한다고 해결되는 게 아니라는 점이다.

패턴 1: 툴 콜 실패 — 스키마가 헐렁하면 모델이 알아서 망친다

툴을 정의할 때 JSON 스키마를 대충 적으면 어떻게 되는지 직접 겪었다. 필터 파라미터를 그냥 object로 열어두면 모델이 {"status": "Active"}(대소문자 오류), {"created_before": "yesterday"}(날짜 형식 오류) 같은 걸 태연하게 넣는다. 전부 유효한 JSON이고, 전부 잘못된 값이다.

헐렁한 스키마 vs 타이트한 스키마

해결책은 단순하다. enum, format, minimum, maximum으로 모델이 임의로 만들 수 없게 막으면 된다. status_filter를 enum: ["active", "inactive", "pending", "all"]로 정의하면 모델은 저 네 가지 중에서만 고른다.

실측 데이터가 있다. 동일한 프로덕션 데이터 조회 에이전트에서, 스키마를 타이트하게 바꾸기 전에는 툴 콜의 14%가 유효성 검사에서 실패했다. 바꾼 뒤에는 2.1%로 떨어졌다. 설명(description)만 추가하는 건 효과가 없었다. 기계가 읽을 수 있는 제약 조건이어야 했다.

패턴 2: 무한 루프 — 시스템 프롬프트로는 안 멈춘다

에이전트가 같은 스텝을 반복해서 재계획하면서 토큰을 태운다. 그리고 시스템 프롬프트에 "10번 이상 같은 작업을 반복하지 마라"고 써도, 루프가 시작되면 그 지시를 그냥 무시한다.

실제 인시던트: 57분 루프

최근에 GitHub에서 버그 리포트를 보다가 좀 황당한 사례를 봤다. 에이전트가 57분 동안 같은 툴 콜을 50번 반복했다. 컨텍스트가 꽉 차자 시스템이 자동 압축을 시도했고 — 7분 걸려서 압축이 됐는데 — 에이전트가 압축 후에 다시 같은 루프를 재개했다. 그 배포에서 하루에 4,765만 토큰이 날아갔다. 루프 감지 기능이 코드엔 다 짜여 있었는데, 기본값이 off였다는 게 문제였다. 대부분 사용자는 그걸 켜야 한다는 걸 몰랐다.

코드에 하드 스텝 제한 걸기

시스템 프롬프트에 의존하면 안 된다. 스텝 제한은 코드에 하드코딩해야 한다. 단순 데이터 조회 에이전트라면 5스텝, 멀티 소스 리서치 에이전트라면 20스텝. 작업 복잡도에 따라 다르게 설정하고, 한도에 도달하는 세션은 반드시 로그로 남겨야 한다. 한도 도달은 태스크 설계가 잘못됐다는 신호다.

패턴 3: 컨텍스트 오버플로우와 에러 캐스케이드

컨텍스트 오버플로우는 15~20 스텝부터 슬금슬금 시작된다. 모델이 앞에서 한 툴 콜 결과를 잊는다. 25~30 스텝을 넘어가면 불일치가 심해진다. 200K 토큰 컨텍스트 창을 가진 모델도 예외가 아니다.

에러 캐스케이드는 다르다. 툴 하나가 실패해서 에이전트가 불일치한 상태로 남으면, 이후 6~7 스텝에 걸쳐 다른 이유들로 계속 실패한다. 근본 원인이 6단계 전에 묻혀 있다. 에러 복구는 타입을 구분해야 한다. 일시적 오류는 백오프 재시도, 입력 오류는 모델에 컨텍스트 재전달, 치명적 오류는 즉시 중단.

비용 한도를 먼저 걸어라

스텝 제한보다 더 빠른 안전장치가 하나 있다. 세션당 비용 한도다. 스텝마다 누적 비용을 계산하고 임계값을 초과하면 멈추는 방식이다. soft limit에서는 현재 툴 콜을 마치고 부분 결과를 반환한다. hard limit에서는 즉시 종료한다. 2년 운영 동안 hard limit에 도달한 세션은 딱 한 번이었다고 한다 — 의도적으로 무한 태스크를 구성한 사용자였다.

물론 이게 모든 걸 해결하지는 않는다. 에이전트의 "자율성"에는 아직 못 올린 천장이 있다. 컨텍스트를 요약하면 세부 정보가 빠지고, 서브태스크로 나누면 핸드오프 오버헤드가 생긴다. 완전히 자율적인 장기 작업 처리는 지금의 인프라 설계로는 한계가 있다. 그래도 시작점은 있다. 스키마를 타이트하게, 스텝 제한을 코드에, 비용 한도를 세션마다. 이 셋만 잡아도 90%의 장애 패턴은 막힌다.

관련해서 멀티에이전트 구조로 투자 분석 자동화하는 방법도 참고해 볼 만하다. 플래너-익스큐터 분리 패턴이 여기서 다룬 루프 문제와 직접 연결된다.

---

📎 참고 자료

• Agentic AI in Production: Tool-Calling, Planning, Recovery — Kalvium Labs
• Bug: tool-loop detection disabled by default (2026-05-04 incident) — GitHub
• Ralph 루프: 자율 AI 에이전트를 밤새 운영하는 방법 — Blake Crosley

---

📌 함께 보면 좋은 글

• 클로드(Claude) 비용은 절반, 품질은 두 배 — 검증된 7가지 레버
• n8n AI 자동화 처음 만들어봤는데, 쉽다는 말이 반만 맞았다
• 카파시 30분 진단 — 바이브 코딩 다음은 에이전틱 엔지니어링이다 (Software 3.0)