Databricks LTAP, AI 앱 데이터 계층의 재설계

모델보다 데이터 신선도가 병목이다

Databricks의 Lakebase LTAP 설명은 Postgres 기반 운영 데이터베이스를 storage layer부터 다시 보자는 주장이다. 글은 전통 데이터베이스가 write-ahead log와 data files를 한 머신 디스크에 두는 구조를 출발점으로 삼고, Lakebase가 WAL과 데이터 파일을 SafeKeeper와 PageServer 같은 독립 클라우드 서비스로 외부화한다고 설명한다.

핵심은 LTAP, 즉 lake transactional/analytical processing이다. Databricks는 운영 데이터가 open columnar format으로 한 번 저장되고, Postgres와 lakehouse 엔진이 같은 최신 데이터를 읽으면 CDC, mirroring, zero ETL의 지연과 복제 비용을 줄일 수 있다고 주장한다. Databricks의 Lakebase 소개와 LTAP 발표는 이 방향을 회사의 AI 데이터 플랫폼 전략으로 묶는다.

AI 에이전트가 원하는 것은 최신 운영 데이터

AI 앱은 단순히 벡터 DB에 문서를 넣고 검색하는 구조를 넘어섰다. 고객지원 에이전트는 방금 생성된 티켓과 결제 상태를 알아야 하고, 영업 에이전트는 최신 CRM 변경을 반영해야 하며, 운영 에이전트는 장애 로그와 비용 데이터를 동시에 봐야 한다. 데이터가 10분 늦게 복제되거나, 분석용 사본과 운영 DB가 어긋나면 모델이 아무리 좋아도 답은 틀린다.

PostgreSQL WAL 문서는 WAL이 장애 복구와 내구성의 핵심임을 설명한다. Apache Parquet 같은 columnar format은 분석 엔진 생태계의 기반이다. Databricks의 주장은 이 둘을 억지로 한 엔진에 넣기보다 storage layer에서 만나는 쪽이 낫다는 것이다.

한국 기업의 현실적인 의미

한국 기업 대부분은 아직 "AI 프로젝트용 데이터마트"를 별도로 만들고 있다. CRM, 결제, 로그, 상담 데이터를 ETL로 모으고, 다시 벡터화하고, 다시 권한을 붙인다. 이 방식은 PoC에는 빠르지만 운영 단계에서는 지연과 권한 불일치가 문제가 된다. AI 에이전트가 실제 업무를 수행하려면 최신성과 권한, 감사 로그가 동시에 맞아야 한다.

KTX Data, 에이전트 시대의 컨텍스트 레이어는 에이전트용 데이터 접근 계층의 중요성을 다뤘고, Appia Foundation, AI 표준을 증거 체계로 바꾸다는 결과의 근거를 남기는 표준화 흐름을 봤다. LTAP 논의는 이 두 흐름의 하부 인프라다. AI가 최신 데이터를 읽고, 그 근거를 남기며, 운영 부하를 만들지 않아야 하기 때문이다.

Databricks의 전략적 포지션

Databricks가 이 메시지를 내는 이유도 분명하다. 모델 레이어는 OpenAI, Anthropic, Google, 오픈웨이트 진영이 격렬히 경쟁한다. 반면 기업 고객은 "우리 데이터로 안전하게 일하는 AI"를 원한다. Lakebase와 LTAP은 Databricks가 lakehouse를 운영 애플리케이션 쪽으로 확장하려는 시도다.

물론 위험도 있다. 운영 데이터베이스는 신뢰 보수성이 매우 높다. 금융, 커머스, 제조 시스템이 storage architecture를 바꾸려면 latency, rollback, backup, 접근제어, 장애 복구를 모두 검증해야 한다. 따라서 단기적으로는 전면 이전보다 신규 AI 기능, 내부 업무 앱, 분석 부하가 큰 운영 테이블부터 실험될 가능성이 크다. Workweave Router, 모델 선택을 인프라로 만든다가 모델 라우팅을 인프라 문제로 본 것처럼, LTAP은 데이터 라우팅을 인프라 문제로 만든다.

자주 묻는 질문

Q1: LTAP은 HTAP과 같은 건가요?

A: Databricks는 다르다고 설명한다. HTAP은 한 엔진에서 트랜잭션과 분석을 함께 하려는 접근이고, LTAP은 storage layer를 통합하고 compute engine은 분리한다.

Q2: 왜 AI 앱에 중요한가요?

A: 에이전트는 최신 운영 데이터를 읽어야 한다. 지연된 복제본을 보면 잘못된 추천이나 작업을 할 수 있다.

Q3: 기존 CDC가 사라지나요?

A: 당장 사라지지는 않는다. 다만 복제 파이프라인을 줄이려는 수요가 커질수록 대안 구조가 중요해진다.

Q4: 한국 기업은 바로 도입해야 하나요?

A: 핵심 거래 DB를 즉시 바꾸기보다 AI 내부도구, 분석 부하가 큰 테이블, 신규 서비스에서 검증하는 편이 현실적이다.

Q5: 데이터팀의 첫 점검 항목은 무엇인가요?

A: AI 기능이 읽는 데이터의 freshness, 권한 일치, 원본 추적, 운영 DB 부하, 장애 시 fallback을 문서화해야 한다.