데이터베이스 브랜칭: 개발자를 위한 Git 스타일 워크플로우 가이드

Git은 소프트웨어 팀의 격리된 개발 환경을 기본 표준으로 만들었습니다. 개발자는 각자 브랜치를 생성하여 독립적으로 작업하고, 준비가 되면 변경 사항을 병합할 수 있습니다.

데이터베이스 브랜칭(Database branching)은 이와 동일한 격리성을 데이터베이스에 제공합니다. 이를 통해 개발자, 지속적 통합(CI) 작업, AI 에이전트는 공유된 데이터베이스 상태에서 격리된 데이터베이스 환경을 생성하고, 상위 데이터베이스나 서로에게 영향을 주지 않고 변경 작업을 수행할 수 있습니다.

즉, 공유 환경을 기다리는 시간이 줄어들고, 다른 사람의 변경 사항으로 인한 테스트 실패가 감소하며, 스키마 마이그레이션에 대한 피드백을 더 빠르게 받을 수 있습니다. 문제가 발생하면 공유 데이터베이스를 복구하거나 복원하는 대신 해당 브랜치를 그냥 버리면 됩니다.

TL;DR

• 데이터베이스 브랜칭은 전체 데이터베이스를 복사하지 않고도 격리된 환경을 생성합니다. 이는 변경되지 않은 데이터를 공유하고 변경된 내용만 저장하는 Copy-on-write 방식을 통해 가능해집니다.
• 데이터베이스 브랜칭은 AI 에이전트에게 점점 더 중요해지고 있습니다. 에이전트가 상위 데이터베이스를 위험에 빠뜨리지 않고 변경 사항을 테스트하고 실험할 수 있는 격리된 환경을 제공합니다.
• 데이터베이스 브랜치를 안전하게 운영하려면 명확한 제어가 필요합니다. 상위 브랜치를 보호하고, 민감한 데이터에 대한 액세스를 제한하며, 정리를 자동화하고, 일회성 환경을 재현 가능하게 유지해야 합니다.

What Is Database Branching?

데이터베이스 브랜칭은 특정 시점의 다른 데이터베이스 상태를 기반으로 격리된 데이터베이스 환경을 제공합니다. 브랜치는 상위 데이터베이스의 스키마 및 데이터로 시작하지만, 브랜치에서 수행한 변경 사항은 상위 브랜치나 다른 형제 브랜치에 영향을 미치지 않습니다.

Git에 익숙하다면 기본적인 개념이 친숙하게 느껴질 것입니다. 코드 브랜치가 알려진 커밋으로부터 개인적인 개발 라인을 제공하는 것처럼, 데이터베이스 브랜치는 알려진 데이터베이스 상태로부터 격리된 데이터베이스 환경을 제공합니다.

한 가지 중요한 차이점은 일반적으로 데이터베이스 브랜치의 변경 사항을 상위 데이터베이스로 다시 병합하지 않는다는 것입니다. 대신 마이그레이션 파일이 지속적인 단일 진실 공급원(source of truth)으로 유지됩니다. 브랜치에서 마이그레이션을 테스트하여 실제 데이터에 대해 제대로 작동하는지 확인한 다음, 배포 파이프라인이 동일한 마이그레이션을 대상 데이터베이스에 적용하도록 할 수 있습니다. 이러한 방식으로 데이터베이스 브랜칭은 프로덕션 규모의 데이터를 다룰 때도 점진적 데이터베이스 설계(evolutionary database design), 개발자별 데이터베이스 환경, 버전 관리 마이그레이션과 같이 오랫동안 지속되어 온 관행들을 실용적으로 만들어 줍니다.

위에서 볼 수 있듯이, 상위 데이터베이스는 여러 격리된 브랜치에 알려진 스키마와 데이터를 제공합니다. 개발자 브랜치를 사용하여 변경 사항을 수정 및 테스트하거나, PR 브랜치를 사용하여 마이그레이션 및 CI를 실행하거나, 에이전트 브랜치를 사용하여 변경 사항을 탐색하고 평가할 수 있습니다. 작업이 완료되면 상위 데이터베이스나 다른 브랜치에 영향을 주지 않고 각 브랜치를 재설정, 삭제 또는 정리(prune)할 수 있습니다. 데이터베이스 브랜칭은 Copy-on-write를 통해 이러한 수준의 격리를 가능하게 합니다.

How Copy-on-Write Database Branching Works

Copy-on-write (CoW)는 데이터베이스의 사전 전체 복사를 피함으로써 데이터베이스 브랜칭을 실용적으로 만듭니다. 브랜치를 생성하면 처음에는 데이터를 복제하는 대신 상위 데이터베이스의 기존 데이터를 공유합니다. 둘 다 동일한 기본 데이터를 읽을 수 있으며, 한쪽에서 수행한 변경 사항은 다른 쪽에 격리된 상태로 유지됩니다. 하지만 브랜치에서 데이터를 수정하면 스토리지 레이어는 해당 브랜치에 대해 영향을 받는 데이터의 새 버전을 생성하고, 변경되지 않은 데이터는 상위 데이터베이스와 계속 공유됩니다.

Lakebase는 이러한 Copy-on-write 방식을 사용하여 전체 상위 데이터베이스를 복제하지 않고 데이터베이스 브랜치를 생성합니다. 결과적으로 각 브랜치는 상위 데이터베이스와 달라지는 데이터에 대해서만 추가 스토리지를 필요로 합니다.

40 GB 데이터베이스를 예로 들어 보겠습니다. 기존의 전체 복사 방식을 사용하면 개발자 브랜치와 PR 브랜치를 생성하는 데 추가로 80 GB의 스토리지가 필요합니다. 하지만 Copy-on-write 방식을 사용하면 두 브랜치 모두 처음에는 상위 데이터베이스의 데이터를 공유하며, 서로 달라지는 시점에만 추가 스토리지를 소비합니다.

위 다이어그램에서 볼 수 있듯이, 개발자 브랜치의 변경 사항이 1.6 MB에 불과하고 PR 브랜치의 변경 사항이 4 MB에 불과하다면, 두 브랜치가 추가하는 스토리지는 약 5.6 MB에 그칩니다. 기존의 복사 방식은 각 브랜치마다 전체 데이터베이스를 복제하는 반면, Copy-on-write 브랜치는 변경되지 않은 데이터를 공유하고 변경된 사항만 저장합니다.

브랜치가 생성된 후 상위 데이터베이스가 변경될 때도 동일한 원칙이 적용됩니다. 브랜치는 변경되지 않은 데이터의 원본 버전을 계속 참조하는 반면, 상위 데이터베이스는 수정하는 페이지의 새 버전을 기록합니다. 이를 통해 두 브랜치는 변경되지 않은 데이터를 복제하지 않고도 독립적으로 변경될 수 있습니다.

What Database Branching Makes Possible

데이터베이스 브랜칭을 도입하면 여러 개발 워크플로우를 훨씬 쉽게 구현할 수 있습니다.

Production-like baselines

보호된 프로덕션 스냅샷에서 데이터베이스 브랜치를 생성할 수 있으므로, 모든 개발자와 CI 작업이 동일한 알려진 상태에서 시작할 수 있습니다. 이를 통해 비어 있는 로컬 데이터베이스나 오래된 스테이징 환경 대신, 실제 데이터, 기존 제약 조건 및 프로덕션 규모의 테이블을 대상으로 마이그레이션을 테스트할 수 있습니다.

예를 들어, ALTER TABLE orders ADD COLUMN customer_id UUID NOT NULL와 같은 마이그레이션은 비어 있는 데이터베이스에서는 작동할 수 있지만 수백만 개의 기존 주문 데이터에 대해서는 실패할 수 있습니다. 프로덕션과 유사한 브랜치에서 이를 테스트하면 마이그레이션이 스테이징이나 프로덕션에 도달하기 전에 문제를 발견할 수 있습니다. 브랜치가 오래되면 이를 삭제하고 동일한 베이스라인에서 새로운 브랜치를 생성하면 됩니다.

Per-PR isolation

모든 PR에 고유한 데이터베이스 환경을 제공할 수 있습니다. PR이 열리면 CI가 브랜치를 생성하고, 제안된 마이그레이션을 적용한 다음, 이에 대해 통합 테스트를 실행합니다. PR이 닫히면 파이프라인이 브랜치를 삭제합니다.

즉, 두 명의 개발자가 서로의 테스트에 영향을 주지 않고 충돌하는 스키마 변경을 수행할 수 있습니다. 열을 추가하거나, 제약 조건을 변경하거나, 인덱스를 수정하는 PR은 자체 데이터베이스 상태를 갖게 되므로, CI는 다른 개발자가 스테이징에서 수행 중인 작업과 상관없이 격리된 상태에서 변경 사항을 테스트합니다.

Easier failure recovery

브랜치를 사용하면 실패한 마이그레이션과 실험을 더 쉽게 격리할 수 있습니다. 백필(backfill)이 예상치 못한 결과를 초래하거나, 테스트로 인해 데이터가 손상되거나, 마이그레이션으로 인해 브랜치 상태가 손상된 경우, 오염된 개발 환경에서 계속 작업하는 대신 영향을 받은 브랜치를 폐기하고 상위 브랜치에서 새로운 브랜치를 생성할 수 있습니다.

예를 들어, 브랜치에서 DELETE FROM orders WHERE created_at < ...와 같은 파괴적인 작업을 안전하게 테스트하고, 결과를 검사한 다음, 완료되면 브랜치를 폐기할 수 있습니다. 이 과정 동안 상위 데이터베이스는 전혀 영향을 받지 않습니다.

개발자와 DevOps 팀에게 이러한 이점은 이미 충분히 매력적입니다. 하지만 AI 에이전트를 구축하거나 운영하는 경우, 데이터베이스 브랜칭은 완전히 다른 규모로 중요해집니다.

Why AI Agents Make Branching Infrastructure-Critical

AI 에이전트는 작업에 대한 다양한 접근 방식을 테스트하기 위해 자체 데이터베이스 환경이 필요할 수 있습니다. 각 접근 방식에 대한 브랜치를 생성하고, 결과를 비교한 다음, 필요하지 않은 브랜치는 폐기할 수 있습니다. 수많은 에이전트 플릿 전체에서 이는 수백 또는 수천 개의 수명이 짧은 환경이 동시에 실행됨을 의미할 수 있습니다.

이러한 규모에서는 전체 데이터베이스 복사본을 프로비저닝하는 데 비용이 많이 들고 속도가 느려집니다. 데이터베이스 브랜칭은 이러한 오버헤드를 방지하여 에이전트가 작업하면서 환경을 실용적으로 생성하고 폐기할 수 있도록 합니다.

또한 브랜칭은 에이전트에게 변경 사항을 테스트할 수 있는 격리된 환경을 제공함으로써 에이전트의 실수로 인한 피해 범위를 줄일 수 있습니다. 에이전트에게 프로덕션 데이터베이스에 대한 쓰기 권한을 부여하는 대신, 상위 데이터베이스에 영향을 주지 않고 파괴적인 작업을 테스트할 수 있는 브랜치에 대한 액세스 권한을 부여할 수 있습니다.

How to Operate Database Branches Safely

데이터베이스 브랜치는 일회성 환경으로 취급하고 수명 주기를 자동화할 때 가장 쉽게 관리할 수 있습니다. 다음과 같은 몇 가지 방안을 통해 워크플로우를 안전하고 예측 가능하게 유지할 수 있습니다.

• 프로덕션 및 상위 브랜치 보호: 프로덕션 및 기타 중요한 상위 브랜치에 쓰기, 재설정 또는 삭제를 수행할 수 있는 권한을 제한합니다. 에이전트와 개발자는 대신 하위 브랜치에서 작업해야 합니다.
• 임시 브랜치에 안전한 데이터 사용: 필수적이고 적절하게 보호되지 않는 한, 민감한 프로덕션 데이터를 수명이 짧은 개발 또는 에이전트 브랜치로 복사하지 마세요. 가능한 경우 모크(mock) 데이터를 사용하여 일회성 환경이 프로덕션 정보를 노출하는 경로가 되지 않도록 하세요.
• 브랜치에 수명 주기(TTL) 설정: 수명이 짧은 브랜치에 만료 시간을 부여하여 방치된 PR, 실패한 CI 실행, 종료된 에이전트 작업으로 인해 환경이 무기한 실행되는 것을 방지하세요.
• 마이그레이션을 단일 진실 공급원(source of truth)으로 유지: 마이그레이션 파일을 단일 진실 공급원으로 취급하세요. 브랜치에서 직접 변경한 내용을 그대로 반영하기보다, 브랜치에서 마이그레이션을 테스트하고 버전 제어 시스템에서 검토한 후 승인된 마이그레이션을 대상 데이터베이스에 적용하세요.
• 재현 가능한 환경 구축: 브랜치를 수동 복구가 필요한 장기 실행 환경이 아닌 일회용 환경으로 취급하세요. 환경을 재구성하는 데 필요한 설정을 버전 제어 시스템에 보관하여, 오래되거나 손상된 브랜치를 삭제하고 상위 브랜치에서 다시 생성할 수 있도록 하세요.
• 액세스 및 리소스 사용 제어: 개발자와 에이전트에게 필요한 권한만 부여하고 브랜치 수명, 컴퓨팅, 스토리지, 활성 환경 수를 모니터링하세요. Unity Catalog와 같은 도구를 사용하여 이러한 환경 내에서 사용할 수 있는 데이터에 대한 액세스를 제어하세요.

이러한 가드레일을 마련하면 팀은 개발, 지속적 통합 및 지속적 배포(CI/CD), 에이전트 워크플로 전반에서 데이터베이스 브랜치를 일회용 환경으로 사용할 수 있습니다. 각 브랜치는 변경 사항을 테스트하기 위한 격리된 환경을 제공하며, 작업이 완료되면 자동으로 제거될 수 있습니다.

요약

데이터베이스 브랜칭은 전체 복사본을 만드는 비용과 오버헤드 없이 격리된 데이터베이스 환경을 생성할 수 있는 실용적인 방법을 제공합니다. 브랜치를 사용하여 실제 데이터에 대해 마이그레이션을 테스트하고, 모든 풀 요청에 고유한 데이터베이스를 부여하고, 실패한 실험을 복구하고, 데이터베이스 기반 워크로드를 병렬로 실행할 수 있습니다.

풀 요청당 하나의 브랜치와 같은 간단한 워크플로로 시작하여 생성 및 정리를 자동화하세요. 거기서부터 필요에 따라 개발자 환경 및 에이전트 워크로드로 브랜칭을 확장할 수 있습니다. 시작할 준비가 되셨나요? Databricks Lakebase로 데이터베이스 브랜칭을 살펴보거나, Postgres에서 데이터베이스 브랜칭을 구현하기 위한 실습 튜토리얼을 따라해 보세요.

자주 묻는 질문

데이터베이스 브랜칭이란 무엇인가요?

데이터베이스 브랜칭은 특정 시점의 상위 데이터베이스로부터 격리된 데이터베이스 환경을 생성합니다. 브랜치는 상위 데이터베이스의 스키마와 데이터로 시작하지만, 브랜치에 적용된 변경 사항은 격리된 상태로 유지됩니다. copy-on-write 방식을 사용하면 브랜치가 상위 데이터베이스와 변경되지 않은 데이터를 공유하므로 빠르게 생성하고 비용 부담 없이 폐기할 수 있습니다.

데이터베이스 브랜칭은 Git 브랜칭과 어떻게 다른가요?

개념은 비슷합니다. 둘 다 알려진 상태에서 격리된 환경을 생성하고 원본에 영향을 주지 않고 변경할 수 있도록 합니다. Git 브랜치는 소스 코드를 격리하는 반면, 데이터베이스 브랜치는 데이터베이스 스키마와 데이터를 격리합니다.

그 이후의 워크플로는 다릅니다. Git 브랜치는 일반적으로 메인 브랜치로 다시 병합되지만, 데이터베이스 브랜치는 보통 그렇지 않습니다. 대신 데이터베이스 브랜치에서 마이그레이션을 테스트한 다음, 배포 프로세스를 통해 검토된 마이그레이션을 대상 데이터베이스에 적용합니다.

데이터베이스 브랜칭의 목적은 무엇인가요?

데이터베이스 브랜칭은 개발자, CI 작업, AI 에이전트에게 프로덕션이나 다른 워크로드에 영향을 주지 않고 변경 사항을 테스트할 수 있는 격리된 환경을 제공합니다. 브랜치를 사용하여 실제 데이터에 대해 마이그레이션을 테스트하고, PR별 환경을 생성하고, 실패한 실험을 복구하고, 여러 데이터베이스 기반 워크로드를 병렬로 실행할 수 있습니다.

데이터베이스 브랜칭의 두 가지 유형은 무엇인가요?

두 가지 일반적인 접근 방식은 full-copy 브랜칭과 copy-on-write 브랜칭입니다. full-copy 브랜칭은 각 브랜치에 대해 데이터베이스를 복제하므로 데이터베이스 크기에 따라 생성 시간과 스토리지 요구 사항이 늘어납니다. copy-on-write 브랜칭은 상위 데이터베이스와 변경되지 않은 데이터를 공유하고 각 브랜치에 대한 변경 사항만 저장합니다.

어떤 유형의 데이터베이스가 브랜칭을 지원하나요?

브랜칭은 데이터 모델보다는 데이터베이스의 스토리지 아키텍처에 더 많이 의존합니다. 관계형, 문서형, 키-값, 그래프 데이터베이스 모두 이론적으로 브랜칭을 지원할 수 있지만, 구현 방식과 기능은 플랫폼에 따라 다릅니다.

데이터베이스 브랜칭은 어떻게 구현하나요?

구현은 데이터베이스 플랫폼과 스토리지 아키텍처에 따라 다릅니다. 일반적으로 상위 데이터베이스와 알려진 데이터베이스 상태에서 격리된 브랜치를 생성하는 방법이 필요합니다. Databricks Lakebase는 개발, CI, 에이전트 워크플로를 위한 데이터베이스 브랜칭을 제공하며, 필요에 따라 브랜치를 생성하고 제거할 수 있습니다. 실제 구현 방법은 Databricks 브랜치 기반 개발 튜토리얼을 참조하세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)