PART 5 · 강의 2/3
레거시 시스템
리팩토링
점진적 현대화 전략으로 안전하게 시스템을 진화시킵니다.
01
점진적 현대화 전략
빅뱅 vs 점진적 마이그레이션
빅뱅 리라이트
기존 시스템을 완전히 새로 작성하여 한 번에 교체하는 방식
- • 높은 리스크
- • 긴 개발 기간
- • 비즈니스 중단 위험
점진적 마이그레이션
작은 단위로 기능을 이전하며 서서히 현대화하는 방식
- • 낮은 리스크
- • 지속적인 가치 제공
- • 롤백 용이
마이그레이션 진행률
40%
💡 핵심 원칙
"작동하는 것을 먼저, 아름다운 것은 나중에" - 레거시 시스템이 작동하고 있다면, 그것을 유지하면서 점진적으로 개선하는 것이 안전합니다. 한 번에 모든 것을 바꾸려 하지 마세요.
02
Strangler Fig 패턴
레거시를 감싸며 자라는 새 시스템
레거시 시스템
사용자 관리
결제 시스템
재고 관리
Facade / API Gateway
새 시스템
사용자 서비스
주문 서비스
결제 서비스
재고 서비스
🌿
이름의 유래
교살자 무화과나무처럼 숙주를 감싸며 자라나 결국 대체함
🔀
라우팅 전환
Facade 레이어에서 트래픽을 새 시스템으로 점진적 전환
🔄
공존 기간
두 시스템이 함께 운영되며 안정성 검증 후 전환
📌 Strangler Fig 패턴 구현 단계
- Transform — 새로운 컴포넌트를 현대적인 방식으로 구현
- Coexist — 레거시와 새 시스템이 함께 운영
- Eliminate — 검증 후 레거시 컴포넌트 제거
03
리팩토링 단계
안전한 현대화를 위한 단계별 접근
1
현황 분석 및 문서화
기존 시스템의 의존성, 데이터 흐름, 비즈니스 로직을 파악하고 문서화합니다. 이 단계를 건너뛰면 나중에 큰 문제가 발생합니다.
2
테스트 안전망 구축
리팩토링 전에 현재 동작을 검증하는 테스트를 작성합니다. Characterization Tests로 기존 동작을 캡처합니다.
3
경계 식별 및 인터페이스 정의
모듈 간 경계를 명확히 하고, API 계약을 정의합니다. 이것이 마이크로서비스 분리의 기초가 됩니다.
4
점진적 분리 및 마이그레이션
가장 독립적인 모듈부터 시작하여 하나씩 새 시스템으로 이전합니다. 각 단계마다 검증합니다.
5
검증 및 레거시 제거
새 시스템의 안정성을 충분히 검증한 후, 레거시 코드를 제거합니다. 이 단계를 서두르지 마세요.
❌ 리팩토링 전: 스파게티 코드
class OrderService {
processOrder(data) {
// 모든 로직이 한 곳에...
validateUser(data.userId);
checkInventory(data.items);
calculatePrice(data.items);
processPayment(data.payment);
updateInventory(data.items);
sendNotification(data.userId);
// 200줄 더...
}
}
✅ 리팩토링 후: 명확한 책임 분리
class OrderService {
constructor(
userService,
inventoryService,
paymentService,
notificationService
) { ... }
async processOrder(order) {
await this.userService.validate();
await this.inventoryService.check();
await this.paymentService.process();
await this.notificationService.send();
}
}
⚠️ 흔한 실수
테스트 없이 리팩토링하지 마세요. "잘 작동하던 코드"를 망가뜨리는 가장 빠른 방법입니다. 작은 단계로 나누고, 각 단계마다 검증하세요.
SUMMARY
핵심 요약
- 점진적 마이그레이션이 빅뱅 리라이트보다 안전하고 리스크가 낮다
- Strangler Fig 패턴으로 레거시를 감싸며 새 시스템을 성장시킨다
- 리팩토링 전 테스트 안전망을 반드시 구축한다
- 작은 단계로 나누고, 각 단계마다 검증한다
- 레거시 제거는 충분한 검증 후에 진행한다