AWS가 Amazon Bedrock AgentCore에서 LiteLLM을 퍼스트 클래스 모델 제공자로 만들었습니다

AWS가 Amazon Bedrock AgentCore harness를 정식 출시(Generally Available)했습니다. 그리고 모델 설정 문서 속에 주의 깊게 살펴볼 만한 내용이 숨겨져 있습니다.

LiteLLM이 이제 AgentCore에서 공식적으로 지원되는 4가지 모델 제공자(Model Provider) 유형 중 하나가 되었습니다. Bedrock, OpenAI, Gemini와 나란히 자리 잡았습니다.

커뮤니티 플러그인도 아니고, 임시 방편(Workaround)도 아닙니다. CreateHarness API 내의 정식 liteLlmModelConfig입니다.

AgentCore Harness란 무엇인가

간단한 배경 설명입니다. AgentCore harness는 프로덕션 AI 에이전트를 실행하기 위한 AWS의 관리형 추상화(Managed Abstraction) 계층입니다. 에이전트를 정의하고, 모델과 도구(Tools)를 지정하면 AWS가 샌드박스 환경(Sandboxed Environment), 메모리, ID, 그리고 관찰 가능성(Observability)을 처리합니다.

두 번의 API 호출이면 충분합니다. 에이전트를 정의하는 CreateHarness, 그리고 이를 실행하는 InvokeHarness. 그게 전부입니다.

흥미로운 부분은 모델 설정입니다. 네 가지 옵션을 제공합니다:

• Bedrock 모델을 위한 bedrockModelConfig
• OpenAI 직접 연결을 위한 openAiModelConfig
• Google Gemini를 위한 geminiModelConfig
• 그 외 모든 것을 위한 liteLlmModelConfig

마지막 옵션이 매우 유용합니다.

AgentCore에서 LiteLLM 사용하기

liteLlmModelConfig를 사용하면 LiteLLM이 지원하는 모든 제공자에게 접근할 수 있습니다. modelId를 LiteLLM 제공자 접두사가 붙은 모델 ID로 설정하기만 하면 됩니다.

다음은 AWS CLI 버전입니다:

aws bedrock-agentcore-control create-harness \
  --harness-name my-agent \
  --execution-role-arn arn:aws:iam::123456789:role/MyAgentRole \
...

이것은 Bedrock의 모델 카탈로그를 통하지 않고, Anthropic의 API를 통해 Claude를 직접 사용하는 에이전트를 생성합니다. 동일한 모델을 사용하면서도 잠재적으로 다른 가격 정책을 적용받을 수 있으며, Bedrock 전용 모델 ID에 종속되지 않습니다.

대신 Azure OpenAI를 사용하고 싶으신가요?

--model '{
  "liteLlmModelConfig": {
    "modelId": "azure/gpt-4o",
...

또는 직접 호스팅하는 LiteLLM 프록시(Proxy)를 지정할 수도 있습니다:

--model '{
  "liteLlmModelConfig": {
    "modelId": "litellm_proxy/claude-haiku",
...

마지막 예시가 가장 강력합니다. LiteLLM을 프록시 (proxy)로 배포하고, 모든 모델, 지출 한도 (spend limits), 속도 제한 (rate limiting), 폴백 (fallbacks)을 그곳에서 설정한 다음, AgentCore가 이를 가리키도록 설정하면 됩니다. 그러면 여러분의 에이전트들은 LiteLLM의 모든 라우팅 로직 (routing logic)을 무료로 얻게 됩니다.

이것이 중요한 이유

여기서 몇 가지 눈에 띄는 점이 있습니다.

첫째, AWS는 LiteLLM을 구체적으로 "그 외 모든 것 (everything else)" 제공자로 통합하기로 선택했습니다. 단순한 OpenAI 호환 심 (shim)이나 사용자가 직접 어댑터를 가져오는 패턴 (bring-your-own-adapter pattern)이 아닙니다. 이를 위해 전용 설정 유형 (config type)을 구축했습니다.

둘째, apiBase 필드를 통해 여러분의 VPC 내부에서 자체 LiteLLM 게이트웨이 (gateway)를 실행하고 AgentCore 에이전트가 이를 사용하게 할 수 있습니다. 지출 추적 (spend tracking), 팀 예산, 모델 폴백 (model fallbacks), 가드레일 (guardrails) 등 모든 기능이 그대로 작동합니다. AgentCore는 에이전트 오케스트레이션 (agent orchestration)을 담당하고, LiteLLM은 모델 라우팅 (model routing)을 담당합니다.

셋째, 동일한 세션 내에서 턴 (turn) 사이에 제공자를 전환해도 대화가 계속 유지됩니다. 호출 (invocation) 단위로 모델 설정을 재정의할 수 있습니다. 빠른 모델로 작업을 시작하고, 에이전트에게 더 깊은 추론 (reasoning)이 필요할 때 더 강력한 모델로 전환하십시오. LiteLLM의 제공자 접두사가 붙은 모델 ID (provider-prefixed model IDs) 덕분에 이 작업은 매우 간단합니다.

셀프 호스팅 프록시 패턴 (The Self-Hosted Proxy Pattern)

이미 운영 환경에서 LiteLLM을 실행 중이라면, 통합 패턴은 매우 간단합니다:

1. AWS 환경 (ECS, EKS, EC2 등)에 LiteLLM 프록시를 배포합니다.
2. config.yaml에 필요한 모든 제공자를 포함하여 모델 목록을 구성합니다.
3. AgentCore Identity에 LiteLLM 가상 API 키를 자격 증명 제공자 (credential provider)로 저장합니다.
4. apiBase를 프록시 엔드포인트 (endpoint)로, modelId를 litellm_proxy/<your-model-name>으로 설정합니다.

이제 여러분의 AgentCore 에이전트는 LiteLLM을 통해 라우팅됩니다. 모든 에이전트에 걸친 통합된 지출 추적, 팀 또는 키별 속도 제한, 제공자 장애 시 폴백 체인 (fallback chains), 그리고 완전한 관측성 (observability)을 확보할 수 있습니다.

빠른 설정

지금 바로 시도해보고 싶다면:

# AgentCore CLI 설치
npm install -g @aws/agentcore@preview

...

모델 설정에 관한 AWS 문서에서 liteLlmModelConfig에 대한 전체 참조 정보를 확인할 수 있습니다.

지원되는 제공자(supported providers)에 대한 LiteLLM 자체 문서에는 사용할 수 있는 모든 모델 ID 형식이 나열되어 있습니다.

결론 (Bottom Line)

AWS가 LiteLLM을 AgentCore에 퍼스트 클래스 통합(first-class integration)으로 구축한 것은 강력한 신호입니다. 이는 제공업체에 관계없이 동일한 API를 사용하는 통합 모델 게이트웨이(unified model gateway)를 갖추는 접근 방식이 타당함을 입증합니다.

AWS에서 에이전트를 구축 중이며 Bedrock의 카탈로그 외부에 있는 모델에 접근해야 하거나, 비용 제어 및 폴백(fallbacks) 기능이 포함된 자체 프록시 계층(proxy layer)을 원하는 경우, LiteLLM 통합이 가장 깔끔한 경로입니다.

AgentCore Harness 문서 | LiteLLM GitHub | AWS 발표 블로그