엔터프라이즈 계약을 3주 앞두고, 보이스 에이전트는 운영 준비가 되어 있지 않았다

보세요. 우리는 스테이징 (staging) 환경에서 99.2%의 업타임 (uptime)을 유지했습니다. 1,400개의 테스트 턴 (test turns)에 대한 평가 커버리지 (eval coverage)를 확보했습니다. 첫 번째 토큰 (first-token) 지연 시간 (latency)은 280ms 미만이었습니다.

하지만 우리는 운영 준비가 되어 있지 않았습니다.

제가 이 사실을 아는 이유는 엔터프라이즈 파일럿 (pilot)이 월요일에 시작되었고, 화요일 오후에 첫 번째 심각한 장애 (critical incident)가 발생했기 때문입니다.

이 글은 어떤 일이 일어났는지, 무엇이 고장 났는지, 그리고 이를 빠르게 해결해야 한다는 압박 속에서 게이트웨이 레이어 (gateway layer)에 대한 결정이 실제로 어떻게 이루어지는지에 대해 다룹니다.

장애 발생 (The incident)

고객사는 자산 관리 기업이었습니다. 그들의 어드바이저 (advisors)들은 고객 포트폴리오 데이터를 추출하고, 자산 배분 질문에 답하며, 후속 일정을 잡기 위해 보이스 에이전트 (voice agent)를 사용합니다. 우리는 6주 동안 합성 페르소나 (synthetic personas)를 사용하여 테스트를 진행해 왔습니다. 시뮬레이션 결과는 깨끗했습니다.

첫째 날: 한 시니어 어드바이저가 대규모 포트폴리오 가치를 포함한 세 번의 연속적인 자산 배분 쿼리 (allocation queries)가 포함된 세션을 실행했습니다. 미국 동부 표준시 (EST) 오후 6시, 즉 어드바이저 사용량이 가장 많은 피크 타임에 우리의 OpenAI 속도 제한 (rate limit)에 걸렸습니다. 제한 이후의 모든 요청은 429 에러를 반환했습니다. 에이전트는 아무런 유용한 로그도 남기지 않았습니다. 어드바이저의 고객은 4분 동안 대기 상태로 방치되었습니다.

둘째 날: 컴플라이언스 담당자 (compliance officer)가 첫째 날의 장애에 대한 감사 로그 (audit log)를 추출하려고 시도했습니다. 로그는 없었습니다. 우리에게는 트레이스 스팬 (trace spans)은 있었지만, 어떤 어드바이저가, 어떤 고객 컨텍스트 (client context)에서, 어떤 도구 호출 (tool calls)을 했으며, 에이전트가 무엇이라고 응답했는지를 보여주는 요청별 로그 (per-request log)는 없었습니다. 이는 모니터링 (monitoring)의 문제가 아니라 컴플라이언스 (compliance)의 공백이었습니다.

둘째 주: 운영 부문 부사장 (VP of operations)이 팀별 비용 내역을 요청했습니다. 우리는 그들에게 단일 숫자만을 제공했습니다. 그들은 어드바이저별 귀속 (per-advisor attribution) 정보를 원했습니다. 우리에게는 테넌트별 태깅 (per-tenant tagging) 기능이 없었습니다.

셋째 주: 운영 팀이 말투 문제를 해결하기 위해 새로운 프롬프트 (prompt) 버전을 배포했습니다. 3시간 후, 보이스 에이전트는 이전에는 문제없이 처리했던 특정 자산 배분 질문들을 거부하기 시작했습니다. 우리는 트레이스 (trace) 상에서 추론 (inference) 시점에 고정된 프롬프트 버전을 확인할 수 없었습니다. 실패가 언제 시작되었는지, 어떤 요청들이 영향을 받았는지 알 수 없었습니다.

네 번의 장애. 그 중 어느 것도 모델 품질 (model quality) 문제는 아니었습니다. 모두 우리가 구축하지 않았던 게이트웨이 레이어 (gateway layer)의 문제였습니다.

게이트웨이 레이어 (gateway layer)가 수행해야 하는 역할

이번 파일럿 (pilot)을 진행하기 전까지, 나는 게이트웨이를 라우팅 (routing) 정도로 생각했습니다. 요청을 OpenAI, Anthropic, 혹은 다른 어떤 제공업체로 보낼지 결정하고, 재시도 (retries)를 처리하는 것. 그것으로 끝이라고 생각했습니다.

하지만 그것은 틀렸습니다.

엔터프라이즈 운영자 배포 (operator deployment)를 위한 게이트웨이는 최소한 다섯 가지 일을 수행해야 합니다:

테넌트 (tenant)별 속도 제한 (Rate limiting). 계정 (account) 단위가 아니라 테넌트 단위여야 합니다. 사용량이 많은 상담사가 전체 배포 환경의 속도 제한을 초과해버려서는 안 됩니다.

비용 귀속 (Cost attribution). 모든 요청에는 운영자, 팀, 사용자가 태그로 지정되어야 합니다. 이것이 없다면, 운영 2개월 차에 들어오는 비용 귀속 관련 질문에 답할 수 없습니다.

가드레일 (Guardrail) 적용. 금융 서비스의 경우: 특정 투자 권유처럼 들리는 조언은 금지해야 합니다. 가드레일은 단순히 잊지 않고 추가할 때만 작동하는 것이 아니라, 모든 응답에 대해 실행되어야 합니다.

감사 로그 (Audit logging). 상호작용을 재현할 수 있을 만큼 충분한 컨텍스트 (context)를 포함하며, 요청별로 생성되는 불변 (immutable) 로그여야 합니다. 이는 대부분의 규제 산업에서 '있으면 좋은 기능'이 아니라 준수해야 하는 규정 사항 (compliance requirement)입니다.

멀티 제공업체 페일오버 (Multi-provider failover). OpenAI가 429 에러를 발생시키면 Anthropic으로 라우팅해야 합니다. 수동 개입이 아니라 자동으로 이루어져야 합니다. 첫날 발생했던 4분간의 장애는 예방 가능한 것이었습니다.

내가 평가한 것들

첫째 주가 끝난 후, 나는 주말 대부분을 할애하여 게이트웨이 옵션들을 평가했습니다. 솔직한 분석은 다음과 같습니다:

LiteLLM (오픈 소스, 셀프 호스팅). 완전한 제어권을 원한다면 가장 완벽한 기능 세트를 제공합니다. 테넌트별 속도 제한, 비용 태깅, 제공업체 폴백 (fallback), 프록시 모드 (proxy mode) 등을 지원합니다. 다만 설정 복잡성이 실재합니다. 배포 환경을 유지 관리해야 하고, 속도 제한 영속성을 위해 Redis를 구성해야 하며, 자체적인 감사 로그 스키마 (audit log schema)를 작성해야 합니다. 이미 Kubernetes 인프라를 갖춘 팀에게는 아마도 올바른 선택일 것입니다. 하지만 우리는 파일럿 진행 중이었고 더 빠른 설정이 필요했습니다.

Portkey (managed). 설정이 필요 없는 가드레일 (Zero-config guardrails), 롤백 UI를 갖춘 내장형 프롬프트 버전 관리 (prompt versioning), 견고한 멀티 프로바이더 라우팅 (multi-provider routing)을 제공합니다. 규모가 커지면 비용이 비싸지지만, 매니지드 (managed) 모델이기에 빠른 설정과 운영 오버헤드 (ops overhead) 감소가 가능합니다. 이들의 가드레일 정책은 LiteLLM의 기본 기능보다 더 구성 가능성이 높습니다. 우리는 시간 압박을 받고 있었고 설정이 필요 없는 가드레일 강제 적용이 필요했기 때문에 파일럿을 위해 이곳을 선택했습니다.

Future AGI's gateway (open-source, future-agi 플랫폼의 일부). 이는 그들의 엔드 투 엔드 (end-to-end) 평가 (eval) + 관측성 (observability) + 가드레일 (guardrail) 스택의 게이트웨이 구성 요소입니다. 가드레일 정책, 속도 제한 (rate limiting), 그리고 플랫폼의 나머지 부분과 동일한 OTel 기반 관측성 스택에 연결되는 OTel 네이티브 트레이싱 (OTel-native tracing)을 통해 멀티 프로바이더 라우팅을 처리합니다. 우리가 이미 음성 평가 하네스 (voice eval harness)를 위해 FAGI의 시뮬레이션 툴링을 실행 중이었고, 가드레일, 트레이싱, 평가가 모두 동일한 FAGI 플랫폼을 통해 실행되는 통합 스택이 매우 매력적이었기에 이를 구체적으로 평가했습니다.

평가와 시뮬레이션을 위해 이미 FAGI 플랫폼을 사용 중인 팀에게 게이트웨이는 적절한 다음 단계입니다. FAGI 툴링 없이 처음 도입하는 팀에게는 첫 운영 배포 시 Portkey나 Helicone보다 설정 비용이 더 높습니다.

2026년 6월 기준으로, FAGI 게이트웨이는 OpenAI 호환 프록시 (proxy), 멀티 프로바이더 라우팅, 가드레일 정책, 그리고 OTel 트레이싱을 하나의 스택으로 제공합니다.

Helicone (managed). 비용 귀속 (cost attribution) 및 사용자별 분석 (per-user analytics) 측면에서 가장 강력합니다. 태깅 (tagging) 시스템이 세밀하며 대시보드가 읽기 쉽습니다. 가드레일 측면에서는 다소 약합니다 (Portkey보다 구성 가능성이 낮음). 주요 요구 사항이 FinOps 가시성이고 가드레일을 별도로 처리하고 있다면 올바른 선택입니다.

OpenRouter (managed). 순수 라우팅 (routing) 서비스입니다. 멀티 프로바이더 폴백 (multi-provider fallback)을 지원하며, 프로바이더 간 지연 시간 (latency) 최적화에 좋습니다. 테넌트별 속도 제한 (per-tenant rate limiting)이나 내장된 가드레일 강제 기능은 없습니다. 컴플라이언스 (compliance) 기능이 필요한 엔터프라이즈 배포에는 적합한 선택이 아닙니다.

Bifrost (open-source). 흥미로운 성능 수치를 보여주는 빠른 프록시 (proxy)입니다. 더 최신이며 커뮤니티 규모는 더 작습니다. 제가 직접 평가해 본 결과, 지연 시간 (latency)에 대한 이야기는 사실이었습니다. 하지만 규제 산업 (regulated industry) 배포를 위해 확정하기에는 너무 최신 기술이었습니다.

3주 차: 우리가 해결한 것들

3주 차에 이르러 우리는 이미 속도 제한 (rate limiting) 및 가드레일 강제 (guardrail enforcement)를 위해 Portkey를 배포한 상태였습니다. 우리는 모든 요청에 어드바이저별 태깅 (per-advisor tagging)을 추가했습니다. 추론 (inference) 시점에 프롬프트 버전을 고정 (pinned)하였고, 각 트레이스 스팬 (trace span)에 버전 ID를 기록했습니다.

프롬프트 버전 사고는 버전 고정 (version pinning)이 되어 있었다면 즉시 포착되었을 것입니다. 비용 귀속 (cost-attribution) 요청은 두 개의 SQL 쿼리로 답변할 수 있었을 것입니다.

감사 로그 (audit log) 구축에는 더 오랜 시간이 걸렸습니다. 금융 서비스의 감사 로깅 (audit logging)은 일반적인 트레이스 시스템 (trace systems)이 기본적으로 충족하지 못하는 특정 보존 (retention) 및 불변성 (immutability) 요구 사항을 가지고 있습니다. 우리는 Portkey의 로깅 위에 컴플라이언스 (compliance) 사양을 충족하는 얇은 쓰기 전용 (write-once) 레이어를 구축했습니다. 이는 파일럿 (pilot) 시작 전에 완료했어야 할 이틀 치의 작업이었습니다.

출시된 기능 (What shipped)

속도 제한 (rate limiting) 및 가드레일 강제 (guardrail enforcement)를 위한 Portkey. 모든 요청에 대한 테넌트별 태깅 (per-tenant tagging). 추론 (inference) 시점의 프롬프트 버전 고정 (prompt version pinning). 컴플라이언스를 위한 맞춤형 감사 로그 (audit log) 레이어.

속도 제한 (rate-limit) 사고는 재발하지 않았습니다. 비용 귀속 (cost-attribution) 질문에 답변하는 데 이제 2분이 소요됩니다. 감사 로그는 컴플라이언스를 충족합니다.

과거의 나에게 해주고 싶은 말

엔터프라이즈 고객과 대화하기 전에 게이트웨이 (gateway)를 설계하세요. 파일럿이 한계에 부딪히기 시작할 때 사후 고려 사항으로 처리하지 마세요.

첫 달에 받게 될 질문들은 다음과 같습니다: "누가, 언제, 무엇을 하여, 어떤 결과로, 얼마를 썼는가." 만약 당신의 게이트웨이가 이 네 가지 질문에 답하지 못한다면, 당신은 운영 준비 (operator-ready)가 되지 않은 것입니다. 모델 품질은 아마 괜찮을 것입니다. 당신을 괴롭힐 것은 그 주변의 인프라 (infrastructure)입니다.

만약 당신이 이미 FAGI의 평가(eval) 및 시뮬레이션 스택(simulation stack)을 실행하고 있다면, 그들의 게이트웨이(gateway) 컴포넌트를 병렬로 평가하십시오. 가드레일(guardrails), 트레이스(traces), 그리고 평가 신호(eval signals) 간의 통합 데이터 모델(unified data model)은 평가 커버리지(eval coverage)와 연결되는 감사 추적(audit trail)이 필요한 규제 대상 배포(regulated deployments) 환경에서 진정으로 유용합니다.

제가 다음에 구축하고 있는 것: 모든 엔터프라이즈 인도(enterprise handoff) 전에 CI 게이트(CI gate)로서 실행되는 운영 전 준비 체크리스트(pre-operator readiness checklist)입니다. 이는 테넌트별 속도 제한(per-tenant rate limit) 설정, 감사 로그 스키마 커버리지(audit log schema coverage), 그리고 프롬프트 버전 추적(prompt version tracking)을 점검합니다. 이 중 그 어느 것도 수동으로 이루어져서는 안 됩니다.