CORE CAPABILITY

멈출 수 없는 시스템을 옮기는 방법

"주말에 한 번에 전환하자"는 계획은 대부분 월요일 아침에 무너집니다. 두이음은 트래픽을 조금씩 옮기면서 되돌릴 수 있는 상태를 유지합니다.

전환 상담

스트랭글러 패턴

레거시 앞에 라우팅 계층을 두고, 새로 만든 기능부터 신규 시스템으로 보냅니다. 나머지 요청은 그대로 레거시가 처리합니다. 이 상태를 몇 달간 유지하면서 기능을 하나씩 옮기고, 마지막 기능이 넘어가면 레거시를 내립니다.

이 방식의 핵심은 언제든 되돌릴 수 있다는 것입니다. 신규 시스템에서 문제가 발생하면 라우팅만 되돌리면 됩니다. 빅뱅 전환에는 이 선택지가 없습니다.

선행 작업

이행 전에 반드시 확인하는 것이 있습니다.

  • 데이터 소유권 — 어느 시스템이 어느 테이블의 쓰기 권한을 갖는지. 양쪽이 같은 테이블에 쓰기 시작하면 되돌릴 수 없습니다.
  • 세션과 인증 — 두 시스템이 같은 세션을 인식해야 사용자가 로그아웃되지 않습니다.
  • 관측 가능성 — 이행 중에는 요청이 어느 쪽으로 갔는지 추적되어야 합니다. 분산 추적을 먼저 넣습니다.

데이터 이행

데이터는 코드보다 먼저, 그리고 더 천천히 옮깁니다. 이중 쓰기(dual write) 후 검증 기간을 두고, 읽기를 신규로 전환한 뒤 마지막에 레거시 쓰기를 끕니다. 각 단계마다 되돌리는 절차를 문서로 남기고 실제로 리허설합니다.

일반적인 이행 단계

  1. 2025 04

    5단계 — 레거시 종료

    마지막 기능 이행 후 레거시를 읽기 전용으로 두고 한 분기 유지한 뒤 종료합니다.

  2. 2024 11

    4단계 — 데이터 이중화와 검증

    이중 쓰기 후 양쪽 데이터를 비교합니다. 불일치가 0이 되기 전에는 읽기를 옮기지 않습니다.

  3. 2024 07

    3단계 — 첫 기능 이행

    의존성이 가장 적은 기능부터 옮깁니다. 첫 이행의 목적은 성과가 아니라 절차 검증입니다.

  4. 2024 05

    2단계 — 라우팅 계층 도입

    레거시 앞단에 게이트웨이를 두고 전량을 그대로 통과시킵니다. 이 시점에는 동작이 바뀌지 않아야 합니다.

  5. 2024 03

    1단계 — 관측 가능성 확보

    분산 추적과 구조화 로그를 먼저 넣습니다. 안 보이는 상태로 옮기면 문제 원인을 찾을 수 없습니다.

  6. 2024 01

    0단계 — 현황 파악과 경계 설정

    코드와 데이터 의존성을 실측합니다. 문서상 구조와 실제 호출 관계는 거의 항상 다릅니다.

함께 수행하는 것

  • 컨테이너 이관

    런타임 버전 고정과 이미지 최소화를 함께 진행합니다. 베이스 이미지 취약점은 이관 시점에 정리하는 것이 가장 쌉니다.

  • DevSecOps 파이프라인

    빌드 단계에 의존성 취약점 검사와 SBOM 생성을 넣습니다. 게이트는 처음부터 차단이 아니라 경고로 시작합니다.

  • 성능 예산 도입

    전환 전후 성능을 같은 기준으로 측정합니다. 체감이 아니라 숫자로 비교해야 논쟁이 끝납니다.

전환 계획을 검토받고 싶다면

이미 세운 계획이 있으시면 그 계획의 위험 구간을 짚어 드립니다.

문의하기