지리적 프로파일과 글로벌 프로파일의 차이

사내 안내 도우미에 직원의 질문이 몰린다고 가정하겠습니다. 애플리케이션은 한 출발 리전에서 요청을 보내지만, 교차 리전 추론 프로파일을 사용하면 Bedrock이 정의된 대상 리전 중 한 곳에서 요청을 처리할 수 있습니다.

지리적 프로파일은 미국·유럽 등 정해진 지리적 범위의 후보 리전을 사용합니다. 글로벌 프로파일은 특정 지리적 그룹에 한정되지 않고 전 세계의 지원되는 AWS 상용 리전으로 처리 범위가 넓어집니다. 글로벌이라는 말은 한 질문을 모든 리전에서 동시에 처리한다는 뜻이 아닙니다. 교차 리전 추론 비교

따라서 두 방식을 고르는 첫 질문은 “어느 지역에서 처리되어도 되는가?”입니다. 요청량이나 비용이 중요하더라도 데이터 처리 가능 지역을 먼저 확인해야 합니다.

지원 모델과 대상 범위

글로벌 프로파일은 모든 모델과 모든 출발 리전에서 사용할 수 있는 기능이 아닙니다. 선택한 모델의 모델 카드에서 글로벌 프로파일 ID, 사용할 수 있는 출발 리전, API 및 필요한 기능을 확인합니다. 글로벌 교차 리전 추론 · 추론 프로파일 지원 조건

글로벌 프로파일의 처리 후보 범위는 AWS가 지원 리전을 추가하면서 달라질 수 있습니다. 오늘의 특정 목록을 영구적인 허용 목록처럼 취급하지 말고, 운영 중인 모델의 공식 지원 정보를 계속 확인해야 합니다. 후보가 넓어질 가능성 자체가 데이터 처리 요구사항과 맞는지도 검토해야 합니다.

애플리케이션 추론 프로파일을 사용하는 경우에도 원본으로 글로벌 시스템 정의 프로파일을 지정하면 그 글로벌 라우팅 범위를 따릅니다. 비용 추적을 위한 프로파일 이름만 보고 실제 처리 범위를 좁게 가정하면 안 됩니다. 애플리케이션 프로파일의 원본

데이터 처리 위치 요구사항

도우미가 안내문과 직원 질문을 모델에 보내면, 글로벌 프로파일에서는 그 입력과 모델 출력이 출발 리전 밖의 지원 상용 리전에서 처리될 수 있습니다. 특정 국가나 리전에서만 처리해야 하는 정보라면 글로벌 프로파일이 그 요구에 맞지 않을 수 있습니다.

처리 위치와 저장 위치는 따로 확인해야 합니다. 출발 리전의 호출 기록, 별도로 설정한 모델 호출 로그, 검색 저장소와 외부 도구의 데이터는 각각의 설정과 서비스 조건을 따릅니다. 글로벌 프로파일을 선택했다고 모든 데이터가 한곳에 저장되거나 자동으로 여러 곳에 저장된다고 단정할 수 없습니다.

AWS는 계정에서 수동 활성화하지 않은 옵트인 리전에도 교차 리전 요청이 라우팅될 수 있고, 해당 리전에서 남용 탐지 목적으로 입력과 출력이 저장될 수 있다고 안내합니다. 조직의 데이터 분류와 보관·처리 요구사항에 이 조건을 반영해야 합니다. 대상 리전과 데이터 처리 조건 · Bedrock 데이터 보호

AWS는 교차 리전 간 데이터가 AWS 네트워크를 통해 전송되고 전송 중 암호화된다고 설명합니다. 이는 데이터가 특정 국가를 벗어나지 않는다는 뜻이 아니며, 애플리케이션과 출발 엔드포인트 사이의 연결이나 별도 저장소 경로도 각각 검토해야 합니다. 교차 리전 전송 조건

IAM·SCP 조건의 차이

IAM은 호출 주체가 프로파일과 모델에 필요한 작업을 수행할 수 있는지 평가하고, SCP는 조직 차원의 권한 경계를 제한합니다. 지리적 프로파일에서는 출발 리전과 프로파일의 대상 리전들에 적용되는 조건을 확인해야 합니다. 대상 중 필요한 추론 작업이 SCP에서 차단되면 호출이 실패할 수 있습니다. 프로파일 권한 전제 · 지리적 프로파일과 SCP

글로벌 프로파일은 권한 평가 방식이 다릅니다. AWS는 출발 리전의 프로파일 리소스, 출발 리전의 기반 모델, 리전이 지정되지 않은 글로벌 기반 모델 리소스를 구분해 설명합니다. 이 중 글로벌 기반 모델 리소스의 평가에서 aws:RequestedRegion 값은 실제 대상 리전 코드가 아닌 unspecified로 나타납니다. 글로벌 추론 IAM 조건

따라서 기존 SCP가 허용 리전 외 요청을 거부한다면 unspecified 평가가 차단되는지 확인해야 합니다. AWS는 정책 설계에 따라 이 값을 고려하거나 bedrock:InferenceProfileArn을 이용한 프로파일 예외를 검토하는 방법을 안내합니다. 이는 모든 리전이나 모든 서비스에 대한 무조건 허용을 뜻하지 않으며, 예외를 적용해도 출발 리전의 호출 제한은 별도로 평가됩니다.

이 조건 키는 프로파일 리소스 평가와 기반 모델 리소스 평가에서 동일하게 제공되는 것이 아닙니다. AWS 안내에 따르면 bedrock:InferenceProfileArn은 기반 모델 리소스 평가에 설정되지만 프로파일 리소스 평가에는 설정되지 않습니다. 기존 정책 전체의 명시적 거부와 조건을 함께 검토해야 합니다. 이 글의 설명만으로 조직의 SCP를 그대로 변경해서는 안 됩니다. 글로벌 추론 SCP 조건

글로벌 추론이 적합한 업무와 부적합한 업무

글로벌 추론은 허용된 데이터가 여러 지원 상용 리전에서 처리될 수 있고, 더 넓은 처리 후보를 활용하려는 업무에서 검토할 수 있습니다. 예를 들어 공개된 문서로 구성한 가상의 안내 도우미라도 실제 업무의 데이터 분류와 모델 이용 조건을 먼저 확인해야 합니다.

반대로 원문이나 출력이 특정 국가 또는 단일 리전에서만 처리되어야 한다면 글로벌 프로파일은 적합하지 않을 수 있습니다. 이 경우에도 지리적 프로파일이 자동으로 적합한 것은 아니므로 그 프로파일의 모든 대상 리전이 요구사항을 충족하는지 확인해야 합니다.

처리 범위가 넓다고 지연 시간이나 가용성이 항상 개선되는 것은 아닙니다. 모델별 글로벌 할당량, 응답 시간, 제한 오류와 재시도를 함께 평가합니다. 요금도 모델과 출발 리전·사용 방식에 맞는 현재 요금표로 비교하며, 특정 할인이나 절감액을 일괄적으로 가정하지 않습니다. 글로벌 할당량 · Bedrock 요금

운영 중 실제 요청이 처리된 리전은 출발 리전의 CloudTrail 이벤트에서 additionalEventData.inferenceRegion을 확인할 수 있습니다. 이 값은 한 요청의 처리 위치를 보여 주며, 이후 요청의 처리 위치를 고정하거나 별도 로그·저장소 위치를 대신 증명하지는 않습니다. 교차 리전 호출 기록

출발 리전과 후보 대상 리전

사내 안내 도우미가 Bedrock에 직원의 질문을 보낸다고 가정하겠습니다. 애플리케이션이 요청을 보내는 곳은 출발 리전이고, Bedrock이 모델 추론을 수행할 수 있는 곳은 대상 리전입니다. 지리적 교차 리전 추론을 사용하면 대상 후보가 출발 리전 하나에만 고정되지 않을 수 있습니다. 출발 리전과 대상 리전

예를 들어 설명을 위한 가상 구성에서 출발 리전이 A이고 선택한 프로파일의 후보가 A·B·C라고 하겠습니다. 한 요청은 그 후보 중 한 곳에서 처리될 수 있으며, 다음 요청도 같은 곳에 간다고 단정할 수 없습니다. A·B·C는 실제 AWS 리전이나 특정 모델의 지원 목록이 아닙니다.

같은 프로파일이라도 출발 리전에 따라 후보 대상이 달라질 수 있습니다. 사용할 모델과 지리적 프로파일, 실제 출발 리전을 함께 정하고 모델 카드 또는 프로파일 조회 결과로 후보를 확인해야 합니다. 리전 이름의 접두어만으로 정확한 대상 목록을 판단하지 않습니다.

프로파일에 따른 요청 라우팅

애플리케이션은 선택한 지리적 추론 프로파일을 modelId에 지정해 출발 리전의 Bedrock 엔드포인트로 질문과 안내 정보를 보냅니다. Bedrock은 해당 출발 리전에서 프로파일이 정의한 후보 중 한 리전을 선택해 모델 추론을 수행하고, 생성된 응답을 호출한 애플리케이션에 반환합니다. 교차 리전 추론 흐름

여러 리전을 활용한다는 말은 여러 요청이 서로 다른 리전에서 처리될 수 있다는 뜻입니다. 하나의 질문이 여러 리전으로 나뉘어 동시에 계산되거나 모든 후보가 동시에 결과를 생성한다고 해석하면 안 됩니다.

애플리케이션 추론 프로파일을 사용하는 경우에도 원본으로 교차 리전 시스템 정의 프로파일을 선택했다면 그 원본의 라우팅 범위를 따릅니다. 반대로 단일 리전 기반 모델을 원본으로 한 애플리케이션 프로파일은 이름만으로 교차 리전 경로가 되지 않습니다. 애플리케이션 프로파일 생성

단일 리전 호출과 다른 점

지원되는 모델을 단일 리전에서 직접 호출하는 구성은 해당 리전의 모델 호출을 기준으로 처리 위치를 검토합니다. 지리적 교차 리전 프로파일은 출발 리전에서 요청하더라도 정의된 다른 후보 리전이 실제 처리 위치가 될 수 있습니다. 모든 모델이 두 방식을 모두 제공하는 것은 아닙니다.

프로파일과 연결된 기반 모델에 필요한 IAM 권한, 조직의 SCP와 리전 제한을 함께 확인해야 합니다. 예를 들어 가상 후보 A·B·C 중 C에서 필요한 추론 작업이 SCP로 차단되면, A와 B가 허용돼 있어도 해당 지리적 프로파일의 요청이 실패할 수 있습니다. 허용된 후보만 자동으로 골라 사용한다고 생각하면 안 됩니다. 추론 프로파일 권한 · 대상 리전과 SCP

따라서 IAM에서 프로파일과 연결 모델에 필요한 작업이 허용되는지, SCP 등 조직 정책이 각 후보 리전의 추론을 제한하는지 나누어 확인합니다. 데이터 처리 요구사항과 맞지 않는 리전이 후보에 있다면 모든 리전을 무조건 허용하기보다 적합한 프로파일이나 다른 호출 방식을 검토합니다.

처리량·가용성·데이터 위치의 관계

여러 리전의 처리 용량을 활용하는 것은 요청이 몰릴 때 고려할 수 있는 방식입니다. 다만 교차 리전 프로파일을 쓴다는 이유만으로 지연 시간이 항상 줄거나 장애가 없어지는 것은 아닙니다. 애플리케이션에서 할당량, 재시도와 오류 처리, 실제 응답 시간을 함께 살펴야 합니다. Bedrock 할당량

지리적 프로파일은 정의된 지리적 범위 안의 대상 리전을 사용합니다. 그렇더라도 조직의 요구가 “특정 국가” 또는 “하나의 리전”으로 더 좁다면 프로파일의 모든 후보가 그 요구에 맞는지 확인해야 합니다.

AWS는 교차 리전 경로가 계정에서 수동 활성화하지 않은 옵트인 리전에도 라우팅될 수 있다고 안내합니다. 해당 처리 경로와 남용 탐지 목적의 데이터 처리 조건을 포함해 조직의 데이터 위치 요구사항을 검토해야 합니다. 옵트인 리전과 추론 처리 · Bedrock 데이터 보호

AWS는 교차 리전 간 전송이 AWS 네트워크 내에서 암호화된다고 설명합니다. 다만 애플리케이션에서 출발 리전까지의 연결 방식과 별도 저장소·도구의 경로는 각 구성에서 따로 확인해야 합니다. 교차 리전 추론 전송 조건

모델 처리 위치, 모델 호출 로그의 저장 위치, 검색용 데이터 저장소 및 연결된 도구의 위치는 각각 다릅니다. Bedrock까지의 사설 연결 여부만으로 이 모든 위치가 단일 리전에 고정된다고 가정해서는 안 됩니다.

로그와 프로파일 정보로 확인할 범위

특정 교차 리전 요청의 실제 처리 리전은 출발 리전의 CloudTrail 이벤트에서 additionalEventData.inferenceRegion을 확인할 수 있습니다. 다만 이 정보만으로 모델 호출 본문, 별도 로그 저장소, 검색 데이터나 외부 도구의 모든 저장 위치가 확인되는 것은 아닙니다. 교차 리전 추론의 CloudTrail 기록

운영 전에는 모델 카드와 프로파일 조회 결과로 후보 범위를 확인하고, 해당 범위에 대한 IAM·SCP를 검토합니다. 운영 중에는 실제 처리 리전과 호출 오류·지연을 확인하며, 모델과 프로파일의 지원 조건이 바뀌면 관련 설정과 데이터 위치 요구사항을 다시 살펴봅니다.

후보 목록을 확인하려면 GetInferenceProfile을 사용할 출발 리전에서 호출해 models 목록의 modelArn에 나타난 대상 리전을 확인합니다. 아래 PowerShell 명령에서 SOURCE_REGION은 실제 출발 리전 코드, PROFILE_ID는 해당 리전에서 사용할 프로파일 ID 또는 ARN으로 바꿉니다. AWS CLI 자격증명과 조회 권한이 필요하며 결과에는 리소스 식별자가 포함될 수 있습니다. GetInferenceProfile

기반 모델 ID와 추론 프로파일

사내 안내 도우미가 직원의 질문을 모델에 보낼 때 애플리케이션은 호출 대상을 지정해야 합니다. 지원되는 경우 기반 모델 ID를 지정할 수 있고, 추론 프로파일을 사용하는 경로에서는 프로파일의 ID 또는 ARN을 호출 대상에 지정합니다. 어떤 모델이 어떤 방식으로 제공되는지는 리전과 모델별 조건을 확인해야 합니다. 추론 프로파일로 모델 호출

기반 모델 ID는 사용할 모델을 가리킵니다. 추론 프로파일은 모델과 요청을 처리할 수 있는 하나 이상의 리전을 정의하는 별도 리소스입니다. 예를 들어 Converse의 modelId라는 필드에는 이름과 달리 지원되는 추론 프로파일을 지정할 수도 있습니다. 추론 프로파일 개요

프로파일을 지정했다고 모델을 새로 학습시키거나 별도의 모델 복사본을 만드는 것은 아닙니다. 어떤 모델과 리전을 호출 대상으로 삼을지, 그리고 프로파일 종류에 따라 사용량을 어떻게 추적할지를 구성하는 방식입니다.

시스템 정의 프로파일과 애플리케이션 추론 프로파일

시스템 정의 프로파일은 AWS가 미리 정의한 교차 리전 추론 프로파일입니다. 모델과 요청을 보낼 수 있는 대상 리전들이 정의되어 있으며, 해당 프로파일을 호출하면 Bedrock이 요청을 후보 리전 중 하나로 라우팅합니다. 시스템 정의 프로파일

애플리케이션 추론 프로파일은 사용자가 만들어 모델 호출의 사용량과 비용을 구분하는 데 사용하는 리소스입니다. 생성할 때 단일 리전의 기반 모델을 원본으로 지정하거나, 여러 리전을 사용하는 시스템 정의 프로파일을 원본으로 지정할 수 있습니다. 따라서 애플리케이션 프로파일을 쓴다는 사실만으로 교차 리전 추론을 사용하는 것은 아닙니다. 애플리케이션 프로파일 생성

가상의 안내 도우미와 문서 분류 서비스가 같은 모델을 사용해도 각각 다른 애플리케이션 프로파일과 태그를 사용하면 비용을 구분해 분석할 수 있습니다. 프로파일을 나누는 목적과 처리 리전의 범위는 별도로 결정해야 합니다.

프로파일이 가리키는 처리 대상

직원이 안내 도우미에 질문하면 애플리케이션은 선택한 출발 리전의 Bedrock 엔드포인트로 요청합니다. 교차 리전 프로파일을 사용하면 Bedrock은 해당 프로파일에서 허용하는 대상 리전 중 하나를 선택해 그 요청을 처리합니다. 한 요청의 계산이 여러 리전에 나뉜다는 뜻은 아닙니다. 교차 리전 추론

출발 리전은 애플리케이션이 요청을 보내는 리전이고, 대상 리전은 서비스가 처리 대상으로 선택할 수 있는 리전입니다. 같은 프로파일이라도 출발 리전에 따라 후보가 다를 수 있으므로, 이름의 접두어만 보고 처리 위치를 확정하지 말고 사용할 출발 리전에서 프로파일 정보를 확인합니다. 프로파일별 리전 확인

프로파일이 정의하는 처리 후보는 로그나 연결 저장소의 보관 위치와 같은 뜻이 아닙니다. 데이터 위치 요구사항이 있다면 처리 후보와 함께 호출 로그, 검색 저장소, 외부 도구의 위치를 각각 확인해야 합니다.

프로파일과 모델 호출에 필요한 IAM 권한, 조직의 SCP와 리전 제한도 함께 살펴야 합니다. 지리적 교차 리전 프로파일에서 후보 리전 중 하나가 SCP에 의해 차단되면 다른 후보가 허용되어도 요청이 실패할 수 있습니다. 글로벌 프로파일은 별도의 조건을 공식 문서에서 확인합니다. 교차 리전 권한과 SCP 조건

태그·사용량·비용 추적의 관계

애플리케이션 추론 프로파일에 태그를 붙이면 지원되는 모델 호출 비용을 서비스나 환경 같은 기준으로 분석하는 데 활용할 수 있습니다. 예를 들어 가상의 안내 도우미와 분류 서비스에 서로 다른 프로파일을 사용하면 모델 호출 비용을 구분하는 출발점이 됩니다. 애플리케이션 프로파일과 태그

태그를 붙이는 것과 비용 보고서에서 비용 할당 태그로 사용하는 것은 별개입니다. AWS Billing에서 해당 태그를 활성화하고 반영 조건을 확인해야 Cost Explorer나 비용·사용량 보고서에서 분석할 수 있습니다. 태그에는 실제 개인 정보나 민감한 업무 내용을 넣지 않습니다. 비용 보고서의 태그

프로파일을 경유하지 않은 다른 호출이나 별도의 검색 저장소·네트워크 비용이 그 프로파일에 자동으로 모두 합산된다고 가정하면 안 됩니다. 또한 비용 보고서의 금액은 집계된 비용이므로 개별 질문마다 청구 금액이 한 줄씩 제공되는 것으로 해석하지 않습니다. 모델 사용량 지표와 호출 로그도 목적·설정·보관 위치를 구분해 확인합니다. 비용과 사용량 추적

프로파일 조회 결과를 읽는 방법

GetInferenceProfile은 프로파일의 ID 또는 ARN으로 정보를 조회하는 관리 API입니다. 사용하려는 출발 리전에서 호출해 type, status와 models를 확인합니다. type이 SYSTEM_DEFINED이면 AWS가 정의한 프로파일이고 APPLICATION이면 사용자가 만든 애플리케이션 프로파일입니다. status가 ACTIVE인 것은 사용할 준비 상태를 뜻하지만, 호출 주체의 권한과 조직 정책까지 허용된다는 증거는 아닙니다. GetInferenceProfile 응답 필드

다음은 PowerShell에서 사용할 수 있는 조회 명령입니다. AWS CLI와 자격증명, 조회 권한이 필요합니다. SOURCE_REGION을 요청을 보낼 실제 리전 코드로, PROFILE_ID를 그 리전에서 확인할 프로파일 ID 또는 ARN으로 바꿉니다. 조회 결과에는 리소스 식별자가 포함되므로 공개할 때 실제 값을 노출하지 않아야 합니다. 프로파일 조회 방법

호출별 실제 처리 리전은 교차 리전 추론의 CloudTrail 기록에 있는 additionalEventData.inferenceRegion으로 확인할 수 있습니다. 조회 결과의 후보 목록과 특정 요청의 실제 처리 위치를 구분하고, 글로벌 프로파일의 대상 범위는 변경될 수 있으므로 현재 공식 문서와 조회 결과를 함께 확인합니다. 교차 리전 추론 기록

실시간 호출과 배치 처리의 차이

사내 안내 도우미가 직원의 질문을 받았을 때 사용자는 화면에서 답변을 기다립니다. 이런 요청은 애플리케이션이 모델에 호출을 보내고 응답을 받는 실시간 추론으로 처리할 수 있습니다. 스트리밍을 사용하면 지원 모델의 응답을 생성 중 일부씩 전달할 수도 있습니다.

반대로 안내문 수백 건을 분류해 다음 날 확인하는 작업은 각 결과를 즉시 볼 필요가 없을 수 있습니다. 배치 추론은 여러 입력을 파일로 준비해 비동기 작업으로 제출하고 나중에 결과 파일을 받는 방식입니다. 작업 제출이 곧 결과 완성을 뜻하지는 않습니다. Bedrock 배치 추론

Provisioned Throughput은 실시간과 같은 요청에 사용할 모델 처리 용량을 확보하는 방식입니다. 배치 작업과 같은 뜻이 아니며, 지원 모델·리전과 비용 조건을 확인해야 합니다. 어떤 방식도 특정 응답 시간이나 비용 절감을 자동으로 보장하지 않습니다.

배치 입력·출력과 작업 상태

Bedrock 배치 추론에서는 입력을 S3의 JSONL 파일로 준비합니다. JSONL은 한 줄에 JSON 객체 하나를 넣는 형식입니다. 각 레코드의 modelInput은 작업을 만들 때 선택한 Converse 또는 InvokeModel 형식에 맞아야 하며 모델은 작업 생성 시 지정합니다. 배치 입력 형식

아래는 Converse 형식의 가상 입력 두 줄입니다. recordId는 결과를 입력과 연결하기 위한 식별자입니다. 두 줄은 구조를 설명하기 위한 예시이므로 실제 작업의 최소 레코드 수나 파일·작업 크기 할당량을 충족하는지는 별도로 확인해야 합니다.

작업 생성 시 입력·출력 S3 위치와 Bedrock이 작업을 수행할 서비스 역할을 지정합니다. 호출자의 작업 생성 권한과 서비스 역할의 모델 호출·입출력 S3 권한, 암호화에 필요한 경우 KMS 권한은 서로 구분해 확인해야 합니다. 배치 작업 생성

작업은 검증과 대기를 거쳐 진행될 수 있습니다. Completed뿐 아니라 PartiallyCompleted, Failed, Expired 등 상태와 오류 메시지를 확인합니다. 입력 형식 검증을 통과해도 modelInput이 해당 모델에 맞는지까지 보장되는 것은 아닙니다. 배치 작업 상태

출력 순서는 입력 순서와 같다고 보장되지 않으므로 recordId로 결과를 연결합니다. Completed여도 개별 레코드 오류가 있을 수 있어 출력의 error와 manifest.json.out의 성공·오류 건수를 확인하고 필요한 레코드만 재처리합니다. 배치 결과 확인

Provisioned Throughput의 목적

Provisioned Throughput은 지원되는 모델에 일정 수준의 처리 용량을 확보하기 위한 방식입니다. 반복적으로 발생하는 요청량과 입력·출력 토큰 처리량을 예상할 수 있고 용량 확보가 중요한 업무에서 검토할 수 있습니다. Provisioned Throughput 안내

모델 단위로 구매하는 경우 Model Unit은 모델별 분당 입력과 출력 처리량에 해당합니다. 필요한 단위 수와 지원 모델·리전, 약정 및 시간당 요금을 확인해야 합니다. 약정이 있다면 종료 전 삭제가 제한될 수 있고 과금 종료 조건도 살펴야 합니다.

이 방식은 용량 확보를 위한 선택이지 모든 요청의 지연 시간이나 정답 품질을 보장하는 설정은 아닙니다. AWS는 배치 추론을 프로비저닝된 모델에 지원하지 않는다고 안내합니다. 또한 서비스 티어의 Reserved와 Provisioned Throughput은 관련된 용량 선택지이지만 동일한 구매 절차나 요금제로 취급하지 말고 각각의 조건을 확인해야 합니다. 배치 사용 조건 · 서비스 티어

지원되는 서비스 티어와 처리 조건

서비스 티어는 지원되는 추론 요청에서 가용성·우선순위·비용 요구에 맞춰 선택하는 방식입니다. AWS는 Standard, Priority, Flex, Reserved를 안내합니다. 각 티어를 모든 모델·리전·API에서 쓸 수 있다고 가정하지 말고 모델 카드와 호출 방식의 조건을 확인합니다. Bedrock 서비스 티어

Standard는 일반 요청의 기본 티어입니다. Priority는 우선 처리가 필요한 요청에, Flex는 처리 시간이 더 길어져도 되는 요청에 고려할 수 있습니다. Reserved는 별도의 용량 예약 조건이 있는 선택지입니다. 각 티어의 요금과 제공 조건은 모델과 리전에 따라 확인해야 합니다.

요청에서 티어를 지정하더라도 실제 처리 결과와 적용 조건을 응답·지표로 확인하는 것이 좋습니다. 티어 선택은 배치 작업 제출이나 Provisioned Throughput 구매와 같은 작업이 아닙니다. 기본값과 지원되지 않는 조합의 동작은 실제 사용하는 API 문서를 확인합니다.

처리량·대기 시간·비용을 함께 비교하기

먼저 업무의 완료 기한을 정합니다. 직원이 화면에서 기다리는 질문이라면 첫 응답과 전체 답변 완료 시간을 측정하고, 일괄 분류라면 전체 작업이 끝나는 시간과 개별 실패 건수에 주목합니다.

다음으로 모델·리전·입출력 크기와 요청량을 같은 조건으로 두고 비교합니다. 실시간 요청은 모델 호출과 재시도, 배치는 작업과 S3 입출력, 용량 구매 방식은 확보한 용량과 이용 시간을 포함해 살펴봅니다. 실제 비용은 모델과 요금 방식에 따라 다르므로 수치를 임의로 가정하지 않습니다. Bedrock 요금 안내

마지막으로 계정의 할당량, 필요한 사용자·서비스 역할 권한, 데이터 처리 위치와 운영 인력을 확인합니다. 처리량이 충분해도 권한 오류나 잘못된 입력은 해결되지 않으며, 요청이 성공해도 모델 답변의 품질은 별도로 평가해야 합니다. Bedrock 할당량

도구 이름·설명·입력 스키마

직원이 사내 도우미에 “내 장비 신청 상태를 알려줘”라고 묻는다고 가정하겠습니다. 모델은 일반적인 문장을 만들 수 있지만 업무 시스템에 있는 현재 신청 상태를 질문만으로 알 수 없습니다. 애플리케이션이 상태 조회 기능을 연결하고 모델에 그 기능을 언제 어떤 입력으로 요청할 수 있는지 알려줘야 합니다.

Converse의 toolConfig에는 사용할 도구 목록을 넣습니다. 각 toolSpec의 name은 도구 이름, description은 도구의 목적, inputSchema는 입력의 구조를 설명합니다. name과 inputSchema는 필수이며 description은 선택 사항이지만 모델이 역할을 구분할 수 있도록 구체적으로 작성하는 것이 도움이 됩니다. ToolSpecification 필드

다음은 가상의 신청 번호를 받는 조회 도구 정의입니다. 전체 Converse 요청이 아니라 toolConfig에 넣을 객체이며, 업무 API를 만들거나 실행하는 코드가 아닙니다.

도구 요청을 반환하는 모델의 역할

애플리케이션은 사용자 메시지와 도구 정의를 모델에 보냅니다. 모델이 조회가 필요하다고 판단하면 일반 텍스트 대신 또는 다른 콘텐츠와 함께 toolUse 블록을 반환할 수 있습니다. Converse 응답의 stopReason이 tool_use인 경우 도구 요청을 처리하는 흐름으로 분기합니다. 클라이언트 측 Tool Use

toolUse에는 요청을 구분하는 toolUseId, 모델이 고른 name, 전달할 input이 들어갑니다. 이 값들은 모델이 제안한 실행 요청입니다. 모델이 사용자 신원을 인증하거나 실제 업무 시스템의 조회를 끝냈다는 의미는 아닙니다. ToolUseBlock

모델이 get_request_status와 가상의 신청 번호를 반환하더라도 애플리케이션은 그 번호가 현재 사용자에게 허용된 대상인지 확인해야 합니다. 도구가 필요 없다고 판단하면 일반 답변이 반환될 수도 있습니다.

애플리케이션의 실행과 결과 전달

클라이언트 측 도구에서는 애플리케이션이 허용된 도구 이름과 입력을 확인하고 실제 조회 함수를 실행합니다. 먼저 로그인한 사용자의 신원을 기준으로 대상 신청에 접근할 수 있는지 검사합니다. 모델이 제시한 사용자 ID나 신청 번호를 권한의 근거로 삼지 않습니다.

조회가 끝나면 애플리케이션은 모델이 반환한 assistant 메시지를 대화 이력에 넣고, 해당 요청의 toolUseId와 조회 결과를 담은 user 역할의 toolResult 메시지를 추가합니다. 이후 대화 이력과 도구 설정을 다시 모델에 전달하면 모델이 결과를 바탕으로 응답을 만들 수 있습니다. Converse 도구 실행과 결과 전달

다음은 앞선 도구 요청의 ID가 tool-001이었다고 가정한 결과 메시지의 구조입니다. 상태 값은 가상이며 실제 조회 결과가 아닙니다. toolUseId는 해당 toolUse에서 받은 값을 그대로 사용해 요청과 결과를 연결합니다. ToolResultBlock

반복 호출과 도구 선택 제어

모델은 도구 결과를 받은 뒤 추가 도구를 요청하거나 최종 답변을 생성할 수 있습니다. 애플리케이션은 응답의 콘텐츠 블록을 확인하고 필요한 경우 같은 과정을 반복합니다. 한 응답에 여러 도구 요청이 있다면 각각의 toolUseId와 결과를 올바르게 연결해야 합니다.

Converse의 toolChoice는 도구 선택 방식을 지정하는 선택 항목입니다. auto는 모델이 도구 요청과 일반 답변 중 선택합니다. any는 최소 한 도구의 요청을 요구하고, tool은 지정한 도구 요청을 요구합니다. 지원되는 선택지는 모델마다 다르며 지원하지 않는 설정은 오류가 날 수 있습니다. ToolChoice · 모델별 도구 선택 지원

도구 요청을 강제해도 올바른 대상이 선택되거나 실제 실행이 승인되는 것은 아닙니다. 애플리케이션은 반복 횟수·실행 시간·실패 시 중단 조건을 정하고, 불필요한 재호출과 비용 증가를 제한해야 합니다.

입력 검증·승인·중복 실행 방지

도구 입력은 형식과 업무 조건을 모두 확인합니다. 예를 들어 request_id가 문자열이라는 것과 그 신청이 현재 사용자의 것이라는 것은 다른 검사입니다. 서버에서 허용된 도구만 실행하고, 사용자 신원과 접근 범위는 인증된 세션과 업무 시스템을 기준으로 판단합니다.

일부 지원 모델에서는 strict 도구 사용으로 모델이 반환하는 도구 이름과 입력의 스키마 준수를 강화할 수 있습니다. 그러나 스키마가 맞아도 입력값의 사실성, 사용자 권한과 업무 승인까지 보장되지는 않습니다. 모델·API의 지원 조건도 확인해야 합니다. 구조화 출력과 strict 도구 사용

신청 내용을 변경하는 도구를 추가한다면 조회와 달리 사용자 승인과 변경 권한을 별도로 검토합니다. 재시도나 반복 요청으로 같은 변경이 두 번 적용되지 않도록 업무 작업에 대한 멱등성 키와 실행 기록을 설계합니다. 도구 요청 ID만으로 업무 전체의 중복이 방지된다고 가정해서는 안 됩니다.

Bedrock에는 서버 측 도구 사용도 있습니다. 이 경우 지원되는 API에서 Bedrock이 도구 실행을 맡을 수 있으므로, 이 글의 Converse 클라이언트 측 흐름과 실행 주체·인증 경로를 구분해야 합니다. Bedrock 도구 사용 방식

이미지·문서·음성·영상의 전달 방식

직원이 장비 신청 안내문의 사진을 올리고 “어디에서 신청하나요?”라고 묻는다고 가정하겠습니다. 텍스트 질문만 받는 도우미라면 사진 내용을 처리할 수 없습니다. 이미지 입력을 지원하는 모델과 API에 질문과 이미지를 함께 전달하도록 구성해야 합니다.

멀티모달은 텍스트 외의 이미지·음성·영상처럼 서로 다른 형태의 정보를 다루는 것을 뜻합니다. 한 모델이 이미지를 입력받아 텍스트로 설명할 수 있어도 이미지를 생성하거나 음성을 처리할 수 있다는 뜻은 아닙니다. 필요한 입력과 출력 각각의 지원 여부를 확인합니다. 모델별 API 지원

Converse 계열에서는 지원되는 콘텐츠를 메시지의 콘텐츠 블록으로 전달합니다. 예를 들어 질문은 text 블록, 이미지는 image 블록에 담을 수 있습니다. 문서나 영상도 해당 모델과 API가 지원하는 콘텐츠 형태를 사용해야 합니다. 음성은 모델과 API에 따라 별도의 요청 형식이나 양방향 스트림이 필요할 수 있으므로 같은 메시지 형식을 모든 모델에 적용하지 않습니다. Converse 콘텐츠 블록 · API별 호환성

파일 위치·크기·형식 조건

파일을 전달하기 전에는 모델이 요구하는 형식과 크기·개수, 이미지 크기나 영상 길이 등 적용 조건을 확인합니다. 전송 방법도 중요합니다. 일부 입력은 파일 바이트를 요청에 넣고, 지원되는 모델·콘텐츠 유형에서는 S3 위치를 지정할 수 있습니다. 모든 모델이 같은 방식으로 S3를 읽는 것은 아닙니다. Converse 입력 형식

예를 들어 Converse 메시지의 일반 제한에는 이미지 최대 20개, 이미지당 3.75 MB와 8,000×8,000픽셀 이하, 문서 최대 5개와 문서당 4.5 MB 이하가 안내되어 있습니다. 모델별 추가 제한이 있을 수 있으므로 이 수치만으로 모든 모델의 사용 가능 여부를 판단하지 않습니다. Converse 메시지 제한

Converse에서 document 블록을 사용하면 같은 메시지에 문서와 관련된 text 블록을 포함해야 합니다. 일반적인 문서 요청에는 형식을 명시해야 하며, 일부 인용 설정을 사용하는 인라인 콘텐츠에는 예외가 있습니다. 문서 이름도 모델이 지시로 해석하지 않도록 중립적으로 정합니다. Converse 문서 입력 조건

S3를 참조하는 구성을 사용할 때는 지원 여부와 요청을 처리하는 주체의 객체 접근·암호화 권한, 저장 리전 및 보관 정책을 확인합니다. 실제 조직의 파일명이나 리소스 식별자를 예시에 그대로 넣지 않습니다.

비동기 처리가 필요한 작업

텍스트 답변처럼 요청을 보내고 곧바로 결과를 받는 방식과 달리, 일부 영상 생성 작업은 비동기 호출을 사용합니다. 요청을 시작한 뒤 즉시 결과 파일이 아닌 작업 식별자를 받고, 나중에 상태를 확인해 완성된 출력을 읽는 구조입니다. 모든 영상 모델이 동일한 API를 사용하는 것은 아닙니다. Bedrock Invoke API

예를 들어 StartAsyncInvoke 요청에는 모델 ID, 모델별 입력과 출력 저장 위치가 필요합니다. 반환된 작업 식별자로 GetAsyncInvoke를 호출해 상태를 확인하고, 완료되면 지정된 저장 위치의 결과를 읽습니다. 실패 상태와 실패 원인도 확인해야 합니다. 비동기 호출 시작 · 비동기 호출 상태 조회

이때 모델 호출 권한과 결과 저장·읽기에 필요한 S3 및 필요한 경우 KMS 권한을 각각 검토합니다. 재시도 시 중복 작업이 생기지 않도록 요청 토큰과 애플리케이션의 작업 상태를 관리합니다. 처리 시간과 비용은 모델과 작업 조건에 따라 다릅니다.

JSON 응답과 스키마 제약의 의미

도우미가 안내문에서 장비 이름과 신청 위치를 추출해 다른 프로그램에 넘긴다고 가정하겠습니다. 자연어로 “JSON으로 답해 줘”라고 요청하는 방식은 가능하지만, 응답에 설명 문장이 섞이거나 필드가 빠질 수 있습니다.

지원되는 Bedrock 구조화 출력은 JSON Schema로 필드와 자료형 등 결과의 구조를 제한합니다. Converse에서는 outputConfig.textFormat을 사용하며, InvokeModel은 모델에 따라 다른 요청 필드를 사용합니다. 모델·리전·API·프로파일별 지원 조건을 확인해야 합니다. Bedrock 구조화 출력

아래는 장비 이름과 신청 위치를 문자열로 받기 위한 가상의 JSON Schema입니다. API 요청 전체가 아니라 스키마 부분만 나타냅니다. properties는 필드와 자료형을, required는 필수 필드를, additionalProperties는 지정하지 않은 필드를 허용할지 정합니다. 지원하는 JSON Schema 범위

모델별 지원 차이와 출력 검증

Bedrock 구조화 출력은 JSON Schema의 일부 기능만 지원합니다. 예를 들어 숫자의 minimum·maximum 같은 제약은 지원 범위에 포함되지 않으며, 각 object의 additionalProperties는 false로 지정해야 합니다. 지원하지 않는 스키마는 요청 오류를 일으킬 수 있습니다. 구조화 출력의 지원 제약

일부 조합에는 기능 간 제약도 있습니다. AWS는 Anthropic 모델에서 문서 인용과 구조화 출력을 함께 사용할 수 없다고 안내합니다. 따라서 모델이 각각의 기능을 지원하더라도 같은 요청에서 함께 사용할 수 있는지는 별도로 확인해야 합니다. 구조화 출력 지원 조건

형식이 스키마에 맞아도 request_location에 실제와 다른 위치가 들어갈 수 있습니다. 애플리케이션은 반환된 값이 원문과 일치하는지, 필요한 항목이 누락되지 않았는지, 업무상 허용된 값인지 확인해야 합니다. 모델이 문서의 내용을 잘못 읽을 가능성도 평가 대상입니다.

출력을 실제 신청 변경 같은 작업에 사용한다면 JSON 파싱 성공만으로 실행하지 않습니다. 사용자 권한, 대상 값과 필요한 승인 절차를 확인하고, 결과를 반영하기 전 검증에 실패한 경우의 처리도 설계합니다.

대화 상태를 보관하는 주체

직원이 도우미에 “장비는 어디에서 신청하나요?”라고 물은 뒤 “승인은 누가 하나요?”라고 이어 묻는다고 가정하겠습니다. 두 번째 질문만 전달하면 어떤 신청의 승인인지 알기 어렵습니다. 첫 질문과 답변 중 필요한 부분을 함께 전달해야 문맥이 이어집니다.

Converse와 ConverseStream에서는 애플리케이션이 필요한 이전 메시지를 관리해 이후 요청에 포함합니다. 화면에 이전 대화가 보이더라도 서버가 그 내용을 현재 모델 요청에 포함하지 않으면 모델에는 전달되지 않습니다. Converse 대화 이력

대화 이력을 데이터베이스나 세션 저장소에 보관한다면 사용자별 접근 권한·보존 기간·삭제 방법은 애플리케이션에서 설계해야 합니다. 별도로 설정한 모델 호출 로그와 대화 이력 저장소는 각각 다른 보관 경로입니다.

이 설명은 Converse 계열의 직접 이력 전달 기준입니다. Responses API 등 다른 인터페이스에서는 서버 측 응답 저장을 사용할 수 있으므로 해당 API의 설정과 리전·보관 조건을 따로 확인합니다. Bedrock Responses API

이전 메시지를 다시 전달하는 구조

다음은 두 번째 질문을 보낼 때 사용할 수 있는 messages 배열의 가상 예시입니다. 각 메시지는 role과 content를 가지며, 앞선 모델 답변은 assistant 역할로 전달합니다. 실제 요청에는 모델 ID와 필요한 안내 정보도 함께 넣습니다. Converse 메시지 구조

첫 번째 답변이 가상의 내용이므로 실제 도우미에서는 신청 방법과 승인자를 확인할 수 있는 최신 안내문을 함께 전달해야 합니다. 이전 답변이 있었다는 사실만으로 그 내용이 정확하다는 뜻은 아닙니다.

스트리밍 이벤트와 부분 응답 조립

Converse는 완성된 응답을 한 번에 반환하고, ConverseStream은 생성 중인 응답을 이벤트로 나누어 보냅니다. 사용자는 답변 전체가 끝나기 전에 일부 텍스트를 볼 수 있지만, 화면에 글자가 나타났다는 사실만으로 생성이 정상 완료됐다고 판단할 수는 없습니다. ConverseStream API

스트림에서는 messageStart로 메시지가 시작되고 contentBlockDelta에 텍스트 등 내용 조각이 들어올 수 있습니다. contentBlockIndex로 같은 블록의 조각을 구분하며, contentBlockStop 이후 messageStop에서 종료 이유를 확인합니다. metadata에는 토큰 사용량 등이 포함될 수 있습니다. 도구 요청이나 기타 블록은 텍스트와 구조가 다릅니다. ConverseStream 이벤트 구조

아래는 텍스트 응답의 조각을 블록별로 모으면서 화면에 표시하는 짧은 예시입니다. Python과 boto3, AWS 자격증명, 스트리밍을 지원하는 모델의 접근 조건과 bedrock:InvokeModelWithResponseStream 권한이 필요합니다. REGION과 MODEL_ID를 실제 값으로 바꾸며 호출에는 요금이 발생할 수 있습니다. 스트리밍 지원과 권한

연결 중단·취소·재연결 처리

브라우저 연결과 애플리케이션에서 Bedrock으로 여는 스트림은 서로 다른 연결입니다. 브라우저가 닫혔다는 사실만으로 서버 측 작업이 어떤 상태가 되었는지 단정하지 말고, 서버가 받은 이벤트와 작업 상태를 기준으로 처리해야 합니다.

연결이 끊기거나 스트림 처리 중 예외가 발생하면 사용자에게 부분 답변을 미완료로 표시하고, 성공적으로 끝난 대화 이력과 구분합니다. messageStop을 받았다면 stopReason도 확인해야 하며, 출력 상한이나 도구 요청처럼 일반적인 답변 완료와 다른 이유일 수 있습니다.

ConverseStream 재연결이 이전 생성의 정확한 지점부터 자동으로 이어진다고 가정하지 않습니다. 재시도한다면 새 요청으로 다루고 중복 표시와 추가 사용량을 고려합니다. 도구가 실제 업무를 변경하는 흐름에서는 실행 여부 확인과 중복 방지를 별도로 설계합니다.

사용자 취소를 제공한다면 화면 표시 중단, 서버의 스트림 정리, 이미 실행된 도구 작업의 상태를 각각 관리합니다. 취소 버튼을 눌렀다는 이유만으로 이미 실행된 외부 작업까지 되돌아갔다고 표시해서는 안 됩니다.

긴 대화의 컨텍스트와 비용 관리

이전 메시지와 안내문을 계속 다시 보내면 요청의 입력이 커집니다. 모델의 입력·출력 한도를 확인하고 필요한 대화만 선택하거나 이전 내용을 요약할 수 있습니다. 요약할 때 신청 대상이나 예외 조건이 빠지지 않았는지 평가해야 합니다.

지원되는 모델과 엔드포인트에서는 CountTokens로 추론 전 입력 토큰 수를 확인할 수 있습니다. 지원 방식은 모델별로 다르며, 스트림이 정상적으로 metadata까지 전달된 경우 usage를 통해 실제 사용량을 확인할 수 있습니다. 중간에 연결이 끊기면 해당 메타데이터를 받지 못할 수 있습니다. 입력 토큰 계산

비용은 모델과 요금 방식, 실제 입력·출력 사용량 등에 따라 달라집니다. 대화 이력 재전달과 재시도로 입력이 늘어날 수 있으므로 선택한 모델의 현재 요금과 기록 정책을 함께 검토합니다. Bedrock 요금 안내

모델별 요청 형식이 다른 이유

사내 안내 도우미가 같은 질문을 두 모델에 보낸다고 가정해 보겠습니다. 질문은 같아도 각 모델이 요구하는 메시지·생성 설정의 필드 이름과 반환 구조는 다를 수 있습니다. 텍스트 생성, 이미지 생성, 임베딩처럼 작업의 입력과 출력 자체가 다른 경우도 있습니다.

Converse는 메시지를 지원하는 모델에 공통 형식을 제공하고, 일부 모델별 필드는 별도로 전달할 수 있습니다. InvokeModel은 선택한 모델이 기대하는 요청 본문을 사용합니다. 따라서 모델 ID만 바꾸고 기존 본문을 그대로 보내면 형식 오류가 생기거나 의도한 기능을 사용하지 못할 수 있습니다. Invoke API 요청 · Converse API

InvokeModel은 bedrock-runtime 엔드포인트에서 사용합니다. 모델별 API·입출력 지원은 다르므로 요청을 만들기 전에 모델 카드와 공식 문서를 확인합니다. 모델별 API 호환성

InvokeModel의 입력·출력 처리

InvokeModel 요청에는 모델 또는 추론 프로파일을 가리키는 modelId와 모델별 입력을 담은 body가 들어갑니다. contentType은 보내는 본문의 형식이며 accept는 원하는 응답 형식을 나타냅니다. 지원되는 값과 응답 유형은 API 및 모델 문서를 확인해야 합니다. InvokeModel 요청과 응답

아래 예시는 Anthropic Claude Messages 형식을 지원하는 모델을 호출합니다. Python과 boto3, AWS 자격증명, 해당 모델의 접근 조건 및 bedrock:InvokeModel 권한이 준비되어 있어야 합니다. REGION은 실제 호출 리전, MODEL_ID는 그 리전에서 이 형식과 InvokeModel을 지원하는 모델 또는 프로파일 ID로 바꿉니다. 호출에는 요금이 발생할 수 있습니다. Claude Messages 요청 필드

안내문은 가상의 문장입니다. anthropic_version과 max_tokens, messages는 이 모델 형식의 본문에 들어갑니다. body를 JSON 문자열로 변환해 보내고, 응답 body에서 JSON을 읽은 뒤 텍스트 블록을 출력합니다.

Messages·Responses·Chat Completions 계열 인터페이스 구분

Messages는 Anthropic 계열의 메시지 인터페이스이고, Responses와 Chat Completions는 OpenAI 호환 인터페이스입니다. InvokeModel의 Claude Messages 본문과 Messages 엔드포인트를 통한 요청은 사용하는 인터페이스가 관련되어 있어도 호출 주소와 인증·요청 방법을 구분해야 합니다.

Bedrock은 지원되는 모델에 대해 bedrock-runtime과 bedrock-mantle에서 호환 API를 제공합니다. 같은 Responses API라도 두 엔드포인트의 기능이 동일하지 않습니다. 예를 들어 AWS는 bedrock-runtime의 Responses 요청이 동기식이며 일부 서버 측 기능을 지원하지 않는다고 안내합니다. Bedrock 추론 엔드포인트 · Responses API 지원 조건

호환 형식은 기존 코드를 이전하는 데 도움이 될 수 있지만, 모든 모델이 모든 API·입력 형식·도구 기능을 지원한다는 뜻은 아닙니다. 선택한 모델 카드에서 엔드포인트와 API, 필요한 기능을 함께 확인합니다.

기존 애플리케이션을 연결할 때 달라지는 부분

기존 애플리케이션을 Bedrock에 연결할 때는 먼저 모델과 엔드포인트를 고르고, 그 조합에 맞는 주소와 인증 방식을 확인합니다. AWS 자격증명 서명 또는 지원되는 API 키를 사용하더라도 실제 호출 주체에 필요한 IAM 권한이 있어야 합니다. 엔드포인트별 인증과 권한

그다음 시스템 지시와 사용자 메시지, 생성 설정, 도구 정의, 이미지 입력을 새 API의 필드에 맞춥니다. 응답에서는 텍스트만이 아니라 종료 이유와 도구 요청, 오류, 스트리밍 이벤트를 애플리케이션이 어떻게 처리하는지도 확인해야 합니다.

대화 이력과 응답 저장 방식도 API 및 설정에 따라 다릅니다. 기존 시스템이 이력을 직접 보관했는지, 서버 측 상태를 사용했는지 확인하고 데이터 처리·로그·보관 정책을 새 경로와 대조합니다. 같은 이름의 API라는 이유로 저장 위치나 수명을 추측해서는 안 됩니다.

지원하지 않는 기능과 요청 형식 오류

요청이 ValidationException 등 형식 오류로 거부되면 모델·리전·엔드포인트·API 조합을 먼저 확인합니다. 그다음 해당 모델이 요구하는 필수 필드와 이름, 자료형, 값의 허용 범위, contentType을 확인합니다. 한 모델의 예제를 다른 모델에 그대로 적용한 경우도 점검합니다.

인증이나 권한 오류는 본문 형식 오류와 분리해 살펴봅니다. InvokeModel에는 bedrock:InvokeModel 권한이 필요하며 프로파일을 사용하는 경우 관련 추가 권한과 조직 정책이 적용될 수 있습니다. 모델 접근 조건이나 리전 제한도 확인해야 합니다. InvokeModel 권한과 오류

지원 기능이 부족하다면 다른 API나 모델을 검토하되, 변경 전후의 요청·응답과 데이터 경로를 공통 질문으로 평가합니다. 요청이 성공했다고 해서 모델 답변이 정확하거나 업무 규칙을 충족했다고 단정하지 않습니다.

요청과 응답의 기본 구조

사내 안내 도우미가 “장비는 어디에서 신청하나요?”라는 질문에 답하려면 애플리케이션이 모델에 질문과 필요한 안내문을 전달해야 합니다. Converse는 이처럼 메시지를 보내고 모델의 답변을 받는 공통 인터페이스입니다. 메시지를 지원하는 Bedrock 모델에 사용할 수 있으며, API는 bedrock-runtime 엔드포인트에서 제공됩니다. Converse API 개요

요청에서 modelId는 사용할 모델 또는 추론 프로파일을 가리킵니다. messages에는 사용자 질문과 필요에 따라 이전 대화를 담고, system에는 답변 방식 같은 시스템 지시를 넣을 수 있습니다. inferenceConfig는 출력 길이 등 생성 설정을 지정할 때 사용합니다.

응답의 output.message에는 모델이 반환한 메시지가 들어갑니다. stopReason은 생성이 멈춘 이유, usage는 토큰 사용량, metrics는 호출 지표를 나타냅니다. 요청 성공과 답변의 사실성이 같지는 않으므로 애플리케이션은 반환 내용을 업무 기준에 따라 평가해야 합니다. Converse 요청과 응답

사용자·모델 메시지와 시스템 지시

messages의 각 항목은 role과 content로 구성됩니다. role이 user면 사용자 메시지, assistant면 모델의 이전 응답을 나타냅니다. content는 내용 블록의 배열이며, 텍스트는 text 블록으로 전달합니다. 모델과 API가 지원하는 경우 다른 콘텐츠 유형도 사용할 수 있습니다. Converse 메시지와 콘텐츠

시스템 지시는 messages 바깥의 system 필드에 둡니다. 예를 들어 “제공된 안내문을 바탕으로 답하고 정보가 부족하면 알려 달라”고 요청할 수 있습니다. 실제 질문과 안내문은 user 메시지에 담습니다. 시스템 지시는 답변 방향을 제시하지만 정확한 답이나 업무 권한을 보장하지 않습니다.

대화를 이어가려면 애플리케이션이 필요한 이전 user와 assistant 메시지를 다음 Converse 요청에 포함해야 합니다. 대화 이력의 저장·보존과 사용자별 분리는 애플리케이션 설계에 달려 있습니다. 별도로 활성화한 호출 로그나 연결 저장소의 보관 설정도 따로 확인합니다.

Prompt Management의 프롬프트 버전을 modelId로 사용하는 경우에는 system, inferenceConfig 등 일부 필드를 요청에 직접 넣을 수 없습니다. 이 경우 해당 설정은 프롬프트에서 정의해야 하므로 일반 모델 ID 호출과 구분합니다. Converse 요청 제약

생성 설정의 의미와 모델별 차이

inferenceConfig의 maxTokens는 생성할 출력 토큰의 최대치입니다. 너무 작으면 문장이 끝나기 전에 생성이 멈출 수 있지만, 상한을 늘린다고 반드시 긴 답변이 나오거나 사실성이 좋아지지는 않습니다.

temperature는 다음 토큰을 고를 때 선택의 다양성에 영향을 줍니다. 값을 낮추면 더 가능성이 높은 선택에 무게가 실리지만 동일한 답변이나 정답을 보장하지는 않습니다. topP와 stopSequences도 지원되는 공통 설정이지만, 각 모델의 지원 범위와 조합 조건을 확인해야 합니다. 추론 설정 · 생성 파라미터 의미

이 필드들은 선택 사항이며 생략할 수 있습니다. 생략 시 기본값은 모델별로 다를 수 있으므로 특정 값을 임의로 가정하지 않습니다. 모델별 고유 설정이 필요한 경우 additionalModelRequestFields를 사용할 수 있지만, 해당 필드의 이름과 지원 값은 모델 문서를 따릅니다.

응답 종료 이유와 사용량 정보

stopReason이 end_turn이면 모델이 해당 응답 생성을 마친 경우입니다. max_tokens이면 출력 토큰 상한에 도달한 경우이므로 답변이 잘렸는지와 maxTokens 설정을 살펴볼 수 있습니다. stop_sequence는 지정한 중단 문자열을 만나 멈춘 경우입니다. Converse 종료 이유

tool_use는 모델이 도구 사용을 요청한 상태이므로 단순 최종 답변과 구분해야 합니다. Guardrails나 콘텐츠 필터에 따른 종료 등 다른 값도 있으므로 운영 코드는 모든 종료 이유를 같은 성공 결과로 처리하지 않아야 합니다.

usage의 inputTokens와 outputTokens는 각각 요청 입력과 생성된 출력의 토큰 수이고 totalTokens는 그 합계입니다. 사용량은 비용을 이해하는 데 도움이 되지만, 금액은 모델·요금 방식과 캐시 등 실제 적용 조건을 따로 확인해야 합니다. 토큰 사용량 필드

짧은 호출 코드와 필드별 해설

다음은 Python용 AWS SDK인 boto3를 사용하는 가상의 안내 도우미 예시입니다. boto3와 자격증명 설정, 모델 접근 조건, bedrock:InvokeModel 권한이 필요합니다. REGION은 실제 요청을 보낼 리전 코드로, MODEL_ID는 그 리전과 Converse를 지원하는 모델 또는 추론 프로파일 ID로 바꿉니다. 호출은 사용량에 따라 비용이 발생할 수 있습니다. 모델별 API 호환성

안내문은 예시를 위해 직접 만든 문장입니다. 코드의 system은 답변 조건을, messages는 안내문과 현재 질문을 전달합니다. 모델은 이 문장을 근거로 답할 수 있지만 실제 사내 포털을 조회하지는 않습니다.

관리 API와 추론 API의 차이

사내 서비스 안내 도우미를 만든다고 가정하겠습니다. 먼저 사용 가능한 모델을 살펴보고, 선택한 모델에 직원의 질문과 안내문을 전달해야 합니다. 두 작업은 모두 Bedrock과 통신하지만 목적이 다릅니다.

관리 API는 모델이나 관련 리소스의 정보를 조회하고 설정을 관리할 때 사용합니다. 예를 들어 ListFoundationModels는 기반 모델 목록을 확인하는 관리 작업입니다. 모델에 질문을 보내 답변을 생성하는 작업은 아닙니다. Bedrock 모델 탐색

추론 API는 모델에 입력을 전달하고 결과를 받는 데 사용합니다. 도우미가 선택한 모델에 질문을 보내는 Converse와 모델별 요청 본문을 사용하는 InvokeModel이 그 예입니다. 모델을 목록에서 확인할 수 있다는 사실만으로 추론 권한이 자동으로 허용되는 것은 아닙니다. Bedrock 추론 API

SDK 클라이언트와 엔드포인트의 관계

엔드포인트는 요청을 받는 서비스 주소입니다. AWS SDK에서 클라이언트를 만들 때 서비스와 리전을 지정하면 SDK가 해당 서비스의 엔드포인트를 선택합니다. 모델 ID는 요청에서 추론 대상을 지정하는 값이고 엔드포인트 주소는 요청을 보내는 곳입니다.

예를 들어 Python용 AWS SDK인 boto3에서는 관리 작업을 위해 bedrock 클라이언트를, Bedrock Runtime 추론 작업을 위해 bedrock-runtime 클라이언트를 만듭니다. 아래 코드는 클라이언트가 사용할 주소를 살펴보는 구성 예시입니다. boto3가 설치된 환경에서 REGION을 실제 사용할 AWS 리전 코드로 바꿉니다. 모델 호출 코드는 포함하지 않습니다. Bedrock 추론 엔드포인트

Converse·InvokeModel·호환 API의 구분

Converse는 메시지를 지원하는 모델에 공통 대화 형식으로 요청하는 API입니다. InvokeModel은 모델별 요청 본문을 사용하므로 선택한 모델의 필드와 응답 형식을 확인해야 합니다. 두 API는 bedrock-runtime 엔드포인트에서 사용합니다. Converse 사용 조건 · Invoke API

Responses와 Chat Completions는 OpenAI 호환 형식이고, Messages는 Anthropic 계열 인터페이스입니다. 기존 애플리케이션과 형식을 맞추는 데 도움이 될 수 있지만, 같은 이름의 API라도 모델과 엔드포인트별 지원 기능은 다를 수 있습니다.

AWS는 대부분의 신규 애플리케이션에 bedrock-runtime을 권장하며, bedrock-mantle은 해당 엔드포인트에만 제공되는 기능이 필요한 경우 고려하도록 안내합니다. 예를 들어 서버 측 도구나 백그라운드 추론은 해당 API와 엔드포인트의 지원 조건을 확인해야 합니다. 엔드포인트별 기능 비교

인증 방식과 모델별 지원 조건

AWS SDK를 사용하는 일반적인 방식에서는 프로그램이 AWS 자격증명을 사용해 요청에 서명합니다. 지원되는 엔드포인트에서는 Bedrock API 키를 사용하는 방식도 있습니다. 어떤 인증을 선택하든 연결된 IAM 신원에 필요한 권한이 있어야 하며, 키를 코드나 공개 문서에 넣지 않아야 합니다. 엔드포인트별 인증

bedrock-runtime의 Converse와 InvokeModel에는 bedrock:InvokeModel 권한이 필요하고, 해당 스트리밍 API에는 bedrock:InvokeModelWithResponseStream 권한이 필요합니다. 추론 프로파일이나 다른 리소스를 사용하면 추가 권한이 필요할 수 있으며, SCP를 포함한 적용 정책의 명시적 거부도 확인해야 합니다. 추론 권한

bedrock-mantle의 추론 인가에는 bedrock-mantle:CreateInference가 사용됩니다. 엔드포인트를 바꾸면서 기존 권한이 그대로 적용된다고 가정하지 말고 API·모델·리전과 권한을 함께 확인해야 합니다. 엔드포인트별 권한 · 모델별 API 호환성

교차 리전 추론 프로파일을 선택하면 요청을 보낸 리전과 실제 처리되는 리전이 다를 수 있습니다. 엔드포인트의 리전과 프로파일의 후보 대상 리전, 관련 IAM·조직 정책을 함께 살펴봐야 합니다. 교차 리전 추론

API 선택이 애플리케이션에 미치는 영향

도우미가 Converse를 사용한다면 애플리케이션은 메시지 배열과 역할을 구성하고 응답의 콘텐츠 블록을 읽습니다. InvokeModel을 선택하면 같은 업무라도 모델이 요구하는 요청 본문을 만들어야 하고, 반환 본문도 해당 모델의 형식에 맞춰 처리해야 합니다.

기존 앱을 호환 API로 옮길 때도 주소만 바꿔 모든 기능이 같다고 가정하면 안 됩니다. 시스템 지시, 이미지 입력, 도구 사용, 응답 저장, 스트리밍 이벤트와 오류 처리의 지원 범위를 선택한 모델·엔드포인트와 대조해야 합니다.

호출이 실패하면 먼저 실제 호출 주체와 엔드포인트·리전을 확인합니다. 이후 모델 ID와 API 호환성, 인증·권한, 요청 형식과 할당량을 오류 종류에 맞춰 나누어 확인합니다. 모델 호출에는 사용량에 따른 요금이 발생할 수 있으므로 평가 전 선택한 모델과 방식의 요금도 확인합니다.