CORE CAPABILITY
멈출 수 없는 시스템을 옮기는 방법
"주말에 한 번에 전환하자"는 계획은 대부분 월요일 아침에 무너집니다. 두이음은 트래픽을 조금씩 옮기면서 되돌릴 수 있는 상태를 유지합니다.
스트랭글러 패턴
레거시 앞에 라우팅 계층을 두고, 새로 만든 기능부터 신규 시스템으로 보냅니다. 나머지 요청은 그대로 레거시가 처리합니다. 이 상태를 몇 달간 유지하면서 기능을 하나씩 옮기고, 마지막 기능이 넘어가면 레거시를 내립니다.
이 방식의 핵심은 언제든 되돌릴 수 있다는 것입니다. 신규 시스템에서 문제가 발생하면 라우팅만 되돌리면 됩니다. 빅뱅 전환에는 이 선택지가 없습니다.
선행 작업
이행 전에 반드시 확인하는 것이 있습니다.
- 데이터 소유권 — 어느 시스템이 어느 테이블의 쓰기 권한을 갖는지. 양쪽이 같은 테이블에 쓰기 시작하면 되돌릴 수 없습니다.
- 세션과 인증 — 두 시스템이 같은 세션을 인식해야 사용자가 로그아웃되지 않습니다.
- 관측 가능성 — 이행 중에는 요청이 어느 쪽으로 갔는지 추적되어야 합니다. 분산 추적을 먼저 넣습니다.
데이터 이행
데이터는 코드보다 먼저, 그리고 더 천천히 옮깁니다. 이중 쓰기(dual write) 후 검증 기간을 두고, 읽기를 신규로 전환한 뒤 마지막에 레거시 쓰기를 끕니다. 각 단계마다 되돌리는 절차를 문서로 남기고 실제로 리허설합니다.
일반적인 이행 단계
- 2025 04
5단계 — 레거시 종료
마지막 기능 이행 후 레거시를 읽기 전용으로 두고 한 분기 유지한 뒤 종료합니다.
- 2024 11
4단계 — 데이터 이중화와 검증
이중 쓰기 후 양쪽 데이터를 비교합니다. 불일치가 0이 되기 전에는 읽기를 옮기지 않습니다.
- 2024 07
3단계 — 첫 기능 이행
의존성이 가장 적은 기능부터 옮깁니다. 첫 이행의 목적은 성과가 아니라 절차 검증입니다.
- 2024 05
2단계 — 라우팅 계층 도입
레거시 앞단에 게이트웨이를 두고 전량을 그대로 통과시킵니다. 이 시점에는 동작이 바뀌지 않아야 합니다.
- 2024 03
1단계 — 관측 가능성 확보
분산 추적과 구조화 로그를 먼저 넣습니다. 안 보이는 상태로 옮기면 문제 원인을 찾을 수 없습니다.
- 2024 01
0단계 — 현황 파악과 경계 설정
코드와 데이터 의존성을 실측합니다. 문서상 구조와 실제 호출 관계는 거의 항상 다릅니다.
함께 수행하는 것
-
컨테이너 이관
런타임 버전 고정과 이미지 최소화를 함께 진행합니다. 베이스 이미지 취약점은 이관 시점에 정리하는 것이 가장 쌉니다.
-
DevSecOps 파이프라인
빌드 단계에 의존성 취약점 검사와 SBOM 생성을 넣습니다. 게이트는 처음부터 차단이 아니라 경고로 시작합니다.
-
성능 예산 도입
전환 전후 성능을 같은 기준으로 측정합니다. 체감이 아니라 숫자로 비교해야 논쟁이 끝납니다.
전환 계획을 검토받고 싶다면
이미 세운 계획이 있으시면 그 계획의 위험 구간을 짚어 드립니다.