[AI] LLM 시대의 데이터 파이프라인

들어가며

최근에는 범용적인 지식을 가진 대형 언어 모델(LLM)에 기업 내부의 프라이빗한 데이터(사내 규정, 고객 CS 내역, 위키 문서 등)를 주입하여, 정확하고 안전하게 답변하는 AI를 구축하려는 니즈가 폭발하고 있습니다.

이때 LLM에게 실시간으로 관련 지식을 검색해서 떠먹여 주는 기술을 RAG(Retrieval-Augmented Generation, 검색 증강 생성)라고 부릅니다. 그리고 이 RAG 시스템을 지탱하는 뼈대가 바로 Vector DB입니다.

그동안 숫자와 날짜 같은 '정형 데이터'를 다루는 데 익숙했던 데이터 엔지니어들에게, 비정형 데이터를 AI가 이해할 수 있는 형태로 가공하여 파이프라인을 구축하는 일은 완전히 새로운 패러다임입니다. 이번 글에서는 전통적인 ETL 파이프라인과 RAG 파이프라인이 어떻게 다른지, 그리고 왜 기존의 RDBMS가 아닌 Vector DB를 사용해야만 하는지 그 원리를 짚어보겠습니다.

 

 

1. ETL에서 RAG 파이프라인으로

기존 데이터 엔지니어링의 핵심은 RDBMS나 로그 파일에서 데이터를 추출하고, 비즈니스 로직에 맞게 조인 및 집계하여 데이터 웨어하우스에 적재하는 ETL 파이프라인이었습니다. 목적지는 주로 BI 대시보드나 통계 리포트였죠.

하지만 LLM을 위한 RAG 파이프라인은 데이터의 형태와 가공 방식이 완전히 다릅니다.

• Extract (추출): 테이블 형태가 아닌 PDF, 사내 Confluence 위키, 슬랙 대화 기록 같은 비정형 텍스트 데이터를 수집합니다.
• Chunking (분할): 수집한 긴 문서를 LLM이 소화할 수 있는 적절한 길이(Token 단위)의 조각으로 잘게 쪼갭니다.
• Embedding (임베딩): 쪼개진 텍스트 조각들을 AI가 의미를 연산할 수 있도록 다차원 숫자 배열(벡터)로 변환합니다.
• Load (적재): 이 벡터 데이터들을 고속으로 검색할 수 있는 Vector DB(Pinecone, Milvus, Chroma 등)에 저장합니다.

전통적인 파이프라인이 데이터를 '집계'하기 위해 존재했다면, RAG 파이프라인은 AI에게 문맥을 '검색'해주기 위해 존재합니다.

 

2. 왜 기존 RDBMS로는 안 될까? (키워드 검색의 한계)

"그냥 기존에 쓰던 PostgreSQL이나 MySQL에 텍스트를 저장하고 LIKE 연산자로 검색해서 LLM한테 주면 안 되나요?"라는 의문이 들 수 있습니다.

RDBMS의 검색은 기본적으로 키워드 일치 방식입니다. 예를 들어 사용자가 "해외 출장 시 식비 지원 한도가 얼마인가요?"라고 질문했을 때, 사내 규정 DB에 '해외', '출장', '식비'라는 단어가 정확히 들어간 문장만 찾을 수 있습니다. 만약 사내 규정에 "국외 파견 시 식대 보상 규정"이라고 적혀 있다면, 의미는 완벽히 같지만 RDBMS는 이를 찾아내지 못합니다.

LLM이 똑똑하게 대답하려면 글자가 아니라 '의미(Semantic)'를 기준으로 데이터를 검색해 와야 합니다. 이것이 Vector DB가 필요한 이유입니다.

 

3. Vector DB의 핵심: 임베딩과 코사인 유사도

Vector DB는 텍스트를 고차원 공간의 좌표, 즉 벡터로 저장합니다. 임베딩 모델을 거친 텍스트는 수백~수천 개의 숫자로 이루어진 배열이 됩니다.

임베딩의 마법은 의미가 비슷한 단어나 문장일수록 다차원 공간에서 서로 가까운 위치에 좌표가 찍힌다는 점입니다. '사과'와 '바나나'는 거리가 가깝고, '사과'와 '맥북'은 문맥에 따라 다른 공간에 배치되는 식입니다.

사용자가 질문을 던지면, RAG 시스템은 다음 과정을 거칩니다.

1. 사용자의 질문을 임베딩 모델을 통해 벡터 좌표로 변환합니다.
2. Vector DB 공간에서 방금 찍힌 질문의 좌표와 가장 가까운 거리에 있는 데이터 조각(Chunk)들을 찾아냅니다.

이때 거리를 계산하는 가장 대표적인 수학적 개념이 코사인 유사도입니다. 두 벡터가 이루는 '각도'를 계산하여, 각도가 0도에 가까울수록 두 문장의 의미가 유사하다고 판단하는 원리입니다. 단순히 단어의 빈도수를 세는 것을 넘어, 문장의 맥락과 숨은 의미까지 수치화하여 가장 연관성 높은 데이터를 LLM에게 쥐여줄 수 있게 됩니다.

 

4. 대표적인 Vector DB 종류와 특징

RAG 파이프라인을 구축할 때 어떤 Vector DB를 선택할 것인가는 데이터 엔지니어에게 중요한 아키텍처 결정 사항입니다. 현재 시장에서 가장 많이 활용되는 대표적인 Vector DB 3가지의 특징을 표로 정리해 보았습니다.

 

종류	아키텍처 형태	장점	단점	최적의 선택 기준
Pinecone	완전 관리형 SaaS (Cloud Native)	• 빠른 초기 셋업 • 운영/유지보수 공수 제로 • 실시간 고속 인덱싱	• 상용량 비례 비용 발생 • 자체 인프라 내재화 불가	인프라 관리 리소스를 최소화하고, 빠르게 서비스를 프로덕션에 배포해야 할 때
Milvus	대규모 분산형 오픈소스 (Kubernetes 최적화)	• 대용량 데이터에서 극강의 비용 효율 • 다양한 맞춤형 인덱싱 알고리즘 지원	• 다소 복잡한 아키텍처 구성 • 초기 구축 및 운영에 상당한 엔지니어링 리소스 필요	사내 데이터 보안이 중요하고, 수십억 건 이상의 대규모 벡터 데이터를 다룰 때
Chroma	개발자 친화적 경량 오픈소스	• 매우 직관적인 가이드와 사용법 • 인메모리 및 로컬 파일 구동 가능	• 분산 클러스터링 미지원 • 고가용성이 부족하여 대용량 서빙에 한계	로컬 환경에서 테스트를 수행하거나, 빠르게 AI 기능의 MVP(최소 기능 제품)를 검증할 때

 

마무리하며

지금까지 데이터 엔지니어의 핵심 역량은 파이프라인이 멈추지 않게 스케줄링하고, 대용량 데이터를 메모리 낭비 없이 빠르게 조인하는 것이었습니다.

하지만 AI 시대가 본격화되면서, 데이터 엔지니어의 역할은 정형화된 숫자를 다루는 것을 넘어 "AI가 참조할 양질의 문맥을 어떻게 잘게 쪼개고, 정확하게 벡터화하여 서빙할 것인가"로 확장되고 있습니다.

Vector DB와 RAG는 단순한 유행이 아니라 데이터 엔지니어링 생태계의 새로운 필수 인프라로 자리 잡고 있습니다. 앞으로의 파이프라인은 숫자의 집계를 넘어, 언어의 의미를 담아내는 방향으로 진화할 것입니다.