모든 것을 망가뜨리지 않고 레거시 시스템을 점진적으로 마이그레이션하는 방법

레거시 시스템 마이그레이션: Strangler Fig 패턴 완전 가이드

빅뱅 방식의 재작성(Big-Bang Rewrites)이 실패하는 이유

빅뱅 방식의 재작성은 예측 가능한 이유로 실패합니다. 재작성하는 동안에도 레거시 시스템은 계속 진화하며(움직이는 목표), 프로덕션 코드에 숨겨진 문서화되지 않은 예외 케이스(edge cases)가 너무 늦게 드러나며, 몇 달 동안 아무것도 출시하지 못한 채 팀의 동기부여가 저하되고, 결국 두 개의 시스템을 유지하는 것이 영구적인 상태가 되어버립니다. 누군가 프로덕션 시스템의 전체 재작성을 제안한다면, 기본 답변은 "아니오"여야 합니다. 점진적 마이그레이션(incremental migration)이 왜 작동하지 않는지를 증명해야 하는 입증 책임은 제안자에게 있습니다.

Strangler Fig 패턴 설명

Strangler Fig(교살 무화과) 패턴은 기존 시스템을 계속 실행 상태로 유지하면서 특정 기능을 새로운 애플리케이션으로 점진적으로 교체함으로써 레거시 시스템을 점진적으로 마이그레이션합니다. 숙주 나무를 둘러싸고 자라나 결국 숙주를 대체하는 나무의 이름에서 유래한 이 접근 방식은, 위험한 빅뱅 방식의 재작성을 시도하는 대신 조각조각 현대화할 수 있게 해줍니다.

작동 방식

단계	발생하는 일	기간
설정 (Setup)	레거시 시스템 앞에 라우팅 계층(proxy/façade)을 배치합니다. 트래픽의 100%를 레거시로 라우팅합니다.	2주
...

프록시(proxy) 계층은 요청을 가로채서 레거시 시스템 또는 새로운 서비스로 라우팅합니다. 클라이언트의 관점에서는 URL, 요청 형태, 인증 방식이 동일하므로 아무것도 변하지 않습니다.

단계별 구현

1. 레거시 시스템 매핑

주요 기능(capabilities)과 그 사이의 경계를 식별합니다. 요청을 가로챌 수 있는 위치를 찾으세요. 첫 번째 후보를 선정할 때는 경계가 명확한 기능(bounded capability), 가치가 있는 기능, 그리고 리스크가 낮은 기능을 기준으로 적용합니다.

2. 라우팅 계층을 먼저 구축

무엇인가를 마이그레이션하기 전에, 시스템 간에 요청을 라우팅할 인프라를 설정합니다. 웹 애플리케이션의 경우 리버스 프록시(reverse proxy) 또는 로드 밸런서(load balancer)를 사용하세요. 처음에는 요청의 100%를 레거시 시스템으로 전달하고 라우팅 계층이 아무것도 망가뜨리지 않는지 확인합니다.

3. 격리된 환경에서 새로운 컴포넌트 개발 (Develop New Components in Isolation)

각 슬라이스(slice)에 대해, 현대적인 기술을 사용하여 기존 기능을 복제하는 새로운 컴포넌트를 개발합니다. 상대적으로 격리된 기능 단위부터 시작하세요.

4. 점진적인 트래픽 라우팅 (Route Traffic Gradually)

새로운 컴포넌트가 준비되면, 기존 컴포넌트 대신 간접 계층(indirection layer)을 통해 라우팅을 구현합니다. 트래픽을 단계별로 늘리세요: 1%, 10%, 50%, 100%.

5. 반복 및 기존 컴포넌트 폐기 (Iterate and Retire Old Components)

추가되는 각 기능에 대해 이 사이클을 반복합니다. 새로운 컴포넌트가 역할을 넘겨받음에 따라, 기존 컴포넌트는 불필요해지며 폐기할 수 있습니다.

마이그레이션 제어를 위한 피처 플래그 (Feature Flags for Migration Control)

피처 플래그(Feature flags)는 전환을 관리하고 마이그레이션 리스크를 완화하는 데 필수적입니다. 엔드포인트를 레거시에서 현대적인 시스템으로 한 번에 바꾸지 마세요. 피처 플래그를 사용하여 트래픽을 점진적으로 전환해야 합니다:

주차	현대적 시스템으로의 트래픽	모니터링 항목
1	내부 팀 전용	에러율, 응답 시간, 데이터 일관성
...

어느 시점에서든 에러나 성능 저하가 발견되면 즉시 플래그를 다시 되돌리세요. 내부 팀부터 시작하여, 가장 작거나 새로운 사용자 순으로 진행하세요. 이들은 데이터가 가장 적고, 엣지 케이스(edge cases)가 가장 적으며, 문제에 대한 허용도가 가장 높습니다. 가장 크고 복잡한 계정은 마지막에 마이그레이션하세요.

데이터 마이그레이션 전략 (Data Migration Strategies)

코드 마이그레이션은 데이터 마이그레이션에 비해 직관적입니다. 코드는 상태가 없지만(stateless), 데이터는 상태를 가집니다(stateful). 즉, 새로운 스키마(schema)에 데이터를 한 번 쓰고 나면, 롤백(rolling back)한다는 것은 데이터를 역으로 마이그레이션해야 함을 의미합니다.

조정(Reconciliation)을 동반한 이중 쓰기 (Dual-Write with Reconciliation (Proven Approach))

1. 새로운 시스템이 새로운 데이터베이스(향후 신뢰할 수 있는 단일 원천, source of truth)에 기록합니다.
2. 또한 레거시 데이터베이스에도 기록합니다(전환 기간 동안 레거시 시스템의 일관성을 유지합니다).
3. 백그라운드 작업(background job)이 과거 데이터를 배치(batch) 단위로 마이그레이션합니다.
4. 조정 작업(reconciliation job)이 기존 데이터와 새 데이터를 비교하여 불일치 사항을 표시합니다.

조정 작업(reconciliation job)은 레거시 시스템에 문서화되지 않은 모든 가정(timezone conversions, currency rounding differences, inconsistently handled nullable fields 등)을 발견하게 되는 지점입니다. 데이터 마이그레이션(data migration)에는 예상보다 두 배의 시간을 할당하십시오. 한 프로젝트에서는 코드 마이그레이션(code migration)에 3개월이 걸린 반면, 데이터 마이그레이션과 조정 작업에는 4개월이 소요되었습니다.

데이터 마이그레이션 전략 옵션 (Data Migration Strategy Options)

전략	설명	다운타임 (Downtime)	리스크 (Risk)
Big Bang	계획된 다운타임 동안 모든 데이터를 한 번에 전송	높음	높음
...

데이터 무결성을 위한 모범 사례 (Best Practices for Data Integrity)

• 체크섬(checksums)과 레코드 수(record counts)를 사용하여 데이터 무결성(data integrity)을 확인하십시오.
• 모든 마이그레이션 스크립트에 대해 버전 관리(version control)를 적용하여 데이터 무결성을 보존하십시오.
• 모든 것을 문서화하십시오. 근본 원인 분석(root cause analysis)을 위해 완전한 로그를 유지하십시오.
• 매핑 버그(mapping bugs)를 조기에 발견할 수 있도록 첫 달부터 조정 작업을 조기에 시작하십시오.

다운타임 최소화 및 처리 (Minimizing and Handling Downtime)

마이그레이션 전 계획 (Pre-Migration Planning)

• 상세한 일정과 리소스 할당을 포함한 포괄적인 마이그레이션 계획을 수립하십시오.
• 사용량이 적은 시간대나 계획된 유지보수 시간(maintenance windows) 동안 마이그레이션을 수행하십시오.
• 마이그레이션이 시작되기 전에 철저히 테스트된 명확한 폴백(fallback) 및 롤백(rollback) 절차를 수립하십시오.

라이브 마이그레이션 기술 (Live Migration Techniques)

중단 없이 운영을 지속하기 위해 데이터베이스 복제(database replication), 액티브-액티브 페일오버(active-active failover) 구성, 제로 다운타임 배포(zero-downtime deployment) 전략을 채택하십시오. AWS Database Migration Service는 전환 중에 실시간 복제(real-time replication)를 제공합니다.

커뮤니케이션 및 조정 (Communication and Coordination)

IT 직원, 최종 사용자, 비즈니스 리더를 포함한 모든 이해관계자(stakeholders)와 열린 소통 채널을 유지하십시오.

롤백 계획 (Rollback Plans)

피처 플래그(Feature Flags)를 이용한 즉각적인 롤백

스트랭글러 피그(strangler fig) 패턴의 심리적 이점은 모든 단계가 가역적(reversible)이라는 것입니다. 오류가 발견되면 피처 플래그(feature flag)를 즉시 다시 전환하십시오.

롤백 대상으로의 레거시 시스템 (Legacy System as Rollback Target)

작업이 "완료"되었다고 생각한 후에도 레거시 시스템을 운영 환경(production)에서 한 달 이상 계속 실행하십시오. 트래픽은 전혀 전달하지 않되, 롤백 대상(rollback target)으로서 사용할 수 있는 상태로 유지해야 합니다. 새로운 시스템이 모든 예외 케이스(edge case)를 처리할 수 있다는 확신이 들 때 시스템을 폐기(decommission)하십시오.

데이터베이스 롤백 (Database Rollback)

각 변경 세트(ChangeSet)에는 마이그레이션 스크립트에 정의된 롤백 로직이 포함되어야 합니다. 마이그레이션이 실패하면 시스템은 자동으로 롤백 명령을 호출하여 데이터베이스 스키마(schema)를 이전의 안정적인 상태로 복구합니다. 필요한 경우 마이그레이션을 일시 중지하거나 롤백할 수 있도록 미리 정의된 체크포인트(checkpoint)를 설정해야 합니다.

마이그레이션 테스트 (Testing Migrations)

계약 테스트 (Contract Testing)는 필수적입니다

성공한 스트랭글러(strangler) 프로젝트의 89%는 계약 테스트(contract testing)를 사용한 반면, 실패한 프로젝트 중 이를 사용한 경우는 14%에 불과했습니다. 계약 테스트는 소비자(consumer) 서비스와 제공자(provider) 서비스 간의 API 규약을 검증합니다.

마이그레이션 중 테스트 분포의 변화

테스트 유형	모놀리스 (Monolith) %	스트랭글러 진행 중 %	마이그레이션 후 %
단위 테스트 (서비스 내부)	40%	55%	70%
...

테스트 체크리스트

• 모든 마이그레이션 스크립트는 버전 관리(versioned)되어야 함
• 병목 현상(bottlenecks)에 대한 성능을 모니터링하고, 접근 방식을 변경할 준비를 갖출 것
• 자동화된 대조(reconciliation) 실행을 지속적으로 수행할 것 (한 사례 연구에서는 14개월 동안 8,064회 실행)
• 중단 기준(kill criteria) 설정: 폐기 전 4주 연속 불일치(mismatch) 0건 달성

실제 마이그레이션 사례 연구 (Real Migration Case Studies)

사례 연구 1: 보험 SaaS 가격 엔진 마이그레이션

프로젝트 상세 정보:

• 코드베이스: 380,418 LOC VB6 + 127 SQL Server 저장 프로시저 (stored procedures)
• 기간: 14개월 (2024년 2월 - 2025년 4월)
• 팀: 엔지니어 5명 (백엔드 3명, DevOps 1명, QA 1명)
• 비용: $1.24M

마이그레이션 전 지표:

지표	이전 (VB6)	이후 (.NET 8)	개선 사항
중간 지연 시간 (Median latency)	1,247ms	32ms	-97.4%
...

420만 달러를 절감한 대조 루프 (Reconciliation Loop):

• 14개월 동안 8,064회의 자동화된 대조 (reconciliation) 실행
• 1,240만 건의 가격 계산 처리
• 847건의 불일치(mismatch) 감지 (전체 이벤트의 0.007%)
• 불일치 원인: 반올림 차이 (49%), 세금 계산 예외 케이스 (26%), 문서화되지 않은 비즈니스 규칙 (15%), 시간대 (timezone) 처리 (8%)

자동화된 대조 (reconciliation)가 없었다면, 14개월 동안 420만 달러 상당의 잘못된 견적/송장이 발생했을 것으로 예상되었습니다.

사례 연구 2: OTT 스트리밍 플랫폼 마이크로서비스 (Microservices) 마이그레이션

• 데이터 동기화를 위한 UUID 매핑 전략을 사용하여 레거시 시스템을 마이크로서비스 (microservices)로 성공적으로 마이그레이션
• 데이터 동기화 및 버전 관리를 위해 SNS, SQS, 데드 레터 큐 (Dead Letter Queues) 사용
• 신규 시스템은 무수히 많은 기능, 더 나은 콘텐츠 관리, 간소화된 퍼블리싱 메커니즘을 지원

사례 연구 3: 글로벌 EHS 플랫폼의 ServiceNow 이전

• 노후화된 SaaS에서 ServiceNow로 글로벌 EHS 플랫폼을 12개월에 걸쳐 마이그레이션
• 마이그레이션을 완료하는 동안 20%의 비용 절감
• 워크플로 (workflows)의 95%가 예상대로 작동했으며, 나머지 5%는 배포 후 조정이 필요했음

차이를 만든 5가지 교훈:

1. 이해관계자 매핑 (Stakeholder mapping) - 의사 결정 권한을 우선적으로 정의
2. 벤더 검증 (Vendor verification) - 통제된 테스트 환경에서 워크플로 (workflows) 검증
3. DevOps에 비즈니스 내재화 (Embedding business in DevOps) - 요구사항과 인도(delivery) 사이의 간극 해소
4. 스마트한 범위 관리 (Smart scope management) - 대상 사용자별 맞춤형 도입
5. 산출물 기반 성공 지표 (Deliverable-based success metrics) - 추상적인 목표 대신 측정 가능한 결과 도출

대부분의 스트랭글러 (Strangler) 시도가 실패하는 이유 (연구 데이터)

41개의 엔터프라이즈 스트랭글러 (strangler) 프로젝트(2022-2025)를 분석한 결과, 68%가 90일 이전에 중단되었으며, 첫 번째 모놀리스 (monolith) 구성 요소를 교체하는 데 실패했습니다.

실패 분석: 중단된 28개 프로젝트

실패 모드	프로젝트 비율	중단까지의 중앙값	주요 증상
UI 레이어에서 시작	39%	68일	새로운 UI가 레거시 백엔드와 강하게 결합됨
...

핵심 결과: 첫 90일 동안 모놀리스 (monolith) 기능의 5% 미만을 추출한 프로젝트의 **실패율은 92%**에 달했습니다.

피해야 할 안티 패턴 (Anti-Patterns)

안티 패턴 1: UI 레이어부터 먼저 스트랭글러(Strangle)를 시도하는 경우

• 레거시 JSP UI를 교체하기 위해 새로운 React 관리자 패널을 구축함
• 새로운 UI는 단일 페이지 로드 시 레거시 모놀리스 (Monolith)에 47개의 API 호출을 발생시킴
• 결과: "현대적인" UI가 레거시의 모든 성능 및 신뢰성 문제를 그대로 물려받음
• 비용: 68만 달러 매몰

안티 패턴 2: 안정적인 시맨틱 경계 (Semantic Boundary) 부재 → 범위 확장 (Scope Creep)

• "고객 서비스 (Customer Service)" 추출 작업이 8주 동안 주문 (Order), 풀필먼트 (Fulfillment), 반품 (Returns) 도메인까지 끌어들임
• 해당 서비스는 현재 6개의 도메인에 의존하게 되었으며, 처음부터 다시 시작해야 했음

안티 패턴 3: 읽기 전용 현대화 (중복 쓰기의 지옥)

이중 쓰기 (Dual-Write) 전략	성공률	월간 중간 장애 발생 건수
조정 (Reconciliation) 없음	12%	38
...

성공을 위한 9가지 타협 불가능한 전제 조건

전제 조건	성공한 프로젝트의 %	실패한 프로젝트의 %
레거시에 대한 포괄적인 테스트 커버리지 (Test Coverage)	100%	18%
...

핵심 통찰 (Critical Insight): 2개 이상의 전제 조건을 충족하지 못한 프로젝트의 **실패율은 94%**에 달했습니다.

스트랭글러 (Strangler) vs 빅뱅 (Big Bang) 적용 시점

요소	스트랭글러 피그 (Strangler Fig) 승리	빅뱅 (Big Bang) 승리
모듈화된 비즈니스 로직	22/22 성공	2/8 성공
...

41개 프로젝트의 종합 결과 (2022-2025):

접근 방식	프로젝트 수	성공률	중간 소요 기간	중간 비용
스트랭글러 피그 (Strangler Fig)	29	76% (22/29)	16.2개월	$1.8M
빅뱅 재작성 (Big Bang Rewrite)	12	50% (6/12)	22.8개월	$3.4M

주요 교훈 (Key Lessons Learned)

1. 가장 위험도가 낮고 신호(Signal)가 명확한 엔드포인트부터 시작하세요 — 인증(Authentication)이나 단순 읽기 전용 API와 같은 것들입니다.
2. 첫 2주 이내에 현대적인 시스템으로 무언가를 배포하세요 — 접근 방식이 작동함을 보여주는 것은 그 어떤 슬라이드 덱(Slide deck)보다 빠르게 신뢰를 구축합니다.
3. 데이터 마이그레이션(Data migration)에는 코드 마이그레이션보다 두 배의 시간을 할당하세요 — 대조(Reconciliation) 과정에서 문서화되지 않은 가설들이 드러납니다.
4. 가장 어려운 부분은 기술적인 것이 아니라 정치적인 것입니다 — 새로운 기능을 출시하면서 "점진적으로 현대화(Incrementally modernizing)"하는 것으로 프레임을 짜야 하며, "재작성(Rewrite)"이라고 표현해서는 안 됩니다.
5. 초기 속도(Velocity)가 성공을 예측하는 가장 강력한 지표입니다 — 첫 90일 이내에 기능의 5% 이상을 추출하세요.
6. 시작하기 전에 포괄적인 모니터링(Monitoring)을 구축하세요 — 관찰할 수 없는 것은 디버깅(Debug)할 수 없습니다.
7. 계약 테스트(Contract testing)를 사용하세요 — 성공적인 프로젝트의 89%가 이를 사용했습니다.
8. 마이그레이션이 완료된 후에도 한 달 동안은 레거시 시스템을 계속 실행하세요 — 롤백(Rollback)을 위한 안전망으로서 말입니다.
9. UI 레이어부터 시작하는 것을 피하세요 — UI는 빙산의 일각일 뿐입니다. 백엔드 로직을 소유하지 않은 채 스트랭글러(Strangling) 방식을 적용하면 분산된 프론트엔드(Distributed frontend)가 만들어집니다.
10. 인내심을 가지세요 — 스트랭글러 피그(Strangler fig)는 천천히 감싸 안으며 자랍니다. 최고의 마이그레이션은 "어, 벌써 다 됐어요?"라는 최고의 찬사를 듣는 것입니다.

스트랭글러 피그 패턴(Strangler fig pattern)은 마이그레이션 작업 중에도 기존 애플리케이션이 계속 작동할 수 있도록 제어된 단계별 현대화 접근 방식을 제공합니다. 적절한 계획, 피처 플래그(Feature flags), 자동화된 대조(Automated reconciliation), 그리고 이해관계자의 동의가 있다면, 더 낮은 위험과 중단으로 레거시 시스템을 점진적으로 현대화할 수 있습니다.

Rizwan Saleem — https://rizwansaleem.co