AI 에이전트 프로덕션 배포기: 성능보다 중요한 건 '우아한 예외 처리'였다

AI 에이전트는 생각보다 훨씬 잘합니다.

실제로 다양한 도구를 연결해주면, 단순 질의응답을 넘어서 데이터를 바탕으로 사람이 인지하지 못했던 영역까지 분석하고, 급등/급락 감지, 재구매 코호트 분석, 크로스셀 경로 제안까지 — 그래프를 만들고, KPI를 비교 분석하고, 예측을 위한 동적 UI를 구성하고, 디테일한 인사이트와 다음 액션까지 제안할 수 있습니다.

저희 팀도 글로벌 K-뷰티 기업에 AI 에이전트 스킬팩을 배포하면서 이 가능성에 여러 번 놀랐습니다. 데이터를 바탕으로 사람이 인지하지 못했던 영역까지 분석하고, 인사이트를 제공하는 경험은 단순히 "자동화"라는 단어로는 부족했습니다. 실제로 고객사 전무님이 에이전트 동작과 분석 결과를 보시고 "대~박"이라고 하셨다는 이야기를 전달받을 정도였습니다.

그런데 프로덕션에 붙이기 전, 내부 테스트 과정에서 중요한 걸 깨달았습니다. 드물게 실패가 발생했을 때, 대비가 없으면 치명적이라는 점이었습니다.

도구를 쓰는 기본 흐름

AI → 도구 호출 → 결과 수신 → 다음 행동 결정

문제는 도구가 실패했을 때입니다. 내부 테스트 과정에서 발견하고 수정한 문제는 크게 네 가지였습니다.

1. 같은 실패를 반복했다

도구가 에러를 반환하면 AI는 같은 호출을 반복했습니다. 사용자는 응답을 기다리는데, 내부에서는 같은 API가 여러 번 호출되며 비용과 지연이 같이 커졌습니다.

해결: Circuit Breaker

연속 실패 횟수가 일정 기준을 넘으면 해당 도구를 잠시 비활성화하고, AI에게는 내부적으로 "이 도구는 더 쓰지 말고 다른 방법을 찾아라"는 신호를 전달했습니다. 분산 시스템에서 흔히 쓰이는 패턴이지만, AI 에이전트 맥락에서는 "AI의 행동을 제어하는 신호"로 작동한다는 점이 핵심이었습니다.

2. 같은 도구를 중복 호출했다

같은 도구, 같은 파라미터를 다시 호출하는 경우도 있었습니다. AI 입장에서는 확인 행동일 수 있지만, 시스템 입장에서는 중복 트래픽이었습니다.

해결: Dedup Cache

같은 tool + 같은 parameter 조합이면 두 번째 호출에는 캐시된 결과를 반환하도록 했습니다. 캐시 TTL은 도구 특성에 따라 다르게 설정했습니다. 실시간 데이터를 다루는 도구는 짧게, 정적 데이터를 다루는 도구는 길게.

3. 도구가 멈추면 전체 루프가 같이 멈췄다

외부 API가 응답 없이 멈추면 AI 루프 전체가 블로킹됐습니다. 사용자 화면에는 그냥 "로딩 중…"만 계속 남는 상황이 됐습니다.

해결: Timeout 강제

30초를 넘기면 시간 초과로 처리하고, AI에게는 "파라미터를 단순화해서 한 번만 재시도해봐" 같은 식으로 안내했습니다. 타임아웃 값은 도구별로 다르게 설정했고, 외부 API의 평균 응답 시간 데이터를 기반으로 조정했습니다.

4. 에러 메시지 설계가 AI의 행동을 바꿨다 — 핵심 발견

이 부분이 가장 중요한 발견이었습니다.

단순히 "에러 발생"이라고만 전달하면, AI는 같은 행동을 반복하는 경향이 있었습니다. 반대로 에러를 종류별로 구분해 전달하면 행동이 달라졌습니다.

에러 유형	AI에게 전달하는 제어 신호	AI의 행동 변화
도구가 존재하지 않음	"이 도구는 사용 불가, 다른 접근을 찾아라"	재시도 금지, 대안 탐색
권한 없음	"권한 부족, 사용자에게 알려라"	재시도 금지, 사용자 안내
타임아웃	"시간 초과, 파라미터 단순화 후 1회만 재시도"	파라미터 수정 후 1회 재시도
잘못된 입력	"입력값 오류, 파라미터를 수정해서 재시도"	파라미터 수정 후 재시도

즉, 에러 메시지는 로그가 아니라 제어 신호에 가까웠습니다.

이 피드백 루프가 핵심이었습니다. 사람이 개입하지 않아도, AI가 실패를 인식하고 스스로 전략을 바꿔서 해결하는 구조. 에러 메시지를 잘 설계하는 것만으로, AI의 복구 능력이 근본적으로 달라졌습니다.

이 모든 피드백은 사용자에게는 보이지 않는 내부 채널로 전달됩니다.

이게 우리만의 문제가 아니었다

찾아보니 AI 업계 전체가 같은 문제를 겪고 있었습니다.

LangGraph (2025)

LangGraph(LangChain의 에이전트 프레임워크)는 langgraph-prebuilt v1.0.1에서 도구 에러 처리 기본값을 "자동 활성화"에서 "비활성화"로 변경했습니다. 기존 동작에 의존하던 그래프들이 예고 없이 깨지면서 이슈로 보고됐습니다. 이건 단순 버그라기보다, "에러 처리를 프레임워크가 어디까지 기본 제공해야 하느냐"는 질문을 드러낸 사례로 보였습니다.

OpenAI / Anthropic

OpenAI와 Anthropic도 도구 호출 자체는 지원합니다. OpenAI 공식 문서는 function calling을 "애플리케이션이 외부 시스템과 연결해 실행하는 흐름"으로 설명하고 있고, Anthropic 공식 문서도 Claude가 tool_use를 내보내면 개발자가 도구를 실행한 뒤 tool_result를 다시 돌려주는 구조를 전제로 합니다. Anthropic은 is_error 같은 기본 에러 시그널도 제공하지만, 재시도 정책, 도구 폴백, 타임아웃 제어, 상태 복구 같은 워크플로 수준의 안전장치까지 자동으로 해결해주는 것은 아닙니다. 결국 이 부분은 애플리케이션이나 에이전트 프레임워크가 직접 설계해야 하는 영역에 가깝습니다.

MCP 2026 로드맵

MCP(Model Context Protocol) 2026 공식 로드맵에서는 Tasks primitive를 실제 프로덕션에서 운영한 뒤, retry semantics와 expiry policies를 공식적으로 정리해야 할 과제로 적고 있습니다. 프로토콜 차원에서도 "실패 시 누가 재시도하는가"와 "결과를 얼마나 보존하는가"가 중요한 운영 이슈로 인식되고 있다는 신호입니다.

SHIELDA (arXiv 2508.07935, 2025)

SHIELDA는 LLM 에이전트 워크플로우의 예외 처리만을 별도 주제로 다루며, 12개 에이전트 아티팩트에 걸친 36개 예외 유형 taxonomy를 제시합니다. 중요한 점은, 실행 단계에서 터진 예외를 그 이전 단계의 원인과 연결해 복구하려는 관점을 전면에 둔다는 것입니다. "예외 처리를 에이전트 운영의 중심 문제로 본다"는 점이 분명합니다.

저희가 내부 테스트에서 부딪히며 만든 해결책이 업계가 향하는 방향과 정확히 같은 맥락이었습니다.

얻은 교훈

결국 저희가 프로덕션에 앞서 붙인 장치들—circuit breaker, dedup cache, timeout, error classification—은 과한 엔지니어링이 아니었습니다. 오히려 지금의 에이전트 생태계에서는 원래 애플리케이션이 책임져야 하는 기본 운영 장치에 가까웠습니다.

이 경험을 통해 얻은 교훈은 단순합니다.

도구는 실패합니다
AI는 같은 실수를 반복합니다
에러를 분류하고 제어 신호로 전달하면, AI가 스스로 복구합니다
그 실패를 어떻게 처리하느냐가 사용자 경험을 결정합니다

프로덕션 에이전트의 진짜 실력은 "얼마나 똑똑한가"보다 "실패했을 때 AI가 스스로 얼마나 안전하게 복구하는가"에 더 가깝다고 생각하게 됐습니다.

좋은 에이전트는 답을 잘 내는 에이전트이기도 하지만, 그보다 먼저 실패를 드러내고, 분류하고, 스스로 복구할 수 있는 에이전트여야 합니다.