AIDB로 AI 데이터 파이프라인 자동화: PostgreSQL RAG 구축 가이드
Dr. Sala Muthukrishnan · 2026년 5월 18일
AIDB는 청킹(chunking), 임베딩(embedding), 벡터 인덱싱(vector indexing)으로 이어지는 AI 데이터 파이프라인 자동화를 지원하는 EDB의 Postgres 익스텐션입니다. 새로운 데이터가 입력되는 순간 데이터베이스 내부에서 실시간으로 처리됩니다. 실제 작동 방식을 살펴보기 위해 이번 글에서는 등장인물과 사건, 관계가 담긴 수사 스토리 PDF를 별도의 수작업 데이터 가공 없이 쿼리 가능한 RAG 지식 베이스로 변환합니다.
목차
AIDB가 자동화하는 작업과 중요한 이유
비정형 문서를 다루는 모든 AI 파이프라인에는 눈에 잘 띄지 않는 공통 비용이 있습니다. 바로 데이터 준비(data preparation)입니다. 단 하나의 쿼리에 답하기 위해서도 원시 텍스트를 정제하고, 모델이 다루기 좋은 크기로 나누고(청킹), 벡터 임베딩으로 변환한 뒤, 검색을 위해 인덱싱해야 합니다. 기존 방식에서는 각 단계가 별도의 작업입니다. 직접 코드를 작성하고 일정을 설정해 모니터링하며, 원본 데이터가 바뀔 때마다 다시 실행해야 합니다.
AIDB는 이러한 데이터 준비 작업을 자동화합니다. preparer와 지식 베이스(knowledge base)를 살아 있는 데이터베이스 객체로 선언하면, 데이터 준비의 주체가 데이터베이스로 바뀝니다. 소스 테이블에 INSERT가 발생할 때마다 청킹, 임베딩, 인덱싱이 자동으로 실행됩니다. 외부 스케줄러나 ETL 스크립트가 필요하지 않으며, 지식 베이스가 원본과 어긋날 위험도 줄일 수 있습니다.
핵심 원리는 다음과 같습니다. 데이터 준비는 정해진 시간에 실행하는 작업(job)이 아니라, 모든 INSERT마다 데이터베이스가 자동으로 수행하는 동작(behaviour)입니다. AIDB의 Live 모드가 이를 구현합니다.
이를 직접 검증하기 위해 이름이 명확한 등장인물, 시간 순으로 이어지는 사건, 복잡한 관계망이 담긴 수사 스토리 PDF를 사용합니다. 이 문서를 AIDB를 이용해 완전히 자동화되고 쿼리 가능한 RAG 지식 베이스로 변환해 보겠습니다. 아래에서 전체 파이프라인을 SQL과 함께 단계별로 살펴봅니다.
AIDB 자동화 파이프라인 한눈에 보기
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 지식 베이스를 자연어로 쿼리하기
자동화 파이프라인이 가동되면 RAG_KB를 자연어로 쿼리할 수 있습니다. 질의문을 AIDB의 시맨틱 검색 함수에 바로 전달하면 됩니다. 인물 이름, 특정 유형의 사건, 장소 또는 당사자 간 관계로 질문할 수 있습니다.
검색은 키워드가 아니라 유사도(similarity)를 기반으로 합니다. 쿼리에 사용한 단어가 원문과 다르더라도 AIDB가 관련성이 높은 구절을 찾아 순위를 매깁니다. 자동화된 데이터 준비를 통해 수사 스토리는 정적인 PDF에서 구조화되고 검색 가능한 인텔리전스 계층으로 바뀌며, 새 자료가 추가될 때마다 자동으로 최신 상태를 유지합니다.
AIDB가 처음부터 끝까지 자동화하는 기능
이번 수사 스토리 예시는 AIDB의 일반적인 활용 방식을 보여줍니다. PDF, 보고서, 사건 파일, 연구 논문, HTML 등 어떤 문서든 source_documents에 적재하면 살아 있는 자동화 RAG 파이프라인의 일부가 됩니다. 나머지 데이터 준비 과정은 AIDB가 처리합니다.
- 청킹:
target_preparer가 INSERT 시점에 원시 텍스트를 모델에 바로 사용할 수 있는 청크로 자동 분할합니다. - 임베딩:
RAG_KB가 청크가 입력되는 즉시 각 청크를 벡터로 자동 변환합니다. - 인덱싱: 벡터는 Postgres 내부에 저장되고 인덱싱됩니다. 별도의 외부 벡터 스토어가 필요하지 않습니다.
- 최신성(freshness): 지식 베이스는 원본 데이터와 동기화된 상태를 유지합니다. 예약된 재실행이나 데이터 드리프트가 없습니다.
bert를 AIDB가 지원하는 다른 모델로 교체할 수도 있습니다. OpenAI 임베딩, 로컬 Ollama 모델 또는 특정 도메인에 맞게 파인튜닝한 모델까지 파이프라인을 변경하지 않고 사용할 수 있습니다. target_preparer와 RAG_KB가 모델 비종속적(model-agnostic)으로 설계되었기 때문입니다.
AIDB와 AI 데이터 파이프라인 FAQ
AIDB는 무엇을 자동화하나요?
AIDB는 소스 테이블에 새 데이터가 입력되면 청킹, 임베딩, 벡터 인덱싱으로 이어지는 데이터 준비 과정을 자동화합니다. Live 모드를 사용하면 각 INSERT 시점에 데이터베이스 내부에서 이 과정이 실행됩니다.
AIDB Live 모드는 어떻게 작동하나요?
Live 모드는 source_documents에 INSERT가 발생할 때마다 target_preparer의 청킹과 RAG_KB의 임베딩을 순차적으로 실행합니다. 따라서 외부 스케줄러, cron 작업, Celery 워커 또는 폴링 루프가 필요하지 않습니다.
PDF를 AIDB RAG 지식 베이스로 바로 변환할 수 있나요?
PDF 내용은 먼저 외부에서 구절, 섹션 또는 문단 단위로 파싱해 source_documents에 적재해야 합니다. 적재 이후의 청킹, 임베딩, 인덱싱 과정은 AIDB가 자동으로 처리합니다.
AIDB에 별도의 벡터 데이터베이스가 필요한가요?
이 글의 구성에서는 임베딩 벡터가 Postgres 내부의 백엔드 벡터 테이블에 저장되고 인덱싱됩니다. 따라서 별도의 외부 벡터 스토어 없이 RAG 지식 베이스를 구성할 수 있습니다.
AIDB에서 BERT 이외의 임베딩 모델도 사용할 수 있나요?
본문에 따르면 bert를 AIDB가 지원하는 다른 모델로 교체할 수 있습니다. OpenAI 임베딩, 로컬 Ollama 모델, 특정 도메인에 맞게 파인튜닝한 모델을 파이프라인 구조 변경 없이 사용할 수 있습니다.
원문: AI Data Pipeline Automation with AIDB (EDB Blog)