2.4 Merge와 운영 반영
분기 환경에서 변경을 검증한 뒤에는 무엇을 운영에 가져갈지 결정해야 합니다. 마이그레이션 파일과 수정한 일부 행은 서로 다른 반영 대상입니다. branch의 데이터 이력과 환경 전체도 각각 다른 대상입니다. 테스트가 통과했다는 사실만으로 반영 대상이 정해지지는 않습니다. 운영이 계속 바뀌는 동안 분기 결과를 어떻게 대조하고 반영할지 먼저 설계해야 합니다.
이 장에서는 데이터 3-way merge를 머지로 설명합니다. 이를 schema 배포, 승격, SQL MERGE와 구분합니다. 이후 쓰기 분기에서 운영으로 다시 합류하는 네 경로를 제안합니다. 이 경로 분류와 검토 절차는 공개 기능에 근거한 설계안입니다. 모든 제품이 같은 이름의 명령을 제공한다는 뜻은 아닙니다.
Merge라는 이름의 적용 범위
Dolt의 데이터 머지는 서로 갈라진 데이터 버전의 변경을 합치는 기능입니다. 공통 조상과 양쪽의 상태를 대조해 변경을 판별합니다. PlanetScale Vitess의 deploy request는 schema 배포 절차입니다. 개발 branch의 schema 변경을 운영에 배포합니다. 두 기능 모두 branch를 사용하지만 반영 대상과 충돌 판정 범위가 다릅니다.
이 장에서 승격은 특정 환경을 운영의 새 대상 또는 기준 환경으로 선택하는 동작을 뜻합니다. 구체적인 명령과 전환 절차는 제품별로 확인해야 합니다. 승격이라는 이름만으로 두 환경의 데이터 차이를 계산하고 합쳤다고 해석하지 않습니다. 원본이 계속 쓰기를 받았다면 새 환경이 그 변경을 어디까지 포함했는지 별도로 확인해야 합니다.
SQL MERGE는 source와 target의 조건을 대조하는 SQL입니다. 이 조건에 따라 target 행에 INSERT, UPDATE, DELETE 등을 수행합니다. PostgreSQL 문서는 source와 target의 join 결과를 동작의 근거로 설명합니다. WHEN 조건도 동작을 결정합니다. 데이터 버전 머지는 branch의 공통 조상이나 commit 계보를 자동 탐색합니다. SQL MERGE와는 처리 근거가 다릅니다. 같은 단어를 사용해도 입력 자료와 검토 조건을 따로 적습니다.
| 구분 | 입력 또는 기준 | 반영 대상 |
|---|---|---|
| 데이터 3-way merge | 공통 조상과 양쪽 데이터 버전 | 양쪽 변경을 대조한 데이터 상태 |
| Schema 배포 | 검토한 schema 차이 또는 마이그레이션 | 운영의 schema 변경 |
| 승격과 환경 전환 | 선택한 대상 환경과 전환 조건 | 운영 연결 및 쓰기 대상 |
SQL MERGE | Source, target, join과 조건 | Target 테이블의 행 |
이 표는 2026-09-30에 확인한 기능 설명을 바탕으로 용어를 대조한 것입니다. 데이터 머지 지원 여부만으로 schema 검증 환경의 가치를 판단하지 않습니다. 산출물이 재실행 가능한 마이그레이션이라면 운영 데이터 전체를 합칠 필요가 있는지 먼저 검토합니다. 반영할 산출물과 제품의 변경 기능이 일치해야 합니다.
공통 조상과 Cell 단위 머지
3-way merge에는 공통 조상과 반영 대상의 현재 버전이 필요합니다. 가져올 branch의 현재 버전도 필요합니다. 두 현재 상태만 비교하면 어느 쪽이 분기 후에 바뀌었는지 판단하기 어렵습니다. Dolt는 commit 이력의 공통 조상을 기준으로 양쪽 변경을 대조합니다. 같은 행을 양쪽에서 수정했을 때는 cell 단위의 변경을 고려합니다.
다음은 규칙을 설명하기 위한 가상 데이터입니다. 고객 등급과 알림 설정을 가진 행에서 부모는 등급을 바꾸고 자식은 알림 설정을 바꾼다고 가정합니다. 동일한 기본키를 수정했지만 변경한 컬럼이 다릅니다. 이처럼 서로 다른 cell의 변경은 자동으로 머지될 수 있습니다. 같은 행의 수정이 모두 충돌한다는 설명은 이 경우를 놓칩니다.
| 데이터 버전 | 고객 ID | 등급 | 알림 설정 |
|---|---|---|---|
| 공통 조상 | 101 | basic | |
| 부모 변경 | 101 | premium | |
| 자식 변경 | 101 | basic | sms |
| Cell 변경을 합친 값 | 101 | premium | sms |
반대로 같은 기본키의 같은 컬럼을 서로 다른 값으로 바꾸면 충돌 검토가 필요합니다. 한쪽의 삭제와 다른 쪽의 수정도 별도 충돌 사례입니다. 제약조건과 schema 충돌은 cell 값 비교와 구분합니다. 공식 문서의 자동 머지 범위를 넘어 모든 업무 규칙을 자동으로 검증한다고 설명하지 않습니다.
자동 머지 결과도 업무 검증이 필요합니다. 위 예에서 등급과 알림 방식의 조합에 별도 업무 정책이 있다고 가정합니다. 각 컬럼을 따로 수정한 테스트만으로는 합쳐진 상태를 검증했다고 보기 어렵습니다. 이는 해당 제품의 결함 주장이나 실제 고객 사고 사례가 아닙니다. 충돌 없는 데이터 결과와 업무적으로 허용되는 결과를 별도로 시험해야 하는 이유를 보여 주는 예입니다.
Dolt를 시험할 때는 서로 다른 행과 같은 행의 다른 컬럼을 나누어 기록하는 방법을 제안합니다. 같은 cell의 상이한 값, 삭제와 수정의 조합도 나누어 기록합니다. 각 결과에 사용한 commit과 최종 diff를 붙이면 재검토 기준이 남습니다. 실행 환경 구성은 기존 Dolt와 Doltgres 노트를 참고합니다. 다만 현재 머지 판정에는 이 장의 cell 기준과 공식 문서를 적용합니다.
Schema 배포와 검증 산출물
PlanetScale Vitess의 deploy request는 개발 branch의 schema diff를 검토합니다. 이를 배포 대상으로 전달합니다. 공식 문서는 대상 branch의 safe migrations 설정을 요구합니다. 배포 가능성 검사와 검토 절차도 설명합니다. 이 기능을 개발 branch에서 작성한 임의의 업무 데이터를 운영에 합치는 절차로 설명하지 않습니다. 검토 화면의 schema diff가 어떤 변경을 포함하는지 확인해야 합니다.
PlanetScale의 workflow 설명은 schema 충돌 검사를 제시합니다. 이 검사는 분기 당시 schema와 현재 운영 schema를 함께 고려합니다. 따라서 머지의 의미를 넓게 보면 Dolt 외에도 해당하는 기능이 있습니다. 데이터 값의 3-way merge와 schema 변경의 대조를 구분해 기능 범위를 적습니다. 이 Vitess 설명을 PlanetScale Postgres의 빈 branch에 자동 적용해서는 안 됩니다. backup 복원 branch에도 같은 제한이 적용됩니다.
Supabase의 branch workflow에서도 schema와 마이그레이션 배포를 다룹니다. 이때 생성 모드와 데이터 범위를 함께 확인해야 합니다. 기본 branch가 운영 데이터를 포함하지 않는다는 조건과 운영 반영 절차는 별도 항목입니다. 데이터 포함 옵션이 있다는 이유만으로 양쪽 업무 데이터의 자동 머지까지 제공한다고 해석하지 않습니다.
일반적인 마이그레이션 검증에서는 검증한 변경 파일과 실행 조건을 산출물로 삼는 방법을 제안합니다. 검증에 성공한 사본 전체보다 이 산출물을 우선합니다. 운영에 적용할 파일의 checksum, 실행 순서, 기준 schema, 테스트 결과를 연결합니다. 검증 후 파일이 달라지거나 운영 schema가 바뀌었다면 재검토 대상을 명확히 표시합니다. 변경 파일과 적용 대상이 각각 동일한지 함께 확인하는 것이 테스트 결과의 적용 범위를 설명하기 위한 전제입니다.
Schema 배포 과정에 필요한 데이터 변환도 별도 범위로 검토합니다. 컬럼을 추가하는 DDL과 그 컬럼을 채우는 작업이 한 릴리스에 있는 경우가 있습니다. 이때도 승인할 산출물과 검증 SQL을 구분해 적습니다. branch에서만 만든 테스트 행이나 임시 수정은 운영 반영 목록에서 제외해야 합니다. 이를 위해 변경 의도와 실행 결과를 대조하는 절차를 제안합니다. 이 절차를 특정 공급사의 내부 배포 정책으로 소개하지는 않습니다.
쓰기 분기 후 재수렴 경로
반영 경로는 분기를 만들 때 정하는 편이 좋습니다. 다음 그림은 검증 결과를 운영에 가져오는 네 가지 설계 경로입니다. 마이그레이션 재실행, 검토한 데이터 patch, 데이터 머지, 전체 전환을 구분합니다. 같은 작업에서 일부 경로를 함께 사용한다면 각각의 입력과 완료 조건도 따로 적습니다.
마이그레이션 재실행 경로는 운영 DB에 검증한 변경을 적용합니다. 여기서는 현재 운영 schema와 데이터 조건이 리허설의 전제와 맞는지 확인합니다. 리허설 이후 운영에 추가된 변경이 있다면 적용 순서를 다시 대조합니다. 준비한 파일이 같더라도 대상 상태가 달라졌다면 보고서에 표시합니다. 어떤 전제를 재확인했는지도 남기는 방법을 제안합니다.
데이터 patch 경로는 조사용 branch에서 찾은 일부 값을 운영에 반영할 때 검토합니다. 가져올 기본키와 값, 현재 운영에서 기대하는 값, 변경할 범위를 명시합니다. 같은 행이 운영에서 이미 바뀌었다면 그 차이를 검토 대상에 넣습니다. patch에 필요한 대조 조건은 작성자가 정의해야 합니다. SQL MERGE를 사용해도 공통 조상에 근거한 충돌 검토가 자동으로 추가되지는 않습니다.
데이터 머지 경로는 제품의 버전 관리 기능을 사용해 양쪽 이력을 대조합니다. 검토자는 기준 commit, 가져올 commit, 반영 대상 commit을 함께 기록합니다. 충돌을 해결한 뒤에는 해결 결과를 새로운 검증 대상으로 다룹니다. 양쪽 branch에서 따로 통과한 테스트와 합쳐진 상태의 테스트를 구분합니다. 최종 데이터 diff와 업무 검증 결과를 같은 반영 기록에 붙입니다.
전체 전환 경로에서는 검증한 환경을 새 운영 대상으로 선택합니다. 설계 단계에서 분기 이후 운영 쓰기를 어떻게 추종할지 정해야 합니다. 전환 조건과 기존 환경의 쓰기를 끝낼 시점도 정해야 합니다. 독립된 시점 사본만 준비한 상태라면 최신 변경을 포함했는지부터 대조합니다. 이 장은 모든 branch 제품에 지속 replication이나 자동 cutover가 있다고 가정하지 않습니다.
승격과 반영 완료 조건
승격의 승인 자료에는 운영 대상 변경과 데이터 상태 검증을 함께 담는 방법을 제안합니다. 새 환경의 접속 성공만으로 최신 변경 확인을 대신하지 않습니다. 전환 기준 시점과 포함되어야 할 마지막 업무 변경을 명시합니다. 연결 대상과 쓰기 허용 상태도 명시하면 운영자가 검토할 결과가 구체화됩니다. 제품이 제공하는 전환 기능과 직접 작성한 운영 절차도 구분해 남깁니다.
되돌리기 조건은 반영 경로에 맞게 따로 작성합니다. 데이터 patch는 반영 뒤 추가로 바뀐 행을 어떻게 대조할지 정합니다. schema 배포는 되돌릴 대상 변경의 범위를 어떻게 확인할지 정합니다. 전체 전환에서는 새 환경에서 시작한 쓰기를 기존 환경으로 어떻게 처리할지 검토합니다. 이전 환경을 남겼다는 사실만으로 데이터 손실 없는 복귀를 보장하지 않습니다.
반영 직전 운영 상태가 검토 당시와 달라졌다면 다시 대조하도록 절차를 설계합니다. 승인한 것이 파일인지, 데이터 diff인지, 특정 환경 상태인지 명시해야 재검토 범위를 정할 수 있습니다. 경로가 불분명한 상태에서 branch의 이름만 운영용으로 바꾸면 완료 판정의 근거가 부족합니다. 이름 변경과 실제 연결 및 데이터 상태를 별도로 확인합니다.
반영 후에는 적용 결과와 함께 남길 이력, 조사에 필요한 branch, 삭제 대상의 수명을 정합니다. 모든 검증 환경을 영구 보존하는 대신 목적에 맞는 증적을 선택하는 운영 정책을 제안합니다. 준비 시간과 자원 비용에서 구분한 compute 수명과 보존 비용을 함께 고려합니다. 최종 반영 기록에는 선택한 경로와 검증 결과를 남깁니다.