AI를 위한 데이터 스택 재구성

엔터프라이즈 AI 도입의 실질적 병목은 모델 성능이 아니라 데이터 인프라라는 점이 점점 명확해지고 있다. 기존 데이터 스택은 정형 데이터 중심의 BI/ETL 워크로드에 최적화되어 있어 OLAP 큐브, 스타 스키마, 배치 ETL 파이프라인이 핵심이었지만, AI 워크로드는 비정형 텍스트·이미지·로그까지 포함한 대규모 임베딩 생성, 벡터 검색, 실시간 피처 서빙을 요구한다. 이를 위해 Lakehouse 아키텍처(Delta Lake, Iceberg, Hudi)가 부상하며 ACID 트랜잭션과 스키마 진화를 보장하는 동시에 객체 스토리지(S3) 위에서 직접 학습 데이터를 다룰 수 있게 됐고, pgvector·Pinecone·Weaviate 같은 벡터 DB가 RAG 파이프라인의 표준 구성요소로 자리잡았다. 또한 Feast·Tecton 같은 Feature Store가 학습-서빙 간 데이터 일관성(training-serving skew)을 해결하고, dbt와 Airflow/Dagster가 데이터 계보(lineage)와 품질 검증을 자동화하는 구조로 재편되고 있다.

개발자 입장에서 가장 큰 변화는 데이터 엔지니어링과 ML 엔지니어링의 경계가 사실상 사라지고 있다는 점이다. 과거에는 데이터팀이 정제된 테이블을 넘기면 ML팀이 모델을 만드는 분업 구조였지만, RAG·Agent 시스템에서는 청킹 전략, 임베딩 모델 선택, 메타데이터 설계, 인덱스 갱신 주기 같은 데이터 파이프라인 결정이 곧 모델 품질을 좌우한다. 한국 기업 환경에서도 사내 위키·Confluence·Jira·Slack 데이터를 LLM에 연결하려는 시도가 늘면서, 권한 기반 접근제어(ACL)를 벡터 검색 단계에서 어떻게 강제할지, PII 마스킹과 데이터 거버넌스를 어떻게 파이프라인에 녹일지가 실무 과제로 떠오르고 있다. 특히 GDPR·개인정보보호법상 "삭제 요청"이 들어왔을 때 임베딩과 벡터 인덱스에서도 해당 데이터를 추적·삭제할 수 있어야 하는데, 이는 전통적인 RDBMS의 DELETE와는 차원이 다른 문제다.

실무적으로 개발자가 지금 점검해야 할 것은 세 가지다. 첫째, 현재 데이터 스택이 비정형 데이터와 벡터 워크로드를 수용할 수 있는지 진단하라. PostgreSQL을 쓰고 있다면 pgvector 확장으로 시작해 별도 벡터 DB 도입 여부를 점진적으로 검토하는 것이 비용 대비 효과적이다. 둘째, 데이터 품질·계보·관측가능성(observability) 도구를 미리 구축하라. Great Expectations, Monte Carlo, OpenLineage 같은 도구로 데이터 SLA를 정의해두지 않으면, AI 모델이 "왜 갑자기 답이 이상해졌는지" 디버깅이 불가능해진다. 셋째, 메타데이터 카탈로그(DataHub, OpenMetadata, Unity Catalog)에 투자하라. AI 에이전트가 자율적으로 데이터를 탐색하고 활용하려면, 사람이 읽는 문서가 아니라 기계가 파싱 가능한 스키마·태그·소유자 정보가 필수다. 모델은 교체 가능하지만 데이터 파운데이션은 한 번 잘못 설계되면 수년간 부채로 남는다는 점을 기억해야 한다.