Build multi-tenant agentic chat applications on enterprise data with Amazon Bedrock Managed Knowledge Base

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Managed Knowledge Base를 활용해 문서 수집과 검색을 관리형으로 처리하고, 검증된 사용자 식별자와 메타데이터 필터로 사용자별 문서를 격리하는 다중 테넌트 문서 채팅 구조를 설명한다.

📌 핵심 요약

• Amazon Bedrock Managed Knowledge Base는 수집·저장·임베딩·순위 산정과 에이전트 검색을 관리하며, 복잡한 질문을 하위 질의로 나누는 다중 홉 검색에서도 접근 권한을 적용한다.
• 애플리케이션은 Amazon Cognito와 검증된 JWT에서 사용자 식별자를 추출하고, 문서의 user_id 메타데이터와 AgenticRetrieveStream의 서버 측 equals 필터를 연결해 사용자별 검색 범위를 제한한다.
• 업로드는 Amazon SQS로 수집 작업과 분리하며, 파일은 6 MB까지 인라인으로 전달하고 더 큰 텍스트 파일은 최대 50 MB까지 Amazon S3 참조로 수집한다.
• 사용자 업로드는 사용자 지정 커넥터와 IngestKnowledgeBaseDocuments로 직접 수집한다. 같은 문서 ID를 재사용하면 기존 문서가 교체되며, 부분 수정은 지원하지 않고 호출당 최대 10개 문서를 수집할 수 있다.
• 색인은 비동기로 진행되며 STARTING은 검색 가능 상태가 아니다. TEXT_INDEXED에서는 텍스트를 검색할 수 있고 INDEXED에서는 처리가 완료되며, Amazon DynamoDB에 기록한 상태를 통해 준비 여부를 화면에 표시한다.

🧩 주요 포인트

1. 검색 계획·색인·응답 생성의 관리형 처리 → 애플리케이션 개발 범위가 업로드 경험, 인증, 사용자별 격리와 업무 로직에 집중된다.
2. 검증된 JWT 기반 user_id와 서버 측 equals 필터 → 클라이언트가 보낸 사용자 값에 의존하지 않고 다중 홉 검색의 사용자 경계를 유지한다.
3. Amazon SQS를 통한 비동기 수집과 TEXT_INDEXED 기준의 텍스트 검색 개방 → 업로드 응답성과 실제 검색 준비 상태를 분리해 다룬다.

🧠 상세 정리

1. 문서 채팅의 핵심 과제와 관리형 검색

다중 테넌트 문서 채팅은 사용자가 계약서, 보고서, 제품 설명서를 올린 뒤 즉시 또는 나중에 질문하는 경험을 제공하며, 대규모 고객에게 자주 요청되는 기능으로 소개된다. 대화 화면을 만드는 것과 별개로, 내부 검색 시스템은 다른 사용자의 문서가 섞이지 않도록 검증된 신원에 기반한 격리를 보장해야 한다. 에이전트가 질문을 여러 하위 질의로 나누면 검색이 반복되므로, 모든 검색 단계에서 사용자 경계를 유지해야 한다. 여기에 벡터·전문 검색 엔진, 다양한 형식을 파싱하고 임베딩하는 수집 파이프라인, 동기화된 색인까지 필요해 구축과 운영 부담이 커진다. Amazon Bedrock Managed Knowledge Base는 수집·저장·임베딩·순위 산정을 관리하고 반복적 계획과 다중 홉 검색을 제공해 이러한 기반 작업을 줄인다.

2. 검색 서비스와 애플리케이션의 역할 분담

솔루션은 문서 수집과 대화형 검색이라는 두 흐름으로 구성되며, 사용자가 자신의 문서를 올리고 그 내용에 근거한 답변을 받도록 설계된다. 질문이 들어오면 Amazon Bedrock Knowledge Bases의 에이전트 검색 API가 응답 방식을 결정하고, 단순 조회에는 한 번의 검색을 수행한다. 복잡하거나 여러 부분으로 구성된 질문에는 하위 질의를 생성하고 여러 차례 검색한 뒤, 검색된 구절을 근거로 출처 인용을 포함한 답변을 만든다. 지식 기반은 검색 계획, 벡터 색인, 순위 산정기와 최종 응답 생성 모델을 담당한다. 애플리케이션은 업로드 경험, 채팅 화면, 인증, 사용자별 격리와 사용자 지정 업무 로직을 담당하므로, 관리형 기능을 사용하더라도 제품의 인증과 검색 범위 설정 책임은 남는다.

3. 주요 구성 요소와 비동기 업로드 흐름

Amazon API Gateway와 AWS Lambda는 업로드·상태·채팅 엔드포인트 및 애플리케이션 로직을 제공하고, Amazon Cognito는 인증과 사용자 격리에 필요한 검증된 신원을 제공한다. API Gateway가 요청의 JWT를 검증하면 업로드 처리기는 서버에서 추출한 사용자 식별자를 문서 또는 Amazon S3 참조와 함께 Amazon SQS 메시지에 넣고 사용자에게 응답한다. Amazon SQS는 업로드와 수집을 분리하고 업로드 급증을 흡수하며, 반복 실패한 메시지는 배달 못한 편지 대기열로 보낸다. 작업자 Lambda는 메시지의 사용자 식별자를 문서 메타데이터에 부여한 뒤 수집 API를 호출하고, 문서별 처리 상태는 Amazon DynamoDB에 기록된다. 브라우저는 상태 엔드포인트를 주기적으로 조회해 화면을 갱신하며, Amazon S3는 큰 파일의 임시 저장과 Amazon CloudFront 뒤에서 제공되는 단일 페이지 애플리케이션의 호스팅을 맡는다.

4. 사용자 지정 커넥터를 통한 직접 수집

실행 중인 애플리케이션에서 사용자가 올리는 문서는 Amazon S3 커넥터 대신 사용자 지정 커넥터 데이터 소스를 통해 직접 수집한다. 원문은 S3 커넥터가 예약된 동기화로 갱신하는 대량 문서 수집에 적합하며, 해당 동기화가 사용자가 방금 추가한 문서를 덮어쓰거나 제거할 수 있다고 설명한다. IngestKnowledgeBaseDocuments를 통한 직접 수집에는 이러한 동기화가 없으므로 문서는 삭제할 때까지 유지되고, 애플리케이션이 문서 ID를 직접 지정할 수 있다. 지식 기반은 각 원본 파일의 사본도 보관하며 GetDocumentContent API로 가져올 수 있어, 사용자가 응답의 근거가 된 원문을 열어볼 수 있다. 파일 크기에 따른 경로는 서버에서 결정하며, 6 MB까지는 API 호출에 바이트를 넣고 더 큰 텍스트 파일은 최대 50 MB까지 S3에 저장한 뒤 URI로 전달하되 두 경로 모두 같은 지식 기반으로 수집된다.

5. 문서 교체와 수집 요청의 단위

직접 수집에서는 애플리케이션이 문서 ID를 정하므로, 같은 ID로 다시 수집하면 중복 문서를 만드는 대신 기존 문서를 그 자리에서 갱신한다. 이를 위해 애플리케이션은 사용자의 파일과 문서 ID 사이의 대응 관계를 관리해야 하며, 참조 구현은 색인 상태를 기록하는 Amazon DynamoDB 테이블에 사용자 식별자와 파일명 조합에 대응하는 문서 ID도 저장한다. 사용자가 파일을 다시 올리면 기존 ID를 조회해 재사용하므로, 파일 교체가 기존 문서의 갱신으로 이어진다. 부분 수정은 지원하지 않기 때문에 편집된 문서도 전체를 다시 수집해야 한다. 또한 IngestKnowledgeBaseDocuments는 한 번의 호출에서 최대 10개 문서를 받을 수 있어, 작업자가 여러 수집 작업을 하나의 요청으로 묶어 전달할 수 있다.

6. 비동기 색인의 다섯 단계

IngestKnowledgeBaseDocuments는 요청을 받으면 STARTING 상태를 즉시 반환하지만, 이 시점에는 문서를 검색할 수 없다. 이후 문서는 처리 슬롯을 기다리는 PENDING을 거쳐 파싱과 임베딩이 실행되는 IN_PROGRESS로 이동하며, 이 두 단계에서도 검색은 불가능하다. TEXT_INDEXED에 도달하면 텍스트 청크의 색인이 완료되어 텍스트 검색이 가능하지만, PDF의 멀티모달 요소는 아직 처리 중일 수 있다. INDEXED는 처리가 모두 끝난 상태로, PDF 안의 이미지와 표 같은 멀티모달 요소도 검색할 수 있음을 뜻한다. 따라서 요청 수락과 검색 가능 상태를 구분해야 하며, STARTING을 검색 준비 완료로 취급하면 아직 색인 중인 문서를 대상으로 한 질의에서 빈 결과를 받을 수 있다.

7. 색인 시간의 관측값과 화면 표시

원문의 성능 수치는 유휴 상태의 지식 기반에서 5 MB 미만의 작은 문서를 시험한 관측값으로, 일반 텍스트는 검색 가능 상태와 전체 색인 완료까지 모두 2~3초가 걸렸다. PDF는 TEXT_INDEXED까지 5~30초, 전체 INDEXED까지 약 90초가 걸려 텍스트 검색과 멀티모달 처리 완료 사이에 차이가 있었다. 이 시간은 문서 크기, 내용의 복잡성, 리전과 지식 기반 부하에 따라 달라지며 서비스 수준 보장이나 확정 지연 시간이 아니다. 부하가 있으면 PENDING에서 처리 슬롯을 기다리는 시간도 추가되므로, 수집 대기열이 깊어질수록 전체 색인 완료가 늦어진다. 애플리케이션은 GetKnowledgeBaseDocuments로 조회한 상태를 Amazon DynamoDB에 기록하고 화면에 접수·처리 중·준비 완료로 표시하되, 텍스트 검색은 TEXT_INDEXED에서 사용할 수 있도록 안내한다.

8. 검증된 사용자 식별자에 기반한 검색 격리

사용자별 문서 격리는 테넌트마다 별도 지식 기반을 만들거나 하나의 공유 지식 기반에서 호출자의 검색 범위를 제한하는 방식으로 구현할 수 있다. 공유 방식은 메타데이터 필터 또는 서비스가 평가하는 문서별 접근 제어 목록을 사용하며, 원문은 최종 사용자가 많은 애플리케이션에서 계정별 지식 기반 할당량과 다수의 작은 색인에 따른 기본 비용을 피하는 선택으로 이를 제시한다. 예시 구조에서는 인증된 업로드 처리기가 검증된 JWT에서 얻은 Amazon Cognito sub를 메시지에 넣고, 작업자가 이를 문서의 user_id 메타데이터로 지정한다. 질문 처리 시에는 서버가 동일한 검증 신원으로 user_id의 equals 필터를 구성해 AgenticRetrieveStream을 호출하므로, 요청 본문에 담긴 사용자 값이 검색 범위를 결정하지 않는다. 지식 기반은 다중 홉 검색에서도 접근 권한을 적용하고, 애플리케이션은 허용된 문서에서 검색한 구절을 근거로 생성된 인용 포함 응답을 사용자에게 스트리밍한다.

🧾 핵심 주장 / 시사점

• 관리형 검색을 도입하면 검색 기반 시설의 운영 부담은 줄지만, 검증된 신원에서 사용자별 필터를 만드는 애플리케이션의 책임은 유지된다.
• 문서 업로드 완료, 텍스트 검색 가능, 멀티모달 처리 완료는 서로 다른 시점이므로 화면의 준비 상태도 이 차이를 반영해야 한다.
• 직접 수집의 문서 ID 재사용은 파일 교체를 단순하게 만들지만, 사용자 파일과 문서 ID의 대응 관계는 애플리케이션이 관리해야 한다.

✅ 액션 아이템

• 검증된 JWT에서 추출한 user_id가 문서 메타데이터와 AgenticRetrieveStream의 서버 측 equals 필터에 일관되게 적용되는지 확인.
• Amazon SQS로 업로드와 수집을 분리하고, 6 MB 인라인 한도와 최대 50 MB 텍스트 파일의 Amazon S3 참조 경로를 반영.
• Amazon DynamoDB의 색인 상태를 화면에 연결하고, TEXT_INDEXED의 텍스트 검색 가능 상태와 INDEXED의 처리 완료 상태를 구분.

❓ 열린 질문

• 검증된 JWT 기반 user_id와 서버 측 equals 필터가 모든 AgenticRetrieveStream 호출에 적용되는가?
• 6 MB를 초과하고 최대 50 MB인 텍스트 파일이 Amazon S3 참조 경로로 수집되는가?
• 화면은 STARTING을 준비 완료로 표시하지 않고 TEXT_INDEXED와 INDEXED의 차이를 반영하는가?