Converse API, RAG, Agent,
Guardrails 내부 구조
Amazon Bedrock은 단순히 Claude나 Titan 같은 Foundation Model을 호출하는 API가 아닙니다. Converse API, Knowledge Bases, Agents, Guardrails, CloudWatch 로그가 함께 연결되면서 기업용 생성형 AI 애플리케이션의 실행 계층이 됩니다.
이 글은 Amazon Bedrock을 이미 들어봤지만 내부 구조가 헷갈리는 개발자와 클라우드 엔지니어를 위한 딥다이브입니다. Bedrock Runtime 요청이 모델까지 가는 흐름, Converse API와 InvokeModel API 차이, Knowledge Bases 기반 RAG, Agent Action Group, Guardrails, CloudWatch 운영 지표까지 실무 설계 기준으로 정리합니다.
Amazon Bedrock을 단순 모델 API로 보면 안 되는 이유
Amazon Bedrock을 처음 보면 "AWS에서 제공하는 LLM 호출 서비스" 정도로 이해하기 쉽습니다. 하지만 실무에서는 모델 호출 하나만으로 끝나지 않습니다. 사용자의 질문을 받고, 시스템 프롬프트를 붙이고, 외부 문서를 검색하고, 필요한 경우 도구를 호출하고, 출력이 정책을 위반하지 않는지 검사하고, 호출 로그와 비용을 추적해야 합니다.
Bedrock은 이 흐름에서 모델 실행 계층과 AI 애플리케이션 운영 계층 사이에 놓입니다. Runtime API는 모델을 호출하고, Converse API는 대화형 메시지 구조를 통일하고, Knowledge Bases는 RAG 구성을 추상화하고, Agents는 외부 작업 실행을 연결하고, Guardrails는 입력과 출력의 안전 기준을 적용합니다.
Bedrock을 제대로 이해하려면 "어떤 모델을 호출할까?"보다 "요청, 검색, 도구 호출, 안전 정책, 로그가 어떤 순서로 연결되는가?"를 먼저 봐야 합니다.
Bedrock 요청 처리 흐름: Client에서 Foundation Model까지
Bedrock 애플리케이션의 기본 흐름은 Client, Application Backend, Bedrock Runtime, Foundation Model로 이어집니다. 사용자가 웹이나 앱에서 질문을 입력하면 백엔드가 인증, 권한, 입력 검증, 프롬프트 조립을 처리한 뒤 Bedrock Runtime API를 호출합니다. Bedrock은 선택한 모델 또는 추론 프로파일에 요청을 전달하고, 모델 응답을 다시 애플리케이션으로 반환합니다.
User
↓
Application Backend
↓
Prompt / Context / Policy
↓
Amazon Bedrock Runtime
↓
Foundation Model
↓
Response / Stream / Logs이 구조에서 중요한 점은 Bedrock이 모든 애플리케이션 로직을 대신하지 않는다는 것입니다. 사용자 세션, 권한, 데이터 마스킹, 프롬프트 조립, 응답 후처리, 캐싱, 재시도 정책은 대부분 애플리케이션 계층에서 설계해야 합니다. Bedrock은 모델 호출과 관련 기능을 제공하지만, 운영 가능한 AI 서비스를 만드는 책임은 여전히 설계자에게 남아 있습니다.
Converse API와 InvokeModel API 차이
Bedrock에서 모델을 호출하는 대표 방식은 InvokeModel 계열 API와 Converse API입니다. InvokeModel은 모델별 요청 형식에 더 가깝고, Converse API는 여러 모델에 공통으로 사용할 수 있는 대화형 메시지 인터페이스에 가깝습니다. 대화형 애플리케이션, 멀티턴 대화, Tool Use까지 고려한다면 Converse API를 먼저 보는 것이 자연스럽습니다.
| 구분 | Converse API | InvokeModel API |
|---|---|---|
| 목적 | 대화형 메시지 구조를 공통 인터페이스로 처리 | 모델별 요청 본문을 직접 구성해 호출 |
| 입력 구조 | messages, system, inferenceConfig, toolConfig 중심 | 모델 제공사별 JSON body 중심 |
| 적합한 상황 | 챗봇, 업무 비서, Tool Use, 멀티턴 대화 | 모델별 기능을 세밀하게 제어하거나 기존 호출 구조 유지 |
| 운영 관점 | 모델 교체와 공통 처리 로직을 만들기 쉬움 | 모델별 차이를 애플리케이션이 더 많이 알아야 함 |
Converse API를 boto3로 호출하는 기본 예제는 Bedrock 실습 2편: boto3와 Converse API 예제에서 이어서 볼 수 있습니다.
Messages, System Prompt, InferenceConfig가 처리되는 방식
Converse API의 핵심 입력은 messages, system, inferenceConfig입니다. messages는 사용자의 질문과 이전 대화 흐름을 담고, system은 모델이 따라야 할 역할과 제약을 담습니다. inferenceConfig는 maxTokens, temperature, topP 같은 추론 동작을 조정하는 설정입니다.
{
"modelId": "anthropic.claude-3-5-sonnet-20240620-v1:0",
"system": [
{"text": "You are a cloud architecture assistant."}
],
"messages": [
{
"role": "user",
"content": [{"text": "Bedrock Knowledge Bases 구조를 설명해줘."}]
}
],
"inferenceConfig": {
"maxTokens": 1200,
"temperature": 0.2
}
}실무에서는 system prompt를 단순한 말투 지시로 쓰면 부족합니다. 출력 형식, 금지 행동, 보안 기준, 불확실할 때의 응답 방식, 내부 데이터 사용 기준을 함께 넣어야 합니다. 다만 너무 긴 system prompt는 비용과 지연시간에 영향을 줄 수 있으므로, 공통 정책과 요청별 지시를 분리하는 것이 좋습니다.
Streaming 응답은 내부적으로 무엇이 다른가
Streaming은 모델이 전체 답변을 완성한 뒤 한 번에 반환하는 방식이 아니라, 생성되는 토큰이나 이벤트를 순차적으로 클라이언트에 전달하는 방식입니다. 사용자는 전체 응답 시간이 같더라도 첫 글자가 더 빨리 보이면 체감 지연시간이 줄었다고 느낍니다.
Bedrock에서 Streaming을 사용할 때는 백엔드와 프론트엔드가 모두 스트림 처리를 지원해야 합니다. API Gateway, ALB, Lambda, 컨테이너 백엔드, 브라우저까지 이어지는 경로 중 하나라도 버퍼링하면 사용자는 스트리밍 효과를 느끼지 못할 수 있습니다.
Tool Use는 Bedrock에서 어떻게 동작하는가
Tool Use는 모델이 외부 시스템을 직접 실행한다는 뜻이 아닙니다. 모델은 "이 작업에는 어떤 도구를 어떤 인자로 호출해야 한다"는 구조화된 요청을 반환하고, 실제 실행은 애플리케이션이 담당합니다. 예를 들어 EC2 상태 조회, 티켓 생성, 주문 조회 같은 작업은 모델이 직접 AWS API를 호출하는 것이 아니라 백엔드가 검증 후 실행해야 합니다.
User Request
↓
Converse API
↓
tool_use response
↓
Application executes tool
↓
tool_result
↓
Model final response이 구조에서 가장 중요한 것은 권한 분리입니다. 모델이 제안한 도구 호출을 그대로 실행하면 안 됩니다. 애플리케이션은 허용된 도구인지, 인자가 안전한지, 사용자가 해당 작업을 할 권한이 있는지, 변경 작업이면 승인 절차가 필요한지 확인해야 합니다.
Knowledge Bases는 RAG를 어떻게 추상화하는가
Bedrock Knowledge Bases는 RAG를 구성할 때 반복적으로 필요한 데이터 소스 연결, 청킹, 임베딩, 벡터 저장소 연동, 검색, 생성 단계를 관리형 기능으로 묶어줍니다. 직접 RAG를 만들면 문서 파싱, 청크 크기, 임베딩 모델, 벡터 DB, 검색 쿼리, reranking, prompt 조립을 모두 설계해야 합니다.
Knowledge Bases를 사용하면 애플리케이션은 "어떤 지식베이스에서 검색할 것인가"와 "검색 결과를 바탕으로 답변을 생성할 것인가"를 중심으로 설계할 수 있습니다. 대신 추상화된 만큼 세밀한 검색 전략이나 특수한 전처리가 필요한 경우에는 직접 RAG 파이프라인이 더 적합할 수 있습니다.
| 구분 | 직접 RAG 구현 | Bedrock Knowledge Bases |
|---|---|---|
| 구현 범위 | 문서 수집부터 검색, 프롬프트 조립까지 직접 구현 | 데이터 소스, 임베딩, 검색, 생성 흐름을 관리형으로 사용 |
| 장점 | 검색 전략과 전처리를 세밀하게 제어 | 초기 구축과 운영 부담이 낮음 |
| 주의점 | 운영 복잡도와 장애 지점이 많음 | 세부 동작을 모두 원하는 방식으로 바꾸기는 어려울 수 있음 |
| 적합한 상황 | 검색 품질 튜닝이 핵심인 서비스 | AWS 안에서 빠르게 RAG 기능을 붙이는 서비스 |
Retrieve와 RetrieveAndGenerate 차이
Knowledge Bases를 사용할 때 자주 헷갈리는 지점이 Retrieve와 RetrieveAndGenerate의 차이입니다. Retrieve는 지식베이스에서 관련 문서를 검색해 반환하는 단계입니다. 답변 생성은 애플리케이션이 별도로 처리합니다. 반면 RetrieveAndGenerate는 검색과 생성까지 Bedrock 흐름 안에서 함께 처리합니다.
| API | 역할 | 실무 사용 기준 |
|---|---|---|
| Retrieve | 관련 문서 조각을 검색해 반환 | 검색 결과를 직접 검증하거나 자체 프롬프트 조립이 필요할 때 |
| RetrieveAndGenerate | 검색 결과를 바탕으로 답변까지 생성 | 빠르게 RAG 답변 기능을 만들고 싶을 때 |
| GenerateQuery | 자연어 질문을 데이터 소스에 맞는 쿼리로 변환하는 흐름에 사용 | 구조화 데이터나 쿼리 기반 검색 흐름을 설계할 때 |
운영 기준으로 보면 Retrieve는 제어권이 높고, RetrieveAndGenerate는 구현 속도가 빠릅니다. 고객지원 챗봇처럼 빠르게 답변 기능을 만들 때는 RetrieveAndGenerate가 편합니다. 반대로 금융, 보안, 정책 문서처럼 출처와 응답 제어가 중요한 경우에는 Retrieve로 검색 결과를 받은 뒤 애플리케이션에서 별도 검증과 prompt 조립을 수행하는 방식이 더 안전할 수 있습니다.
Agents는 Action Group과 Lambda를 어떻게 호출하는가
Bedrock Agents는 사용자의 목표를 이해하고, 필요한 경우 Action Group을 통해 외부 작업을 실행하는 구조입니다. Action Group은 특정 작업 묶음이며, 보통 Lambda 함수와 연결됩니다. 예를 들어 "내 EC2 상태를 확인해줘"라는 요청이 들어오면 Agent가 의도를 파악하고, 연결된 Action Group을 통해 Lambda를 호출해 EC2 정보를 조회할 수 있습니다.
이 구조는 강력하지만 위험도 함께 생깁니다. Agent가 실행할 수 있는 작업은 명확히 제한해야 합니다. 조회 작업과 변경 작업은 분리하고, 변경 작업에는 승인 흐름을 넣는 것이 좋습니다. 또한 Lambda 입력 스키마를 명확히 정의해 모델이 애매한 인자를 넘기지 않도록 해야 합니다.
Guardrails는 입력과 출력의 어느 지점에서 개입하는가
Guardrails는 모델이 생성한 답변만 검사하는 기능으로 이해하면 부족합니다. Bedrock Guardrails는 사용자 입력과 모델 응답 모두에 적용될 수 있고, 금지 주제, 민감정보, 부적절한 내용, 특정 정책 위반을 탐지하는 데 사용됩니다. Knowledge Bases나 Agents 흐름에도 함께 적용할 수 있습니다.
하지만 Guardrails가 모든 보안 문제를 해결하는 것은 아닙니다. Prompt Injection, 권한 오남용, 내부 데이터 유출, 잘못된 도구 호출은 Guardrails 하나로 끝낼 수 없습니다. Guardrails는 방어 계층 중 하나이고, 애플리케이션 권한 검증, 데이터 마스킹, 도구 실행 승인, 로그 감사와 함께 설계해야 합니다.
| 적용 지점 | 역할 | 주의점 |
|---|---|---|
| 입력 검사 | 사용자 요청의 정책 위반 가능성 탐지 | 우회 표현이나 간접 프롬프트 공격까지 항상 완벽히 막지는 못함 |
| 출력 검사 | 모델 응답의 민감정보, 부적절한 내용, 금지 주제 검사 | 업무 정책과 규제 기준에 맞게 별도 검토 필요 |
| RAG/Agent 흐름 | 검색 기반 응답과 도구 사용 결과에 안전 기준 적용 | 도구 실행 자체의 권한 검증은 애플리케이션에서 별도 처리 |
Bedrock Latency가 발생하는 구간
Bedrock이 느리다고 느껴질 때 원인은 하나가 아닙니다. 네트워크 왕복 시간, 모델 선택, 입력 토큰 수, 출력 토큰 수, RAG 검색 시간, Agent의 Lambda 호출 시간, Guardrails 평가 시간, 클라이언트 스트리밍 처리 방식이 모두 영향을 줍니다.
| 구간 | 느려지는 이유 | 개선 방향 |
|---|---|---|
| 입력 토큰 | 긴 문서와 긴 대화 기록을 매번 전송 | 요약, 캐싱, 필요한 문맥만 선택 |
| 모델 생성 | 큰 모델, 긴 출력, 높은 추론 부하 | 작업별 모델 분리, maxTokens 제한, streaming 사용 |
| RAG 검색 | 벡터 검색, reranking, 문서 수 증가 | 검색 범위 제한, metadata filter, chunk 전략 조정 |
| Agent Tool 호출 | Lambda cold start, 외부 API 지연 | Lambda 최적화, timeout 분리, 비동기 처리 |
| Guardrails | 입력과 출력 정책 평가 추가 | 필요한 정책만 적용하고 측정 지표를 분리 |
Bedrock 호출 지표와 로그 운영은 Amazon Bedrock Observability 구성 방법에서 더 구체적으로 볼 수 있습니다.
CloudWatch와 S3로 Bedrock 호출 로그를 운영하는 방법
Bedrock 운영에서 로그는 선택 사항이 아니라 장애 분석과 비용 분석의 핵심입니다. 모델 호출 로그를 CloudWatch Logs나 S3로 보내면 어떤 모델을 얼마나 호출했는지, 요청과 응답이 어떤 패턴을 가지는지, 에러가 어디서 발생하는지 추적할 수 있습니다.
다만 모델 입력과 출력에는 민감정보가 포함될 수 있습니다. 따라서 호출 로그를 켜기 전에 보관 위치, 암호화, 접근 권한, 보존 기간, 마스킹 기준을 먼저 정해야 합니다. 특히 고객 데이터, 내부 문서, 소스코드, 인증정보가 prompt에 들어갈 수 있는 구조라면 무조건 전체 payload를 남기는 방식은 위험합니다.
Bedrock 실무 아키텍처 체크리스트
Bedrock 기반 서비스를 설계할 때는 모델 호출 코드보다 운영 기준을 먼저 정하는 것이 안전합니다. 아래 체크리스트는 PoC를 운영 서비스로 확장할 때 반드시 확인해야 하는 항목입니다.
SUMMARY. Amazon Bedrock 딥다이브 핵심 요약
Amazon Bedrock은 모델 하나를 호출하는 서비스가 아니라, 기업용 생성형 AI 애플리케이션을 운영하기 위한 실행 계층으로 봐야 합니다. Converse API는 대화형 요청 구조를 통일하고, Knowledge Bases는 RAG를 관리형으로 추상화하며, Agents는 외부 작업 실행을 연결하고, Guardrails는 입력과 출력의 안전 기준을 적용합니다.
실무에서 중요한 것은 기능 이름을 외우는 것이 아니라 요청이 어떤 경로로 흐르는지 이해하는 것입니다. Client에서 시작한 요청이 애플리케이션 백엔드, Bedrock Runtime, RAG 검색, Tool 호출, Guardrails, CloudWatch 로그로 어떻게 이어지는지 그릴 수 있어야 장애, 비용, 보안 문제를 운영 기준으로 다룰 수 있습니다.
Bedrock 도입을 검토한다면 먼저 Converse API와 InvokeModel 중 어떤 호출 방식을 쓸지, RAG를 Knowledge Bases로 처리할지, Agent에게 어떤 작업까지 허용할지, Guardrails와 로그를 어디에 적용할지부터 정하는 것이 좋습니다.
Amazon Bedrock should be designed as an AI execution layer that connects model inference, RAG, tools, safety controls, and operational observability.
