AWS Knowledge Bases 완벽 가이드

AWS Bedrock Knowledge Bases를 활용하여 AI 모델에게 커스텀 지식을 제공하는 방법을 배웁니다. 벡터 스토어 설정부터 임베딩 모델 선택까지 실무에 바로 적용할 수 있는 내용을 담았습니다.

1. Knowledge Bases 소개

어느 날 김개발 씨는 회사의 내부 문서를 학습한 챗봇을 만들어 달라는 요청을 받았습니다. "AI 모델에게 우리 회사만의 지식을 어떻게 가르치지?" 고민하던 그에게 박시니어 씨가 AWS Knowledge Bases를 소개해 주었습니다.

Knowledge Bases는 AI 모델에게 커스텀 지식을 제공하는 AWS Bedrock의 핵심 기능입니다. 마치 도서관 사서가 필요한 책을 찾아주듯이, AI가 방대한 문서에서 관련 정보를 찾아 답변에 활용할 수 있게 해줍니다.

RAG(Retrieval-Augmented Generation) 패턴을 쉽게 구현할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# Knowledge Base 클라이언트 생성
bedrock_agent = boto3.client('bedrock-agent')

# Knowledge Base 목록 조회
response = bedrock_agent.list_knowledge_bases(
    maxResults=10
)

# 결과 출력
for kb in response['knowledgeBaseSummaries']:
    print(f"KB 이름: {kb['name']}")
    print(f"KB ID: {kb['knowledgeBaseId']}")
    print(f"상태: {kb['status']}")
    print("---")

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 고객 지원 챗봇 프로젝트를 맡게 되었습니다.

"우리 제품 매뉴얼과 FAQ를 학습한 챗봇을 만들어 주세요." 팀장님의 요청은 명확했지만, 김개발 씨는 막막했습니다. 일반적인 AI 모델은 공개된 인터넷 데이터로 학습되어 있습니다.

하지만 회사만의 특수한 정보나 최신 업데이트 내용은 알 수 없습니다. "어떻게 AI에게 우리 회사 지식을 가르칠 수 있을까?" 바로 이럴 때 AWS Knowledge Bases가 필요합니다.

Knowledge Bases란 무엇일까요? 쉽게 비유하자면, Knowledge Bases는 AI 모델 옆에 앉아서 참고 자료를 건네주는 비서와 같습니다. 사용자가 질문을 하면, 먼저 관련된 문서를 찾아서 AI에게 보여줍니다.

그러면 AI는 그 문서를 참고하여 더 정확하고 구체적인 답변을 생성합니다. 이런 방식을 **RAG(Retrieval-Augmented Generation)**라고 부릅니다.

Retrieval은 검색, Augmented는 강화, Generation은 생성을 의미합니다. 즉, 검색으로 강화된 생성이라는 뜻입니다.

왜 Knowledge Bases가 필요한가? Knowledge Bases가 없던 시절에는 어땠을까요? 개발자들은 AI 모델을 직접 파인튜닝하거나, 프롬프트에 모든 문서를 복사해서 붙여넣어야 했습니다.

하지만 파인튜닝은 비용이 많이 들고 시간도 오래 걸립니다. 프롬프트에 문서를 붙여넣는 방식은 토큰 제한 때문에 긴 문서를 다루기 어렵습니다.

더 큰 문제는 문서가 업데이트될 때마다 다시 학습하거나 프롬프트를 수정해야 한다는 점이었습니다. 실시간으로 변하는 정보를 AI에게 제공하기는 거의 불가능했습니다.

Knowledge Bases의 작동 원리 Knowledge Bases는 세 단계로 작동합니다. 첫 번째, 문서를 업로드하면 임베딩 모델이 문서를 벡터로 변환합니다.

벡터는 문서의 의미를 숫자로 표현한 것입니다. 마치 단어를 좌표평면의 점으로 나타내는 것과 같습니다.

두 번째, 이렇게 만들어진 벡터들을 벡터 스토어에 저장합니다. 벡터 스토어는 의미가 비슷한 문서를 빠르게 찾을 수 있는 특수한 데이터베이스입니다.

세 번째, 사용자가 질문하면 질문도 벡터로 변환하여 가장 관련성 높은 문서를 찾아냅니다. 그리고 그 문서를 AI 모델에게 컨텍스트로 제공합니다.

실무에서의 활용 박시니어 씨는 김개발 씨에게 실제 사례를 들려주었습니다. "저번에 법률 자문 서비스 프로젝트를 진행했는데, 수천 개의 판례 문서를 Knowledge Base에 등록했어요.

그랬더니 AI가 관련 판례를 찾아서 법률 질문에 답변하더라고요." 고객 지원, 사내 헬프데스크, 기술 문서 검색, 연구 자료 분석 등 다양한 분야에서 Knowledge Bases를 활용할 수 있습니다. 특히 정보가 자주 업데이트되는 환경에서 빛을 발합니다.

Knowledge Bases의 장점 무엇보다 관리가 쉽습니다. 문서를 S3 버킷에 업로드하기만 하면 자동으로 처리됩니다.

모델을 다시 학습시킬 필요가 없습니다. 또한 확장성이 뛰어납니다.

문서가 수십 개든 수만 개든 동일한 방식으로 처리할 수 있습니다. AWS가 인프라를 자동으로 확장해 줍니다.

마지막으로 정확도가 높습니다. AI가 답변과 함께 참고한 문서의 출처를 제공하므로, 사용자가 정보의 신뢰성을 확인할 수 있습니다.

주의할 점 하지만 Knowledge Bases가 만능은 아닙니다. 문서의 품질이 나쁘면 AI의 답변도 부정확해집니다.

"쓰레기를 넣으면 쓰레기가 나온다"는 원칙은 여기서도 적용됩니다. 또한 비용도 고려해야 합니다.

임베딩 모델 사용료, 벡터 스토어 비용, 그리고 AI 모델 호출 비용이 모두 발생합니다. 소규모 프로젝트에서는 단순한 검색 시스템이 더 효율적일 수 있습니다.

시작하기 김개발 씨는 박시니어 씨의 설명을 듣고 흥미를 느꼈습니다. "그럼 어떻게 시작하면 될까요?" "AWS 콘솔에서 몇 번의 클릭만으로 Knowledge Base를 만들 수 있어요.

문서를 S3에 업로드하고, 임베딩 모델을 선택하고, 벡터 스토어를 설정하면 끝이에요." 다음 섹션에서는 실제로 콘솔에서 Knowledge Base를 생성하는 과정을 살펴보겠습니다.

실전 팁

💡 - 문서는 명확하고 구조화된 형식(Markdown, PDF)으로 준비하세요

처음에는 작은 규모로 시작해서 테스트한 후 확장하세요
답변 품질을 높이려면 문서에 명확한 제목과 섹션을 추가하세요

2. 콘솔에서 KB 생성하기

김개발 씨는 AWS 콘솔에 로그인했습니다. "Bedrock Knowledge Bases 메뉴를 찾아야 하는데..." 화면을 살펴보던 그에게 박시니어 씨가 옆에서 단계별로 알려주기 시작했습니다.

AWS 콘솔에서 Knowledge Base를 생성하는 과정은 직관적입니다. 이름을 정하고, 데이터 소스를 연결하고, 모델을 선택하면 됩니다.

코드 없이도 몇 분 안에 완성할 수 있습니다.

다음 코드를 살펴봅시다.

# AWS CLI로 Knowledge Base 생성하기
aws bedrock-agent create-knowledge-base \
    --name "company-docs-kb" \
    --description "회사 내부 문서 Knowledge Base" \
    --role-arn "arn:aws:iam::123456789012:role/BedrockKBRole" \
    --knowledge-base-configuration '{
        "type": "VECTOR",
        "vectorKnowledgeBaseConfiguration": {
            "embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v1"
        }
    }' \
    --storage-configuration '{
        "type": "OPENSEARCH_SERVERLESS"
    }'

김개발 씨는 AWS Management Console 검색창에 "Bedrock"을 입력했습니다. 여러 메뉴 중에서 Amazon Bedrock을 클릭하고, 왼쪽 사이드바에서 Knowledge bases를 찾았습니다.

"여기 있네요!" 김개발 씨가 화면을 가리키자, 박시니어 씨가 고개를 끄덕였습니다. "이제 'Create knowledge base' 버튼을 클릭해 보세요." 1단계: Knowledge Base 세부 정보 입력 첫 화면에서는 기본 정보를 입력합니다.

Knowledge base name에는 프로젝트에서 식별하기 쉬운 이름을 넣습니다. 김개발 씨는 "customer-support-kb"라고 입력했습니다.

고객 지원용 Knowledge Base라는 의미입니다. Description은 선택 사항이지만, 나중에 여러 개의 Knowledge Base를 관리할 때 유용합니다.

"고객 지원 챗봇용 제품 매뉴얼 및 FAQ"라고 적어두면 좋습니다. Tags도 추가할 수 있습니다.

"Environment: Production", "Team: CustomerSuccess" 같은 태그를 달아두면 비용 추적과 권한 관리에 도움이 됩니다. 2단계: IAM 역할 설정 다음으로 IAM permissions을 설정해야 합니다.

Knowledge Base는 S3에서 문서를 읽고, 벡터 스토어에 데이터를 쓰고, 임베딩 모델을 호출해야 합니다. 이 모든 작업에는 권한이 필요합니다.

여기서 두 가지 옵션이 있습니다. Create and use a new service role을 선택하면 AWS가 자동으로 필요한 권한을 가진 역할을 만들어 줍니다.

처음 시작하는 경우에는 이 옵션이 편리합니다. 기존 역할을 사용하려면 Use an existing service role을 선택하고 역할의 ARN을 입력합니다.

회사의 보안 정책에 따라 미리 만들어진 역할을 사용해야 할 때 이 옵션을 씁니다. 김개발 씨는 "자동으로 만들어 주는 게 편하겠네요"라며 첫 번째 옵션을 선택했습니다.

3단계: 데이터 소스 설정 이제 가장 중요한 부분입니다. Data source를 연결해야 합니다.

Add data source 버튼을 클릭하면 새 화면이 나타납니다. 데이터 소스 이름을 입력하고, S3 URI를 지정합니다.

예를 들어 "s3://my-company-docs/manuals/" 같은 경로입니다. 박시니어 씨가 조언했습니다.

"문서는 미리 S3 버킷에 업로드해 두어야 해요. PDF, TXT, Markdown, HTML 등 다양한 형식을 지원합니다." Chunking strategy도 선택해야 합니다.

청킹은 긴 문서를 작은 조각으로 나누는 작업입니다. 기본값인 Default chunking을 선택하면 AWS가 적절한 크기로 자동 분할합니다.

고급 사용자는 Custom chunking으로 토큰 수를 직접 지정할 수 있습니다. 4단계: 동기화 스케줄 데이터 소스 설정에서 Sync schedule도 중요합니다.

S3의 문서가 업데이트되면 Knowledge Base도 동기화해야 합니다. On-demand를 선택하면 수동으로 동기화 버튼을 눌러야 합니다.

Scheduled를 선택하면 매일 또는 매주 자동으로 동기화됩니다. 김개발 씨는 "문서가 자주 바뀌지 않으니까 일단 On-demand로 하겠습니다"라고 결정했습니다.

5단계: 검토 및 생성 마지막으로 Review and create 화면에서 모든 설정을 확인합니다. 이름, IAM 역할, 데이터 소스, 임베딩 모델, 벡터 스토어 등 지금까지 설정한 내용이 표시됩니다.

문제가 없으면 Create knowledge base 버튼을 클릭합니다. 몇 분 후, Knowledge Base가 생성됩니다.

상태가 Creating에서 Active로 바뀌면 사용할 준비가 된 것입니다. 첫 번째 동기화 Knowledge Base가 만들어졌다고 바로 사용할 수 있는 건 아닙니다.

데이터 소스와 처음 동기화를 해야 합니다. Knowledge Base 상세 페이지에서 Data sources 탭을 클릭하고, 방금 추가한 데이터 소스를 선택합니다.

그리고 Sync 버튼을 누릅니다. 동기화가 진행되는 동안 AWS는 S3의 모든 문서를 읽어서 청킹하고, 임베딩 모델로 벡터를 생성하고, 벡터 스토어에 저장합니다.

문서 양에 따라 몇 분에서 몇 시간이 걸릴 수 있습니다. 테스트하기 동기화가 완료되면 즉시 테스트할 수 있습니다.

Knowledge Base 상세 페이지의 Test 탭으로 이동합니다. 여기서 간단한 질문을 입력하면 AI가 Knowledge Base를 참고하여 답변합니다.

"제품 보증 기간은 얼마인가요?"라고 물어보면, 관련 매뉴얼을 찾아서 답변해 줍니다. 김개발 씨는 테스트를 해보고 감탄했습니다.

"와, 정말 우리 문서에서 답을 찾아주네요!" CLI로 생성하기 콘솔 대신 AWS CLI를 사용할 수도 있습니다. 위의 코드 예제처럼 aws bedrock-agent create-knowledge-base 명령어로 같은 작업을 할 수 있습니다.

CLI는 자동화와 인프라 코드(IaC) 환경에서 유용합니다. Terraform이나 CloudFormation 템플릿에 포함시켜서 배포 파이프라인의 일부로 만들 수 있습니다.

실전 팁

💡 - 처음에는 콘솔로 만들어서 개념을 익히고, 나중에 CLI나 IaC로 자동화하세요

Knowledge Base 이름에는 용도를 명확히 표현하세요 (예: "hr-policies-kb", "product-docs-kb")
데이터 소스는 나중에 추가할 수 있으니 처음엔 하나만 연결해서 테스트하세요

3. 임베딩 모델 선택

"임베딩 모델은 뭐고, 왜 선택해야 하나요?" 김개발 씨가 설정 화면을 보며 물었습니다. 박시니어 씨는 "좋은 질문이에요.

임베딩 모델은 Knowledge Base의 두뇌라고 할 수 있죠"라고 답했습니다.

임베딩 모델은 텍스트를 벡터로 변환하는 AI 모델입니다. 문장의 의미를 숫자 배열로 표현하여, 비슷한 의미를 가진 문서를 찾을 수 있게 합니다.

AWS는 여러 임베딩 모델을 제공하며, 각각 성능과 비용이 다릅니다.

다음 코드를 살펴봅시다.

import boto3
import numpy as np

# Bedrock Runtime 클라이언트 생성
bedrock_runtime = boto3.client('bedrock-runtime')

# 텍스트를 임베딩으로 변환
text = "AWS Knowledge Bases는 RAG를 쉽게 구현합니다"

response = bedrock_runtime.invoke_model(
    modelId='amazon.titan-embed-text-v1',
    body='{"inputText": "' + text + '"}'
)

# 임베딩 벡터 파싱
import json
result = json.loads(response['body'].read())
embedding = result['embedding']

print(f"벡터 차원: {len(embedding)}")
print(f"첫 5개 값: {embedding[:5]}")

김개발 씨는 "임베딩"이라는 단어가 낯설었습니다. "벡터로 변환한다는 게 무슨 뜻이죠?" 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다.

"쉽게 설명할게요." 임베딩이란 무엇인가? 임베딩은 단어나 문장을 숫자의 배열로 표현하는 것입니다. 마치 지도에서 장소를 위도와 경도로 나타내는 것과 비슷합니다.

예를 들어 "강아지"라는 단어를 [0.8, 0.2, 0.5, ...]와 같은 숫자들로 표현합니다. 이 숫자들은 단어의 의미를 담고 있습니다.

비슷한 의미를 가진 단어는 비슷한 숫자 패턴을 가집니다. "강아지"와 "고양이"의 임베딩 벡터는 서로 가까울 것입니다.

둘 다 애완동물이기 때문입니다. 하지만 "강아지"와 "자동차"는 멀리 떨어져 있을 것입니다.

왜 임베딩이 필요한가? 컴퓨터는 텍스트를 직접 이해하지 못합니다. 숫자로 변환해야 계산할 수 있습니다.

전통적인 방식은 단순히 단어의 출현 빈도를 세는 것이었습니다. 하지만 이 방법은 문맥을 무시합니다.

"은행"이라는 단어가 금융기관을 뜻하는지, 강가를 뜻하는지 구분하지 못합니다. 임베딩 모델은 문맥을 고려합니다.

"돈을 찾으러 은행에 갔다"와 "강가 은행에서 낚시를 했다"에서 같은 "은행"이지만 다른 벡터를 생성합니다. AWS가 제공하는 임베딩 모델들 AWS Bedrock은 여러 임베딩 모델을 제공합니다.

첫 번째는 Amazon Titan Embeddings입니다. AWS가 직접 개발한 모델로, 다국어를 지원하고 성능이 우수합니다.

가장 많이 사용되는 선택지입니다. 두 번째는 Cohere Embed입니다.

Cohere 회사가 만든 모델로, 특히 영어에서 뛰어난 성능을 보입니다. 다양한 버전이 있어서 용도에 맞게 선택할 수 있습니다.

세 번째는 Custom embedding models입니다. 자체 임베딩 모델을 가져와서 사용할 수도 있습니다.

하지만 대부분의 경우 AWS 제공 모델로 충분합니다. 어떤 모델을 선택할까? 박시니어 씨가 조언했습니다.

"처음에는 Titan Embeddings v1을 추천해요. 무난하고 안정적이거든요." 모델을 선택할 때 고려할 점은 세 가지입니다.

언어 지원: 한국어 문서를 다룬다면 다국어를 잘 지원하는 모델이 필요합니다. Titan Embeddings는 한국어를 포함한 100개 이상의 언어를 지원합니다.

벡터 차원: 벡터의 크기를 의미합니다. 차원이 크면 더 정확하지만 저장 공간과 연산 비용이 증가합니다.

Titan Embeddings v1은 1536차원, v2는 설정 가능합니다. 비용: 모델마다 토큰당 가격이 다릅니다.

대량의 문서를 처리한다면 비용 차이가 커질 수 있습니다. 임베딩의 작동 과정 Knowledge Base가 문서를 처리할 때 무슨 일이 일어날까요?

먼저 문서를 청크(작은 조각)로 나눕니다. 각 청크는 보통 몇 백 단어 정도입니다.

그 다음 각 청크를 임베딩 모델에 입력합니다. 임베딩 모델은 청크를 읽고 벡터를 출력합니다.

이 벡터가 벡터 스토어에 저장됩니다. 나중에 사용자가 질문하면, 질문도 같은 임베딩 모델로 벡터로 변환합니다.

그리고 질문 벡터와 가장 가까운 문서 벡터를 찾습니다. 이것이 바로 "유사도 검색"입니다.

코사인 유사도, 유클리드 거리 등의 수학적 방법을 사용합니다. 실제 사용 예제 위의 코드를 살펴보겠습니다.

invoke_model을 호출하면 텍스트를 임베딩 벡터로 변환할 수 있습니다. 결과로 받은 embedding은 1536개의 실수로 이루어진 배열입니다.

이 숫자들이 문장의 의미를 표현합니다. 사람이 보기에는 무작위 숫자처럼 보이지만, AI 모델에게는 의미 있는 패턴입니다.

임베딩 품질의 중요성 김개발 씨가 물었습니다. "임베딩이 잘못되면 어떻게 되나요?" "좋은 질문이에요.

임베딩 품질이 낮으면 관련 없는 문서를 가져오게 됩니다." 박시니어 씨가 답했습니다. 예를 들어 사용자가 "환불 정책"을 물었는데, 임베딩이 엉망이면 "배송 정책" 문서를 가져올 수 있습니다.

그러면 AI가 엉뚱한 답변을 하게 됩니다. 따라서 검증된 고품질 임베딩 모델을 사용하는 것이 중요합니다.

AWS가 제공하는 모델들은 이미 수많은 데이터로 학습되어 성능이 검증되었습니다. 업데이트와 버전 관리 임베딩 모델도 계속 발전합니다.

AWS는 주기적으로 새로운 버전을 출시합니다. 하지만 주의할 점이 있습니다.

모델 버전이 바뀌면 같은 텍스트라도 다른 벡터가 생성됩니다. 따라서 모델을 업그레이드하려면 모든 문서를 다시 임베딩해야 합니다.

프로덕션 환경에서는 모델 버전을 명시적으로 지정하고, 업그레이드는 신중하게 계획해야 합니다.

실전 팁

💡 - 처음 시작할 때는 Amazon Titan Embeddings v1으로 시작하세요

한국어 문서가 많다면 다국어 지원을 확인하세요
임베딩 품질을 테스트하려면 샘플 질문으로 검색 결과를 확인하세요

4. 벡터 스토어 구성

"임베딩된 벡터들을 어디에 저장하나요?" 김개발 씨가 다음 단계를 궁금해하자, 박시니어 씨가 "벡터 스토어가 필요하죠. 일반 데이터베이스와는 좀 다릅니다"라고 설명하기 시작했습니다.

벡터 스토어는 고차원 벡터를 효율적으로 저장하고 검색하는 특수한 데이터베이스입니다. AWS는 OpenSearch Serverless, Amazon Aurora, Pinecone 등 여러 옵션을 지원합니다.

유사도 검색에 최적화되어 있어 빠르게 관련 문서를 찾을 수 있습니다.

다음 코드를 살펴봅시다.

# OpenSearch Serverless를 벡터 스토어로 사용하는 Knowledge Base 생성
import boto3

bedrock_agent = boto3.client('bedrock-agent')

response = bedrock_agent.create_knowledge_base(
    name='my-kb-with-opensearch',
    roleArn='arn:aws:iam::123456789012:role/BedrockKBRole',
    knowledgeBaseConfiguration={
        'type': 'VECTOR',
        'vectorKnowledgeBaseConfiguration': {
            'embeddingModelArn': 'arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v1'
        }
    },
    storageConfiguration={
        'type': 'OPENSEARCH_SERVERLESS',
        'opensearchServerlessConfiguration': {
            'collectionArn': 'arn:aws:aoss:us-east-1:123456789012:collection/my-kb-collection',
            'vectorIndexName': 'bedrock-knowledge-base-index',
            'fieldMapping': {
                'vectorField': 'embedding',
                'textField': 'text',
                'metadataField': 'metadata'
            }
        }
    }
)

print(f"Knowledge Base ID: {response['knowledgeBase']['knowledgeBaseId']}")

김개발 씨는 궁금해졌습니다. "MySQL이나 PostgreSQL 같은 일반 데이터베이스에 저장하면 안 되나요?" 박시니어 씨가 고개를 저었습니다.

"이론적으로는 가능하지만 비효율적이에요. 벡터 검색에는 특수한 인덱스와 알고리즘이 필요하거든요." 벡터 스토어란 무엇인가? 벡터 스토어는 고차원 벡터를 다루는 데 특화된 데이터베이스입니다.

마치 도서관의 색인 카드가 책을 빠르게 찾게 해주듯이, 벡터 스토어는 수백만 개의 벡터 중에서 비슷한 것을 순식간에 찾아냅니다. 일반 데이터베이스는 정확한 값을 찾는 데 최적화되어 있습니다.

"ID가 123인 사용자를 찾아라" 같은 쿼리는 매우 빠릅니다. 하지만 "이 벡터와 가장 비슷한 벡터 10개를 찾아라"는 느립니다.

벡터 스토어는 근사 최근접 이웃(ANN, Approximate Nearest Neighbor) 알고리즘을 사용합니다. 정확도를 약간 희생하는 대신 속도를 크게 높입니다.

수백만 개 벡터에서도 밀리초 안에 결과를 반환합니다. AWS가 지원하는 벡터 스토어들 Knowledge Bases는 여러 벡터 스토어를 지원합니다.

Amazon OpenSearch Serverless가 가장 인기 있는 선택입니다. 서버리스이므로 인프라 관리가 필요 없습니다.

자동으로 확장되고, 사용한 만큼만 비용을 지불합니다. AWS와의 통합이 매끄럽습니다.

Amazon Aurora with pgvector도 좋은 옵션입니다. PostgreSQL의 pgvector 확장을 사용하여 벡터를 저장합니다.

이미 Aurora를 사용 중이라면 추가 인프라 없이 시작할 수 있습니다. Pinecone은 벡터 데이터베이스 전문 서비스입니다.

매우 빠르고 확장성이 뛰어나지만, 별도의 계정과 비용이 필요합니다. AWS 외부 서비스입니다.

MongoDB Atlas도 지원합니다. 이미 MongoDB를 사용 중이라면 편리한 선택입니다.

어떤 벡터 스토어를 선택할까? 박시니어 씨가 추천했습니다. "새로 시작한다면 OpenSearch Serverless를 추천해요.

설정이 간단하고 AWS 생태계와 잘 어울립니다." 선택 기준은 다음과 같습니다. 규모: 작은 프로젝트(수천 개 문서)라면 Aurora로도 충분합니다.

대규모(수백만 개 문서)라면 OpenSearch나 Pinecone이 적합합니다. 기존 인프라: 이미 사용 중인 데이터베이스가 있다면 그것을 활용하는 게 효율적입니다.

Aurora를 쓰고 있다면 pgvector 확장을 추가하면 됩니다. 비용: OpenSearch Serverless는 인덱싱과 검색 시간에 따라 과금됩니다.

Aurora는 데이터베이스 인스턴스 비용입니다. Pinecone은 자체 요금제가 있습니다.

OpenSearch Serverless 설정하기 Knowledge Base를 만들 때 벡터 스토어를 지정합니다. OpenSearch Serverless를 선택하면 AWS가 자동으로 컬렉션을 생성할 수 있습니다.

Collection ARN은 OpenSearch Serverless 컬렉션의 고유 식별자입니다. 미리 만들어 둔 컬렉션을 지정하거나, Knowledge Base 생성 시 자동 생성을 선택할 수 있습니다.

Vector index name은 벡터가 저장될 인덱스 이름입니다. 기본값은 "bedrock-knowledge-base-index"입니다.

여러 Knowledge Base가 같은 컬렉션을 공유한다면 인덱스 이름으로 구분합니다. Field mapping은 중요합니다.

벡터 필드, 텍스트 필드, 메타데이터 필드를 각각 지정합니다. 이 매핑이 잘못되면 검색이 작동하지 않습니다.

벡터 인덱싱의 원리 문서가 동기화될 때 무슨 일이 일어날까요? 먼저 문서가 청크로 나뉘고 각 청크가 임베딩됩니다.

그러면 [0.1, 0.3, -0.2, ...] 같은 벡터가 생성됩니다. 이 벡터들이 벡터 스토어에 저장됩니다.

단순히 저장만 하는 게 아니라 인덱스를 만듭니다. 인덱스는 빠른 검색을 위한 특수한 자료구조입니다.

대표적인 인덱싱 알고리즘은 **HNSW(Hierarchical Navigable Small World)**입니다. 벡터들을 그래프 구조로 연결하여 검색 경로를 최적화합니다.

마치 고속도로 네트워크가 목적지까지 빠르게 도달하게 해주는 것과 같습니다. 검색 과정 사용자가 "제품 보증 기간은?"이라고 질문합니다.

이 질문이 임베딩되어 벡터가 됩니다. 벡터 스토어는 이 질문 벡터와 가장 가까운 문서 벡터들을 찾습니다.

Top-K 검색이라고 부르며, 보통 상위 3~5개를 반환합니다. 거리 계산에는 코사인 유사도나 유클리드 거리를 사용합니다.

코사인 유사도는 벡터의 방향을 비교하고, 유클리드 거리는 실제 거리를 계산합니다. 찾아낸 문서들이 AI 모델에게 전달되고, AI는 이를 참고하여 최종 답변을 생성합니다.

성능 최적화 벡터 스토어의 성능은 여러 요인에 영향을 받습니다. 벡터 차원이 클수록 정확하지만 느립니다.

1536차원보다 384차원이 훨씬 빠릅니다. 정확도와 속도 사이의 균형을 찾아야 합니다.

청크 크기도 중요합니다. 청크가 작으면 정확한 정보를 찾지만 검색 횟수가 많아집니다.

청크가 크면 검색은 빠르지만 불필요한 정보가 포함될 수 있습니다. 인덱스 파라미터를 조정할 수도 있습니다.

HNSW의 경우 ef_construction과 M 값을 튜닝하면 성능을 개선할 수 있습니다. 비용 관리 벡터 스토어는 비용이 발생합니다.

OpenSearch Serverless는 OCU(OpenSearch Compute Units)로 과금됩니다. 인덱싱과 검색 작업량에 따라 비용이 증가합니다.

불필요한 비용을 줄이려면 사용하지 않는 인덱스를 삭제하고, 동기화 빈도를 조절하세요. 개발 환경과 프로덕션 환경을 분리하는 것도 좋습니다.

백업과 복구 프로덕션 환경에서는 벡터 스토어도 백업해야 합니다. OpenSearch Serverless는 자동 스냅샷을 지원합니다.

만약 문제가 생기면 스냅샷에서 복구할 수 있습니다. 하지만 가장 안전한 방법은 S3의 원본 문서를 보존하는 것입니다.

언제든지 재동기화하면 벡터 스토어를 재구축할 수 있습니다.

실전 팁

💡 - 처음 시작할 때는 OpenSearch Serverless를 추천합니다

벡터 스토어는 별도로 백업하기보다 S3 원본을 잘 관리하세요
대용량 데이터라면 청크 크기와 Top-K 값을 조정하여 성능을 최적화하세요

5. IAM 역할 설정

김개발 씨가 Knowledge Base를 테스트하려는데 권한 오류가 발생했습니다. "Access Denied?" 당황한 그에게 박시니어 씨가 "아, IAM 역할 설정을 확인해야 해요"라고 말했습니다.

IAM 역할은 Knowledge Base가 AWS 리소스에 접근할 수 있도록 권한을 부여하는 메커니즘입니다. S3 읽기, 벡터 스토어 쓰기, 모델 호출 등 모든 작업에 적절한 권한이 필요합니다.

보안의 핵심이자 자주 실수하는 부분입니다.

다음 코드를 살펴봅시다.

# Knowledge Base를 위한 IAM 역할 정책 예시 (JSON)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-docs-bucket",
        "arn:aws:s3:::my-docs-bucket/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel"
      ],
      "Resource": "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1"
    },
    {
      "Effect": "Allow",
      "Action": [
        "aoss:APIAccessAll"
      ],
      "Resource": "arn:aws:aoss:us-east-1:123456789012:collection/*"
    }
  ]
}

김개발 씨는 오류 메시지를 자세히 읽었습니다. "User: arn:aws:sts::...:assumed-role/BedrockKBRole is not authorized to perform: s3:GetObject" "역할에 S3 읽기 권한이 없나봐요." 박시니어 씨가 IAM 콘솔을 열었습니다.

IAM 역할이란? IAM(Identity and Access Management)은 AWS의 권한 관리 시스템입니다. 역할은 특정 작업을 수행할 수 있는 권한의 집합입니다.

마치 회사의 출입증과 같습니다. 일반 사원증으로는 일반 사무실에만 들어갈 수 있지만, 관리자 카드는 서버실에도 접근할 수 있습니다.

IAM 역할도 이와 비슷하게 리소스 접근을 제어합니다. Knowledge Base는 여러 AWS 서비스를 사용합니다.

S3에서 문서를 읽고, Bedrock으로 임베딩을 생성하고, OpenSearch에 벡터를 저장합니다. 각 작업마다 권한이 필요합니다.

필수 권한들 Knowledge Base가 작동하려면 세 가지 핵심 권한이 필요합니다. 첫째, S3 읽기 권한입니다.

s3:GetObject는 파일을 읽는 권한이고, s3:ListBucket은 버킷의 파일 목록을 보는 권한입니다. 데이터 소스로 지정한 S3 버킷에 대해 이 권한이 있어야 합니다.

둘째, Bedrock 모델 호출 권한입니다. bedrock:InvokeModel을 통해 임베딩 모델을 사용할 수 있습니다.

리소스 ARN에 사용할 모델을 명시해야 합니다. 셋째, 벡터 스토어 접근 권한입니다.

OpenSearch Serverless라면 aoss:APIAccessAll, Aurora라면 데이터베이스 접근 권한, Pinecone이라면 API 키 관리 권한이 필요합니다. 역할 생성하기 IAM 콘솔에서 새 역할을 만들 수 있습니다.

Trusted entity로 "Bedrock"을 선택합니다. 이렇게 하면 Bedrock 서비스가 이 역할을 사용할 수 있습니다.

Trust relationship이라는 개념으로, "누가 이 역할을 맡을 수 있는가"를 정의합니다. 다음으로 Permissions policies를 연결합니다.

위의 JSON 코드처럼 필요한 권한을 정의한 정책을 만들어 연결합니다. 여러 개의 정책을 조합할 수도 있습니다.

역할 이름은 "BedrockKnowledgeBaseRole" 같이 명확하게 짓습니다. 나중에 어떤 용도인지 알 수 있어야 합니다.

최소 권한 원칙 보안의 기본 원칙은 **최소 권한(Least Privilege)**입니다. 꼭 필요한 권한만 부여해야 합니다.

예를 들어 S3 권한을 줄 때 s3:* 같은 와일드카드는 위험합니다. 모든 S3 작업을 허용하기 때문입니다.

대신 s3:GetObject와 s3:ListBucket만 명시적으로 허용합니다. 리소스 ARN도 구체적으로 지정합니다.

"Resource": "*"는 모든 리소스를 뜻하므로 피해야 합니다. "Resource": "arn:aws:s3:::my-docs-bucket/*"처럼 특정 버킷만 허용합니다.

자동 생성된 역할 검토하기 콘솔에서 Knowledge Base를 만들 때 "자동으로 역할 생성" 옵션을 선택했다면, AWS가 역할을 만들어 줍니다. 하지만 자동 생성된 역할도 검토해야 합니다.

IAM 콘솔에서 역할을 찾아 정책을 확인하세요. 때로는 너무 많은 권한을 부여하거나, 반대로 필요한 권한이 빠져있을 수 있습니다.

박시니어 씨가 조언했습니다. "프로덕션에 배포하기 전에 보안팀에 역할 정책을 리뷰 받는 게 좋아요." 일반적인 권한 오류들 김개발 씨가 겪은 것처럼 권한 문제는 자주 발생합니다.

Access Denied on S3: S3 버킷 정책이 역할의 접근을 막고 있을 수 있습니다. IAM 역할 정책뿐만 아니라 S3 버킷 정책도 확인해야 합니다.

Model invocation failed: Bedrock 모델 접근 권한이 없거나, 해당 리전에서 모델이 활성화되지 않았을 수 있습니다. Bedrock 콘솔에서 모델 액세스를 요청해야 합니다.

OpenSearch access denied: OpenSearch Serverless는 데이터 액세스 정책과 네트워크 정책을 별도로 관리합니다. IAM 역할에 권한이 있어도 OpenSearch 정책에서 허용해야 합니다.

Trust relationship 문제 역할을 만들었는데도 작동하지 않는다면 Trust relationship을 확인하세요. Trust policy는 "누가 이 역할을 맡을 수 있는가"를 정의합니다.

Bedrock 서비스가 역할을 assume할 수 있도록 다음과 같은 정책이 필요합니다. json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole" }] } 이 정책이 없으면 Knowledge Base가 역할을 사용할 수 없습니다.

교차 계정 시나리오 복잡한 조직에서는 S3 버킷과 Knowledge Base가 다른 AWS 계정에 있을 수 있습니다. 이 경우 양쪽 계정 모두에서 권한을 설정해야 합니다.

Knowledge Base 계정의 역할이 S3를 읽을 권한을 가지고, S3 계정의 버킷 정책이 그 역할의 접근을 허용해야 합니다. 교차 계정 설정은 복잡하므로 AWS 문서를 참고하거나 보안팀과 협력하세요.

권한 테스트 역할 설정이 끝나면 테스트해야 합니다. AWS CLI의 aws sts assume-role 명령어로 역할을 테스트할 수 있습니다.

또는 Knowledge Base 동기화를 실행하여 실제로 작동하는지 확인합니다. CloudTrail 로그를 보면 어떤 권한이 거부되었는지 자세히 알 수 있습니다.

오류가 발생하면 CloudTrail에서 AccessDenied 이벤트를 찾아보세요. 역할 업데이트 나중에 데이터 소스를 추가하거나 모델을 변경하면 역할도 업데이트해야 합니다.

새로운 S3 버킷을 추가한다면 해당 버킷 ARN을 역할 정책에 추가합니다. 다른 임베딩 모델을 사용한다면 그 모델의 ARN도 허용해야 합니다.

역할 정책을 변경할 때는 프로덕션 환경에 바로 적용하지 말고, 개발 환경에서 먼저 테스트하세요.

실전 팁

💡 - 자동 생성된 역할도 반드시 검토하여 불필요한 권한을 제거하세요

CloudTrail 로그를 활용하면 권한 문제를 빠르게 디버깅할 수 있습니다
프로덕션 배포 전에 보안팀의 리뷰를 받으세요

6. KB 설정 옵션

Knowledge Base가 작동하기 시작했습니다. 하지만 김개발 씨는 "답변이 너무 길어요" "가끔 엉뚱한 답을 해요" 같은 피드백을 받았습니다.

박시니어 씨가 "설정 옵션들을 조정해 보죠"라고 제안했습니다.

Knowledge Base는 다양한 설정 옵션을 제공하여 검색 정확도, 응답 품질, 성능을 튜닝할 수 있습니다. 청킹 전략, 검색 파라미터, 메타데이터 필터링 등을 조정하여 최적의 결과를 얻을 수 있습니다.

다음 코드를 살펴봅시다.

# Knowledge Base 검색 파라미터 설정
import boto3

bedrock_runtime = boto3.client('bedrock-agent-runtime')

# Knowledge Base에서 검색하고 답변 생성
response = bedrock_runtime.retrieve_and_generate(
    input={
        'text': '제품 보증 기간은 얼마인가요?'
    },
    retrieveAndGenerateConfiguration={
        'type': 'KNOWLEDGE_BASE',
        'knowledgeBaseConfiguration': {
            'knowledgeBaseId': 'YOUR_KB_ID',
            'modelArn': 'arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2',
            'retrievalConfiguration': {
                'vectorSearchConfiguration': {
                    'numberOfResults': 5,  # Top-K 값
                    'overrideSearchType': 'HYBRID'  # 하이브리드 검색
                }
            }
        }
    }
)

print(response['output']['text'])

김개발 씨는 테스트 결과를 분석했습니다. 어떤 질문은 완벽하게 답변하지만, 어떤 질문은 관련 없는 내용을 말합니다.

"뭔가 조정할 수 있는 게 있을까요?" 박시니어 씨가 설정 화면을 열었습니다. "Knowledge Base에는 생각보다 많은 튜닝 옵션이 있어요." 청킹 전략 선택 문서를 어떻게 나눌 것인가는 매우 중요한 결정입니다.

Default chunking은 AWS가 자동으로 적절한 크기로 나눕니다. 대부분의 경우 이것으로 충분합니다.

특별한 이유가 없다면 기본값을 사용하세요. Fixed-size chunking은 고정된 토큰 수로 나눕니다.

예를 들어 300토큰씩 나누고, 50토큰 오버랩을 둡니다. 오버랩은 청크 경계에서 문맥이 끊기는 것을 방지합니다.

Hierarchical chunking은 문서 구조(제목, 섹션)를 고려하여 나눕니다. 기술 문서나 매뉴얼처럼 체계적으로 구성된 콘텐츠에 적합합니다.

Semantic chunking은 의미적으로 연관된 내용끼리 묶습니다. 가장 정교하지만 처리 시간이 더 걸립니다.

청크 크기의 영향 청크가 너무 작으면 문맥이 부족합니다. "제품 보증 기간은 1년입니다"만 있고 어떤 제품인지 없다면 혼란스럽습니다.

청크가 너무 크면 불필요한 정보가 많이 포함됩니다. AI 모델의 컨텍스트 윈도우를 낭비하고, 핵심 정보가 희석됩니다.

일반적으로 300~500 토큰이 적절합니다. 하지만 문서 특성에 따라 다릅니다.

짧은 FAQ는 100토큰, 긴 기술 문서는 1000토큰일 수 있습니다. 검색 파라미터 조정 numberOfResults는 Top-K 값입니다.

몇 개의 관련 문서를 가져올지 결정합니다. 기본값은 보통 3~5입니다.

너무 적으면 필요한 정보를 놓칠 수 있고, 너무 많으면 노이즈가 섞입니다. 실험을 통해 최적값을 찾아야 합니다.

김개발 씨는 5로 설정하고 테스트했습니다. "이제 더 다양한 정보를 참고하네요." 검색 타입 선택 overrideSearchType은 검색 방식을 지정합니다.

SEMANTIC 검색은 순수하게 벡터 유사도로만 검색합니다. 의미적으로 비슷한 문서를 찾는 데 강력합니다.

HYBRID 검색은 벡터 검색과 키워드 검색을 결합합니다. 특정 용어가 정확히 매칭되어야 하는 경우에 유리합니다.

예를 들어 제품 모델명이나 고유명사 검색에 효과적입니다. 박시니어 씨가 추천했습니다.

"일반적으로는 HYBRID가 더 안정적이에요. 두 방식의 장점을 모두 활용하니까요." 메타데이터 필터링 문서에 메타데이터를 추가하면 검색을 더 정교하게 할 수 있습니다.

예를 들어 각 문서에 {"category": "warranty", "product": "laptop"} 같은 메타데이터를 붙입니다. 그러면 검색할 때 특정 카테고리나 제품만 대상으로 할 수 있습니다.

이것은 멀티 테넌트 환경에서 특히 유용합니다. 고객별로 다른 문서를 보여주고 싶다면 메타데이터로 필터링하면 됩니다.

생성 모델 선택 검색 후 답변을 생성하는 모델도 선택할 수 있습니다. modelArn에 사용할 파운데이션 모델을 지정합니다.

Claude, Titan, Llama 등 다양한 선택지가 있습니다. 모델마다 특성이 다릅니다.

Claude는 긴 컨텍스트를 잘 처리하고 안전한 답변을 생성합니다. Titan은 빠르고 비용 효율적입니다.

용도에 맞게 선택하세요. 프롬프트 템플릿 커스터마이징 기본 프롬프트가 마음에 들지 않는다면 커스텀 프롬프트를 사용할 수 있습니다.

예를 들어 "다음 문서를 참고하여 답변하되, 반드시 출처를 명시하세요" 같은 지시를 추가할 수 있습니다. 또는 답변 형식을 지정할 수도 있습니다.

하지만 프롬프트 엔지니어링은 섬세한 작업입니다. 잘못하면 오히려 품질이 떨어질 수 있으니 신중하게 테스트하세요.

응답 스트리밍 긴 답변을 생성할 때는 스트리밍이 유용합니다. 사용자가 전체 답변을 기다리지 않고 부분적으로 먼저 볼 수 있습니다.

Bedrock Runtime API는 스트리밍을 지원합니다. 웹 애플리케이션에서 실시간으로 답변이 나타나는 효과를 줄 수 있습니다.

캐싱 활용 같은 질문이 반복되는 경우가 많다면 캐싱을 고려하세요. Lambda나 API Gateway 레벨에서 자주 묻는 질문의 답변을 캐싱하면 비용과 응답 시간을 줄일 수 있습니다.

단, 문서가 업데이트되면 캐시를 무효화해야 합니다. A/B 테스팅 어떤 설정이 최적인지 확신이 없다면 A/B 테스트를 하세요.

같은 질문 세트로 여러 설정을 테스트하고, 답변 품질을 비교합니다. 정량적 지표(정확도, 응답 시간)와 정성적 평가(사용자 만족도)를 모두 고려해야 합니다.

모니터링과 로깅 프로덕션에서는 Knowledge Base 사용 패턴을 모니터링해야 합니다. CloudWatch 메트릭으로 검색 횟수, 응답 시간, 오류율을 추적합니다.

이상 징후가 보이면 즉시 대응할 수 있습니다. 사용자 질문과 답변을 로깅하면 품질 개선에 도움이 됩니다.

어떤 질문에 답변을 잘하지 못하는지 분석하여 문서를 보완하거나 설정을 조정할 수 있습니다. 반복적 개선 김개발 씨는 여러 설정을 시도해 보았습니다.

Top-K를 3에서 5로 늘리고, HYBRID 검색을 활성화했습니다. 청크 크기도 400토큰으로 조정했습니다.

며칠 후 사용자 피드백을 확인하니 답변 품질이 눈에 띄게 좋아졌습니다. "처음엔 완벽하지 않아도 괜찮아요.

계속 튜닝하면서 개선하면 됩니다." 박시니어 씨의 조언이었습니다. Knowledge Base 최적화는 일회성 작업이 아닙니다.

사용 패턴을 모니터링하고, 사용자 피드백을 수집하고, 설정을 조정하는 반복적인 과정입니다. 비용 최적화 설정을 조정할 때 비용도 고려해야 합니다.

Top-K를 늘리면 검색 비용이 증가합니다. 큰 청크를 사용하면 모델의 입력 토큰이 많아져 생성 비용이 올라갑니다.

동기화를 자주 하면 임베딩 비용이 증가합니다. 성능과 비용 사이의 균형을 찾아야 합니다.

프로덕션 전에 예상 비용을 계산해 보세요.

실전 팁

💡 - 처음에는 기본 설정으로 시작하고, 실제 사용 데이터를 보면서 조정하세요

HYBRID 검색이 대부분의 경우 더 안정적인 결과를 제공합니다
청크 크기는 300~500 토큰이 일반적으로 적절합니다
사용자 피드백을 적극 수집하여 지속적으로 개선하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#AWS#Bedrock#KnowledgeBases#VectorStore#RAG

AWS Knowledge Bases 완벽 가이드

# AWS Knowledge Bases 완벽 가이드 AWS Bedrock Knowledge Bases를 활용하여 AI 모델에게 커스텀 지식을 제공하는 방법을 배웁니다. 벡터 스토어 설정부터 임베딩 모델 선택까지 실무에 바로 적용할 수 있는 내용을 담았습니다. --- ## 목차 1. [Knowledge_Bases_소개](#knowledge-bases-소개) 2. [콘솔에서_KB_생성하기](#콘솔에서-kb-생성하기) 3. [임베딩_모델_선택](#임베딩-모델-선택) 4. [벡터_스토어_구성](#벡터-스토어-구성) 5. [IAM_역할_설정](#iam-역할-설정) 6. [KB_설정_옵션](#kb-설정-옵션) --- ## 1. Knowledge_Bases_소개 어느 날 김개발 씨는 회사의 내부 문서를 학습한 챗봇을 만들어 달라는 요청을 받았습니다. "AI 모델에게 우리 회사만의 지식을 어떻게 가르치지?" 고민하던 그에게 박시니어 씨가 AWS Knowledge Bases를 소개해 주었습니다. **Knowledge Bases**는 AI 모델에게 커스텀 지식을 제공하는 AWS Bedrock의 핵심 기능입니다. 마치 도서관 사서가 필요한 책을 찾아주듯이, AI가 방대한 문서에서 관련 정보를 찾아 답변에 활용할 수 있게 해줍니다. **RAG(Retrieval-Augmented Generation)** 패턴을 쉽게 구현할 수 있습니다. 다음 코드를 살펴봅시다. ```python import boto3 # Knowledge Base 클라이언트 생성 bedrock_agent = boto3.client('bedrock-agent') # Knowledge Base 목록 조회 response = bedrock_agent.list_knowledge_bases( maxResults=10 ) # 결과 출력 for kb in response['knowledgeBaseSummaries']: print(f"KB 이름: {kb['name']}") print(f"KB ID: {kb['knowledgeBaseId']}") print(f"상태: {kb['status']}") print("---") ``` 김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 고객 지원 챗봇 프로젝트를 맡게 되었습니다. "우리 제품 매뉴얼과 FAQ를 학습한 챗봇을 만들어 주세요." 팀장님의 요청은 명확했지만, 김개발 씨는 막막했습니다. 일반적인 AI 모델은 공개된 인터넷 데이터로 학습되어 있습니다. 하지만 회사만의 특수한 정보나 최신 업데이트 내용은 알 수 없습니다. "어떻게 AI에게 우리 회사 지식을 가르칠 수 있을까?" 바로 이럴 때 **AWS Knowledge Bases**가 필요합니다. **Knowledge Bases란 무엇일까요?** 쉽게 비유하자면, Knowledge Bases는 AI 모델 옆에 앉아서 참고 자료를 건네주는 비서와 같습니다. 사용자가 질문을 하면, 먼저 관련된 문서를 찾아서 AI에게 보여줍니다. 그러면 AI는 그 문서를 참고하여 더 정확하고 구체적인 답변을 생성합니다. 이런 방식을 **RAG(Retrieval-Augmented Generation)**라고 부릅니다. Retrieval은 검색, Augmented는 강화, Generation은 생성을 의미합니다. 즉, 검색으로 강화된 생성이라는 뜻입니다. **왜 Knowledge Bases가 필요한가?** Knowledge Bases가 없던 시절에는 어땠을까요? 개발자들은 AI 모델을 직접 파인튜닝하거나, 프롬프트에 모든 문서를 복사해서 붙여넣어야 했습니다. 하지만 파인튜닝은 비용이 많이 들고 시간도 오래 걸립니다. 프롬프트에 문서를 붙여넣는 방식은 토큰 제한 때문에 긴 문서를 다루기 어렵습니다. 더 큰 문제는 문서가 업데이트될 때마다 다시 학습하거나 프롬프트를 수정해야 한다는 점이었습니다. 실시간으로 변하는 정보를 AI에게 제공하기는 거의 불가능했습니다. **Knowledge Bases의 작동 원리** Knowledge Bases는 세 단계로 작동합니다. 첫 번째, 문서를 업로드하면 **임베딩 모델**이 문서를 벡터로 변환합니다. 벡터는 문서의 의미를 숫자로 표현한 것입니다. 마치 단어를 좌표평면의 점으로 나타내는 것과 같습니다. 두 번째, 이렇게 만들어진 벡터들을 **벡터 스토어**에 저장합니다. 벡터 스토어는 의미가 비슷한 문서를 빠르게 찾을 수 있는 특수한 데이터베이스입니다. 세 번째, 사용자가 질문하면 질문도 벡터로 변환하여 가장 관련성 높은 문서를 찾아냅니다. 그리고 그 문서를 AI 모델에게 컨텍스트로 제공합니다. **실무에서의 활용** 박시니어 씨는 김개발 씨에게 실제 사례를 들려주었습니다. "저번에 법률 자문 서비스 프로젝트를 진행했는데, 수천 개의 판례 문서를 Knowledge Base에 등록했어요. 그랬더니 AI가 관련 판례를 찾아서 법률 질문에 답변하더라고요." 고객 지원, 사내 헬프데스크, 기술 문서 검색, 연구 자료 분석 등 다양한 분야에서 Knowledge Bases를 활용할 수 있습니다. 특히 정보가 자주 업데이트되는 환경에서 빛을 발합니다. **Knowledge Bases의 장점** 무엇보다 **관리가 쉽습니다**. 문서를 S3 버킷에 업로드하기만 하면 자동으로 처리됩니다. 모델을 다시 학습시킬 필요가 없습니다. 또한 **확장성이 뛰어납니다**. 문서가 수십 개든 수만 개든 동일한 방식으로 처리할 수 있습니다. AWS가 인프라를 자동으로 확장해 줍니다. 마지막으로 **정확도가 높습니다**. AI가 답변과 함께 참고한 문서의 출처를 제공하므로, 사용자가 정보의 신뢰성을 확인할 수 있습니다. **주의할 점** 하지만 Knowledge Bases가 만능은 아닙니다. 문서의 품질이 나쁘면 AI의 답변도 부정확해집니다. "쓰레기를 넣으면 쓰레기가 나온다"는 원칙은 여기서도 적용됩니다. 또한 비용도 고려해야 합니다. 임베딩 모델 사용료, 벡터 스토어 비용, 그리고 AI 모델 호출 비용이 모두 발생합니다. 소규모 프로젝트에서는 단순한 검색 시스템이 더 효율적일 수 있습니다. **시작하기** 김개발 씨는 박시니어 씨의 설명을 듣고 흥미를 느꼈습니다. "그럼 어떻게 시작하면 될까요?" "AWS 콘솔에서 몇 번의 클릭만으로 Knowledge Base를 만들 수 있어요. 문서를 S3에 업로드하고, 임베딩 모델을 선택하고, 벡터 스토어를 설정하면 끝이에요." 다음 섹션에서는 실제로 콘솔에서 Knowledge Base를 생성하는 과정을 살펴보겠습니다. **실전 팁** 💡 - 문서는 명확하고 구조화된 형식(Markdown, PDF)으로 준비하세요 - 처음에는 작은 규모로 시작해서 테스트한 후 확장하세요 - 답변 품질을 높이려면 문서에 명확한 제목과 섹션을 추가하세요 --- ## 2. 콘솔에서_KB_생성하기 김개발 씨는 AWS 콘솔에 로그인했습니다. "Bedrock Knowledge Bases 메뉴를 찾아야 하는데..." 화면을 살펴보던 그에게 박시니어 씨가 옆에서 단계별로 알려주기 시작했습니다. **AWS 콘솔**에서 Knowledge Base를 생성하는 과정은 직관적입니다. 이름을 정하고, 데이터 소스를 연결하고, 모델을 선택하면 됩니다. 코드 없이도 몇 분 안에 완성할 수 있습니다. 다음 코드를 살펴봅시다. ```python # AWS CLI로 Knowledge Base 생성하기 aws bedrock-agent create-knowledge-base \ --name "company-docs-kb" \ --description "회사 내부 문서 Knowledge Base" \ --role-arn "arn:aws:iam::123456789012:role/BedrockKBRole" \ --knowledge-base-configuration '{ "type": "VECTOR", "vectorKnowledgeBaseConfiguration": { "embeddingModelArn": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v1" } }' \ --storage-configuration '{ "type": "OPENSEARCH_SERVERLESS" }' ``` 김개발 씨는 AWS Management Console 검색창에 "Bedrock"을 입력했습니다. 여러 메뉴 중에서 **Amazon Bedrock**을 클릭하고, 왼쪽 사이드바에서 **Knowledge bases**를 찾았습니다. "여기 있네요!" 김개발 씨가 화면을 가리키자, 박시니어 씨가 고개를 끄덕였습니다. "이제 'Create knowledge base' 버튼을 클릭해 보세요." **1단계: Knowledge Base 세부 정보 입력** 첫 화면에서는 기본 정보를 입력합니다. **Knowledge base name**에는 프로젝트에서 식별하기 쉬운 이름을 넣습니다. 김개발 씨는 "customer-support-kb"라고 입력했습니다. 고객 지원용 Knowledge Base라는 의미입니다. **Description**은 선택 사항이지만, 나중에 여러 개의 Knowledge Base를 관리할 때 유용합니다. "고객 지원 챗봇용 제품 매뉴얼 및 FAQ"라고 적어두면 좋습니다. **Tags**도 추가할 수 있습니다. "Environment: Production", "Team: CustomerSuccess" 같은 태그를 달아두면 비용 추적과 권한 관리에 도움이 됩니다. **2단계: IAM 역할 설정** 다음으로 **IAM permissions**을 설정해야 합니다. Knowledge Base는 S3에서 문서를 읽고, 벡터 스토어에 데이터를 쓰고, 임베딩 모델을 호출해야 합니다. 이 모든 작업에는 권한이 필요합니다. 여기서 두 가지 옵션이 있습니다. **Create and use a new service role**을 선택하면 AWS가 자동으로 필요한 권한을 가진 역할을 만들어 줍니다. 처음 시작하는 경우에는 이 옵션이 편리합니다. 기존 역할을 사용하려면 **Use an existing service role**을 선택하고 역할의 ARN을 입력합니다. 회사의 보안 정책에 따라 미리 만들어진 역할을 사용해야 할 때 이 옵션을 씁니다. 김개발 씨는 "자동으로 만들어 주는 게 편하겠네요"라며 첫 번째 옵션을 선택했습니다. **3단계: 데이터 소스 설정** 이제 가장 중요한 부분입니다. **Data source**를 연결해야 합니다. **Add data source** 버튼을 클릭하면 새 화면이 나타납니다. 데이터 소스 이름을 입력하고, **S3 URI**를 지정합니다. 예를 들어 "s3://my-company-docs/manuals/" 같은 경로입니다. 박시니어 씨가 조언했습니다. "문서는 미리 S3 버킷에 업로드해 두어야 해요. PDF, TXT, Markdown, HTML 등 다양한 형식을 지원합니다." **Chunking strategy**도 선택해야 합니다. 청킹은 긴 문서를 작은 조각으로 나누는 작업입니다. 기본값인 **Default chunking**을 선택하면 AWS가 적절한 크기로 자동 분할합니다. 고급 사용자는 **Custom chunking**으로 토큰 수를 직접 지정할 수 있습니다. **4단계: 동기화 스케줄** 데이터 소스 설정에서 **Sync schedule**도 중요합니다. S3의 문서가 업데이트되면 Knowledge Base도 동기화해야 합니다. **On-demand**를 선택하면 수동으로 동기화 버튼을 눌러야 합니다. **Scheduled**를 선택하면 매일 또는 매주 자동으로 동기화됩니다. 김개발 씨는 "문서가 자주 바뀌지 않으니까 일단 On-demand로 하겠습니다"라고 결정했습니다. **5단계: 검토 및 생성** 마지막으로 **Review and create** 화면에서 모든 설정을 확인합니다. 이름, IAM 역할, 데이터 소스, 임베딩 모델, 벡터 스토어 등 지금까지 설정한 내용이 표시됩니다. 문제가 없으면 **Create knowledge base** 버튼을 클릭합니다. 몇 분 후, Knowledge Base가 생성됩니다. 상태가 **Creating**에서 **Active**로 바뀌면 사용할 준비가 된 것입니다. **첫 번째 동기화** Knowledge Base가 만들어졌다고 바로 사용할 수 있는 건 아닙니다. 데이터 소스와 처음 동기화를 해야 합니다. Knowledge Base 상세 페이지에서 **Data sources** 탭을 클릭하고, 방금 추가한 데이터 소스를 선택합니다. 그리고 **Sync** 버튼을 누릅니다. 동기화가 진행되는 동안 AWS는 S3의 모든 문서를 읽어서 청킹하고, 임베딩 모델로 벡터를 생성하고, 벡터 스토어에 저장합니다. 문서 양에 따라 몇 분에서 몇 시간이 걸릴 수 있습니다. **테스트하기** 동기화가 완료되면 즉시 테스트할 수 있습니다. Knowledge Base 상세 페이지의 **Test** 탭으로 이동합니다. 여기서 간단한 질문을 입력하면 AI가 Knowledge Base를 참고하여 답변합니다. "제품 보증 기간은 얼마인가요?"라고 물어보면, 관련 매뉴얼을 찾아서 답변해 줍니다. 김개발 씨는 테스트를 해보고 감탄했습니다. "와, 정말 우리 문서에서 답을 찾아주네요!" **CLI로 생성하기** 콘솔 대신 AWS CLI를 사용할 수도 있습니다. 위의 코드 예제처럼 `aws bedrock-agent create-knowledge-base` 명령어로 같은 작업을 할 수 있습니다. CLI는 자동화와 인프라 코드(IaC) 환경에서 유용합니다. Terraform이나 CloudFormation 템플릿에 포함시켜서 배포 파이프라인의 일부로 만들 수 있습니다. **실전 팁** 💡 - 처음에는 콘솔로 만들어서 개념을 익히고, 나중에 CLI나 IaC로 자동화하세요 - Knowledge Base 이름에는 용도를 명확히 표현하세요 (예: "hr-policies-kb", "product-docs-kb") - 데이터 소스는 나중에 추가할 수 있으니 처음엔 하나만 연결해서 테스트하세요 --- ## 3. 임베딩_모델_선택 "임베딩 모델은 뭐고, 왜 선택해야 하나요?" 김개발 씨가 설정 화면을 보며 물었습니다. 박시니어 씨는 "좋은 질문이에요. 임베딩 모델은 Knowledge Base의 두뇌라고 할 수 있죠"라고 답했습니다. **임베딩 모델**은 텍스트를 벡터로 변환하는 AI 모델입니다. 문장의 의미를 숫자 배열로 표현하여, 비슷한 의미를 가진 문서를 찾을 수 있게 합니다. AWS는 여러 임베딩 모델을 제공하며, 각각 성능과 비용이 다릅니다. 다음 코드를 살펴봅시다. ```python import boto3 import numpy as np # Bedrock Runtime 클라이언트 생성 bedrock_runtime = boto3.client('bedrock-runtime') # 텍스트를 임베딩으로 변환 text = "AWS Knowledge Bases는 RAG를 쉽게 구현합니다" response = bedrock_runtime.invoke_model( modelId='amazon.titan-embed-text-v1', body='{"inputText": "' + text + '"}' ) # 임베딩 벡터 파싱 import json result = json.loads(response['body'].read()) embedding = result['embedding'] print(f"벡터 차원: {len(embedding)}") print(f"첫 5개 값: {embedding[:5]}") ``` 김개발 씨는 "임베딩"이라는 단어가 낯설었습니다. "벡터로 변환한다는 게 무슨 뜻이죠?" 박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "쉽게 설명할게요." **임베딩이란 무엇인가?** 임베딩은 단어나 문장을 숫자의 배열로 표현하는 것입니다. 마치 지도에서 장소를 위도와 경도로 나타내는 것과 비슷합니다. 예를 들어 "강아지"라는 단어를 [0.8, 0.2, 0.5, ...]와 같은 숫자들로 표현합니다. 이 숫자들은 단어의 의미를 담고 있습니다. 비슷한 의미를 가진 단어는 비슷한 숫자 패턴을 가집니다. "강아지"와 "고양이"의 임베딩 벡터는 서로 가까울 것입니다. 둘 다 애완동물이기 때문입니다. 하지만 "강아지"와 "자동차"는 멀리 떨어져 있을 것입니다. **왜 임베딩이 필요한가?** 컴퓨터는 텍스트를 직접 이해하지 못합니다. 숫자로 변환해야 계산할 수 있습니다. 전통적인 방식은 단순히 단어의 출현 빈도를 세는 것이었습니다. 하지만 이 방법은 문맥을 무시합니다. "은행"이라는 단어가 금융기관을 뜻하는지, 강가를 뜻하는지 구분하지 못합니다. 임베딩 모델은 문맥을 고려합니다. "돈을 찾으러 은행에 갔다"와 "강가 은행에서 낚시를 했다"에서 같은 "은행"이지만 다른 벡터를 생성합니다. **AWS가 제공하는 임베딩 모델들** AWS Bedrock은 여러 임베딩 모델을 제공합니다. 첫 번째는 **Amazon Titan Embeddings**입니다. AWS가 직접 개발한 모델로, 다국어를 지원하고 성능이 우수합니다. 가장 많이 사용되는 선택지입니다. 두 번째는 **Cohere Embed**입니다. Cohere 회사가 만든 모델로, 특히 영어에서 뛰어난 성능을 보입니다. 다양한 버전이 있어서 용도에 맞게 선택할 수 있습니다. 세 번째는 **Custom embedding models**입니다. 자체 임베딩 모델을 가져와서 사용할 수도 있습니다. 하지만 대부분의 경우 AWS 제공 모델로 충분합니다. **어떤 모델을 선택할까?** 박시니어 씨가 조언했습니다. "처음에는 Titan Embeddings v1을 추천해요. 무난하고 안정적이거든요." 모델을 선택할 때 고려할 점은 세 가지입니다. **언어 지원**: 한국어 문서를 다룬다면 다국어를 잘 지원하는 모델이 필요합니다. Titan Embeddings는 한국어를 포함한 100개 이상의 언어를 지원합니다. **벡터 차원**: 벡터의 크기를 의미합니다. 차원이 크면 더 정확하지만 저장 공간과 연산 비용이 증가합니다. Titan Embeddings v1은 1536차원, v2는 설정 가능합니다. **비용**: 모델마다 토큰당 가격이 다릅니다. 대량의 문서를 처리한다면 비용 차이가 커질 수 있습니다. **임베딩의 작동 과정** Knowledge Base가 문서를 처리할 때 무슨 일이 일어날까요? 먼저 문서를 청크(작은 조각)로 나눕니다. 각 청크는 보통 몇 백 단어 정도입니다. 그 다음 각 청크를 임베딩 모델에 입력합니다. 임베딩 모델은 청크를 읽고 벡터를 출력합니다. 이 벡터가 벡터 스토어에 저장됩니다. 나중에 사용자가 질문하면, 질문도 같은 임베딩 모델로 벡터로 변환합니다. 그리고 질문 벡터와 가장 가까운 문서 벡터를 찾습니다. 이것이 바로 "유사도 검색"입니다. 코사인 유사도, 유클리드 거리 등의 수학적 방법을 사용합니다. **실제 사용 예제** 위의 코드를 살펴보겠습니다. `invoke_model`을 호출하면 텍스트를 임베딩 벡터로 변환할 수 있습니다. 결과로 받은 `embedding`은 1536개의 실수로 이루어진 배열입니다. 이 숫자들이 문장의 의미를 표현합니다. 사람이 보기에는 무작위 숫자처럼 보이지만, AI 모델에게는 의미 있는 패턴입니다. **임베딩 품질의 중요성** 김개발 씨가 물었습니다. "임베딩이 잘못되면 어떻게 되나요?" "좋은 질문이에요. 임베딩 품질이 낮으면 관련 없는 문서를 가져오게 됩니다." 박시니어 씨가 답했습니다. 예를 들어 사용자가 "환불 정책"을 물었는데, 임베딩이 엉망이면 "배송 정책" 문서를 가져올 수 있습니다. 그러면 AI가 엉뚱한 답변을 하게 됩니다. 따라서 검증된 고품질 임베딩 모델을 사용하는 것이 중요합니다. AWS가 제공하는 모델들은 이미 수많은 데이터로 학습되어 성능이 검증되었습니다. **업데이트와 버전 관리** 임베딩 모델도 계속 발전합니다. AWS는 주기적으로 새로운 버전을 출시합니다. 하지만 주의할 점이 있습니다. 모델 버전이 바뀌면 같은 텍스트라도 다른 벡터가 생성됩니다. 따라서 모델을 업그레이드하려면 모든 문서를 다시 임베딩해야 합니다. 프로덕션 환경에서는 모델 버전을 명시적으로 지정하고, 업그레이드는 신중하게 계획해야 합니다. **실전 팁** 💡 - 처음 시작할 때는 Amazon Titan Embeddings v1으로 시작하세요 - 한국어 문서가 많다면 다국어 지원을 확인하세요 - 임베딩 품질을 테스트하려면 샘플 질문으로 검색 결과를 확인하세요 --- ## 4. 벡터_스토어_구성 "임베딩된 벡터들을 어디에 저장하나요?" 김개발 씨가 다음 단계를 궁금해하자, 박시니어 씨가 "벡터 스토어가 필요하죠. 일반 데이터베이스와는 좀 다릅니다"라고 설명하기 시작했습니다. **벡터 스토어**는 고차원 벡터를 효율적으로 저장하고 검색하는 특수한 데이터베이스입니다. AWS는 OpenSearch Serverless, Amazon Aurora, Pinecone 등 여러 옵션을 지원합니다. 유사도 검색에 최적화되어 있어 빠르게 관련 문서를 찾을 수 있습니다. 다음 코드를 살펴봅시다. ```python # OpenSearch Serverless를 벡터 스토어로 사용하는 Knowledge Base 생성 import boto3 bedrock_agent = boto3.client('bedrock-agent') response = bedrock_agent.create_knowledge_base( name='my-kb-with-opensearch', roleArn='arn:aws:iam::123456789012:role/BedrockKBRole', knowledgeBaseConfiguration={ 'type': 'VECTOR', 'vectorKnowledgeBaseConfiguration': { 'embeddingModelArn': 'arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v1' } }, storageConfiguration={ 'type': 'OPENSEARCH_SERVERLESS', 'opensearchServerlessConfiguration': { 'collectionArn': 'arn:aws:aoss:us-east-1:123456789012:collection/my-kb-collection', 'vectorIndexName': 'bedrock-knowledge-base-index', 'fieldMapping': { 'vectorField': 'embedding', 'textField': 'text', 'metadataField': 'metadata' } } } ) print(f"Knowledge Base ID: {response['knowledgeBase']['knowledgeBaseId']}") ``` 김개발 씨는 궁금해졌습니다. "MySQL이나 PostgreSQL 같은 일반 데이터베이스에 저장하면 안 되나요?" 박시니어 씨가 고개를 저었습니다. "이론적으로는 가능하지만 비효율적이에요. 벡터 검색에는 특수한 인덱스와 알고리즘이 필요하거든요." **벡터 스토어란 무엇인가?** 벡터 스토어는 고차원 벡터를 다루는 데 특화된 데이터베이스입니다. 마치 도서관의 색인 카드가 책을 빠르게 찾게 해주듯이, 벡터 스토어는 수백만 개의 벡터 중에서 비슷한 것을 순식간에 찾아냅니다. 일반 데이터베이스는 정확한 값을 찾는 데 최적화되어 있습니다. "ID가 123인 사용자를 찾아라" 같은 쿼리는 매우 빠릅니다. 하지만 "이 벡터와 가장 비슷한 벡터 10개를 찾아라"는 느립니다. 벡터 스토어는 **근사 최근접 이웃(ANN, Approximate Nearest Neighbor)** 알고리즘을 사용합니다. 정확도를 약간 희생하는 대신 속도를 크게 높입니다. 수백만 개 벡터에서도 밀리초 안에 결과를 반환합니다. **AWS가 지원하는 벡터 스토어들** Knowledge Bases는 여러 벡터 스토어를 지원합니다. **Amazon OpenSearch Serverless**가 가장 인기 있는 선택입니다. 서버리스이므로 인프라 관리가 필요 없습니다. 자동으로 확장되고, 사용한 만큼만 비용을 지불합니다. AWS와의 통합이 매끄럽습니다. **Amazon Aurora with pgvector**도 좋은 옵션입니다. PostgreSQL의 pgvector 확장을 사용하여 벡터를 저장합니다. 이미 Aurora를 사용 중이라면 추가 인프라 없이 시작할 수 있습니다. **Pinecone**은 벡터 데이터베이스 전문 서비스입니다. 매우 빠르고 확장성이 뛰어나지만, 별도의 계정과 비용이 필요합니다. AWS 외부 서비스입니다. **MongoDB Atlas**도 지원합니다. 이미 MongoDB를 사용 중이라면 편리한 선택입니다. **어떤 벡터 스토어를 선택할까?** 박시니어 씨가 추천했습니다. "새로 시작한다면 OpenSearch Serverless를 추천해요. 설정이 간단하고 AWS 생태계와 잘 어울립니다." 선택 기준은 다음과 같습니다. **규모**: 작은 프로젝트(수천 개 문서)라면 Aurora로도 충분합니다. 대규모(수백만 개 문서)라면 OpenSearch나 Pinecone이 적합합니다. **기존 인프라**: 이미 사용 중인 데이터베이스가 있다면 그것을 활용하는 게 효율적입니다. Aurora를 쓰고 있다면 pgvector 확장을 추가하면 됩니다. **비용**: OpenSearch Serverless는 인덱싱과 검색 시간에 따라 과금됩니다. Aurora는 데이터베이스 인스턴스 비용입니다. Pinecone은 자체 요금제가 있습니다. **OpenSearch Serverless 설정하기** Knowledge Base를 만들 때 벡터 스토어를 지정합니다. OpenSearch Serverless를 선택하면 AWS가 자동으로 컬렉션을 생성할 수 있습니다. **Collection ARN**은 OpenSearch Serverless 컬렉션의 고유 식별자입니다. 미리 만들어 둔 컬렉션을 지정하거나, Knowledge Base 생성 시 자동 생성을 선택할 수 있습니다. **Vector index name**은 벡터가 저장될 인덱스 이름입니다. 기본값은 "bedrock-knowledge-base-index"입니다. 여러 Knowledge Base가 같은 컬렉션을 공유한다면 인덱스 이름으로 구분합니다. **Field mapping**은 중요합니다. 벡터 필드, 텍스트 필드, 메타데이터 필드를 각각 지정합니다. 이 매핑이 잘못되면 검색이 작동하지 않습니다. **벡터 인덱싱의 원리** 문서가 동기화될 때 무슨 일이 일어날까요? 먼저 문서가 청크로 나뉘고 각 청크가 임베딩됩니다. 그러면 [0.1, 0.3, -0.2, ...] 같은 벡터가 생성됩니다. 이 벡터들이 벡터 스토어에 저장됩니다. 단순히 저장만 하는 게 아니라 **인덱스**를 만듭니다. 인덱스는 빠른 검색을 위한 특수한 자료구조입니다. 대표적인 인덱싱 알고리즘은 **HNSW(Hierarchical Navigable Small World)**입니다. 벡터들을 그래프 구조로 연결하여 검색 경로를 최적화합니다. 마치 고속도로 네트워크가 목적지까지 빠르게 도달하게 해주는 것과 같습니다. **검색 과정** 사용자가 "제품 보증 기간은?"이라고 질문합니다. 이 질문이 임베딩되어 벡터가 됩니다. 벡터 스토어는 이 질문 벡터와 가장 가까운 문서 벡터들을 찾습니다. **Top-K 검색**이라고 부르며, 보통 상위 3~5개를 반환합니다. 거리 계산에는 **코사인 유사도**나 **유클리드 거리**를 사용합니다. 코사인 유사도는 벡터의 방향을 비교하고, 유클리드 거리는 실제 거리를 계산합니다. 찾아낸 문서들이 AI 모델에게 전달되고, AI는 이를 참고하여 최종 답변을 생성합니다. **성능 최적화** 벡터 스토어의 성능은 여러 요인에 영향을 받습니다. **벡터 차원**이 클수록 정확하지만 느립니다. 1536차원보다 384차원이 훨씬 빠릅니다. 정확도와 속도 사이의 균형을 찾아야 합니다. **청크 크기**도 중요합니다. 청크가 작으면 정확한 정보를 찾지만 검색 횟수가 많아집니다. 청크가 크면 검색은 빠르지만 불필요한 정보가 포함될 수 있습니다. **인덱스 파라미터**를 조정할 수도 있습니다. HNSW의 경우 `ef_construction`과 `M` 값을 튜닝하면 성능을 개선할 수 있습니다. **비용 관리** 벡터 스토어는 비용이 발생합니다. OpenSearch Serverless는 OCU(OpenSearch Compute Units)로 과금됩니다. 인덱싱과 검색 작업량에 따라 비용이 증가합니다. 불필요한 비용을 줄이려면 사용하지 않는 인덱스를 삭제하고, 동기화 빈도를 조절하세요. 개발 환경과 프로덕션 환경을 분리하는 것도 좋습니다. **백업과 복구** 프로덕션 환경에서는 벡터 스토어도 백업해야 합니다. OpenSearch Serverless는 자동 스냅샷을 지원합니다. 만약 문제가 생기면 스냅샷에서 복구할 수 있습니다. 하지만 가장 안전한 방법은 S3의 원본 문서를 보존하는 것입니다. 언제든지 재동기화하면 벡터 스토어를 재구축할 수 있습니다. **실전 팁** 💡 - 처음 시작할 때는 OpenSearch Serverless를 추천합니다 - 벡터 스토어는 별도로 백업하기보다 S3 원본을 잘 관리하세요 - 대용량 데이터라면 청크 크기와 Top-K 값을 조정하여 성능을 최적화하세요 --- ## 5. IAM_역할_설정 김개발 씨가 Knowledge Base를 테스트하려는데 권한 오류가 발생했습니다. "Access Denied?" 당황한 그에게 박시니어 씨가 "아, IAM 역할 설정을 확인해야 해요"라고 말했습니다. **IAM 역할**은 Knowledge Base가 AWS 리소스에 접근할 수 있도록 권한을 부여하는 메커니즘입니다. S3 읽기, 벡터 스토어 쓰기, 모델 호출 등 모든 작업에 적절한 권한이 필요합니다. 보안의 핵심이자 자주 실수하는 부분입니다. 다음 코드를 살펴봅시다. ```python # Knowledge Base를 위한 IAM 역할 정책 예시 (JSON) { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::my-docs-bucket", "arn:aws:s3:::my-docs-bucket/*" ] }, { "Effect": "Allow", "Action": [ "bedrock:InvokeModel" ], "Resource": "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v1" }, { "Effect": "Allow", "Action": [ "aoss:APIAccessAll" ], "Resource": "arn:aws:aoss:us-east-1:123456789012:collection/*" } ] } ``` 김개발 씨는 오류 메시지를 자세히 읽었습니다. "User: arn:aws:sts::...:assumed-role/BedrockKBRole is not authorized to perform: s3:GetObject" "역할에 S3 읽기 권한이 없나봐요." 박시니어 씨가 IAM 콘솔을 열었습니다. **IAM 역할이란?** IAM(Identity and Access Management)은 AWS의 권한 관리 시스템입니다. 역할은 특정 작업을 수행할 수 있는 권한의 집합입니다. 마치 회사의 출입증과 같습니다. 일반 사원증으로는 일반 사무실에만 들어갈 수 있지만, 관리자 카드는 서버실에도 접근할 수 있습니다. IAM 역할도 이와 비슷하게 리소스 접근을 제어합니다. Knowledge Base는 여러 AWS 서비스를 사용합니다. S3에서 문서를 읽고, Bedrock으로 임베딩을 생성하고, OpenSearch에 벡터를 저장합니다. 각 작업마다 권한이 필요합니다. **필수 권한들** Knowledge Base가 작동하려면 세 가지 핵심 권한이 필요합니다. 첫째, **S3 읽기 권한**입니다. `s3:GetObject`는 파일을 읽는 권한이고, `s3:ListBucket`은 버킷의 파일 목록을 보는 권한입니다. 데이터 소스로 지정한 S3 버킷에 대해 이 권한이 있어야 합니다. 둘째, **Bedrock 모델 호출 권한**입니다. `bedrock:InvokeModel`을 통해 임베딩 모델을 사용할 수 있습니다. 리소스 ARN에 사용할 모델을 명시해야 합니다. 셋째, **벡터 스토어 접근 권한**입니다. OpenSearch Serverless라면 `aoss:APIAccessAll`, Aurora라면 데이터베이스 접근 권한, Pinecone이라면 API 키 관리 권한이 필요합니다. **역할 생성하기** IAM 콘솔에서 새 역할을 만들 수 있습니다. **Trusted entity**로 "Bedrock"을 선택합니다. 이렇게 하면 Bedrock 서비스가 이 역할을 사용할 수 있습니다. Trust relationship이라는 개념으로, "누가 이 역할을 맡을 수 있는가"를 정의합니다. 다음으로 **Permissions policies**를 연결합니다. 위의 JSON 코드처럼 필요한 권한을 정의한 정책을 만들어 연결합니다. 여러 개의 정책을 조합할 수도 있습니다. 역할 이름은 "BedrockKnowledgeBaseRole" 같이 명확하게 짓습니다. 나중에 어떤 용도인지 알 수 있어야 합니다. **최소 권한 원칙** 보안의 기본 원칙은 **최소 권한(Least Privilege)**입니다. 꼭 필요한 권한만 부여해야 합니다. 예를 들어 S3 권한을 줄 때 `s3:*` 같은 와일드카드는 위험합니다. 모든 S3 작업을 허용하기 때문입니다. 대신 `s3:GetObject`와 `s3:ListBucket`만 명시적으로 허용합니다. 리소스 ARN도 구체적으로 지정합니다. `"Resource": "*"`는 모든 리소스를 뜻하므로 피해야 합니다. `"Resource": "arn:aws:s3:::my-docs-bucket/*"`처럼 특정 버킷만 허용합니다. **자동 생성된 역할 검토하기** 콘솔에서 Knowledge Base를 만들 때 "자동으로 역할 생성" 옵션을 선택했다면, AWS가 역할을 만들어 줍니다. 하지만 자동 생성된 역할도 검토해야 합니다. IAM 콘솔에서 역할을 찾아 정책을 확인하세요. 때로는 너무 많은 권한을 부여하거나, 반대로 필요한 권한이 빠져있을 수 있습니다. 박시니어 씨가 조언했습니다. "프로덕션에 배포하기 전에 보안팀에 역할 정책을 리뷰 받는 게 좋아요." **일반적인 권한 오류들** 김개발 씨가 겪은 것처럼 권한 문제는 자주 발생합니다. **Access Denied on S3**: S3 버킷 정책이 역할의 접근을 막고 있을 수 있습니다. IAM 역할 정책뿐만 아니라 S3 버킷 정책도 확인해야 합니다. **Model invocation failed**: Bedrock 모델 접근 권한이 없거나, 해당 리전에서 모델이 활성화되지 않았을 수 있습니다. Bedrock 콘솔에서 모델 액세스를 요청해야 합니다. **OpenSearch access denied**: OpenSearch Serverless는 데이터 액세스 정책과 네트워크 정책을 별도로 관리합니다. IAM 역할에 권한이 있어도 OpenSearch 정책에서 허용해야 합니다. **Trust relationship 문제** 역할을 만들었는데도 작동하지 않는다면 Trust relationship을 확인하세요. Trust policy는 "누가 이 역할을 맡을 수 있는가"를 정의합니다. Bedrock 서비스가 역할을 assume할 수 있도록 다음과 같은 정책이 필요합니다. ```json { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole" }] } ``` 이 정책이 없으면 Knowledge Base가 역할을 사용할 수 없습니다. **교차 계정 시나리오** 복잡한 조직에서는 S3 버킷과 Knowledge Base가 다른 AWS 계정에 있을 수 있습니다. 이 경우 양쪽 계정 모두에서 권한을 설정해야 합니다. Knowledge Base 계정의 역할이 S3를 읽을 권한을 가지고, S3 계정의 버킷 정책이 그 역할의 접근을 허용해야 합니다. 교차 계정 설정은 복잡하므로 AWS 문서를 참고하거나 보안팀과 협력하세요. **권한 테스트** 역할 설정이 끝나면 테스트해야 합니다. AWS CLI의 `aws sts assume-role` 명령어로 역할을 테스트할 수 있습니다. 또는 Knowledge Base 동기화를 실행하여 실제로 작동하는지 확인합니다. CloudTrail 로그를 보면 어떤 권한이 거부되었는지 자세히 알 수 있습니다. 오류가 발생하면 CloudTrail에서 `AccessDenied` 이벤트를 찾아보세요. **역할 업데이트** 나중에 데이터 소스를 추가하거나 모델을 변경하면 역할도 업데이트해야 합니다. 새로운 S3 버킷을 추가한다면 해당 버킷 ARN을 역할 정책에 추가합니다. 다른 임베딩 모델을 사용한다면 그 모델의 ARN도 허용해야 합니다. 역할 정책을 변경할 때는 프로덕션 환경에 바로 적용하지 말고, 개발 환경에서 먼저 테스트하세요. **실전 팁** 💡 - 자동 생성된 역할도 반드시 검토하여 불필요한 권한을 제거하세요 - CloudTrail 로그를 활용하면 권한 문제를 빠르게 디버깅할 수 있습니다 - 프로덕션 배포 전에 보안팀의 리뷰를 받으세요 --- ## 6. KB_설정_옵션 Knowledge Base가 작동하기 시작했습니다. 하지만 김개발 씨는 "답변이 너무 길어요" "가끔 엉뚱한 답을 해요" 같은 피드백을 받았습니다. 박시니어 씨가 "설정 옵션들을 조정해 보죠"라고 제안했습니다. Knowledge Base는 다양한 **설정 옵션**을 제공하여 검색 정확도, 응답 품질, 성능을 튜닝할 수 있습니다. 청킹 전략, 검색 파라미터, 메타데이터 필터링 등을 조정하여 최적의 결과를 얻을 수 있습니다. 다음 코드를 살펴봅시다. ```python # Knowledge Base 검색 파라미터 설정 import boto3 bedrock_runtime = boto3.client('bedrock-agent-runtime') # Knowledge Base에서 검색하고 답변 생성 response = bedrock_runtime.retrieve_and_generate( input={ 'text': '제품 보증 기간은 얼마인가요?' }, retrieveAndGenerateConfiguration={ 'type': 'KNOWLEDGE_BASE', 'knowledgeBaseConfiguration': { 'knowledgeBaseId': 'YOUR_KB_ID', 'modelArn': 'arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-v2', 'retrievalConfiguration': { 'vectorSearchConfiguration': { 'numberOfResults': 5, # Top-K 값 'overrideSearchType': 'HYBRID' # 하이브리드 검색 } } } } ) print(response['output']['text']) ``` 김개발 씨는 테스트 결과를 분석했습니다. 어떤 질문은 완벽하게 답변하지만, 어떤 질문은 관련 없는 내용을 말합니다. "뭔가 조정할 수 있는 게 있을까요?" 박시니어 씨가 설정 화면을 열었습니다. "Knowledge Base에는 생각보다 많은 튜닝 옵션이 있어요." **청킹 전략 선택** 문서를 어떻게 나눌 것인가는 매우 중요한 결정입니다. **Default chunking**은 AWS가 자동으로 적절한 크기로 나눕니다. 대부분의 경우 이것으로 충분합니다. 특별한 이유가 없다면 기본값을 사용하세요. **Fixed-size chunking**은 고정된 토큰 수로 나눕니다. 예를 들어 300토큰씩 나누고, 50토큰 오버랩을 둡니다. 오버랩은 청크 경계에서 문맥이 끊기는 것을 방지합니다. **Hierarchical chunking**은 문서 구조(제목, 섹션)를 고려하여 나눕니다. 기술 문서나 매뉴얼처럼 체계적으로 구성된 콘텐츠에 적합합니다. **Semantic chunking**은 의미적으로 연관된 내용끼리 묶습니다. 가장 정교하지만 처리 시간이 더 걸립니다. **청크 크기의 영향** 청크가 너무 작으면 문맥이 부족합니다. "제품 보증 기간은 1년입니다"만 있고 어떤 제품인지 없다면 혼란스럽습니다. 청크가 너무 크면 불필요한 정보가 많이 포함됩니다. AI 모델의 컨텍스트 윈도우를 낭비하고, 핵심 정보가 희석됩니다. 일반적으로 **300~500 토큰**이 적절합니다. 하지만 문서 특성에 따라 다릅니다. 짧은 FAQ는 100토큰, 긴 기술 문서는 1000토큰일 수 있습니다. **검색 파라미터 조정** `numberOfResults`는 **Top-K 값**입니다. 몇 개의 관련 문서를 가져올지 결정합니다. 기본값은 보통 3~5입니다. 너무 적으면 필요한 정보를 놓칠 수 있고, 너무 많으면 노이즈가 섞입니다. 실험을 통해 최적값을 찾아야 합니다. 김개발 씨는 5로 설정하고 테스트했습니다. "이제 더 다양한 정보를 참고하네요." **검색 타입 선택** `overrideSearchType`은 검색 방식을 지정합니다. **SEMANTIC** 검색은 순수하게 벡터 유사도로만 검색합니다. 의미적으로 비슷한 문서를 찾는 데 강력합니다. **HYBRID** 검색은 벡터 검색과 키워드 검색을 결합합니다. 특정 용어가 정확히 매칭되어야 하는 경우에 유리합니다. 예를 들어 제품 모델명이나 고유명사 검색에 효과적입니다. 박시니어 씨가 추천했습니다. "일반적으로는 HYBRID가 더 안정적이에요. 두 방식의 장점을 모두 활용하니까요." **메타데이터 필터링** 문서에 메타데이터를 추가하면 검색을 더 정교하게 할 수 있습니다. 예를 들어 각 문서에 `{"category": "warranty", "product": "laptop"}` 같은 메타데이터를 붙입니다. 그러면 검색할 때 특정 카테고리나 제품만 대상으로 할 수 있습니다. 이것은 멀티 테넌트 환경에서 특히 유용합니다. 고객별로 다른 문서를 보여주고 싶다면 메타데이터로 필터링하면 됩니다. **생성 모델 선택** 검색 후 답변을 생성하는 모델도 선택할 수 있습니다. `modelArn`에 사용할 파운데이션 모델을 지정합니다. Claude, Titan, Llama 등 다양한 선택지가 있습니다. 모델마다 특성이 다릅니다. Claude는 긴 컨텍스트를 잘 처리하고 안전한 답변을 생성합니다. Titan은 빠르고 비용 효율적입니다. 용도에 맞게 선택하세요. **프롬프트 템플릿 커스터마이징** 기본 프롬프트가 마음에 들지 않는다면 커스텀 프롬프트를 사용할 수 있습니다. 예를 들어 "다음 문서를 참고하여 답변하되, 반드시 출처를 명시하세요" 같은 지시를 추가할 수 있습니다. 또는 답변 형식을 지정할 수도 있습니다. 하지만 프롬프트 엔지니어링은 섬세한 작업입니다. 잘못하면 오히려 품질이 떨어질 수 있으니 신중하게 테스트하세요. **응답 스트리밍** 긴 답변을 생성할 때는 스트리밍이 유용합니다. 사용자가 전체 답변을 기다리지 않고 부분적으로 먼저 볼 수 있습니다. Bedrock Runtime API는 스트리밍을 지원합니다. 웹 애플리케이션에서 실시간으로 답변이 나타나는 효과를 줄 수 있습니다. **캐싱 활용** 같은 질문이 반복되는 경우가 많다면 캐싱을 고려하세요. Lambda나 API Gateway 레벨에서 자주 묻는 질문의 답변을 캐싱하면 비용과 응답 시간을 줄일 수 있습니다. 단, 문서가 업데이트되면 캐시를 무효화해야 합니다. **A/B 테스팅** 어떤 설정이 최적인지 확신이 없다면 A/B 테스트를 하세요. 같은 질문 세트로 여러 설정을 테스트하고, 답변 품질을 비교합니다. 정량적 지표(정확도, 응답 시간)와 정성적 평가(사용자 만족도)를 모두 고려해야 합니다. **모니터링과 로깅** 프로덕션에서는 Knowledge Base 사용 패턴을 모니터링해야 합니다. CloudWatch 메트릭으로 검색 횟수, 응답 시간, 오류율을 추적합니다. 이상 징후가 보이면 즉시 대응할 수 있습니다. 사용자 질문과 답변을 로깅하면 품질 개선에 도움이 됩니다. 어떤 질문에 답변을 잘하지 못하는지 분석하여 문서를 보완하거나 설정을 조정할 수 있습니다. **반복적 개선** 김개발 씨는 여러 설정을 시도해 보았습니다. Top-K를 3에서 5로 늘리고, HYBRID 검색을 활성화했습니다. 청크 크기도 400토큰으로 조정했습니다. 며칠 후 사용자 피드백을 확인하니 답변 품질이 눈에 띄게 좋아졌습니다. "처음엔 완벽하지 않아도 괜찮아요. 계속 튜닝하면서 개선하면 됩니다." 박시니어 씨의 조언이었습니다. Knowledge Base 최적화는 일회성 작업이 아닙니다. 사용 패턴을 모니터링하고, 사용자 피드백을 수집하고, 설정을 조정하는 반복적인 과정입니다. **비용 최적화** 설정을 조정할 때 비용도 고려해야 합니다. Top-K를 늘리면 검색 비용이 증가합니다. 큰 청크를 사용하면 모델의 입력 토큰이 많아져 생성 비용이 올라갑니다. 동기화를 자주 하면 임베딩 비용이 증가합니다. 성능과 비용 사이의 균형을 찾아야 합니다. 프로덕션 전에 예상 비용을 계산해 보세요. **실전 팁** 💡 - 처음에는 기본 설정으로 시작하고, 실제 사용 데이터를 보면서 조정하세요 - HYBRID 검색이 대부분의 경우 더 안정적인 결과를 제공합니다 - 청크 크기는 300~500 토큰이 일반적으로 적절합니다 - 사용자 피드백을 적극 수집하여 지속적으로 개선하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: AWS

언어: Python

태그: AWS, Bedrock, KnowledgeBases, VectorStore, RAG

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

AWS Knowledge Bases 완벽 가이드

목차

1. Knowledge Bases 소개

2. 콘솔에서 KB 생성하기

3. 임베딩 모델 선택

4. 벡터 스토어 구성

5. IAM 역할 설정

6. KB 설정 옵션

댓글 (0)

함께 보면 좋은 카드 뉴스

Helm 마이크로서비스 패키징 완벽 가이드

보안 아키텍처 구성 완벽 가이드

AWS Organizations 완벽 가이드

AWS KMS 암호화 완벽 가이드

AWS Secrets Manager 완벽 가이드