진화적 데이터베이스 개발 실현: Lakebase를 활용한 데이터베이스 브랜칭, 최종편

Evolutionary Database Design에서 설명하고 Refactoring Databases: Evolutionary Database Design에서 구체화된 방법론은 지난 20년 동안 명확하게 정립되어 왔습니다. 7가지 실천법, 70개 이상의 이름이 지정된 리팩터링 카탈로그, 전환 메커니즘 등 모든 것이 문서화되고 피어 리뷰를 거쳐 교육되어 왔습니다.

이 방법론은 2010년 Continuous Delivery(12장: 데이터 관리)와 함께 CI/CD에 도달했습니다. 마이그레이션은 배포 파이프라인에서 일급 아티팩트(first-class artifact)가 되었습니다. '코드로서의 데이터베이스 변경(database-changes-as-code)' 규율은 더 넓은 CI/CD 운동으로 확산되었습니다. CD가 해결하지 못한 것은 파이프라인별 격리였습니다. 파이프라인이 마이그레이션을 실행할 수는 있었지만, 여전히 대상 데이터베이스가 필요했고 그 대상은 공유되었습니다. 실천법 #4 – 모두가 자신만의 데이터베이스 인스턴스를 갖는다 – 는 대부분의 팀에서 이상향으로만 남아 있었습니다. 개발자별로 실제 운영 환경과 유사한 데이터베이스를 구축하려면 시간, 비용, 그리고 DBA의 리소스가 많이 소모되기 때문입니다. 이 격차를 해결하기 위해 등장한 보완 레이어(모의 객체, 공유 스테이징 환경, 인메모리 데이터베이스 대체재, DBA 티켓 대기열)는 의도된 설계가 아니라 어쩔 수 없는 기본 방법론으로 자리 잡았습니다.

2026년, 기록 중 복사(copy-on-write) 데이터베이스 브랜칭 기능이 Databricks Lakebase에 도입됩니다. 테라바이트 규모의 운영 데이터베이스를 생성 시 스토리지 사용량 없이 1초 만에 브랜치로 만드는 작업이 이제 O(1) 연산으로 가능해집니다. 실천법 #4를 이상향으로만 머물게 했던 제약이 마침내 사라진 것입니다.

이 시리즈에서는 이러한 제약이 사라졌을 때 무엇이 변하는지 설명합니다. 방법론 자체는 그대로 유지되지만, 최초로 등장하는 새로운 실천법, 자동으로 이루어지는 팀 규모의 거버넌스, DBA의 역할 진화, 그리고 에이전트가 인간 동료와 공유하는 새로운 기반에 대해 다룹니다.

젠(Jen)을 소개합니다

젠은 Evolutionary Database Design에 등장하는 개발자 캐릭터입니다. 이 에세이에서 그녀는 일상적인 사용자 스토리(user story)로서 inventory_code 필드를 location_code, batch_number, 및 serial_number로 분할하는 데이터베이스 리팩터링을 구현하여, DBA와 개발자가 협업할 수 있고, 스키마가 소규모로 점진적으로 발전할 수 있으며, 마이그레이션을 통해 변경 사항을 안전하게 전달할 수 있음을 보여주었습니다.

이 시리즈는 20년 후의 젠의 이야기로 이어집니다. 그녀가 따르는 방법론은 2003년에 따랐던 것과 동일합니다. 새로워진 것은 그녀의 워크플로를 뒷받침하는 기반인 '기록 중 복사(copy-on-write) 데이터베이스 브랜칭'입니다. 이를 통해 그녀가 읽어왔던 실천법들이 실제 운영 규모에서 실현 가능해졌습니다. 총 3부로 구성된 이 시리즈에서 그녀는 세 가지 범위, 즉 그녀의 하루(1부), 그녀의 새로운 플레이북(2부), 그리고 그녀의 팀(3부)에서 활약하는 동일한 젠입니다.

3부: 대규모 조직에서의 젠의 팀

1부에서는 하나의 기능을 구현하는 젠의 과정을 살펴보았습니다. 2부에서는 2026년에 그녀가 작업할 때 따르는 11가지 실천법 플레이북을 소개했습니다. 3부에서는 이 동일한 플레이북을 50명의 개발자로 구성된 팀에 적용하고, 에이전트가 인간과 함께 브랜치를 생성하는 환경에서 이 규모가 되었을 때 무엇이 구조화되는지 질문을 던집니다.

세 가지 요소가 핵심적인 지지대 역할을 하게 됩니다.

첫째, 프로모션 경로의 각 환경을 나타내는 장기 실행 브랜치인 티어 토폴로지(tier topology)입니다. 개발자가 한 명일 때는 기능(feature) 브랜치와 운영(production) 환경만 있으면 되었습니다. 하지만 50명일 때는 안정적인 레인과 그 위에 레이어로 얹어진 임시(ephemeral) 레인을 갖춘 구조화된 계층 구조가 필요합니다.

둘째, 어떤 브랜치에 대해 누가 무엇을 할 수 있는지 정의하는 권한 모델 프레임워크입니다. 개발자가 한 명일 때는 관례에 의존할 수 있었습니다. 하지만 에이전트가 함께 참여하는 50명 규모에서는 프레임워크를 한 번 설계한 후 자동으로 강제 적용해야 합니다.

셋째, DBA의 역할입니다. 개발자가 한 명일 때 DBA는 PR에서 젠의 설계 파트너였습니다. 하지만 50명 규모에서 DBA는 젠과 그녀의 팀원들이 작업하는 프레임워크를 설계한 플랫폼 엔지니어입니다.

이 포스트에서는 이러한 각 요소를 다룬 다음 에이전트에 대해 알아봅니다. 동일한 역량을 갖춘 에이전트를 활용하는 것은 실천법 #11입니다. 에이전트는 주니어 개발자와 같습니다. 실행되는 코드, 통과하는 테스트, 적용되는 마이그레이션을 만들어내지만, 가이드가 없으면 유지보수할 수 없는 시스템을 만듭니다. 테스트는 팀이 에이전트의 결과물을 검증하는 방법입니다. 다음에 이어지는 TDD 플레이북은 팀이 테스트를 우선시하도록 만드는 방법입니다.

별도의 인스턴스가 아닌 장기 실행 브랜치로서의 티어

브랜칭이 도입되기 전의 세상에서 환경은 곧 인스턴스였습니다. 스테이징을 위한 전용 Postgres 배포, UAT를 위한 배포, 성능 테스트를 위한 배포가 각각 별도로 프로비저닝되고, 패치되고, 마스킹되고, 동기화되었습니다. 2부에서 언급한 보완 레이어도 여기에 존재했습니다. 환경 간의 불일치(drift)는 구조적인 문제였습니다.

팀 규모에서는 티어 모델이 동일한 Lakebase 부모 브랜치에서 갈라져 나온 장기 실행 브랜치로 통합됩니다.

브랜치는 두 가지 중 하나입니다. 티어(장기 실행되며 프로모션 계층 구조의 부모 역할을 함) 또는 기능(feature)(임시로 존재하며 티어에서 파생되어 사용 후 정리됨)입니다. 티어에는 부모가 있습니다. 이 부모-자식 체인이 바로 프로모션 계층 구조입니다.

그림 1에서는 메인이 운영 환경이고 필요할 때마다 기능(Feature) 브랜치를 가져오는 간단한 계층 구조를 볼 수 있습니다. 이 설정은 일반적으로 초기 프로토타이핑이나 아주 소규모 팀의 초기 단계 작업에 유용합니다. 더 많은 개발자가 있거나 많은 환경이 필요한 성숙한 팀에서는 아래와 같은 설정이 필요합니다.

일부 기업에서는 릴리스 후보(RC)가 필요하며, 이 릴리스 후보는 일정 기간 동안 개발된 후 성공적인 테스트를 거쳐 운영 환경으로 프로모션됩니다. 그림 3은 릴리스 후보를 개발한 후 운영 환경으로 프로모션하고 이후 릴리스 후보 브랜치를 정리할 수 있는 레이아웃을 보여줍니다.

브랜치의 이름은 임의로 지정할 수 있으며, 중요한 것은 부모-자식 관계가 설정되는 방식에 대한 규칙입니다. 부모 체인 계층 구조에 모순되는 전환을 허용하지 않는 정책을 구현하여 직접적인 기능 병합을 방지할 수 있습니다.

이러한 정책 정의는 파이프라인 관리에 많은 이점을 제공합니다:

• 브랜치를 인식하는 단일 파이프라인 정의. 2부에서 소개된 pr.yml 는 모든 PR에 대해 실행되고, merge.yml는 모든 프로모션에 대해 실행됩니다. 동일한 워크플로가 기능, 티어 및 그 사이의 전환을 모두 처리합니다.
• 프로모션은 재배포가 아닌 병합(merge)입니다. 스테이징에서 운영 환경으로 배포하는 것은 git 병합이며, 그 다운스트림 효과로 Lakebase 브랜치 프로모션이 발생합니다. 마이그레이션은 이전 단계에서 검증된 코드와 마찬가지로, 이전 티어에서 먼저 검증된 후 각 티어에서 한 번씩 적용됩니다.
• "테스트 환경"과 운영 환경 간의 불일치(drift)가 없습니다. 모든 티어는 동일한 부모에서 파생됩니다. 두 티어 간의 스키마 차이(diff)는 실제로 계산 가능한 실체입니다. 스키마는 두 개의 서로 다른 데이터베이스 소프트웨어 설치본이 아니라, 분기 마커가 있는 하나의 페이지 체인입니다. 이를 통해 팀은 패치 및 업그레이드가 필요한 수많은 데이터베이스 서버를 직접 관리하지 않아도 됩니다.
• 재지정을 통한 롤백. 잘못된 프로모션은 애플리케이션이 해당 티어의 프로모션 전 스냅샷을 가리키도록 하여 복구합니다. 스냅샷 자체가 또 다른 브랜치이므로 팀이 잘못된 배포로부터 복구할 수 있습니다.
• project_id, branch_id, endpoint_id별 비용 귀속. Unity Catalog은 메타데이터를 자동으로 캡처합니다. 감사 및 청구 테이블에 대한 SQL 쿼리를 통해 누가 어떤 브랜치를 생성했는지, 브랜치가 언제 생성되었는지, 브랜치를 계속 실행하는 데 드는 비용이 얼마인지 확인할 수 있습니다.

수많은 데이터베이스 인스턴스 수도 급격히 감소합니다. 6개의 환경 인스턴스 환경(prod, staging, UAT, QA, perf, demo)이 상위 브랜치와 연결된 계층 구조를 가진 장기 실행 브랜치들을 포함하는 하나의 Lakebase 상위 브랜치로 통합됩니다. 프로비저닝, 모니터링 및 패치에 사용되던 인스턴스는 이제 프로덕션과 동일한 데이터 형태를 가지고 프로덕션과 동일한 정책의 제어를 받으며, 필요할 때 1초 만에 프로덕션 상태로 재설정되는 논리적 브랜치가 됩니다.

다양한 규칙을 통해 여러 유형의 브랜치를 상위 브랜치로 생성할 수 있습니다. 일반적인 규칙은 데이터베이스 스키마와 참조 데이터가 포함된 브랜치를 유지하여, 누구나 이 브랜치에서 새로운 브랜치를 생성하고 테스트 데이터로 채우거나 실제 데이터를 생성하는 자동화된 테스트를 실행하여 staging 또는 다른 브랜치와의 충돌을 피하는 것입니다.

지금 해야 할 일: 권한 모델

실천법 #10 파트 2의 플레이북에서 우리는 한 번 설계하고 브랜치별로 상속되는 거버넌스에 대해 논의했습니다. 이것이 어떻게 구현되는지 살펴보겠습니다.

설계 작업은 런타임을 제한하지 않습니다. 이는 공통 작업이 강제할 수 있는 구조적 설계입니다.

팀 규모가 확장되거나 에이전트가 추가되기 전에 지금 내려야 할 결정은 다음과 같습니다.

• 각 티어에서 브랜치 생성. production에서 포크하는 것은 staging 또는 feature에서 포크하는 것과는 다른 권한입니다. 기본값은 다음과 같아야 합니다. feature는 진입(최하위) 티어에서 포크하며, 절대 production에서 포크하지 않습니다. production 포크는 핫픽스 및 복구 흐름을 위해 예약되어 있습니다.
• 티어 간 프로모션. “feature에서 staging으로”의 프로모션은 코드 리뷰 영역입니다. “staging에서 production으로”의 프로모션은 릴리스 조정 영역입니다. 이 두 가지는 서로 다른 검토자가 있는 별개의 관문이므로 비즈니스 팀과 개발 팀에 독립성을 부여합니다.
• 읽기 대 쓰기. 브랜치에 있는 프로덕션 형태의 데이터에 대한 읽기 권한은 해당 브랜치에 대한 쓰기 권한과 동일하지 않습니다. 많은 엔지니어링 역할에 읽기 권한이 필요하지만, 쓰기 권한이 필요한 경우는 거의 없습니다.
• Unity Catalog 정책. Unity Catalog 정책(마스킹, 행 필터, 열 수준 권한 등)은 프로덕션에 적용됩니다. 이러한 정책은 기본적으로 모든 하위 브랜치에 상속되며, 티어별 예외(예: 부하 테스트를 위해 합성된 PII가 포함된 QA 티어)는 한 번만 선언됩니다.
• 감사 추적 캡처. 모든 브랜치 생성, 모든 프로모션, 모든 마이그레이션 적용, 모든 액세스 패턴을 쿼리 가능한 단일 위치에서 제공합니다.

팀 규모에서 이를 작동하게 만드는 원칙은 다음과 같습니다. 역할은 선언하고, 정책은 강제합니다. 플랫폼 엔지니어는 티어 계층 구조, 권한 모델, 프로모션 경로 및 Unity Catalog 정책 태세를 선언합니다. 정책은 선언된 내용과 모순되는 전환을 거부합니다. 사람이나 에이전트가 다른 형태로 작업을 재시도하여 선언된 경계를 무시할 수 있는 방법은 없습니다.

이것은 팀이 50명의 개발자로 늘어나고 에이전트가 사람이 검토할 수 있는 것보다 더 빠르게 브랜치를 생성하기 전에 오늘 해야 할 작업입니다. 프레임워크는 공유된 규칙과 가드레일로 팀을 하나로 묶어주는 역할을 합니다. 다른 모든 것은 그 안에서 작동합니다.

새로운 역할: DBA에서 플랫폼 엔지니어로

20년 전, 2003년 Evolutionary Database Design 에세이의 결론은 다음과 같았습니다.

“여기서 설명하는 기술을 사용하는 것이 많은 작업처럼 들릴 수 있지만, 실제로는 엄청난 인력이 필요하지 않습니다. 많은 프로젝트에서 우리는 30여 명의 개발자와 100명에 가까운 팀 규모(QA, 분석가 및 관리자 포함)를 유지했습니다. 어느 날이든 사람들의 워크스테이션에는 다양한 스키마의 사본이 100개 정도 나와 있을 것입니다. 하지만 이 모든 활동에는 프로세스와 워크플로의 작동 방식을 이해하는 두 명의 개발자와 단 한 명의 전임 DBA만 있으면 되었습니다.”

이 주장은 다섯 가지 보강 사항과 함께 2026년에도 그대로 이어집니다.

1. 비율은 유지되며, DBA당 더 많은 여유 공간이 확보됩니다. 약 100명당 1명의 전임 DBA가 있고 100개 이상의 동시 브랜치가 실행 중인 경우, 이제 브랜치 생성이 1초 만에 완료되는 메타데이터 작업이므로 브랜치당 비용이 적게 듭니다. 비율이 중요한 것이 아닙니다. DBA가 그 시간 동안 무엇을 하고 있는지가 중요합니다.

2. 작업이 스택 위로 이동합니다. 2003년에 인프라 프로비저닝, 스키마 프로비저닝, 액세스 제어 및 가끔씩의 수동 개입에 소요되던 시간이 이제는 브랜칭 정책 설계, 마스킹 정책, 프로모션 워크플로 및 감사 추적 관찰 가능성으로 이동합니다. 구체적인 아티팩트로는 모든 PR에 게시되는 schema-diff 봇, 매일 밤 개발 브랜치를 재설정하는 예약된 작업, 브랜치 수명 주기 및 TTL 준수를 추적하는 관찰 가능성 대시보드, 스키마 유효성 검사 시 병합을 제한하는 CI 정의 등이 있습니다. 이것은 플랫폼 설계 작업이며, 이전보다 훨씬 더 고차원적인 작업입니다.

3. 에이전트가 방정식에 등장합니다. 2003년 에세이에서 다루지 않아도 되었던 것은 에이전트가 코드를 작성하는 것이었습니다. Neon은 하루에 약 50만 개의 브랜치가 생성되며, 그 중 80% 이상이 에이전트에 의해 생성된다고 보고합니다. 단 한 명의 DBA가 이 엄청난 양을 티켓으로 제어할 수는 없습니다. 플랫폼 아키텍트로의 역할 진화만이 에이전트 규모에서 작동할 수 있는 유일한 역할입니다.

4. 수치가 구체화됩니다. 6명의 개발자로 구성된 팀은 기존 모델에서 스프린트당 일반적으로 30개 이상의 운영 티켓(프로비저닝, 스키마 검토, 데이터 새로 고침, 액세스 권한 부여)을 생성합니다. 브랜치 네이티브 모델에서는 스프린트당 5개 미만의 고가치 정책 검토가 발생합니다. DBA의 노고는 주당 20시간 이상에서 5시간 미만으로 줄어들고, MTTR은 4시간 이상에서 30분 미만으로 단축됩니다. 이러한 노고의 감소는 DBA가 개발자와 협력하여 개발 중인 기능에 대한 최적의 솔루션에 도달하는 데 도움이 될 수 있습니다.

5. 감사 추적이 전략적 대시보드가 됩니다. 이전에는 3개의 서비스와 3개의 쿼리 언어를 교차 참조해야 했던 작업이 이제는 플랫폼의 시스템 테이블에 대한 단일 SQL 쿼리로 가능해졌습니다. 모든 브랜치, 모든 작업, 모든 비용, 모든 거버넌스 이벤트가 한곳에 모입니다. DBA가 이 뷰를 수동으로 구축하는 것이 아니라 플랫폼이 이를 수행합니다.

Refactoring Databases (2006)의 서문에서 마틴 파울러(Martin Fowler)는 이 책이 "단지 첫 걸음"을 나타내기를 바랐습니다. IDE가 코드 리팩터링을 자동화하는 방식으로 데이터베이스 리팩터링을 자동화하는 도구를 향한 첫 걸음 말입니다. 브랜칭이 바로 그 다음 단계입니다. 파울러가 2006년에 바랐던 코드 속도의 규율 있는 데이터베이스 변경을 이제 플랫폼이 제공합니다. DBA가 규율을 설계하고 플랫폼이 이를 적용합니다.

새로운 역할의 직함은 다양합니다(플랫폼 엔지니어, 데이터베이스 플랫폼 소유자, 여전히 이름만 DBA 등). 본질은 동일합니다. 다른 모든 사람이 작동하는 프레임워크를 설계하는 사람입니다.

동일한 기능을 사용하는 에이전트

실천법 #11 파트 2에서 우리는 동일한 브랜칭 기능을 가진 실무자로서의 코딩 에이전트에 대해 설명했습니다. 이에 대해 논의해 보겠습니다.

에이전트는 production이 아닌 브랜치에 액세스할 수 있습니다. Jen에게 적용되는 동일한 워크플로 규칙이 에이전트에도 적용됩니다. 테스트는 에이전트가 수정하거나 삭제할 수 있는 모의(mock)가 아니라 브랜치의 실제 데이터베이스를 대상으로 실행됩니다. 누가 마이그레이션을 작성했는지에 관계없이 모든 PR에 스키마 차이(schema diff)가 표시됩니다. Jen을 보호하는 정책이 에이전트도 보호합니다.

방치된 에이전트는 주니어 개발자와 같습니다.

주니어 개발자에게 기능 티켓만 주어지고 추가적인 안내가 없다면, 컴파일되는 코드, 통과하는 테스트, 깔끔하게 적용되는 마이그레이션 스크립트는 만들어낼 수 있을 것입니다. 하지만 이 코드는 코드베이스의 다른 곳에 이미 존재하는 로직을 중복으로 구현하여 중복성을 초래할 수 있습니다. 마이그레이션은 이름은 맞지만 타입이 잘못된 컬럼을 추가할 수도 있습니다. 테스트는 정상적인 경로(happy path)만 검증하기 때문에 통과할 수도 있습니다. 이러한 문제는 CI 빌드가 성공(green)할 때는 전혀 나타나지 않으며, 6주 후에 다른 사람이 해당 작업을 확장해야 할 때 비로소 드러납니다.

에이전트도 똑같은 일을 하지만 훨씬 더 빠르고 대량으로 수행합니다.

명확한 안내가 없다면 에이전트는 다음과 같은 작업을 수행하게 됩니다.

• 코드베이스에 이미 존재하는 패턴을 불필요하게 새로 만듭니다.
• 겉보기에는 맞지만 지정된 리팩터링 전환 메커니즘을 건너뛰는 스키마 변경을 작성합니다(예: 데이터를 먼저 이동하지 않고 컬럼을 삭제하거나, 기존 행을 업데이트하지 않고 NOT NULL 컬럼을 추가하는 등).
• 실제 프로덕션에 존재하는 데이터 형태가 아니라 자신이 상상한 데이터 형태를 기준으로 통과하는 테스트를 작성합니다.
• 적용은 되지만 롤백 시 일관성 없는 상태를 초래하는 마이그레이션을 작성합니다.
• 작은 변경 사항을 해결하기 위해 추상화 위에 또 다른 추상화를 겹겹이 쌓습니다.

하부 구조(substrate)는 테스트 성공 표시(green bar)를 신뢰할 수 있게 만듭니다(모의 객체(mock) 없이 브랜치에 실제 데이터베이스 사용). 하지만 코드를 유지 관리하기 쉽게 만들어 주지는 않습니다.

팀은 네 가지 보완 장치를 통해 코드를 유지 관리할 수 있게 만듭니다:

• 가드레일: 권한 모델. 에이전트는 프로덕션에서 브랜치를 생성할 수 없고, 티어 간에 승격할 수 없으며, 자신이 소유하지 않은 티어에 마이그레이션을 적용할 수 없습니다. 하부 구조가 이를 거부합니다.
• 패턴: 명명된 리팩터링. databaserefactoring.com의 2006년 카탈로그에는 명확한 전환 메커니즘을 가진 70개 이상의 리팩터링이 정의되어 있습니다. "Split Column 리팩터링 적용"이라는 안내를 받은 에이전트는 단순히 "이 컬럼 분할"이라는 안내를 받은 에이전트와는 다른 마이그레이션을 생성합니다.
• 워크플로: SCM 상태 머신. 에이전트는 차단 게이트가 있는 일련의 상태 순서를 따릅니다. 하부 구조는 선언된 계약을 충족하지 않는 상태 전환을 거부합니다.
• 검토: PR 루프의 사람. 모든 PR에서 스키마 차이(schema-diff)를 확인할 수 있으며, DBA가 검토 경로에 참여합니다. Part 2에서 재구성된 실천법 #1은 이를 비동기식으로 만들었습니다. 팀 규모에서 에이전트가 포함된 경우, 이러한 비동기 검토를 통해 테스트가 잡아내지 못한 미세한 오류를 잡아낼 수 있습니다.

SCM 워크플로는 핵심적인 역할을 합니다. Lakebase App Dev Kit에서 소스 제어 관리(source control management)는 단순한 코드 브랜치 그 이상을 다룹니다. Part 1에서 소개한 것처럼 단일 단위로 관리되는 쌍을 이루는 브랜칭(코드 브랜치와 Lakebase 브랜치)을 다룹니다. Lakebase App Dev Kit의 공통 하부 구조에서 기능으로 제공되는 이 쌍을 이루는 브랜칭은 계층 구조에 모순되는 병합, 브랜치와 함께 이동하는 마이그레이션, CI 게이트, 마이그레이션을 상위 티어에 적용하는 병합과 같은 공통 가드레일을 강제합니다. 이 개발 키트는 이 SCM 워크플로를 실행 가능한 상태 머신으로 제공합니다.

위의 그림 4는 개발 중의 다섯 가지 상태인 scaffold-complete, feature-claimed, pr-ready, ci-green, merged를 설명합니다. 서로 다른 상태 간의 각 전환은 CLI 명령(lakebase-scm-claim-feature-branch, lakebase-scm-prepare-pr, lakebase-scm-wait-ci, lakebase-scm-merge)에 의해 구동됩니다. 각 CLI 명령은 작업을 수행하기 전에 전제 조건을 검증하고, 전환을 수행하며, 새 상태를 .lakebase/workflow-state.json (스키마가 검증된 게이트 표면)에 기록합니다. 게이트가 실패하더라도 머신은 이전 상태로 복구 가능한 상태로 유지됩니다. 게이트는 권고 사항이 아니라 차단 장치입니다.

에이전트는 이러한 CLI를 호출할 뿐, 병렬 경로를 임의로 만들어낼 수 없습니다. 하부 구조는 전제 조건 실패 시 상태 머신의 진행을 거부합니다. 잘못된 티어를 상위로 둔 기능 브랜치는 거부되고, CI가 성공(green)하기 전에 병합하려는 시도는 거부되며, 일관성 없는 상태 파일은 다음 게이트를 차단합니다. 핸드오프 계약은 스크럼 마스터 역할이 소유하며, 하부 구조가 이를 강제합니다. 구조적 결정(티어 계층 구조, 기능의 소스 티어, 승격 경로)은 아키텍트나 스크럼 마스터의 몫이며, 기록된 후 하부 구조에 의해 준수됩니다. 하부 구조는 티어나 상위 요소를 임의로 만들어내지 않으며, 선언된 내용을 준수하고 이에 모순되는 전환을 거부합니다.

이것이 바로 지금까지 팀들이 에이전트를 사용해 온 방식을 깨뜨리는 프레임워크입니다. 단순한 통합 방식은 에이전트를 채팅창의 시니어 엔지니어처럼 취급합니다. 컨텍스트를 제공하고, 결과물을 요청하고, 이를 반복하는 방식입니다. 이는 1인 개발자 규모에서는 작동하지만 팀 규모에서는 작동하지 않습니다. 에이전트의 "컨텍스트"를 검토하거나 거버넌스를 적용하거나 재현할 수 없기 때문입니다. 대신 에이전트를 주니어 개발자로 취급해 보세요. 실행 가능한 상태 머신 내에서 문서화된 좁은 범위의 작업을 부여하고, 스키마에 따라 결과물을 검증하고, 게이트를 통과시킨 후 이를 반복하는 것입니다. 하부 구조가 이를 강제하며, 워크플로 상태 파일이 바로 API 역할을 합니다.

팀 규모 실천법을 위한 플레이북 항목

Part 2에서는 2026년을 위한 새로운 실천법 중 실천법 #10과 #11을 소개했습니다.

실천법 #10: 한 번 설계하고 브랜치별로 상속하는 거버넌스

규칙. 권한 모델, 액세스 제어를 관리하기 위한 Unity Catalog 정책 및 감사 추적 캡처는 트렁크에서 한 번 설계되며 모든 하위 브랜치에 자동으로 상속됩니다.

이것이 왜 지속 가능한 습관이 되었을까요? 팀 규모에서 거버넌스는 개발자가 기억해야 하는 규율이 아니라 DBA나 플랫폼 엔지니어의 역할이어야 하기 때문입니다. 브랜치는 몇 초 만에 생성되고 삭제됩니다. 브랜치별로 거버넌스를 수동으로 구성한다면 브랜칭을 통해 얻은 시간 절약 효과가 사라지게 됩니다.

작동 방식:

• 티어 계층 구조 선언: 장기 실행 브랜치가 무엇인지, 상위 링크가 무엇인지, 각 티어가 어떤 거버넌스 태세를 취하는지 선언합니다.
• 권한 경계 선언: 각 티어에서 브랜치를 생성할 수 있는 사람, 티어 간에 승격할 수 있는 사람, 읽기 권한과 쓰기 권한을 가진 사람을 선언합니다.
• Unity Catalog 정책 상속 선언: 마스킹, 행 필터 및 기본적으로 상위에서 상속되는 컬럼 수준 권한을 선언합니다. 티어별 예외는 한 번만 선언합니다. 모든 Unity Catalog 정책 유형에 대한 자동 전파가 거의 완료 단계에 있으므로, 최종 상태를 고려하여 프레임워크를 설계하세요.
• 감사 추적 캡처 선언: 모든 브랜치 생성, 모든 승격, 모든 마이그레이션 적용, 모든 액세스 패턴이 쿼리 가능한 시스템 테이블에 자동으로 기록됩니다.
• DBA 또는 플랫폼 엔지니어가 정책을 통해 이를 강제합니다. 선언된 모델에 모순되는 전환은 거부됩니다.

안티 패턴. 런타임에 브랜치별로 거버넌스를 구성하는 것입니다. 한 번만 선언하는 것의 핵심은 사람이 검토할 수 있는 속도보다 더 빠르게 브랜치가 생성되더라도 프레임워크가 유지된다는 점입니다. 브랜치별로 수동 구성을 하게 되면 브랜칭을 통해 방금 제거한 병목 현상이 다시 발생하게 됩니다.

Jen의 팀이 확장 적용하는 방법. Jen의 플랫폼 엔지니어 또는 DBA가 프로젝트 생성 시 계층 구조를 선언했습니다. Jen, 팀원들 또는 팀의 에이전트가 생성하는 모든 브랜치는 선언된 마스킹, 권한 및 감사 구성을 상속받습니다. 팀이 새로운 계층을 추가하면 프레임워크는 새로운 부모 링크를 기록합니다. 진행 중인 기능은 원래의 부모를 유지하며(소급하여 부모를 다시 지정하지 않음), 새로운 기능은 새로운 진입 계층에서 분기됩니다.

실행 방식 #11: 동일한 브랜칭 기능을 갖춘 실무자로서의 에이전트

규칙. 에이전트는 SCM 워크플로의 실행 가능한 상태 머신 내에서 작동합니다. 여기에는 5가지 상태, 상태 간의 차단 게이트, 스키마 검증된 상태 파일이 포함됩니다. 동일한 워크플로 규칙이 Jen과 에이전트 모두에게 적용되며, 누가 작업을 수행하든 상관없이 공통 서브스트레이트(substrate)가 이를 강제합니다.

이것이 왜 이제 지속 가능한 습관이 되었을까요? 브랜치 생성은 메타데이터 작업이므로 에이전트가 주도하는 대량의 작업 처리가 가능합니다. 에이전트가 활용할 수 있도록 개발된 서브스트레이트는 선언된 계층 구조나 기록된 게이트 상태에 모순되는 전환을 거부할 수 있습니다. 의존할 수 있는 채팅 창 컨텍스트는 없으며, 디스크에 있는 아티팩트(workflow-state.json)만이 게이트 전환 간의 경계를 넘나듭니다.

작동 원리:

• SCM 상태 머신에는 5가지 상태인 scaffold-complete, feature-claimed, pr-ready, ci-green, merged가 있습니다. 각 전환은 CLI에 의해 구동되며, 각 CLI는 작업을 수행하기 전에 전제 조건을 검증합니다.
• 게이트 표면은 .lakebase/workflow-state.json이며, scm-workflow-state.schema.json에 대해 검증됩니다. 모든 전환은 새로운 상태와 다음 게이트가 필요로 하는 불변 요소를 기록합니다.
• 구조적 결정(계층 구조, 기능별 소스 계층, 승격 경로, 핸드오프 계약)은 역할(아키텍트 또는 스크럼 마스터)에 속하며, 기록된 후 서브스트레이트에 의해 강제됩니다.
• 에이전트는 CLI를 호출합니다. 서브스트레이트가 이를 강제하므로 에이전트는 이를 우회할 수 없습니다. 게이트 통과에 실패하면 상태 머신은 이전 상태에서 복구 가능한 상태로 남게 되며, 에이전트는 "다른 방식으로 재시도"하지 않습니다.
• pr-ready에서 ci-green 내부에서 실행되는 CI 게이트는 브랜치에서 실제 Postgres를 실행하며, 스키마 차이점(diff)이 PR에 인라인으로 게시됩니다. 에이전트의 작업은 실제 데이터베이스 상태를 기준으로 측정됩니다.

안티 패턴. 채팅 창에서 에이전트를 수석 엔지니어처럼 취급하며 “컨텍스트를 쏟아붓고 출력을 요청하는 방식”은 단일 개발자 규모에서는 작동할 수 있지만, "컨텍스트"를 검토, 거버넌스 또는 재실행할 수 없기 때문에 팀 규모에서는 실패합니다. 대신 아티팩트 기반 API(artifact-as-API) 모델을 사용하세요. 에이전트는 workflow-state.json 및 해당 단계에 대해 문서화된 입력을 읽고(READ), 문서화된 출력을 기록(WRITE)합니다. 검증기가 이를 확인하며, 계약이 준수될 때만 다음 게이트가 실행됩니다.

Jen의 팀이 확장 적용하는 방법. Jen의 팀에 있는 모든 에이전트는 Jen과 그녀의 팀원들이 사용하는 것과 동일한 5가지 상태 머신 내에서 작동합니다. 스크럼 마스터 역할이 핸드오프 계약을 소유하며, 서브스트레이트는 이를 충족하지 않는 전환을 거부합니다. 에이전트는 잘못된 계층에서 분기된 기능을 배포할 수 없고, CI가 통과(green)되기 전에 머지할 수 없으며, 스키마 차이점(diff) 아티팩트를 우회할 수 없습니다. 누가 또는 무엇이 작업을 시작했든 상관없이 프레임워크는 유지됩니다.

그 위에 결합된 선택적 레이어로서의 TDD

실행 방식 #11은 SCM 워크플로를 기본 기준으로 설정합니다. 에이전트와 인간 모두를 포함하여 키트를 사용하는 모든 사람이 이를 따릅니다. TDD는 테스트 우선(test-first) 규율을 원하는 팀을 위해 해당 기본 기준 위에 얹어지는 별도의 고려 사항입니다. 이는 선택 사항(opt-in)이며, 경로에 관계없이 SCM 게이트는 필수적입니다.

TDD 이전에도 테스트가 중요한 이유: 에이전트가 코드를 작성할 때 테스트는 확장 가능한 유일한 강제 수단입니다. Kent Beck은 2026년 Pragmatic Engineer 인터뷰에서 이러한 실패 모드를 공개적으로 언급했습니다. 그는 AI 에이전트가 테스트를 통과시키기 위해 테스트 자체를 삭제하는 것을 막는 데 어려움을 겪고 있다고 말했습니다. 루프 내의 그 어떤 것도 에이전트가 시스템의 실제 형태에 직면하도록 강제하지 않는다면, 테스트 통과(green bar)를 만족시키는 것은 너무나 쉽습니다. 모의 객체(mock)를 사용하면 이 작업이 아주 단순해집니다. 인메모리 대체물도 마찬가지입니다.

브랜칭은 데이터 레이어에서 테스트 통과(green bar)가 정직하게 이루어지도록 만듭니다. 에이전트가 테스트하는 대상은 실제 브랜치에 있는 실제 데이터베이스입니다. 스키마 제약 조건은 일치하지 않는 행 삽입을 거부하고, 외래 키는 분리된 데이터를 거부하며, 실제 데이터 형태는 모의 객체가 조용히 흡수했을 가정을 드러내고, 에이전트는 테이블을 드롭할 수 없습니다. 이러한 가드레일 덕분에 규정 준수를 가장하는 비용이 증가합니다.

하지만 서브스트레이트는 필요조건일 뿐 충분조건은 아닙니다. 테스트는 어딘가에서 제공되어야 합니다. 에이전트가 테스트를 작성한다면 에이전트가 이를 삭제할 수도 있습니다. 이것이 바로 TDD가 메우는 공백입니다.

TDD 워크플로는 SCM 워크플로 위에 레이어로 얹어집니다. 이는 SCM 상태인 feature-claimed와 pr-ready 사이에서 실행되며, 브랜치 작업을 위해 SCM을 호출하고(주기 실험 브랜치는 내부적으로 SCM 프리미티브를 사용함), SCM을 상위로 호출하지는 않습니다. 의존성은 단방향입니다. TDD 레이어를 원하지 않는 팀은 기능 브랜치에서 직접 편집하여 기능을 배포하면서도 모든 SCM 게이트를 충족할 수 있습니다.

Lakebase App Dev Kit 은 역할별 자체 에이전트와 게이트 검증기를 갖춘 두 번째 상태 머신으로 TDD 워크플로를 제공합니다:

• Spec-author은 요청자의 설명을 스키마 검증된 구조화된 기능 아티팩트로 변환합니다.
• Architect-reviewer는 기능의 비기능적 요구사항(NFR)과 아키텍처 원칙을 아키텍처 결정에 매핑하고, 이를 architecture.json 및 설명 텍스트로 출력합니다.
• Test-strategist는 테스트 목록과 수락 기준(AC)별 시나리오를 생성하여 test-list.json 및 렌더링된 마크다운으로 출력합니다. 모든 NFR에는 최소 하나 이상의 수락 기준(AC)이 있으며, 모든 AC에는 시나리오가 있습니다.
• Scrum-master는 빌드 주기를 조율합니다. 각 주기는 (내부적으로 SCM 서브스트레이트를 사용하여) 실험 브랜치를 분기하고, 드라이버 에이전트를 실행하여 다음 AC를 구현하며, 네비게이터 에이전트를 실행하여 결과를 검토하고 검증합니다.
• Driver 및 navigator는 내부 루프의 테스트 작성자와 코드 작성자로, 쌍을 이루어 RED-GREEN-REFACTOR를 수행합니다.

각 역할에는 스키마에 따라 검증된 문서화된 입력과 출력이 있습니다. 각 에이전트는 문서화된 입력만 받으며, 다음 역할이 실행되기 전에 출력이 검증됩니다. 아티팩트는 역할 간의 API이며, 스키마는 타입 체크 역할을 합니다. 아티팩트가 누락되면 게이트 실패로 처리됩니다. 형식이 잘못된 아티팩트는 누락된 것과 동일하게 처리됩니다. TDD 레이어는 실행 방식 #11이 SCM을 위해 설정한 것과 동일한 아티팩트 기반 API(artifact-as-API) 모델을 차용합니다.

TDD 레이어 는 Companion: Lakebase App Dev Kit (오픈 소스이며, 인간 실무자를 위한 동반 전자책 포함)에 포함되어 있습니다. SCM 및 TDD 상태 머신, 역할별 에이전트 계약, 아티팩트 적합성 검사, 게이트 검증기는 모두 CLI 형태로 제공되므로 모든 오케스트레이터(키트, IDE 확장 프로그램, CI 작업, 인간 쉘 세션)가 호출할 수 있습니다.

요약하자면, SCM은 기본 기준(실행 방식 #11)이고 TDD는 그 위의 레이어입니다. 브랜칭은 테스트를 정직하게 만들고, TDD는 테스트를 우선시하게 만들며, 키트는 두 워크플로를 모두 실행 가능하게 만듭니다.

Jen의 팀이 보여주는 것

파트 1 에서는 Jen이 하나의 기능을 구현하는 과정을 살펴보았습니다. 그녀는 코드 브랜치를 Lakebase 브랜치와 페어링하고, 프로덕션 형태의 데이터를 대상으로 단 몇 초 만에 실제 마이그레이션을 실행했으며, 모의 객체 없이 테스트하고, 검토를 위해 스키마 차이점(diff)이 인라인으로 게시된 PR을 열었으며, 마이그레이션이 적용되고 임시 브랜치가 정리된 상태로 머지했습니다. 데이터베이스 변경이 일반적인 개발 프로세스의 일부가 되었습니다.

파트 2에서는 플레이북을 정의했습니다. 즉, 2003년의 7가지 실천법, 2026년까지 그중 5가지를 이상으로만 남겨두었던 한계점, 브랜칭 기능이 도입되면서 재구성된 동일한 7가지 실천법, 그리고 이 기술이 개별 개발자에게 제공하는 2가지 새로운 실천법을 다루었습니다. 일상적인 업무에서의 9가지 실천법과 팀 규모에서 새롭게 나타나는 2가지 실천법이 있습니다.

파트 3에서는 플레이북을 팀에 적용했습니다. 티어 토폴로지를 정의하여 장기 실행 브랜치가 하나의 Lakebase 부모 내에 어떻게 상주하는지, 권한 모델이 어떻게 플랫폼 엔지니어의 설계 아티팩트가 되는지 설명했습니다. 이는 한 번 선언되면 서브스트레이트에 의해 강제 적용됩니다(실천법 #10). 또한 2003년 인력 구성 논거를 뒷받침하는 5가지 보강 사항과 함께, DBA의 역할이 플랫폼 아키텍트로 어떻게 완전히 진화하는지 설명했습니다. 에이전트는 동일한 기능을 바탕으로 SCM 워크플로우의 실행 가능한 상태 머신 내부에서 워크플로우에 참여하며, 서브스트레이트는 주체가 누구든 또는 무엇이든 관계없이 게이트를 강제 적용합니다(실천법 #11). TDD는 그 위에 얹어진 선택적 레이어입니다. 이를 원하는 팀을 위해 전담 역할, 게이트, 아티팩트 계약을 갖춘 테스트 우선 원칙을 제공합니다.

가이드: 플러그인 안내서(Companion: Plugin Walkthrough)에서는 Lakebase SCM Extension용 VS Code 및 Cursor를 처음부터 끝까지 다룹니다.

가이드: Lakebase App Dev Kit(실무자를 위한 가이드 전자책 포함)에서는 위의 TDD 워크플로우를 다룹니다. 여기에는 SCM 및 TDD 상태 머신, 역할별 에이전트, 게이트 검증기, 에이전트를 팀에 안전하게 도입할 수 있도록 하는 아티팩트 계약이 포함됩니다.

방법론은 20년 동안 명확했습니다. 기술적 역량은 2026년에 마침내 실현되었습니다. 이제 사람과 에이전트 실무자 모두를 위한 플레이북이 작동하고 있습니다. 젠(Jen)의 팀은 50명의 개발자와 다수의 에이전트로 구성되어 있으며, 워크플로우는 동일합니다.

결론: 데이터베이스 브랜칭 기능은 이제 개발 팀에 엄청난 유연성을 제공합니다. 데이터베이스를 프로비저닝하고, 실제 스키마를 대상으로 테스트를 빌드하고, 각 PR 생성 시 자체 데이터베이스에 대해 CI를 실행하며, 에이전트가 이러한 방식으로 작업할 수 있도록 지원합니다. 이 모든 과정은 정책을 강제 적용하는 Unity Catalog의 거버넌스 프레임워크 내에서 이루어집니다.

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