Amazon SageMaker AI(아마존 세이지메이커 AI, AWS의 머신러닝 플랫폼)가 이번 주에 OpenAI 호환 API 지원을 공개했다. 핵심은 실시간 추론 엔드포인트에 /openai/v1 경로를 추가해 Chat Completions 요청과 스트리밍 응답을 그대로 처리할 수 있게 만든 점이다. 이 변화로 개발자는 기존에 사용하던 OpenAI SDK, 랭체인(LangChain, LLM 애플리케이션 프레임워크) 또는 Strands Agents(스트랜즈 에이전트, AI 에이전트 구축 도구)의 코드를 거의 수정하지 않고도 AWS 인프라 위에서 모델을 구동할 수 있게 됐다.

그동안 AWS 환경에서 모델을 호출하려면 SigV4(AWS의 표준 요청 서명 방식)라는 복잡한 인증 과정을 거쳐야 했다. 이는 개발자에게 커스텀 클라이언트를 만들거나 별도의 래퍼 코드를 작성해야 하는 번거로움을 안겨주었다. 하지만 이번 업데이트를 통해 엔드포인트 URL만 바꾸면 즉시 호출이 가능한 '드롭인(Drop-in)' 방식이 구현됐다. 즉, 애플리케이션의 로직은 그대로 둔 채, 요청을 보내는 목적지 주소만 AWS 세이지메이커로 변경하면 된다는 의미다. 이는 모델 공급자를 변경할 때 발생하는 전환 비용을 획기적으로 낮추는 결과로 이어진다.

/openai/v1 경로 도입과 베어러 토큰 인증 방식

이번 업데이트에서 먼저 바뀐 건 도구 연결 방식이다. 세이지메이커 AI 엔드포인트(모델이 외부 요청을 받는 접속 지점)가 /openai/v1 경로를 도입하면서 이제 OpenAI 표준 인터페이스를 그대로 사용할 수 있게 되었다. 쉽게 말하면 전 세계적으로 가장 많이 쓰이는 AI 통신 규격을 세이지메이커가 수용한 것이다. 비유하자면 전용 어댑터를 써야만 전원을 켤 수 있었던 가전제품이 이제는 범용 콘센트에 바로 꽂을 수 있게 바뀐 셈이다. 개발자는 이제 Chat Completions 요청을 보내거나 실시간으로 답변이 출력되는 스트리밍 응답을 받을 때 별도의 커스텀 클라이언트를 만들 필요가 없다. 기존에 OpenAI SDK나 랭체인(LangChain, LLM 기반 애플리케이션 구축 프레임워크)을 사용하던 환경이라면 엔드포인트 URL만 수정하는 것으로 즉시 전환이 가능하다.

인증 방식 역시 훨씬 간결해졌다. 기존의 복잡한 서명 과정 대신 베어러 토큰(Bearer Token, 토큰을 보유한 사람에게 권한을 부여하는 인증 방식) 방식을 도입했다. 이는 마치 호텔에서 체크인 후 받는 카드키와 비슷하다. 카드키를 가지고 있으면 정해진 시간 동안 객실에 자유롭게 출입할 수 있듯, 이 토큰만 있으면 세이지메이커 API에 접근할 수 있다. 다만 보안을 위해 유효 기간이 설정되어 있으며 최대 12시간까지만 유지된다. 토큰은 사용자의 AWS 자격 증명을 기반으로 생성되며, 생성 과정에서 네트워크 통신이 발생하지 않고 클라이언트 측에서 즉시 처리된다는 점이 특징이다.

이 시스템이 작동하려면 IAM(Identity and Access Management, AWS 리소스 접근 권한을 관리하는 서비스)에서 특정 권한이 부여되어야 한다. 구체적으로는 sagemaker:CallWithBearerToken과 sagemaker:InvokeEndpoint 권한이 필수적이다. 특히 베어러 토큰은 내부적으로 base64로 인코딩된 SigV4(AWS의 표준 요청 서명 방식) 사전 서명 URL 형태를 띠고 있다. 서비스는 전달받은 토큰을 디코딩해 서명을 검증하고, 유효 기간이 지나지 않았는지, 그리고 요청자가 적절한 IAM 권한을 가졌는지 확인한 뒤 응답을 보낸다.

이러한 변화는 인프라 교체 비용을 획기적으로 낮춘다. 개발자는 더 이상 AWS 전용 인증 라이브러리를 공부하거나 복잡한 서명 코드를 짤 필요가 없다. 표준화된 경로와 토큰 방식 덕분에 모델을 교체하거나 환경을 옮길 때 코드 수정 범위를 최소화할 수 있기 때문이다. 실제 구현 방법과 배포 및 호출 예제는 https://github.com/aws/sagemaker-examples 저장소의 노트북 예제를 통해 확인할 수 있다.

SigV4 서명을 베어러 토큰으로 변환하는 작동 원리

개발자가 AWS 서비스를 이용할 때 가장 번거로워하는 지점은 SigV4(Signature Version 4, AWS의 표준 인증 방식)라는 복잡한 서명 과정이다. 요청을 보낼 때마다 시간, 지역, 서비스 이름 등을 조합해 암호화된 서명을 만들어 붙여야 하는데, 이는 표준 OpenAI SDK와 호환되지 않는 구조다. 이번 업데이트는 이 복잡한 서명 과정을 클라이언트 사이드에서 토큰화하여 호출 과정을 단순화했다. 쉽게 말하면, 매번 복잡한 서류를 작성해 제출하던 방식을 임시 출입증 하나로 대체한 셈이다.

여기서 사용되는 베어러 토큰(Bearer Token, 소지자에게 권한을 부여하는 인증 토큰)의 정체는 Base64(이진 데이터를 텍스트로 바꾸는 인코딩 방식)로 인코딩된 SigV4 사전 서명 URL(Pre-signed URL)이다. 비유하자면, 정식 서류인 SigV4를 미리 작성한 뒤 이를 읽기 쉬운 암호문으로 압축해 토큰 형태로 만든 것이다. 주목할 점은 이 토큰을 생성할 때 네트워크 호출이 전혀 발생하지 않는다는 사실이다. 클라이언트가 가진 AWS 자격 증명을 이용해 로컬 환경에서 즉시 서명하고 토큰을 생성하므로, 인증을 위해 서버와 통신하며 시간을 낭비할 필요가 없다.

python
from sagemaker import token_generator

def generate_token(region="us-east-1", expiry=None):
 return token_generator.generate_token(
 region=region,
 expiry=expiry
 )

토큰은 최대 12시간까지만 유효한 시한부 권한을 가진다. 보안을 위해 토큰을 파일이나 데이터베이스에 저장하지 않고, 요청이 발생할 때마다 즉석에서 새로 생성하는 방식이 권장된다. 이를 효율적으로 구현하기 위해 httpx(파이썬의 현대적인 HTTP 클라이언트 라이브러리)의 인증 패턴을 활용할 수 있다. 요청을 보낼 때마다 자동으로 신규 토큰을 생성해 헤더에 붙여주는 구조를 만들면, 개발자는 토큰의 만료 시간을 일일이 계산하지 않고도 안전하게 API를 호출할 수 있다.

python
import httpx

class SageMakerAuth(httpx.Auth):
 def auth_flow(self, request):
 token = generate_token()
 request.headers["Authorization"] = f"Bearer {token}"
 yield request

이 과정은 보안성과 편의성을 동시에 잡은 설계다. 서버는 전달받은 토큰을 디코딩해 SigV4 서명을 검증하고, 유효 기간과 IAM(Identity and Access Management, AWS 자격 증명 및 액세스 관리) 권한을 확인해 요청을 승인한다. 결과적으로 개발자는 복잡한 AWS 보안 로직을 직접 구현할 필요 없이, 표준 OpenAI 클라이언트를 그대로 사용하면서 SageMaker AI의 인프라를 활용할 수 있게 되었다.

단일 모델 엔드포인트 vs 추론 구성 요소(Inference Components)

개발자가 Qwen3-4B 모델을 ml.g6.2xlarge 인스턴스에 배포하면 단일 모델 엔드포인트가 생성된다. 이 방식은 하나의 서버 자원을 오직 하나의 모델이 독점하는 구조다. 쉽게 말하면 전용 매장을 하나 차리는 것과 같다. 관리가 단순하고 성능 예측이 쉽지만 여러 모델을 동시에 운영해야 할 때는 비용 부담이 급격히 늘어난다. 모델마다 별도의 인스턴스를 띄워야 하므로 사용하지 않는 자원이 낭비되는 구간이 생기기 때문이다.

이런 비효율을 해결하는 것이 추론 구성 요소(Inference Components, 하나의 엔드포인트 내에서 모델별로 자원을 분할해 할당하는 기능)다. 하나의 엔드포인트라는 커다란 울타리 안에 여러 모델을 함께 호스팅하면서도 각 모델이 사용할 자원량은 개별적으로 설정할 수 있다. 비유하자면 커다란 공유 오피스에 여러 기업이 입주하는 것과 비슷하다. 건물 입구는 하나지만 내부에서는 각 기업이 할당받은 책상과 장비를 독립적으로 사용하는 원리다. 덕분에 Llama 같은 범용 모델과 특정 도메인에 최적화된 Mistral 모델을 한 곳에서 효율적으로 운영할 수 있다.

특정 모델을 호출하는 방법은 URL 경로에 포함된 구성 요소 이름을 통해 결정된다. 사용자는 OpenAI Python SDK(OpenAI 모델을 제어하기 위한 표준 소프트웨어 개발 도구)를 그대로 사용하면서 주소만 바꿔주면 된다. 단일 모델을 호출할 때는 아래와 같이 기본 엔드포인트 주소를 사용한다.

python
from openai import OpenAI

client = OpenAI(
 base_url="https://runtime.sagemaker.us-east-1.amazonaws.com/endpoints/my-endpoint/openai/v1",
 api_key="your-bearer-token"
)

response = client.chat.completions.create(
 model="qwen3-4b",
 messages=[{"role": "user", "content": "Hello!"}]
)

반면 여러 추론 구성 요소를 사용할 때는 URL 경로에 각 구성 요소의 이름을 넣어 구분한다. 이렇게 하면 애플리케이션 코드 내에 복잡한 라우팅 로직을 짤 필요 없이 URL 변경만으로 모델을 교체하거나 병렬로 호출할 수 있다.

python
from openai import OpenAI

llama_client = OpenAI(
 base_url="https://runtime.sagemaker.us-east-1.amazonaws.com/endpoints/my-endpoint/components/llama-component/openai/v1",
 api_key="your-bearer-token"
)

classifier_client = OpenAI(
 base_url="https://runtime.sagemaker.us-east-1.amazonaws.com/endpoints/my-endpoint/components/classifier-component/openai/v1",
 api_key="your-bearer-token"
)

llama_res = llama_client.chat.completions.create(model="llama", messages=[{"role": "user", "content": "Write a poem."}])
class_res = classifier_client.chat.completions.create(model="small-model", messages=[{"role": "user", "content": "Classify this text."}])

랭체인과 에이전트 프레임워크의 '드롭인' 교체 가능성

개발자가 가장 먼저 체감하는 변화는 코드를 새로 짜지 않고 엔드포인트 URL(접속 주소) 하나만 바꿔도 모델이 교체된다는 점이다. 기존에는 특정 LLM 공급자의 API를 사용하다가 다른 인프라로 옮기려면 SDK(소프트웨어 개발 키트)를 교체하거나 호출 방식을 완전히 새로 설계해야 했다. 하지만 이제는 랭체인(LangChain, LLM 애플리케이션 개발 프레임워크)이나 스트랜즈 에이전트(Strands Agents, AI 워크플로우 설계 도구)로 구축한 복잡한 작업 흐름을 그대로 둔 채 세이지메이커 AI(SageMaker AI, AWS의 머신러닝 플랫폼)의 GPU 인스턴스로 옮겨 실행할 수 있다. 쉽게 말하면 모델을 갈아끼우는 과정에서 발생하는 개발 공수를 거의 제로에 가깝게 줄인 셈이다.

비유하자면 가전제품의 전원 플러그를 바꾸는 것과 비슷하다. 집안의 전기 배선을 전부 뜯어고칠 필요 없이 플러그 규격만 맞으면 어떤 브랜드의 제품이든 바로 꽂아 쓸 수 있는 식이다. 실제로 카페인 AI(Caffeine.AI)의 엔지니어 조르조 피아티(Giorgio Piatti)는 비프로스트(Bifrost, LLM 게이트웨이)라는 도구를 통해 이 이점을 증명했다. 이전에는 AWS 환경에서 모델을 호출하려면 시그니처 V4(SigV4, AWS 전용 보안 인증 방식)라는 복잡한 서명 과정이 필요해 별도의 커스텀 클라이언트를 만들어야 했다. 그러나 이번 업데이트로 도입된 베어러 토큰(Bearer Token, 단순 인증 키) 방식을 사용하면 별도의 서명 로직 없이도 버셀 AI SDK(Vercel AI SDK, 웹 인터페이스용 AI 개발 도구)나 표준 OpenAI 클라이언트와 네이티브하게 호환된다.

이런 드롭인(Drop-in, 기존 부품을 그대로 대체하는 방식) 교체 가능성은 인프라 선택의 자유도를 극대화한다. 개발자는 기존에 작성한 SDK 호출 코드나 실시간 응답을 구현한 스트리밍 로직, 그리고 모델에게 내리는 지시서인 프롬프트 포맷팅을 단 한 줄도 수정할 필요가 없다. 단순히 접속 주소만 변경하면 서비스 운영 환경을 외부 API 기반에서 내 계정의 전용 GPU 인스턴스 기반으로 즉시 전환할 수 있다. 이는 특정 기업의 API 정책이나 가격 변동에 휘둘리지 않고, 필요에 따라 오픈소스 모델을 직접 튜닝해 배포하면서도 애플리케이션의 구조는 그대로 유지할 수 있다는 실무적 이점을 제공한다. 결과적으로 개발팀은 인프라의 종속성에서 벗어나 모델의 성능 최적화라는 본질적인 작업에만 집중할 수 있는 환경을 갖게 된다.

한국 AI 실무자를 위한 AWS 모델 전환 전략

개발자가 가장 먼저 체감하는 변화는 코드 수정 없이 엔드포인트 URL(서비스 접속 주소) 하나만 바꾸면 모델이 교체된다는 점이다. 기존에 OpenAI SDK(소프트웨어 개발 키트)나 랭체인(LangChain) 같은 도구를 사용해 애플리케이션을 구축했다면, 내부 로직을 전부 뜯어고치거나 복잡한 인증 래퍼를 새로 만들 필요가 없다. 쉽게 말하면 주문하는 앱의 인터페이스는 그대로 두고 배달 업체만 바꾸는 것과 같다. 이 방식 덕분에 실무자는 모델 마이그레이션에 드는 공수를 획기적으로 줄이면서도, 서비스 운영 중에 더 적합한 모델이 나오면 즉시 갈아탈 수 있는 기술적 유연성을 확보하게 된다.

보안과 규제가 까다로운 한국의 기업 환경에서는 데이터가 외부로 유출되는 것에 매우 민감하며, 이는 AI 도입의 가장 큰 걸림돌이었다. 이번 전략의 핵심은 오픈소스 모델을 사용하면서도 이를 기업의 자체 계정 내 전용 GPU 인스턴스(그래픽 처리 장치 서버)에서 운영한다는 점이다. 비유하자면 공용 도서관에서 책을 빌려 보는 것이 아니라, 내 집 안에 나만의 금고 서재를 만들고 그곳에서만 자료를 관리하는 것과 비슷하다. 데이터가 기업의 통제권 안에 완전히 격리되어 처리되므로, 금융이나 공공 분야처럼 엄격한 엔터프라이즈급 보안 요구사항을 충족하면서도 최신 오픈소스 모델의 강력한 성능을 안전하게 활용할 수 있다.

특정 산업 도메인의 전문 지식을 학습시킨 미세 조정(Fine-tuning) 모델을 운영할 때의 비용 효율성도 크게 개선되었다. 인퍼런스 컴포넌트(Inference Components, 추론 구성 요소) 기능을 활용하면 하나의 엔드포인트에서 성격이 다른 여러 모델을 동시에 호스팅할 수 있다. 예를 들어 일반적인 고객 응대는 라마(Llama) 모델이 처리하고, 고도의 전문성이 필요한 기술 상담은 미세 조정된 미스트랄(Mistral) 모델이 담당하게 구성하는 식이다. 이때 각 모델별로 필요한 컴퓨팅 자원을 독립적으로 할당하고 스케일링(자원 확장 및 축소)할 수 있어, 사용량이 적은 소형 모델 때문에 전체 서버 사양을 높여 비용을 낭비하는 비효율을 막을 수 있다. 이는 마치 대형 쇼핑몰이라는 하나의 입구를 공유하면서도, 각 브랜드 매장이 자신의 매출에 맞춰 매장 크기와 인력을 따로 조절해 운영비를 최적화하는 구조와 같다.