전담 예산 없이 모놀리스를 허물다: Pull-based Migration 전략
HR/급여 시스템을 운영하는 한 팀이 5년에 걸쳐 3개의 모놀리식 시스템을 120개 이상의 마이크로서비스로 전환하는 데 성공했다. 놀라운 점은 전담 마이그레이션 예산이 전혀 없었다는 것이다. 일반적으로 대규모 리아키텍처 프로젝트는 별도의 팀과 예산을 확보한 뒤 빅뱅 방식으로 진행되는 경우가 많다. 하지만 이 팀은 그 대신 기존 모놀리스를 건드리지 않고, 신규 기능을 개발할 때마다 독립 서비스로 구축하는 방식을 택했다.
이 전략의 핵심 철학은 단순하다. "새 기능은 절대 모놀리스 안에 넣지 않는다"는 하드 스톱(Hard-Stop) 규칙이다. 이를 통해 모놀리스는 자연스럽게 트래픽을 잃고, 새 서비스 쪽으로 점진적으로 부하가 이동한다.
Pull-based Migration이란 무엇인가
기존의 마이그레이션 접근법은 크게 두 가지로 나뉜다. 모놀리스를 통째로 교체하는 빅뱅 방식과, 모놀리스 내부 코드를 직접 분리해 나가는 스트랭글러 패턴이다. Pull-based Migration은 스트랭글러 패턴과 유사하지만 한 가지 중요한 차이가 있다. 기존 코드를 밀어내는(Push) 것이 아니라, 새 서비스가 트래픽과 책임을 스스로 당겨오는(Pull) 구조라는 점이다.
구체적으로는 다음과 같은 흐름으로 진행된다.
- 신규 기능 요청이 들어오면, 모놀리스 수정 대신 독립 서비스로 구현
- API Gateway 또는 라우팅 레이어에서 해당 도메인 트래픽을 새 서비스로 전환
- 기존 모놀리스의 해당 코드는 점진적으로 레거시 처리 후 제거
- 반복을 통해 모놀리스의 기능 범위가 자연스럽게 축소
// 기존 모놀리스 라우팅 → 신규 서비스로 점진적 전환 예시
@RestController
public class PayrollController {
@Autowired
private FeatureToggleService featureToggle;
@GetMapping("/payroll/calculate")
public ResponseEntity<?> calculate(@RequestBody PayrollRequest req) {
if (featureToggle.isEnabled("new-payroll-service")) {
return newPayrollServiceClient.calculate(req); // 신규 서비스로 위임
}
return legacyPayrollService.calculate(req); // 기존 모놀리스 처리
}
}
이처럼 피처 토글을 활용하면 배포 리스크 없이 트래픽 전환 시점을 유연하게 조정할 수 있다.
비용과 운영 문제를 어떻게 통제했나
120개 서비스로의 전환은 자칫 인프라 비용 폭증으로 이어질 수 있다. 이 팀은 비용 절감을 위해 도구 선택에 신중했으며, 서비스별 리소스 할당을 최소화하고 공유 인프라를 최대한 활용했다. 컨테이너 오케스트레이션과 서비스 메시를 도입해 소규모 서비스들의 운영 복잡도를 낮추는 데 집중했다.
분산 환경으로 전환하면서 실제로 마주친 문제들도 솔직하게 다루고 있다.
- 분산 트랜잭션 관리: 급여 계산처럼 원자성이 중요한 도메인에서 서비스 간 데이터 정합성 확보가 어려웠다
- 서비스 간 의존성 증가: 120개 서비스가 생기면서 장애 전파 경로가 복잡해졌고, 서킷 브레이커 도입이 필수가 됐다
- 디버깅 난이도 상승: 분산 추적(Distributed Tracing) 없이는 요청 흐름을 파악하기 어려워졌다
- 팀 간 도메인 경계 합의: 서비스 경계를 잘못 그으면 나중에 재분리 비용이 크게 발생했다
이러한 문제들은 마이크로서비스 전환을 검토하는 팀이라면 반드시 사전에 고려해야 할 현실적인 트레이드오프다.
정리
- 하드 스톱 규칙이 핵심: 신규 기능을 모놀리스에 추가하지 않는 원칙 하나가 5년에 걸친 전환의 동력이 됐다
- Pull-based Migration은 전담 예산 없이도 점진적·지속적으로 아키텍처를 개선할 수 있는 현실적인 전략이다
- 분산 전환 후에는 분산 트랜잭션, 장애 전파, 도메인 경계 설계가 새로운 핵심 과제로 부상한다