AWS Bedrock Knowledge Bases를 중심으로 사내 문서 기반 RAG 챗봇을 설계할 때, 어떤 서비스를 선택하고 어떻게 연결하는지를 아키텍처 관점에서 정리합니다.
핵심 요약
- AWS Bedrock Knowledge Bases는 S3 문서를 자동으로 Chunking → Embedding → 벡터 저장까지 처리하는 관리형 RAG 파이프라인입니다.
- 벡터 저장소로 OpenSearch Serverless를 사용하며, VPC 내부에서 프라이빗하게 통신할 수 있습니다.
- Bedrock Agent를 결합하면 단순 Q&A를 넘어 외부 API 호출, 다단계 추론이 가능한 챗봇을 구성할 수 있습니다.
- 데이터 유출 방지를 위해 VPC Endpoint, IAM 최소 권한, S3 버킷 정책, Guardrails를 조합하여 보안 계층을 설계합니다.
- 비용은 모델 호출(토큰), 벡터 저장소(OCU), S3 저장 세 가지에서 발생하며, 트래픽 패턴에 따라 비용 구조가 달라집니다.
1. 설계 배경과 요구사항
사내 기술 문서, 운영 매뉴얼, FAQ를 기반으로 직원들이 자연어로 질문할 수 있는 챗봇을 구축한다고 가정합니다.
1.1 비즈니스 요구사항
- 직원 500명이 사용하는 사내 문서 검색 챗봇
- 문서 규모: PDF, Confluence 페이지, Markdown 약 5,000건
- 응답 시간: 5초 이내
- 보안: 사내 문서가 외부로 유출되면 안 됨
- 운영: 인프라 관리 인력 최소화 (관리형 서비스 우선)
1.2 기술 제약 조건
- 기존 인프라가 AWS에 있으므로 AWS 서비스 우선 검토
- VPC 내부에서만 접근 가능해야 함 (인터넷 노출 금지)
- 문서 업데이트 시 자동으로 인덱스가 갱신되어야 함
- 답변에 출처 문서를 반드시 포함해야 함
1.3 왜 Bedrock Knowledge Bases를 선택했는가
RAG 챗봇을 구축하는 방법은 여러 가지가 있습니다.
| 선택지 | 장점 | 단점 |
|---|---|---|
| LangChain + Pinecone + OpenAI | 유연한 커스터마이징 | 인프라 직접 관리, 데이터 외부 전송 |
| LangChain + pgvector + 자체 LLM | 완전한 통제 | 운영 복잡도 높음, GPU 인프라 필요 |
| Bedrock Knowledge Bases | 관리형, VPC 내부 통신, IAM 통합 | 커스터마이징 제한, AWS 종속 |
| Azure AI Search + Azure OpenAI | 엔터프라이즈 검색 강점 | Azure 환경 필요 |
이 시나리오에서는 다음 이유로 Bedrock Knowledge Bases를 선택합니다.
- 보안: 모든 데이터가 AWS 계정 내부에서 처리됩니다. 외부 API로 사내 문서를 전송할 필요가 없습니다.
- 운영 부담 최소화: Chunking, Embedding, 벡터 저장소 관리를 AWS가 처리합니다.
- 기존 인프라 통합: S3, IAM, VPC, CloudWatch 등 기존 AWS 리소스와 자연스럽게 연결됩니다.
- 모델 선택 유연성: Claude, Titan, Llama 등 여러 모델을 동일 인터페이스로 교체할 수 있습니다.
다만 Chunking 전략의 세밀한 제어나 커스텀 Reranker 적용이 필요하다면, 직접 구축 방식을 검토해야 합니다.
2. 전체 아키텍처 구조
이 아키텍처는 크게 세 영역으로 나뉩니다.
| 영역 | 역할 | 주요 서비스 |
|---|---|---|
| 데이터 수집/인덱싱 | 문서를 벡터로 변환하여 저장 | S3, Bedrock Knowledge Bases, OpenSearch Serverless |
| 질의/응답 | 사용자 질문에 대해 검색 + 생성 | Bedrock Agent, Knowledge Bases, Foundation Model |
| 보안/운영 | 접근 제어, 모니터링, 비용 관리 | VPC Endpoint, IAM, CloudWatch, Guardrails |
2.1 데이터 흐름 요약
- 운영팀이 S3 버킷에 문서를 업로드합니다.
- Bedrock Knowledge Bases가 문서를 Chunking → Embedding → OpenSearch Serverless에 저장합니다.
- 사용자가 챗봇에 질문을 입력합니다.
- Bedrock Agent가 질문을 분석하고, Knowledge Bases에서 관련 문서를 검색합니다.
- 검색된 문서를 컨텍스트로 Foundation Model(Claude 등)에 전달하여 응답을 생성합니다.
- 출처 정보와 함께 사용자에게 응답을 반환합니다.
3. 핵심 구성 요소 상세
3.1 Amazon Bedrock Knowledge Bases
Knowledge Bases는 RAG의 오프라인 파이프라인(문서 수집 → Chunking → Embedding → 저장)을 자동화하는 관리형 서비스입니다.
동작 방식:
- S3 버킷을 데이터 소스로 지정합니다.
- 동기화(Sync)를 실행하면 문서를 자동으로 파싱합니다.
- 설정된 Chunking 전략에 따라 문서를 분할합니다.
- Embedding 모델(Titan Embeddings V2 등)로 벡터를 생성합니다.
- OpenSearch Serverless 컬렉션에 벡터를 저장합니다.
Chunking 옵션:
| 전략 | 설명 | 적합한 경우 |
|---|---|---|
| Fixed-size | 고정 토큰 수로 분할 (기본 300토큰, 최대 overlap 20%) | 구조가 일정한 문서 |
| Hierarchical | 부모-자식 청크 구조 (부모 1500토큰, 자식 300토큰) | 긴 문서에서 문맥 유지 필요 시 |
| Semantic | 의미 단위로 분할 | 구조가 다양한 문서 |
| No chunking | 문서 전체를 하나의 청크로 | 짧은 FAQ 문서 |
설계 관점에서 Hierarchical Chunking을 선택한 이유: - 사내 문서는 섹션 구조가 있는 긴 문서가 많습니다. - 자식 청크로 정밀 검색하되, 부모 청크로 넓은 문맥을 LLM에 전달할 수 있습니다. - 다만 저장 용량이 약 2배로 증가하므로 비용 trade-off를 고려해야 합니다.
3.2 Amazon OpenSearch Serverless (벡터 저장소)
Knowledge Bases의 벡터 저장소로 OpenSearch Serverless를 사용합니다.
왜 OpenSearch Serverless인가:
| 선택지 | 장점 | 단점 |
|---|---|---|
| OpenSearch Serverless | 관리형, 자동 스케일링, VPC 지원 | 최소 비용 발생 (OCU 단위) |
| Aurora PostgreSQL (pgvector) | 기존 RDS 활용 가능, 비용 예측 쉬움 | 벡터 검색 성능 제한, 직접 스키마 관리 |
| Pinecone | 벡터 검색 전문, 높은 성능 | 외부 서비스, 데이터 외부 전송 |
| Redis (벡터 검색) | 낮은 지연 시간 | 메모리 비용, 대규모 데이터 부적합 |
이 시나리오에서는 보안(VPC 내부 통신)과 운영 편의성(관리형)을 우선하여 OpenSearch Serverless를 선택합니다.
OCU(OpenSearch Compute Unit) 이해:
OpenSearch Serverless는 OCU 단위로 과금됩니다. 최소 구성은 인덱싱 2 OCU + 검색 2 OCU = 4 OCU입니다.
- 1 OCU = 약 $0.24/시간 (us-east-1 기준)
- 기존에는 최소 4 OCU가 상시 필요했으나, 현재는 scale-to-zero를 지원하여 사용하지 않을 때 비용이 발생하지 않습니다.
- 다만 프로덕션 환경에서 상시 가용성이 필요하면 최소 4 OCU × 24시간 × 30일 = 약 $691/월이 발생할 수 있습니다.
- 트래픽 패턴에 따라 비용이 크게 달라지므로, PoC 단계에서는 scale-to-zero를 활용하여 비용을 줄일 수 있습니다.
3.3 Amazon Bedrock Agent
Agent는 사용자 질문을 분석하고, 적절한 도구(Knowledge Bases, API 등)를 선택하여 다단계 추론을 수행합니다.
Agent가 필요한 이유:
단순 RAG(질문 → 검색 → 응답)만으로는 부족한 경우가 있습니다.
- "지난달 장애 보고서를 요약해줘" → Knowledge Bases 검색
- "이 장애의 담당자에게 알림을 보내줘" → 외부 API 호출 (Action Group)
- "장애 보고서를 요약하고, 담당자에게 알림까지 보내줘" → 다단계 추론
Agent는 이런 복합 요청을 분해하여 순차적으로 처리합니다.
Agent 구성 요소:
| 구성 요소 | 역할 |
|---|---|
| Instruction | Agent의 역할과 행동 규칙을 정의하는 시스템 프롬프트 |
| Knowledge Bases | 문서 검색 도구로 연결 |
| Action Groups | 외부 API를 호출하는 Lambda 함수 연결 |
| Guardrails | 입출력 필터링 규칙 |
3.4 Foundation Model 선택
Bedrock에서 사용할 수 있는 모델 중 RAG 챗봇에 적합한 선택지를 비교합니다.
| 모델 | 강점 | 비용 (입력/출력 per 1M 토큰) | 적합한 경우 |
|---|---|---|---|
| Claude Sonnet 4.6 | 균형 잡힌 성능, 긴 컨텍스트 (1M) | $3 / $15 | 범용 Q&A, 문서 요약 |
| Claude Haiku 4.5 | 빠른 응답, 중간 비용 | $1 / $5 | 간단한 질문, 높은 트래픽 |
| Amazon Titan Text Express | AWS 네이티브, 낮은 비용 | $0.20 / $0.60 | 비용 최적화 우선 |
| Llama 3 70B Instruct | 오픈소스, 커스터마이징 가능 | $0.99 / $0.99 | 특정 도메인 튜닝 필요 시 |
설계 결정:
- 기본 모델: Claude Sonnet 4.6 — 문서 이해력과 한국어 응답 품질이 높음
- 간단한 질문 라우팅: Claude Haiku 4.5 — 비용 절감을 위해 질문 복잡도에 따라 모델을 분기
- 이 라우팅은 Agent의 Instruction에서 제어하거나, 앞단에 분류기를 두어 구현할 수 있습니다.
4. 데이터 파이프라인 설계
4.1 문서 수집 흐름
[Confluence/SharePoint] → [Lambda: 문서 추출] → [S3 버킷]
│
[직접 업로드 (PDF/MD)] ─────────────────────────────→ │
▼
[S3 이벤트 트리거]
│
▼
[Bedrock Knowledge Bases: Sync]
│
▼
[OpenSearch Serverless: 벡터 저장]
4.2 자동 동기화 설계
문서가 업데이트되면 인덱스도 자동으로 갱신되어야 합니다.
방법 1: EventBridge + Lambda (권장)
- S3 버킷에 객체가 생성/수정되면 EventBridge 규칙이 트리거됩니다.
- Lambda 함수가
StartIngestionJobAPI를 호출합니다. - Knowledge Bases가 변경된 문서만 증분 인덱싱합니다.
방법 2: 스케줄 기반 동기화
- EventBridge Scheduler로 매일 새벽 2시에 동기화를 실행합니다.
- 구현이 단순하지만, 문서 변경과 인덱스 반영 사이에 지연이 발생합니다.
설계 관점에서는 방법 1을 기본으로 하되, 대량 문서 업로드 시에는 디바운싱(5분 대기 후 한 번에 동기화)을 적용합니다. 매번 개별 파일마다 동기화를 실행하면 비용이 증가할 수 있습니다.
4.3 S3 버킷 구조 설계
s3://company-rag-documents/
├── raw/ # 원본 문서
│ ├── hr-policy/
│ ├── tech-docs/
│ └── operations/
├── processed/ # 전처리된 문서 (Knowledge Bases 데이터 소스)
│ ├── hr-policy/
│ ├── tech-docs/
│ └── operations/
└── metadata/ # 문서 메타데이터 (접근 권한, 부서 등)
raw/와 processed/를 분리하는 이유: - 원본 문서(PPT, 복잡한 PDF 등)는 전처리가 필요할 수 있습니다. - Knowledge Bases가 파싱하기 좋은 형태(텍스트 추출된 PDF, Markdown)로 변환 후 processed/에 저장합니다. - 메타데이터 파일(.metadata.json)을 함께 저장하면 검색 시 필터링에 활용할 수 있습니다.
5. 보안 아키텍처
RAG 챗봇은 사내 문서를 LLM에 전달하는 구조이므로, 데이터 유출 경로를 설계 단계에서 차단해야 합니다. Bedrock은 AWS 계정 내에서 처리되지만, 추가 보안 계층이 필요합니다.
5.1 네트워크 격리
| 계층 | 설정 | 목적 |
|---|---|---|
| VPC Endpoint | Bedrock, S3, OpenSearch용 Interface Endpoint 생성 | 인터넷 경유 없이 프라이빗 통신 |
| Security Group | Endpoint에 대한 인바운드를 애플리케이션 서브넷으로 제한 | 접근 범위 최소화 |
| S3 Bucket Policy | VPC Endpoint 경유 요청만 허용 | 퍼블릭 접근 차단 |
| NAT Gateway 제거 | Private Subnet에서 인터넷 아웃바운드 차단 | 데이터 유출 경로 제거 |
5.2 IAM 권한 설계
최소 권한 원칙에 따라 역할별 권한을 분리합니다.
Bedrock Agent 실행 역할:
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:Retrieve"
],
"Resource": [
"arn:aws:bedrock:*:*:knowledge-base/KB_ID",
"arn:aws:bedrock:*:*:foundation-model/anthropic.claude-*"
]
}
Knowledge Bases 서비스 역할:
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::company-rag-documents/processed/*"
]
}
주의할 점: - Knowledge Bases 역할에 s3:* 같은 와일드카드를 부여하면, 의도하지 않은 버킷의 문서까지 인덱싱될 수 있습니다. - processed/ 경로만 허용하여 원본 문서(raw/)에 대한 직접 접근을 차단합니다.
5.3 Bedrock Guardrails
Guardrails는 LLM의 입출력을 필터링하는 보안 계층입니다.
| 기능 | 설정 예시 | 목적 |
|---|---|---|
| Content filters | 유해 콘텐츠 차단 (hate, violence 등) | 부적절한 응답 방지 |
| Denied topics | "경쟁사 비교", "급여 정보" 등 금지 주제 설정 | 민감 정보 노출 방지 |
| Word filters | 특정 키워드 차단 | PII, 내부 코드명 유출 방지 |
| Sensitive information filters | 주민번호, 카드번호 등 PII 마스킹 | 개인정보 보호 |
| Contextual grounding | 검색 결과에 근거하지 않은 응답 차단 | Hallucination 감소 |
설계 관점에서 Contextual grounding check는 RAG 챗봇에서 특히 중요합니다. 검색된 문서에 없는 내용을 모델이 생성하면 "해당 정보를 찾을 수 없습니다"로 응답하도록 설정합니다.
5.4 문서 접근 제어
사용자별로 볼 수 있는 문서가 다른 경우, 검색 시 메타데이터 필터링을 적용합니다.
사용자 질문 → [사용자 부서/권한 확인] → [메타데이터 필터 생성]
│
▼
Knowledge Bases 검색 (filter: department=engineering)
Knowledge Bases의 RetrieveAndGenerate API에서 retrievalConfiguration.vectorSearchConfiguration.filter를 사용하여 메타데이터 기반 필터링을 적용할 수 있습니다.
6. 비용 설계
Bedrock 기반 RAG의 비용은 OpenSearch Serverless의 OCU 사용량과 LLM 호출 토큰에 의해 결정됩니다. scale-to-zero를 지원하지만, 프로덕션 환경에서 상시 가용성을 유지하면 월 $600 이상이 발생할 수 있으므로, PoC 단계에서는 비용 구조를 먼저 확인해야 합니다.
6.1 비용 구조 분석
| 구성 요소 | 과금 기준 | 월 예상 비용 (500명, 일 50건 질문 기준) |
|---|---|---|
| OpenSearch Serverless | OCU × 시간 (scale-to-zero 지원) | ~$200~691 (트래픽 패턴에 따라) |
| Bedrock 모델 호출 (Claude Sonnet) | 입력/출력 토큰 | ~$45~90 (일 1,500건 × 평균 2K 토큰) |
| Bedrock Embedding (Titan V2) | 입력 토큰 | ~$5 (인덱싱 시 1회 + 질문당) |
| S3 저장 | GB/월 | ~$1~5 |
| VPC Endpoint | 시간 + 데이터 처리량 | ~$22~44 (2~4개 Endpoint) |
| 합계 | ~$273~835/월 |
6.2 비용 최적화 전략
1. 모델 라우팅으로 LLM 비용 절감
모든 질문에 Claude Sonnet을 사용하면 비용이 높아집니다. 질문 복잡도에 따라 모델을 분기합니다.
- 간단한 FAQ → Claude Haiku 4.5 (비용 1/3)
- 복잡한 분석/요약 → Claude Sonnet 4.6
2. 응답 캐싱
동일하거나 유사한 질문에 대한 응답을 캐싱합니다. - ElastiCache(Redis)에 질문 해시 → 응답을 저장 - 캐시 히트율이 30%만 되어도 LLM 호출 비용을 의미 있게 줄일 수 있습니다.
3. OpenSearch Serverless 비용 관리
- 업무 시간 외에는 검색 OCU를 최소로 유지합니다.
- 인덱싱 OCU는 동기화 시에만 활성화되도록 설정합니다.
- 소규모 PoC에서는 Aurora PostgreSQL + pgvector를 대안으로 검토할 수 있습니다 (최소 비용이 낮음).
7. 운영 설계
7.1 모니터링 지표
| 지표 | 수집 방법 | 알림 기준 |
|---|---|---|
| 응답 지연 시간 (P95) | CloudWatch Metrics | > 5초 |
| 모델 호출 실패율 | Bedrock CloudWatch Logs | > 1% |
| 검색 결과 0건 비율 | 애플리케이션 로그 | > 20% |
| 토큰 사용량 | Bedrock 사용량 메트릭 | 일일 예산 초과 시 |
| OpenSearch OCU 사용률 | OpenSearch Serverless 메트릭 | > 80% |
7.2 검색 품질 평가
RAG 시스템에서 가장 중요한 운영 지표는 검색 품질입니다.
평가 방법:
- 수동 평가 (초기): 50~100개 질문-정답 쌍을 만들어 검색 결과의 관련성을 평가합니다.
- 자동 평가 (운영): 사용자 피드백(👍/👎)을 수집하여 검색 품질 추이를 모니터링합니다.
- A/B 테스트: Chunking 전략이나 Top-K 값을 변경할 때, 일부 트래픽으로 효과를 검증합니다.
검색 품질이 낮을 때 확인할 항목:
- Chunk 크기가 너무 크거나 작지 않은지
- 문서 전처리 품질 (PDF에서 텍스트가 제대로 추출되었는지)
- Embedding 모델이 한국어를 잘 처리하는지
- 메타데이터 필터가 너무 좁게 설정되어 있지 않은지
7.3 장애 대응
| 장애 시나리오 | 영향 | 대응 방안 |
|---|---|---|
| Bedrock 모델 호출 실패 | 응답 불가 | 대체 모델로 자동 Fallback (Sonnet → Haiku) |
| OpenSearch Serverless 장애 | 검색 불가 | "현재 검색이 불가합니다" 안내 + 캐시된 응답 제공 |
| S3 접근 불가 | 인덱싱 실패 | 기존 인덱스로 서비스 유지, 알림 발송 |
| 토큰 한도 초과 | 응답 불가 | 일일 한도 설정 + 초과 시 큐잉 처리 |
8. 확장 설계
8.1 멀티 Knowledge Base 구성
문서 유형이나 부서별로 Knowledge Base를 분리하면 검색 정밀도를 높일 수 있습니다.
[사용자 질문]
│
▼
[Agent: 질문 분류]
│
├── HR 관련 → KB-HR (인사 정책 문서)
├── 기술 관련 → KB-Tech (기술 문서, API 스펙)
└── 운영 관련 → KB-Ops (운영 매뉴얼, 장애 보고서)
분리의 장점: - 검색 범위가 좁아져 정밀도가 향상됩니다. - Knowledge Base별로 Chunking 전략을 다르게 적용할 수 있습니다. - 접근 권한을 Knowledge Base 단위로 제어할 수 있습니다.
다만 Knowledge Base가 많아지면 Agent의 라우팅 정확도가 중요해집니다. 질문이 어느 KB에 해당하는지 잘못 판단하면 검색 결과가 없거나 부정확해집니다.
8.2 Action Group을 활용한 기능 확장
Knowledge Bases 검색 외에 외부 시스템과 연동이 필요한 경우, Action Group으로 Lambda 함수를 연결합니다.
| Action Group | 연결 대상 | 사용 예시 |
|---|---|---|
| ticket-create | Jira API | "이 장애에 대한 티켓을 생성해줘" |
| user-lookup | 사내 LDAP | "김철수 팀장의 연락처를 알려줘" |
| metric-query | CloudWatch API | "어제 API 응답 시간 P95가 얼마였어?" |
Action Group 설계 시 주의할 점: - Lambda 함수의 IAM 역할에 최소 권한만 부여합니다. - 쓰기 작업(티켓 생성, 알림 발송)은 사용자 확인 단계를 추가합니다. - Agent가 잘못된 Action을 호출하지 않도록 OpenAPI 스펙을 명확하게 정의합니다.
9. 대안 아키텍처와 비교
9.1 직접 구축 vs Bedrock Knowledge Bases
| 기준 | Bedrock Knowledge Bases | 직접 구축 (LangChain + 자체 인프라) |
|---|---|---|
| 초기 구축 시간 | 1~2주 | 4~8주 |
| Chunking 커스터마이징 | 제한적 (4가지 옵션) | 완전 자유 |
| Reranker 적용 | 제한적 | 자유롭게 적용 가능 |
| 벡터 저장소 선택 | OpenSearch Serverless, Aurora, Pinecone 등 | 제한 없음 |
| 운영 부담 | 낮음 (관리형) | 높음 (직접 관리) |
| 최소 비용 | ~$700/월 (OpenSearch OCU) | 구성에 따라 다름 |
| 보안 통합 | IAM, VPC 네이티브 | 직접 구현 |
| 모니터링 | CloudWatch 통합 | 직접 구축 |
선택 기준:
- 빠른 출시 + 운영 인력 부족 → Bedrock Knowledge Bases
- 검색 품질 극대화 + 커스텀 파이프라인 필요 → 직접 구축
- PoC 단계에서 비용 최소화 → 직접 구축 (pgvector + 작은 모델)
9.2 Bedrock Knowledge Bases vs Kendra
Amazon Kendra도 문서 검색 서비스이지만, 접근 방식이 다릅니다.
| 기준 | Bedrock Knowledge Bases | Amazon Kendra |
|---|---|---|
| 검색 방식 | 벡터 유사도 검색 | 시맨틱 검색 + 키워드 검색 |
| LLM 통합 | Bedrock 모델과 네이티브 연동 | 별도 LLM 연동 필요 |
| 비용 | OCU 기반 (OpenSearch) | Storage Unit + Query Unit 시간 기반 과금 (공식 가격 페이지 참고) |
| 데이터 소스 | S3 중심 | S3, SharePoint, Confluence, DB 등 다양 |
| 적합한 경우 | RAG 기반 생성형 AI 챗봇 | 전통적 엔터프라이즈 검색 |
RAG 챗봇이 목적이라면 Bedrock Knowledge Bases가 더 적합합니다. 기존 엔터프라이즈 검색 시스템이 필요하다면 Kendra를 검토합니다.
10. 구현 시 자주 하는 실수
- OpenSearch Serverless 비용을 간과하는 것: PoC에서 "관리형이니까 편하겠지"라고 시작했다가 월 $700 청구서를 받는 경우가 있습니다. 소규모 테스트에서는 Aurora pgvector나 로컬 벡터 DB를 먼저 사용하는 것이 합리적입니다.
- 문서 전처리를 건너뛰는 것: PDF에서 텍스트가 제대로 추출되지 않으면 Chunking과 Embedding 품질이 모두 떨어집니다. 특히 스캔된 PDF, 표가 많은 문서는 별도 전처리가 필요합니다.
- Guardrails 없이 배포하는 것: 사내 챗봇이라도 Prompt Injection으로 시스템 프롬프트가 노출되거나, 의도하지 않은 정보가 응답에 포함될 수 있습니다. Guardrails는 초기부터 설정합니다.
- 단일 Knowledge Base에 모든 문서를 넣는 것: 문서 유형이 다양하면 검색 노이즈가 증가합니다. HR 문서와 기술 문서의 Chunking 전략이 같을 수 없습니다.
- 동기화 전략을 설계하지 않는 것: 문서가 업데이트되었는데 인덱스가 갱신되지 않으면, 챗봇이 오래된 정보를 답합니다. 자동 동기화 파이프라인은 초기 설계에 포함해야 합니다.
- 응답 캐싱을 고려하지 않는 것: 같은 질문이 반복되는 환경(FAQ 성격)에서 매번 LLM을 호출하면 비용이 불필요하게 증가합니다.
11. 정리
- AWS Bedrock Knowledge Bases는 S3 → Chunking → Embedding → 벡터 저장 → 검색 → 생성까지의 RAG 파이프라인을 관리형으로 제공합니다.
- 보안 설계의 핵심은 VPC Endpoint로 네트워크를 격리하고, IAM으로 최소 권한을 적용하며, Guardrails로 입출력을 필터링하는 것입니다.
- 비용의 대부분은 OpenSearch Serverless OCU에서 발생하므로, 트래픽 규모에 맞는 벡터 저장소 선택이 중요합니다.
- Agent를 결합하면 단순 Q&A를 넘어 외부 시스템 연동, 다단계 추론이 가능한 챗봇으로 확장할 수 있습니다.
- 직접 구축 대비 운영 부담은 낮지만, Chunking 커스터마이징과 비용 유연성에서는 제약이 있습니다. 요구사항에 따라 선택합니다.
참고 문서
'AI' 카테고리의 다른 글
| RAG Chunking 전략: 문서를 나누는 기준과 성능 영향 (0) | 2026.06.06 |
|---|---|
| RAG와 Fine-tuning 차이: LLM 커스터마이징 전략 선택 기준 (0) | 2026.05.31 |
| AI 애플리케이션 보안 리스크: Prompt Injection과 데이터 유출 (0) | 2026.05.31 |
| Multi-modal RAG 구현 전략: 이미지, 테이블, 차트를 RAG에 통합하기 (0) | 2026.05.29 |
| RAG란 무엇인가: LLM 애플리케이션 아키텍처 관점에서 이해하기 (0) | 2026.05.29 |
