Gateway에 제어 레이어 추가 시 디버깅 복잡도가 증가함

Context

AI Gateway는 모델 제공업체 앞에 위치하여 policy enforcement, traffic shaping, retries, failover, quotas 등의 역할을 함. Gateway가 실제 결정을 내리기 시작하면 더 이상 단순 프록시가 아니라 production control plane의 일부가 됨. 기존 direct-to-provider 방식에서는 요청 흐름이 짧지만, Gateway 도입 시 동일한 요청이 policy check, quota guardrail, route selection, retry branch, failover path 등 여러 단계를 거침.

Technical Solution

• Trace 구조 정의: gateway request → policy check → route selection → quota/budget rule → failover or retry branch → downstream provider call → response + trace metadata 형태로 요청 흐름을 구조화함
• Observability 필드 설계: route_reason, selected_provider, selected_model, retry_count, failover_used, tenant_id, trace_id, latency by step, cost by step 등을 포함하는 response record를 정의함
• 결정 메타데이터 캡처: 선택된 제공업체, 모델 선택 이유, quota 적용 여부, tenant context 등을 요청 lineage에 기록함
• 문제 분리 가능성 확보: provider latency와 gateway retry 동작을 별도로 식별할 수 있도록 각 단계별 메타데이터를 분리함

Impact

단순 provider logging만으로는 premium customer의 잘못된 모델 라우팅, backup provider로 전환 후 복귀 실패, policy rollout에 따른 특정 세그먼트 지연 증가, retries로 인한 비용 증가 등의 문제를 설명하기 어려움. Gateway 결정 자체가 가시화되면 control plane 문제와 provider 문제를 명확히 분리할 수 있음.

Key Takeaway

AI Gateway는 black box가 아니라 workflow로 취급해야 함. 요청 경로 전체에 걸쳐 각 결정 단계를 명시적으로 추적해야 production 환경에서 "Did the request finish?"가 아닌 "Why did it take this path?"라는 질문에 답변할 수 있음.