무엇을 먼저 바꾸나
데이터는 어떻게 이동하나
언제 잘 맞나
쓰기 경로를 먼저 엶
듀얼 라이트
애플리케이션의 쓰기를 두 저장소로 보냅니다
앱이 RDB와 NoSQL에 함께 기록하고, 읽기는 나중에 천천히 넘깁니다.
App → RDB + NoSQL
같은 요청 결과를 두 DB에서 비교하며 정합성을 직접 확인할 수 있습니다.
읽기 전환을 단계적으로 검증할 때
초기엔 구현 부담이 있지만, 비교 데이터가 가장 선명하게 남습니다.
로그 복제를 먼저 둠
CDC
기존 앱의 쓰기 방식은 그대로 둡니다
애플리케이션은 계속 RDB에 쓰고, 변경 로그가 새 저장소를 따라가게 합니다.
App → RDB → 변경 로그 → NoSQL
동기화 책임이 앱이 아니라 복제 파이프에 모이므로 코드 변경을 줄일 수 있습니다.
기존 서비스 코드를 크게 건드리기 어려울 때
복제 지연과 장애 대응은 별도로 운영해야 합니다.
기능 경계를 먼저 나눔
스트랭글러
새 기능이나 일부 도메인만 새 DB로 분리합니다
기존 기능은 남겨 두고, 경계가 분명한 부분부터 NoSQL로 옮깁니다.
기능별로 RDB와 NoSQL이 공존
한 시스템 안에서 저장소 경계를 나누고, 전환 범위를 기능 단위로 넓혀 갑니다.
전체 동시 전환보다 위험을 작게 격리하고 싶을 때
도메인 경계를 잘못 잡으면 운영 복잡도가 오래 남을 수 있습니다.
읽는 법
앱이 직접 두 DB에 쓰면 듀얼 라이트, 변경 로그가 뒤에서 따라가면 CDC, 기능별로 새 DB를 붙이면 스트랭글러입니다. 즉 전략 선택은 “무엇을 먼저 바꿀 것인가”를 정하는 일입니다.