모놀리식 아키텍처에서 마이크로서비스(MSA)로 전환할 때 개발자를 가장 괴롭히는 것 중 하나가 바로 ‘트랜잭션 관리’입니다. 여러 서비스에 걸친 데이터의 일관성(Consistency)을 어떻게 유지할 것인가? 한 서비스는 성공했는데 다른 서비스에서 에러가 나면 어떻게 되돌릴 것인가? 오늘은 이 복잡한 문제를 우아하게 해결해 주는 **Saga 패턴**의 원리와 실전 적용법을 상세히 알아보겠습니다.
[그림 1] Saga 패턴의 핵심: 로컬 트랜잭션의 연속과 보상 트랜잭션(Compensating Transaction)
1. 왜 분산 트랜잭션(2PC)은 안 될까?
과거에는 여러 DB를 묶어 하나처럼 다루는 2단계 커밋(2PC) 방식을 썼습니다. 하지만 MSA 환경에서는 치명적인 단점이 있습니다. 모든 서비스가 응답할 때까지 대기해야 하므로 성능이 급격히 떨어지고, 하나의 서비스만 장애가 나도 전체 시스템이 마비됩니다. 즉, **가용성보다 일관성에 너무 치중한 나머지 시스템을 경직**시킵니다.
2. Saga 패턴: 일관성을 ‘결과적’으로 맞추다
Saga 패턴은 거대한 트랜잭션을 여러 개의 **로컬 트랜잭션**으로 쪼개어 순차적으로 실행합니다. 만약 중간에 에러가 발생하면, 이전에 성공했던 작업들을 취소하는 **보상 트랜잭션(Compensating Transaction)**을 실행하여 데이터의 정합성을 맞춥니다. 이는 ‘즉시’ 맞추는 것이 아니라 ‘결과적’으로 맞추는 **결과적 일관성(Eventual Consistency)** 모델을 따릅니다.
3. 두 가지 구현 방식: 코레오그래피 vs 오케스트레이션
[그림 2] 이벤트 기반의 코레오그래피와 중앙 제어 방식의 오케스트레이션 비교
– **코레오그래피(Choreography)**: 중앙 통제관 없이 각 서비스가 이벤트를 주고받으며 반응합니다. 단순하고 서비스 간 결합도가 낮지만, 복잡해지면 전체 흐름을 파악하기 어렵습니다.
– **오케스트레이션(Orchestration)**: 중앙의 ‘Saga 인스턴스’가 전체 흐름을 지휘합니다. 로직이 복잡할 때 에러 처리가 명확하고 흐름 파악이 쉽지만, 중앙 관리자가 단일 실패 지점(SPOF)이 될 위험이 있습니다.
4. 실전 도입 시 주의사항
[그림 3] 성공적인 분산 트랜잭션 처리를 통해 확보된 데이터의 신뢰성과 무결성
Saga 패턴을 도입할 때는 반드시 **멱등성(Idempotency)**을 보장해야 합니다. 네트워크 오류로 인해 보상 트랜잭션이 여러 번 호출될 수 있기 때문입니다. 또한, 보상 트랜잭션 자체가 실패했을 때를 대비한 사후 모니터링 체계가 필수적입니다.
마치며: 복잡함을 수용하고 설계로 대응하기
MSA는 장점이 많지만, 데이터 정합성 관점에서는 지옥과 같습니다. 하지만 Saga 패턴과 같은 성숙한 설계 기법을 활용한다면, 시스템의 확장성을 유지하면서도 신뢰할 수 있는 비즈니스 로직을 구축할 수 있습니다. 여러분의 마이크로서비스에도 이 ‘우아한 취소 과정’을 도입해 보시기 바랍니다.