310. 스트랭글러 피그 (Strangler Fig) 패턴 - 레거시를 점진적으로 MSA로 마이그레이션

핵심 인사이트 (3줄 요약)

본질: 스트랭글러 피그(Strangler Fig) 패턴은 거대하고 낡은 모놀리식(Monolithic) 레거시 시스템을 새로운 마이크로서비스 아키텍처(MSA)로 교체할 때, 시스템을 한 번에 뒤엎지 않고 야금야금(점진적으로) 새로운 서비스로 덮어씌워 결국 레거시를 고사(Strangulate)시키는 마이그레이션 전술이다.

가치: "빅뱅(Big Bang) 배포는 재앙이다"라는 소프트웨어 공학의 교훈을 바탕으로, 신구 시스템을 공존시키며 안전하게 트래픽을 넘기기 때문에 비즈니스 중단(Downtime)과 롤백의 리스크를 거의 0에 가깝게 통제할 수 있다.

융합: 앞단에 API 게이트웨이(또는 L7 라우터)를 두는 파사드(Facade) 패턴과 완벽하게 융합되며, 클라우드 네이티브 전환(Modernization) 과정에서 가장 신뢰받고 널리 쓰이는 표준 전환 아키텍처다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 스트랭글러 피그 나무는 숙주 나무의 줄기를 타고 올라가 결국 숙주 나무를 완전히 덮어서 말라 죽게 만드는 열대의 무화과나무다. 이처럼 기존 시스템(숙주)의 앞단에 라우터를 두고, 새로 짠 마이크로서비스 기능부터 라우팅을 하나씩 넘겨(가로채어) 결국 낡은 시스템을 완전히 도태시키는 마이그레이션 설계다.
필요성: 20년 된 100만 줄짜리 거대한 '쇼핑몰 자바 모놀리식 서버'가 있다. 코드가 너무 스파게티라서 이걸 MSA로 쪼개기로 했다. 개발팀이 2년 동안 문을 닫아걸고 완벽한 MSA 서버 20개를 짠 뒤, 금요일 밤에 옛날 서버를 끄고 새 서버를 한 방에 올렸다(빅뱅 배포). 토요일 아침, 새 서버에서 생각지도 못한 DB 락(Lock) 버그가 터져 쇼핑몰이 마비되었다. 다시 옛날 서버로 돌리려니 DB 스키마가 다 망가져서 롤백도 안 된다. 이런 대참사를 막을 안전하고 '점진적인' 이사 방법이 필요했다.
💡 비유: 살고 있는 낡은 집을 부수고 새 집을 짓는 방법과 같습니다. 집을 통째로 허물고 식구들이 한 달 동안 텐트에서 자는 것(빅뱅 배포)이 아니라, 마당에 새 화장실을 먼저 짓고, 그다음엔 새 부엌을 짓고 하나씩 쓰다가, 마지막에 낡은 안방을 부수고 새 안방으로 들어가는 것(스트랭글러 피그)입니다.
등장 배경 및 발전 과정:
1. 마틴 파울러(Martin Fowler)의 제안 (2004): 호주를 여행하다 스트랭글러 피그 나무를 보고 영감을 얻어, 낡은 코드를 버리는 방법으로 이 패턴을 명명하고 블로그에 제안했다.
2. MSA의 대유행 (2010년대): 엔터프라이즈 기업들이 모놀리식에서 MSA로 대규모 이사를 시작하면서, 마틴 파울러의 이 이론이 아키텍트들에게 구원의 동아줄이 되었다.
3. 클라우드 API 게이트웨이와 융합: L7 라우팅을 0.1초 만에 휙휙 바꿀 수 있는 AWS API Gateway나 Nginx의 발전으로, 스트랭글러 패턴의 라우팅 스위칭이 인프라 레벨에서 숨 쉬듯 쉬워졌다.
📢 섹션 요약 비유: 낡은 시스템의 배에 기생충(새로운 MSA)을 심어놓는 것입니다. 기생충이 처음엔 '결제 기능'만 파먹고, 그다음엔 '검색 기능'을 파먹으면서 점점 덩치를 키우다, 숙주가 텅 비게 되면 숙주를 미련 없이 버리는 잔인하지만 우아한 세대교체입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

스트랭글러 피그 패턴의 3단계 작동 메커니즘

스트랭글러 피그 패턴의 핵심은 클라이언트와 시스템 사이에 무조건 **파사드(Facade, API Gateway)**가 존재해야 한다는 점이다.

  ┌─────────────────────────────────────────────────────────────┐
  │              스트랭글러 피그 패턴의 점진적 교체 흐름 (1~3단계)       │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [1단계: Facade 설정] (모든 트래픽은 레거시로)                  │
  │   Client ─▶ [ API Gateway (Facade) ] ─▶ [ 낡은 레거시 모놀리스 ] │
  │                                                             │
  │  [2단계: 교살(Strangulate) 시작] (기능 1개 이사 완료)             │
  │               ┌─────────▶ ( /users 요청 ) ─▶ [ 신규 유저 MSA ]  │
  │   Client ─▶ [ API Gateway ]                                  │
  │               └─────────▶ ( 나머지 요청 ) ─▶ [ 낡은 레거시 모놀리스 ]│
  │                                                             │
  │  [3단계: 100% 교체 완료] (숙주의 죽음)                          │
  │               ┌─────────▶ ( /users ) ───▶ [ 신규 유저 MSA ]  │
  │   Client ─▶ [ API Gateway ] ─▶ ( /orders ) ──▶ [ 신규 주문 MSA ]  │
  │               └─────────▶ ( /pay ) ─────▶ [ 신규 결제 MSA ]  │
  │                                                             │
  │            ( 낡은 레거시 모놀리스는 트래픽 0%가 되어 폐기됨 X_X )    │
  └─────────────────────────────────────────────────────────────┘

1. 변환(Transform) : 파사드 삽입

레거시 시스템을 뜯기 전에, 사용자 트래픽의 모든 입구에 API Gateway나 L7 로드밸런서를 세운다. 초기에는 라우팅 규칙이 투명하게 설정되어 모든 요청을 그냥 레거시로 패스(Pass-through)시킨다. 사용자는 아무 변화도 느끼지 못한다.

2. 공존(Coexist) : 라우팅 가로채기

개발팀이 레거시에서 가장 떼어내기 쉬운 '알림(Notification)' 기능 하나를 새 MSA 서버로 짰다. 배포 후, API Gateway의 라우팅 룰을 조작해 /api/notification으로 들어오는 요청만 새 MSA로 돌린다. 나머지 수백 개의 기능은 여전히 레거시가 처리한다.

3. 제거(Eliminate) : 레거시의 무덤

이 과정을 주문, 결제, 배송으로 수십 번 반복한다. 마침내 레거시 시스템으로 가는 트래픽이 0건이 되는 날, 엔지니어들은 기쁜 마음으로 레거시 서버의 전원 코드를 뽑고 장례식을 치른다.

마이그레이션의 가장 큰 벽: 데이터베이스(DB) 분리 전략

코드(서버)를 쪼개는 건 쉽다. 문제는 하나로 뭉쳐있는 레거시 DB다. 코드가 나뉘어도 DB가 하나라면 진정한 MSA가 아니다. 이 DB를 쪼개는 아키텍처 전술이 2가지가 있다.

DB 먼저 쪼개기 (Database-First): 레거시 코드에서 DB 테이블을 먼저 물리적으로 분리하고 임시로 API 통신하게 만든 뒤, 나중에 코드를 MSA로 빼내는 방법. 가장 고통스럽지만 근본적인 방법이다.
동기화 뷰/트리거 활용 (Code-First): 새 MSA에 새 DB를 만들고, 레거시 DB와 새 DB 사이에 CDC(Change Data Capture)나 트리거를 달아 양방향/단방향 동기화를 유지한다. 과도기적 데이터 불일치(Eventual Consistency)를 아키텍트가 감당해야 한다.

📢 섹션 요약 비유: 이삿짐을 옮길 때 짐(DB)을 먼저 새 집에 다 보내놓고 사람이 나중에 갈지, 사람(서버 코드)이 먼저 가서 자고 짐을 매일 밤 택배(동기화)로 조금씩 받을지 결정하는 피 말리는 전술입니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 스트랭글러 피그 vs 빅뱅(Big Bang) 배포

SI(시스템 통합) 차세대 프로젝트에서 아키텍트들이 매일 싸우는 주제다.

비교 항목	빅뱅 (Big Bang) 마이그레이션	스트랭글러 피그 (Strangler Fig)
배포 방식	D-day를 정해 한 번에 100% 교체	기능별로 쪼개서 매주/매월 조금씩 교체
롤백(Rollback)	실패 시 DB 데이터 꼬임으로 롤백 거의 불가 (대재앙)	라우터 스위치만 원복하면 즉시 0.1초 만에 롤백 (매우 안전)
비즈니스 영향	전환 기간 1~2년 동안 신규 기능(기획) 개발 전면 중지	레거시 운영과 MSA 이사가 동시에 가능함 (Agile)
복잡도/비용	한 번에 하므로 구조는 단순하지만 리스크 비용이 큼	신/구 시스템을 공존시키고 동기화하는 파이프라인(CDC) 구축비가 큼

과목 융합 관점

소프트웨어 공학 (SE): 파사드(Facade) 패턴을 엔터프라이즈 아키텍처 단위로 끌어올린 전형이다. 클라이언트(사용자)는 시스템 내부가 레거시인지 새 MSA인지 알 필요 없이 파사드(API Gateway)만 바라보게 하여 결합도를 끊어냈다.
클라우드 / 배포 전략: 기능 하나를 쪼개어 배포할 때, 카나리(Canary) 배포 전술과 완벽히 융합된다. 새 MSA 서비스로 트래픽을 100% 돌리지 않고, 10%만 돌려보고 에러가 없으면 100%로 늘려 레거시를 고사시키는 극강의 방어적 데브옵스(DevOps) 파이프라인이 완성된다.
📢 섹션 요약 비유: 빅뱅 배포는 달리는 자동차의 엔진을 한 번에 뽑고 새 엔진을 우겨넣는 미친 짓입니다. 스트랭글러 피그는 달리는 자동차에 보조 엔진(MSA)을 달아 시동을 걸어보고, 잘 돌면 원래 엔진으로 가는 연료 파이프(라우팅)를 잠가 서서히 시동을 꺼버리는 우아한 레이싱 정비술입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 분리할 수 없는 스파게티 덩어리 (도메인 쪼개기 실패): 차세대 쇼핑몰 전환 프로젝트. 주문 기능을 새 MSA로 쪼개어 스트랭글러 피그로 빼냈다. 그런데 주문 테이블과 결제 테이블이 레거시 DB에서 무자비한 JOIN으로 50군데나 얽혀 있었다. 새 주문 MSA 서버에서 쿼리를 날릴 때마다 레거시의 결제 데이터를 가져오기 위해 수만 번의 API 동기 호출(HTTP)이 발생해 응답 시간이 10초로 늘어나고 서버가 폭발했다.
- 아키텍트의 해결책: 도메인 주도 설계(DDD, Domain-Driven Design) 부재로 인한 참사다. 스트랭글러 피그 패턴을 쓸 때 가장 먼저 떼어내야 할 기능은 "가장 중요한 기능"이 아니라 **"결합도(Coupling)가 가장 낮은 가장자리의 기능(예: 알림, 마이페이지)"**이다. 엉켜있는 핵심 도메인을 먼저 떼어내면 피투성이가 된다. 아키텍트는 분해하기 전 코드 분석(Seam 찾기)을 통해, 쪼갰을 때 네트워크 홉(Hop) 오버헤드가 최소화되는 응집된 덩어리(Bounded Context)부터 수술을 시작해야 한다.
시나리오 — 부패 방지 계층(ACL) 없는 공존의 타락: 신규 시스템(MSA)을 너무 잘 짰다. 그런데 과도기(Coexist) 기간 동안 신규 시스템이 레거시 시스템의 낡은 세션 데이터와 이상한 JSON 규격을 계속 참고해야 했다. 1년 뒤 레거시를 100% 껐는데, 신규 MSA 코드 안에는 낡은 레거시를 위해 짜놓은 더러운 분기문과 변환 코드들이 지뢰처럼 남아 영원한 기술 부채가 되었다.
- 아키텍트의 해결책: 안티 코럽션 레이어(ACL, 부패 방지 계층) 패턴을 결합하지 않은 실수다. 새 시스템의 순수한 도메인 로직이 낡은 레거시의 데이터 포맷을 직접 알게 해서는 절대 안 된다. 두 시스템이 공존하며 통신할 때는 반드시 사이에 어댑터(Adapter) 계층을 두어, 레거시의 더러운 데이터를 새 시스템의 우아한 객체로 번역(Translation)해서 넘겨주어야 한다. 나중에 레거시가 죽으면 이 어댑터 계층만 툭 떼어버리면 새 시스템은 100% 순수하게 유지된다.

도입 체크리스트

비즈니스적: 이 레거시 시스템이 "아예 더 이상 기능을 추가할 필요가 없는 굳어버린 시스템"인가? 그렇다면 무리해서 MSA로 쪼갤 필요가 없다. (Leave it alone). 잦은 요구사항 변경으로 인해 배포가 두려워 비즈니스 속도가 죽어가는 생동하는 도메인일 때만 이 고통스러운 수술을 감행해야 한다.
기술적: 클라이언트 화면(프론트엔드)이 레거시의 모놀리식 렌더링(예: JSP, Thymeleaf)에 묶여 있는가? 백엔드 API만 새 서버로 빼내면, 결국 옛날 JSP 서버가 새 API를 호출해서 화면을 그려야 하는 반쪽짜리 분리가 된다. 프론트엔드를 SPA(React/Vue)로 먼저 완전히 찢어내어 API 게이트웨이를 바라보게 하는 선행 작업이 요구된다.

안티패턴

영원한 과도기 (Forever Strangling): 3년 계획으로 스트랭글러 피그 패턴을 시작해 놓고, 결제와 회원가입 등 어려운 코어(Core) 모듈은 "너무 복잡하다"는 이유로 무기한 미루는 행위. 결국 회사는 옛날 레거시 시스템 1개와 새로운 MSA 시스템 20개를 동시에 운영하며 유지보수 비용과 인프라 비용(AWS+IDC)을 2배로 태우는 최악의 하이브리드 지옥에 갇힌다. 시작했으면 숙주의 숨통을 완전히 끊을 때까지 멈추면 안 된다.
📢 섹션 요약 비유: 이혼(시스템 분리)을 하기로 해놓고 집을 구하기 귀찮아서 전 남편(레거시)과 새 남편(MSA)이 한 지붕 아래 5년째 같이 사는 꼴입니다. 스트랭글러 피그는 반드시 마지막에 예전 시스템의 전원 코드를 시원하게 뽑아버리는 피날레가 있어야 완성됩니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	빅뱅 마이그레이션 (AS-IS)	스트랭글러 피그 적용 (TO-BE)	개선 효과
정량	차세대 배포 실패 시 롤백에 며칠 소요 (대장애)	API Gateway 라우팅 수정으로 1초 내 롤백	릴리즈/마이그레이션 리스크 99% 차단
정량	차세대 완료(2년) 전까지 신기능 비즈니스 배포 불가	MSA로 쪼개진 부분부터 즉시 신기능 배포/운영	신기능 타임 투 마켓(TTM) 24개월 -> 1주로 혁신
정성	"오픈 날 밤새우고 기도해야 함" (엔지니어 번아웃)	퇴근 전 클릭 한 번으로 카나리 테스트하며 평화로운 이사	애자일(Agile) 문화를 물리적 아키텍처로 증명 및 안착

미래 전망

클라우드 네이티브 라우팅의 극한 (Service Mesh): 과거엔 API Gateway(Nginx 등)의 설정 파일을 고치고 재시작해야 라우팅이 바뀌었지만, 현대의 쿠버네티스와 Istio 서비스 메시는 Weight: 5%라는 YAML 설정 한 줄만 적용하면 즉시 레거시와 신규 서버로 95 대 5의 트래픽을 쪼개주는 선언적 마이그레이션 시대를 열었다.
AI 리팩토링 에이전트: 스트랭글러 피그의 가장 큰 고통인 '레거시 스파게티 코드 분석'을 LLM(대형 언어 모델)이 대신해 주고 있다. 수십만 줄의 코볼(COBOL)이나 오래된 자바 코드를 AI가 분석하여 결합도가 가장 낮은 모듈(Seam)을 추천해 주고, 해당 부분을 마이크로서비스(Spring Boot)로 1차 초벌 번역해 주는 AI 주도 모더나이제이션(Modernization)이 태동하고 있다.

참고 표준

Martin Fowler의 블로그 (2004): 스트랭글러 피그 패턴을 세상에 처음 소개한 기념비적인 아티클.
12-Factor App: 스트랭글러로 떼어낸 새로운 마이크로서비스가 반드시 지켜야 할 클라우드 네이티브 애플리케이션의 12가지 설계 규약.

스트랭글러 피그 패턴은 아키텍트가 경영진에게 내미는 **"가장 현실적이고 평화로운 혁명 계획서"**다. 비즈니스는 단 하루도 멈출 수 없다. 달리는 마차의 바퀴를 갈아 끼우는 기적을 행하기 위해, 아키텍트는 마차 바닥에 몰래 보조 바퀴(새로운 MSA)를 달고, 원래 바퀴(레거시)의 나사를 매일 밤 하나씩 조용히 풀어내야 한다. 거대한 레거시에 대한 분노로 한 번에 다 엎어버리고 싶은(빅뱅) 개발자의 유혹을 억누르고, 수년에 걸쳐 살을 발라내는 끈기와 아키텍처 라우팅의 마술을 지휘하는 자만이 시스템 모더나이제이션(Modernization)을 승리로 이끌 수 있다.

📢 섹션 요약 비유: 이 패턴은 매미 허물 벗기와 같습니다. 매미는 나무에 매달려 조금씩 조금씩 등껍질을 깨고 새 몸을 꺼냅니다(스트랭글러). 다 빠져나올 때까지 헌 껍질(레거시)은 매미를 안전하게 감싸줍니다. 그리고 완벽히 밖으로 나왔을 때, 헌 껍질은 그 자리에 남겨두고 새 날개(MSA)로 날아오르는 대자연의 우아한 시스템 교체법입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
API 게이트웨이 (API Gateway)	스트랭글러 피그의 알파와 오메가. 트래픽을 옛날 집으로 갈지 새 집으로 갈지 0.1초 만에 스위칭해 주는 파사드(문지기).
모놀리식 vs 마이크로서비스 (MSA)	스트랭글러 피그가 필요한 근본적인 이유. 거대한 진흙 덩어리(모놀리식)를 수십 개의 작은 레고 블록(MSA)으로 부수는 과정.
부패 방지 계층 (ACL)	이사하는 도중에 낡은 레거시 시스템의 더러운 데이터 구조가 새 시스템의 깨끗한 코드를 오염시키지 못하게 막는 어댑터 방패.
카나리 배포 (Canary Release)	기능을 떼어냈을 때, 갑자기 100% 트래픽을 주지 않고 1%, 10%씩 서서히 늘려가며 에러를 관찰하는 안전한 배포 전술.
도메인 주도 설계 (DDD)	레거시의 코드를 뜯어낼 때 아무 데나 자르지 않고, 비즈니스 의미 단위(Bounded Context)로 깔끔하게 절단선을 긋는 메스(칼).

👶 어린이를 위한 3줄 비유 설명

낡고 위험한 헌 나무집(레거시 시스템)에 살고 있는데, 집을 한 번에 다 부수고 새 집을 지으면 가족들이 한 달 동안 밖에서 자야 해요.
그래서 마당에 멋진 새 부엌(새 마이크로서비스)을 먼저 지어서 밥만 거기서 먹고, 다음 달엔 새 침실을 지어서 잠을 자요. (점진적 이사)
이렇게 조금씩 야금야금 새 방으로 이사를 가다가, 마지막에 텅 빈 낡은 나무집을 쿵! 하고 부숴버리는 똑똑하고 안전한 이사 방법을 **'스트랭글러 피그 패턴'**이라고 부른답니다!