Amazon Bedrock 기반 RAG와 Agent 아키텍처 설계

Amazon Bedrock은 AWS에서 제공하는 관리형 생성형 AI 서비스로, 여러 Foundation Model을 하나의 플랫폼에서 사용할 수 있게 해줍니다. RAG 구조로 기업 내부 문서나 서비스 데이터를 기반으로 답변하게 만들 수 있고, Agent를 활용하여 외부 API를 호출해 실제 작업까지 수행할 수 있다는 점이 특징입니다. 이번 글에서는 Amazon Bedrock에서 자주 함께 언급되는 RAG for Amazon Bedrock과 Agents for Amazon Bedrock의 개념을 정리하고, 실제 서비스에서 사용할 수 있는 Bedrock 기반 RAG / Agent 아키텍처를 설계하는 방법을 알아보겠습니다.

 

---

 

목차

1. RAG for Amazon Bedrock
2. Agents for Amazon Bedrock
3. 도입 시 고려할 점
4. 결론

 

---

 

#1 RAG for Amazon Bedrock

 

<그림 1>. RAG for Amazon Bedrock

 

 RAG는 Retrieval-Augmented Generation의 약자로, 한국어로는 검색 증강 생성이라고 부를 수 있습니다. 일반적인 LLM은 학습된 지식만을 바탕으로 답변하기 때문에 최신 정보나 사내 문서, 서비스 내부 데이터에 대해서는 정확하게 답변하지 못할 수 있습니다. 이때 RAG 구조를 사용하면 사용자의 질문과 관련된 문서를 먼저 검색하고, 검색된 문서 내용을 LLM에게 함께 전달하여 더 정확한 답변을 생성할 수 있습니다. Amazon Bedrock에서는 이러한 RAG 구조를 직접 모두 구현하지 않아도, Knowledge Bases for Amazon Bedrock 기능을 통해 관리형 RAG를 구성할 수 있습니다. Knowledge Base는 데이터 소스에 저장된 문서를 기반으로 관련 정보를 검색하고, 검색된 결과를 Foundation Model에게 전달하여 답변의 정확성과 관련성을 높이는 역할을 합니다.

 

 기본적인 RAG 흐름은 다음과 같습니다.

 

• 사용자 질문
• Knowledge Base 검색
• 관련 문서 Chunk 반환
• Foundation Model에 질문 + 검색 결과 전달
• 근거 기반 답변 생성

 

 예를 들어 회사 내부 운영 문서, 서비스 매뉴얼, 기술 문서, FAQ, 정책 문서를 S3에 저장해 두고 Knowledge Base와 연결하면, 사용자가 질문했을 때 Bedrock이 해당 문서에서 관련 내용을 검색한 뒤 답변을 생성을 해줍니다. 일반적인 RAG 구조를 만들기 위해서는 문서를 업로드하고, 긴 문서를 파편화하는 문서 분할 Chunking, AI가 검색할 수 있도록 숫자 벡터로 변경하는 Embdedding을 생성하고, 벡터 저장소에 저장해야 합니다. Amazon Bedrock Knowledge Bases를 사용하면 이 과정 중 문서 수집, 임베딩, 벡터 저장소 연동 과정을 AWS 관리형 기능으로 처리할 수 있습니다. 즉, 직접 전체 RAG 파이프라인을 구현하지 않아도 AWS 환경 안에서 비교적 간단하게 RAG 아키텍처를 구성할 수 있습니다.

 

RAG가 필요한 이유

일반적인 LLM은 다음과 같은 한계를 가집니다.

• 최신 정보를 실시간으로 알지 못할 수 있음
• 사내 문서나 비공개 데이터에 접근할 수 없음
• 근거 없는 답변을 생성할 수 있음
• 서비스 내부 DB나 정책 문서를 반영하지 못함
• 특정 도메인에 맞는 정확한 답변을 제공하기 어려움

 RAG는 이 문제들을 해결하기 위해 사용됩니다. 모델이 모르는 내용을 억지로 생성하게 하는 것이 아니라, 외부 데이터 소스에서 관련 정보를 먼저 검색한 뒤 그 정보를 기반으로 답변하도록 만드는 방식입니다. 예를 들어 "우리 서비스의 환불 정책은 어떻게 되나요?", "우리 IAM 계정 권한 규칙 체계는 어떻게 되나요?" 등의 질문을 하여 회사의 정책에 관한 답변을 정확하게 받을 수 있습니다.

참고로 AWS 프로덕션 환경에서 벡터 저장소는 OpenSearch Serverless 계열이나 Aurora PostgreSQL이 자주 사용된다고 합니다.

 

---

 

#2 Agents for Amazon Bedrock

 

<그림 2>. Agents for Amazon Bedrock

 

 Agent는 사용자의 요청을 이해하고 필요한 작업을 수행합니다. Agents for Amazon Bedrock은 Foundation Model, Knowledge Base, Action Group, 외부 API, 사용자 대화를 연결하여 사용자의 요청을 처리할 수 있습니다. 즉, Agent는 사용자의 요청을 분석하고, 필요한 경우 Knowledge Base에서 문서를 검색하거나, Action Group을 통해 Lambda 또는 외부 API를 호출하여 실제 작업을 수행할 수 있습니다.

 

 Agent의 기본 흐름은 다음과 같습니다.

 

• 사용자 요청
• Bedrock Agent가 의도 파악
• 필요한 경우 Knowledge Base 검색
• 필요한 경우 Action Group 실행
• Lambda 또는 외부 API 호출
• 결과를 바탕으로 최종 응답 생성

 

 여기서 중요한 개념은 Action Group입니다. Action Group은 Agent가 수행할 수 있는 작업을 정의한 단위입니다. 예를 들어 호텔 예약 서비스라면 예약 생성, 조회, 취소 같은 작업을 Action Group으로 정의할 수 있습니다. 즉, Agent는 단순히 답변만 하는 것이 아니라, 필요할 경우 실제 API를 호출해 작업을 수행할 수 있습니다. RAG와는 다르게 Agent는 실제 서비스의 기능도 실행할 수 있다는 차이점이 존재합니다.

 

Action Group이란?

 Action Group은 Agent가 호출할 수 있는 작업의 묶음입니다. 실제 서비스에서는 Action Group을 통해 Lambda 함수를 연결하거나, API Schema를 정의하여 Agent가 외부 시스템과 통신할 수 있게 만듭니다. 사용자가 자연어로 요청하면 Agent가 어떤 Action Group을 호출해야 하는지 판단하고, 필요한 파라미터를 추출해 Lambda 또는 API를 실행합니다.

 

---

 

#3 도입 시 고려할 점

 

 Bedrock 기반 RAG와 Agent 아키텍처를 설계할 때는 단순히 기능을 연결하는 것만으로는 부족합니다. 실제 서비스에 적용하려면 데이터 품질, 보안, 비용, 응답 속도, 오류 처리 등을 함께 고려해야 합니다.

 

1. 문서 품질과 Chunking 관리

 RAG 성능은 결국 검색되는 문서 품질에 크게 영향을 받습니다. 문서가 오래되었거나 중복이 많거나 구조가 불명확하면, Knowledge Base가 관련 없는 문서를 검색할 수 있습니다. 따라서 다음과 같은 관리가 필요합니다.

• 오래된 문서와 최신 문서를 구분
• 문서 제목, 섹션, 날짜 등 메타데이터 관리
• 너무 긴 문서는 적절한 크기로 Chunking
• 중복 문서를 제거

 

2. Agent 권한 관리

 Agent는 Action Group을 통해 Lambda나 API를 호출할 수 있기 때문에 권한 관리가 중요합니다. 잘못 설계하면 사용자가 의도하지 않은 작업을 실행하거나, 민감한 데이터에 접근할 위험이 있습니다. 따라서 다음과 같은 관리가 필요합니다.

• IAM Role은 최소 권한 원칙으로 구성
• 삭제, 변경 같은 민감한 작업은 추가 확인 절차 적용
• Agent가 호출할 수 있는 API 범위를 명확히 제한

 

3. 응답 속도와 비용

 RAG와 Agent 구조는 일반 LLM 호출보다 처리 단계가 많기 때문에 응답 시간이 길어질 수 있습니다. 비용 측면에서도 다음 요소를 고려해야 합니다.

• Foundation Model 호출 비용
• Vector Store 비용
• Lambda 실행 비용
• 외부 API 호출 비용

 

---

 

#4 결론

Amazon Bedrock은 Knowledge Bases와 Agents를 통해 실제 서비스에 적용 가능한 생성형 AI 아키텍처를 구성할 수 있게 해줍니다. 실무에서는 두 개념을 따로 보기보다는 함께 설계하는 것이 중요합니다. 단순 문서 Q&A에는 RAG를 사용하고, 실시간 조회나 작업 수행이 필요한 경우에는 Agent를 사용하면서 두 개념이 상호작용할 수 있도록 설계하여 효율을 끌어올리는 것이 좋습니다.