AI 애플리케이션은 더 이상 하나의 모델을 중심으로 구축되지 않습니다.

챗봇은 빠른 응답을 위해 하나의 모델이, 추론 (Reasoning)을 위해 또 다른 모델이, 그리고 다국어 지원을 위해 또 다른 모델이 필요할 수 있습니다. RAG (Retrieval-Augmented Generation) 애플리케이션은 채팅 모델, 임베딩 (Embeddings), 리랭킹 (Reranking), 그리고 폴백 (Fallback) 옵션이 필요할 수 있습니다. AI 에이전트 (AI Agent)는 계획 (Planning), 도구 사용 (Tool use), 그리고 구조화된 출력 (Structured output)을 위해 서로 다른 모델이 필요할 수 있습니다.

동시에, 개발자들은 GPT, Claude, Gemini와 같은 글로벌 모델뿐만 아니라 DeepSeek, Qwen, Kimi, GLM, MiniMax, Doubao 등 중국의 프런티어 (Frontier) 모델들도 탐색하고 있습니다.

이는 실제 인프라 문제를 야기합니다:

애플리케이션을 특정 제공업체별 통합 코드의 더미로 만들지 않고, 어떻게 수많은 AI 모델에 접근하고, 관리하고, 모니터링하며, 최적화할 수 있을까요?

모델 계층은 인프라가 되어가고 있습니다

단순한 프로토타입에서는 하나의 API 키와 하나의 모델만으로 충분할 수 있습니다.

하지만 실제 서비스용(Production) AI 앱은 보통 더 많은 것을 필요로 합니다:

• 다중 모델 선택지
• 신뢰할 수 있는 모델 접근성
• 요청 로그 (Request logs)
• 토큰 사용량 추적 (Token usage tracking)
• 과금 가시성 (Billing visibility)
• 모델 라우팅 (Model routing)
• 폴백 동작 (Fallback behavior)
• 비용 제어 (Cost control)
• 워크플로 수준의 모니터링 (Workflow-level monitoring)

이것이 바로 모델 접근이 인프라 계층이 되어가고 있는 이유입니다.

애플리케이션은 모든 제공업체의 세부 사항을 알 필요가 없어야 합니다. 제품 코드는 특정 기능 (Capability)을 요청해야 하며, 인프라 계층이 어떤 모델, 경로, 정책을 사용할지 결정해야 합니다.

예를 들어:

text
AI application
...