Build agentic retrieval on a Managed Amazon Bedrock Knowledge Base with CDK

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS는 Managed Amazon Bedrock Knowledge Base와 AgentCore, AWS CDK를 결합해 두 지식 베이스를 선택·반복 검색하고, 인용 답변과 관측·평가 기능을 함께 제공하는 에이전트 검색 구성을 제시한다.

📌 핵심 요약

• 일반 RAG는 한 번 검색하고 한 번 생성하므로 여러 자료 집합을 결합하거나 질문에 따라 검색 대상을 선택하고 추가 검색을 수행해야 하는 경우 불완전한 답변을 낼 수 있다.
• Managed Amazon Bedrock Knowledge Base(Type: MANAGED)는 수집·저장·인덱싱·검색을 관리하며, AgenticRetrieveStream과 AgentCore Gateway 연동은 관리형 지식 베이스에서만 지원된다. 고객 관리형은 기존 벡터 저장소 재사용이나 데이터 상주·튜닝·규정 준수 요구에 맞춰 저장소를 직접 선택하고 운영할 때 적합하다.
• AgentCore Runtime의 에이전트는 금융·날씨 지식 베이스를 각각의 도구로 선택하고, AgentCore Gateway의 MCP 연결을 통해 AgenticRetrieveStream을 호출한다. 이 API는 지식 베이스 내부에서 하위 질의 분해와 반복 검색을 수행해 근거와 인용을 포함한 답변을 반환하며, 에이전트는 필요하면 다시 검색한다.
• 솔루션은 CloudWatch 대시보드 2개, 텔레메트리 7개 계층, 온디맨드·지속 평가를 같은 배포에 포함한다. Runtime은 OpenTelemetry 스팬, 토큰 수와 지표를 CloudWatch 및 AWS X-Ray로 보내며, 인용과 충실성·정확성 점수는 답변의 근거 추적과 품질 확인을 지원한다.
• Python AWS CDK 애플리케이션은 지식 베이스·Gateway·에이전트·대시보드의 4개 스택으로 구성되며, 스택 사이에 7개 값이 전달된다. CDK는 구성 요소 참조에서 의존성과 배포 순서를 도출하므로, 2024년 단일 검색 구성에서 수동으로 지정하던 순서와 별도 OpenSearch Serverless 저장소 운영이 이 설계에서는 필요하지 않다.

🧩 주요 포인트

1. 검색 대상 선택과 반복 검색의 결합 → 여러 자료 집합에 걸친 질문을 처리할 수 있지만 실행 경로가 질문마다 달라져 관측과 평가의 중요성이 커진다.
2. 관리형 전용 AgenticRetrieveStream·AgentCore Gateway 연동 → 관리형 선택은 기능 사용의 전제이며, 고객 관리형의 저장소 선택·운영 요구와 함께 판단해야 한다.
3. 개 스택·7개 교차 전달 값과 관측 자원의 결합 → AWS CDK의 구성 요소 참조가 연결 정보와 배포 의존성을 함께 표현해 수동 조정 부담을 줄인다.

🧠 상세 정리

1. 단일 검색 RAG가 한계에 부딪히는 지점

일반적인 RAG는 질문을 임베딩하고 하나의 인덱스에서 가까운 청크를 가져온 다음, 모델이 이를 바탕으로 답변을 생성하는 구조다. 원문은 많은 질문에는 이러한 한 번의 검색과 생성이 적절하며, 불필요하게 복잡한 구성을 만들 이유가 없다고 전제한다. 그러나 답이 두 자료 집합에 걸쳐 있으면 필요한 근거의 일부만 검색될 수 있고, 모델은 유창하지만 불완전한 답변을 반환할 수 있다. 질문에 따라 적절한 출처가 달라지는 경우에도 단일 인덱스에는 검색 대상을 선택하는 장치가 없으며, 첫 결과를 본 뒤 다시 자료를 살펴야 하는 질문에는 추가 검색 단계가 마련되어 있지 않다. 에이전트 검색은 추론 에이전트가 검색 여부와 대상, 추가 검색의 필요성을 판단하도록 하여 이 세 가지 한계에 대응한다.

2. 2024년 CDK 구성에서 달라진 기반

2024년 8월의 선행 글은 Amazon S3 자료, Amazon OpenSearch Serverless 컬렉션과 인덱스, 지식 베이스와 데이터 소스를 CDK 스택으로 배포하는 단일 검색 구성을 다뤘다. 당시에는 스택의 배포 순서를 사람이 직접 지정했지만, 이번 구성은 Python AWS CDK 애플리케이션 하나에서 의존성을 도출해 한 명령으로 전체를 배포한다고 설명한다. 첫 번째 변화는 Managed Knowledge Base가 수집과 저장, 인덱싱과 검색을 맡아 별도 OpenSearch Serverless 컬렉션이나 OCU 용량을 준비할 필요가 없어졌다는 점이다. 두 번째는 AgentCore Gateway와 Runtime, AgenticRetrieveStream을 통해 도구 기반 검색과 추론, 인용 답변을 구성한다는 점이다. 세 번째는 관측과 평가도 같은 배포에서 제공하며, 원문은 애플리케이션이 만드는 자원의 대략 절반이 에이전트의 행동을 파악하기 위한 것이라고 강조한다.

3. 관리형과 고객 관리형 지식 베이스의 선택

Managed Knowledge Base는 Type: MANAGED로 지정하며, Amazon Bedrock이 수집·저장·인덱싱·검색을 관리하고 기본적으로 서비스 관리형 임베딩과 재순위화 모델을 제공한다. 원문의 비교표는 이 내장 모델에 추가 비용이 없다고 설명하며, 사용자가 별도의 벡터 데이터베이스를 프로비저닝하거나 확장하고 패치할 필요가 없다는 점을 제시한다. 이 솔루션에서 특히 중요한 제약은 AgenticRetrieveStream과 AgentCore Gateway 연동이 관리형에서만 지원되고 고객 관리형에서는 지원되지 않는다는 것이다. 고객 관리형에서는 사용자가 OpenSearch Serverless 같은 벡터 저장소를 직접 선택하고 운영하며, 임베딩과 재순위화도 구성한다. 다만 기존 OpenSearch Serverless 컬렉션을 재사용하거나 특정 데이터 상주·튜닝·규정 준수 요구를 충족해야 한다면 고객 관리형이 적합할 수 있으므로, 원문은 선택의 근거를 기능과 운영 요구에 연결한다.

4. 관측과 평가가 설계에 포함되어야 하는 이유

단일 검색 파이프라인은 코드를 읽어 동작을 파악하기 비교적 쉽지만, 추론과 검색을 반복하는 에이전트는 질문마다 다른 경로를 밟는다. 따라서 답변이 반환되었다는 사실만으로 운영에 충분하다고 볼 수 없으며, 지연 시간과 호출량, 토큰 사용량뿐 아니라 검색과 답변의 품질도 지속적으로 확인해야 한다는 것이 원문의 주장이다. 이 솔루션은 텔레메트리 7개 계층을 아우르는 CloudWatch 대시보드 2개와 온디맨드·지속 평가를 같은 CDK 애플리케이션으로 배포한다. 인용은 답변을 원문 구절까지 추적할 수 있게 해 감사 가능성을 높이고, 충실성과 정확성 점수는 답변이 출처에서 벗어나는 현상을 발견하는 데 쓰인다. 관측과 평가는 나중에 붙이는 부가 기능이 아니라, 반복 검색 시스템이 실제로 어떻게 움직이고 얼마나 적절한 답변을 만드는지 판단하는 기반으로 제시된다.

5. 네 스택의 연결에서 CDK가 맡는 역할

원문은 다른 인프라 코드 도구로도 같은 자원을 만들 수 있다고 인정하면서, 이 구조에서는 스택 사이의 촘촘한 참조가 CDK를 사용하는 구체적인 이유라고 설명한다. Gateway에는 두 지식 베이스의 ID가 필요하고, 에이전트에는 Gateway의 URL과 ARN이 필요하며, 대시보드에는 지식 베이스 ID와 Gateway ARN, 에이전트 Runtime ID가 필요하다. 이렇게 스택 경계를 넘는 값은 7개이며, 각각 지표의 차원이나 연결 대상에 사용된다. 원시 템플릿으로 구성하면 스택 내보내기와 교차 조회를 맞추고 배포 순서 및 출력 전달을 별도 스크립트로 관리해야 하지만, CDK에서는 구성 요소를 전달하는 행위에서 내보내기와 의존 관계가 도출된다. 원문은 2024년의 3개 스택과 대체로 선형적인 의존 구조가 4개 스택의 연결로 확장되면서, 이러한 차이가 단순한 작성 방식의 취향을 넘어선다고 주장한다.

6. 두 지식 베이스를 연결하는 전체 검색 구조

전체 솔루션은 AgentCore Runtime에서 실행되는 에이전트와 AgentCore Gateway, 금융·날씨용 Managed Knowledge Base 두 개를 중심으로 구성된다. 각 지식 베이스는 Amazon S3의 개별 자료 집합을 수집하고, Gateway에는 지식 베이스마다 하나씩 AgenticRetrieveStream 도구가 노출된다. 사용자의 질문을 받은 에이전트는 금융과 날씨 중 주제에 맞는 도구를 선택하므로, 모든 자료를 섞은 단일 인덱스에서 검색하는 흐름과 구별된다. 이때 바깥쪽 에이전트는 검색 대상과 재호출 필요성을 판단하고, 선택된 지식 베이스의 AgenticRetrieveStream은 내부 검색과 답변 합성을 맡는다. 도구가 근거와 인용을 포함한 답변을 반환한 뒤에도 에이전트는 추가 검색을 선택할 수 있으며, 전체 과정의 동작 정보는 CloudWatch와 AWS X-Ray로 전달된다.

7. 배포 시 수집과 질문별 라우팅·인증

원문의 단계 0은 질문 처리 이전에 배포 시 수행되는 자료 수집으로, Amazon S3의 각 자료 집합을 별도의 Managed Knowledge Base에 넣는 과정이다. Amazon Bedrock은 이때 파싱과 청크 분할, 임베딩과 인덱싱을 자동으로 수행하며, 이 단계는 매 질문의 처리 경로에 포함되지 않는다. 질문별 흐름은 사용자가 AgentCore Runtime의 에이전트에 질문을 보내면서 시작되고, Runtime은 전체 추론·행동 반복 과정을 OpenTelemetry 스팬으로 자동 계측한다. 이어 추론 모델이 질문을 계획하고 금융 또는 날씨 도구를 선택하며, Gateway가 MCP를 통해 해당 도구 호출을 중개한다. 호출은 에이전트의 IAM 태스크 역할로 권한을 부여받고 SigV4로 서명되어 선택한 Managed Knowledge Base의 AgenticRetrieveStream API에 전달되므로, 검색 대상 선택과 실제 호출 경로가 구체적으로 연결된다.

8. 지식 베이스 내부 검색과 반복 판단의 마무리

AgenticRetrieveStream은 선택된 지식 베이스 안에서 질문을 하위 질의로 분해하고, Amazon Bedrock이 관리하는 데이터 저장소를 반복 검색한 뒤 근거와 인용을 포함한 답변을 합성한다. 이 답변은 Gateway를 통해 스트리밍으로 돌아오며, 바깥쪽 에이전트는 반환된 맥락이 질문에 답하기에 충분한지 판단한다. 충분하지 않으면 다시 대상을 선택하고 검색하는 순환을 거치며, 충분하면 사용자에게 최종 인용 답변을 반환한다. 이 과정 내내 Runtime이 내보내는 스팬과 토큰 수, 지표는 CloudWatch 및 AWS X-Ray로 전달되어 관측 계층과 온디맨드·지속 평가에 사용된다. 제공된 본문은 마지막으로 app.py가 네 스택을 선언하고 CDK가 구성 요소 참조에서 순서를 도출한다고 설명한 뒤 Gateway 스택 생성 코드 도중에 끝나므로, 이후 구현의 세부 설정은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 이 설계에는 지식 베이스 사이의 선택·재검색과 지식 베이스 내부의 질의 분해·반복 검색이라는 두 수준의 판단이 존재하므로, 최종 답변 품질을 이해하려면 두 수준의 동작을 함께 관측해야 한다.
• 관리형 전환은 벡터 저장소 운영 부담을 줄이는 동시에 AgenticRetrieveStream과 Gateway 연동을 가능하게 하지만, 저장소를 직접 선택하고 운영해야 하는 요구는 고객 관리형 선택의 근거로 남는다.
• 검색 기능뿐 아니라 관측과 평가 자원까지 같은 CDK 애플리케이션에서 연결함으로써, 배포 의존성과 실행 후 품질 확인을 하나의 인프라 구성 안에서 다루는 접근이다.

✅ 액션 아이템

• 여러 자료 집합 결합과 추가 검색의 필요성을 기준으로 일반 RAG와 에이전트 검색의 적용 범위 검토.
• AgenticRetrieveStream·AgentCore Gateway 지원 조건과 데이터 상주·튜닝·규정 준수 요구를 함께 고려해 관리형과 고객 관리형의 적합성 판단.
• 4개 스택·7개 교차 전달 값의 CDK 의존성과 CloudWatch 대시보드 2개·온디맨드·지속 평가의 연결 확인.

❓ 열린 질문

• 대상 질문은 일반 RAG의 한 번 검색으로 충분한가, 여러 자료 집합 결합과 추가 검색이 필요한가?
• AgenticRetrieveStream·AgentCore Gateway 지원과 저장소 직접 운영을 요구하는 데이터 상주·튜닝·규정 준수 조건 중 어떤 요구가 선택을 좌우하는가?
• CloudWatch 대시보드 2개와 온디맨드·지속 평가에서 어떤 결과를 검색 및 답변 품질의 충분한 근거로 판단할 것인가?