Amazon Bedrock Managed Knowledge Base는 RAG를 직접 조립하던 일을 관리형 서비스로 묶으려는 시도입니다. RAG는 검색으로 찾은 기업 데이터를 모델 답변에 붙여 정확도를 높이는 방식이지만, 실제 운영에서는 커넥터, 권한, 파싱, 청킹, 임베딩, 재랭킹, 벡터 저장소, 평가가 모두 문제로 따라옵니다. AWS는 2026년 발표에서 이 복잡도를 “Managed Knowledge Base”라는 단일 구성 요소로 낮추겠다고 설명했습니다.
기업 입장에서는 이 변화가 작지 않습니다. 사내 문서는 SharePoint, Confluence, Google Drive, OneDrive, S3, 웹 페이지처럼 흩어져 있고, 각 데이터는 접근 권한과 형식이 다릅니다. 에이전트가 업무 답변을 하려면 최신 문서를 찾는 것뿐 아니라 누가 볼 수 있는 자료인지도 지켜야 합니다. 그래서 지식 베이스는 모델 기능보다 AI 인프라 운영에 가까운 문제가 됩니다.
배경
AWS News Blog는 Managed Knowledge Base가 저장, 검색, 임베딩, 재랭킹, 기반 모델 선택을 기본 관리한다고 설명합니다. 출시 시점의 기본 커넥터는 Amazon S3, SharePoint, Confluence, Web Crawler, Google Drive, OneDrive입니다. AWS 문서는 Managed Knowledge Base가 AgentCore Gateway와 통합되어 MCP 호환 에이전트 프레임워크가 도구처럼 호출할 수 있다고 안내합니다.
| 구성 요소 | 맡는 역할 | 운영 부담이 줄어드는 부분 |
|---|---|---|
| Native connectors | 기업 데이터 연결 | 소스별 커넥터 개발 |
| Smart Parsing | 문서 형식별 파싱 | PDF·PPTX·이미지 포함 문서 처리 |
| Agentic Retriever | 멀티홉 검색 계획 | 복잡한 질문 분해와 반복 검색 |
| Observability | 검색 추적과 지표 | 답변 근거 확인과 품질 점검 |
원리
일반적인 RAG는 문서를 잘라 벡터로 저장하고, 질문과 가까운 조각을 찾아 모델 프롬프트에 넣습니다. 문제는 실제 질문이 단순하지 않다는 점입니다. “ML 플랫폼 예산으로 연간 약정을 선결제할 수 있나” 같은 질문은 팀 예산 문서와 비용 정책을 함께 찾아야 합니다. AWS가 말하는 Agentic Retriever는 이런 질문을 하위 질문으로 나누고 여러 지식 베이스를 오가며 충분한 근거를 모읍니다.
Smart Parsing도 중요합니다. 문서 안의 표, 이미지, 스캔 문서, 동영상 설명은 단순 텍스트 추출로는 빠지기 쉽습니다. 관리형 파서는 문서 유형별 전략을 골라 검색 가능한 단위로 바꾸려 합니다. 이는 에이전틱 AI가 실제 기업 업무로 들어갈 때 필수인 “기억과 권한의 기반”입니다.
구조
첫 번째 이미지는 여러 문서 더미가 하나의 지식 베이스로 들어가고, 검색 결과가 에이전트에게 전달되는 흐름을 보여줍니다. 두 번째 이미지는 Agentic Retriever가 큰 질문을 세 개의 작은 질문으로 나누고, 각 근거를 다시 결합하는 모습을 나타냅니다.
RAG의 난점은 “벡터 DB를 붙이는 것”보다 데이터 준비와 권한 보존입니다. 관리형 지식 베이스는 이 반복 운영을 클라우드 서비스로 흡수하려는 방향입니다.
체크포인트
관리형 서비스는 빠르게 시작하게 해주지만 잠금 효과도 생깁니다. 커넥터와 기본 모델 선택이 편하더라도, 검색 품질 평가와 권한 매핑은 조직 데이터 구조에 맞춰 검증해야 합니다. 멀티홉 검색은 답변 품질을 높일 수 있지만 비용과 지연을 키울 수도 있습니다. 민감한 문서가 포함된다면 ACL 필터링, 감사 로그, 리전 지원 범위를 먼저 확인해야 합니다.
Bedrock Managed Knowledge Base의 핵심은 RAG가 실험 코드에서 운영 인프라로 넘어가고 있다는 점입니다. 기업 에이전트의 경쟁력은 모델 이름보다 “필요한 근거를 안전하게 찾아오는 데이터 계층”에서 갈릴 가능성이 큽니다.
댓글 없음:
댓글 쓰기