117편 · 약 13분

Databricks Lakehouse//RT와 Omnigent: 에이전트 시대의 실시간 레이크하우스 아키텍처

문제: 레이크하우스와 실시간 조회의 불일치

레이크하우스는 분석 쿼리에 최적화돼 있다. Delta Lake와 Apache Iceberg는 대용량 배치 읽기와 ACID 트랜잭션에서 탁월하지만, 수십 밀리초 안에 응답해야 하는 운영 쿼리에는 맞지 않는다.

결과적으로 많은 팀이 두 가지 스택을 동시에 운영한다:

역할	스택	문제
배치 분석	Databricks / Delta / Iceberg	지연 최소 수십 초
실시간 조회	Apache Pinot / ClickHouse / Druid	별도 운영, 데이터 동기화, 거버넌스 격리

데이터는 두 곳에 이중으로 존재하고, 동기화 파이프라인 유지 비용과 거버넌스 정책 이중 적용 부담이 따른다. AI 에이전트가 레이크하우스 데이터를 실시간으로 조회해야 하는 시대에는 이 구조가 더 큰 걸림돌이 된다.

Databricks는 2026년 6월 Data + AI Summit에서 두 가지 발표로 이 문제를 정면으로 공략했다: Lakehouse//RT와 Omnigent.

Lakehouse//RT: Reyden 엔진으로 레이크하우스에서 실시간 조회

핵심 약속

Lakehouse//RT는 Delta Lake와 Apache Iceberg 테이블에서 직접 100ms 이하 지연과 12,000 QPS 처리를 제공한다. 별도의 실시간 데이터베이스 없이, 이미 레이크하우스에 있는 데이터를 그대로 쿼리한다.

데이터 이동이 없고, 포맷 변환이 없으며, CDC 파이프라인이 필요 없다. Unity Catalog 거버넌스가 모든 Lakehouse//RT 쿼리에 네이티브로 적용된다.

Reyden 엔진

Lakehouse//RT를 구동하는 것은 Reyden이라는 신규 컴퓨트 엔진이다. Databricks는 기존 Spark나 Photon을 튜닝하는 대신 처음부터 새 엔진을 작성했다.

Reyden의 핵심 설계 원칙은 두 가지다.

① 완전 비동기 실행 모델

기존 SQL 쿼리 엔진은 단계별로 결과를 기다린다. 스캔이 끝나야 필터가 시작되고, 필터가 끝나야 집계가 시작된다. Reyden은 처음부터 완전히 비동기로 설계됐다. 스캔·필터·집계가 파이프라인 방식으로 동시에 처리된다.

이 설계가 고동시성(high-concurrency) 환경에서 중요한 이유: 수천 개의 쿼리가 동시에 들어오더라도 한 쿼리가 다른 쿼리를 블록하지 않는다. 지연이 처리량이 늘어날수록 급격히 올라가는 기존 OLAP 엔진의 특성을 피한다.

② Delta/Iceberg 파일 포맷 직접 처리

Reyden은 Delta와 Iceberg의 트랜잭션 로그와 파일 포맷을 네이티브로 이해한다. 별도 포맷 변환 없이 Parquet 파일을 직접 읽으면서 ACID 시맨틱을 유지한다. 스냅샷 격리와 타임트래블 쿼리도 지원한다.

성능 수치

Databricks가 공개한 수치:

소규모 데이터셋: 응답 시간 10ms 수준
대규모 데이터셋: 100ms 이하
동시 처리: 12,000 QPS 유지
별도 실시간 스택 대비: 최대 16× 성능 향상 (일부 고객 사례)

StarTree(Apache Pinot 기반)와의 비교에서는 워크로드에 따라 경쟁력 있는 수준을 보였으나, Pinot의 세그먼트 기반 인덱스 구조가 특정 집계 패턴에서는 여전히 유리하다는 평가가 있다.

Databricks Lakehouse//RT 아키텍처: 기존 vs 신규

현재 상태와 한계

Lakehouse//RT는 2026년 6월 기준 베타 단계다. 운영 적용 전에 확인해야 할 사항:

지원 워크로드: 점조회(point lookup), 낮은 카디널리티 필터, 소규모 집계. 풀 스캔이 필요한 대규모 집계는 Photon/Spark가 여전히 효율적이다.
인덱스 전략: Delta 테이블의 Z-order나 Liquid Clustering이 Lakehouse//RT 성능에 영향을 준다. 인덱스 설계 없이 기본 적용했을 때 수치는 나오지 않는다.
GA 일정: 2026년 8월 기준 General Availability 일정 미공개. 프로덕션 크리티컬 워크로드에 적용하려면 GA 여부를 확인할 것.

Omnigent: 에이전트 메타 하네스

문제: 에이전트 하네스의 파편화

코딩 에이전트를 도입하는 팀이 직면하는 문제가 있다. Claude Code, Codex, Cursor, Pi 등 각 에이전트 하네스가 독자적인 실행 환경과 정책 메커니즘을 가진다. 팀이 여러 에이전트를 동시에 운영하면, 각각에 별도 정책을 적용하고 세션을 따로 관리해야 한다.

Omnigent는 이 문제를 해결하는 오픈소스 메타 하네스다. 개별 에이전트 하네스 위에 앉아 이들을 통합 제어한다.

라이선스: Apache 2.0
GitHub: github.com/omnigent-ai/omnigent
발표: 2026년 6월 DAIS, 8월 Databricks Updates에서 추가 기능 공개

Runner + Server 아키텍처

Omnigent는 두 컴포넌트로 구성된다.

Runner

Runner는 개별 에이전트 하네스를 감싸는 래퍼다. Claude Code를 실행하든 Codex를 실행하든, Runner가 제공하는 표준화된 API를 통해 동일하게 제어한다.

omnigent runner claude-code    # Claude Code 래핑
omnigent runner codex          # Codex 래핑
omnigent runner custom ./my-agent.sh  # 커스텀 에이전트 래핑

Runner는 에이전트를 샌드박스 세션으로 격리한다. 세션은 파일시스템 접근, 네트워크 접근, 실행 가능한 명령 등을 정책으로 제한한다.

Server

Server는 정책 관리와 세션 공유를 담당한다. 팀 전체가 공유하는 Omnigent Server 하나에 여러 Runner가 연결된다. Server는:

정책을 중앙에서 정의하고 모든 Runner에 적용
세션을 URL로 공유 (팀원이 에이전트 세션에 실시간 참여)
모든 에이전트 액션의 감사 로그 생성

에이전트 하네스

Claude Code

Codex / Cursor

Pi / 커스텀

→

Runner (샌드박스 세션)

표준화 API 래핑
에이전트 교체 시 코드 변경 없음

파일·네트워크 격리
정책 기반 접근 제어

감사 이벤트 스트림
모든 액션 기록

→

Omnigent Server

정책 엔진
Python 컨텍스트 정책
세션 상태 기반 동적 제어

세션 공유 (URL)
팀원 실시간 참여
핸드오프

감사 로그 저장
Unity AI Gateway 연동 (베타)

→

접근 경로

터미널 CLI

Databricks 앱
(관리형 서버)

웹 API
VPS / Render / Fly.io 배포 가능

Omnigent Runner + Server 아키텍처

컨텍스트 정책 (Contextual Policies)

Omnigent의 핵심 차별점은 상태를 가진(stateful) 정책이다. 기존 에이전트 정책은 요청 단위로 동작한다. Omnigent 정책은 세션 전체 이력을 볼 수 있다.

예: 에이전트가 한 세션에서 10개 이상의 파일을 삭제하면 이후 삭제 명령을 차단

# Omnigent 컨텍스트 정책 예시 (Python)
class DeleteGuard:
    def __init__(self):
        self.delete_count = 0

    def on_action(self, event, state):
        if event.tool == "delete_file":
            self.delete_count += 1
            if self.delete_count > 10:
                return PolicyDecision.DENY(
                    reason="세션 내 삭제 한도(10개) 초과"
                )
        return PolicyDecision.ALLOW

정책은 세션 상태 변수(self.delete_count)를 유지한다. 이 상태는 정책만 볼 수 있고, 에이전트 자신은 정책이 존재한다는 사실도 모른다.

YAML 커스텀 에이전트

Omnigent는 YAML로 멀티 스텝 에이전트를 정의하는 기능을 제공한다. 기존 에이전트를 서브에이전트로 조합하거나, 특정 태스크에 특화된 에이전트를 선언적으로 정의한다.

# omnigent-agent.yaml 예시
name: "코드리뷰 에이전트"
harness: claude-code
steps:
  - action: read_files
    pattern: "**/*.py"
  - action: analyze
    prompt: "보안 취약점을 중심으로 리뷰하고 SARIF 형식으로 출력"
  - action: post_comment
    target: github_pr
policy: security-review-policy

통합 관점: Lakehouse//RT + Omnigent + Unity AI Gateway

Databricks의 큰 그림은 세 구성요소를 묶어 AI 에이전트가 레이크하우스를 실시간으로 안전하게 활용하는 환경을 만드는 것이다.

AI 에이전트 (Omnigent Runner로 래핑)
     │
     │ Omnigent 정책: 쿼리 한도, 민감 테이블 접근 제한
     ▼
Lakehouse//RT (Reyden 엔진)
     │
     │ Unity Catalog: 컬럼 레벨 마스킹, 행 필터, 감사 로그
     ▼
Delta / Iceberg 테이블 (단일 소스)

에이전트가 레이크하우스 데이터를 10ms에 조회하면서, 동시에 Omnigent 정책이 쿼리 유형과 빈도를 제어하고 Unity Catalog가 데이터 접근 권한을 강제한다.

운영 시사점:

에이전트 워크로드와 배치 분석 워크로드가 동일 테이블을 공유하면 리소스 경합이 발생할 수 있다. Lakehouse//RT와 Spark 클러스터의 리소스 격리 정책이 필요하다.
Omnigent Server가 단일 장애점이 되지 않도록 고가용성 배포 구성을 검토할 것.
컨텍스트 정책이 고성능 서빙 경로에 있으면 정책 실행 시간이 지연에 영향을 준다. 정책 로직은 가볍게 유지해야 한다.

도입 체크리스트

Lakehouse//RT 검토 기준

[ ] 레이크하우스 외에 별도 실시간 데이터베이스(Pinot, ClickHouse)를 운영하고 있는가
[ ] 해당 실시간 DB로의 동기화 파이프라인 운영 비용이 유의미한가
[ ] 쿼리 패턴이 점조회/저카디널리티 필터 중심인가 (풀 스캔 중심이면 Photon이 낫다)
[ ] Lakehouse//RT Beta 상태를 수용할 수 있는 환경인가 (GA 전 프로덕션 크리티컬 지양)

Omnigent 검토 기준

[ ] 팀이 여러 에이전트 하네스를 동시에 운영하거나 전환을 고려 중인가
[ ] 에이전트 액션에 대한 감사 로그와 정책 적용이 컴플라이언스 요건인가
[ ] 팀원 간 에이전트 세션 공유나 핸드오프가 워크플로에 필요한가
[ ] Databricks 플랫폼을 사용 중인가 (관리형 Omnigent Server 활용 가능)

요점 정리

Lakehouse//RT는 레이크하우스의 가장 오래된 약점 — 실시간 조회 불가 — 에 구체적인 수치로 응답한다. Reyden의 완전 비동기 설계와 Delta/Iceberg 네이티브 처리가 별도 실시간 DB 없이 10~100ms 응답을 가능하게 한다.

Omnigent는 에이전트 파편화 문제에 오픈소스 레이어로 응답한다. 에이전트 하네스를 교체해도 정책·감사·세션 공유 구조는 그대로 유지된다.

두 제품 모두 2026년 하반기 기준 베타다. 성숙도보다는 방향성을 검증하는 단계다. 레이크하우스 실시간화와 에이전트 거버넌스를 동시에 풀어야 하는 팀이라면, 프로덕션 적용보다 파일럿 평가를 먼저 고려할 것을 권한다.

References

Databricks 공식 발표 — "Introducing Lakehouse//RT: Real-Time Performance on a Unified Lakehouse": https://www.databricks.com/blog/introducing-lakehousert-real-time-performance-unified-lakehouse
Databricks 공식 발표 — "Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents": https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents
Omnigent GitHub: https://github.com/omnigent-ai/omnigent
Databricks Omnigent 문서 (AWS): https://docs.databricks.com/aws/en/omnigent/
Databricks Lakehouse//RT 보도자료: https://www.databricks.com/company/newsroom/press-releases/databricks-launches-lakehousert-bring-real-time-analytics-directly
VentureBeat 분석: https://venturebeat.com/data/databricks-says-it-solved-the-decades-old-data-pipeline-problem-thats-been-slowing-ai-agents
Databricks Lakehouse//RT vs StarTree 비교: https://startree.ai/resources/databricks-lakehouse-rt-vs-startree/
August 2026 Databricks Updates (YouTube): https://www.youtube.com/watch?v=-uocW5O30MQ