Lakebase 및 에이전틱 SDLC: 코딩 에이전트를 위한 데이터베이스 브랜칭

AI는 소프트웨어가 구축되는 방식을 바꾸었습니다. 코딩 에이전트가 개발 작업에서 차지하는 비중이 늘어남에 따라 개발자들은 점점 더 이들을 오케스트레이션하는 방향으로 전환하고 있습니다. 여러 에이전트를 병렬로 실행하는 것이 대세가 되고 있으며, 이에 맞춰 스킬과 훅(hook)부터 MCP, 서브 에이전트에 이르기까지 에이전트를 더 안전하고 효과적으로 만들기 위해 도구도 함께 발전했습니다.

하지만 개발 워크플로에서 핵심적인 요소 중 하나인 데이터베이스는 여전히 간과되는 경우가 많습니다.

동시 실행되는 각 에이전트는 코드를 작성하고 스키마 변경 사항을 적용하며 데이터베이스를 대상으로 테스트를 실행해야 합니다. 기존 데이터베이스 설정에서 흔히 사용하는 단일 개발 또는 스테이징 데이터베이스와 같은 공유 환경에서는 상당한 어려움이 발생합니다. 에이전트 간에 스키마 변경 사항이 충돌하거나 서로 간섭할 수 있고, 실제 데이터를 반영하지 못하는 목(mock) 데이터로 대체될 수 있습니다. 이는 개발자에게 이미 고충이었지만 코딩 에이전트로 인해 더욱 악화되고 있습니다. 에이전트는 더 빠르게 움직이고 병렬로 작동하므로, 운영 데이터를 위험에 빠뜨리거나 민감한 데이터를 노출하지 않도록 안전한 환경이 필요합니다.

Lakebase Postgres 아키텍처는 데이터베이스 브랜칭을 통해 이 문제를 해결합니다. Git을 통해 코드를 브랜치하는 것처럼, Lakebase를 사용하면 데이터베이스 크기에 관계없이 1초 이내에 전체 데이터베이스를 브랜치할 수 있습니다. Copy-on-write 방식을 사용하므로 브랜치는 상위 브랜치 데이터를 공유하지만 변경 사항이 발생할 때만 추가 스토리지 용량을 소비합니다. 또한 스케일투제로(scale-to-zero)를 지원하여 유휴 브랜치에는 컴퓨팅 비용이 발생하지 않습니다. 이는 여러 에이전트를 동시에 실행할 때 매우 중요합니다. 각 브랜치는 완전히 격리되어 있으므로 에이전트가 마이그레이션을 적용하고 테스트를 실행한 후 작업이 끝나면 브랜치를 폐기할 수 있습니다.

이 문서에서는 코딩 에이전트를 중심으로 구축된 Lakebase 개발 루프의 엔드투엔드 워크플로를 통해 이것이 실제로 어떻게 작동하는지 보여드립니다. 다음 섹션에서 설명하는 내용을 구현하기 위한 GitHub Actions 워크플로 예시가 포함된 예시 리포지토리를 여기에서 확인할 수 있습니다.

실제 작동 모습을 확인하고 싶으신가요? 아래 비디오 시연을 시청해 보세요.

본론으로 들어가기 전에 Databricks의 환경 구성에 대해 알려드립니다. Lakebase Postgres를 사용할 때 일반적인 구성은 dev, staging, prod와 같이 환경당 하나의 Databricks 워크스페이스를 사용하는 것입니다. 단일 워크스페이스를 사용할 수도 있지만 대부분의 팀은 보안 및 규정 준수 등의 이유로 여러 워크스페이스를 활용하려고 합니다. 마찬가지로 PII와 같은 민감한 데이터의 노출을 방지하기 위해 운영 데이터베이스 대신 시드 데이터베이스에서 브랜치하는 경우도 흔합니다. 이 문서에서는 단순성을 위해 단일 워크스페이스를 사용하지만, 동일한 핵심 개념이 다중 워크스페이스 구성에도 적용되며 동일하게 쉽게 구현할 수 있습니다.

병렬 코딩 에이전트를 위한 안전하고 격리된 데이터베이스

기존 데이터베이스에서 발생하는 주요 장애 요소는 여러 코딩 에이전트가 동시에 작업할 때 발생합니다. 새로운 기능을 개발하거나 문제를 해결할 때 각 에이전트는 데이터베이스 스키마를 읽고, 변경 사항을 적용하고, 데이터를 시드하고, 테스트를 실행해야 하는 경우가 많습니다. 격리가 이루어지지 않으면 이러한 에이전트가 서로 간섭하거나 공유 데이터베이스를 손상시킬 수 있습니다. 데이터베이스 브랜칭은 각 에이전트에 격리된 환경을 제공하여 동시에 실행되는 다른 에이전트에 영향을 주지 않고 독립적으로 작업할 수 있게 해줍니다.

로컬에서 코드 충돌을 방지하는 실용적인 방법은 Git worktree를 활용하는 것입니다. worktree는 각 에이전트에 고유한 브랜치가 체크아웃된 전용 디렉터리를 제공하므로 에이전트 간 파일 수준의 충돌이 발생하지 않습니다. Git worktree는 병렬 에이전트의 코드 격리 문제를 해결합니다. Lakebase 브랜칭은 나머지 절반인 데이터베이스 격리 문제를 해결합니다. 리포지토리에 post-checkout 훅을 추가하면 각 새 worktree가 자동으로 전용 데이터베이스 브랜치를 갖게 됩니다. 개발이 완료되면 에이전트는 PR을 생성합니다. 에이전트의 동작은 AGENTS.md 또는 CLAUDE.md와 같은 리포지토리 지침 파일을 통해 가이드될 수 있습니다.

다음은 안전한 AI 개발을 위해 Claude Code, worktree 및 Lakebase 브랜칭을 사용하는 예시 워크플로입니다.

• 에이전트가 claude -worktree feature-123 명령을 실행합니다.
• Git이 feature-123 브랜치를 위한 worktree를 생성합니다.
• post-checkout 훅이 자동으로 실행되어 데이터베이스 브랜치를 생성합니다.
• 이제 에이전트는 완전히 격리된 자체 코드 디렉터리와 자체 데이터베이스를 갖게 됩니다.

작업이 완료되면 에이전트가 PR을 생성합니다. 이 동작은 리포지토리 지침 파일에 정의되어 있습니다. PR이 생성되면 worktree와 데이터베이스 브랜치를 모두 폐기할 수 있습니다. Git과의 한 가지 중요한 차이점은 Lakebase 브랜치는 메인 브랜치로 다시 머지(merge)되지 않는다는 점입니다. 상위 브랜치와 하위 브랜치가 모두 독립적으로 변경될 수 있어 데이터를 조정하는 것이 현실적으로 어려워지기 때문입니다. 대신 스키마 변경 사항은 애플리케이션 로직과 함께 코드로 추적된 후 Drizzle, Flyway, Liquibase 또는 Alembic과 같은 도구를 사용한 마이그레이션을 통해 상위 브랜치로 승격됩니다.

이 예시에서는 Drizzle을 사용합니다. 스키마 변경이 필요한 경우 에이전트는 해당 마이그레이션을 코드베이스에 추가합니다. 그런 다음 배포 자동화 시스템이 프리뷰 애플리케이션을 배포할 때, 그리고 변경 사항이 메인 브랜치에 머지될 때 해당 마이그레이션을 적용합니다.

모든 Pull Request를 위한 임시 데이터베이스

Pull Request(PR)가 생성되면 코드가 프로덕션에 적용되기 전에 실제 데이터베이스를 대상으로 코드를 자동으로 검증하고 테스트하고자 합니다.

지속적 통합(CI) 도구(이 경우 GitHub Actions)를 사용하여 운영 브랜치의 하위 브랜치로 각 PR에 대한 임시 Lakebase 브랜치를 생성합니다. 이 브랜치는 PR을 위한 데이터베이스 환경이 됩니다. 이를 대상으로 자동화된 테스트를 실행하고, 프리뷰 애플리케이션을 배포하며, 검토자가 실제 데이터베이스를 대상으로 변경 사항을 검증할 수 있습니다.

브랜치가 운영 데이터베이스에서 시작되므로 변경 사항이 프로덕션에 적용되기 전에 스키마 마이그레이션을 적용하고 테스트할 수 있습니다.

PR이 승인되고 머지되면 기능 코드와 마이그레이션 명령이 승격되고 임시 Lakebase 브랜치가 삭제됩니다.

일반적인 GitHub Actions 워크플로는 다음과 같습니다.

• main을 대상으로 PR이 오픈됩니다.
• CI가 Lakebase CLI를 호출하여 pr-123과 같은 브랜치를 생성합니다.
• 마이그레이션 도구(Drizzle, Alembic 등)가 새로 생성된 전용 데이터베이스 브랜치를 대상으로 실행됩니다.
• 해당 브랜치의 연결 문자열을 가리키는 프리뷰 앱이 배포됩니다.
• 스키마 diff가 생성되고 어떤 테이블, 컬럼, 인덱스가 변경되었는지 정확히 보여주는 PR 댓글로 게시됩니다.
• 검토자는 코드와 데이터베이스 변경 사항을 모두 검증합니다.
• PR이 닫히거나 머지되면 CI가 브랜치를 삭제합니다.

리포지토리 예시에서는 Databricks Apps를 사용하여 애플리케이션을 배포하지만, 이 개념은 Vercel, Netlify, Cloudflare 등 다른 모든 호스팅 플랫폼에도 적용됩니다.

데이터베이스 브랜치를 활용한 버그 재현, 마이그레이션 및 테스트

개발 작업 외에도 데이터베이스 브랜칭은 여러 다른 유용한 워크플로를 지원할 수 있습니다. 예제 리포지토리에는 구현되어 있지 않지만, Lakebase 개발 워크플로에 유용한 기능이 될 수 있습니다. 예를 들어 데이터베이스 브랜칭을 사용하면 버그가 발생하기 직전 등 특정 시점의 프로덕션 환경에서 격리된 브랜치를 생성하여 실제 데이터를 바탕으로 문제를 조사하고, 버그를 안전하게 재현하며, 수정 사항이 검증되면 브랜치를 폐기할 수 있습니다.

브랜칭을 활용하면 스키마 마이그레이션도 더 안전하게 수행할 수 있습니다. 변경 사항을 프로덕션에 배포하기 전에 데이터베이스 브랜치를 자동으로 생성하고, 마이그레이션을 적용하고, 테스트를 실행하여 애플리케이션이 예상대로 동작하는지 확인할 수 있습니다. 마이그레이션이 검증되면 동일한 변경 사항을 프로덕션에 적용할 수 있습니다.

이러한 워크플로는 예를 들어 Unity Catalog 마스킹 등을 사용하여 운영 중인 데이터베이스에 위험을 주지 않으면서도 프로덕션과 유사하거나 프로덕션에서 파생된 데이터로 개발자가 작업할 수 있게 해주므로 매우 유용합니다. 각 브랜치는 격리되어 있고 일회성이므로 디버깅, 테스트 및 검증을 위한 안전한 환경을 제공합니다.

결론

이러한 패턴이 모여 에이전트당 브랜치 하나, PR당 브랜치 하나, 프로덕션 검증을 위한 격리된 브랜치라는 Lakebase 개발 루프를 형성합니다.

Agentic SDLC의 경우 데이터베이스 브랜칭은 코딩 에이전트와 함께 작업하는 개발 팀에게 안전하고 유연한 기반을 제공합니다. 직접 브랜칭을 시도해 보세요.

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