OpenAI 규격으로 열린 SageMaker, AWS가 접속층을 내준 이유

AWS가 SageMaker AI에 작은 문 하나를 냈습니다. 이름은 OpenAI 호환 API 지원입니다. 발표만 놓고 보면 "OpenAI SDK로 SageMaker 엔드포인트를 부를 수 있다"는 개발자 편의 기능처럼 보입니다. 하지만 이 변화가 가리키는 방향은 더 큽니다. 기업 AI 팀이 자체 모델과 자체 GPU, VPC, IAM 통제를 유지하려 할수록 애플리케이션 계층은 오히려 OpenAI식 인터페이스로 모이고 있다는 신호이기 때문입니다.

AWS 공식 블로그는 2026년 5월 20일, SageMaker AI 실시간 추론 엔드포인트가 OpenAI 호환 API를 지원한다고 발표했습니다. 핵심은 /openai/v1/chat/completions 경로입니다. OpenAI SDK, LangChain, Strands Agents 같은 도구를 쓰는 팀은 별도 클라이언트, SigV4 래퍼, 애플리케이션 코드 재작성 없이 엔드포인트 URL을 바꿔 SageMaker 모델을 호출할 수 있습니다. AWS 문서도 같은 내용을 더 운영 관점에서 정리합니다. SageMaker AI 엔드포인트와 inference component가 표준 SageMaker API와 SDK 위에서 OpenAI 호환 경로를 노출하고, 응답은 컨테이너가 반환한 형식 그대로 스트리밍까지 처리합니다.

이것은 AWS가 OpenAI에 굴복했다는 단순한 이야기가 아닙니다. 더 정확히는, 모델 제공자와 클라우드 제공자가 서로 다른 계층에서 싸우는 구조가 선명해졌다는 이야기입니다. 모델은 Qwen, Llama, Mistral, 사내 fine-tuned 모델일 수 있습니다. 런타임은 vLLM, SGLang, 커스텀 컨테이너일 수 있습니다. 클라우드는 AWS일 수 있습니다. 그런데 앱과 에이전트 프레임워크가 기대하는 접속 표면은 점점 "OpenAI Chat Completions처럼 말해 달라"로 좁혀지고 있습니다.

왜 URL 하나가 뉴스인가

생성형 AI 인프라에서 URL 하나를 바꾼다는 말은 자주 과장됩니다. 실제 운영에서는 인증, 스트리밍, 에러 형식, 모델 이름, tool call, 로깅, 비용 태깅, 권한 분리까지 맞아야 하기 때문입니다. 그래서 많은 팀이 "OpenAI 호환"이라는 문구를 보면서도 다시 프록시와 게이트웨이를 붙입니다. 이번 SageMaker 발표가 흥미로운 이유는 AWS가 이 접속층을 외부 우회로가 아니라 자체 실시간 추론 엔드포인트의 공식 경로로 넣었다는 점입니다.

공식 블로그의 예시는 명확합니다. 기존 OpenAI 클라이언트의 base_url을 SageMaker 런타임 주소로 바꾸고, api_key 자리에 SageMaker SDK가 생성한 bearer token을 넣습니다. URL은 대략 다음 구조입니다.

https://runtime.sagemaker.{REGION}.amazonaws.com/endpoints/{ENDPOINT_NAME}/openai/v1

Inference component를 쓸 때는 경로에 component 이름이 들어갑니다.

https://runtime.sagemaker.{REGION}.amazonaws.com/endpoints/{ENDPOINT_NAME}/inference-components/{IC_NAME}/openai/v1

이 경로가 중요한 이유는 에이전트 애플리케이션의 상위 계층을 거의 건드리지 않게 만들기 때문입니다. LangChain이나 Strands Agents, OpenAI SDK 기반 게이트웨이는 모델 호출을 이미 Chat Completions 형태로 추상화해 둔 경우가 많습니다. 이전에는 SageMaker 전용 InvokeEndpoint 호출, SigV4 서명, 컨테이너별 요청 변환을 애플리케이션 주변에 붙여야 했습니다. 이제는 SageMaker가 그 차이를 일부 흡수합니다.

이 흐름도는 공식 문서의 세 가지 사실을 압축합니다. 첫째, 경로는 Chat Completions 요청을 받습니다. 둘째, 인증은 SageMaker SDK의 token generator가 만든 bearer token을 씁니다. 셋째, 컨테이너는 /v1/chat/completions와 스트리밍 응답을 구현해야 합니다. 클라우드 런타임과 앱 프레임워크 사이에 있던 접속 어댑터가 점점 플랫폼 기능으로 내려가고 있는 셈입니다.

OpenAI API가 이긴 것이 아니라, 호환층이 이겼습니다

이번 발표를 "OpenAI API가 표준이 됐다"로만 읽으면 절반만 보는 것입니다. 실제로는 OpenAI의 특정 모델보다 OpenAI식 wire format이 강해졌습니다. 기업은 민감 데이터, 비용 구조, 규제, 지연 시간, GPU 예약, 사내 fine-tuning 때문에 자체 엔드포인트를 원합니다. 동시에 개발자는 에이전트 프레임워크와 LLM 게이트웨이, 평가 도구, 로그 도구가 기대하는 공통 인터페이스를 원합니다. 두 요구가 충돌할 때 중간 지점은 "모델은 내 계정에 두고, 호출 문법은 널리 쓰는 규격을 따른다"입니다.

AWS가 블로그에서 제시한 사용 사례도 그 지점을 향합니다. 첫째는 owned infrastructure 위의 agentic workflow입니다. 다단계 에이전트를 LangChain이나 Strands Agents로 만들되, 추론은 기업 계정의 전용 GPU 엔드포인트에서 돌리는 구조입니다. 둘째는 단일 인터페이스를 통한 multi-model hosting입니다. 일반 작업용 Llama, 도메인 특화 fine-tuned Mistral, 분류용 소형 모델을 inference component로 묶고 같은 OpenAI SDK로 호출하는 그림입니다. 셋째는 fine-tuned 모델을 앱 코드 변경 없이 제공하는 흐름입니다.

이 세 가지는 모두 "모델 다양성"과 "접속 단일성"의 조합입니다. 모델은 많아지고, 프레임워크는 더 자동화되고, 에이전트는 더 많은 tool call과 장기 작업을 처리합니다. 이때 각 모델 제공자 SDK를 앱 코드에 직접 심으면 운영 복잡도가 급격히 늘어납니다. 반대로 모든 모델을 OpenAI의 hosted model로만 쓰면 데이터 위치, 비용, 모델 선택권이 좁아질 수 있습니다. OpenAI 호환 SageMaker 엔드포인트는 이 사이에서 AWS가 제시한 절충안입니다.

인증의 핵심은 API 키가 아니라 짧은 권한 위임입니다

OpenAI 호환이라는 이름 때문에 정적 API key를 떠올리기 쉽지만, SageMaker의 방식은 다릅니다. SageMaker 개발자 문서는 bearer token 인증을 설명합니다. SageMaker Python SDK의 generate_token 함수가 AWS 자격 증명을 바탕으로 짧은 수명의 token을 만듭니다. 기본값과 최대 유효 기간은 문서 기준 12시간이며, timedelta로 더 짧게 설정할 수 있습니다.

흥미로운 부분은 이 token의 정체입니다. 문서는 bearer token이 SigV4 pre-signed URL을 base64로 인코딩한 형태라고 설명합니다. token 생성 자체는 로컬 서명 작업이며 네트워크 호출이 아닙니다. 호출 시 SageMaker 서비스가 token을 디코딩하고, 서명과 만료 여부, 원래 IAM 주체의 권한을 확인합니다. 즉 개발자는 OpenAI SDK가 기대하는 api_key 위치에 문자열을 넣지만, 실제 보안 모델은 AWS IAM 위에 얹힌 임시 위임에 가깝습니다.

여기에는 실무적으로 중요한 주의점이 있습니다. 문서는 호출 주체에게 sagemaker:InvokeEndpoint와 sagemaker:CallWithBearerToken 권한이 필요하다고 설명합니다. InvokeEndpoint는 특정 엔드포인트 ARN으로 좁히는 것이 권장됩니다. 반면 CallWithBearerToken은 리소스 수준 제한을 지원하지 않아 Resource에 *가 필요합니다. 또한 token은 원래 AWS 자격 증명과 같은 수준의 권한을 갖기 때문에 디스크, 환경 변수, 로그, DB, 분산 캐시에 저장하지 말라는 권고가 붙습니다.

이 대목이 이번 발표의 중요한 현실성입니다. "OpenAI SDK로 호출할 수 있다"는 편의성 뒤에는, 기업이 여전히 IAM 정책과 endpoint ARN, token 수명, 로깅 정책을 설계해야 한다는 사실이 남아 있습니다. OpenAI 호환층은 코드를 줄여 주지만 권한 설계를 없애지는 않습니다.

vLLM과 SGLang을 공식 경로로 끌어들인 효과

지원 컨테이너 목록도 눈여겨볼 만합니다. 문서는 SageMaker AI vLLM Deep Learning Container, SageMaker AI SGLang Deep Learning Container, 그리고 /v1/chat/completions와 /ping을 구현한 커스텀 컨테이너를 지원 대상으로 적고 있습니다. 이는 AWS가 자체 추론 API만 고집하기보다, 오픈소스 모델 서버 생태계의 사실상 표준 경로를 받아들이는 쪽으로 움직였다는 의미입니다.

vLLM과 SGLang은 모델 서빙을 단순한 "모델을 띄운다"의 문제가 아니라 batching, streaming, structured output, latency, GPU 메모리 관리의 문제로 다룹니다. LocalLLaMA 같은 커뮤니티에서도 TGI와 vLLM 전환을 이야기할 때 OpenAI 호환 엔드포인트가 클라이언트 코드 변경을 줄인다는 반응이 반복됐습니다. 이번 SageMaker 발표가 그 커뮤니티 논쟁의 직접 답은 아니지만, 클라우드 관리형 배포에서도 같은 방향의 압력이 작동하고 있음을 보여줍니다.

공식 샘플 노트북은 이 흐름을 더 구체화합니다. AWS 샘플 노트북은 Qwen3-4B를 예시 모델로 삼고, single model endpoint와 inference component, Strands Agents 다중 에이전트 워크플로를 차례로 보여 줍니다. 노트북은 엔드포인트 프로비저닝을 포함해 약 20-30분, ml.g6.12xlarge 1시간 미만 기준 약 5-10달러의 비용을 예상치로 적고 있습니다. 이 숫자는 기능의 화려함보다 더 실무적인 메시지를 줍니다. SageMaker는 서버리스 토큰 과금 API가 아니라, 엔드포인트가 켜져 있는 동안 비용이 발생하는 전용 추론 인프라입니다.

에이전트 팀에는 무엇이 달라지나

에이전트 개발팀 입장에서 가장 큰 변화는 모델 라우팅의 선택지가 늘어난다는 점입니다. 지금 많은 팀은 OpenAI, Anthropic, Gemini, Bedrock, 자체 vLLM 엔드포인트를 LLM gateway 뒤에 묶습니다. 게이트웨이가 provider별 SDK 차이를 숨기고, 앱은 하나의 Chat Completions 스타일 인터페이스로 말합니다. 그런데 SageMaker가 직접 OpenAI 호환 경로를 제공하면, "자체 모델을 AWS에 올리는 선택지"가 게이트웨이에 더 자연스럽게 들어옵니다.

예를 들어 코딩 에이전트는 일반 추론, 코드 리뷰, 요약, 분류, 테스트 로그 분석을 각각 다른 모델로 보낼 수 있습니다. 일반 추론은 hosted frontier model을 쓰고, 사내 코드나 고객 데이터가 들어가는 작업은 VPC 안의 SageMaker endpoint로 보낼 수 있습니다. 앱 코드가 provider별 요청 형식을 많이 알 필요가 없다면, 모델 선택은 정책과 비용, 데이터 민감도에 따라 더 자주 바뀔 수 있습니다.

또 하나의 영향은 평가와 관측입니다. OpenAI 호환 계층이 널리 퍼질수록 tracing, eval, prompt logging, gateway policy 도구는 provider별 특수 API보다 공통 요청/응답 형식에 맞춰 발전합니다. AWS 입장에서는 SageMaker endpoint를 이 공통 관측 생태계에 끼워 넣는 것이 중요합니다. 개발자 입장에서는 자체 모델을 올려도 기존 평가 파이프라인을 덜 바꾸는 것이 중요합니다.

다만 여기서 "모든 OpenAI 기능이 그대로 된다"는 결론은 위험합니다. 이번 발표의 범위는 Chat Completions 경로입니다. 모델별 tool call 세부 동작, structured output, reasoning trace, multimodal 입력, provider별 안전 정책, 응답 필드의 미묘한 차이는 실제 컨테이너 구현과 프레임워크 어댑터에 따라 달라질 수 있습니다. 호환 API는 시작점을 맞춰 주지만, 완전한 의미의 동작 등가성을 보장하는 말은 아닙니다.

AWS의 방어이자 공격입니다

AWS는 Bedrock으로 managed foundation model API를 제공하고, SageMaker로 훈련과 배포를 제공하며, AgentCore와 Strands Agents로 에이전트 운영층을 넓히고 있습니다. 이번 SageMaker OpenAI 호환 API는 그 사이에 있던 빈틈을 메우는 움직임입니다. 기업이 "이미 앱은 OpenAI SDK로 짜여 있다"는 이유로 자체 AWS 추론 인프라를 포기하지 않게 만드는 방어입니다. 동시에 "OpenAI 호환 앱도 AWS 계정 안의 GPU와 IAM으로 운영할 수 있다"는 공격입니다.

경쟁 구도도 이 지점에서 바뀝니다. OpenAI나 Anthropic 같은 모델 회사와의 경쟁만이 아닙니다. Vertex AI, Azure AI Foundry, Together AI, Fireworks AI, self-hosted vLLM, LLM gateway 업체들이 모두 같은 질문을 받습니다. 앱 개발자가 이미 OpenAI 호환 인터페이스를 쓰고 있다면, 누가 가장 적은 마찰로 모델 다양성, 데이터 통제, 비용 예측, 보안 정책을 제공할 수 있는가.

GeekNews에 올라온 Bifrost 같은 AI gateway 소개가 흥미로운 것도 같은 이유입니다. 여러 제공자를 단일 OpenAI 호환 API로 묶는 도구가 주목받는다는 것은, 개발자가 모델별 SDK보다 공통 접속층을 더 원한다는 신호입니다. SageMaker가 이 경로를 공식화하면, 게이트웨이는 더 이상 "SageMaker를 OpenAI처럼 보이게 만드는 프록시"만 할 필요가 없습니다. 대신 라우팅, fallback, budget, observability, policy에 집중할 수 있습니다.

실무자가 확인해야 할 네 가지

첫째, token 발급과 갱신 방식을 설계해야 합니다. 장기 실행 앱은 요청마다 새 token을 만들거나 httpx.Auth 같은 auto-refresh 패턴을 쓸 수 있습니다. token을 환경 변수나 로그에 남기는 방식은 문서 권고와 맞지 않습니다.

둘째, IAM 권한 범위를 좁혀야 합니다. InvokeEndpoint는 endpoint ARN 단위로 제한하고, token을 만드는 역할 자체가 과도한 권한을 갖지 않게 해야 합니다. CallWithBearerToken의 Resource: "*" 요구는 설계상 피하기 어렵기 때문에, 더더욱 원래 role의 범위가 중요합니다.

셋째, 비용 모델을 오해하면 안 됩니다. 공식 블로그와 문서는 SageMaker endpoint가 트래픽이 없어도 켜져 있는 동안 비용이 발생한다고 주의합니다. OpenAI SDK로 호출한다고 해서 서버리스 per-token API가 되는 것은 아닙니다. 전용 endpoint의 장점은 통제와 성능, 데이터 위치일 수 있지만, 유휴 비용과 capacity planning은 그대로 남습니다.

넷째, 호환성 테스트를 실제 프레임워크 단위로 해야 합니다. OpenAI SDK의 단순 chat completion은 잘 맞을 수 있어도, 에이전트 프레임워크가 기대하는 tool call, streaming chunk, error object, retry semantics는 더 까다로울 수 있습니다. 특히 프로덕션 에이전트는 한 번의 응답보다 실패 복구와 부분 실행, 재시도에서 문제가 드러납니다.

결론: 모델 전쟁의 아래층에서 API 문법 전쟁이 끝나가고 있습니다

SageMaker의 OpenAI 호환 API 지원은 화려한 모델 발표가 아닙니다. benchmark 점수도 없고, 새 foundation model도 없습니다. 그러나 AI 개발자에게는 이런 인프라 발표가 더 오래 남을 때가 있습니다. 한 번 자리 잡은 호출 규격은 프레임워크, 게이트웨이, 평가 도구, 로그 도구, 운영 정책을 모두 끌고 가기 때문입니다.

이번 변화의 핵심은 AWS가 OpenAI 모델을 인정했다는 데 있지 않습니다. AWS가 OpenAI식 API 문법을 기업 AI 인프라의 접속층으로 인정했다는 데 있습니다. 모델은 AWS 계정 안의 SageMaker endpoint에서 돌고, 앱은 OpenAI SDK로 말하며, 권한은 IAM과 짧은 bearer token으로 통제합니다. 이 조합이 완벽한 해답은 아니지만, 기업 AI 팀이 실제로 원하는 절충에 가깝습니다.

앞으로 비슷한 발표는 더 늘어날 가능성이 큽니다. 모델 제공자는 자기 API를 밀고, 클라우드는 자기 런타임을 밀고, 개발자는 자기 앱을 덜 고치고 싶어 합니다. 그 사이에서 살아남는 것은 특정 브랜드의 SDK가 아니라 가장 많은 도구가 이해하는 접속 문법입니다. SageMaker가 /openai/v1 문을 연 사건은, 에이전트 인프라 경쟁의 승부가 모델 성능표 아래층의 API 표면에서 벌어지고 있음을 보여줍니다.