SageMaker OpenAI API 지원, AWS 모델 배포의 새 선택지

AWS가 2026년 5월 20일 Amazon SageMaker AI 실시간 inference endpoint에 OpenAI-compatible API 지원을 추가했습니다. 발표문은 OpenAI SDK, LangChain, Strands Agents 사용자가 custom client, SigV4 wrapper, code rewrite 없이 SageMaker endpoint를 호출할 수 있다고 설명합니다. 바뀌는 부분은 모델 자체보다 호출 계약입니다. 기존 앱이 client.chat.completions.create()를 중심으로 짜여 있다면 base_url과 인증 token을 바꿔 AWS 계정 안의 endpoint를 겨냥할 수 있습니다.

AWS What's New 공지는 하루 뒤인 2026년 5월 21일 같은 기능을 제품 availability로 정리했습니다. 적용 region에는 US East, US West, Europe, Canada, South America와 함께 Asia Pacific Seoul도 들어 있습니다. 한국 팀이 이 기능을 볼 때 새 모델 출시보다 실무적인 부분은 데이터 경계와 배포 경계입니다. POC는 OpenAI API로 빨리 만들고, production inference는 VPC, IAM, CloudWatch, autoscaling이 붙은 SageMaker endpoint로 옮기는 선택지가 생겼습니다.

호출 경로는 단순합니다. SageMaker docs는 real-time inference endpoint가 /openai/v1/chat/completions path를 노출한다고 적습니다. AWS blog는 이를 더 짧게 /openai/v1 경로로 설명합니다. 실제 OpenAI Python SDK 예시는 다음과 같은 base URL을 사용합니다.

from openai import OpenAI
from sagemaker.core.token_generator import generate_token

REGION = "us-west-2"
sme_base_url = (
    f"https://runtime.sagemaker.{REGION}.amazonaws.com"
    f"/endpoints/{SME_ENDPOINT_NAME}/openai/v1"
)

client = OpenAI(
    base_url=sme_base_url,
    api_key=generate_token(region=REGION),
)

이 코드에서 model field는 endpoint routing의 중심이 아닙니다. SageMaker는 URL 안의 endpoint name으로 request를 route하고, model field는 container로 pass-through됩니다. AWS docs는 비워 두거나 container가 기대하는 model name으로 맞추면 된다고 설명합니다. OpenAI API 클라이언트가 model name을 route key로 쓰던 구조와 다르게, SageMaker에서는 endpoint와 inference component가 AWS resource 경계를 먼저 결정합니다.

인증은 API 호환성의 숨은 절반입니다. OpenAI API key처럼 보이는 문자열을 넘기지만, SageMaker의 bearer token은 SageMaker Python SDK의 generate_token이 기존 AWS credentials로 만든 base64-encoded SigV4 pre-signed URL입니다. 기본 유효 시간은 12시간이고 expiry를 쓰면 1초부터 12시간 사이로 줄일 수 있습니다. token 생성은 client-side signing이라 생성 시점에 별도 network call이 없습니다.

이 설계는 편하지만 보안팀이 읽어야 할 문장도 같이 붙습니다. AWS docs는 bearer token이 underlying AWS credentials와 같은 authorization을 가진다고 적습니다. token을 만든 role이 넓으면 token도 넓습니다. 그래서 sagemaker:InvokeEndpoint는 특정 endpoint ARN으로 좁히고, AdministratorAccess나 AmazonSageMakerFullAccess 같은 expansive permission에서 token을 만들지 말라고 권합니다. sagemaker:CallWithBearerToken은 resource-level restriction을 지원하지 않아 Resource: "*"가 필요하다는 단서도 있습니다.

token storage도 단순 API key처럼 다루면 위험합니다. AWS는 token을 disk, environment variable, config file, database, distributed cache에 저장하지 말고 log에도 남기지 말라고 안내합니다. long-running app에서는 httpx.Auth 같은 auto-refresh pattern으로 request마다 fresh token을 만들 수 있습니다. OpenAI-compatible이라는 표현이 인증까지 OpenAI 방식으로 바꾼다는 뜻은 아닙니다. 개발자는 OpenAI client를 쓰지만, 운영 경계는 IAM role, endpoint ARN, credential chain이 결정합니다.

AWS가 내세운 첫 사용 사례는 agentic workflow입니다. Strands Agents나 LangChain으로 multi-step agent를 만들었다면 같은 OpenAI-compatible interface로 SageMaker endpoint를 부르고, inference는 고객 AWS 계정의 dedicated GPU instance에서 실행할 수 있습니다. Caffeine.AI의 AWS blog 인용은 더 직접적입니다. 회사가 Bifrost gateway로 여러 LLM provider를 쓰고 있으며, bearer token 기능 덕분에 SageMaker를 Vercel AI SDK와 standard OpenAI clients에 drop-in endpoint로 붙일 수 있다고 말했습니다.

둘째 사용 사례는 multi-model hosting입니다. SageMaker inference components를 쓰면 같은 endpoint 아래에 Llama, fine-tuned Mistral, smaller classification model 같은 여러 model component를 둘 수 있습니다. 각 component는 resource allocation을 따로 갖고, OpenAI SDK client는 URL path에 inference component name을 넣어 특정 component를 부릅니다. 앱 코드가 provider별 client를 직접 갈아끼우는 대신, endpoint와 component path가 routing 표면이 됩니다.

지원 container도 공개됐습니다. SageMaker AI vLLM Deep Learning Container와 SGLang Deep Learning Container가 supported이고, custom container도 OpenAI API path와 /ping을 구현하면 지원 대상입니다. AWS blog 예시는 Hugging Face의 Qwen/Qwen3-4B를 vLLM container로 배포하고 ml.g6.2xlarge instance를 사용합니다. 이 예시는 "OpenAI-compatible API"가 model provider API를 호출하는 기능이 아니라, AWS-hosted open model serving container 앞에 붙은 interface라는 점을 보여줍니다.

비용 구조는 API 표준화만 보고 건너뛰기 쉽습니다. AWS docs는 SageMaker AI endpoint가 traffic 유무와 관계없이 InService 상태에서 비용이 발생한다고 경고합니다. OpenAI API의 per-token billing에 익숙한 팀은 endpoint uptime, instance type, autoscaling, inference component allocation을 따로 계산해야 합니다. 짧은 POC에는 hosted API가 싸고, 지속 traffic이나 data residency 요구가 있는 production에는 dedicated endpoint가 맞을 수 있습니다. 이번 기능은 비용을 자동으로 낮추는 발표가 아니라 migration friction을 낮추는 발표입니다.

개발자 관점의 변화는 OpenAI API가 특정 회사의 API를 넘어 agent runtime의 공통 wire format이 됐다는 점입니다. vLLM과 SGLang은 이미 OpenAI-compatible server를 중요한 selling point로 삼았습니다. OpenRouter, LiteLLM, Portkey, Vercel AI Gateway 같은 gateway도 이 호환성을 전제로 provider routing을 설계합니다. SageMaker가 endpoint path에 /openai/v1을 추가한 것은 AWS가 이 ecosystem을 우회하지 않고 흡수하겠다는 선택입니다.

Bedrock과의 구분도 중요합니다. Bedrock은 managed foundation model access, guardrails, agent service, marketplace integration에 가깝습니다. SageMaker는 customer-owned model artifact, custom container, dedicated endpoint, inference component 같은 낮은 운영 단위를 제공합니다. 이번 OpenAI-compatible endpoint는 Bedrock을 대체하는 발표가 아닙니다. fine-tuned open model, self-hosted vLLM/SGLang container, 내부 모델 serving을 OpenAI SDK 생태계에 붙이는 접점입니다.

에이전트 팀에는 gateway 구성이 더 단순해집니다. 예를 들어 앱은 OpenAI public API, Anthropic, Bedrock, local vLLM, SageMaker endpoint를 LiteLLM이나 Bifrost 같은 router 뒤에 둘 수 있습니다. 지금까지 SageMaker를 추가하려면 SigV4 wrapper 또는 provider-specific adapter가 필요했습니다. 이제는 SageMaker가 OpenAI-compatible endpoint로 들어오므로 router가 다루는 provider 수는 늘지만 client contract는 줄어듭니다. 장애 대응과 권한 감사에서는 그 차이가 큽니다.

반대로 lock-in이 사라졌다고 말하기에는 이릅니다. OpenAI-compatible API의 최소 공통분모는 Chat Completions와 streaming입니다. tool calling, structured output, multimodal input, embedding, batch, response metadata, safety filter semantics는 provider와 container 구현에 따라 달라집니다. AWS docs도 supported container가 /v1/chat/completions path와 SSE streaming response를 구현해야 한다고 씁니다. 앱이 OpenAI API의 세부 behavior에 깊게 기대고 있다면 URL만 바꿔 같은 결과를 얻는다고 가정하면 안 됩니다.

운영팀이 먼저 확인할 checklist는 네 가지입니다. 첫째, token을 생성하는 IAM role이 endpoint별 최소 권한인지 확인해야 합니다. 둘째, gateway나 agent runner가 token을 log에 남기지 않는지 봐야 합니다. 셋째, endpoint uptime 비용과 autoscaling policy를 traffic pattern에 맞춰야 합니다. 넷째, vLLM 또는 SGLang container가 앱이 쓰는 tool call, streaming, timeout, error shape를 실제로 맞추는지 regression test를 만들어야 합니다.

이번 발표는 일반 개발 가이드보다 AI infrastructure 뉴스에 가깝습니다. AWS가 OpenAI API를 "경쟁사 API"로만 보지 않고, LLM 앱이 이미 채택한 호출 문법으로 인정했기 때문입니다. 그 결과 SageMaker의 장점인 AWS account boundary, dedicated GPU, IAM, inference component가 OpenAI SDK 생태계와 더 가까워졌습니다. AI 앱 개발자는 모델 품질만 비교하는 대신, 같은 client code가 어디까지 이동 가능한지와 그 이동 뒤에 남는 권한, 비용, observability를 함께 비교하게 됩니다.