데이터브릭스, CI/CD 테스트를 위한 레이크베이스 브랜칭 기능 공개
데이터브릭스는 자사의 레이크베이스(Lakebase) 포스트그레SQL 데이터베이스가 제공하는 복제-쓰기(copy-on-write) 분기 기능이 고객사인 스노클 AI(Snorkel AI)의 CI/CD 데이터베이스 프로비저닝 시간을 30분 이상에서 60초 미만으로 줄였다고 설명했다.
한 줄 답
데이터브릭스는 CI/CD를 위한 Lakebase 데이터베이스 브랜칭과 관련해 무엇을 발표했는가?
데이터브릭스는 서버리스 포스트그레스 데이터베이스인 레이크베이스(Lakebase)가 복사 후 쓰기(copy-on-write) 방식의 브랜칭 기술을 사용해, CI/CD 풀 리퀘스트마다 프로덕션 데이터의 독립적인 쓰기 가능 복제본을 30분 이상이 아닌 60초 이내에 생성한다고 밝혔다. 고객사인 스노클 AI(Snorkel AI)가 약 2.5테라바이트 규모의 데이터셋에서 동시에 약 100개의 브랜치를 운영하는 사례 연구가 이를 보여준다.
핵심 요약
- 데이터브릭스에 따르면, Lakebase의 복제 후 쓰기(copy-on-write) 브랜칭 기능을 통해 고객사인 스노클 AI는 CI/CD 풀 리퀘스트를 위한 데이터베이스 프로비저닝 시간을 30분 이상에서 60초 이내로 단축할 수 있었다.
- 블로그 게시물에 따르면, 스노클 AI(Snorkel AI)는 약 2.5테라바이트 규모의 프로덕션 데이터셋에서 동시에 약 100개의 풀 리퀘스트 브랜치를 운영하며, 각 브랜치는 자체 변경 사항으로 5~10기가바이트의 저장 공간만 추가로 사용한다.
- 데이터브릭스는 브랜치가 비공개 네트워킹, 개발자용 오크타(Okta) 단일 로그인, 서비스 프린시펄로 실행되는 CI 파이프라인용 단기 OAuth 토큰을 통해 운영 데이터를 안전하게 보호한다고 밝혔다.
- 브랜치 만료 설정은 더 이상 필요하지 않은 풀 리퀘스트 브랜치를 자동으로 삭제하며, Databricks에 따르면 이를 통해 스토리지 비용을 프로덕션과 활성 브랜치를 합한 규모에 가깝게 유지할 수 있다.
- 데이터브릭스는 동일한 브랜칭 방식을 통해 개별 AI 에이전트 작업마다 독립적이고 필요에 따라 폐기할 수 있는 데이터베이스 복제본을 부여할 수 있다고 밝혔다.
문제
AI 팀을 위한 데이터 개발 도구를 만드는 기업 스노클 AI(Snorkel AI)는 쿠버네티스 기반으로 CI/CD 파이프라인을 운영하며, 열려 있는 풀 리퀘스트마다 테스트용 임시 네임스페이스를 하나씩 할당한다. 데이터브릭스에 따르면 스노클은 실제 운영 데이터베이스인 아마존 오로라(Aurora) PostgreSQL 클러스터의 데이터를 가지고 코드를 테스트하고자 했지만, 환경 하나당 전체 데이터베이스를 복원하는 데 약 20분이 걸렸다. 데이터브릭스는 개발자들이 하루 종일 풀 리퀘스트를 여는 업무 흐름에서는 이 정도 속도가 너무 느려서, 스노클은 그동안 모든 풀 리퀘스트에 전용 데이터베이스 복사본을 제공할 수 없었다고 설명한다.
레이크베이스 브랜칭 방식
데이터브릭스는 자사의 서버리스 Postgres 데이터베이스인 레이크베이스(Lakebase)를 통해 스노클이 깃(Git) 브랜치와 비슷한 방식으로, 특정 시점을 기준으로 격리된 쓰기 가능한 데이터베이스 브랜치를 새로 만들 수 있게 됐다고 밝혔다. 데이터브릭스는 이러한 브랜치를 '카피 온 라이트(copy-on-write)' 방식이라고 설명하는데, 이는 브랜치를 생성할 때 데이터를 복사하지 않는다는 의미다. 대신 새 브랜치는 부모 브랜치와 저장소 페이지를 공유하며, 브랜치에서 변경되는 페이지만 새로운 저장소 공간에 기록된다. 블로그 게시물에 따르면 스노클은 AWS 데이터베이스 마이그레이션 서비스(Database Migration Service)를 이용해 오로라 운영 데이터베이스를 레이크베이스의 "메인(main)" 브랜치로 복제했으며, 지속적인 변경 데이터 캡처(change data capture)를 통해 운영 환경과의 시차를 약 2분 이내로 유지했다. 데이터브릭스는 스노클의 CI 파이프라인이 풀 리퀘스트가 열릴 때마다 레이크베이스 API를 호출해 메인 브랜치에서 새 브랜치를 생성하고, 해당 브랜치에 만료 시간을 설정한 뒤 풀 리퀘스트가 닫히면 이를 삭제한다고 설명했다. 이 정리 단계가 실행되지 않을 경우에도, 데이터브릭스에 따르면 브랜치는 설정된 TTL(time-to-live)이 만료되면 자동으로 사라진다.
보안 통제
데이터브릭스에 따르면 운영 데이터는 퍼블릭 인터넷이 아닌 사설 네트워크를 통해 오로라, 레이크베이스, 스노클의 CI 클러스터 사이를 이동한다. 회사 측 설명에 따르면 스노클의 개발자들은 데이터브릭스 계정에 연동된 옥타(Okta) 싱글 사인온(SSO)으로 인증하며, CI 파이프라인은 데이터브릭스 서비스 프린시펄(service principal)로 실행되어 데이터브릭스 SDK를 통해 단기 OAuth 토큰을 발급받는다. 데이터브릭스는 Postgres 감사 로그가 모든 쿼리 뒤에 있는 서비스 프린시펄의 신원을 기록하기 때문에, 각 쿼리를 실행한 파이프라인까지 추적할 수 있다고 설명했다.
데이터브릭스가 밝힌 결과
데이터브릭스에 따르면 레이크베이스 브랜칭을 도입한 뒤 스노클의 데이터베이스 준비 시간은 30분 이상에서 60초 이내로 줄었으며, 이 시스템은 약 2.5테라바이트 규모의 운영 데이터셋을 기준으로 동시에 약 100개의 풀 리퀘스트 브랜치를 지원하도록 설계됐다. 블로그 게시물에 따르면 풀 리퀘스트 브랜치 하나당 공유 기본 데이터 위에 약 5~10기가바이트의 변경 사항이 추가로 기록되며, 스노클은 이 시스템을 여러 팀에 걸친 60~70명의 개발자에게 도입했다. 데이터브릭스는 이름을 밝히지 않은 스노클 개발자의 말을 인용해, 기존 데이터 복사 작업은 "몇 시간씩 걸렸고 다양한 CI 플랫폼에서 네트워크 등 여러 병목 현상에 자주 부딥혔다"고 전했으며, 팀은 가상 프라이빗 클라우드(VPC) 밖으로 나가는 데이터에 대한 보안 및 컴플라이언스 요건을 충족하는 해법이 필요했다고 덧붙였다.
CI/CD를 넘어선 활용
데이터브릭스는 같은 브랜칭 방식이 SQL을 작성하거나 마이그레이션을 실행하거나 데이터를 변경하는 AI 에이전트에도 적용될 수 있다고 밝혔다. 각 에이전트 작업에 메인 데이터베이스의 전용 브랜치를 할당해, 운영 환경이나 다른 에이전트의 작업에 영향을 주지 않으면서 데이터를 읽고 쓸 수 있게 하는 방식이다. 회사에 따르면 에이전트는 단기 OAuth 토큰을 지닌 서비스 프린시펄로 실행될 수 있으며, 에이전트의 변경 사항이 바람직하지 않을 경우 브랜치를 검토 후 삭제하거나, 만료 설정을 통해 자동으로 정리할 수 있다.
출처: 데이터브릭스 블로그, "CI/CD를 위한 레이크베이스 브랜칭: 100개 PR 데이터베이스에서 얻은 교훈(Lakebase branching for CI/CD: lessons from 100 PR databases)", 2026년 10월 31일 게시.
자주 묻는 질문
- Lakebase 브랜칭이란 무엇인가?
- 데이터브릭스에 따르면 레이크베이스 브랜칭(Lakebase branching)은 복제 온 라이트(copy-on-write) 스토리지를 이용해 특정 시점의 포스트그레스(Postgres) 데이터베이스를 격리된 쓰기 가능 복사본으로 생성할 수 있는 기능으로, 깃(Git) 브랜치를 만드는 것과 유사한 방식이다.
- Snorkel AI는 Lakebase 브랜칭을 어떻게 활용했을까요?
- Databricks에 따르면 스노클 AI(Snorkel AI)는 열려 있는 모든 풀 리퀘스트마다 프로덕션용 오로라(Aurora) PostgreSQL 데이터베이스의 전용 Lakebase 브랜치를 생성해 CI/CD 테스트에 활용하고 있으며, 이를 통해 환경당 30분 이상 걸리던 기존 프로세스를 대체했다.
- 데이터브릭스는 레이크베이스의 브랜칭 기능이 비용 절감에 어떻게 도움이 된다고 설명하나요?
- 데이터브릭스에 따르면 복제 없이 쓰기 시점에만 데이터를 복사하는 '카피온라이트(copy-on-write)' 저장 방식을 적용해, 브랜치는 변경된 데이터에 대해서만 추가 저장 공간을 사용하며, 각 브랜치의 컴퓨팅 자원은 유휴 상태일 때 0으로 줄어든다.
- Lakebase 브랜칭을 CI/CD 외의 용도로도 사용할 수 있나요?
- 데이터브릭스는 동일한 브랜칭 방식이 AI 에이전트에도 그대로 적용된다고 설명한다. 각 에이전트 작업마다 별도의 임시 데이터베이스 브랜치를 부여해, 프로덕션에 영향을 주지 않고 데이터를 읽고 쓰고 변경 사항을 테스트할 수 있게 하는 방식이다.