우수한 AI 에이전트가 프로덕션 환경에서 실패하는 이유: 부재된 인프라 레이어

첫 번째 알림이 발생한 시간은 오전 6시였습니다. 곧이어 두 번째 알림이 울렸습니다. 그리고 세 번째 알림이 울렸습니다.

온콜 엔지니어가 노트북을 열었을 때 단일 AI 에이전트에서 발생한 관련 없는 3개의 장애를 발견했습니다. 이 에이전트는 지원 티켓을 처리하고, 청구 조정을 진행하며, 고객 질문에 답변했습니다. 이 에이전트는 LangChain 기반으로 실행되었습니다. 스테이징 환경의 모든 테스트를 통과했고 정상적으로 작동했지만, 결국 문제가 발생했습니다.

많은 팀이 프롬프트 엔지니어링과 모델 선택에 수개월을 쏟아붓고도, 이 둘 중 어느 것과도 무관한 인시던트를 수습하느라 주말을 허비하는 모습을 지켜보았습니다. 다음에 소개할 장애는 가상의 상황이 아닙니다. 에이전트를 제대로 지원하는 데 필요한 인프라 없이 프로덕션 환경에 처음 배포되었을 때 발생하는 일반적인 문제입니다. 그리고 프로덕션 배포에 필요한 아이덴티티 경계, 안전성 적용, 운영 거버넌스 등의 인프라를 기본으로 제공하는 프레임워크는 아직 보지 못했습니다.

43건의 중복된 지원 티켓

목표를 추론하고, 툴을 선택하며, 자율적으로 다단계 작업을 수행하는 AI 시스템인 이 에이전트는 지원 대기열을 모니터링하고 있었습니다. 한 고객이 문의 케이스를 제출했습니다. 에이전트가 티켓 생성을 위해 티켓팅 API를 호출했고, API는 요청을 수락하여 티켓을 생성했습니다. 그러나 응답 시간이 초과되었습니다.

에이전트의 관점에서는 호출이 실패한 것이었습니다. LangChain은 잘 설계된 프레임워크가 툴 호출 실패 시 수행하는 일반적인 동작대로 재시도를 실행했습니다. 재시도로 인해 두 번째 티켓이 생성되었습니다. 응답 시간이 다시 초과되었습니다. 또 다른 재시도가 이어졌습니다. 또 다른 티켓이 생성되었습니다.

오전 6시가 되자 시스템에는 43건의 중복 티켓이 쌓였습니다. 각 티켓마다 자동 확인 이메일이 발송되어 고객의 수신함에 43개의 이메일이 도착했습니다. 지원 팀은 본연의 업무 대신 아침 내내 중복 티켓을 수동으로 닫고 사과 메일을 보내야 했습니다.

여기서 무엇이 잘못되었는지 명확히 짚고 넘어가고자 합니다. 이는 매우 중요하기 때문입니다. LangChain은 이 과정을 올바르게 처리했습니다. 프레임워크는 실패한 응답을 감지하고 호출을 재시도했습니다. 재시도 로직은 바로 이러한 동작을 수행하도록 설계되었습니다. 문제는 재시도가 아니라, 인프라의 어느 곳에서도 원래 요청의 성공 여부를 추적하지 않았다는 점이었습니다. 멱등성 엔벨로프(반복된 요청이 원본과 동일한 결과를 생성하도록 보장하여 중복을 방지하는 메커니즘)가 없었습니다. 중복 제거 레이어도 없었습니다. 이미 완료된 작업의 재시도임을 플랫폼 수준에서 인식하지 못했습니다.

손익을 따지는 의사 결정자 관점에서 보면, 여기서 발생한 비용은 단순히 당혹스러운 아침 한때의 해프닝에 그치지 않았습니다. 사후 처리에 소모된 지원 인력의 업무 시간, 기계적인 중복 이메일로 인해 실추된 고객 신뢰, 그리고 모든 미결 티켓을 수동으로 전수 검사하기 전까지는 시스템을 신뢰할 수 없게 된 손실이었습니다. 재시도 로직을 검토하는 개발자의 입장에서는 코드가 완전했습니다. 격차는 그 하부 인프라에 존재했습니다.

프레임워크는 제 역할을 다했습니다. 단지 이를 뒷받침할 주변 인프라가 존재하지 않았을 뿐입니다.

잘못된 계정에 청구된 4,000달러

인프라 격차는 43건의 티켓처럼 요란하게 드러날 수도 있지만, 소리 없이 은밀하게 발생할 수도 있습니다. 동일한 AI 에이전트가 청구 조정 작업도 처리했습니다. 이 에이전트는 배포 시 서비스 계정으로 프로비저닝된 청구 API에 대한 액세스 권한을 가지고 있었습니다. 개발 단계에서 에이전트를 가장 빠르게 실행하기 위해 해당 서비스 계정이 여러 청구 계정에 접근할 수 있도록 설정되어 있었습니다. 단순 구성이 아닌 검증된 아이덴티티를 기반으로 특정 워크로드가 액세스할 수 있는 리소스를 제어하는 인프라 레이어인 아이덴티티 경계를 구축한 사람이 없었기 때문에, 에이전트를 프로덕션으로 전환하기 전에 자격 증명 범위를 제한하지 않았습니다.

에이전트는 계정 A에 대한 청구를 처리해야 했습니다. 프롬프트에는 계정 식별자가 포함되어 있었습니다. 모델은 계정 B를 선택했습니다. 이는 모든 대규모 언어 모델(LLM)에서 흔히 발생할 수 있는 그럴듯한 오류였습니다. 청구 API가 호출을 수락하여 엉뚱한 고객에게 4,000달러가 청구되었습니다.

이는 모델 자체의 장애가 아니었습니다. 대규모 언어 모델은 그럴듯한 출력을 생성하지만 때로는 잘못된 결과를 내놓기도 합니다. 동일한 청구 API에 잘못된 계정 매개변수가 전달된 것이 원인일 가능성이 높으며, 이는 발생 가능한 파라미터 선택 오류였습니다.

기존 소프트웨어에서는 잘못 라우팅된 API 호출의 잠재적 영향이 두 가지 계층으로 제한됩니다. 자격 증명 범위 지정을 통해 워크로드가 접근할 수 있는 서비스를 제한하고, 다운스트림 API가 지정된 호출자에게 유효한 매개변수를 적용합니다. 개발자라면 단일 자격 증명 세트로 모든 고객의 청구 기록을 수정할 수 있는 웹 애플리케이션을 배포하지 않겠지만, 여기서는 바로 그런 일이 일어났습니다.

에이전트는 시스템의 모든 계정에 접근할 수 있을 만큼 광범위한 자격 증명으로 프로비저닝되었으며, 플랫폼이나 다운스트림 API 등 스택 내의 어떤 요소도 그 범위를 제한하지 않았습니다. 현재 자격 증명 범위 지정 기능을 기본으로 제공하는 프레임워크는 없습니다. 암호화된 워크로드 아이덴티티를 제공하거나 프롬프트 콘텐츠가 아닌 인프라 수준의 정책을 기반으로 에이전트가 접근할 수 있는 서비스를 제어하는 프레임워크는 존재하지 않습니다.

다음 주 월요일에 누군가 인보이스를 검토하기 전까지는 아무도 이를 알아차리지 못했습니다. 다양한 규모에서 이러한 장애가 변형되어 나타나는 사례를 보아왔습니다. 세부적인 사항은 다르지만 근본 원인은 항상 동일합니다. 에이전트에 있어서는 안 될 자격 증명이 부여되었고, 스택의 어느 곳에서도 경계를 강제하지 않았습니다.

회사가 작성한 적 없는 환불 정책

경계(Boundary) 제어가 동작하지 않아 그날 밤 4,000달러의 손실이 발생했지만, 세 번째 실패는 금액으로 산정하기조차 어려운 손실을 불러왔습니다. 한 고객이 에이전트에게 제품 구매 후 반품 가능 기간에 대해 문의했습니다. 모델은 확신에 차고 명확한 어조로 환불 정책상 90일 이내에 반품이 가능하다는 답변을 생성했습니다. 하지만 실제 정책은 30일이었습니다. 답변은 조리 있고 친절했지만 완전히 틀린 내용이었습니다.

LangChain은 모델의 출력을 고객용 응답 채널로 그대로 전달했습니다. 이번에도 프레임워크는 모델의 출력을 체인의 다음 단계로 라우팅하는 본연의 역할을 정확히 수행했습니다. 고객에게 전송되거나 데이터베이스에 기록되거나 특정 작업을 트리거하는 데 사용되는 등 모델의 출력이 실제 환경에 적용되는 지점인 추론 경계에 가드레일이 없었습니다. 출력을 문서화된 정책과 대조하여 검증하는 레이어가 없었습니다. 에이전트의 응답이 고객에게 도달하기 전에 알려진 팩트와 모순되는지 확인하는 메커니즘이 없었습니다. 출력은 중간 검증 없이 모델에서 고객에게 곧바로 전달되었습니다.

고객은 에이전트의 답변을 근거로 제시하며 47일 차에 280달러 상당의 제품을 반품했습니다. 지원 팀은 해당 반품을 수용했습니다. 손실은 환불 금액 자체에 그치지 않고 법적 리스크로 이어졌습니다. AI 에이전트가 고객에게 권한 없는 계약상 진술을 했으며, 기업에는 이를 방지하기 위한 제어 기능이 마련되어 있었음을 입증할 감사 추적 기록이 없었습니다.

청구 오류는 금액으로 환산할 수 있습니다. 중복 티켓은 개수로 집계할 수 있습니다. 하지만 고객에게 이미 전달된 부정확한 정책은 수량화하기도, 수습하기도 매우 어렵습니다. 이는 누적되는 법적 책임입니다. 검증 없이 에이전트가 전송하는 모든 응답은 법무 팀이 승인한 적 없는 잠재적인 계약 의무가 될 수 있습니다. 고객과 커뮤니케이션하는 에이전트를 운영하는 모든 조직이 이러한 위험에 직면해 있으며, 대부분은 이를 인지조차 하지 못하고 있습니다.

에이전트 자체에는 문제가 없었습니다

개발 환경에서는 완전하게 작동하던 에이전트에서 하룻밤 사이에 3건의 장애가 발생했습니다.

이 패턴을 살펴보세요. 모든 경우에서 프레임워크는 올바르게 작동했습니다. LangChain은 툴 호출을 오케스트레이션하고, 출력을 라우팅하며, 장애 발생 시 재시도를 수행했습니다. 추론, 계획, 툴 호출, 오케스트레이션 등 에이전트 루프는 설계된 대로 정상 작동했습니다.

모든 장애는 프로덕션 인프라가 부재했기 때문에 발생했습니다. 첫 번째 장애는 플랫폼 수준의 멱등성과 중복 제거 기능이 필요했습니다. 두 번째 장애는 범위가 지정된 자격 증명과 암호화된 워크로드 아이덴티티를 갖춘 아이덴티티 경계가 필요했습니다. 세 번째 장애는 응답이 고객에게 도달하기 전에 문서화된 팩트를 기반으로 출력을 검증하는 추론 경계의 가드레일이 필요했습니다.

이는 프레임워크가 담당할 영역이 아닙니다. 아이덴티티, 툴 거버넌스(에이전트가 어떤 조건에서 어떤 툴에 액세스할 수 있는지 제어), 관측성(감사 및 디버그를 위해 에이전트의 모든 작업을 트랙킹), 안전 적용은 모두 플랫폼의 영역이며, 이를 해결하도록 설계된 프레임워크는 없습니다.

저는 LangChain, CrewAI, LangGraph 및 사용자 정의 프레임워크에서 에이전트를 운영하는 여러 팀과 이야기를 나누었습니다. 선택한 프레임워크는 저마다 달랐습니다. 하지만 인프라의 격차는 동일했습니다. 모두가 같은 한계에 부딪혔습니다. "개발 환경에서의 작동"과 "프로덕션 환경에서의 실행" 사이의 간극은 프레임워크 문제가 아니라 인프라 문제이며, 이를 해결하지 않는 한 실제 비용과 고객 신뢰, 엔지니어링 시간이 계속해서 소모됩니다.

격차를 해소하는 방법

이러한 인프라 문제는 구체적인 형태를 띠고 있습니다. 에이전트 프레임워크는 에이전트 루프 문제를 해결합니다. 프로덕션 인프라를 해결하기 위해 설계된 것도 아니며, 그럴 필요도 없습니다. 웹 프레임워크가 자체 TLS(Transport Layer Security) 인증 기관을 직접 제공할 것이라고 기대하지 않는 것과 같습니다. 이는 서로 다른 엔지니어링 범주에 속합니다.

Red Hat AI는 프레임워크가 제공하지 못하는 프로덕션 인프라를 제공합니다. Red Hat OpenShift AI가 그 기반 역할을 합니다. 운영 원칙은 BYOA(Bring Your Own Agent)로, 플랫폼은 에이전트 코드를 변경할 필요 없이 LangChain, CrewAI, LangGraph, 사용자 정의 코드 등 모든 에이전트 런타임을 안정적으로 운영 환경에 배포합니다. 기존 프레임워크에 대한 투자가 그대로 유지됩니다. 에이전트 코드를 수정할 필요가 없습니다. 플랫폼이 그 하부에 아이덴티티, 안전, 거버넌스, 관측성 레이어를 제공합니다.

현재 마주하고 있는 격차

오전 6시에 장애를 일으킨 에이전트는 결코 잘못 만들어진 에이전트가 아니었습니다. 밑을 받쳐주는 단단한 기반 없이 실행되고 있던 우수한 에이전트였습니다. 모든 프레임워크는 추론 루프, 툴 호출, 오케스트레이션 기능을 제공합니다. 그러나 이러한 기능이 실제 환경에서 안전하게 실행될 수 있는지를 결정하는 인프라를 제공하는 프레임워크는 없습니다. 프레임워크가 처리하는 역할과 플랫폼이 반드시 담당해야 하는 역할 사이의 이러한 차이가 바로 프로덕션 격차입니다. 이는 프레임워크가 해결하도록 설계된 격차가 아닙니다.

지금 개발 중인 에이전트가 있다면, 동일하게 부재한 기반 위에 서 있을 가능성이 높습니다. 구축이 잘못되어서가 아니라, 프레임워크 자체가 이러한 기반 인프라를 함께 제공하지 않기 때문입니다. 다음 아티클에서는 이러한 기반을 구성하는 구체적인 요소와 이를 구축하는 데 필요한 사항을 소개합니다.

시작하기

프로덕션 환경에 즉시 적용 가능한 AI 에이전트 인프라가 어떤 모습인지 확인할 준비가 되셨나요? 다음을 살펴보세요:

• Developer Sandbox에서 무료로 OpenShift AI 체험하기: AI 워크로드 실험을 위해 사전 구성된 환경
• Red Hat AI 인터랙티브 데모 살펴보기: Red Hat AI를 직접 체험해 볼 수 있는 핸즈온 소개
• BYO Agent 스타터 키트로 시작하기: LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK 등을 위해 사전 구성된 템플릿
• Red Hat AI 도큐멘테이션 읽기: 전체 플랫폼 도큐멘테이션
• Red Hat AI에서 BYOA 운영하기: OpenClaw 에디션: 플랫폼에 실제 에이전트를 배포하는 방법을 다룬 핸즈온 아티클