RAG(Retrieval-Augmented Generation)은 FM의 학습 데이터에 없는 최신 정보나 기업 내부 지식을 동적으로 주입하는 아키텍처 패턴입니다. FM은 파라미터에 고정된 지식만 갖고 있기 때문에, 2024년 이후의 정보나 사내 기밀 문서를 다루려면 RAG가 필수입니다. 이 글에서는 데이터 전처리부터 검색 최적화까지 RAG 전체 파이프라인을 실무 관점에서 분해합니다.
FM 입력 데이터 전처리/검증/변환
RAG 시스템의 품질은 검색 단계보다 데이터 품질 단계에서 훨씬 더 많이 결정됩니다. "garbage in, garbage out"은 FM에서도 그대로 적용됩니다.
데이터 소스와 형식
Bedrock Knowledge Bases가 지원하는 데이터 소스는 다양합니다.
| 소스 타입 | 예시 | 전처리 포인트 | |----------|------|-------------| | S3 문서 | PDF, Word, HTML, Markdown | 레이아웃 파싱, 표/이미지 처리 | | 웹 크롤러 | 공개 웹페이지 | 광고/내비게이션 노이즈 제거 | | Confluence | 사내 위키 | 접근 권한 기반 필터링 | | SharePoint | MS365 문서 | 메타데이터 보존 | | Salesforce | CRM 데이터 | 구조적 데이터 정규화 |
전처리 핵심 원칙
문서를 그냥 청킹하면 검색 품질이 크게 떨어집니다. 전처리 단계에서 아래 항목을 반드시 처리해야 합니다.
노이즈 제거: 헤더/푸터, 페이지 번호, 목차, 광고 배너를 제거합니다. 인코딩 정규화: UTF-8로 통일하고 특수 문자(em-dash, non-breaking space)를 표준화합니다. 구조 보존: 표, 리스트, 코드 블록의 구조적 의미를 텍스트에서 유지합니다. 중복 제거: 동일 문서의 버전 관리 불일치로 같은 내용이 여러 번 인덱싱되지 않도록 합니다.
ETL/ELT 파이프라인 설계
대규모 문서 처리는 단순 스크립트가 아닌 제대로 된 파이프라인 아키텍처가 필요합니다.
AWS Glue
AWS Glue는 서버리스 ETL 서비스입니다. S3에서 원본 문서를 읽어 정제·변환한 뒤 다시 S3에 저장하는 배치 파이프라인에 적합합니다.
일반적인 패턴: S3 원본 버킷에 새 문서 업로드 이벤트 발생 EventBridge 규칙이 Glue Job을 트리거 Glue Job이 텍스트 추출, 정제, 메타데이터 보강 수행 처리된 문서를 정제 버킷(clean bucket)에 저장 Bedrock Knowledge Base가 정제 버킷을 동기화
Amazon Kinesis Data Streams / Firehose
실시간 문서 스트림이 필요한 경우 (예: 뉴스 피드, 실시간 로그 분석)에 사용합니다. Kinesis Data Streams로 이벤트를 수집하고, Lambda로 전처리한 뒤, S3로 저장하는 패턴이 일반적입니다.
AWS Step Functions
복잡한 조건 분기가 있는 멀티스텝 파이프라인에 적합합니다. 예를 들어 PDF → 텍스트 추출 → 언어 감지 → 번역(필요시) → 임베딩 생성 → 벡터 DB 삽입 흐름을 Step Functions으로 오케스트레이션합니다. 각 스텝의 재시도 로직과 에러 처리를 시각적으로 관리할 수 있습니다.
벡터 데이터베이스 선택: OpenSearch Serverless vs Aurora PostgreSQL vs 기타
벡터 DB 선택은 규모, 비용, 운영 복잡도, 검색 기능에 따라 달라집니다.
Amazon OpenSearch Serverless (벡터 검색)
Bedrock Knowledge Bases의 기본 벡터 스토어입니다. 서버리스로 자동 스케일링되므로 용량 계획이 필요 없습니다.
장점: Bedrock와 네이티브 통합 (설정 최소화) ANN(Approximate Nearest Neighbor) 알고리즘 기반 고속 벡터 검색 하이브리드 검색 (BM25 + 벡터) 지원 전문 검색(full-text search)과 벡터 검색을 단일 엔진에서
단점: 트래픽이 없어도 최소 OCU(OpenSearch Compute Unit) 비용 발생 완전한 SQL 인터페이스를 원한다면 부적합
Amazon Aurora PostgreSQL + pgvector
기존 Aurora PostgreSQL 클러스터에 확장을 추가해 벡터 검색을 사용합니다.
장점: 기존 RDS 인프라 재사용 (추가 비용 최소화) SQL로 벡터 검색 + 관계형 필터링 동시 수행 메타데이터 필터링이 복잡할 때 SQL의 유연성
단점: 수억 개의 벡터에서는 OpenSearch보다 검색 속도 느림 클러스터 관리 오버헤드 존재
Amazon Neptune Analytics
그래프 데이터베이스 기반으로, 벡터 검색 + 그래프 탐색을 결합해야 할 때 적합합니다. 예를 들어 "이 논문과 유사한 논문 중 저자가 연결된 것" 같은 복잡한 지식 그래프 쿼리에 사용합니다.
Pinecone, Redis (서드파티)
Amazon Bedrock Knowledge Bases는 Pinecone, Redis Enterprise Cloud도 벡터 스토어로 지원합니다. 기존 인프라에 Pinecone을 사용 중이라면 재활용 가능합니다.
임베딩 모델: Titan Embeddings vs Cohere Embed
임베딩 모델은 텍스트를 고차원 벡터로 변환합니다. 같은 의미의 텍스트는 벡터 공간에서 가까이 위치하도록 학습됩니다.
| 모델 | 차원 | 언어 | 강점 | |------|-----|------|------| | Titan Embeddings G1 Text | 1536 | 영어 중심 | AWS 통합, 비용 효율 | | Titan Embeddings V2 | 256/512/1024 (선택) | 영어 중심 | 가변 차원, 최신 성능 | | Cohere Embed Multilingual | 1024 | 100+ 언어 | 다국어 RAG | | Cohere Embed English | 1024 | 영어 | 영어 검색 품질 우수 |
Titan Embeddings V2는 가변 차원(Matryoshka embeddings)을 지원합니다. 낮은 차원(256)을 쓰면 저장 비용과 검색 속도를 개선하면서도 품질 손실을 최소화할 수 있습니다.
다국어 문서를 처리해야 한다면 Cohere Embed Multilingual이 명확한 선택입니다.
청킹 전략: 고정 크기, 시맨틱, 계층적
청킹(Chunking)은 긴 문서를 검색 가능한 작은 단위로 분할하는 과정입니다. 청킹 전략이 RAG 품질에 직접적으로 영향을 미칩니다.
고정 크기 청킹 (Fixed-Size Chunking)
가장 단순한 방법입니다. 토큰 수 기준으로 일정 크기로 자르되, 오버랩을 추가해 문맥이 잘리는 문제를 완화합니다.
청크 크기: 256~512 토큰 (일반적) 오버랩: 50~100 토큰 장점: 구현 단순, 일관된 청크 크기 단점: 문장/단락 중간에서 잘릴 수 있음 (의미 손실)
시맨틱 청킹 (Semantic Chunking)
의미 경계를 기반으로 분할합니다. 문장 단위로 임베딩을 생성한 뒤, 인접 문장 간 코사인 유사도가 크게 떨어지는 지점에서 청크를 분할합니다.
장점: 의미 단위가 보존되어 검색 품질 향상 단점: 임베딩 계산 비용 증가, 청크 크기가 불규칙
계층적 청킹 (Hierarchical Chunking)
문서의 섹션 구조(제목 → 소제목 → 단락)를 반영해 부모-자식 계층으로 청크를 구성합니다.
Amazon Bedrock Knowledge Bases의 "Hierarchical" 청킹 옵션이 이를 지원합니다.
동작 방식: 부모 청크: 섹션 전체를 담는 큰 청크 (컨텍스트 보존) 자식 청크: 세부 단락 단위의 작은 청크 (정밀 검색) 검색 시 자식 청크로 찾고, FM에게는 부모 청크를 컨텍스트로 제공
이 방식은 "small-to-big retrieval" 또는 "parent document retrieval"이라고도 부릅니다.
RAG 파이프라인 설계와 구현
RAG는 두 단계로 구성됩니다.
인덱싱 단계 (오프라인)
!인덱싱 단계(오프라인) 파이프라인