AWS가 9월 18일 Moonshot AI의 Kimi K3를 Amazon Bedrock에서 정식 제공하기 시작했다. Kimi K3는 100만 토큰 문맥 창과 네이티브 비전을 내세운 오픈 웨이트 모델이다. 이번 변화에서 눈여겨볼 부분은 모델의 크기만이 아니다. Bedrock에서 명시적 프롬프트 캐시를 지원하는 첫 오픈 웨이트 모델이라는 점이, 긴 문서와 저장소를 반복해서 읽는 에이전트 작업의 설계를 다시 보게 한다.
앞서 Kimi K3 자체의 특성과 다른 플랫폼에서의 도입은 살펴본 바 있다. 이번에는 Bedrock이라는 관리형 환경에 들어오면서 생긴 운영상 선택지를 좁혀 보려 한다. 같은 모델이라도 호출 경로, 문맥 재사용 방식, 데이터가 이동하는 범위가 바뀌면 비용과 장애 양상이 달라진다.
이번 발표에서 확인할 수 있는 범위
AWS 발표와 Bedrock 모델 카드에 따르면 Kimi K3는 2026년 9월 18일부터 Bedrock에서 활성 상태로 제공된다. 모델은 Responses와 Chat Completions API, Bedrock Runtime을 지원한다. AWS 문서는 새 애플리케이션에는 Bedrock Runtime을 권장하고, Kimi K3에는 가능한 한 OpenAI 호환 Responses 또는 Chat Completions API를 쓰라고 안내한다.
여기서 중요한 제약도 있다. Converse API로 여러 턴을 이어 갈 때 이전 응답의 reasoning content를 그대로 넣으면 InternalServerException이 날 수 있다고 문서에 적혀 있다. PDF와 HTML 문서 첨부도 Converse에서는 거부될 수 있다. 프레임워크가 기본값으로 Converse를 쓰는지, 대화 이력을 어떤 형태로 다시 보내는지 확인하지 않고 모델 ID만 바꾸면 파일럿 단계에서 바로 막힐 수 있다.
문서상 Kimi K3는 US Geo와 Global 교차 리전 추론 프로필로 호출한다. US Geo 프로필은 요청을 미국 지리권 내 리전에만 라우팅하고, Global 프로필은 지원되는 상용 AWS 리전으로 보낼 수 있다. 한국에서 실행한다고 해서 처리 위치가 한국 리전으로 고정된다는 뜻은 아니다. 데이터 위치 요구사항이 있는 업무라면 모델 성능보다 이 선택을 먼저 검토해야 한다.
명시적 캐시는 긴 문맥을 공짜로 만들어 주지 않는다
프롬프트 캐시는 이전 요청의 입력 접두사를 재사용해 지연 시간과 입력 비용을 낮추는 기능이다. Kimi K3의 Bedrock 문서는 최소 1,024토큰 이상인 캐시 체크포인트와 최소 30분의 유지 시간을 명시한다. 명시적 캐시는 Responses와 Chat Completions API에서만 지원된다.
따라서 저장소 전체, 사내 위키 전체를 매 요청마다 붙이는 방식이 자동으로 효율적이 되는 것은 아니다. 캐시가 맞으려면 여러 요청이 실제로 같은 접두사를 공유해야 한다. 시스템 지침, 고정된 도구 정의, 변하지 않는 프로젝트 규칙처럼 자주 반복되는 입력은 후보가 될 수 있다. 반대로 매번 순서가 달라지는 검색 결과, 사용자별 민감 정보, 자주 갱신되는 티켓을 고정 접두사에 섞으면 적중률이 낮아지고 변경 관리도 어려워진다.
AWS가 제시한 표준 요금은 Global 교차 리전 추론 기준으로 입력 100만 토큰당 3달러, 캐시 읽기 0.30달러, 캐시 쓰기 3.75달러, 출력 15달러다. 캐시 쓰기에도 비용이 들고 유지 시간도 제한된다. 그래서 캐시를 켠 뒤 전체 비용이 줄었는지는 호출 횟수, 캐시 읽기 비율, 첫 요청과 후속 요청의 응답 시간을 함께 봐야 판단할 수 있다. 모델 공급사가 제시한 장기 코딩 성능 수치만으로 절감 효과를 단정할 수는 없다.
오픈 웨이트와 관리형 서비스 사이에서 달라지는 일
Moonshot AI는 Kimi K3를 2.8조 파라미터, 네이티브 비전, 100만 토큰 문맥의 모델로 소개했다. 자체 API나 직접 배포에서는 모델 버전, 런타임, 인증과 네트워크 경계를 팀이 더 많이 관리해야 한다. Bedrock에서 쓰면 모델 호출을 기존 AWS의 접근 제어, 암호화, 감사 흐름에 얹을 수 있다는 것이 AWS의 설명이다.
다만 관리형 경로가 모든 책임을 대신하지는 않는다. 교차 리전 추론을 어떤 프로필로 허용할지, 호출 로그에 어떤 입력이 남는지, 에이전트가 도구 호출 전에 어떤 승인을 받는지는 애플리케이션 쪽에서 정해야 한다. 오픈 웨이트 모델이라는 이유만으로 자체 통제 범위가 넓어졌다고 보는 것도 정확하지 않다. 이 경로에서는 AWS 계정, IAM 권한, Bedrock의 서비스 제약이 실제 운영 경계가 된다.
독립 보도는 Kimi K3가 긴 작업에서 이전 사고 내용을 보존하는 형식에 맞춰 학습됐으며, 에이전트 하네스가 이력을 제대로 되돌려 주지 않으면 출력이 불안정해질 수 있다는 Moonshot AI의 설명을 전한다. 이 내용은 모델의 일반 성능보다 세션 직렬화와 재개 테스트가 중요하다는 신호로 읽을 만하다. 다만 이는 공급사 설명을 바탕으로 한 보도이므로, 각 팀의 프레임워크에서 재현된 결과로 받아들이면 안 된다.
작게 확인해 볼 세 가지
- 고정 문맥을 분리한다. 프로젝트 규칙, 도구 스키마, 보안 정책처럼 30분 동안 거의 바뀌지 않는 입력만 별도 접두사로 두고, 검색 결과와 사용자 데이터는 뒤에 붙인다. 캐시 적중률을 확인할 수 있는 형태여야 한다.
- 호출 경로를 두 개만 비교한다. 읽기 전용 코드 질의 하나를 골라 Chat Completions 또는 Responses 경로와 기존 Converse 경로의 성공률, 첫 응답 시간, 후속 응답 시간을 기록한다. 멀티턴에서 reasoning content가 들어갈 때의 실패 여부도 확인한다.
- 리전과 로그를 배포 조건으로 적는다. Global과 US Geo 프로필 중 어느 것을 쓸지, 허용 가능한 데이터 종류는 무엇인지, invocation log의 보존 주체는 누구인지 문서로 남긴다. 이 항목이 정해지지 않았다면 실제 업무 문서를 넣는 단계는 미루는 편이 낫다.
모델 선택이 아니라 입력 설계의 문제
이번 출시가 모든 긴 문맥 작업에 Kimi K3를 권하는 근거는 아니다. 100만 토큰은 상한일 뿐이며, 긴 입력이 더 좋은 답을 보장하지도 않는다. 특히 Kimi K3의 Bedrock 지원 API와 Converse의 제약 차이는 기존 에이전트 프레임워크에 영향을 줄 수 있다.
그렇지만 반복되는 문맥을 가진 코딩과 지식 업무라면, 모델을 바꾸기 전에 입력을 고정 부분과 가변 부분으로 나누어 보는 계기는 된다. 캐시는 비용 기능인 동시에 프롬프트를 어떤 단위로 관리하는지 드러내는 장치다. 작은 읽기 전용 과제에서 그 경계를 먼저 검증하면, 장기 에이전트에 더 큰 권한과 문서를 연결할지 판단할 근거가 생긴다.