AI 에이전트 프레임워크만으로는 충분하지 않은 이유: 프로덕션 환경에서 누락된 7가지 플랫폼 기능

여러분의 에이전트는 작동합니다. 제대로 작동하고 있다는 걸 알고 있습니다. LangChain이나 CrewAI 또는 맞춤형 솔루션을 기반으로 에이전트를 구축하고, 실제 시나리오에 따라 테스트를 거쳐 성공적으로 처리했을 것입니다. 문제는 에이전트 자체가 아닙니다. 문제는 에이전트를 둘러싼 다른 모든 것입니다.

"우수한 AI 에이전트가 운영 환경에서 실패하는 이유: 부재한 인프라 레이어영어 (English) 버전으로 제공됩니다 (한국어 미지원)"에서는 하나의 AI 에이전트 배포 환경에서 하룻밤 사이에 3가지 장애가 동시에 발생했습니다. 43건의 중복 지원 티켓이 발행되었고, 잘못된 청구 계정에 4,000달러가 청구되었으며, 환각 현상으로 인한 잘못된 환불 정책 때문에 회사는 규정에도 없는 280달러를 환불해 주어야 했습니다. 해당 에이전트는 개발 환경에서는 완벽하게 작동했지만, 프로덕션 인프라가 미비하여 실제 운영 환경에서 문제가 발생했습니다. 개발 중인 에이전트와 프로덕션 레디 배포 사이의 격차는 프레임워크의 문제가 아니라 인프라의 문제입니다.

이 문서에서는 이러한 격차를 분석합니다. 다음 내용에 대해 살펴보겠습니다.

• 현재 어떤 프레임워크에서도 제공하지 않는 7가지 특정 기능
• 프레임워크가 한계에 부딪히는 지점
• 일반적인 3가지 해결 방법이 실패하는 이유
• 에이전트를 다시 작성하지 않고도 격차를 해소하는 데 실제로 도움이 되는 방법

프레임워크가 제공하지 않는 7가지 기능

오전 6시에 발생한 인시던트로 3가지 장애가 드러났습니다. 하지만 이 세 가지는 더 광범위한 인프라 누락의 징후일 뿐입니다. 여러 조직의 프로덕션 에이전트 장애를 분석해 보면 매번 동일한 7가지 격차가 나타납니다.

1. 암호화 ID

암호화 ID는 요청을 보내는 워크로드에 대한 검증 가능한 증거를 제공하며, 워크로드가 액세스할 수 있는 서비스를 결정하는 ID 속성을 포함합니다. 4,000달러의 잘못된 계정 청구는 에이전트가 프로덕션용으로 범위가 지정되지 않은 광범위한 자격 증명으로 실행되었기 때문에 발생했습니다. 대규모 언어 모델(LLM)이 잘못된 계정 식별자를 선택했지만, 인프라의 그 어떤 요소도 이를 차단하지 못했습니다. 암호화 ID를 사용하면 플랫폼이 에이전트가 액세스할 수 있는 서비스를 제한하고, 적절하게 구성된 다운스트림 API가 지정된 호출자에게 유효한 매개변수를 강제 적용합니다. 모델이 여전히 잘못된 식별자를 선택할 수는 있지만, 잠재적인 영향은 제한됩니다. 즉, 시스템의 모든 계정이 아니라 에이전트의 승인된 범위 내 리소스로만 피해가 국한됩니다. 의사 결정자 입장에서 이는 '하나의 계정이 영향을 받은 것'과 '모든 계정이 노출된 것'의 엄청난 차이를 의미합니다.

2. 실행 샌드박싱

실행 샌드박싱은 하드웨어 및 애플리케이션 수준의 격리를 제공하여, 보안이 침해되거나 오작동하는 워크로드가 호스트 운영 체제에 도달하거나 다른 워크로드에 영향을 미치지 않도록 방지합니다. 이는 에이전트만의 문제가 아닙니다. 모든 워크로드에는 격리가 필요하지만, 에이전트는 자율적으로 작동하며 머신과 같은 속도로 API를 호출하고 툴 작업을 실행하므로 격리가 더욱 시급합니다. 샌드박싱을 사용하지 않으면 동일한 머신에서 발생한 한 워크로드의 오류가 모든 워크로드의 오류로 이어집니다. 파일 시스템에 데이터를 쓰거나 허용 범위를 벗어난 네트워크 연결을 생성할 수 있는 에이전트는 보안 팀이 프로덕션용으로 절대 승인하지 않을 리스크 요인입니다.

3. 툴 거버넌스

툴 거버넌스는 에이전트가 호출할 수 있는 툴을 결정하는 인프라 수준의 정책입니다. 이는 네트워크 계층에서 시행되므로 프롬프트 주입(악의적인 입력으로 에이전트를 속여 의도하지 않은 작업을 수행하게 하는 기술)으로도 우회할 수 없습니다. 프롬프트 엔지니어링을 통해 툴 액세스를 제어하려는 시도를 보았지만, 이는 충분하지 않습니다. 결단력 있는 공격자나 충분히 창의적인 모델은 프롬프트 수준의 제한을 우회할 방법을 찾아냅니다. 거버넌스는 프롬프트가 아닌 인프라 수준에서 이루어져야 합니다.

4. 관측성 및 추적

관측성 및 추적 기능에는 모든 프롬프트, 툴 호출, 중간 결과를 캡처하는 전체 실행 추적이 포함됩니다. 오전 6시 인시던트에서 발생한 3건의 장애는 고객의 불만이나 인보이스 문제가 제기되기 전까지 전혀 감지되지 않았습니다. 전체 실행 추적 기능이 있었다면 고객이 보고하기 전에 각 장애를 미리 확인할 수 있었을 것입니다. 개발자는 분산 마이크로서비스 호출을 디버깅하는 것과 동일한 방식으로 다단계 에이전트 상호 작용을 디버깅할 수 있습니다. 기업 입장에서는 컴플라이언스 검토를 통과할 수 있는 감사 추적을 확보하게 됨을 의미합니다.

5. 지속적인 평가

지속적인 평가는 정책 및 정답(ground truth)을 기준으로 에이전트 출력에 대한 프로덕션 점수를 제공하므로, 고객이 보고하기 전에 회귀 오류를 파악할 수 있습니다. 에이전트가 고객에게 반품 기간을 실제 30일이 아닌 90일이라고 잘못 안내한 환각 현상은 실제 정책과 출력을 대조하는 평가 레이어가 없었기 때문에 발생했습니다. 정적 테스트 제품군은 예상 가능한 문제를 잡아내지만, 지속적인 평가는 예상치 못한 문제를 잡아냅니다.

6. 안전 시행

안전 시행은 추론 경계에서 가드레일을 제공하여 출력이 고객, 데이터베이스 또는 다운스트림 에이전트에 도달하기 전에 차단합니다. 에이전트가 하루에 3번 실패한 사례에서, 프레임워크는 모델의 조작된 응답을 아무런 점검 없이 고객에게 직접 전달했습니다. 안전 시행을 통해 추론 경계는 단순한 통로가 아닌 체크포인트 역할을 하게 됩니다.

7. 라이프사이클 관리

라이프사이클 관리에는 일관된 운영 및 보안 태세를 갖춘 제품군 전반에서 에이전트를 배포, 업데이트, 확장, 사용 종료하는 작업이 포함됩니다. 에이전트 한 개는 프로젝트 수준이지만, 3개 팀에 걸친 10개의 에이전트는 운영상의 과제입니다. 라이프사이클 관리가 없으면 각 팀은 자체적인 배포 프로세스, 보안 모델, 업데이트 주기를 따로 고안하게 됩니다. 이로 인해 일관성이 사라집니다.

프레임워크가 한계에 부딪히는 지점

프로덕션 환경에서는 이러한 7가지 기능 전반의 일관성이 반드시 필요합니다. 그렇다면 현재 사용 중인 프레임워크는 어떤 상태일까요? LangChain과 LangGraph는 체인, 에이전트, 툴 호출, 구조화된 출력, 그래프 기반 오케스트레이션, 세션 메모리, 검색 통합 기능을 제공합니다. 이러한 구성 기능은 매우 강력합니다. CrewAI는 멀티 에이전트 조정, 역할 기반 에이전트 설계, 태스크 위임, 크루 오케스트레이션을 제공하며, 멀티 에이전트 패턴이 잘 설계되어 있습니다. Google ADK는 Google 에코시스템과 긴밀하게 통합됩니다. Claude Agents는 깊이 있는 추론 능력을 제공합니다. Strands(AWS)는 AWS 네이티브 워크플로우 통합을 제공합니다.

각 프레임워크는 에이전트를 에이전트답게 만드는 인식, 추론, 행동의 주기인 에이전트 루프 구현에 탁월합니다. 하지만 암호화 ID나 실행 샌드박싱을 제공하는 프레임워크는 하나도 없습니다. 네트워크 계층에서의 툴 거버넌스 기능도 부재합니다. 프로덕션급 분산 추적, 지속적인 평가, 추론 경계에서의 안전 시행, 플릿 라이프사이클 관리는 그 어디에도 존재하지 않습니다.

이는 비판이 아니라 단순히 범주가 다르다는 점을 지적하는 것입니다. 프레임워크는 애플리케이션 계층 툴이지만, 앞서 나열한 7가지 기능은 플랫폼 계층의 영역입니다. 프레임워크가 이러한 기능을 제공하길 기대하는 것은 Django가 쿠버네티스를 제공하길 기대하는 것과 같습니다. 컨테이너 오케스트레이션은 애플리케이션 로직이 아닌 인프라의 영역이며, 웹 프레임워크에 이 기능이 포함되기를 바라는 것은 무리입니다. 에이전트의 경우에도 마찬가지입니다. 담당하는 계층이 다를 뿐입니다.

적절한 ID, 추적, 거버넌스를 갖춘 LangChain 에이전트를 배포해 본 적이 있다면 이미 이 점을 느꼈을 것입니다. 결국 에이전트 코드보다 플랫폼 통합 코드를 더 많이 작성하게 됩니다. 에이전트 구현은 오히려 쉬운 부분이었습니다.

확장성이 떨어지는 3가지 접근 방식

에이전트 구현이 쉬운 부분이었다면, 팀은 여전히 어려운 부분을 해결해야 합니다. 제가 상담한 모든 팀은 플랫폼 솔루션을 찾기 전에 다음 중 하나 이상의 방식을 시도했습니다.

직접 구축 팀에서 자체적으로 ID 주입, 추적 통합, 배포 스크립트를 작성합니다. 에이전트가 1개일 때는 이 방법이 효과적입니다. 모든 세부 사항을 직접 파악하고 있으므로 만족스럽기까지 합니다. 하지만 3개 팀에서 10개의 에이전트를 운영하게 되면, 각 팀은 서로 다른 보안 모델, 추적 형식, 배포 프로세스를 갖게 됩니다. 일관성과 거버넌스는 사라지고 유지 관리 부담만 커지며, 이로 인해 선임 엔지니어가 에이전트 개발 자체에 집중하지 못하게 됩니다. 저는 팀들이 에이전트 기능을 구축하는 것보다 자체 제작한 플랫폼을 유지 관리하는 데 더 많은 시간을 허비하는 것을 보았습니다.

Salesforce Agentforce, AWS Bedrock Agents, Azure AI Agent Service와 같은 호스팅된 에이전트 플랫폼은 전체 스택을 직접 관리하여 프로덕션 격차를 해소합니다. 하지만 그 대가로 데이터 경로에 대한 통제권도 플랫폼이 가져갑니다. 모든 프롬프트, 툴 호출, 추론 결과가 타사 서비스를 거치게 됩니다. 데이터가 네트워크 외부로 유출되어서는 안 되는 규제 산업에서는 이러한 방식을 도입할 수 없습니다. 또한 플랫폼이 가격을 변경하거나 기능을 중단하면 에이전트도 그에 맞춰 변경해야 합니다.

프레임워크별 확장 프로그램은 단일 에코시스템 내에서 프로덕션 중심의 애드온을 제공합니다. 추적을 위한 LangSmith가 대표적인 예이며 매우 유용합니다. 하지만 LangChain, CrewAI, 맞춤형 에이전트를 동시에 운영하는 조직은 이제 3가지의 서로 다른 프로덕션 관리 체계가 필요하게 됩니다. 이는 팀이 학습해야 할 추적 형식, 보안 모델, 툴 세트가 각각 3개씩 늘어남을 의미합니다. 프로덕션 인프라는 특정 벤더의 에코시스템에 종속되지 않고 프레임워크에 구애받지 않아야 합니다.

각 접근 방식은 문제의 일부를 해결하지만 새로운 제약 조건을 만듭니다. 첫 번째 방식은 확장이 불가능합니다. 두 번째 방식은 편의를 위해 주권을 포기합니다. 세 번째 방식은 프레임워크 경계에 따라 프로덕션 관리 체계를 파편화합니다.

사용자의 에이전트와 Red Hat의 플랫폼

모든 접근 방식이 공유하는 제약은 프로덕션 인프라가 에이전트 프레임워크와 동일한 곳에서 제공되거나 처음부터 직접 구축해야 한다고 가정하는 것입니다. 저는 그 가정이 틀렸다고 생각합니다. BYOA(Bring Your Own Agent)는 플랫폼이 코드 변경 없이 모든 에이전트 프레임워크에 프로덕션 인프라를 제공하는 Red Hat AI의 접근 방식으로, 기존과는 정반대의 전제에서 시작합니다.

Red Hat은 프레임워크 계층에서 경쟁하지 않습니다. 에이전트가 LangChain, CrewAI, Claude Agents, Google ADK, Strands 또는 사용자 정의 Python 중 무엇으로 실행되든 Red Hat AI는 이를 운영화합니다. 팀이 개발 단계에서 작성한 에이전트 코드는 프로덕션에서 실행되는 코드와 동일합니다. ID, 샌드박싱, 툴 거버넌스, 추적, 평가, 라이프사이클 관리는 에이전트 개발자가 작성하는 것이 아니라 플랫폼에 의해 주입됩니다. 또한 프로덕션 인프라는 조직 내 모든 프레임워크에서 일관되게 유지됩니다.

의사 결정자 입장에서 이는 조직이 선택한 프레임워크에 대한 투자가 낭비되지 않음을 의미합니다. 팀은 선호하는 프레임워크와 규제 제한 사항을 준수하는 프로덕션 인프라 중 하나를 선택할 필요 없이, 두 가지 모두를 활용할 수 있습니다. 플랫폼이 프레임워크에 프로덕션 인프라를 제공하는 것이지, 그 반대가 아닙니다.

BYOA는 또한 AI 인프라를 임대하는 방식에서 소유하는 방식으로의 전환을 의미합니다. Red Hat은 디지털 주권의 4가지 핵심 요소로 데이터 주권, 기술 주권, 운영 주권, 보증 주권을 정의합니다. BYOA 플랫폼은 이 4가지 요소를 모두 해결하며, 이에 대해서는 향후 문서에서 자세히 다룰 예정입니다.

자율 사이트 신뢰성 엔지니어(SRE) 에이전트를 구동하는 동일한 플랫폼 인프라가 인사(HR) 온보딩 어시스턴트, 조달 승인 워크플로우, 고객 서비스 에스컬레이션 봇을 모두 지원할 수 있습니다. 즉, 활용 사례가 다르더라도 인프라는 도메인에 구애받지 않습니다.

Red Hat은 인증, MCP(Model Context Protocol) 연결, 추적 초기화 등 플랫폼 통합이 이미 완료된 LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK 등을 위한 스타터 키트를 제공합니다. 팀은 몇 주간의 통합 작업에 매달리는 대신 Day 0부터 바로 구축을 시작할 수 있습니다.

이미 답을 알고 있는 결정

‘몇 주가 아닌 Day 0(즉시 도입)’이라는 표현은 익숙하게 들릴 것입니다. 10년 전, 조직은 컨테이너와 관련하여 동일한 문제에 직면했습니다. 모든 팀이 컨테이너를 만들 수는 있었지만, 조직 전반에서 일관된 보안, 네트워킹, 라이프사이클 관리를 갖춘 프로덕션 환경에서 컨테이너를 실행할 수 있는 사람은 없었습니다. 그 해답은 '더 나은 컨테이너 런타임 선택'이 아니라, 런타임 자체에서 제공하지 않는 인프라를 통해 모든 컨테이너 런타임을 운영화할 수 있는 플랫폼인 Red Hat OpenShift에 있었습니다. 지금 논의하는 내용이 익숙하게 느껴지는 이유는 Red Hat AI가 바로 그 기반 위에서 실행되기 때문입니다.

에이전트 격차 문제도 이와 동일한 양상을 보입니다. 핵심은 '어떤 프레임워크를 사용해야 하는가'가 아닙니다. 여러분은 이미 그 결정을 내렸으며, 아마도 그것이 최선의 선택이었을 것입니다. 중요한 질문은 '내 프레임워크가 제공하지 않는 프로덕션 인프라를 누가 제공하는가'이며, 가장 먼저 해결해야 할 격차는 개발과 프로덕션 사이의 간극이 가장 큰 영역입니다. 그 영역은 바로 보안이며, 다음 블로그에서 이 내용을 다루겠습니다.

시작하기

에이전트의 프로덕션 격차를 해소할 준비가 되셨나요?

• 개발자 샌드박스에서 무료로 OpenShift AI 체험하기: 사전 구성된 환경에서 비용 부담 없이 에이전트를 빌드하고 테스트해 보세요.
• BYO 에이전트 스타터 키트 살펴보기: LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK 등을 위해 사전 구성된 템플릿입니다.
• 무료 Red Hat AI Foundations 교육 과정 수강하기: Red Hat AI 기반 구축의 핵심을 다루는 핸즈온 랩입니다.
• Red Hat AI에 대해 알아보기: 플랫폼 개요 및 프로덕션 인프라 기능을 확인해 보세요.
• Red Hat AI에서 BYOA 운영하기: OpenClaw 에디션: 실제 에이전트 배포를 통해 BYOA의 실제 활용 사례를 확인해 보세요.