게이트웨이 없이 AI 에이전트를 실행할 때 끔찍하게 잘못되는 5가지 일 (그리고 출혈을 막는 방법)

AI 에이전트 하나만 돌리나요? 귀엽네요. 열 개를 돌린다면요? 이제야 제대로 된 이야기죠. 게이트웨이나 거버넌스 없이, 그리고 아무도 읽지 않는 #agents-prod라는 슬랙 채널로 50개의 에이전트를 프로덕션 환경에서 운영한다고요? 그러면 월요일 아침 회의에서 CFO에게 왜 주말 동안 LLM 청구서가 $4K에서 $61K로 늘어났는지, 그리고 왜 회계팀이 플래그를 지정하기 전까지 아무도 알아차리지 못했는지 설명하게 될 겁니다. 저는 이 영화를 너무 많이 봤습니다. 줄거리는 항상 똑같죠. 누군가가 화요일에 에이전트 AI(agentic AI)에 대해 읽고, 금요일까지 개념 증명(PoC)을 배포하고, 한 분기 후에는 문서화되지 않은 MCP 서버를 통해 서로 대화하는 7개의 레포지토리에 에이전트들이 여기저기 흩어져 있고, API 키는 세 엔지니어의 노트북에 있는 .env 파일에 놓여 있습니다. 그러다 무언가 고장 납니다. 작지 않습니다. 가장 흔하게 잘못되는 다섯 가지 방법과 각각을 실제로 해결하는 방법을 알려드리겠습니다.

실패 #1: 예산을 잡아먹은 무한 에이전트 루프

당신은 에이전트 A를 만듭니다. 유용하죠. 막힐 때 에이전트 B에게 도움을 요청할 수 있습니다. 에이전트 B도 유용합니다. 막힐 때 에이전트 C에게 도움을 요청할 수 있죠. 에이전트 C 역시 당연히 도움이 됩니다. 그리고 막힐 때, 다시 에이전트 A에게 요청합니다. 어디로 가는지 보이시죠? 이 루프는 금요일 오후에 시작됩니다. 아무도 위임 깊이 제한(delegation depth limits)을 설정하지 않았습니다. 아무도 에이전트별 예산 상한선(per-agent budget caps)을 설정하지 않았습니다.

에이전트들이 주말 동안 서로에게 38,000번씩 전화를 겁니다. 각 통화는 돈 몇 푼으로 시작하지만, 순식간에 달러가 되고, 곧바로 '월요일 오전 8시에 회의에 오세요'라는 요청으로 이어집니다. 이를 막아줄 것이었던 것은 A 게이트웨이였습니다. 이 게이트웨이는 에이전트와 모델 제공자 사이에 위치하여 두 가지를 강제합니다: 하드 위임 깊이 제한(Hard delegation depth limits) (Agent X는 N개 이상의 다운스트림 호출을 트리거할 수 없음) 그리고 에이전트별 토큰 및 달러 상한선(Per-agent token and dollar caps) (Agent X는 하루 $50를 받습니다. 그 한도에 도달하면 멈춥니다). TrueFoundry 같은 도구들이 바로 이런 용도로 만들어졌습니다. 대시보드에서 에이전트별 예산 책정이 이루어지며, 요청 수준에서 강제되고 전체 위임 체인을 보여주는 중앙 집중식 비용 보기 기능을 제공합니다. 이 루프는 스테이크 저녁 식사비로 돈을 쓰기도 전에, 심지어 모기지 납부액으로 돈을 쓰기도 전에 종료됩니다. Helicone — 탁월한 관측 가능성(observability). 실시간 대시보드에서 급증하는 것을 아름답게 볼 수 있습니다. 하지만 이를 막지는 못합니다. 연기 감지기이지 스프링클러 시스템이 아닙니다. Langfuse — 비슷한 이야기입니다. 훌륭한 추적 기록(traces)을 제공하여 사후 분석에 도움이 됩니다. 예산 상한선을 강제하도록 설계되지는 않았습니다. 실패 #2: 모두의 급여를 아는 유용한 챗봇 한 대 한 제품팀이 내부 Q&A 봇을 만듭니다. 이를 유용하게 만들기 위해, 회사의 데이터베이스와 MCP 서버를 통해 연결합니다. 권한 범위를 좁게 설정하는 것은 번거롭다고 여겨지기 때문에('나중에 고칠게요'), 에이전트는 광범위한 읽기 접근 권한을 얻게 됩니다. 3개월 후, 마케팅 부서의 누군가가 그 봇에게 무심코 '야, 엔지니어링에 있는 마커스는 얼마 받는데?'라고 묻습니다. 그리고 봇은 기꺼이, 자신감 있게 그것을 알려줍니다.

이것은 가설이 아닙니다. 당신이 들어본 회사들 중 일부에서 이미 이런 일이 발생했고, 그 복구 과정에는 '공개(disclosure)', '시정 조치(remediation)', 그리고 '법무팀을 참여시켜야 합니다(loop in legal)' 같은 단어들이 포함됩니다. 이를 막았을 것이라고 상상해 보세요. 두 가지 요소가 결합된 경우입니다: 에이전트 레지스트리 (agent registry) — 조직 내의 모든 에이전트는 등록되고, 소유권이 명시되며, 문서화되고, 검색 가능합니다. '잠깐, 누가 이걸 배포했지?'라는 질문은 더 이상 없습니다. 도구 수준의 RBAC(역할 기반 접근 제어)가 있는 MCP 게이트웨이 (MCP gateway) — 에이전트가 광범위한 데이터베이스 접근 권한을 얻는 것이 아닙니다. 특정 도구를 호출할 수 있는 권한, 특정 인수를 사용해야 하며, 특정 데이터에 한정됩니다. TrueFoundry가 돕는 도구들 — 에이전트 레지스트리와 MCP 게이트웨이를 하나의 제어 평면(control plane)에서 제공합니다. 모든 에이전트를 볼 수 있고, 누가 소유하는지, 어떤 도구를 호출할 수 있는지, 그리고 그 도구들이 어떤 데이터에 접근할 수 있는지를 알 수 있습니다. CISO들은 이것을 좋아하는데, 왜냐하면 '우리 환경에서 어떤 AI가 실행되고 있나요?'라는 질문에 더 이상 어깨를 으쓱하며 대답할 필요가 없기 때문입니다. Obot AI — 어떤 서버에 설치될 수 있는지 접근 제어 기능을 갖춘 괜찮은 MCP 레지스트리입니다. 문제의 일부(서버 수준)는 해결하지만, 전부(도구 수준 RBAC, 에이전트 수준 인벤토리)를 해결하지는 못합니다. MCPJungle — MCP 서버 검색 및 집계에 유용합니다. 접근 제어는 강제하지 않습니다. 당신의 에이전트가 존재한다는 것을 아는 것과 그것들을 통제하는 것은 다릅니다. 실패 #3: 공급자가 재채기하고 당신의 전체 제품이 감기에 걸린 날입니다 화요일 오후 2시 14분입니다. Anthropic에 장애가 발생했습니다. (또는 OpenAI. 또는 Google. 원하는 것을 고르세요.) 그들의 상태 페이지가 노란색으로 바뀝니다. 당신이 구축한 모든 에이전트가 단일 공급자에 의존합니다. 이들 모두가 한 번에 다운됩니다. 고객 지원 워크플로우가 멈춥니다.

내부 코딩 어시스턴트가 멈춥니다. 다음 주 이사회에서 할 멋진 데모는요? 그들이 503 에러를 좋아하길 바랍니다. 이것을 막아줄 게이트웨이가 필요합니다. 공급자 계층(provider layer)을 추상화하는 게이트웨이 말입니다. 당신의 에이전트는 Anthropic을 호출하지 않고, 당신의 게이트웨이를 호출합니다. 게이트웨이는 기본적으로 Anthropic을 호출하고, Anthropic에 문제가 생기면 자동으로 GPT나 Gemini로 폴백(fallback)합니다. TrueFoundry AI Gateway — 단일 자릿수 밀리초 오버헤드로 자동 크로스-공급자 장애 조치(Automatic cross-provider failover)를 지원하는 도구입니다. 기본 공급자에 문제가 생겨도, 모니터링 시스템이 누군가에게 페이지를 보내기 전에 요청을 우회시킵니다. 제가 이야기 나눈 여러 팀들은 이 기능 하나만으로도 전체 플랫폼 가치가 있다고 말했습니다. OpenRouter — 견고한 관리형 멀티 모델 액세스를 제공하며 일부 장애 조치를 지원합니다. 다만, 마크업(markup)이 있는 호스팅 서비스이며, 자체 호스팅은 불가능하고 엔터프라이즈 레벨의 거버넌스(governance)를 위해 설계된 것은 아닙니다. LiteLLM — 다중 공급자 라우팅을 처리하는 오픈 소스 프록시입니다. 소규모 설정에는 괜찮지만, 프로덕션 환경의 거버넌스를 위해서는 더 많은 노력이 필요합니다. 실패 #4: 답변에 3주가 걸린 감사 질문 내부 감사자가 정중한 이메일을 보냅니다. "현재 조직에 배포된 모든 AI 에이전트 목록, 각 에이전트가 접근할 수 있는 데이터, 그리고 3월 8일부터 3월 15일까지 고객 대면 챗봇의 전체 활동 로그를 제공해 주시겠습니까?" 만약 게이트웨이가 있다면: 5분 안에 CSV 파일을 내보낼 수 있습니다.

만약 게이트웨이가 없다면: 에이전트는 여덟 개 팀의 리포지토리에 흩어져 있고, MCP 연결은 세 개의 클라우드 계정에 여기저기 흩어져 있으며, 로깅은 '아마 Datadog에 좀 있을 거예요?' 정도이고, 여러분은 이제 3주간의 포렌식 고고학을 해야 합니다. 무엇이 이 모든 것을 막았을까요? 모든 에이전트 활동의 단일 병목 지점(single chokepoint) 역할을 하는 통합 게이트웨이입니다. 모든 LLM 호출, 모든 도구 사용(tool invocation), 모든 MCP 요청 — 중앙에 로깅되고, 쿼리 가능하며, 내보내기 가능합니다. TrueFoundry가 필요로 하는 기능들 — SOC 2, HIPAA, ITAR 준수. LLM 호출과 MCP 도구 사용 전반에 걸친 중앙 집중식 로그. 데이터 거주성 요구사항을 위한 VPC 배포. '감사 보고서 컴파일' 작업이 '한 달간의 일정 비우기'에서 '점심 식사 후에 전달해 드리겠습니다'로 바뀝니다. Datadog / Splunk — 시간, 예산, 그리고 작은 군대를 갖춘다면 물론 직접 구축할 수 있습니다. 하지만 대부분의 팀은 그렇지 못합니다. Docker MCP Gateway — 컨테이너 격리(Container isolation)는 어느 정도 보안 경계를 제공하지만, 감사 로그나 RBAC(Role-Based Access Control) 같은 기능은 주된 목적이 아닙니다. 실패 사례 #5: 이메일을 보내기로 결정한 고객 서비스 에이전트 에이전트의 임무: 사람이 검토하고 보낼 이메일 답장 초안 작성. 누군가 시스템 프롬프트(system prompt)를 '어조 개선'으로 업데이트하면서

Legal 팀이 합류합니다. [MEME PLACEHOLDER: '의심하려면 X를 누르세요'이지만 X가 보내기 버튼으로 대체됨. 캡션: '12,000명의 수신자에게 정말 보내시겠습니까?'] 이것을 막았을 것은 무엇일까요? 여기서 얻을 교훈은 미묘하고 중요합니다. 프롬프트는 보안 경계가 아닙니다. 에이전트가 'X를 하지 않아야 한다'고 인코딩하는 모든 것은 부주의한 편집으로부터 재앙과 거리가 멀지 않습니다. 해결책은 프롬프트 편집이 닿을 수 없는, 게이트웨이 수준에서 외부적으로 중요한 제약 조건을 강제하는 것입니다. 이메일을 보내려면 인간의 승인이 필요합니다 (프롬프트가 아닌 게이트웨이에서 강제). 고객 기록을 수정하려면 인간의 승인이 필요합니다 돈에 관련된 모든 것은 두 번의 승인이 필요합니다 에이전트의 프롬프트가 '이메일을 보내라'고 말해도, 게이트웨이는 '아니요, 초안만 작성할 수 있습니다. 전송하기 전에 사람이 승인해야 합니다'라고 말하는 것입니다. 끝. 도움이 되는 도구들 TrueFoundry — 게이트웨이 수준에서의 액션 레벨 가드레일 및 정책 강제. 정책은 프롬프트가 아닌 인프라에 존재합니다. 엔지니어가 실수로 시스템 프롬프트를 덮어쓰더라도, 그 규칙('인간 승인 필요')은 애초에 프롬프트 안에 있지 않기 때문에 실수로 제거할 수 없습니다. Operant AI — 행동 모니터링 및 위협 탐지. 일탈적인 행동을 포착하는 데 유용합니다. 예방적 통제는 아닙니다. Lasso Security — 비슷한 상황입니다. 탐지에는 강하지만, 예방에는 약합니다.

실패 모드 요약표
TrueFoundry Helicone Obot AI OpenRouter Operant AI
Runaway loop / cost blowup ✅ Prevents ⚠️ Detects ❌ ❌ ❌
Shadow agent with too much access ✅ Prevents ❌ ⚠️ Partial ❌ ❌
Provider outage takes everything down ✅ Prevents ❌ ❌ ⚠️ Partial ❌
Audit question, 3-week answer ✅ Prevents ⚠️ Partial ❌ ❌ ❌
Rogue agent actions ✅ Prevents ❌ ❌ ❌ ⚠️ Detects
그래서 무엇이 핵심인가? 이 실패 사례들은 에이전트를 프로덕션 환경에서 운영하는 모든 회사에서 발생했거나, 현재 발생하고 있거나, 곧 발생할 것입니다. 패턴은 변하지 않습니다: 에이전트는 빠르게 출시됩니다. 거버넌스는 결코 출시되지 않습니다. 게이트웨이는 관료주의가 아닙니다. 그것은 건물이 불타는 것을 막아주는 에이전트들이 플러그를 꽂는 벽 콘센트입니다. TrueFoundry는 단일 제어 평면(single control plane)에서 이 다섯 가지 모든 문제를 다루기 때문에 우리가 계속 돌아오는 곳입니다: 게이트웨이, 레지스트리(registry), RBAC, 관측 가능성(observability), 장애 조치(failover), 가드레일(guardrails). 다른 도구들은 일부 조각만 해결합니다. 무엇을 선택하든, 무언가를 선택하세요. 그리고 LLM 청구서가 5자리 숫자에 도달하여 당신이 사후 분석 보고서를 작성하기 전에 그것을 선택하세요.