Amazon Bedrock 지식베이스 구축 2026, 사내 RAG 비용·보안·운영 기준
Amazon Bedrock 지식베이스 구축을 검색한 팀은 “문서 넣고 챗봇 만들기”보다 더 현실적인 문제에 걸려 있다.
사내 문서는 부서별 권한, 오래된 버전, 첨부 파일, 개인정보, 비용 한도, 검색 품질 기준이 뒤섞여 있다.
AWS 공식 문서는 Bedrock Knowledge Bases가 RAG 방식으로 데이터 소스를 검색해 답변 근거를 보강한다고 설명한다.
2026년의 Amazon Bedrock 지식베이스 구축은 콘솔 클릭 순서보다 데이터 소유권과 운영 책임을 먼저 정해야 실패가 적다.
이 글은 AWS 공식 문서와 가격 페이지를 기준으로 관리형 선택, 권한, 비용, 검색 품질, 운영 런북을 실무 관점으로 정리한다.
- 처음 구축하는 팀은 관리형 지식베이스를 우선 검토하고, 기존 벡터 저장소가 강한 제약일 때만 고객관리형을 본다.
- 데이터 소스 연결 전 문서 소유자, 권한 필터, KMS, 서비스 역할, 삭제 절차를 먼저 승인해야 한다.
- 비용은 모델 호출만 보지 말고 수집, 임베딩, 저장소, 재순위화, 동기화 주기, 로그 보관까지 함께 계산해야 한다.
- 출시 기준은 답변이 자연스러운지가 아니라 인용 정확도, 권한 누수, 실패 질문, 롤백 절차가 통과했는지다.
이 글이 필요한 사람
- 사내 문서 검색 챗봇을 Amazon Bedrock 기반으로 만들려는 AI 플랫폼 팀
- S3, Confluence, SharePoint, Google Drive 문서를 RAG에 연결하려는 클라우드 엔지니어
- 임직원 권한에 따라 검색 결과가 달라져야 하는 보안 담당자
- Bedrock 비용이 모델 호출 외 어디서 커지는지 확인해야 하는 FinOps 담당자
- POC를 끝내고 운영 서비스로 전환할 승인 기준이 필요한 프로젝트 오너
Amazon Bedrock 지식베이스 구축을 RAG 제품 선택으로만 보면 안 된다
Bedrock Knowledge Bases는 파운데이션 모델이 모르는 사내 문서를 검색해 답변 근거로 넣는 RAG 계층이다.
AWS 문서는 질의가 들어오면 지식베이스가 관련 정보를 찾고 그 정보를 생성 답변 품질 개선에 쓴다고 설명한다.
이 구조에서 품질은 모델 성능만으로 결정되지 않고 문서 품질, 청크 전략, 권한 필터, 검색 순위, 인용 처리에 묶인다.
그래서 첫 회의의 질문은 “어떤 모델이 좋은가”가 아니라 “어떤 문서를 누구에게 보여줄 수 있는가”여야 한다.
| 검토 항목 | 잘못된 출발점 | 운영형 출발점 | 확인할 증거 |
|---|---|---|---|
| 데이터 소스 | 문서를 모두 S3에 올린다. | 문서 소유자와 공개 범위를 먼저 분류한다. | 데이터 카탈로그와 승인 기록 |
| 검색 품질 | 답변이 자연스러운지 본다. | 인용이 맞는지와 누락 질문을 본다. | golden question 테스트 |
| 보안 | 콘솔 권한만 열어준다. | 서비스 역할과 문서별 권한을 분리한다. | IAM, KMS, 접근 로그 |
| 비용 | 모델 토큰 비용만 본다. | 수집, 임베딩, 저장소, 재순위화를 같이 본다. | 월별 비용 리포트 |
Amazon Bedrock 지식베이스 구축은 AI 기능 개발이면서 동시에 사내 문서 거버넌스 재정비 작업이다.
관리형 지식베이스와 고객관리형 지식베이스 선택 기준
AWS 문서는 Managed Knowledge Base와 Customer-managed Knowledge Base를 구분한다.
관리형은 수집, 인덱싱, 저장, 검색 인프라를 Bedrock이 맡아 애플리케이션과 에이전트 로직에 집중하게 해준다.
고객관리형은 벡터 저장소와 수집 파이프라인을 직접 관리하는 대신 기존 아키텍처와 세밀한 제어를 유지할 수 있다.
| 선택지 | 맞는 상황 | 주의할 비용 | 보안 체크 |
|---|---|---|---|
| 관리형 지식베이스 | 새 RAG 서비스를 빠르게 만들고 커넥터와 운영 부담을 줄이고 싶다. | 서비스 관리 모델, 수집, 저장, 검색 호출 비용을 확인한다. | 문서별 권한 필터와 데이터 소스 접근 범위를 검토한다. |
| 고객관리형 지식베이스 | 이미 OpenSearch, Aurora, Neptune 같은 저장소 전략이 정해져 있다. | 저장소 운영, 인덱스 튜닝, 백업, 장애 대응 비용이 남는다. | 네트워크 경계와 Secrets Manager 연동을 따로 점검한다. |
| 혼합 접근 | 초기 서비스는 관리형으로 만들고 특정 도메인만 별도 저장소를 쓴다. | 운영 모델이 두 개가 되어 관측과 장애 대응이 복잡해진다. | 권한 정책과 삭제 절차가 경로별로 갈라지지 않게 한다. |
초기 POC는 관리형으로 빠르게 시작하되 운영 전에는 고객관리형이 필요한 강한 이유가 있는지 한 번 더 따져야 한다.
구축 순서: 콘솔보다 데이터 준비가 먼저다
Amazon Bedrock 지식베이스 구축은 콘솔에서 시작해도 실제 작업은 문서 정리와 권한 합의에서 대부분의 시간이 걸린다.
- 사용 사례를 “사내 정책 검색”, “고객지원 답변”, “개발 문서 검색”처럼 하나로 좁힌다.
- 데이터 소스별 소유자, 최신성, 접근 권한, 삭제 책임자를 표로 만든다.
- 지원 문서 형식과 파일 크기 한도를 공식 문서 기준으로 확인한다.
- S3 또는 지원 커넥터의 원본 문서를 샘플링해 중복, 오래된 파일, 민감 정보를 제거한다.
- 관리형 또는 고객관리형 지식베이스 선택 사유를 보안팀과 운영팀에 공유한다.
- 서비스 역할, KMS, 벡터 저장소 접근, Secrets Manager 권한을 최소 권한으로 설계한다.
- 지식베이스를 만든 뒤 데이터 소스 동기화를 실행하고 실패 문서를 따로 모은다.
- Retrieve 또는 RetrieveAndGenerate 흐름으로 샘플 질문을 테스트하고 인용을 검수한다.
- 운영 전 golden question, 권한 필터, 비용 경보, 롤백 절차를 통과시킨다.
이 순서에서 Bedrock 콘솔 작업은 중간 단계이고, 앞뒤의 데이터 승인과 운영 검증이 실제 품질을 결정한다.
데이터 소스 설계: 문서가 많을수록 답변이 좋아지는 것은 아니다
AWS 문서는 지식베이스 데이터가 지원 데이터 소스에 있어야 하고 수집 과정에서 청크로 나뉜다고 설명한다.
문서 수를 늘리는 것보다 같은 질문에 최신 문서가 먼저 검색되도록 원본을 정리하는 편이 더 중요하다.
- 정책 문서: 최신 승인본과 폐기본을 분리하고 파일명에 버전과 시행일을 넣는다.
- 기술 문서: README, 운영 런북, 장애 회고를 섞되 테스트 로그와 임시 메모는 제외한다.
- 지원 문서: 고객별 원문을 바로 넣지 말고 익명화된 FAQ와 승인된 매뉴얼을 우선한다.
- 첨부 파일: PDF, 표, 이미지가 섞이면 추출 품질을 별도로 샘플링한다.
- 웹 크롤러: 권한 필터 예외와 robots 정책을 확인한 뒤 범위를 작게 시작한다.
검색 품질은 원본 문서의 양보다 “같은 질문에 서로 다른 답이 검색되지 않는가”에서 먼저 무너진다.
권한과 보안: 서비스 역할을 자동 생성해도 책임은 남는다
AWS 권한 문서는 커스텀 역할을 만들 때 필요한 권한만 포함하라고 안내한다.
Bedrock 지식베이스는 모델 접근, 데이터 소스 접근, 벡터 저장소 접근, KMS 복호화 권한이 함께 움직인다.
따라서 권한 설계는 “콘솔에서 생성됨”으로 끝내지 말고 누가 어떤 데이터 원본을 검색할 수 있는지까지 내려가야 한다.
| 보안 항목 | 실무 질문 | 검증 방법 | 실패 시 조치 |
|---|---|---|---|
| 서비스 역할 | 이 역할이 꼭 필요한 데이터 소스만 읽는가. | IAM policy와 CloudTrail 이벤트를 확인한다. | 역할 분리와 리소스 조건을 추가한다. |
| KMS | 민감 문서와 벡터 저장소가 같은 키 정책으로 보호되는가. | 키 정책과 복호화 권한을 샘플링한다. | 키 분리 또는 조건부 권한을 적용한다. |
| 문서별 권한 | 사용자가 볼 수 없는 문서가 인용으로 나오지 않는가. | 권한이 다른 계정으로 같은 질문을 던진다. | 데이터 소스 ACL 또는 필터 전략을 수정한다. |
| 로그 | 질문과 답변 로그에 개인정보가 남는가. | 관측 로그와 보관 기간을 확인한다. | 마스킹과 보관 기간 단축을 적용한다. |
보안팀이 봐야 할 핵심은 Bedrock 자체보다 원본 문서 권한이 검색 시점에도 유지되는지다.
Guardrails와 인용: 안전장치의 범위를 오해하지 않는다
AWS Guardrails 문서는 유해 콘텐츠 필터와 개인정보 보호 같은 안전장치를 제공한다고 설명한다.
다만 AWS 문서는 RetrieveAndGenerate 흐름에서 Guardrails가 검색된 참조 자체에는 적용되지 않는다고 별도로 적고 있다.
이 차이를 모르면 모델 응답은 필터링됐지만 검색된 원문 조각이 민감 정보를 품고 있는 상태를 놓칠 수 있다.
- Guardrails는 입력과 생성 답변의 안전장치로 보고 데이터 정제 도구로 오해하지 않는다.
- 민감 문서는 수집 전 분류와 마스킹을 먼저 적용한다.
- 인용은 답변 신뢰도를 높이지만 잘못된 문서를 인용하면 책임도 같이 커진다.
- 권한이 낮은 계정의 질문에서 높은 권한 문서 제목이 노출되는지 확인한다.
- 문서 삭제나 권한 변경 뒤 지식베이스 재동기화와 인덱스 반영 시간을 확인한다.
Amazon Bedrock 지식베이스 구축에서 Guardrails는 마지막 방어선이고 첫 방어선은 데이터 소스 승인이다.
비용 구조: 모델 호출보다 수집과 저장소를 같이 본다
AWS Bedrock 가격 페이지는 모델, Knowledge Bases, Guardrails 같은 항목을 나눠 가격을 제공한다.
정확한 단가는 리전과 모델에 따라 공식 가격표를 다시 확인해야 하며, 설계 단계에서는 비용이 커지는 패턴을 먼저 잡는 편이 낫다.
| 비용 항목 | 커지는 원인 | 줄이는 방법 | 관측 지표 |
|---|---|---|---|
| 데이터 수집 | 중복 문서와 잦은 전체 동기화가 많다. | 변경분 동기화와 문서 정리 주기를 둔다. | 수집 작업 수와 실패 문서 수 |
| 임베딩 | 불필요한 원문과 오래된 첨부를 계속 벡터화한다. | 수집 전 문서 필터와 보존 정책을 둔다. | 문서 수와 청크 수 |
| 벡터 저장소 | 청크 수와 인덱스 설정이 과하게 커진다. | 도메인별 지식베이스와 보관 기간을 분리한다. | 저장소 용량과 쿼리 지연 |
| 생성 모델 | 긴 질의와 긴 검색 결과를 매번 답변에 넣는다. | 검색 개수와 프롬프트 길이를 제한한다. | 토큰 사용량과 응답 지연 |
| 재순위화 | 모든 질문에 고급 재순위화를 적용한다. | 품질 차이가 큰 도메인에만 켠다. | 정확도 개선폭과 호출량 |
비용을 줄이는 가장 빠른 방법은 모델을 싼 것으로 바꾸는 것보다 넣지 않아도 되는 문서를 수집하지 않는 것이다.
검색 품질 검증: 좋은 데모 질문만 믿지 않는다
RAG 데모는 보통 잘 아는 질문으로 성공하지만 운영 장애는 애매한 질문, 오래된 문서, 권한 경계에서 생긴다.
출시 전에는 도메인 담당자가 만든 golden question을 기준으로 검색 결과와 인용을 따로 평가해야 한다.
| 테스트 유형 | 질문 예시 | 합격 기준 | 불합격 신호 |
|---|---|---|---|
| 정답 질문 | 휴가 정책 최신 기준은 무엇인가. | 최신 문서와 정확한 인용이 나온다. | 폐기 문서가 먼저 나온다. |
| 권한 질문 | 임원 전용 보상 정책을 물어본다. | 권한 없는 사용자는 문서가 검색되지 않는다. | 문서 제목이나 일부 문구가 보인다. |
| 충돌 질문 | 서로 다른 버전의 절차를 비교해 달라고 한다. | 최신 승인본을 우선하고 차이를 설명한다. | 두 문서를 섞어 단정한다. |
| 부재 질문 | 존재하지 않는 제도를 물어본다. | 모른다고 답하고 관련 문서를 인용하지 않는다. | 비슷한 문서를 끌어와 답을 만든다. |
검색 품질 평가는 답변 문장보다 검색된 청크와 인용 URL을 먼저 보는 방식이 더 정확하다.
실무 시나리오 1: 사내 정책 Q&A 챗봇
인사, 복지, 보안 정책 Q&A는 검색량이 많지만 잘못 답하면 직원 안내 사고가 생긴다.
이 조건이면 최신 승인 문서만 넣고 인용이 없는 답변은 사용자에게 노출하지 않는 쪽이 안전하다.
- 데이터 소스는 승인된 정책 문서 폴더와 FAQ 문서로 제한한다.
- 폐기 문서는 별도 보관 위치로 옮기고 지식베이스 동기화 대상에서 뺀다.
- 민감 정책은 사용자 그룹별 권한 필터를 테스트한 뒤 연결한다.
- 답변 화면에는 문서명, 시행일, 확인일을 함께 보여준다.
- 정책 변경 주기가 빠르면 매일 밤 동기화와 실패 알림을 둔다.
정책 챗봇에서 중요한 것은 친절한 답변보다 직원이 실제로 따라도 되는 최신 근거다.
실무 시나리오 2: 고객지원 상담원 보조 검색
고객지원 보조 검색은 상담 속도를 줄일 수 있지만 고객별 원문과 개인정보가 섞이기 쉽다.
이 조건이면 실제 고객 로그를 바로 넣지 말고 승인된 매뉴얼, 제품 FAQ, 익명화된 사례부터 시작해야 한다.
- 상담 스크립트와 제품 매뉴얼은 문서 소유자를 지정한다.
- 고객 원문 티켓은 익명화와 법무 검토가 끝난 샘플만 쓴다.
- 답변에는 상담원이 확인해야 할 금지 표현과 에스컬레이션 조건을 넣는다.
- Guardrails는 생성 답변 보조로 쓰고 데이터 원문 정제 책임을 대신 맡기지 않는다.
- 품질 지표는 첫 응답 시간보다 오답으로 인한 재문의율을 같이 본다.
상담 보조 RAG는 상담원을 대체하는 기능이 아니라 상담원이 틀린 근거를 덜 보게 만드는 검색 품질 프로젝트다.
실무 시나리오 3: 개발 문서와 운영 런북 검색
개발 문서 검색은 README, ADR, 장애 회고, 운영 런북이 섞여 검색 품질이 빨리 흔들린다.
이 조건이면 저장소 전체를 수집하기보다 운영 승인 문서와 최근 런북부터 작은 지식베이스로 나누는 편이 낫다.
- 실험 브랜치 문서와 오래된 설계 초안은 기본 수집 대상에서 제외한다.
- 장애 회고는 날짜와 영향 범위를 메타데이터로 남긴다.
- 운영 명령은 복붙 실행이 아니라 전제 조건과 롤백 기준을 함께 보여준다.
- 권한이 필요한 런북은 팀별 접근 권한을 분리한다.
- 검색 실패 질문은 문서 작성 백로그로 넘겨 원문 품질을 고친다.
개발 문서 RAG에서 모델을 바꾸기 전에 문서의 생애주기와 소유자를 먼저 고정해야 한다.
운영 체크리스트: 출시 전 반드시 볼 항목
- 데이터 소스마다 소유자, 권한, 최신성, 삭제 책임자가 적혀 있다.
- 서비스 역할은 필요한 모델, 데이터 소스, 저장소, KMS 권한만 갖는다.
- 권한이 다른 사용자 세 계정으로 같은 질문을 테스트했다.
- 검색 결과에는 인용이 붙고 인용 문서가 실제 답변 근거와 맞다.
- 없는 질문에 그럴듯한 답을 만들지 않는지 확인했다.
- 비용 리포트는 모델 호출, 수집 작업, 저장소, 재순위화를 분리한다.
- 문서 삭제 요청이 들어왔을 때 데이터 소스와 인덱스를 갱신하는 절차가 있다.
- 장애 시 지식베이스 연결을 끊거나 이전 데이터 소스로 되돌리는 방법이 있다.
- 출시 후 실패 질문을 문서 개선 백로그로 보내는 담당자가 있다.
이 체크리스트를 통과하지 못하면 데모 품질이 좋아도 운영 서비스로 올리기에는 이르다.
정책 스켈레톤: 지식베이스 승인 기준을 문서화한다
아래 YAML은 실제 AWS 설정 파일이 아니라 보안팀, 플랫폼팀, 문서 소유자가 같은 기준을 보게 만드는 검토 스켈레톤이다.
# bedrock-knowledge-base-review.yaml
# 목적: Amazon Bedrock 지식베이스 구축 전 데이터, 권한, 비용, 검색 품질을 함께 승인한다.
owner: ai-platform-team
review_cycle: monthly
scope:
application: internal-support-assistant
environments:
- sandbox
- production
knowledge_base_mode:
preferred: managed_knowledge_base
customer_managed_allowed_when:
- existing_vector_store_required
- custom_indexing_pipeline_required
- strict_network_boundary_required
data_sources:
allowed:
- s3_policy_docs
- confluence_engineering_space
- sharepoint_support_library
blocked:
- customer_raw_exports
- secrets_or_credentials
- unresolved_legal_documents
permissions:
service_role_owner: cloud-security
least_privilege_required: true
kms_key_required_for_sensitive_sources: true
retrieval_quality:
golden_questions_minimum: 50
citation_required: true
hallucination_review_owner: domain-owner
cost_guardrail:
sync_schedule: nightly
stale_document_retention_days: 30
monthly_budget_review: true
release_gate:
required_checks:
- ingestion_job_success
- permission_filter_test
- citation_accuracy_test
- pii_redaction_review
- rollback_plan_ready핵심은 Bedrock 기능을 제한하는 것이 아니라 어떤 문서와 권한 조합이 운영에 들어갈 수 있는지 설명 가능하게 만드는 것이다.
수집 전 점검 스크립트: 원본 문서 품질을 먼저 본다
아래 Python 예시는 S3에 올리기 전 로컬 문서 묶음의 형식, 크기, 민감 단어 힌트를 점검하는 보조 스크립트다.
#!/usr/bin/env python3
# kb_source_precheck.py
# 목적: S3에 올릴 문서 묶음이 지식베이스 수집 전에 최소 요건을 넘는지 점검한다.
from pathlib import Path
ROOT = Path("./kb-source")
MAX_DOC_MB = 50
ALLOWED = {".pdf", ".txt", ".md", ".html", ".csv", ".docx", ".xlsx", ".pptx", ".jpeg", ".jpg", ".png"}
DENY_HINTS = ["secret", "credential", "password", "token", "customer_raw"]
errors = []
for path in ROOT.rglob("*"):
if not path.is_file():
continue
if path.suffix.lower() not in ALLOWED:
errors.append(f"unsupported format: {path}")
if path.stat().st_size > MAX_DOC_MB * 1024 * 1024:
errors.append(f"too large: {path}")
lowered = str(path).lower()
if any(word in lowered for word in DENY_HINTS):
errors.append(f"manual review required: {path}")
if errors:
print("PRECHECK_FAILED")
print("
".join(errors))
raise SystemExit(1)
print("PRECHECK_OK")공식 한도와 지원 형식은 변경될 수 있으므로 운영 전에는 AWS 문서를 기준으로 허용 목록과 크기 제한을 다시 확인해야 한다.
운영 런북: 문제는 동기화 뒤에 생긴다
지식베이스 운영에서 진짜 이슈는 첫 생성보다 문서 변경, 권한 변경, 비용 증가, 품질 저하를 지속적으로 잡는 일이다.
Amazon Bedrock 지식베이스 운영 런북
1. 신규 문서 투입 전 도메인 담당자가 출처와 공개 범위를 승인한다.
2. 수집 실패 문서는 원인별로 분류하고 검색 서비스에 바로 노출하지 않는다.
3. 매주 golden question으로 검색 결과, 인용, 답변 누락을 표본 점검한다.
4. 민감 문서가 잘못 들어간 경우 데이터 소스 연결을 끊고 벡터 인덱스 재생성을 검토한다.
5. 비용 급증 시 동기화 주기, 중복 문서, 청크 전략, 모델 호출량을 먼저 확인한다.
6. 답변 품질 사고는 모델 교체보다 원문 품질, 권한 필터, 검색 쿼리 재작성 순서로 본다.런북이 없으면 잘못 수집된 문서 하나를 찾기 위해 모델, 검색, 저장소, 원본 권한을 동시에 뒤지는 상황이 생긴다.
도입을 보류해야 하는 신호
- 문서 소유자가 없거나 오래된 문서를 누가 삭제할지 정해지지 않았다.
- 권한이 다른 사용자를 나눠 테스트할 계정과 시나리오가 없다.
- PII, 비밀값, 고객 원문을 수집 전 제거하는 절차가 없다.
- 검색 결과의 인용을 도메인 담당자가 검수하지 않는다.
- 월 비용을 모델 호출 하나로만 보고 수집과 저장소 비용을 빼먹었다.
- 운영 장애 때 지식베이스를 끊거나 이전 버전으로 되돌릴 방법이 없다.
- Guardrails가 검색된 참조 자체까지 정제해준다고 오해하고 있다.
이 신호가 두 개 이상이면 Amazon Bedrock 지식베이스 구축보다 데이터 정리와 권한 설계를 먼저 끝내는 편이 낫다.
최종 판단: 작은 지식베이스로 시작하고 운영 기준으로 키운다
Amazon Bedrock 지식베이스 구축의 안전한 출발점은 한 도메인, 한 데이터 소스, 한 사용자 그룹으로 작게 시작하는 방식이다.
관리형 지식베이스는 초기 운영 부담을 줄여주지만 문서 품질, 권한 검증, 비용 책임까지 대신 정해주지는 않는다.
고객관리형은 제어권이 크지만 저장소 운영과 장애 대응을 감당할 팀이 있을 때만 장점이 살아난다.
결론은 단순하다: 모델보다 문서, 문서보다 권한, 권한보다 운영 검증이 먼저다.
그 순서가 잡힌 팀만 사내 RAG를 데모가 아니라 업무 시스템으로 올릴 수 있다.
함께 보면 좋은 글
프롬프트 자동화 파이프라인 2026, 사내 AI 답변 품질·비용·보안 기준
사내 LLM 설계 2026, 자체 AI 도입 전 비용·보안·운영 기준
AI 에이전트 데이터 유출 2026, 사내 도입 전 권한·로그·차단 기준클라우드 비용 최적화 2026, 서버리스·컨테이너 비용 줄이는 운영 기준데이터 플랫폼 구축 2026, 스타트업이 먼저 볼 비용·운영·확장 기준자주 묻는 질문
Amazon Bedrock 지식베이스 구축은 관리형으로 시작하는 게 맞나요?
처음 구축하고 운영팀이 작다면 관리형을 먼저 검토하고, 기존 벡터 저장소나 네트워크 제약이 강할 때 고객관리형을 검토하는 편이 현실적이다.
S3 문서를 많이 넣으면 RAG 답변 품질이 좋아지나요?
문서가 많아도 오래된 문서와 중복 문서가 섞이면 검색 품질이 나빠지므로 최신 승인본과 소유자가 있는 문서부터 넣어야 한다.
Bedrock Guardrails를 쓰면 민감 문서 노출을 막을 수 있나요?
Guardrails는 입력과 생성 답변 안전장치로 봐야 하며, 검색된 참조 자체는 데이터 소스 분류와 권한 필터로 먼저 관리해야 한다.
비용은 어떤 항목부터 봐야 하나요?
모델 호출뿐 아니라 데이터 수집, 임베딩, 벡터 저장소, 재순위화, 로그 보관, 동기화 주기를 같이 봐야 월 비용을 설명할 수 있다.
출시 전 품질 검증은 어떻게 하나요?
도메인 담당자가 만든 golden question으로 검색 청크, 인용, 권한별 결과, 없는 질문 대응을 따로 채점하는 방식이 좋다.
고객지원 챗봇에 고객 티켓 원문을 바로 넣어도 되나요?
개인정보와 계약 정보가 섞일 수 있으므로 익명화, 법무 검토, 보존 정책을 거친 샘플이나 승인된 매뉴얼부터 쓰는 편이 안전하다.
출처와 확인일
- AWS News Blog — Introducing Amazon Bedrock Managed Knowledge Base (확인일: 2026-06-30)
- AWS Docs — Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases (확인일: 2026-06-30)
- AWS Docs — Prerequisites for your Amazon Bedrock knowledge base data (확인일: 2026-06-30)
- AWS Docs — Create a service role for Amazon Bedrock Knowledge Bases (확인일: 2026-06-30)
- AWS Docs — Query a knowledge base and generate responses based off the retrieved data (확인일: 2026-06-30)
- AWS Docs — Detect and filter harmful content by using Amazon Bedrock Guardrails (확인일: 2026-06-30)
- AWS — Amazon Bedrock Pricing (확인일: 2026-06-30)
이 글은 AWS 공식 문서와 공개 가격 페이지를 바탕으로 한 일반 정보이며 기능, 가격, 커넥터, 한도, 리전 지원은 변경될 수 있다.
실제 운영 적용 전에는 최신 AWS 문서, 조직 보안 정책, 법무 기준, 구매 조건, 데이터 보존 정책을 함께 확인해야 한다.
댓글
댓글 쓰기