당신의 ETL 파이프라인은 AI를 위해 설계되지 않았습니다 — 2026년에 이를 해결하는 방법

당신은 멋진 데이터 파이프라인을 가지고 있습니다. 소스에서 데이터를 추출하고, 모든 것을 깔끔하게 변환하며, 정해진 일정에 따라 데이터 웨어하우스(Warehouse)에 로드합니다. 테스트도 통과합니다. 이해관계자들도 만족합니다. 모든 것이 좋습니다.

그런 다음 누군가 말합니다: "이걸 우리 LLM(대규모 언어 모델)에 연결할 수 있을까요?"

그러면 갑자기 당신의 멋진 파이프라인은 쓸모없어집니다.

파이프라인이 고장 났기 때문이 아닙니다. 설계된 목적대로 완벽하게 작동하고 있으니까요. 문제는 전통적인 ETL(Extract, Transform, Load)이 SQL 쿼리, 대시보드, 그리고 인간 분석가를 위해 설계되었다는 점입니다. LLM은 근본적으로 다른 것, 즉 문맥(Context), 의미(Meaning), 그리고 벡터(Vectors)를 필요로 합니다. 만약 당신의 파이프라인이 이것들을 생성하지 못한다면, 당신의 AI는 눈을 가린 채 날아다니는 것과 같습니다.

이것이 현재 데이터 엔지니어링 분야에서 벌어지고 있는 조용한 위기입니다. 기업들은 LLM 인프라에 수백만 달러를 쓰고 있지만, 그 밑바탕이 되는 데이터 파이프라인은 여전히 AI가 거의 추론할 수 없는 데이터 웨어하우스로 행(Rows)과 열(Columns)만을 보내고 있습니다.

이제 이를 해결해 봅시다.

LLM이 실제로 당신의 데이터에서 필요로 하는 것은 무엇인가?

인간 분석가가 데이터 웨어하우스에 쿼리를 날릴 때는 SQL을 작성합니다. 그들은 status = 'churned'가 구독을 취소한 고객을 의미한다는 것을 알 정도로 충분히 똑똑합니다. 그들은 스스로 문맥을 가져옵니다.

LLM은 그런 사치를 누릴 수 없습니다. 적어도 도움 없이는 말이죠. 모델에게 "왜 엔터프라이즈 고객들이 이탈하고 있나요?"라고 물었을 때, 모델은 단순히 SELECT * FROM churn_events를 실행할 수 없습니다. 모델에게는 의미론적으로 관련 있는 문맥 (Semantically relevant context), 즉 질문과 의미적으로 가까운 구절, 기록 또는 요약이 필요합니다.

여기서 **RAG (검색 증강 생성, Retrieval-Augmented Generation)**가 등장합니다.

RAG를 다음과 같이 생각해보세요. LLM이 모든 것을 기억하려고 노력하는 대신(그것은 불가능합니다. 컨텍스트 윈도우(Context window)는 유한하니까요), 당신이 도서관을 구축하는 것입니다. LLM이 질문에 답해야 할 때마다 그 도서관으로 걸어 들어가 가장 관련 있는 페이지를 찾아 답변하기 전에 읽는 방식입니다.

데이터 엔지니어로서 당신의 역할은 그 도서관을 구축하고 유지 관리하는 것입니다.

그리고 도서관은 데이터베이스가 아닙니다. 도서관은 행(rows)과 열(columns)이 아니라, _의미(meaning)_에 따라 조직됩니다.

AI-Native 파이프라인: 무엇이 다른가

여기 사고방식의 전환이 있습니다. 전통적인 ETL은 다음과 같은 결과물을 생성합니다:

raw data → clean tables → warehouse → SQL queries

AI-native 파이프라인은 다음과 같은 결과물을 생성합니다:

raw data → cleaned chunks → embeddings → vector store → semantic retrieval

새로운 구성 요소는 청크 (chunks), 임베딩 (embeddings), 그리고 **벡터 스토어 (vector store)**입니다. 각각을 자세히 살펴보겠습니다.

청크 (Chunks)

데이터베이스 테이블 전체를 LLM (Large Language Model)에 입력할 수는 없습니다. 설령 할 수 있다 하더라도, 이는 낭비이며 노이즈가 많을 것입니다. 대신, 데이터를 청크 (chunks), 즉 독립적으로 검색 가능한 작고 의미 있는 텍스트 조각으로 나눕니다.

청크의 예는 다음과 같습니다:

• 고객 지원 티켓의 한 단락
• 제품에 대한 3문장 분량의 설명
• 판매 이벤트에 대한 메타데이터의 요약된 행

여기서 핵심은 청크 분할 전략 (chunking strategy)에 있습니다. 너무 작으면 청크가 문맥 (context)을 잃게 됩니다. 너무 크면 토큰 (tokens)을 낭비하고 검색 정밀도 (retrieval precision)가 떨어집니다. 실제로는 청크 간 약 10%의 중첩 (overlap)을 두는 512–1024 토큰 정도가 견고한 시작점입니다.

임베딩 (Embeddings)

임베딩은 텍스트 조각의 _의미 (meaning)_를 나타내는 숫자 리스트, 즉 벡터 (vector)입니다. 의미가 유사한 두 텍스트는 완전히 다른 단어를 사용하더라도 공간상에서 서로 가까운 벡터를 갖게 됩니다.

"고객이 결제를 중단함"과 "결제 실패로 인해 구독이 취소됨"은 사용하는 단어가 매우 다릅니다. 하지만 벡터 공간 (vector space)에서 이들은 이웃입니다.

이것이 바로 마법이며, 시맨틱 검색 (semantic search)을 가능하게 하는 핵심입니다.

벡터 스토어 (Vector Store)

벡터 스토어는 한 가지 특수한 유형의 쿼리에 최적화된 데이터베이스입니다: "이 쿼리 벡터와 가장 유사한 N개의 벡터를 나에게 보여달라." pgvector, Qdrant, Chroma, 그리고 Weaviate와 같은 시스템들이 바로 이 목적을 위해 구축되었습니다.

파이프라인 구축: 실전 가이드

구체적으로 들어가 보겠습니다. 다음은 Python으로 작성된 완전한 AI-native 수집 (ingestion) 파이프라인입니다.

1단계: 데이터 로드 및 청크 분할

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 이 데이터가 데이터 웨어하우스(warehouse), S3 또는 API에서 온다고 가정합니다
...

RecursiveCharacterTextSplitter는 영리합니다. 문단 구분, 문장, 단어 순으로 분할을 시도하며, 가능한 한 의미적 경계(semantic boundaries)를 온전하게 유지합니다.

2단계: 임베딩 (Embeddings) 생성

from openai import OpenAI

client = OpenAI()  # OPENAI_API_KEY 환경 변수를 사용합니다
...

여기서 주목할 두 가지 사항이 있습니다. 첫째, 우리는 배치(batching) 처리를 하고 있습니다 (OpenAI에는 속도 제한(rate limits)이 있으며, 배치가 더 저렴합니다). 둘째, 기본값인 3072 대신 dimensions=1024를 사용하고 있습니다. 대부분의 사용 사례에서 1024 차원은 비용의 3분의 1만으로 95%의 정밀도를 제공합니다. 충분히 가치 있는 선택입니다.

3단계: 벡터 데이터베이스 (Vector Database)에 저장

다음은 pgvector (벡터 지원 기능이 있는 PostgreSQL)를 사용하는 동일한 코드입니다. 이미 Postgres를 운영 중이고 별도의 관리형 서비스(managed service)를 추가하고 싶지 않다면 훌륭한 선택입니다:

import psycopg2
import json

...

ivfflat 인덱스는 대규모 환경에서 쿼리를 빠르게 만드는 핵심 요소입니다. 이 인덱스가 없다면 모든 쿼리는 전체 테이블 스캔(full table scan)을 수행하게 됩니다. ivfflat을 사용하면 Postgres는 벡터를

2. 모델이 변경되면 다시 임베딩(Re-embed)하세요. 만약 text-embedding-3-small에서 text-embedding-3-large로 업그레이드한다면, 모든 데이터를 다시 임베딩해야 합니다. 서로 다른 모델은 호환되지 않는 벡터 공간(vector spaces)을 생성하기 때문입니다. 첫날부터 이를 파이프라인 버전 관리(pipeline versioning)에 포함시키세요.

3. 생성 품질(generation quality)과 검색 품질(retrieval quality)을 분리하여 평가하세요. 가장 흔한 실수는 실제 문제는 검색(retrieval)에 있는데 LLM을 탓하는 것입니다. 올바른 청크(chunks)가 검색되지 않는다면, 세상에서 가장 뛰어난 모델이라도 쓰레기 같은 결과(garbage)를 내놓을 것입니다. RAGAS와 같은 도구를 사용하여 검색 정밀도(precision)와 재현율(recall)을 독립적으로 측정하세요.

4. 대부분의 팀에게는 pgvector로 충분합니다. 수억 개의 벡터를 저장하는 것이 아니라면, 전용 벡터 데이터베이스(vector database)는 필요하지 않습니다. 기존 Postgres에 있는 pgvector를 사용하는 것이 운영하기 더 간단하고 비용도 저렴하며, 벡터를 일반 테이블과 조인(join)할 수 있게 해줍니다. 필요하다면 나중에 최적화하세요.

5. 청킹(Chunking)은 가장 영향력 있는 레버(lever)입니다. LLM을 바꾸면 답변 품질이 5% 개선될 수 있지만, 청킹 전략을 수정하면 40%가 개선될 수 있습니다. 화려하지는 않지만, 바로 여기서 결과가 나옵니다.

더 큰 그림 (The Bigger Picture)

AI 네이티브 데이터 엔지니어링(AI-native data engineering)으로의 전환은 여러분이 구축한 것을 버리는 것이 아닙니다. 그것을 확장하는 것입니다.

여러분의 브론즈/실버/골드 레이크하우스(bronze/silver/gold lakehouse) 레이어는 여전히 유효합니다. 다만 데이터가 검색을 위해 청킹되고, 임베딩되며, 인덱싱(indexed)되는 "시맨틱 레이어(semantic layer)"를 추가하세요. 여러분의 Airflow DAG는 여전히 유효합니다. 새로운 문서를 다시 임베딩하고 벡터 저장소(vector store)를 업데이트하는 일일 작업(daily job)을 추가하세요. 여러분의 데이터 품질 검사(data quality checks)도 여전히 유효합니다. 임베딩의 신선도(freshness)와 검색 커버리지(retrieval coverage)에 대한 검사를 추가하세요.

이를 파이프라인에 새로운 출력 형식(output format)을 추가하는 것이라고 생각하세요. 여러분은 항상 깨끗한 테이블을 생성해 왔습니다. 이제 벡터 인덱스(vector indexes)도 함께 생성하는 것입니다. 동일한 규율(discipline)을 유지하되, 새로운 산출물(artifact)을 만드는 것입니다.

두 가지를 모두 구축하는 법을 배우는 엔지니어들이 실제로 작동하는 AI 시스템을 구축하게 될 것입니다. 즉, 모델이 단순히 인상적일 정도로 유창한 것이 아니라, 진정으로 유용해지는 데 필요한 컨텍스트(context)를 갖춘 시스템을 만드는 사람들 말입니다.

여러분의 파이프라인은 그것이 먹여주는 AI만큼이나 똑똑해질 자격이 있습니다.

Abs,

가브리엘 엔리케 카르도소 안토니오
🔗 gabrielh.dev