스트랭글러 패턴(Strangler Fig Pattern) 완벽 정리

"이 스파게티 코드가 되어버린 10년 된 쇼핑몰을 MSA로 전환합시다!"

이 결심을 한 순간, 경영진과 개발팀은 두 가지 갈림길에 섭니다. **"새 시스템을 완벽하게 다 만들 때까지 기다렸다가 한방에 오픈하자"**는 유혹과, **"일단 회원 기능만 떼어내서 먼저 오픈하자"**는 신중함 사이의 선택입니다.

---

1. 방식 1: 빅뱅 (Big Bang Rewrite) - "모 아니면 도"

기존 시스템(Legacy)은 그대로 운영하면서, 옆에서 새로운 시스템(New System)을 처음부터 끝까지 다 개발한 뒤, 특정 날짜(D-Day)에 스위치를 내리고 교체하는 방식입니다.

특징

• 이중 개발: 운영팀은 레거시를 유지보수하고, 개발팀은 차세대를 개발합니다. (기능 변경이 있으면 양쪽에 다 적용해야 함)
• 한방 배포: D-Day 새벽에 구 시스템을 끄고 신 시스템을 켭니다.

시나리오

1. 2024년 1월: "차세대 쇼핑몰 프로젝트" 착수.
2. 2025년 12월: 개발 완료.
3. 2026년 1월 1일: 오픈! -> 장애 발생 -> 롤백 -> 오픈 연기 -> 프로젝트 실패

장단점

• 장점:
  • 설계의 자유: 레거시의 제약 없이 처음부터 깔끔한 아키텍처로 짤 수 있습니다.
• 단점:
  • 높은 실패율: 2년 동안 비즈니스는 계속 변했는데, 2년 전 기획서로 만든 시스템이 오픈되면 요구사항과 맞지 않습니다.
  • 피드백 부재: 오픈 전까지는 사용자의 반응을 볼 수 없습니다.
  • 데이터 마이그레이션 지옥: 수 테라바이트의 데이터를 하룻밤 사이에 옮겨야 합니다.

---

2. 방식 2: 스트랭글러 패턴 (Strangler Fig) - "야금야금 잠식하기"

열대우림의 '교살 무화과나무(Strangler Fig)'가 숙주 나무를 감싸며 자라다가 결국 숙주를 죽이고 자리를 차지하는 것에서 유래했습니다. 레거시 앞에 프록시(Proxy)를 두고, 기능을 하나씩 새 시스템으로 돌리는 방식입니다.

특징

• 공존(Co-existence): 레거시와 신규 시스템이 동시에 운영됩니다.
• 라우팅: 프록시(API Gateway)가 "이 요청은 옛날 코드로, 저 요청은 새 코드로" 보냅니다.

적용 단계 (마이그레이션)

1. 프록시 설치: 모든 트래픽을 가로채는 API Gateway를 앞단에 둡니다. (처음엔 100% 레거시로 토스)
2. 기능 분리: 가장 작고 쉬운 기능(예: '리뷰 조회')을 마이크로서비스로 새로 짭니다.
3. 라우팅 변경: /reviews 요청이 오면 레거시가 아니라 새 마이크로서비스로 보냅니다.
4. 반복: 회원, 주문, 결제 순으로 하나씩 떼어냅니다.
5. 사망 선고: 레거시에 아무 기능도 남지 않으면 꺼버립니다(Decommission).

코드 개념 (API Gateway 설정)

YAML

 

spring:
  cloud:
    gateway:
      routes:
        # 1. 새로 만든 리뷰 서비스 (여기로 먼저 보냄)
        - id: new-review-service
          uri: lb://review-service
          predicates:
            - Path=/api/reviews/**
        
        # 2. 아직 못 옮긴 나머지 모든 요청 (레거시로 보냄)
        - id: legacy-monolith
          uri: http://legacy-system:8080
          predicates:
            - Path=/**

장단점

• 장점:
  • 낮은 위험: 기능 하나만 옮겼으므로, 에러가 나면 그 기능만 롤백하거나 고치면 됩니다.
  • 가치 전달: 2년을 기다릴 필요 없이, 1달 만에 개선된 리뷰 기능을 사용자에게 보여줄 수 있습니다.
• 단점:
  • 복잡성: 두 시스템이 공존하므로 DB 동기화나 인증 세션 공유 같은 기술적 난제가 발생합니다.
  • 긴 기간: 완전히 교체하는 데 시간이 오래 걸립니다. (경영진이 싫어할 수 있음)

---

3. 실무 비교: 언제 무엇을 쓰는가?

구분	Big Bang (전면 재개발)	Strangler Fig (점진적 전환)
개발 방식	별도 프로젝트로 진행	운영과 개선을 병행
배포 시점	프로젝트 종료 시 (한 번에)	기능 개발 완료 시마다 (수시로)
위험도	매우 높음 (오픈 당일 결판)	매우 낮음 (문제시 부분 롤백)
데이터 동기화	D-Day에 일괄 이관	양방향 동기화 또는 이중 쓰기 필요
추천 상황	시스템이 너무 작거나, 도저히 살릴 수 없을 때	대규모 시스템, 비즈니스가 계속 성장 중일 때

결론

"이 코드는 쓰레기니까 다 밀어버리고 새로 짜죠!"라는 말은 개발자에게 달콤하게 들리지만, 비즈니스 관점에서는 자살행위에 가깝습니다.

성공적인 MSA 전환 사례(넷플릭스, 아마존, 배달의민족 등)는 모두 스트랭글러 패턴을 사용했습니다.

**"API 게이트웨이"**를 먼저 세우세요. 그리고 가장자리(Edge) 기능부터 하나씩 떼어내며 레거시를 천천히 말려 죽이세요. 이것이 거대한 시스템을 안전하게 리팩토링하는 유일한 길입니다.