로봇 학습 데이터 병목을 겨냥한 해법

AI 에이전트가 실시간 데이터를 반영해 정확한 판단을 내리려면, 개발자는 복잡한 ETL(추출·변환·적재) 파이프라인을 설계하고 관리하는 수고를 감수해야 했다. 데이터브릭스는 저장 계층에서 트랜잭션과 분석 데이터를 통합해 이 파이프라인을 제거한 LTAP(Lake Transactional/Analytical Processing)와 Lakehouse//RT를 발표했다.

LTAP는 Postgres(오픈소스 관계형 데이터베이스) 네이티브 트랜잭션 데이터를 쓰기 시점부터 Delta 및 Iceberg 형식으로 저장하는 방식이다. 수십 년 동안 운영 시스템과 분석 시스템을 연결하기 위해 사용해 온 기존의 ETL 파이프라인을 없애 데이터 스택의 구조를 단순화했다. 이를 통해 AI 에이전트가 분석적으로 추론하는 속도를 높여 더 빠르게 움직일 수 있는 환경을 구축했다.

Lakehouse//RT는 초당 12,000건의 쿼리(QPS) 환경에서 100ms 미만의 지연 시간을 제공한다. 특히 소규모 데이터셋에서는 응답 시간이 최저 10ms까지 낮아지며, 이는 기존의 전용 서빙 스택보다 최대 16배 더 나은 성능을 보여주는 수치다. AI 에이전트가 극복하기 어려웠던 데이터 복제 문제와 분리된 거버넌스, 그리고 파이프라인의 복잡성 문제를 해결하는 구체적인 아키텍처 판단 기준이 된다.

기술이 실제로 작동하는 방식

밀리초 단위의 쿼리 지연 시간은 실시간 AI 에이전트의 응답 속도를 결정짓는 핵심 지표다. Lakehouse//RT는 Delta(오픈 소스 저장 형식) 및 Iceberg(오픈 테이블 포맷) 테이블에서 이 수준의 속도를 직접 구현해, 그동안 기업들이 레이크하우스와 병행해 운영하며 관리 부담을 느꼈던 전용 실시간 서빙 계층을 제거했다. 고동시성과 저지연 서빙을 위해 특화 설계된 Reyden(레이든) 컴퓨팅 엔진이 데이터를 레이크하우스 외부로 이동시키지 않고 직접 쿼리하기 때문에 가능하다. 모든 쿼리 실행 과정은 Unity Catalog(통합 거버넌스 프레임워크)의 관리 체계 내에서 이루어지며, 이로 인해 별도의 권한 레이어를 설계하거나 데이터를 복제하는 추가 공정이 사라졌다.

데이터 통합의 지점을 엔진이 아닌 저장소 레이어로 옮긴 Lakebase 아키텍처는 기존 HTAP(하이브리드 트랜잭션/분석 처리) 방식과 차별화된 접근을 보여준다. LTAP(레이크하우스 트랜잭션/분석 처리)는 서로 다른 두 유형의 데이터베이스를 하나로 통합하려 했던 HTAP의 한계를 넘어, 하부 저장소만 단일 복사본으로 유지하는 구조를 택했다. 트랜잭션 처리를 위해서는 Postgres를 사용하고, 분석 작업에는 Spark와 Lakehouse를 각각 배치해 엔진 레벨에서 최적의 도구를 선택해 사용할 수 있게 했다. 쿼리 엔진 레벨에서 작업에 가장 적합한 도구를 사용하게 하면서, 하부 저장소만 단일 복사본으로 유지함으로써 데이터 일관성을 확보하고 아키텍처를 단순화했다.

확인해야 할 핵심 지점

전통적인 데이터 아키텍처가 실시간 데이터 반영을 위해 복잡한 ETL(추출·변환·적재) 파이프라인을 구축해왔다면, 새로운 접근법은 이 계층 자체를 없애는 방향으로 움직인다. 데이터브릭스는 최근 개최된 Data + AI Summit에서 AI 에이전트가 실시간 데이터에 더 빠르게 접근하고 추론할 수 있도록 돕는 Lakehouse//RT와 LTAP(Lake Transactional/Analytical Processing, 레이크 트랜잭션/분석 처리)를 발표했다. Lakehouse//RT는 거버넌스가 적용된 Delta 및 Iceberg 테이블에서 밀리초 단위의 쿼리 지연 시간을 구현한다. 이를 통해 기업이 레이크하우스와 병행해 유지해온 전용 실시간 서빙 계층을 제거하고 인프라를 단순화했다. 이는 데이터 전문가들이 수십 년간 겪어온 운영 및 분석 데이터베이스 관리의 어려움을 해결하려는 목적이다.

LTAP는 Postgres-native 트랜잭션을 저장하며 오브젝트 스토리지의 속도 한계를 극복하는 데 집중한다. 오브젝트 스토리지는 OLTP(온라인 트랜잭션 처리) 워크로드에 필요한 서브 밀리초 성능을 내기에 너무 느리기 때문에, Postgres 컴퓨팅 인스턴스와 스토리지 사이에 Lakebase라는 캐싱 레이어를 배치했다. 설계의 핵심은 캐싱 레이어의 유휴 CPU 성능을 활용해 행(Row) 데이터를 열(Column) 데이터로 변환하는 시점이다. 데이터가 오브젝트 스토리지에 도달하기 전 이 변환을 수행하면 일반적으로 10배 이상 압축된다. 결과적으로 네트워크 비용을 실질적으로 줄이면서 지연 시간 문제를 해결하는 아키텍처를 구현했다.

실시간 데이터를 반영하기 위해 설계하던 복잡한 ETL 파이프라인은 이제 저장 계층의 통합으로 대체된다. 캐싱 레이어의 유휴 CPU를 통해 행 데이터를 열 데이터로 변환해 네트워크 비용을 10배 이상 줄인 구조가 그 실체다.

이제는 별도의 실시간 서빙 계층 없이 12,000 QPS에서 100ms 미만의 지연 시간을 구현할 수 있는지가 아키텍처의 성패를 가르는 기준이 된다. 파이프라인의 제거가 곧 AI 에이전트의 실질적인 성능 최적화로 이어진다.