Databricks, 병렬 코딩 에이전트를 위한 Lakebase 브랜칭 상세

Databricks는 2026년 10월 8일에 블로그 게시물을 공개했으며, 여기서는 모든 병렬 코딩 에이전트와 모든 풀 리퀘스트가 자체 격리된 일시적인 Postgres 데이터베이스에서 실행되는 개발 워크플로우를 상세히 설명합니다. 이 데이터베이스는 Lakebase 데이터베이스 서비스에 내장된 복사-쓰기 브랜칭을 통해 생성됩니다.

이 게시물에서 Databricks는 데이터베이스가 개발 워크플로우에서 종종 간과되는 부분이며, 코딩 에이전트가 개발 작업의 점점 더 큰 비중을 차지하고 병렬로 여러 에이전트를 실행하는 것이 일반화되고 있는 시점이라고 설명합니다. 전통적인 공유 환경(예: 단일 개발 또는 스테이징 데이터베이스)에서는 동시에 실행되는 에이전트들이 스키마 변경으로 충돌하거나 서로 방해하고, 실제 데이터를 반영하지 않는 모크(mock)로 대체될 수 있습니다. 이러한 문제는 이미 개발자들에게 고충이었지만, 게시물에 따르면 에이전트는 더 빠르게 움직이고 병렬로 동작하며, 프로덕션 데이터를 위험에 빠뜨리거나 민감한 데이터를 노출시키지 않는 안전한 환경이 필요하기 때문에 이러한 문제를 더욱 악화시킨다고 합니다.

브랜칭 메커니즘

Databricks에 따르면 Lakebase 브랜칭을 사용하면 사용자가 전체 데이터베이스를 크기에 관계없이 1초 미만에 브랜치할 수 있습니다. 브랜치는 복사-쓰기 스토리지를 기반으로 하며, 새로운 브랜치는 부모의 스키마와 데이터를 상속하면서 기본 스토리지를 공유하고, 분기될 때만 추가 스토리지를 사용합니다. Databricks의 Lakebase 브랜칭 문서에 따르면 각 프로젝트는 기본 브랜치인 production으로 생성되며, 루트 브랜치를 제외한 모든 브랜치는 부모를 가집니다. 자식 브랜치에서의 변경은 부모에 영향을 주지 않으며, 이러한 격리는 Postgres 역할 상태까지 확장됩니다: 역할 및 데이터베이스 생성, GRANT 및 REVOKE 적용, 그리고 한 브랜치에서 수정된 역할 속성은 다른 브랜치에 영향을 미치지 않습니다.

문서에 따르면 각 브랜치는 자체 컴퓨트를 보유하며, 유휴 상태일 때는 0으로 스케일 다운되고, 활성 컴퓨트 시간에 대해서만 비용이 청구됩니다. 스토리지 청구는 브랜치의 만료 여부에 따라 달라집니다: 만료되는 브랜치는 변경된 데이터에 대해서만 비용이 청구되고, 만료되지 않는 영구 브랜치는 독립 데이터베이스와 같이 전체 데이터 크기에 대해 청구됩니다. 브랜치 리셋은 자식 브랜치를 부모로부터 새로 고치는 작업으로, 부모에서 자식으로만 한 방향으로 작동합니다. 시점 복구는 복구 창 내의 과거 데이터를 사용해 새로운 루트 브랜치를 생성하며, 원래 브랜치는 변경되지 않고 그대로 운영됩니다.

제품 페이지에서 Databricks는 Lakebase를 오픈소스 Postgres 엔진을 그대로 실행하는 완전 관리형 서버리스 Postgres 서비스라고 설명합니다.

에이전트당 하나의 브랜치

게시물의 워크플로우는 Git 워크트리를 Lakebase 브랜치와 결합합니다. 워크트리는 각 에이전트에게 자체 디렉터리와 체크아웃된 브랜치를 제공하여 에이전트 간 파일 수준 충돌을 제거하고, 체크아웃 후 후크가 각 새로운 워크트리에 대해 자동으로 데이터베이스 브랜치를 생성합니다. 예시에서는 Claude Code를 사용해 구축되었으며, 에이전트는 실행합니다 claude -worktree feature-123, Git이 워크트리를 생성하고, 후크가 실행되며, 에이전트는 자체 코드 디렉터리와 완전히 격리된 데이터베이스를 얻게 됩니다. AGENTS.md 또는 CLAUDE.md와 같은 리포지토리 지시 파일은 에이전트 동작을 안내하고, 에이전트가 작업을 마치면 풀 리퀘스트를 열며, 이후 워크트리와 데이터베이스 브랜치를 모두 폐기할 수 있습니다.

게시물에 따르면 Git과의 한 차이점은 Lakebase 브랜치는 메인 브랜치로 병합되지 않는다는 것입니다. 이는 부모와 자식이 독립적으로 변경될 수 있어 데이터를 조정하는 것이 곧 실용적이지 않게 되기 때문입니다. 대신 스키마 변경은 애플리케이션 로직과 함께 코드에서 추적되고, Drizzle, Flyway, Liquibase, Alembic 등의 마이그레이션 도구를 사용해 마이그레이션을 통해 부모 브랜치로 승격됩니다. 예시에서는 Drizzle을 사용합니다: 스키마 변경이 필요하면 에이전트가 해당 마이그레이션을 코드베이스에 추가하고, 배포 자동화가 프리뷰 애플리케이션을 배포할 때와 변경이 메인에 병합될 때 적용합니다.

풀 리퀘스트당 하나의 브랜치

지속적 통합을 위해 게시물은 GitHub Actions 워크플로우를 제시합니다. 여기서 main에 대한 풀 리퀘스트를 열면 Lakebase CLI가 해당 풀 리퀘스트 이름을 딴 일시적인 브랜치를 생성하고, 이는 production 브랜치의 자식이 되며, 해당 브랜치는 풀 리퀘스트의 데이터베이스 환경이 됩니다. 마이그레이션 도구가 새 브랜치에서 실행되고, 프리뷰 애플리케이션이 배포되어 브랜치의 연결 문자열을 가리키며, 스키마 차이점이 생성되어 풀 리퀘스트 댓글로 정확히 어떤 테이블, 컬럼, 인덱스가 변경되었는지 표시됩니다. 풀 리퀘스트가 닫히거나 병합되면 자동화가 브랜치를 삭제합니다. 브랜치가 production에서 시작되기 때문에 스키마 마이그레이션을 적용하고 테스트할 수 있어 변경이 production에 도달하기 전에 검증할 수 있습니다. 예시에서는 Databricks Apps에 프리뷰를 배포하지만, 게시물에 따르면 이 개념은 Vercel, Netlify, Cloudflare와 같은 다른 호스팅 플랫폼에도 적용됩니다.

환경에 대해 게시물은 일반적인 Lakebase 설정이 개발, 스테이징, 프로덕션 등 각 환경마다 하나의 Databricks 워크스페이스를 사용하며, 팀들은 보통 프로덕션 데이터베이스 대신 시드된 데이터베이스에서 브랜치를 생성해 PII와 같은 민감한 데이터 노출을 방지한다고 언급합니다. 이 walkthrough는 단순성을 위해 단일 워크스페이스를 사용하지만, 동일한 개념이 다중 워크스페이스 설정에도 적용된다고 명시합니다.

버그 재현 및 마이그레이션 테스트

에이전트별 및 풀 리퀘스트별 루프를 넘어, 이 게시물은 예시 저장소에 구현되지 않은 브랜칭 워크플로우를 설명합니다. 개발자는 버그가 발생하기 직전과 같은 특정 시점에 프로덕션에서 격리된 브랜치를 생성하여 실제 데이터를 기반으로 문제를 재현하고 조사할 수 있으며, 수정이 검증되면 해당 브랜치를 종료합니다. 팀은 프로덕션에 배포하기 전에 브랜치를 만들고, 스키마 마이그레이션을 적용한 뒤 테스트를 실행하여 변경 사항을 승격하기 전에 애플리케이션이 기대대로 동작하는지 확인할 수도 있습니다. 이러한 워크플로우를 통해 개발자는 Unity Catalog 마스킹 등을 활용해 실시간 데이터베이스를 위험에 빠뜨리지 않고도 프로덕션과 유사하거나 프로덕션에서 파생된 데이터를 사용할 수 있다고 게시물은 말합니다.

이 게시물은 databricks/tmm 저장소의 Lakebase-Agentic-CI 디렉터리에 있는 예시 저장소(GitHub)로 연결되며, 해당 패턴을 구현한 GitHub Actions 워크플로우 예제가 포함되어 있습니다. 그리고 이러한 패턴이 결합되어 저자가 ‘Lakebase 개발 루프’라고 부르는, 에이전트당 브랜치, 풀 리퀘스트당 브랜치, 그리고 프로덕션 검증을 위한 격리 브랜치를 형성한다는 결론을 내립니다.