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

직원이 장비 신청 안내문의 사진을 올리고 “어디에서 신청하나요?”라고 묻는다고 가정하겠습니다. 텍스트 질문만 받는 도우미라면 사진 내용을 처리할 수 없습니다. 이미지 입력을 지원하는 모델과 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 호환성, 인증·권한, 요청 형식과 할당량을 오류 종류에 맞춰 나누어 확인합니다. 모델 호출에는 사용량에 따른 요금이 발생할 수 있으므로 평가 전 선택한 모델과 방식의 요금도 확인합니다.

콘솔·CLI·SDK의 역할

사내 안내 도우미가 직원의 질문에 답하도록 모델을 연결한다고 가정하겠습니다. 먼저 AWS 계정과 사용할 리전을 정하고 모델이 해당 리전에서 필요한 API를 지원하는지 확인해야 합니다. 이 글에서는 Bedrock Runtime 엔드포인트의 Converse API를 예로 살펴봅니다. Bedrock 모델 지원 조건

AWS 관리 콘솔은 브라우저에서 모델 목록과 설정을 살펴보는 화면입니다. AWS CLI는 터미널에서 AWS API를 호출하는 도구이고, SDK는 Python이나 Java 등 애플리케이션 코드에서 AWS API를 호출할 수 있도록 제공되는 도구입니다. 세 방법 모두 실제 요청을 보내는 AWS 신원과 그 신원에 적용되는 권한이 중요합니다.

예를 들어 개발자가 콘솔에서 모델을 볼 수 있어도, 나중에 서버에서 실행하는 도우미가 같은 신원과 권한을 쓴다는 뜻은 아닙니다. 모델을 사용할 프로그램이 어디에서 실행되는지 먼저 정해야 호출 주체를 올바르게 확인할 수 있습니다.

모델 접근 조건과 이용 절차

먼저 Bedrock 모델 목록에서 필요한 모델을 선택하고, 모델 카드에서 요청을 보낼 리전과 사용할 API의 지원 여부를 확인합니다. 모델 ID와 추론 프로파일 ID는 호출 대상이 다를 수 있으므로 사용할 경로에 맞는 값을 확인해야 합니다. 모델 가용성과 호환성

AWS는 다수의 기반 모델에 대해 필요한 조건이 충족되면 기본 접근이 가능하다고 안내합니다. 다만 일부 모델은 AWS Marketplace 관련 권한, 유효한 결제 수단, 제공자별 이용 조건이나 추가 계정 접근이 필요할 수 있습니다. 모든 모델에 별도의 수동 접근 신청이 필요하거나, 반대로 어떤 준비도 필요 없다고 일반화해서는 안 됩니다. 모델 접근 조건

특히 서드파티 모델은 계정에서 최초 호출할 때 Marketplace 구독 절차가 시작될 수 있으며 이용 약관이 적용됩니다. 일부 제공자는 최초 사용 정보를 요구하고, 조건은 모델과 엔드포인트에 따라 달라질 수 있습니다. 호출 전에 관련 요금과 이용 조건을 확인하고 조직에서 정한 절차에 따라 준비합니다.

계정 차원의 모델 이용 조건과 개별 호출자의 권한은 별개입니다. 모델을 계정에서 사용할 수 있더라도 도우미의 실행 역할에 필요한 호출 권한이 없다면 요청은 거부될 수 있습니다.

사용자 자격증명과 실행 역할

자격증명은 AWS가 요청을 보낸 신원을 확인하는 데 사용됩니다. 개발자가 사용하는 CLI 프로파일과 AWS에서 실행되는 도우미의 실행 역할은 서로 다른 신원일 수 있습니다. 권한을 점검할 때는 개발자 본인이 아니라 문제가 발생한 요청이 실제로 사용한 신원을 확인해야 합니다.

사람의 개발 환경에서는 조직이 제공하는 로그인 방식과 임시 자격증명 등을 사용하고, AWS에서 실행되는 프로그램에는 해당 실행 환경에 연결한 역할을 사용하는 방식이 일반적입니다. SDK는 환경에 설정된 자격증명 공급 경로를 통해 신원을 찾으며, 설정에 따라 의도와 다른 자격증명이 선택될 수 있습니다. 자격증명이나 키를 코드와 게시용 글에 넣지 않습니다. AWS SDK 자격증명 공급 방식

Bedrock Runtime의 Converse 호출에는 해당 호출 주체의 bedrock:InvokeModel 권한이 필요합니다. 스트리밍 응답을 사용하는 ConverseStream에는 bedrock:InvokeModelWithResponseStream 권한이 필요합니다. 추론 프로파일이나 다른 리소스를 사용하면 관련 추가 권한과 적용 범위를 별도로 확인해야 합니다. IAM에서 허용해도 SCP 등 적용 정책의 명시적 거부는 호출을 막을 수 있습니다. 모델 추론 권한

다음 명령은 로컬 CLI가 선택한 프로파일의 신원을 확인할 때 사용합니다. PROFILE은 환경에 구성된 프로파일 이름으로 바꾸세요. 이 명령은 STS에 요청하며, 출력에는 계정과 역할 식별 정보가 포함될 수 있으므로 공개하지 않습니다. get-caller-identity 명령

서비스 할당량과 사용 가능 여부

서비스 할당량은 계정이 일정 시간 동안 사용할 수 있는 요청 또는 토큰 등의 한도입니다. 적용되는 항목은 모델, 리전, 호출 방식과 엔드포인트에 따라 다를 수 있으므로 실제 사용할 조합의 할당량을 확인합니다. 수치가 높다고 모든 요청이 즉시 처리된다는 보장은 없습니다. Bedrock 할당량

Bedrock Runtime과 Bedrock Mantle은 각각 별도의 모델별 할당량을 사용합니다. 이 글의 Converse는 Bedrock Runtime을 이용하므로 그 엔드포인트에 적용되는 모델·리전·호출 방식의 항목을 살펴봅니다. 교차 리전 추론을 사용한다면 해당 프로파일의 할당량과 후보 처리 리전도 확인합니다. 교차 리전 추론

짧은 시간에 요청이 몰려 제한 오류가 발생하면 단순히 권한을 추가하기보다 적용 할당량과 요청량을 확인합니다. 필요한 경우 요청 속도를 조절하고 일시적 오류에 재시도를 설계하거나, 조정 가능한 항목에 대해 할당량 증가를 요청합니다.

첫 호출 전에 확인할 환경 체크리스트

첫째, 사용할 AWS 계정과 요청을 보낼 리전을 확인합니다. 교차 리전 추론 프로파일을 선택한다면 실제 처리 후보 리전과 조직 정책도 따로 살펴봅니다.

둘째, 모델 ID 또는 프로파일 ID, 사용할 API와 필요한 입력·출력 기능이 서로 호환되는지 확인합니다. 계정에 필요한 모델 접근 조건과 이용 약관, 결제 조건이 있는지도 확인합니다.

셋째, 실제 호출 주체를 확인하고 해당 모델이나 프로파일을 호출할 IAM 권한과 적용되는 조직 정책을 검토합니다. 애플리케이션이 문서나 업무 시스템을 사용한다면 그 대상에 대한 접근 권한은 별도로 필요합니다.

넷째, 적용 할당량과 예상 사용량·요금을 확인합니다. 실제 업무 정보를 보내기 전에는 데이터 처리 경로와 별도로 구성한 로그의 보관 범위도 살펴봅니다.

이 조건들이 갖춰진 뒤에도 오류가 발생하면 오류 종류에 따라 신원·권한, 모델 접근 조건, 요청 형식과 할당량을 나누어 확인합니다. 접근 거부와 요청량 제한은 원인이 다릅니다. Bedrock 추론 엔드포인트

텍스트·임베딩·이미지·음성·영상 모델의 역할

사내 안내 도우미에 쓸 모델을 고른다고 가정하겠습니다. 직원이 텍스트로 질문하고 안내문을 바탕으로 답변을 받는다면, 우선 텍스트를 입력받아 텍스트를 생성하는 모델이 필요합니다.

안내문이 많아 관련 문서를 검색하려면 문서와 질문을 숫자 벡터로 바꾸는 임베딩 모델이 필요할 수 있습니다. 임베딩은 검색에 쓸 표현을 만드는 작업이고, 답변 생성은 검색된 내용을 읽어 문장을 만드는 작업입니다. 두 역할을 같은 모델이 반드시 수행하는 것은 아닙니다.

직원이 사진을 올려 설명을 요청하거나 음성으로 대화하려면 해당 입력을 지원하는 모델이 필요합니다. 이미지나 영상 자체를 생성하는 작업은 또 다른 출력 기능입니다. “멀티모달 모델”이라는 이름만 보고 모든 입력과 출력을 지원한다고 가정하지 말고 모델별 지원 형식을 확인합니다. Bedrock 모델 기능과 지원 범위

모델별 입력·출력과 지원 기능

모델 후보를 고를 때는 먼저 어떤 정보를 넣고 어떤 결과를 받을지 정합니다. 예를 들어 안내문 파일를 직접 전달할지, 추출한 텍스트만 보낼지에 따라 필요한 입력 기능이 달라집니다. 문서의 형식·크기·개수와 컨텍스트 한도도 선택한 모델과 API에서 확인해야 합니다.

도우미에 답변을 조금씩 보여 주려면 스트리밍을, 신청 상태를 조회할 계획이라면 도구 사용을 지원하는지도 확인합니다. JSON 형태의 결과가 필요하다면 단순히 프롬프트에 JSON을 요청하는 것과 스키마 기반 구조화 출력을 지원하는 것은 다르다는 점도 살펴봐야 합니다.

Converse를 지원하는 모델이라도 모든 콘텐츠 유형과 부가 기능이 동일한 것은 아닙니다. 모델 카드와 API별 호환성에서 필요한 조합을 확인한 뒤 후보를 남깁니다. 모델별 API 호환성

모델·리전·호출 방식의 지원 조건

같은 모델이라도 모든 AWS 리전과 엔드포인트에서 같은 API를 지원하는 것은 아닙니다. 먼저 애플리케이션이 요청을 보낼 리전, 모델 ID 또는 추론 프로파일, API와 필요한 기능을 한 묶음으로 확인합니다. 모델을 선택한 뒤 모델 카드의 리전 및 엔드포인트별 지원 내용을 보는 것이 안전합니다. 모델 가용성과 호환성

교차 리전 추론 프로파일을 사용하면 요청을 보낸 리전과 모델이 실제 처리되는 리전이 다를 수 있습니다. 처리 위치에 제한이 있다면 후보 대상 리전과 조직 정책을 함께 검토합니다. 한 요청이 여러 리전에 나뉘어 계산된다는 의미는 아닙니다. 교차 리전 추론

이용 가능 여부는 지원 목록만으로 끝나지 않습니다. 모델 접근 조건, 호출 주체의 권한, 조직의 제한과 할당량도 확인해야 합니다. 권한이 없거나 호출 경로가 제한되면 모델이 목록에 보여도 애플리케이션 요청은 실패할 수 있습니다.

예상 비용은 모델과 처리 방식, 입력과 출력의 양에 따라 비교합니다. 검색을 함께 사용한다면 임베딩, 저장소와 검색 비용도 고려합니다. 실제 요금과 적용 조건은 선택한 구성의 요금표를 확인합니다. Bedrock 요금 안내

공통 질문으로 비교 평가하는 방법

후보를 두 개 골랐다고 가정하겠습니다. 사내 도우미라면 같은 안내문과 질문을 두 모델에 전달하고, 정확한 절차를 말하는지, 필요한 조건을 빠뜨리지 않는지, 안내문에 없는 내용을 지어내지 않는지를 비교할 수 있습니다.

질문은 일반적인 신청 방법만 모으지 않습니다. 예외 조건이 있는 질문, 안내문에 답이 없는 질문, 추가 확인이 필요한 모호한 질문도 포함합니다. 정답에 포함되어야 할 근거와 허용할 수 없는 오류를 미리 적어 두면 평가자의 느낌만으로 선택할 가능성을 줄일 수 있습니다.

가능한 한 같은 입력과 출력 조건을 사용하고 모델 ID, 리전, API, 생성 설정과 실행 시점을 기록합니다. 모델별 지원 설정이 같지 않다면 차이를 기록한 뒤 결과를 해석합니다. 답변이 달라질 수 있으므로 한 번의 결과만으로 품질을 단정하지 않습니다.

속도는 첫 응답이 나타나는 시간과 전체 답변이 끝나는 시간을 구분해 측정합니다. 두 수치는 네트워크, 입력 길이와 요청 부하에도 영향을 받으므로 같은 조건에서 비교합니다. 토큰 기반 요금이 적용되는 구성이라면 입력·출력 사용량과 단가를 분리해 예상 비용을 계산하고, 도구나 검색을 포함한 전체 경로도 살펴봅니다.

Bedrock에는 자동 평가, 평가 모델을 이용한 평가와 사람의 평가 등 여러 평가 방식이 있습니다. 평가 점수는 검토에 도움을 주지만 업무상 중요한 오류를 자동으로 모두 찾아낸다고 가정하지 말고, 평가 기준과 표본을 함께 확인합니다. Bedrock 모델 평가

모델 버전과 수명주기 변경에 대응하는 기준

선택한 모델의 ID와 추론 프로파일, 리전, API, 프롬프트와 평가 결과를 함께 기록합니다. 모델을 바꾸면 입력 형식과 기능 지원, 답변 형식, 속도와 비용이 달라질 수 있으므로 기존 평가 질문으로 새 후보를 다시 비교합니다.

AWS는 모델 수명주기를 Active, Legacy, End-of-Life로 안내합니다. 모델의 출시 시점과 모델 카드에 따라 적용되는 정책이 다르므로, 현재 모델의 상태·종료 일정과 적용 문서를 확인해야 합니다. 기존 모델이 종료된 뒤에는 요청이 실패할 수 있으며, 전환이 자동으로 이루어진다고 가정해서는 안 됩니다. 모델 수명주기 · 이전 모델 수명주기 정책

대체 모델을 미리 선정하고 지원 API와 처리 리전, 권한과 출력 형식을 확인합니다. 중요한 업무라면 새 버전을 일부 평가한 후 전환하고, 문제가 있을 때 복구할 수 있는 경로를 준비합니다. 단, 이전 모델이 이미 종료됐거나 접근이 제한됐다면 되돌릴 수 없으므로 그 조건도 함께 확인합니다.

모델 호출을 중심으로 기능을 분류하는 방법

직원이 사내 도우미에 “신청 절차를 알려줘”라고 묻는 상황을 생각해 보겠습니다. 가장 단순한 구성에서는 애플리케이션이 질문과 필요한 안내문을 모델에 보내고 답변을 받습니다. 이때 모델을 호출해 응답을 생성하는 단계가 추론입니다. Converse 모델 호출

이후 필요한 문제가 달라지면 구성을 확장합니다. 안내문이 많아지면 관련 문서를 찾는 검색이 필요하고, 개인의 신청 상태를 확인하려면 업무 시스템에 조회를 요청해야 합니다. 입력과 출력에 적용할 콘텐츠 기준이나 여러 단계를 관리할 운영 기능도 필요에 따라 추가할 수 있습니다.

아래 표는 기능을 고르는 출발점입니다. 지원 모델·API·리전과 세부 조건은 각 기능에서 따로 확인해야 합니다.

지식 연결과 도구 실행의 차이

직원이 “신청하려면 무엇이 필요한가요?”라고 물으면 최신 안내문에서 해당 조건을 찾는 것이 도움이 됩니다. RAG는 외부 정보에서 관련 내용을 검색해 모델이 답변을 생성할 때 활용하는 방식입니다. Bedrock Knowledge Bases는 연결된 데이터에서 관련 정보를 검색하고 생성형 AI 애플리케이션에 활용하도록 돕습니다. Knowledge Bases 개요

반면 “내 신청은 승인됐나요?”라는 질문은 해당 직원의 현재 신청 상태를 업무 시스템에서 조회해야 합니다. 이때 모델이 필요한 도구를 선택하도록 구성할 수 있지만, 모델이 직접 시스템을 조회하는 것은 아닙니다. 클라이언트 측 도구 사용에서는 애플리케이션 코드가 요청을 받아 권한을 확인하고 도구를 실행한 다음 결과를 모델에 전달합니다. Bedrock 도구 사용

서버 측 도구 사용처럼 Bedrock이 도구 실행을 맡는 방식도 있으며, 지원은 API와 모델에 따라 다릅니다. 어느 쪽이 실행하든 사용자별 조회 범위와 대상 서비스의 인증·권한은 별도로 설계해야 합니다. 검색된 문서가 있다는 사실만으로 특정 사용자의 신청 정보를 조회할 권한이 생기지는 않습니다.

검색 결과가 오래되거나 적절한 문서를 찾지 못하면 답변이 잘못될 수 있습니다. 도구가 실패하면 상태 조회도 완료되지 않습니다. 문제를 확인할 때 검색 결과, 도구 실행 결과와 모델 답변을 나누어 살펴봐야 합니다.

품질 통제와 권한 통제의 차이

안내문에 근거한 답변인지, 중요한 조건이 빠지지 않았는지는 답변 품질의 문제입니다. 평가용 질문과 정답 근거를 준비하고 검색된 문서와 모델의 답변을 함께 비교해야 합니다. 콘텐츠 필터를 켰다는 사실만으로 답변이 정확하다고 단정할 수는 없습니다.

Guardrails는 설정한 정책에 따라 사용자 입력이나 모델 응답에 포함된 원치 않는 콘텐츠와 민감정보 등을 탐지·처리하는 기능입니다. 어떤 유형을 어디에서 평가할 수 있는지는 설정과 사용 경로의 지원 조건에 따릅니다. 예를 들어 특정 개인정보를 감지하도록 구성할 수 있지만 모든 민감정보를 빠짐없이 탐지한다고 가정해서는 안 됩니다. Guardrails 개요와 지원 범위

권한 통제는 “이 직원이 이 문서 또는 이 신청 건에 접근해도 되는가?”를 결정합니다. IAM, 서비스 역할과 업무 시스템의 사용자 인가 등은 각각 적용 위치가 다릅니다. Guardrails가 콘텐츠를 평가하더라도 문서 열람이나 신청 변경 권한을 대신 결정하지 않습니다.

예를 들어 다른 직원의 신청 상태를 묻는 요청이 유해 표현을 포함하지 않아도 조회를 허용하면 안 됩니다. 애플리케이션과 대상 시스템은 실제 요청자의 권한을 확인해야 합니다.

Bedrock Agents와 AgentCore의 위치

에이전트는 목표를 처리하기 위해 모델과 도구를 연결하고 필요한 단계를 진행하는 구성입니다. 모델에 질문을 한 번 보내 답변만 받는 경우보다 도구 호출과 결과를 이어 주는 흐름이 추가됩니다.

Amazon Bedrock Agents는 모델, 데이터와 업무 API를 연결하는 관리형 에이전트 기능입니다. AWS는 현재 이를 Amazon Bedrock Agents Classic으로 안내하며 신규 고객에게는 제공하지 않는다고 명시합니다. 기존 고객의 사용 조건은 해당 문서를 확인해야 합니다. Agents Classic 안내

Amazon Bedrock AgentCore는 에이전트의 구축·배포·운영을 위한 모듈형 플랫폼입니다. 예를 들어 Runtime은 에이전트 실행, Gateway는 도구 연결, Memory는 메모리 기능과 관련됩니다. 필요한 구성요소를 선택해 사용할 수 있으며, 에이전트 코드나 프레임워크 자체와 실행·운영 기반을 구분해 생각해야 합니다. AgentCore 개요

Agents Classic과 AgentCore는 이름이 비슷해도 동일한 구성이나 사용 절차가 아닙니다. 어떤 에이전트를 만들지와 별개로 선택한 모델·프레임워크·리전 및 각 서비스의 지원 조건을 확인해야 합니다.

단순한 구성부터 기능을 추가하는 순서

첫째, 한 가지 질문과 신뢰할 수 있는 가상 안내문을 정하고 모델에 함께 전달해 답변을 평가합니다. 이 단계에서는 모델이 필요한 조건을 반영하는지와 어떤 경우에 정보가 부족한지 살펴봅니다.

둘째, 문서가 많아지면 관련 내용을 찾는 검색을 추가합니다. 검색 전후의 차이를 보려면 답변뿐 아니라 실제 검색 결과도 확인해야 합니다. 검색이 실패한 경우에는 답변 생성이 정상이어도 근거가 부족할 수 있습니다.

셋째, 신청 상태 조회처럼 현재 업무 데이터가 필요할 때만 조회 도구를 연결합니다. 실행 주체, 사용자별 인가와 실패 처리를 먼저 정하고, 조회 결과를 모델에 전달해 답변하게 합니다. 변경 작업을 추가한다면 조회보다 엄격한 권한과 필요한 사용자 승인, 중복 실행 방지를 별도로 설계합니다.

마지막으로 콘텐츠 평가나 에이전트 실행·관측 기능을 필요한 위치에 더하고 전체 흐름을 평가합니다. 각 기능은 모델 호출 외의 사용량과 비용을 발생시킬 수 있으므로, 선택한 모델과 검색·도구·운영 구성의 요금을 함께 확인합니다. Bedrock 요금 안내

모델 학습과 서비스 이용 시 추론의 차이

직원이 사내 안내 도우미에 “회의실 장비는 어디에서 신청하나요?”라고 묻는다고 가정해 보겠습니다. 모델이 자연스러운 문장을 만들 수 있더라도, 그 질문만으로 이 조직의 신청 절차를 정확히 안다고 가정할 수는 없습니다.

이 차이를 이해하려면 먼저 학습과 추론을 나눠야 합니다. 학습은 모델의 매개변수를 데이터에 맞춰 조정하는 과정입니다. 매개변수는 모델이 입력을 처리해 결과를 만드는 데 영향을 주는 내부 값입니다. 기반 모델은 다양한 데이터로 사전에 학습되어 여러 작업에 활용할 수 있습니다. AWS 기반 모델 개요

추론은 이미 준비된 모델에 입력을 주고 결과를 얻는 과정입니다. 애플리케이션이 질문과 가상의 안내문을 Bedrock 모델에 보내 답변을 받는 일반적인 호출이 여기에 해당합니다. 요청에 안내문을 넣는 일 자체가 모델의 매개변수를 다시 학습시키는 것은 아닙니다.

이번 요청에 전달한 안내문과 모델 내부의 매개변수는 다른 곳에 있습니다. 다음 요청에서도 안내문이 필요하다면 애플리케이션이 필요한 정보를 다시 제공하는 방식 등을 설계해야 합니다. 모델 맞춤화는 일반 추론과 별도의 작업입니다.

토큰과 컨텍스트 창의 의미

토큰은 모델이 텍스트를 처리하는 단위입니다. 단어 하나가 언제나 토큰 하나인 것은 아닙니다. 같은 문장도 모델의 토큰화 방식에 따라 나뉘는 결과가 달라질 수 있으므로, 글자 수만으로 정확한 토큰 수를 계산할 수 없습니다. AWS 입력 토큰 계산

컨텍스트는 모델이 이번 답변을 만들 때 활용하도록 전달된 정보입니다. 예를 들어 답변 지시, 현재 질문, 이전 대화, 사내 안내문이 포함될 수 있습니다. 컨텍스트 창은 모델이 한 번의 처리 과정에서 다룰 수 있는 정보량의 한도입니다.

Converse API에서 대화 맥락을 유지하려면 애플리케이션이 필요한 이전 메시지를 다음 요청에 포함합니다. 질문이 여러 번 이어졌다는 이유만으로 모델이 이전 메시지를 자동으로 다시 받는다고 생각하면 안 됩니다. 다른 API의 상태 관리 방식은 별도로 확인해야 합니다. Converse 대화 이력

도우미에 전달할 내용을 한눈에 보면 다음과 같습니다. 아래 내용은 형식을 설명하기 위한 가상의 입력이며 API 요청 전체는 아닙니다.

입력·출력 길이가 응답에 미치는 영향

입력이 모델의 허용 한도를 넘으면 요청이 오류로 거부될 수 있습니다. 허용 범위 안에 있더라도 오래된 대화와 무관한 문서를 계속 더하면 필요한 근거를 골라 검토하기 어려워지고 입력 사용량이 늘어납니다.

먼저 현재 질문에 필요한 안내문과 이전 대화를 고릅니다. 문서를 줄일 때는 신청 대상이나 예외 조건처럼 답을 바꿀 수 있는 내용이 빠지지 않았는지 살펴봐야 합니다. 특정 모델의 입력·출력 한도와 계산 방식은 해당 모델 문서에서 확인합니다.

출력도 별도로 계획해야 합니다. Converse의 maxTokens는 생성할 토큰의 최대치입니다. 값이 너무 작으면 답변이 중간에 멈출 수 있지만, 크게 설정한다고 매번 그만큼 생성하거나 더 정확하게 답하는 것은 아닙니다. 이 값은 선택 사항이며 모델별 기본값과 범위를 확인해야 합니다. Converse 추론 설정

답변이 끝나지 않은 것 같다면 종료 이유와 출력 상한을 함께 확인합니다. 지원되는 모델에서는 CountTokens로 추론 전에 입력 토큰 수를 확인할 수 있습니다. 이 API는 생성될 출력 길이를 미리 알려 주지 않으며, 모델·엔드포인트별 지원 조건이 다릅니다. CountTokens 지원 조건

확률적 생성과 답변이 달라지는 이유

텍스트 생성 모델은 현재까지의 입력과 출력에 따라 다음에 올 토큰 후보의 가능성을 계산하고, 이를 바탕으로 출력을 이어갑니다. 예를 들어 같은 신청 안내문을 주더라도 “포털에서 신청하세요”와 “장비 메뉴를 이용하세요”처럼 표현이 달라질 수 있습니다. 표현의 차이와 사실의 정확성은 따로 판단해야 합니다. AWS 생성 파라미터

temperature는 생성 과정에서 선택의 다양성에 영향을 주는 설정입니다. 일반적으로 낮은 값은 가능성이 높은 후보에 더 무게를 두고, 높은 값은 상대적으로 다양한 후보가 선택될 가능성을 높입니다. 기본값과 허용 범위는 모델마다 다를 수 있습니다.

값을 낮춰도 사실 여부가 보장되거나 모든 호출이 완전히 같은 결과를 낸다고 단정할 수 없습니다. 모델 버전, 지시, 안내문, 대화 이력이나 설정이 달라져도 답변이 달라질 수 있으므로 품질을 비교할 때는 입력과 조건을 함께 기록해야 합니다.

모델이 알고 있는 정보와 외부에서 전달해야 하는 정보

모델은 사전 학습을 통해 일반적인 언어와 여러 주제의 패턴을 익혔지만, 특정 조직의 최신 안내문이나 개인의 현재 신청 상태를 자동으로 알고 있다고 보장할 수 없습니다. 그럴듯한 문장도 근거 없이 만들어질 수 있습니다.

회의실 장비 신청 방법을 묻는다면 애플리케이션은 접근이 허용된 최신 안내문을 요청에 전달할 수 있습니다. 개인의 신청 상태는 문서 설명과 달리 업무 시스템의 현재 데이터를 조회해야 하므로, 사용자 인증과 조회 권한을 확인한 연결이 별도로 필요합니다.

검색 기능을 연결해도 오래되었거나 질문과 맞지 않는 문서를 가져올 수 있습니다. 답변만 보는 대신 실제로 전달된 근거가 적절한지 함께 확인하고, 필요한 정보가 없을 때는 모른다고 답하도록 요청한 뒤 실제 질문 사례로 평가합니다.

질문 하나에서 시작해 보겠습니다

직원에게 사내 서비스 신청 방법을 알려 주는 도우미를 만든다고 가정해 보겠습니다. 직원이 “이 서비스는 어디에서 신청하나요?”라고 질문하면 도우미는 무엇을 해야 할까요?

도우미는 직원이 질문할 화면과 관련 안내문이 필요합니다. 질문과 안내문을 바탕으로 답변을 만드는 일은 기반 모델이 맡습니다.

Amazon Bedrock은 애플리케이션에서 여러 제공자의 기반 모델을 이용할 수 있게 해 주는 AWS 관리형 서비스입니다. 개발자는 Bedrock에 요청해 모델을 사용할 수 있습니다. 화면과 안내문 연결은 도우미를 만드는 쪽에서 구성합니다. Amazon Bedrock 개요

질문과 안내문은 어떻게 답변이 될까?

예를 들어 도우미가 이용할 수 있는 가상의 안내문에 “서비스 신청은 사내 포털의 서비스 신청 메뉴에서 진행합니다”라고 적혀 있다고 가정하겠습니다.

먼저 도우미 애플리케이션이 직원의 질문을 받고, 그 직원이 볼 수 있는 안내문을 준비합니다. 이 예시에서는 관련 문장을 요청에 직접 넣습니다. 안내문을 자동으로 찾으려면 검색 기능을 별도로 연결해야 합니다.

다음으로 애플리케이션은 사용할 모델을 지정하고 질문과 안내문을 Bedrock Runtime에 보냅니다. Bedrock Runtime은 애플리케이션이 모델에 요청을 보내는 인터페이스를 제공합니다. 모델은 전달받은 내용을 바탕으로 “사내 포털의 서비스 신청 메뉴에서 신청할 수 있습니다”와 같은 답변을 생성할 수 있습니다. 답변의 표현은 달라질 수 있습니다.

마지막으로 애플리케이션이 답변을 받아 직원 화면에 표시합니다. 이 과정에서 모델은 애플리케이션이 보낸 안내문을 사용합니다. 사내 포털을 스스로 열어 확인하는 것은 아닙니다. Converse API의 메시지와 응답

모델과 Bedrock, 애플리케이션은 각각 무엇을 할까?

기반 모델은 여러 작업에 활용할 수 있도록 사전에 학습된 모델입니다. 안내 도우미에서는 질문과 안내문을 바탕으로 답변을 생성합니다. 이처럼 학습된 모델이 입력을 처리해 결과를 만드는 과정을 추론이라고 합니다.

모델의 답변이 그럴듯해도 안내문에 없는 내용을 만들어 내거나 내용을 잘못 이해할 수 있습니다. 따라서 애플리케이션이 적절한 정보를 전달하는 것과 답변의 정확성을 평가하는 것은 별개의 일입니다.

Bedrock을 사용하면 무엇을 직접 운영하지 않아도 될까?

모델을 직접 배포한다면 실행할 서버와 용량을 준비하고, 모델 서버 운영과 장애 대응을 맡아야 합니다. Bedrock에서 제공하는 지원 모델을 호출하면 개발자가 그 모델 서버를 직접 설치하고 관리할 필요가 없습니다. AWS의 Bedrock 서비스 설명

그렇다고 도우미 전체가 자동으로 만들어지는 것은 아닙니다. 개발자는 사용할 모델을 선택하고, 사용자를 인증하며, 업무 정보에 대한 접근 권한과 화면을 설계해야 합니다. 질문에 필요한 문서가 무엇인지, 답변 오류를 어떻게 다룰지도 결정해야 합니다.

AWS는 서비스를 실행하는 클라우드 기반 시설의 보안을 책임지고, 고객은 자신의 콘텐츠와 사용하는 서비스의 보안 설정을 관리합니다. 실제 신청 내용을 변경하는 기능을 추가한다면 모델의 제안만으로 실행하지 않고 업무 권한과 필요한 승인 절차를 확인하도록 설계해야 합니다. AWS 데이터 보호와 공동 책임

모델 호출 전에 무엇을 확인해야 할까?

안내 도우미가 모델을 호출하려면 먼저 모델과 API가 선택한 AWS 리전에서 지원되는지, 모델 접근 조건을 충족하는지 확인합니다. 리전은 AWS 서비스를 이용하는 지역 단위입니다. 모델마다 지원하는 리전과 기능이 다를 수 있습니다.

애플리케이션이 사용하는 AWS 자격증명과 호출 권한도 필요합니다. 예를 들어 대화형 요청을 보내는 Converse API에는 호출 주체의 bedrock:InvokeModel 권한이 필요합니다. IAM에서 허용했더라도 조직의 서비스 제어 정책(SCP) 등 적용 정책에 명시적 거부가 있으면 호출이 거부됩니다. Converse 권한과 지원 조건

교차 리전 추론을 사용하면 요청을 보낸 리전과 실제 처리 리전이 다를 수 있습니다. 이때 사용하는 추론 프로파일은 요청을 처리할 후보 리전을 정합니다. 데이터 처리 위치에 제한이 있다면 해당 범위와 조직 정책을 함께 확인해야 합니다. 교차 리전 추론

직접 운영, 외부 API, Bedrock 중 무엇을 선택할까?

예를 들어 AWS 환경에서 지원 모델을 사용하면서 모델 서버 운영 부담을 줄이고 싶다면 Bedrock을 고려할 수 있습니다. 반대로 모델 실행 환경을 직접 제어해야 한다면 직접 운영을 검토하고, 특정 제공자의 직접 API가 필요한 기능을 제공한다면 그 API의 계약과 데이터 처리 조건을 살펴볼 수 있습니다.

어느 방식이 항상 저렴하거나 빠르다고 단정할 수는 없습니다. 모델 호출 요금뿐 아니라 연결한 저장소·로그·네트워크와 운영에 필요한 비용까지 비교해야 합니다. Bedrock 요금은 모델과 사용 방식에 따라 달라집니다. Amazon Bedrock 요금 안내

답변이 나오지 않거나 틀렸다면?

호출 자체가 거부되면 애플리케이션이 실제로 사용하는 자격증명과 호출 권한, 조직 정책, 모델 접근 조건과 리전을 확인합니다. 요청 형식이 모델에 맞지 않거나 호출량 제한에 걸린 경우도 따로 살펴야 합니다.

호출은 성공했는데 신청 방법이 틀렸다면 모델에 전달한 안내문이 최신인지, 질문에 필요한 내용이 포함됐는지 먼저 확인합니다. 이후에도 잘못 답한다면 같은 입력으로 결과를 평가하고 모델이나 요청 구성을 조정할 수 있습니다. 호출 실패와 답변 품질 문제를 구분하면 확인할 범위를 좁힐 수 있습니다.