왜 지금 “AI-Ready 데이터 파이프라인"인가

최근 커뮤니티 밋업에서 발표된 아키텍처는 운영 데이터베이스(PostgreSQL)에서 발생하는 변경 사항을 실시간으로 캡처해 Apache Iceberg 기반 lakehouse로 옮기고, 그 위에서 자연어로 질의하는 AI 에이전트를 붙이는 구조였다. 이는 단발성 실험이 아니라 업계 전반의 흐름과 일치한다. Linux Foundation의 2025 CNCF Annual Cloud Native Survey에 따르면 컨테이너 사용자의 82%가 Kubernetes를 프로덕션에서 운영 중이며, AI 도입 기업의 66%가 추론 워크로드 확장에 Kubernetes를 사용한다. CNCF는 이를 두고 “모든 AI 플랫폼이 Kubernetes로 수렴하고 있다”고 진단한다. 즉 발표자가 구축한 파이프라인은 개별 사례가 아니라 업계 표준 궤적 위에 있다.

핵심 축 1: PostgreSQL — 여전히 성장하는 운영 DB

발표에서 PostgreSQL을 “이용량 기준 4위 데이터베이스"라고 소개했는데, 이는 DB-Engines 랭킹과 실제로 부합한다. Red Gate의 분석에 따르면 PostgreSQL은 2026년 상반기 DB-Engines 점수가 21.97포인트 상승하며 가장 큰 성장세를 기록했고, Stack Overflow 개발자 설문에서는 처음으로 MySQL을 제치고 가장 널리 쓰이는 데이터베이스로 올라섰다. 이런 성장의 배경에는 pgvector 같은 확장이 있다. pgvector는 별도의 벡터 DB 없이 PostgreSQL 안에서 임베딩 유사도 검색(HNSW, IVFFlat 인덱스)을 가능하게 해, RAG나 시맨틱 검색 같은 AI 워크로드를 기존 운영 DB에 자연스럽게 통합시킨다. 발표자가 언급한 “vector, geospatial 확장이 붙는 범용 데이터베이스"라는 표현은 이 흐름을 정확히 짚은 것이다.

핵심 축 2: CDC와 Debezium — 운영 DB를 실시간으로 흘려보내기

운영 DB의 데이터를 배치로 옮기는 대신, WAL(Write-Ahead Log) 변경분을 실시간으로 캡처하는 CDC(Change Data Capture) 방식이 채택됐다. Debezium은 Kafka Connect 위에서 동작하며 INSERT/UPDATE/DELETE 같은 row 단위 변경을 이벤트로 발행하는, 가장 널리 쓰이는 오픈소스 CDC 플랫폼이다. 소스 DB에 트리거나 별도 로그 테이블을 추가할 필요가 없다는 점이 장점으로 꼽힌다. 이 이벤트는 Kafka를 거쳐 downstream 시스템(lakehouse, 검색 인덱스 등)으로 전파되며, 발표에서 나온 “몇 초 단위로 변경을 감지한다"는 설명과 정확히 일치한다.

핵심 축 3: Kubernetes 네이티브 오퍼레이터 — Strimzi

이 모든 Kafka 클러스터를 Kubernetes 위에서 안정적으로 운영하기 위해 사용된 것이 Strimzi다. Strimzi는 2024년 2월 CNCF Incubation 단계로 승격된 프로젝트로, TLS 인증서 생성부터 롤링 업그레이드까지 Kafka 운영의 복잡성을 오퍼레이터 패턴으로 흡수한다. Axual, Decathlon, SBB 등 실제 프로덕션 사례를 보유하고 있어, “오픈소스+커뮤니티 거버넌스” 기반으로 인프라를 표준화하려는 팀에게 검증된 선택지다.

핵심 축 4: Apache Iceberg — lakehouse의 ACID 계층

CDC로 흘러들어온 데이터는 Apache Iceberg 테이블 포맷으로 lakehouse에 적재된다. Iceberg는 Parquet 같은 파일 포맷 위에 스키마 진화, 타임트래블, 숨겨진 파티셔닝, 그리고 여러 엔진이 동시에 안전하게 쓰고 읽을 수 있는 ACID 트랜잭션을 제공하는 오픈 테이블 포맷이다. 발표자가 소개한 bronze-silver-gold 구조는 Databricks가 정립한 medallion architecture 패턴으로, raw 데이터(bronze)를 정제(silver)하고 다시 BI·ML 소비에 최적화된 형태(gold)로 단계적으로 승격시키는 방식이다. 이렇게 하면 운영 DB에 부담을 주지 않으면서도 분석가와 ML 엔지니어가 동일한 신뢰 가능한 데이터셋 위에서 작업할 수 있다.

마지막 축: 자연어 질의 AI 에이전트와 보안

파이프라인의 최종 목적은 이 데이터를 자연어로 질의하는 AI 에이전트에 연결하는 것이다. 여기서 발표자가 강조한 것은 “SELECT만 허용"하는 권한 제한이었는데, 이는 업계 베스트 프랙티스와 정확히 맞닿아 있다. Arcade.dev의 가이드는 AI 에이전트에 SQL 접근을 줄 때 스키마 그라운딩, 엄격한 쿼리 검증, 최소 권한 원칙, 통제된 실행 환경이 필수라고 강조하며, Rietta의 분석도 프로덕션 DB에는 쓰기 권한을 절대 주지 말고 읽기 전용 레플리카에만 연결할 것을 권고한다. secrets 관리 역시 같은 맥락으로, 에이전트가 사용하는 자격 증명을 별도로 격리해 최소 권한만 부여하는 설계가 요구된다.

도입을 고려한다면

이 전체 구조—PostgreSQL(운영) → Debezium(CDC) → Strimzi/Kafka(전송) → Iceberg(lakehouse) → 자연어 AI 에이전트(분석)—는 각 계층이 오픈소스이자 CNCF 생태계 표준에 수렴한다는 공통점이 있다. 팀 규모가 작다면 굳이 전 계층을 한 번에 구축하기보다 CDC 파이프라인 하나부터 검증하고, Iceberg 테이블 위에서 쿼리 성능을 확인한 뒤 AI 에이전트의 읽기 전용 권한 경계를 설계하는 순서로 단계적으로 접근하는 것이 리스크를 줄이는 방법이다.

🔗 참고 자료 (작성 중 열람한 자료)