RAG 인덱싱 파이프라인 : 청킹과 임베딩 핵심 이해

회사에서 자주 언급되는 RAG 아키텍처, 그래서 직접 정리해봤다

요즘 우리 회사에서도 RAG(Retrieval-Augmented Generation) 아키텍처가 중요한 시스템 구성 요소로 자주 언급됩니다. "앞으로 데이터 기반의 지식 활용은 다 저걸로 가지 않을까?" 싶을 정도로 회의나 문서에서 등장 빈도가 많아졌고, 저 역시 자연스럽게 관심을 갖고 학습하게 됐습니다.
이 글은 그 과정을 정리한 내용입니다. 전문가처럼 이론을 파고들기보다는, RAG가 어떻게 작동하고 어떤 흐름으로 구현되는지 실무자의 시선에서 풀어보려 합니다.

RAG에서 가장 핵심이 되는 인덱싱 파이프라인

RAG 시스템이 질문에 답하기 위해서는 사전에 ‘지식’을 잘 정리해 두어야 합니다. 이때 사용하는 것이 RAG 인덱싱 파이프라인인데요, 이 파이프라인은 크게 두 가지 단계로 나뉩니다:

1. 데이터 수집 및 준비 (ELT 포함)
2. RAG 인덱싱

---

1단계: 데이터 수집 및 준비 - ELT 기반 데이터 정제

RAG이 활용할 수 있는 데이터는 굉장히 다양합니다. 내부 문서, DB, 웹페이지, 로그, 심지어 스트리밍 데이터까지 모두가 후보가 될 수 있죠.
먼저 이 데이터들을 데이터 레이크 혹은 레이크하우스로 모읍니다. 여기서 사용하는 방식이 바로 **ELT(Extract → Load → Transform)**입니다.

• Extract: 데이터베이스 쿼리, API, 크롤링 등을 통해 다양한 소스에서 데이터를 가져옵니다.
• Load: 가져온 데이터를 거의 가공하지 않은 상태로 레이크에 저장합니다. 속도와 유연성이 관건입니다.
• Transform: 저장된 데이터를 분석 가능하고 검색 가능한 형태로 정제합니다. 필드 정리, 불필요한 정보 제거, 형식 통일 등이 여기에 포함되죠.

ETL 경험이 있다면 익숙할 텐데요, 이 단계에서의 역할은 매우 중요합니다. 정리가 잘못되면 LLM이 아무리 똑똑해도 쓸모없는 답을 할 수밖에 없습니다.

---

2단계: RAG 인덱싱 파이프라인 - 데이터를 ‘검색 가능한 지식’으로 바꾸는 과정

이제 준비된 데이터를 가지고 RAG 시스템이 바로 사용할 수 있는 형태로 변환하는 단계입니다. 핵심은 텍스트를 벡터로 바꾸고, 그걸 검색 가능한 인덱스로 구성하는 것입니다.

1. 데이터 로딩
   레이크에 저장된 방대한 데이터 중, 실제 RAG에 사용할 정보만 선별해 불러옵니다.
2. 전처리 및 청킹 (Chunking)
   • PDF에서 텍스트 추출
   • 불필요한 기호 제거, 띄어쓰기 정리
   • 긴 문서를 문단 단위로 나누는 ‘청킹’ 작업
     이 과정에서 각 조각에는 원본 위치나 문서 이름 같은 메타데이터도 함께 붙습니다.
3. 임베딩 벡터 생성
   • 청크된 텍스트를 임베딩 모델에 넣으면 각 텍스트는 의미 기반의 벡터로 변환됩니다.
   • 같은 주제의 내용은 서로 가까운 위치의 벡터로 표현되죠.
4. 벡터 DB 인덱싱
   • 생성된 벡터들을 벡터 데이터베이스에 저장하고, 검색 효율성을 높이기 위한 인덱스를 구성합니다.
   • 대표적인 인덱싱 방식으로는 HNSW, IVF 등이 있으며, 수백만 개 벡터 중에서도 유사한 정보를 빠르게 찾아낼 수 있게 해줍니다.

RAG 인덱싱 파이프라인

 

공부를 이어가면서 RAG 인덱싱 파이프라인의 전체 흐름을 이해하는 것도 중요하지만, 그 안에서도 시스템 성능에 결정적인 영향을 주는 핵심 요소가 무엇인지를 구분해내는 감각이 더욱 중요하다는 걸 느꼈습니다. 특히 실전 적용을 고민하는 입장에서, 어떤 부분에 시간을 더 투자하고 어떤 기준으로 설계 결정을 내려야 할지에 대한 명확한 기준이 필요했습니다.

그 중에서도 가장 본질적인 두 축은 바로 **청킹(Chunking)**과 **임베딩(Embedding)**입니다. 이 두 가지는 단순한 전처리 단계가 아니라, RAG 전체 성능의 상한선을 결정짓는 ‘기반 공사’에 해당한다고 봐야 합니다.

---

▷ Chunking은 '의미를 보존하는 손질 과정'

청킹은 원문 데이터를 작은 단위로 나누는 과정입니다. 겉으로 보면 간단해 보이지만, 실제로는 의미의 경계선을 보존하면서 가장 효율적인 크기를 찾는 고난이도 작업입니다.
LLM이 이해할 수 있을 만큼 작게 나누되, 문맥을 잃지 않도록 설계해야 하며, 나눠진 청크는 검색 단계에서 의미 단위로 명확하게 작동해야 합니다.

고정 길이로 나눌지, 문단 단위로 나눌지, 혹은 시맨틱 청킹(Semantic Chunking)으로 접근할지는 도메인 특성과 데이터 구조에 따라 전략적으로 판단해야 합니다. 플랫폼을 설계하는 입장에서는 이 선택이 검색 성능에 미치는 영향을 수치로 확인하고, 반복 테스트를 통해 최적의 조합을 찾아야 합니다.

▷ Embedding은 '의미를 수치화하는 양념'

청크가 만들어졌다면 이제는 그걸 기계가 이해할 수 있는 형태로 바꾸는 작업, 즉 임베딩이 필요합니다.
임베딩은 텍스트를 의미론적 벡터로 바꾸는 과정으로, 결국 ‘사용자 질문과 의미적으로 가장 유사한 데이터’를 찾아주는 검색의 핵심 엔진입니다.

사용자 질문이 "AI의 미래는?"일 때, 단순 키워드 매칭으로는 ‘AI’가 포함된 문장만 검색하겠지만, 임베딩은 "인공지능의 향후 방향", "머신러닝 트렌드" 같은 표현도 동일한 의미로 간주할 수 있게 도와줍니다.
이처럼 ‘언어의 다양성’을 ‘의미의 일관성’으로 환원시키는 기술이 바로 임베딩입니다.

여기에 어떤 임베딩 모델을 쓰는지는 단순한 선택이 아니라 전략입니다. 범용 BERT 기반 모델을 사용할지, 특정 산업군(예: 법률, 의료, 제조)에 특화된 모델을 도입할지, 혹은 내부 데이터로 파인튜닝까지 할지는 시스템 설계 방향에 따라 달라집니다.
속도, 정확도, 벡터 차원 수, 도메인 적합성 등 다양한 요소를 종합 고려한 선택이 필요합니다.

 

이처럼 청킹과 임베딩은 단순한 처리 절차가 아니라, RAG 시스템의 성패를 가르는 본질적인 두 기둥입니다.
여기에 정교한 검색 전략이 맞물리면, 비로소 진짜로 '쓸 만한' RAG 시스템을 구축할 수 있게 됩니다.

📌 핵심 요약

• 청킹(Chunking): 의미 손실 없이 텍스트를 나누는 기술. LLM의 컨텍스트 이해력과 검색 정밀도에 직접적 영향.
• 임베딩(Embedding): 의미 기반 검색의 핵심. 질문과 지식 간의 의미적 유사도를 판단하는 기반 엔진.
• 검색 전략: 위 두 기술의 성과를 실제로 연결해주는 브릿지. 정밀한 검색이 없으면 좋은 청킹과 임베딩도 무용지물.

이 세 가지를 유기적으로 조합하고, 반복 실험을 통해 우리 서비스에 최적화하는 과정이 바로 RAG 시스템의 성과를 좌우하는 진짜 실무입니다.

---

마무리하며

정리해보니 RAG 인덱싱 파이프라인은 결국 기존의 데이터 수집, 정제, 구조화, 인덱싱이라는 익숙한 흐름 위에 새로운 기술이 얹힌 형태라는 걸 느꼈습니다.
특히, ETL 경험이 있는 사람이라면 이 구조에 훨씬 빠르게 적응할 수 있을 것 같습니다.
이제는 데이터를 수집하고 쌓는 것에서 끝나는 게 아니라, 언제든 검색하고 활용할 수 있게 만드는 것이 핵심인 시대입니다.

다음에는 이 인덱싱된 데이터를 기반으로 실제 질의응답이 어떻게 이뤄지는지도 정리해볼 예정입니다.