모든 에이전트 데이터 프로젝트에는 어색한 순간이 찾아옵니다. 에이전트가 잘 작동합니다. 괜찮은 SQL을 작성하고, 스키마(schema)에 대해 추론하며, 올바르게 보이는 마이그레이션(migration)을 제안합니다. 그러다 아무도 대답하고 싶지 않은 질문이 던져집니다. 운영 환경(production)에서 에이전트가 잘못 작동하면 어떻게 될까요?

일반적인 답변들은 모두 좋지 않습니다.

읽기 전용(read-only) 자격 증명으로 운영 환경을 가리키게 하면, 피해는 제한할 수 있지만 에이전트의 능력도 제한됩니다. 즉, 진단은 할 수 있지만 수정은 할 수 없게 됩니다. 시드(seeded) 데이터가 포함된 스테이징(staging) 데이터베이스를 가리키게 하면, 4개월 전에는 운영 환경과 닮았었지만 지금은 전혀 닮지 않은 데이터에 대해 자신 있게 정답을 말하는 에이전트를 얻게 됩니다. 실행마다 컨테이너를 띄우면, 실행 사이에 유휴 상태로 머무는 컴퓨팅(compute) 비용을 지불하면서 영원히 피스처 파이프라인(fixture pipelines)을 유지 관리해야 합니다.

당신이 실제로 원하는 것은 1초 미만으로 나타나고, 존재하는 동안 비용이 거의 들지 않으며, 에이전트가 작업을 마치면 흔적 없이 사라지는 운영 환경의 완전한 복사본입니다. 다시 말해, 데이터베이스를 위한 git checkout -b가 필요한 것입니다.

Databricks Lakebase는 이를 수행하며, 그 메커니즘은 단순히 기능을 활성화하는 것을 넘어 이해할 가치가 있을 만큼 흥미롭습니다.

Lakebase가 이를 구현하는 방법

Lakebase는 Postgres입니다. 단순히 프로토콜만 호환되는 재구현이 아니라, 진정한 Postgres입니다. Databricks가 변경한 것은 그 밑단의 부분입니다.

표준 Postgres는 컴퓨팅(compute)과 스토리지(storage)가 밀접하게 결합된 모놀리스(monolith) 구조입니다. Databricks는 이 둘을 분리하고 스토리지를 레이크 스토리지(lake storage)로 이동시켰는데, 이는 즉각적인 문제를 발생시킵니다. 오브젝트 스토리지(object storage)는 지연 시간(latency)이 높고 트랜잭션 일관성(transactional consistency)이 없는데, Postgres는 이 두 가지가 모두 있다고 가정하기 때문입니다. 두 가지 구성 요소가 이 간극을 메웁니다. Paxos 합의 알고리즘(consensus algorithm)을 기반으로 구축된 Safekeepers는 저지연 내구적 쓰기(low-latency durable writes)를 처리합니다. Page servers는 레이크에서 필요에 따라 페이지를 구체화(materializing)하여 저지연 읽기(low-latency reads)를 처리합니다.

스토리지(storage)가 분리되고 페이지 주소 지정(page-addressed) 방식이 되면, 브랜칭(branching)은 거의 비용이 들지 않게 됩니다. 이는 복사 시 쓰기(copy-on-write) 방식으로 작동합니다. 즉, 데이터는 레이크(lake)의 한 곳에 그대로 머물러 있으며, Lakebase는 브랜치 간의 차이점(deltas)만을 추적합니다. 브랜치에 데이터를 쓰는 작업은 다른 브랜치에 영향을 주지 않고 독립적으로 변경 사항을 기록합니다.

에이전트 작업에서 중요한 수치들은 다음과 같습니다. 브랜치 생성에는 약 **500밀리초(milliseconds)**가 소요되며, 새로운 인스턴스(instance)가 500밀리초 이내에 가동됩니다. 이전 스냅샷(snapshot)으로의 롤백(rollback) 또한 동일하게 빠르며, 유휴(idle) 상태의 브랜치는 스케일 투 제로(scale to zero)가 되어 브랜치가 대기하는 동안 저렴한 레이크 스토리지 비용만 지불하면 됩니다. Databricks는 프로덕션 환경에서 하루 1,200만 건의 데이터베이스 실행(database launches)이 발생한다고 보고했는데, 이는 단순한 벤치마크라기보다 휘발성 인스턴스(ephemeral instances)가 예외적인 사례가 아닌 의도된 사용 패턴임을 나타내는 지표입니다.

마지막 속성이 바로 이 기술을 에이전트에게 특히 유용하게 만드는 요소입니다. Ali Ghodsi가 서밋 키노트 무대에서 언급했듯이, 에이전트는 "데이터베이스가 가동될 때까지 10분 동안 기다리고 싶어 하지 않습니다." 환경을 구축하기 위해 10분을 기다려야 하는 에이전트에게는 차선책이 사용 불가능한 루프(loop)를 만들기 때문에, 결국 그냥 프로덕션(production) 환경을 할당하게 될 것입니다. 1초 미만의 프로비저닝(provisioning)은 안전한 옵션을 편리한 옵션으로 만들어 줍니다.

격리 전략 비교

루프 구축하기

전체적인 패턴은 다음과 같습니다. Databricks 전용 인터페이스는 의도적으로 하나의 얇은 레이어로 격리되어 있으며, 그 외의 모든 것은 일반적인 Postgres입니다. 왜냐하면 실제로 그것이 Postgres이기 때문입니다.

1단계 — 인스턴스 확보. Lakebase는 현재 Genie Code, 서버리스 GPU (serverless GPUs), Agent Bricks, LakeFlow Designer와 함께 Databricks Free Edition에 포함되어 있으므로, 비용 부담 없이 따라 해 볼 수 있습니다.

# lakebase_control.py — 이 설계에서 유일한 Databricks 전용 레이어입니다.
# 브랜치(branch) 작업을 위한 엔드포인트(endpoint) 형태는 아직 확정되지 않았으므로,
# 배포 전 현재 문서를 확인하세요. get_dsn() 이후의 모든 것은 일반 Postgres입니다.
...

2단계 — 에이전트가 물리적으로 운영 환경을 볼 수 없도록 래핑(wrap)하기. 이 부분이 중요한 부분이며, 의도적으로 지루하게 설계되었습니다. 에이전트는 DSN을 받지 않습니다. 대신 브랜치(branch)에 바인딩된 세션(session)을 받습니다.

# agent_sandbox.py
import contextlib
import psycopg
...

3단계 — 무엇이든 믿기 전에 검증하기. 에이전트가 성공을 보고하는 것은 증거가 아닙니다. 작업 전후에 중요한 불변량(invariants)을 스냅샷(snapshot)으로 찍고, 그 차이(diff)를 비교하세요.

# verify.py
from dataclasses import dataclass

...

4단계 — 실행 자체.

# run_agent_task.py
import uuid
from agent_sandbox import branched_session
...

전체 사이클

이것은 제가 이 글을 위해 만들어낸 패턴이 아닙니다. Databricks가 자사의 자율 파이프라인 복구 에이전트(autonomous pipeline-remediation agent)인 Genie ZeroOps를 내부적으로 사용하는 방식입니다. ZeroOps는 실패 원인을 조사하고, 수정안을 초안으로 작성한 다음, Lakebase와 동일한 브랜칭(branching) 메커니즘을 사용하여 운영 데이터의 얕은 복제본(shallow clones)을 생성합니다. 그 후 제안된 수정안을 복제본에 배포하고, 행 수(row counts)를 검증하며, 그 결과를 풀 리퀘스트(pull request)로 제시합니다. 명시적인 인간의 승인 없이는 그 어떤 것도 운영 환경(production)에 도달하지 않습니다. 이 '복제본에서의 검증(verification-on-a-clone)' 단계가 자율 복구를 무모한 것이 아닌 방어 가능한 수준으로 만드는 핵심이며, 여러분은 이를 기본 기능(primitive)으로서 사용할 수 있습니다.

브랜칭이 해결하지 못하는 것들

격리 수준이 생각보다 좁기 때문에 솔직하게 짚고 넘어갈 가치가 있습니다.

부작용(Side effects)은 브랜치를 벗어납니다. 여러분의 데이터베이스는 격리되어 있습니다. 하지만 에이전트가 호출하는 결제 API는 그렇지 않습니다. 에이전트가 보내는 이메일, 게시하는 Slack 메시지, 또는 발행하는 Kafka 토픽도 마찬가지입니다. 브랜치는 Postgres 내에서 여러분이 소유한 상태(state)만을 보호할 뿐 그 외의 것은 보호하지 않습니다. 모든 외부 통합(external integration)에는 자체적인 샌드박싱(sandboxing)이 필요하며, 브랜치가 모든 것을 해결해 줄 것이라고 가정했다가 팀들이 낭패를 보는 지점이 바로 여기입니다.

브랜치 확산(Branch sprawl)은 실재합니다. 1초 미만의 생성 속도와 실패 시 유지(retain-on-failure) 설정이 결합되면 엄청난 양의 브랜치가 생성됩니다. 첫날부터 TTL(Time To Live)을 강제하고, 브랜치에 생성된 실행(run) 정보를 태그로 달며, 정기적으로 정리하는 리퍼(reaper)를 배치하십시오. Copy-on-write 스토리지는 저렴하지만 공짜는 아닙니다. 부모 브랜치와 크게 달라진(diverges heavily) 브랜치는 더 이상 저렴하지 않습니다.

브랜치 생성 시점에는 신선하지만, 직후에는 즉시 노후화됩니다. 오래 실행되는 에이전트 작업은 스냅샷(snapshot)을 바탕으로 추론합니다. 작업에 20분이 소요되었고 근본적인 질문이 시간에 민감한 것이었다면, 결과가 도출될 시점에는 결론이 틀릴 수 있습니다. 이는 격리에 실패했기 때문이 아니라, 특정 시점의 복사본(point-in-time copy)에 대해 실시간 질문을 던졌기 때문입니다.

불변성 검사 (Invariant checks)는 당신이 기록할 것이라고 생각한 것만을 잡아낼 뿐입니다. 위의 assert_no_corruption 함수는 바닥일 뿐, 천장이 아닙니다. 이는 구조적 손상 (structural damage)을 잡아냅니다. 하지만 에이전트가 잘못된 고객의 기록을 올바르게 업데이트한 경우에는 잡아낼 수 없습니다. 왜냐하면 그것은 의미론적으로 유효하며 (semantically valid) 구조적으로 깨끗하기 때문입니다. 차이점 (diff)에 대한 인간의 검토는 여전히 핵심적인 역할을 수행합니다.

더 넓은 변화

이것이 Databricks를 넘어 중요한 이유는, 모든 에이전트 기반 데이터 프로젝트를 조용히 제약해 온 간극을 메워주기 때문입니다. 즉, 에이전트는 안전하거나 혹은 유용하거나 둘 중 하나였으며, 두 가지를 모두 선택하려면 대부분의 팀이 구축하기 어려운 인프라가 필요했습니다.

애플리케이션 코드는 수십 년 전에 이 문제를 올바르게 해결했습니다. 아무도 운영 소스 코드를 편집함으로써 리팩터링 (refactor)을 테스트하지 않습니다. 브랜치 (branch)를 만들고, 자유롭게 무언가를 망가뜨린 뒤, 제대로 작동하는 것을 병합 (merge)합니다. 데이터베이스는 복사 비용이 충분히 비쌌기 때문에 이러한 편의성 (ergonomics)이 구현되지 않았고, 따라서 한 번도 그 기능을 갖지 못했습니다. 컴퓨팅 (compute)과 스토리지 (storage)를 분리한 것이 마침내 복사 비용을 저렴하게 만들었으며, 저렴한 복사본이야말로 실험을 안전하게 만드는 핵심입니다.

에이전트에게 브랜치를 부여하세요. 마음껏 망가뜨리게 하세요. 그리고 차이점 (diff)을 읽으세요.

Lakebase 브랜치 API는 계속 진화하고 있습니다. 위의 컨트롤 플레인 (control-plane) 호출은 구조적으로는 정확하지만, 실제로 실행하기 전에 현재 Databricks 문서와 엔드포인트 및 필드 이름을 대조하여 확인하십시오. DSN 하위의 모든 것은 표준 Postgres이며 당신이 예상하는 대로 정확하게 동작할 것입니다.

참고 문헌

참고 문헌

1. "Lakebase — Lakehouse에서의 서버리스 Postgres." Databricks — https://www.databricks.com/product/lakebase
2. "Genie ZeroOps 소개." Databricks Blog — https://www.databricks.com/blog/introducing-genie-zeroops
3. Marattha, P. "Databricks Data + AI Summit 2026 요약: Genie One, LTAP, Lakehouse//RT 및 주요 발표." Flexera Blog, 2026년 6월 30일 — https://www.flexera.com/blog/perspectives/databricks-data-ai-summit-2026/
4. "Databricks, 최초의 Lake 트랜잭션/분석 처리 아키텍처인 LTAP 출시." Databricks Newsroom — https://www.databricks.com/company/newsroom/press-releases/databricks-launches-ltap-first-lake-transactionalanalytical
5. "Databricks Sandbox — 서버리스 컴퓨팅 문서." Databricks Docs — https://docs.databricks.com/aws/en/compute/serverless/sandbox
6. "Genie One, Genie Ontology, 및 Genie Agents 소개." Databricks Blog — https://www.databricks.com/blog/introducing-genie-one-genie-ontology-and-genie-agents