AIDB로 구현하는 AI 데이터 파이프라인 자동화
Dr. Sala Muthukrishnan · 2026년 5월 18일
AIDB는 청킹(chunking), 임베딩(embedding), 벡터 인덱싱(vector indexing)으로 이어지는 AI 데이터 준비 파이프라인 전체를 자동화하는 EDB의 Postgres 익스텐션입니다. 새로운 데이터가 들어오는 바로 그 순간, 데이터베이스 내부에서 실시간으로 동작합니다. 실제로 어떻게 작동하는지 보여드리기 위해, 이번 글에서는 수사 스토리 PDF를 활용했습니다. 등장인물과 사건, 그리고 그들 사이의 관계가 빼곡히 담긴 실제 문서를, 별도의 수작업 데이터 가공 없이 쿼리 가능한 지식 베이스로 바꿔 보겠습니다.
AIDB가 자동화하는 것, 그리고 그것이 중요한 이유
비정형 문서를 다루는 모든 AI 파이프라인에는 눈에 잘 띄지 않는 공통 비용이 있습니다. 바로 데이터 준비(data preparation)입니다. 단 하나의 쿼리에 답하기 위해서도, 원시 텍스트를 정제하고, 모델이 다루기 좋은 크기로 쪼개고(청킹), 벡터 임베딩으로 변환한 뒤, 검색을 위해 인덱싱하는 과정을 거쳐야 합니다. 기존 방식에서는 이 각각의 단계가 별도의 작업입니다. 직접 코드를 짜고, 스케줄을 걸고, 모니터링하고, 원본 데이터가 바뀔 때마다 다시 돌려야 하죠.
AIDB는 이 비용을 통째로 없앱니다. preparer와 지식 베이스(knowledge base)를 살아 있는 데이터베이스 객체로 선언하기만 하면 됩니다. 그 순간부터 데이터 준비의 주체는 데이터베이스가 됩니다. 소스 테이블에 INSERT가 발생할 때마다 청킹, 임베딩, 인덱싱이 자동으로 실행됩니다. 외부 스케줄러도, ETL 스크립트도 필요 없고, 지식 베이스가 원본과 어긋날 위험도 없습니다.
핵심 원리는 이렇습니다. 데이터 준비는 정해진 시간에 돌리는 작업(job)이 아니라, 모든 INSERT마다 데이터베이스가 자동으로 수행하는 동작(behaviour)이다. AIDB의 Live 모드가 이를 현실로 만들어 줍니다.
이를 직접 검증해 보기 위해, 수사 스토리 PDF를 가져왔습니다. 이름이 명확한 등장인물들, 시간 순으로 이어지는 사건들, 그리고 얽히고설킨 관계망이 담긴 밀도 높은 문서입니다. 이 문서를 AIDB로 완전 자동화된, 쿼리 가능한 RAG 지식 베이스로 바꿔 보겠습니다. 아래는 그 전체 파이프라인을 SQL로 그대로 옮긴 것입니다.
한눈에 보는 자동화 파이프라인
PDF 파일 → source_documents → target_preparer (자동) → RAG_KB (자동) → 쿼리 준비 완료
수작업이 들어가는 단계는 첫 단계, 즉 파싱된 PDF 내용을 source_documents에 적재하는 것뿐입니다. 그 이후는 전부 AIDB가 알아서 처리합니다. target_preparer는 각 구절이 도착하는 즉시 청킹하고, RAG_KB는 그 직후에 각 청크를 임베딩합니다. SQL 클라이언트를 닫기도 전에, 수사 스토리는 이미 쿼리할 수 있는 상태가 됩니다.
1단계 — PDF 내용을 source_documents에 적재하기
수사 스토리 PDF는 외부에서 파싱합니다. 각 구절, 섹션, 문단을 개별 텍스트 조각으로 추출하는 것이죠. 이렇게 추출한 조각들이 소스 테이블의 행(row)으로 들어갑니다. 테이블 구조는 의도적으로 단순하게 가져갑니다. ID, 파트 번호, 자동 생성되는 고유 키, 그리고 원시 텍스트만 있으면 됩니다.
자동 생성되는 unique_id 컬럼은 문서 ID와 파트 번호를 결합해, 모든 구절이 청킹과 임베딩 과정 전체에서 추적 가능하도록 보장합니다. 나중에 RAG_KB를 쿼리해 결과를 받았을 때, 그 결과를 원본 스토리의 어느 구절에서 왔는지 곧바로 역추적할 수 있습니다.
DROP TABLE IF EXISTS source_documents;
CREATE TABLE source_documents (
id TEXT,
part_id INTEGER NOT NULL,
unique_id TEXT NOT NULL GENERATED ALWAYS AS
((id || '.part.') || part_id) STORED,
result TEXT,
CONSTRAINT source_documents_pkey PRIMARY KEY (unique_id)
);
CREATE INDEX source_documents_id_idx
ON source_documents (id);
-- 스토리 구절이 정상적으로 적재되었는지 확인
SELECT * FROM source_documents;
이번 수사 스토리 사례에서 각 행은 하나의 구절을 나타냅니다. 등장인물 프로필, 장면 묘사, 타임라인 항목, 관계에 대한 메모 같은 것들이죠. 파싱이 풍부하고 세밀할수록 검색 정확도도 높아집니다. 행이 삽입되고 나면, AIDB 자동화가 곧바로 작업을 이어받습니다.
2단계 — target_preparer로 청킹 자동화하기
스토리 구절은 길이와 구조가 제각각입니다. AIDB의 target_preparer는 ChunkText 연산을 적용해 각 구절을 일정한 크기의, 임베딩에 바로 쓸 수 있는 청크로 나눠 준비된 문서 테이블에 자동으로 기록합니다. 이것이 자동화된 데이터 준비의 첫 단계입니다. 한 번만 설정해 두면 계속 동작합니다.
aidb.set_auto_preparer를 'Live'로 호출하면 자동화가 활성화됩니다. 이후 source_documents에 발생하는 모든 INSERT는 즉시 청킹됩니다. cron 작업도, Celery 워커도, 폴링 루프도 필요 없습니다.
-- 멱등(idempotent): 다시 실행해도 안전
SELECT aidb.delete_preparer('target_preparer');
SELECT aidb.create_table_preparer(
name => 'target_preparer',
operation => 'ChunkText',
source_table => 'source_documents',
source_data_column => 'result',
destination_table => 'prepared_document',
destination_data_column => 'chunks',
source_key_column => 'unique_id',
destination_key_column => 'id',
options => '{"desired_length": 100}'::JSONB
);
-- Live 모드: INSERT가 발생할 때마다 청킹이 자동 실행됨
SELECT aidb.set_auto_preparer('target_preparer', 'Live');
100토큰 정도의 청크 크기는 서사형(narrative) 콘텐츠에 잘 맞습니다. 특정 인물이나 사건을 분리해 낼 만큼 구체적이면서도, 주변 맥락을 담을 만큼 넉넉하기 때문입니다. 이번 수사 스토리에서는 각 청크가 보통 하나의 인물 특성, 하나의 장면, 또는 하나의 관계 연결을 담게 됩니다.
3단계 — RAG_KnowledgeBase로 임베딩 자동화하기
preparer에서 청크가 자동으로 흘러나오는 상태가 되면, RAG_KB가 두 번째 단계인 임베딩을 담당합니다. AIDB는 각 청크를 BERT 벡터로 변환해 백엔드 벡터 테이블에 저장합니다. Live 모드로 설정해 두면, 새 청크가 기록되는 순간 임베딩이 실행되어 완전 자동화된 데이터 준비 체인이 완성됩니다.
수동으로 임베딩을 돌릴 필요도, 배치 작업을 만들 필요도 없습니다. 수사 스토리 전체, 즉 모든 등장인물과 사건, 관계가 Postgres 내부에서 시맨틱 벡터로 인코딩됩니다. 그것도 끊김 없이, 자동으로요.
-- 멱등(idempotent): 다시 실행해도 안전
SELECT aidb.delete_knowledge_base('RAG_KB');
SELECT aidb.create_table_knowledge_base(
name => 'RAG_KB',
model_name => 'bert',
source_table => 'prepared_document',
source_data_column => 'chunks',
source_data_format => 'Text',
source_key_column => 'unique_id'
);
-- Live 모드: 새 청크가 생길 때마다 임베딩이 자동 실행됨
SELECT aidb.set_auto_knowledge_base('RAG_KB', 'Live');
-- 벡터가 채워졌는지 검증
SELECT * FROM RAG_KB_vector LIMIT 10;
이제 파이프라인이 완전히 살아 움직입니다. 수사 스토리의 새 구절을 source_documents에 삽입해 보세요. 새로운 진술, 새로 발견된 문서, 업데이트된 인물 프로필 무엇이든, target_preparer를 거쳐 RAG_KB까지 자동으로 흘러 들어갑니다. 그 외에 따로 해야 할 일은 없습니다.
결과: 스토리를 데이터베이스처럼 쿼리하기
자동화 파이프라인이 가동되면, RAG_KB는 자연어로 쿼리할 수 있습니다. 질의문을 AIDB의 시맨틱 검색 함수에 바로 넘기면 됩니다. 인물 이름으로 묻든, 특정 유형의 사건으로 묻든, 장소나 당사자 간의 관계로 묻든 상관없습니다. 이 검색은 키워드 기반이 아니라 유사도(similarity) 기반입니다. 쿼리에 사용한 단어가 원문과 다르더라도, AIDB가 가장 관련성 높은 구절을 찾아 순위를 매겨 줍니다.
이것이 바로 AIDB의 자동화된 데이터 준비가 가능하게 만드는 일입니다. 수사 스토리는 더 이상 정적인 PDF가 아니라, 구조화되고 검색 가능한 인텔리전스 계층이 됩니다. 새 자료가 추가되면 자동으로 최신 상태를 유지하는 계층 말이죠.
정리: AIDB가 처음부터 끝까지 자동화하는 것
이번 수사 스토리 예시는 하나의 일반적인 역량을 보여줍니다. PDF, 보고서, 사건 파일, 연구 논문, HTML 등 어떤 문서든 source_documents에 적재하기만 하면, 곧바로 살아 있는 자동화 RAG 파이프라인의 일부가 됩니다. 나머지는 AIDB가 처리합니다.
청킹 — target_preparer가 INSERT 시점에 원시 텍스트를 모델에 바로 쓸 수 있는 청크로 자동 분할합니다.
임베딩 — RAG_KB가 청크가 도착하는 대로 각각을 벡터로 자동 변환합니다.
인덱싱 — 벡터는 Postgres 내부에 저장·인덱싱됩니다. 별도의 외부 벡터 스토어가 필요 없습니다.
최신성(freshness) — 지식 베이스는 항상 원본 데이터와 동기화된 상태를 유지합니다. 예약된 재실행도, 데이터 드리프트도 없습니다.
bert를 AIDB가 지원하는 다른 모델로 교체해도 됩니다. OpenAI 임베딩, 로컬 Ollama 모델, 또는 특정 도메인에 맞게 파인튜닝한 모델까지, 파이프라인을 바꾸지 않고 그대로 쓸 수 있습니다. target_preparer와 RAG_KB는 설계 자체가 모델에 종속되지 않도록(model-agnostic) 만들어졌기 때문입니다.
원문: AI Data Pipeline Automation with AIDB (EDB Blog)
메일: salesinquiry@enterprisedb.com
