Bubble.io 버전 관리와 Live 배포｜DB 마이그레이션 실수 방지 가이드

2026년 10월 2일 읽는 시간 약 15분

Bubble.io로 서비스를 만들다 보면 Development 화면에서는 정상적으로 작동했는데 Live 배포 후 데이터가 보이지 않거나, 기존 사용자의 정보가 사라질까 봐 배포 버튼을 누르기 망설여질 때가 있습니다. 이런 문제는 Bubble의 버전 관리가 일반적인 Git과 비슷해 보이지만, 앱의 변경 사항과 데이터베이스의 실제 레코드를 서로 다르게 관리한다는 점에서 발생합니다.

이번 글에서는 Bubble의 브랜치와 배포 구조를 쉽게 정리하고, Live 서비스의 데이터를 보호하면서 데이터 구조를 변경하는 방법을 단계별로 살펴보겠습니다.

Bubble 버전 관리는 Git과 무엇이 다를까

Bubble의 버전 관리는 여러 작업 공간에서 기능을 개발하고, 변경 사항을 합친 뒤 운영 환경에 배포할 수 있다는 점에서 Git과 닮았습니다. Main과 사용자 정의 브랜치를 이용하면 새로운 기능이나 디자인 개편 작업을 기존 서비스와 분리할 수 있습니다.

하지만 Bubble의 브랜치는 소스코드 파일을 직접 추적하는 Git 저장소와는 다릅니다. 페이지 디자인, 워크플로우, 데이터 타입과 필드, 플러그인 설정 등 에디터에서 만든 앱의 정의를 Bubble 플랫폼 안에서 관리합니다. 따라서 Git의 commit, push, pull과 완전히 같은 개념으로 접근하면 배포 과정에서 혼란이 생길 수 있습니다.

구분	Git 기반 개발	Bubble 버전 관리
변경 대상	소스코드와 설정 파일	페이지, 워크플로우, 데이터 구조, 앱 설정
작업 분리	브랜치	Main, 사용자 정의 브랜치, Hotfix
변경 통합	Merge 또는 Rebase	브랜치 병합과 충돌 해결
운영 반영	빌드 후 서버 배포	Main 또는 Hotfix를 Live에 배포
데이터 관리	별도 DB 도구 사용	Development DB와 Live DB가 분리됨

중요한 점은 버전 배포와 데이터 복사는 별개의 작업이라는 사실입니다. 앱을 Live에 배포했다고 해서 Development에서 만든 테스트 상품, 게시물, 사용자 등의 레코드가 자동으로 Live 데이터베이스에 복사되지는 않습니다.

Development와 Live 데이터베이스는 서로 분리되어 있다

Bubble 앱에는 기본적으로 Development 환경과 Live 환경이 있으며, 각 환경은 독립된 데이터베이스를 사용합니다.

Development 데이터베이스: 기능 개발과 테스트에 사용
Live 데이터베이스: 실제 고객과 운영 데이터가 저장되는 공간

예를 들어 Development 환경에서 Product 타입에 샘플 상품 20개를 입력한 뒤 앱을 배포해도 Live에서 해당 상품이 자동으로 나타나지 않습니다. 배포는 앱의 화면, 워크플로우, 설정 및 데이터 구조를 반영하는 작업이며, 데이터베이스에 저장된 개별 레코드는 독립적으로 유지되기 때문입니다.

반대로 Live에서 신규 회원이 가입하거나 주문을 생성해도 그 레코드는 Development에서 바로 보이지 않습니다. 운영 데이터를 이용해 테스트해야 한다면 필요한 범위를 판단한 후 별도의 데이터 복사 기능을 사용해야 합니다.

Live 배포 시 실제로 반영되는 것

일반적으로 Development의 Main 브랜치를 Live에 배포하면 다음과 같은 앱 변경 사항이 운영 환경에 반영됩니다.

페이지와 재사용 요소의 디자인
프런트엔드 및 백엔드 워크플로우
데이터 타입과 필드 구조
Privacy Rules와 API 관련 설정
Option Sets와 일부 앱 설정
설치된 플러그인 및 플러그인 설정 변경

그러나 Development 데이터베이스에 저장된 실제 레코드는 자동으로 옮겨지지 않습니다. 따라서 데이터 타입을 새로 만들었다면 Live에도 그 구조는 생기지만, 테스트용으로 입력한 내용까지 함께 생성되는 것은 아닙니다.

가장 위험한 실수는 데이터 복사 방향을 거꾸로 선택하는 것이다

Bubble의 Data 탭에는 Development와 Live 사이의 데이터를 복사할 수 있는 기능이 있습니다. 이 기능은 전체 데이터베이스 또는 선택한 데이터 타입을 한쪽 환경에서 다른 쪽으로 덮어쓸 때 사용합니다.

문제는 복사가 단순한 병합이 아니라 대상 데이터의 덮어쓰기로 작동할 수 있다는 점입니다. Development의 테스트 데이터를 Live로 복사하면서 전체 데이터 타입을 선택하면, 실제 회원이나 주문처럼 보존해야 할 운영 데이터에 영향을 줄 수 있습니다.

따라서 다음 두 버튼의 방향을 반드시 구분해야 합니다.

Live 데이터를 Development로 복사: 실제 데이터와 비슷한 조건에서 테스트할 때 사용
Development 데이터를 Live로 복사: 초기 기준 데이터 등을 운영 환경으로 옮길 때 제한적으로 사용

운영 중인 앱에서는 전체 데이터베이스를 Development에서 Live로 복사하는 방식을 습관처럼 사용하면 안 됩니다. 국가 코드, 상품 분류, 공지 템플릿처럼 범위가 분명한 기준 데이터만 선택적으로 이전하는 편이 안전합니다.

데이터 구조 변경은 단계적으로 진행해야 한다

운영 중인 앱의 필드 이름이나 데이터 타입을 한 번에 바꾸면 기존 워크플로우와 레코드 사이의 연결이 끊길 수 있습니다. 특히 기존 필드를 삭제한 다음 같은 이름의 필드를 다시 만들어도 내부적으로는 다른 필드로 취급될 수 있으므로 주의해야 합니다.

안전한 변경은 다음 순서로 진행합니다.

1단계 새 필드를 추가한다

기존 필드를 바로 삭제하지 말고 새로운 필드를 먼저 만듭니다. 예를 들어 User의 name 필드를 display_name으로 바꾸고 싶다면, 우선 display_name 필드를 추가합니다.

2단계 기존 데이터를 새 필드로 옮긴다

Backend Workflow 또는 Data 탭의 Bulk 기능을 이용해 기존 레코드의 name 값을 display_name으로 복사합니다. 처리 대상이 많다면 한 번에 모든 레코드를 수정하기보다 작은 묶음으로 나누고, 실패한 항목을 확인할 수 있도록 로그 필드를 두는 것이 좋습니다.

3단계 읽기 로직을 전환한다

화면과 워크플로우가 새 필드를 읽도록 수정합니다. 마이그레이션이 진행되는 동안에는 새 필드가 비어 있을 경우 기존 필드를 대신 읽는 임시 표현식을 사용할 수 있습니다.

예시 흐름은 다음과 같습니다.

display_name이 비어 있지 않으면 display_name 표시 → 비어 있으면 기존 name 표시

4단계 충분히 검증한 뒤 쓰기 로직을 전환한다

회원가입, 프로필 수정, API 요청 등 데이터를 생성하거나 수정하는 모든 지점이 새 필드에 값을 쓰는지 확인합니다. 백엔드 워크플로우와 관리자 전용 기능도 빠뜨리지 않아야 합니다.

5단계 기존 필드는 나중에 제거한다

Live에서 일정 기간 오류가 없는지 확인한 뒤 기존 필드를 삭제합니다. 바로 삭제하지 않고 한동안 호환용으로 유지하면 롤백이 필요할 때 대응하기 쉽습니다.

데이터 타입 변경 시 이중 필드를 활용하는 이유

텍스트 필드를 숫자나 다른 데이터 타입으로 직접 바꾸려는 경우 기존 값의 형식이 맞지 않아 오류가 생길 수 있습니다. 이런 상황에서도 기존 필드를 즉시 변경하기보다 새 필드를 만들어 변환된 값을 저장하는 방식이 안전합니다.

예를 들어 price_text에 19,900원이라는 문자열이 저장되어 있다면 쉼표와 통화 문자를 제거한 뒤 숫자형 price_number에 기록해야 합니다. 일부 값이 무료, 가격 문의처럼 숫자로 변환할 수 없는 형태일 수도 있으므로 예외 처리 기준도 먼저 정해야 합니다.

권장 절차는 다음과 같습니다.

새 데이터 타입에 맞는 필드를 추가합니다.
변환 가능한 값과 예외 값을 구분합니다.
소량의 데이터로 변환 워크플로우를 시험합니다.
전체 데이터를 나누어 마이그레이션합니다.
변환 전후의 레코드 수와 합계 등을 비교합니다.
앱의 참조를 새 필드로 바꿉니다.
안정화 기간 이후 기존 필드를 정리합니다.

배포 전 반드시 확인할 체크리스트

버전과 브랜치 확인

현재 수정 중인 브랜치가 Main인지 사용자 정의 브랜치인지 확인
다른 브랜치의 변경 사항과 충돌 여부 확인
배포 설명에 변경 목적과 영향 범위 기록
필요하면 배포 직전 사용자 정의 Savepoint 생성

데이터베이스 확인

Data 탭에서 현재 보고 있는 환경이 Development인지 Live인지 확인
데이터 복사 방향과 대상 데이터 타입 재확인
운영 데이터의 백업 또는 복구 가능 시점 확인
대량 수정 전 테스트 레코드로 워크플로우 검증
User, 주문, 결제, 구독 데이터는 전체 복사 대상에서 제외

기능과 보안 확인

Privacy Rules가 Live 데이터에서도 정상 작동하는지 점검
관리자와 일반 사용자 계정으로 각각 테스트
API 키와 외부 서비스의 테스트용·운영용 설정 구분
예약된 Backend Workflow의 중복 실행 여부 확인
삭제하거나 이름을 바꾼 필드를 참조하는 워크플로우 검색

배포 후 확인

핵심 페이지가 정상적으로 열리는지 확인
회원가입, 로그인, 저장, 검색 기능을 실제 Live에서 점검
브라우저 콘솔과 Bubble 서버 로그의 오류 확인
레코드 수와 주요 데이터 합계 비교
오류가 생겼을 때 되돌릴 기준과 담당자 확인

안전한 데이터 마이그레이션 예시

쇼핑 앱의 Order 데이터에 status_text라는 텍스트 필드가 있고, 이를 OrderStatus라는 Option Set 기반 필드로 바꾼다고 가정해 보겠습니다.

먼저 status_v2 필드를 추가하고, 기존 값과 새 옵션의 대응표를 작성합니다.

기존 값	새 Option Set
paid	PAID
preparing	PREPARING
shipped	SHIPPED
canceled	CANCELED

그다음 Backend Workflow가 한 번에 하나의 Order를 처리하도록 만들고, 기존 값에 맞는 옵션을 status_v2에 기록합니다. 대응되는 값이 없는 레코드는 강제로 변환하지 않고 migration_error 같은 점검용 필드나 별도 로그에 남깁니다.

일부 데이터로 먼저 실행한 뒤 성공 건수와 오류 건수를 확인합니다. 문제가 없다면 처리량을 조절하며 전체 데이터에 적용합니다. 화면과 검색 조건이 status_v2를 사용하도록 바꾸고 Live에서 정상 작동하는 것을 확인한 뒤에만 기존 status_text를 정리합니다.

이 과정은 시간이 조금 더 걸리지만, 기존 주문을 잃지 않고 중간에 되돌릴 수 있다는 장점이 있습니다.

Live 데이터를 Development로 복사할 때도 개인정보에 주의해야 한다

운영 데이터를 Development로 복사하면 개발자나 협업자가 실제 사용자 정보를 접할 수 있는 범위가 넓어질 수 있습니다. 테스트 편의를 위해 전체 데이터를 복제하기보다 필요한 데이터 타입만 선택하고, 가능하다면 이름·이메일·전화번호 등의 개인정보를 익명화한 테스트 데이터를 사용하는 것이 좋습니다.

또한 Development 환경은 비밀번호로 보호하고, 협업자 권한과 Privacy Rules를 함께 점검해야 합니다. 운영 데이터를 복사한 뒤 테스트용 이메일이나 알림 워크플로우가 실제 고객에게 실행되지 않도록 발송 조건도 확인해야 합니다.

데이터베이스 복원 기능을 최후의 수단으로 봐야 하는 이유

Bubble의 데이터베이스 복원은 대량 삭제나 심각한 데이터 손상에서 유용하지만, 선택한 시점 이후에 생성된 정상 데이터까지 사라질 수 있습니다. 복원 자체가 모든 문제를 자동으로 해결하는 버튼은 아닙니다.

복원이 필요하다면 다음 사항을 먼저 기록하는 것이 좋습니다.

문제가 시작된 정확한 시간
영향을 받은 데이터 타입과 레코드 범위
복원 시 사라질 수 있는 신규 주문과 회원 데이터
복원 대신 CSV 재입력이나 선택적 수정으로 해결할 수 있는지 여부
외부 결제·메일·CRM 서비스와 데이터가 어긋날 가능성

운영 DB 전체를 과거 시점으로 되돌리기 전에 최근 정상 데이터를 별도로 보존하고, 외부 시스템과의 재동기화 계획까지 준비해야 합니다.

자주 묻는 질문

Live에 배포하면 Development 데이터도 함께 이동하나요

아닙니다. 배포는 앱의 구조와 동작 변경을 운영 환경에 반영하지만, Development DB에 저장된 실제 레코드는 자동으로 Live DB에 복사되지 않습니다. 필요한 데이터는 범위를 정해 별도로 이전해야 합니다.

필드를 추가하면 기존 Live 데이터가 삭제되나요

일반적으로 새 필드를 추가하는 것만으로 기존 레코드가 삭제되지는 않습니다. 다만 새 필드는 기존 레코드에서 비어 있으므로, 필수 로직에서 바로 사용하면 예상하지 못한 오류가 생길 수 있습니다. 기본값과 이전 데이터 처리 방식을 함께 준비해야 합니다.

필드 이름을 바꾸면 기존 데이터도 없어지나요

단순한 이름 변경과 필드 삭제 후 재생성은 결과가 다를 수 있습니다. 중요한 운영 필드는 새 필드를 추가한 후 값을 복사하고 참조를 전환하는 단계적 방식을 권장합니다.

Development의 기준 데이터만 Live로 옮길 수 있나요

Bubble의 데이터 복사 화면에서 특정 데이터 타입을 선택할 수 있습니다. 다만 대상 환경의 같은 타입 데이터를 덮어쓸 수 있으므로, 기존 Live 레코드가 있는지 먼저 확인해야 합니다. 몇 개의 레코드만 추가하려면 CSV 또는 관리용 워크플로우 등 더 세밀한 방법이 적합할 수 있습니다.

Option Sets도 데이터베이스 레코드인가요

Option Sets는 일반 DB 레코드와 성격이 다르며 앱 정의의 일부로 관리됩니다. 변경 사항은 배포해야 Live에서 사용할 수 있습니다. 민감한 값은 Option Sets에 저장하지 않는 것이 원칙입니다.

마무리

Bubble.io의 버전 관리는 코드 없이도 브랜치, 병합, Savepoint, Live 배포를 관리할 수 있다는 장점이 있습니다. 그러나 안전한 운영을 위해서는 앱 버전과 데이터베이스 레코드를 서로 다른 대상으로 이해해야 합니다.

Live 배포는 앱의 구조와 로직을 반영하는 작업이고, 데이터 복사는 실제 레코드를 다른 환경으로 옮기는 작업입니다. 이 둘을 구분하고, 새 필드 추가 → 데이터 이관 → 읽기·쓰기 전환 → 검증 → 기존 필드 정리 순서를 지키면 운영 중인 서비스에서도 데이터 손실 위험을 크게 낮출 수 있습니다.