“Database branching”에는 브랜딩 문제가 있습니다.
오랫동안 이 말은 보통 세 가지 중 하나를 뜻했습니다.
dump/restore 마라톤. 다음 스탠드업이 오기 전이나 우주의 열적 죽음이 오기 전쯤 끝나는 작업입니다.
branch마다 schema 하나라는 환상. 모두가 “격리되어 있다”고 점잖게 말하지만, lock contention과 extension 충돌은 링 위에서 난투를 벌입니다.
“clone” 기능. 실제 뜻은 “프로덕션을 복사했습니다. 청구서는 묻지 마세요.”입니다.
그래서 맞습니다. database branching은 죽었습니다. 적어도 개발자는 삶을 싫어하고 플랫폼 팀은 개발자를 싫어하게 만드는 그 버전은 끝났습니다.
하지만 아이디어 자체는 그 어느 때보다 살아 있습니다. 다만 역할이 올라갔을 뿐입니다. 다음에 당신의 데이터베이스를 운영할 주체는 사람이 아닐 것입니다. 인시던트를 조사하고, 마이그레이션을 검증하고, 스키마 변경을 제안하고, 인덱스를 조정하고, 성능 실험을 수행한 뒤 5분 뒤에 다시 해도 되냐고 정중하게 묻는 에이전트가 될 것입니다.
미래는 에이전트, CI, 프리뷰 환경, QA 자동화, 분석 샌드박스, 빠른 반복입니다. 데이터베이스는 끊임없이, 필요할 때마다, 플랫폼 팀에 허락을 구하지 않고 생성됩니다.
당신의 인프라가 이 루프를 지원하지 못한다면 “agentic workflows”를 가진 것이 아닙니다. 그저 티켓을 발행하는 멋진 챗봇을 가진 것뿐입니다. 티켓은 control plane이 아닙니다.
이 세계에는 branching이 필요합니다. 다만 거짓이 아닌 branching이 필요합니다.
여기서 Vela가 아주 분명한 메시지와 함께 등장합니다. 같은 Postgres, 완전히 다른 경험. 그리고 무엇보다 다른 branching입니다.
문제는 PostgreSQL이 아니다. 문제는 그 주변의 워크플로다.
PostgreSQL은 이미 이 이야기의 주인공입니다. 실전에서 검증되었고, 확장성이 뛰어나며, 프로덕션에서 입증되었고, 가장 좋은 의미로 지루합니다.
지루하지 않은 것은 Postgres 주변의 평범한 작업이 여전히 얼마나 고통스러운가입니다.
기능 개발용으로 깨끗한 데이터베이스가 필요합니까? 티켓.
현실적인 테스트 데이터가 필요합니까? 조율, 승인, dump 파일과 자존심이 들어가는 3단계 의식.
마이그레이션을 안전하게 테스트하고 싶습니까? 아무도 건드리기 싫어하는 공용 staging 환경을 얻기 위해 협상해 보세요.
데이터베이스 엔진은 문제가 아닙니다. 사람과 이제는 에이전트를 위한 주변 경험이 진짜 버그입니다.
오해하지 마세요. 저도 Docker를 알고 개발과 유닛 테스트에서 자주 씁니다. 하지만 매번 처음부터 시작해서 seed 데이터를 넣고, 그 seed가 실제 프로덕션의 엣지 케이스를 어느 정도라도 담고 있기를 바라는 것은 좋은 경험이 아닙니다.
오늘날의 “branching”은 대개 “격리인 척하기”다
대부분의 database branching 솔루션은 같은 함정에 빠집니다. “branch처럼 보인다”를 최적화하지, “branch처럼 동작한다”를 최적화하지 않습니다.
제게 가장 큰 문제는 schema-as-branch 방식입니다. 처음에는 저렴하고 하나의 PostgreSQL 인스턴스 안에 들어가니 매력적으로 보입니다. 하지만 부작용 목록이 끔찍합니다.
여전히 같은 서버이기 때문에 branch 간 lock contention이 생깁니다.
extension 충돌이 생깁니다. 각 branch가 원하는 것을 마음대로 독립적으로 설치하거나 설정할 수 없기 때문입니다.
CPU, 메모리, I/O 예산을 모두가 공유하니 noisy neighbor 문제가 생깁니다. “조심해서 써 주세요”에 기대는 격리는 보안 모델이 아닙니다. 그냥 기도입니다.
그리고 최악은, 이것이 진짜 clone이 아니라는 점입니다. 잘못된 schema에 실행할 때까지는 그저 몇 가지 schema 변경을 “안전하게” 시험해 보는 방식일 뿐입니다. 권한 설정으로 완화할 수는 있지만, “how do I restrict a user to a specific Postgres schema”를 검색해 보면 알 수 있습니다.
이런 branching은 개방형 사무실에 칸막이를 세워 놓고 “개인 사무실”이라고 부르는 것과 같습니다. 현실에서는 옆자리에서 누군가 참치 샌드위치를 먹고 있습니다.
Vela가 다른 이유: branch는 진짜 데이터베이스다
모든 것을 바꾸는 한 문장이 있습니다.
Vela에서 branch는 실제 PostgreSQL 데이터베이스입니다. schema도 아니고, 흉내 낸 namespace도 아니고, “논리 복사본”도 아닙니다. 진짜 Postgres 인스턴스입니다.
각 branch는 자체 micro virtual machine 안에서 완전히 격리된 Postgres 인스턴스로 실행되며, 리소스 제한과 tenant 경계는 “다들 얌전히 쓸 것”을 전제로 하지 않습니다.
이것은 전통적인 branching을 불안하게 만들던 문제들을 즉시 제거합니다.
- 한 branch가 다른 branch의 자원을 굶기지 못합니다.
- extension 충돌이 일어나지 않습니다.
- 이웃 branch와 lock meltdown을 공유하지 않습니다.
- 프로세스를 공유하지 않으니 동작이 새어나가지 않습니다.
- 다른 branch의 데이터를 실수로 파괴할 수도 없습니다.
사용자 입장에서는 이것이 “branching은 재밌는 데모”와 “우리가 소프트웨어를 테스트하고 배포하는 기본 방식”의 차이입니다.
Vela는 새로운 데이터베이스가 아니다. 그게 핵심이다.
솔직히 말하겠습니다. Vela는 또 하나의 새로운 데이터베이스 엔진이 아닙니다.
새로운 쿼리 언어를 만들지 않습니다.
SQL과 당신 사이에 독점 추상화 계층을 끼워 넣지 않습니다.
업그레이드 경로가 결국 눈물로 끝나는 Postgres 포크도 아닙니다.
Vela는 upstream Postgres를 사용합니다. 그래서 ORM, 마이그레이션 도구, 드라이버, BI 도구, 스크립트, 그리고 아무도 건드리지 못하게 된 2017년산 내부 툴까지 계속 그대로 동작합니다.
이 점이 중요합니다. “branching platform”이 모든 것을 다시 플랫폼화하라고 강요하는 순간, 그것은 더 이상 branching이 아니라 직업 전환입니다.
사람에게도 에이전트에게도 컨텍스트가 왕이다
기존 데이터베이스 워크플로는 사람이 마찰을 감수할 것이라고 가정합니다.
- “티켓을 발행해라.”
- “기다려라.”
- “조율해라.”
- “조심해라.”
- “나중에 치워라.”
에이전트는 그것을 용납하지 않습니다. CI도 그렇고, 빠른 제품 사이클도 마찬가지입니다.
대부분의 팀은 production, staging, dev/QA라는 동물원을 운영합니다. 새로고침이 드물고 모두가 drift를 참는 동안에는 “돌아가는 것처럼” 보입니다. 하지만 에이전트 시대에는 이 모델이 벽에 부딪힙니다.
안전하고, 격리되어 있고, 현실적인 데이터베이스 환경을 빠르게 만들 수 없는 워크플로는 바로 병목이 됩니다. 그리고 가장 비싼 부분은 compute가 아니라 잃어버린 반복 속도입니다.
이유는 간단합니다. staging은 기본적으로 prod와 멀어집니다. 데이터 분포는 달라지고, extension은 달라지고, 성능 특성도 변합니다. 사람은 경험과 감으로 메웁니다. 에이전트는 감이 없습니다. 입력값만 있습니다.
에이전트가 오래되었거나 비현실적인 데이터에서 마이그레이션을 검증하면, 그럴듯해 보이는 결과를 내놓더라도 실제 프로덕션 분포에서는 실패할 수 있습니다. 이것은 LLM 문제도, 사람 문제도 아닙니다. 컨텍스트 문제입니다. 그리고 컨텍스트 문제는 “더 좋은 프롬프트”로 해결되지 않습니다.
Vela의 모델은 셀프서비스, 진짜 격리, 빠른 branching, 쉬운 폐기를 중심으로 돌아갑니다. 개발자는 공용 staging을 위험에 빠뜨리지 않고 마이그레이션을 테스트할 수 있습니다. QA는 일정 충돌 없이 기능을 검증할 수 있습니다. 분석가는 프로덕션을 연명 장치에 올리지 않고 무거운 쿼리를 실행할 수 있습니다. 그리고 에이전트는 중요한 변경을 자동으로 검증하고 추천할 수 있습니다.
그리고 플랫폼 팀은 진짜 원하던 것을 얻습니다. 예측 가능성, 명확한 tenant 경계, 그리고 모두의 실험 때문에 온콜을 떠안지 않고도 “예”라고 말할 수 있는 능력입니다.
진짜 트릭은 스토리지다. 그래서 branching은 싸진다.
“branch마다 진짜 데이터베이스”는 비싸 보입니다. 하지만 Vela는 매번 테라바이트를 순진하게 복사하지 않습니다.
“Building an Agent-Ready Postgres Data Platform”에서 Rob은 이 워크로드에 맞는 구조를 설명합니다. shared-everything + copy-on-write (COW)입니다. 이 영상에서는 COW의 장점과 동작 방식도 설명합니다.
핵심 모델은 간단합니다. branches는 base snapshot을 공유하고, branch 생성은 메타데이터 작업이기 때문에 빠르며, 스토리지 오버헤드는 프로덕션 전체 크기가 아니라 각 branch가 실제로 얼마나 바뀌는지에 비례합니다.
Vela는 simplyblock을 분산 스토리지 엔진으로 사용하며, 이를 통해 스토리지 레이어의 copy-on-write semantics를 제공합니다.
바로 여기서 database branching은 특별 행사에서 일상적인 인프라로 바뀝니다. Git branch를 만드는 것과 비슷하지만, 데이터베이스이기 때문에 잘못했을 때의 비용이 더 큽니다.
이것은 에이전트 현실에도 더 잘 맞습니다. 가치 있는 에이전트 작업의 대부분은 read-heavy입니다. 스키마 분석, 분포 샘플링, 제약 검증, EXPLAIN 계획 실행, 마이그레이션 테스트. 이런 작업에는 프로덕션급 컨텍스트가 필요합니다. 이상적으로는 프로덕션 복사본이 필요합니다. 하지만 모든 프로덕션 데이터를 물리적으로 완전히 복사할 필요는 없습니다. COW는 바로 그 비대칭성을 활용하게 해 줍니다.
격리는 필요하지만, 아직 충분하지 않다
에이전트에게는 권한 경계도 필요합니다.
agent-ready blueprint는 매우 단호합니다. 역할 기반 접근 제어, quota 한도, 그리고 에이전트가 어디에서 행동할 수 있고 무엇을 바꿀 수 있는지를 제한하는 환경 수준 정책이 필요합니다.
“작업마다 하나의 branch”는 안전 경계지만, 플랫폼에는 여전히 거버넌스가 필요합니다. branch 전용 자격 증명, branch 범위 권한, 깔끔한 promote/discard 워크플로는 선택 사항이 아닙니다. 이것이 “에이전트가 일을 가속한다”와 “에이전트가 인시던트를 가속한다”의 차이입니다.
Vela는 격리를 1급 시민으로 다루기 때문에, branching 기본 기능도 “환경을 아무런 후폭풍 없이 버릴 수 있어야 한다”는 생각 위에 세워져 있습니다. Vela는 권한, 리소스 제한, VM 경계로 격리를 구현합니다.
그래서, database branching은 죽었는가?
그렇습니다.
오래된 버전은 죽었습니다. schema hack, dump/restore 의식, 사실은 비용 증폭기인 clone 버튼, “믿어 봐, 격리돼 있어” 방식 말입니다.
하지만 실제적이고, 안전하고, 빠른 기본 워크플로로서의 database branching은 이제 막 시작입니다.
재미있는 부분은, 지금 당장 혜택을 얻기 위해 완전한 MCP (Model Context Protocol) 배선이나 거대한 자율 런타임이 필요하지 않다는 점입니다. 이미 agentic하게 일하든 아직 직접 코드를 쓰든, 거대한 데이터셋에서 즉시 복제된 데이터베이스 branch는 제가 늘 원하던 변경 테스트, 수정 검증, 마이그레이션 확인 방식입니다. 이런 것을 대규모로 실제 해볼 기회는 없었습니다. 지금까지는요.
오늘부터 branch-first 습관을 들이고, 모든 마이그레이션 점검과 성능 조사, 위험한 실험을 신뢰할 수 있는 기준선에서 복제한 새 branch 위에서 수행한다면, 나중에 에이전트를 안전하게 사용하기 위한 토대를 이미 만들고 있는 것입니다. 현실적인 컨텍스트와 엄격한 격리가 마찰 없이 공존할 수 있다는 것을 증명하는 셈입니다.
Vela의 베팅은 단순합니다. Postgres는 계속 지루하게 두고, 경험만 더 이상 고통스럽지 않게 만든다.
branch-first Postgres가 어떤 느낌인지 보고 싶다면, Vela Sandbox에서 직접 branch를 만들어 보세요.