CS/기타

데이터 마이그레이션 설계 가이드: 점진적 전환, Outbox, Fix-forward

Joonfluence 2026. 7. 9.

데이터 마이그레이션 전략: 실무에서 사용하는 패턴과 롤백 전략 총정리

1. 문서 제목

2. 기술 개요

데이터 마이그레이션(Data Migration)은 기존 시스템의 데이터를 새로운 시스템으로 이전하는 작업이다. 단순히 데이터를 복사하는 것이 아니라, 서비스를 중단하지 않고 안정적으로 전환하는 것이 핵심 목표다.

실무에서는 다음 네 가지 질문을 중심으로 설계한다.

어떻게 나누어 옮길 것인가?
전환 기간 동안 신규 시스템과 레거시 시스템을 어떻게 함께 운영할 것인가?
실패했을 때 안전하게 재시도할 수 있는가?
문제가 발생하면 어떻게 대응할 것인가?

이 네 가지를 기준으로 대부분의 마이그레이션 전략을 설명할 수 있다.

3. 핵심 개념 정리

3.1 마이그레이션 방식

전략	설명	장점	단점
Big Bang	한 번에 전체 전환	구현 단순	실패 시 전체 영향
Incremental	일부씩 점진적으로 전환	장애 범위 최소화	운영 복잡도 증가
Strangler Fig	신규 시스템이 점진적으로 기존 시스템을 대체	대규모 시스템 교체에 적합	운영 기간이 길어짐

Big Bang

모든 데이터를 한 번에 이전하는 방식이다.

Legacy
   │
   ▼
Migration
   │
   ▼
New System

구현은 가장 단순하다.
서비스 중단이 필요한 경우가 많다.
실패하면 전체 서비스를 되돌려야 한다.

대규모 서비스에서는 거의 사용하지 않는다.

Incremental

대상을 여러 개의 작은 단위로 나누어 순차적으로 이전한다.

예를 들어

고객 ID
생성일
조직 단위
지역
퍼센트 롤아웃

등으로 나누어 진행한다.

Batch 1
Batch 2
Batch 3
Batch 4

장점은 매우 명확하다.

장애 영향 범위(Blast Radius)가 작다.
문제가 생긴 배치만 수정하면 된다.
운영 중에도 전환 가능하다.

실무에서 가장 많이 사용하는 방식이다.

Strangler Fig Pattern

기존 시스템을 한 번에 교체하지 않고 점진적으로 감싸면서 새로운 시스템으로 트래픽을 이동시키는 패턴이다.

Client
   │
   ▼
Gateway
 ├──── Legacy
 └──── New

시간이 지날수록 Legacy 비중은 줄고 New가 증가한다.

대형 레거시 시스템 교체에서 자주 사용된다.

3.2 전환 기간 운영 전략

Dual Write

가장 먼저 떠올리기 쉽지만 가장 위험한 전략이다.

Request

 ├── Legacy DB
 └── New DB

문제는 둘 중 하나만 실패해도 데이터가 달라진다는 것이다.

예를 들어

Legacy 성공

New 실패

즉시 데이터 불일치(Data Drift)가 발생한다.

따라서 Dual Write를 사용할 경우 반드시

재시도
보상 처리
Outbox

등이 함께 필요하다.

Parallel Change의 Migrate 단계에서 쓰는 폴백 조회

조회 시 신규 시스템을 우선 사용한다.

New 조회

있다 → 사용

없다 → Legacy 조회

즉

New

↓

Legacy

방향으로만 폴백한다.

반대로

Legacy

↓

New

로 돌아가는 경우는 거의 없다.

이 방식은 점진적 전환에 매우 적합하다.

Shadow Write / Shadow Read

실제 서비스는 Legacy를 계속 사용한다.

동시에

신규 시스템에도 동일한 데이터를 기록하거나
신규 시스템 결과를 계산해 비교한다.

Client

↓

Legacy Response

↓

New System (검증 전용)

사용자는 영향을 받지 않는다.

신규 시스템의 정확도를 검증하기 위해 많이 사용한다.

3.3 마이그레이션 트리거

대표적으로 세 가지 방식이 있다.

방식	설명
Event Driven	이벤트 발생 시 즉시 이전
Batch	주기적으로 이전
On-demand	요청 시 Lazy Migration

실무에서는 여러 방식을 함께 사용하는 경우가 많다.

예를 들어

신규 가입자는 Event 기반
기존 고객은 Batch
오래된 데이터는 On-demand

처럼 혼합한다.

3.4 안정적인 재시도: Outbox Pattern

마이그레이션은 네트워크 오류나 일시적인 장애로 중간에 실패할 수 있다.

이때 가장 많이 사용하는 패턴이 Outbox이다.

대표적인 상태 머신은 다음과 같다.

PENDING

↓

PROCESSING

↓

COMPLETED

실패하면

FAILED

↓

Retry

↓

PROCESSING

재시도를 반복한다.

재시도 횟수를 초과하면

DEAD_LETTER

상태로 이동하여 운영자가 확인한다.

일반적으로

Exponential Backoff
Idempotency
At-least-once Processing

과 함께 사용한다.

3.5 Verification / Reconciliation

마이그레이션이 끝났다고 해서 끝이 아니다.

신규 데이터와 기존 데이터를 지속적으로 비교해야 한다.

대표적인 작업은

Row Count 비교
Checksum 비교
주요 컬럼 비교
샘플링 검증
불일치 알림

이다.

이를 Reconciliation이라고 부른다.

4. 롤백 전략

실무에서 "완전한 롤백"은 거의 구현하지 않는다

많은 면접에서

롤백은 어떻게 했나요?

라는 질문이 나온다.

하지만 실무에서는 자동 양방향 롤백을 구현하는 경우가 매우 드물다.

그 이유는 레거시로 되돌리는 로직 자체가 또 하나의 마이그레이션이기 때문이다.

즉

Migration

+

Reverse Migration

두 개를 모두 검증해야 한다.

비용이 너무 크다.

실무에서 사용하는 대응 전략

1. Kill Switch

가장 먼저 사용하는 대응이다.

Migration Enabled

↓

OFF

새로운 마이그레이션만 중단한다.

이미 이전된 데이터는 그대로 유지한다.

확산을 막는 것이 목적이다.

2. Blast Radius 최소화

처음부터 Incremental Migration을 사용하면

100만 명

↓

1,000명 단위

처럼 영향 범위를 제한할 수 있다.

따라서 문제가 생겨도 일부 고객만 수정하면 된다.

3. Fix-forward

가장 많이 사용하는 전략이다.

롤백 대신

잘못된 데이터를 수정한다.

Wrong Data

↓

Correction

↓

Correct State

특히 Append-only 구조에서는 (롤백 개념 자체가 성립하지 않으므로) fix-forward에 가까운 대응이 더 자연스럽다.

Append-only 시스템에서의 롤백

Append-only 시스템은 과거 데이터를 수정하지 않는다.

예를 들어

입금

출금

취소

처럼 새로운 이벤트를 추가한다.

즉

Rollback

이 아니라

Compensation Event

를 추가한다.

결제

정산

재고

회계

등에서는 매우 일반적인 설계이다.

5. 실무 사례 예시

다음은 실제, 와이즐리의 멤버십 V2 → V3 마이그레이션 사례를 기준으로 정리한 예시이다.

개념	적용 사례
Incremental Migration	갱신 주기가 도래한 고객부터 배치 단위로 순차 전환
Read-path Fallback	V3 데이터를 우선 조회하고, 없을 경우에만 V2를 조회하는 단방향 폴백
Outbox Pattern	PENDING → PROCESSING → COMPLETED / FAILED / DEAD_LETTER 상태 머신 기반 재시도
Kill Switch	신규 마이그레이션만 중단하는 Feature Flag 운영
Fix-forward	관리자 도구를 이용한 개별 데이터 정정(Reconciliation)
Production Safety	운영 환경에서 위험한 삭제 작업을 코드 수준에서 차단

핵심 설계 포인트

멤버십 마이그레이션 사례에서 중요한 점은 완전한 자동 롤백을 구현하지 않았다는 것이다.

대신 다음과 같은 전략을 선택했다.

Feature Flag(Kill Switch)로 신규 전환을 즉시 중단한다.
점진적 마이그레이션으로 장애 영향 범위를 제한한다.
이미 전환된 데이터는 관리자 도구를 통해 필요한 대상만 수정(Fix-forward)한다.

이는 운영 비용과 안정성을 모두 고려한 현실적인 설계이며, Append-only 기반의 데이터 모델과도 잘 맞는 접근 방식이다.

6. Best Practice

Big Bang보다 Incremental Migration을 우선 고려한다.
Dual Write는 Outbox나 메시지 기반 재시도 없이 사용하지 않는다.
Feature Flag(Kill Switch)를 준비하여 신규 전환을 즉시 차단할 수 있도록 한다.
조회는 신규 우선, 레거시 폴백(Read-path Fallback) 구조를 사용한다.
마이그레이션 작업은 Idempotent하게 구현하여 안전하게 재시도할 수 있도록 한다.
Reconciliation 작업을 통해 지속적으로 데이터 정합성을 검증한다.
자동 양방향 롤백보다 Fix-forward 전략을 우선 검토한다.
Append-only 도메인에서는 보정 이벤트(Compensation Event)를 추가하는 방식으로 정합성을 유지한다.

7. 기술 면접 핵심 질문

Q. 데이터 마이그레이션은 어떤 방식으로 진행하는 것이 좋나요?

대부분의 서비스에서는 Big Bang보다 Incremental Migration을 선택합니다. 장애 영향 범위를 줄일 수 있고, 문제 발생 시 일부 대상만 수정하면 되기 때문입니다.

Q. 롤백은 어떻게 구현했나요?

완전한 자동 양방향 롤백은 구현하지 않았습니다. 대신 Feature Flag로 신규 전환을 즉시 중단하고, 점진적 마이그레이션으로 영향 범위를 최소화했으며, 이미 전환된 데이터는 관리자 도구를 활용한 Fix-forward 방식으로 개별 정정했습니다.

Q. Dual Write를 사용하면 어떤 문제가 발생하나요?

한쪽 저장소만 성공하는 경우 데이터 불일치가 발생합니다. 따라서 Outbox Pattern, 재시도 전략, 멱등성(Idempotency)을 함께 설계해야 안전하게 운영할 수 있습니다.

Q. Fix-forward가 Google SRE 권장 방식 아닌가요?

아니요, 정확히는 반대입니다. Google SRE 원문은 장애 대응 시 원인 분석보다 먼저 롤백을 하라고 명시적으로 권장합니다 — 롤백이 패치보다 빠르고 신뢰도가 높다는 이유입니다. 다만 여기서 다루는 도메인은 append-only 원장 기반이라, SRE가 전제하는 "이전 버전으로 되돌리는 롤백" 자체가 구조적으로 성립하지 않습니다. 그래서 신규 확산만 kill switch로 막고, 이미 발생한 건은 보정 트랜잭션을 추가하는 fix-forward에 가까운 방식을 대안으로 쓴 것입니다.

8. 참고 자료 / 공식 문서

Martin Fowler, Strangler Fig Application — https://martinfowler.com/bliki/StranglerFigApplication.html
Martin Fowler, Feature Toggle — https://martinfowler.com/articles/feature-toggles.html
Chris Richardson, Transactional Outbox Pattern — https://microservices.io/patterns/data/transactional-outbox.html
Google SRE, Effective Troubleshooting — https://sre.google/sre-book/effective-troubleshooting/ (장애 시 원인분석보다 안정화·롤백 우선을 명시)
Google SRE, Configuration Design — https://sre.google/workbook/configuration-design/ ("롤백이 패치보다 빠르고 신뢰도 높다"고 롤백을 명시적으로 우선 권장 — "Fix-forward가 SRE 철학"이라는 통념은 이 원문과 반대이므로 인용 시 주의)
Martin Fowler / refactoring.com, Parallel Change (Expand and Contract) — https://martinfowler.com/bliki/ParallelChange.html
Microsoft Azure Architecture Center, Data Migration Guide — https://learn.microsoft.com/azure/architecture/
AWS Prescriptive Guidance, Database Migration Strategies — https://docs.aws.amazon.com/prescriptive-guidance/

핵심 요약

실무에서 데이터 마이그레이션의 핵심은 "안전하게 이전하는 것"이다. 이를 위해 점진적 전환(Incremental Migration), 신규 우선 조회(Read-path Fallback), Outbox 기반 재시도, 지속적인 데이터 검증(Reconciliation)을 조합해 사용한다. 또한, 자동 양방향 롤백보다는 Kill Switch로 확산을 차단하고 Fix-forward로 필요한 데이터만 정정하는 전략이 운영 비용과 안정성 측면에서 더 현실적이며, 특히 Append-only 기반 시스템에서는 보정 이벤트를 추가하는 방식이 가장 성숙한 설계로 평가된다.

저작자표시 비영리 (새창열림)

'CS > 기타' 카테고리의 다른 글

Webpack에서 Vite로: CRA 마이그레이션 시 발생하는 문제와 해결 전략 (0)	2026.03.22
안쓰면 자꾸 헷갈리는 Cron 표현식 정리하기 (0)	2025.05.22
[대규모 시스템 설계 기초 2] 11장. 결제 시스템 파헤치기 (1)	2024.04.26
[대규모 시스템 설계 기초 2] 7장. 호텔 예약 시스템 파헤치기 (2)	2024.04.23
Redis에 대해 알아보자 (자료구조, Cache) (0)	2024.04.14

데이터 마이그레이션 설계 가이드: 점진적 전환, Outbox, Fix-forward

데이터 마이그레이션 전략: 실무에서 사용하는 패턴과 롤백 전략 총정리

1. 문서 제목

2. 기술 개요

3. 핵심 개념 정리

3.1 마이그레이션 방식

Big Bang

Incremental

Strangler Fig Pattern

3.2 전환 기간 운영 전략

Dual Write

Parallel Change의 Migrate 단계에서 쓰는 폴백 조회

Shadow Write / Shadow Read

3.3 마이그레이션 트리거

3.4 안정적인 재시도: Outbox Pattern

3.5 Verification / Reconciliation

4. 롤백 전략

실무에서 "완전한 롤백"은 거의 구현하지 않는다

실무에서 사용하는 대응 전략

1. Kill Switch

2. Blast Radius 최소화

3. Fix-forward

Append-only 시스템에서의 롤백

5. 실무 사례 예시

핵심 설계 포인트

6. Best Practice

7. 기술 면접 핵심 질문

Q. 데이터 마이그레이션은 어떤 방식으로 진행하는 것이 좋나요?

Q. 롤백은 어떻게 구현했나요?

Q. Dual Write를 사용하면 어떤 문제가 발생하나요?

Q. Fix-forward가 Google SRE 권장 방식 아닌가요?

8. 참고 자료 / 공식 문서

핵심 요약

'CS > 기타' 카테고리의 다른 글

댓글

티스토리툴바