leangnews
Command Palette
Search for a command to run...
2026년 02월 04일 12:02
Databricks Lakebase, 서버리스 DB로 개발 기간을 수개월에서 며칠로
기사 요약
- Databricks의 서버리스 운영 DB ‘Lakebase’가 일반 공급되며 OLTP를 레이크하우스에 직접 얹어 ETL 없이 분석을 가능케 했다.
- Hafnia, easyJet, Warner Music 등이 애플리케이션 제공 시간을 최대 95%까지 단축하고 레거시 환경을 통합했다.
- 저장·컴퓨트 완전 분리와 텔레메트리의 레이크하우스 수집으로, 에이전틱 AI 시대에 데이터베이스 관리를 ‘운영’이 아닌 ‘분석’ 문제로 재정의한다.
Databricks Lakebase 개요: 서버리스 운영 DB의 새 카테고리
Databricks는 5년 전 분석용 데이터 아키텍처인 ‘데이터 레이크하우스’를 제시한 데 이어, 오늘 일반 공급(GA)에 들어간 Lakebase로 운영(OLTP) 데이터베이스의 새 범주를 제안한다. Lakebase는 PostgreSQL 제공업체 네온(Neon) 인수 기술과 2025년 10월 Mooncake 인수로 확보한 포맷 브리징 역량을 결합해, 거대한 단일 시스템이 아닌 데이터 레이크 저장소 위에서 구동되는 경량·일회성 컴퓨트로 운영 DB를 재해석한다. Databricks 공동창업자 레이놀드 신(Reynold Xin)은 “개발자들이 아주 빠르게 앱을 만들 수 있다고 믿게 하고, 중앙 IT와 DBA가 앱·데이터베이스 폭증에도 안심할 수 있어야 한다”며, 고전적 DB 운영 모델은 규모의 경제를 달성하기 어렵다고 말했다.
Databricks Lakebase가 줄인 개발 기간과 사례
Hafnia는 내부 운영 포털의 트랜잭션 엔진으로 Lakebase를 채택해 프로덕션급 앱 출시 기간을 2개월에서 5일로, 즉 92% 단축했다. easyJet은 100개가 넘던 Git 저장소를 2개로 통합하고, 9개월 소요되던 개발 사이클을 4개월로 56% 줄이며, 10년 된 데스크톱 앱과 유럽 최대급 레거시 SQL Server 환경을 대체하는 웹 기반 수익 관리 허브를 구축했다. Warner Music Group은 통합 기반 위에서 인사이트를 곧바로 프로덕션으로 연결하고, Quantum Capital Group은 일관되고 거버넌스가 적용된 데이터로 석유·가스 투자 식별·평가를 수행하며 중복 저장을 제거했다. 속도 향상의 핵심은 테스트용 환경 생성을 위한 데이터베이스 클로닝과, 운영·분석 데이터 동기화를 위한 ETL 파이프라인 유지보수라는 두 병목을 제거한 데 있다.
기술 아키텍처: Databricks Lakebase의 차별점
전통적 DB는 저장과 컴퓨트를 결합해 인스턴스를 증설하는 방식이고, AWS Aurora는 이를 분리했지만 저장소가 AWS 내부에 잠겨 분석 접근성이 제한적이었다. Lakebase는 저장·컴퓨트 분리를 레이크하우스까지 확장한다. 컴퓨트 층은 사실상 표준 PostgreSQL로 동작해 생태계 호환성을 유지하면서, 모든 쓰기 연산을 레이크하우스 저장 형식으로 기록한다. 그 결과 Spark나 Databricks SQL 등 분석 엔진이 별도 ETL 없이 즉시 조회할 수 있다. 신은 “데이터 레이크의 장점인 저장·컴퓨트 분리에 거버넌스와 트랜잭션 관리 같은 데이터 관리 능력을 더했다”고 설명한다. Databricks는 Neon의 혁신적 아이디어에 자사 인프라의 견고함과 클라우드 스케일을 결합해 “초대규모 플랫폼”으로 확장했다.
에이전틱 AI 시대와 Databricks Lakebase의 스케일
AI 코딩 도구로 개발 비용이 급감하면, 기업은 수백 개의 SaaS를 사는 대신 수백만 개의 맞춤형 내부 앱을 만들게 된다. 이때 전통적 방식으로 수천~수백만 개 DB를 프로비저닝·모니터링·트러블슈팅할 만큼 DBA를 고용하는 것은 불가능하다. Lakebase는 DB 관리를 운영 문제가 아닌 데이터 문제로 다룬다. 쿼리 성능, 리소스 사용량, 연결 패턴, 오류율 같은 모든 텔레메트리와 메타데이터를 레이크하우스에 저장해, 데이터팀이 표준 SQL이나 머신러닝으로 이상치 탐지·문제 예측을 수행한다. 심지어 성능 이상을 겪는 AI 에이전트가 스스로 텔레메트리를 조회·분석해 원인을 진단할 수 있어, 전문 DBA 의존도를 낮춘다.
엔터프라이즈 데이터팀에 주는 시사점
운영 DB를 귀중한 전용 인프라가 아니라 클라우드 컴퓨트처럼 프로그램적으로 확장되는 일시적·셀프서비스 리소스로 보는 관점 전환이 중요하다. 자율 에이전트의 보급 속도와 무관하게, DB 관리를 운영이 아닌 분석 문제로 다루는 아키텍처 원리는 팀 역량과 조직 구조를 바꾸게 된다. 또한 운영 DB의 쓰기가 즉시 분석 엔진에서 조회되는 순간, 트랜잭션 시스템과 데이터 웨어하우스의 경계가 흐려져 중복 시스템 유지 비용은 줄고, 그 경계를 전제로 한 업무 분장도 재설계가 필요하다. 레이크하우스가 그랬듯 초기에는 회의론이 있겠지만, 저장·컴퓨트 분리를 전제하고 저장을 레이크로 일원화하는 접근이 가져올 가능성은 자명하다는 것이 Databricks의 전망이다.