Grok 4.3은 Bedrock의 Converse로 호출할 수 없다. OpenAI 호환 Mantle을 통해서만 가능

기존의 Bedrock 애플리케이션에 xAI의 Grok 4.3을 추가하려고 boto3의 converse()를 그대로 호출한 사람은 아마 처음에 막힐 것이다. Grok 4.3은 Amazon Bedrock에 올라왔음에도 불구하고, Bedrock의 대표 API인 Converse나 InvokeModel로는 호출할 수 없기 때문이다. 대신 사용하는 것은 OpenAI SDK이다. AWS 문서가 지시하는 설치 명령어는 말 그대로 pip install openai이다.

이 언뜻 보기에 뒤틀린 상황은 AWS가 Bedrock을 'OpenAI 호환 게이트웨이'로 개편하고 있다는 증거다. 그 입구가 Mantle이라는 새로운 추론 엔진이며, Grok 4.3은 그곳을 통과하는 첫 번째 주요 서드파티 프론티어 모델(Frontier Model)이 되었다. 출시는 2026년 6월 15일이며, xAI에게는 Bedrock 첫 등장이다 (AWS What's New).

Mantle이란 무엇인가, 왜 Converse가 작동하지 않는가

Mantle은 AWS 공식 문서의 표현을 빌리자면 '대규모 모델 배포를 위한 분산 추론 엔진'이며, OpenAI 호환 API를 제공한다. Bedrock에는 기존부터 bedrock-runtime이라는 엔드포인트가 있었고, Converse나 InvokeModel은 그곳에 연결되어 있었다. Mantle은 이와는 별개의 계통인 bedrock-mantle 엔드포인트로 준비되어 있으며, /v1/chat/completions나 /v1/responses와 같이 OpenAI와 동일한 형태의 경로(Path)를 사용한다.

This endpoint allows you to use familiar OpenAI SDKs and tools with Amazon Bedrock models, enabling you to migrate existing applications with minimal code changes—simply update your base URL and API key.

(Inference using Responses API — Amazon Bedrock)

즉, 목표는 OpenAI 코드베이스를 가진 팀이 '베이스 URL과 API 키를 교체하는 것만으로' Bedrock으로 이전할 수 있도록 하는 것이다. Grok 4.3의 모델 카드(Model Card)를 보면, 대응 API는 Chat Completions와 Responses뿐이며, Converse, InvokeModel, bedrock-runtime은 모두 지원되지 않는다고 명시되어 있다. 따라서 기존의 Converse 자산은 유용할 수 없다. 이 점이 실무상 가장 큰 차이점이다.

Mantle 자체가 Grok을 위해 신설된 것은 아니다. AWS는 2026년 2월 시점에 프로젝트 단위의 분리를 수행하는 OpenAI 호환의 Projects API와 함께 Mantle을 출시했으며, 이미 openai.gpt-oss-120b와 같은 모델이 탑재되어 있었다. Grok 4.3은 그 그릇에 외부 연구소의 모델로서 큼직한 한 방이 들어온 격이다.

호출 코드와, 사소하지만 뼈아픈 함정

실제 최소 코드는 다음과 같다. 인증은 OpenAI의 키가 아니라 Bedrock의 장기 API 키를 OPENAI_API_KEY에 넣고, 베이스 URL을 Bedrock 측으로 향하게 한다.

export OPENAI_API_KEY="<your Bedrock API key>"
export OPENAI_BASE_URL="https://bedrock-mantle.us-west-2.api.aws/openai/v1"

from openai import OpenAI
client = OpenAI()
response = client.responses.create(
...

여기에 함정이 있다. Grok 4.3의 베이스 URL은 .../openai/v1이며, 끝에 openai가 끼어 있다. Mantle 일반 문서가 안내하는 .../v1과는 다른 경로다. AWS도 모델 카드에서 굳이 "This is different from the v1/responses path used by other models"라고 주의 사항을 붙여 놓았다. 다른 Mantle 모델에서 작동했던 URL을 재사용하면, Grok만 404 에러로 실패한다.

또 하나, 기본값이 OpenAI의 표준 사양과 어긋나 있다는 점도 놓치기 쉽다. Grok 4.3은 temperature가 0.7(표준인 1이 아님), top_p가 0.95, max_completion_tokens의 기본값이 131072로 설정되어 있다. OpenAI를 위해 온도(temperature) 1을 전제로 튜닝한 프롬프트를 이식하면 출력의 분산 정도가 달라진다. 이전을 단순히 "URL과 키의 교체만"이라고 생각하면, 이 지점에서 동작의 차이로 인해 낭패를 볼 수 있다.

"상시 온"을 표방하는 추론을 사실은 끌 수 있다

Grok 4.3은 모델 카드에서 "reasoning-first", "reasoning is always active by default"라며 추론 전제를 강조하고 있다. 반면 같은 문서의 이용 시 주의 사항에는, 추론의 깊이를 reasoning 파라미터를 통해 none · low · medium · high의 4단계로 조정할 수 있으며, none은 추론을 무효화한다고 적혀 있다. 기본값은 low이다. 요컨대 "기본적으로는 항상 켜져" 있지만, 필요하다면 none으로 멈출 수 있다. 상시 온이라는 홍보 문구와 오프(off)가 가능한 구현이 하나의 문서에 공존하고 있다.

추론 내용의 처리 방식도 한 가지 특징이 있다. Chat Completions API는 추론 토큰을 반환하지 않는다. Responses API라면 include=["reasoning.encrypted_content"]를 전달함으로써 암호화된 추론 내용을 받을 수 있으며, 이를 다음 턴으로 다시 보내 멀티 턴(multi-turn)의 문맥으로 사용할 수 있다. 가공되지 않은 사고 과정은 보여주지 않고 암호화하여 전달하는 설계로, 에이전트의 다단계 루프에서 상태를 이어가고 싶을 때의 방식이 여기에 나타나 있다.

도쿄 리전 개발자가 마주하는 격차

사소하지만 일본 사용자에게 직접적인 영향을 미치는 것은 리전의 비대칭성이다. bedrock-mantle 엔드포인트 자체는 도쿄(ap-northeast-1)를 포함한 많은 리전에서 사용할 수 있다. 하지만 Grok 4.3에 한정하면 제공되는 곳은 미국의 3개 리전(us-east-1, us-east-2, us-west-2)뿐이며, 심지어 In-Region 방식만 지원한다. Geo/Global 크로스 리전 추론은 지원되지 않는다.

bedrock-mantle 전체	Grok 4.3
도쿄 리전	이용 가능
...
도쿄에서 다른 Mantle 모델은 구동할 수 있어도, Grok을 호출하는 순간만큼은 미국으로 요청을 보내는 구성이 된다. 레이턴시(latency)와 데이터 소재(data residency) 양면에서 이 점은 설계 시 의식해 두어야 한다.

이것은 무엇의 전조인가

내 견해로는, 이번 사안의 핵심은 Grok이라는 고유명사가 아니라 Bedrock의 위치가 조용히 변했다는 데 있다. 지금까지 Bedrock에 탑재되려면 각 사의 모델을 AWS 독자적인 Converse라는 방언에 맞춰야 했지만, Mantle는 반대로 업계의 사실상 표준어가 된 OpenAI API 형식을 AWS 측에서 그대로 수용한다. Bedrock이 "AWS 방언을 강요하는 곳"에서 "OpenAI 호환의 다중 벤더 창구"로 다가가는, 그 첫 번째 눈에 띄는 실례가 Grok 4.3이다.

개발자가 얻을 수 있는 결론은 단순하다. AWS의 IAM이나 과금, 데이터 소재의 프레임워크는 유지하면서, 코드는 OpenAI SDK 그대로 작성할 수 있다. 이미 OpenAI 호환 방식으로 구축해 두었다면 이식 비용은 작다. 다만 Converse를 전제로 한 기존 Bedrock 자산은 그대로 사용할 수 없으며, 경로(path)나 기본값의 세부 사항에서 확실히 걸려 넘어지게 된다. 간판에 "호환"이라고 적혀 있어도, 호환이 완전 일치를 의미하지는 않는다. 실행하기 전에 모델 카드의 이용 시 주의 사항을 한 번 정독하는 것만으로도 불필요한 디버깅을 상당히 줄일 수 있다.

Discussion