최근 거대 금융 플랫폼이나 대형 이커머스 기업들의 IT 인프라 고도화 프로젝트를 살펴보면, 시스템의 극한적인 확장성과 배포 민첩성을 확보하기 위해 기존의 거대한 모놀리식(Monolithic) 아키텍처를 마이크로서비스 아키텍처(MSA)로 전환하는 것을 뚜렷한 기술적 표준으로 채택하고 있습니다. 그러나 실제 핀테크나 커머스 도메인에서 MSA 구조를 설계하고 실무에 적용해 보면, 가장 뼈아픈 기술적 장벽으로 다가오는 것이 바로 ‘분산 트랜잭션(Distributed Transaction)’의 정합성 문제입니다. 서비스가 독립적인 데이터베이스를 가지게 되면서 기존에 누리던 물리적인 데이터 무결성을 상실하게 되기 때문입니다. 본 포스팅에서는 이러한 MSA 환경의 치명적인 단점을 극복하고, 서비스 간의 논리적 데이터 무결성을 완벽하게 보장하는 사가(Saga) 패턴의 공학적 구조와 통계적 보상 원리에 대해 심층적으로 분석합니다.
단일 데이터베이스의 물리적 한계와 2PC(Two-Phase Commit)의 클라우드 네이티브 부적합성
전통적인 모놀리식 시스템에서는 하나의 거대한 관계형 데이터베이스(RDBMS) 내에서 ACID(원자성, 일관성, 고립성, 지속성) 원칙이 완벽하게 지켜졌습니다. 주문, 결제, 재고 차감이 하나의 트랜잭션으로 묶여 있었기 때문에, 어느 한 단계에서라도 오류가 발생하면 데이터베이스 엔진이 알아서 전체 과정을 즉시 롤백(Rollback)시킬 수 있었습니다. 하지만 MSA 환경에서는 주문 서비스, 결제 서비스, 재고 서비스가 물리적으로 완전히 분리된 각자의 데이터베이스를 소유합니다.
분산 잠금(Distributed Lock)과 성능 병목 현상
초기에는 여러 개의 독립된 데이터베이스를 하나의 트랜잭션처럼 묶기 위해 2PC(Two-Phase Commit)라는 분산 트랜잭션 프로토콜이 활용되었습니다. 모든 분산 노드(서비스)에 “준비가 되었는가?”를 묻고, 모든 노드가 “그렇다”라고 응답해야만 커밋을 수행하는 중앙 통제 방식이었습니다. 그러나 2PC는 치명적인 결함을 내포하고 있습니다.
모든 마이크로서비스가 응답할 때까지 관련된 모든 데이터베이스의 레코드(Record)에 강력한 잠금(Lock)이 걸려 대기 상태에 빠지게 됩니다. 클라우드 네이티브 환경처럼 수천 건의 요청이 쏟아지는 분산 시스템에서 이러한 잠금 현상은 시스템 전체의 응답 지연(Latency)을 유발하고 끔찍한 병목을 초래합니다. 결과적으로 서비스의 독립적인 확장(Scale-out)을 불가능하게 만들어 MSA를 도입한 본질적인 이유 자체를 부정하게 됩니다.
사가(Saga) 패턴의 핵심 동작 원리: 로컬 트랜잭션의 연속적 체인(Chain)
2PC의 무거운 동기적 잠금 문제를 해결하기 위해 고안된 MSA의 사실상(De facto) 표준 분산 트랜잭션 아키텍처가 바로 사가(Saga) 패턴입니다. 사가 패턴은 전체 비즈니스 프로세스를 여러 개의 ‘로컬 트랜잭션(Local Transaction)’으로 아주 잘게 쪼갭니다. 각 마이크로서비스는 자신의 데이터베이스에서만 트랜잭션을 실행하고 커밋한 뒤, 다음 서비스가 자신의 작업을 수행할 수 있도록 비동기 메시지나 이벤트(Event)를 발행(Publish)합니다.
코레오그래피(Choreography) 방식과 오케스트레이션(Orchestration) 방식의 구조적 차이
사가 패턴을 구현하여 시스템의 무결성을 유지하는 방법은 메시지를 중계하고 흐름을 통제하는 아키텍처 설계에 따라 크게 두 가지로 분류됩니다. (※ 기존 마크다운 표에서 발생할 수 있는 레이아웃 충돌을 방지하기 위해 구조화된 목록 형태로 핵심을 비교합니다.)
- 코레오그래피(Choreography) 사가 패턴:
중앙의 통제자 없이, 각 마이크로서비스가 이벤트를 발행하고 구독하는 P2P(Peer-to-Peer) 방식입니다. 주문 서비스가 ‘주문 생성됨’ 이벤트를 카프카(Kafka)와 같은 메시지 브로커에 던지면, 결제 서비스가 이를 감지하여 결제를 진행하고 다시 ‘결제 완료됨’ 이벤트를 던집니다. 참여하는 서비스가 3~4개 이하로 적을 때 구축이 매우 빠르고 단일 장애점(SPOF)이 없다는 장점이 있으나, 서비스가 많아지면 이벤트의 흐름을 추적하기 어려워지는 단점이 있습니다. - 오케스트레이션(Orchestration) 사가 패턴:
중앙에 오케스트레이터(Orchestrator)라는 별도의 제어 컴포넌트를 두어 전체 트랜잭션의 상태 머신(State Machine)을 관리하는 방식입니다. 교향악단의 지휘자처럼 오케스트레이터가 주문 서비스에게 작업을 지시하고, 결과를 받으면 다시 결제 서비스에게 명령을 내립니다. 시스템의 복잡도가 높은 거대 금융 시스템이나 이커머스에서 전체 프로세스의 가시성을 확보하고 트랜잭션 실패 시 복구 로직을 중앙에서 안전하게 제어하기 위해 필수적으로 채택됩니다.
이러한 비동기 이벤트 기반의 아키텍처는 과거 포스팅인 🔗 내부 링크: 고빈도 매매(HFT) 시스템의 주문 집행 알고리즘(VWAP, TWAP) 내 지정가 주문 체결 확률 극대화 최적화 기법]에서 다루었던 분산 메시징 처리 파이프라인의 설계 철학과 그 공학적 맥락을 정확히 같이합니다.
논리적 데이터 무결성 보장: 보상 트랜잭션(Compensating Transaction)과 최종 일관성
사가 패턴에서 가장 중요한 수학적, 논리적 난제는 “중간에 에러가 발생했을 때 어떻게 롤백할 것인가?”입니다. 예를 들어, [주문 완료] -> [결제 완료]까지는 성공했는데 마지막 [재고 차감] 단계에서 재고 부족으로 에러가 발생했다고 가정해 보겠습니다. 이미 결제 서비스는 자신의 데이터베이스에 커밋을 완료해 버렸기 때문에 과거처럼 단순한 DB 롤백 명령어를 사용할 수 없습니다.
“MSA 환경의 사가 패턴에서 데이터 무결성은 물리적 롤백(Rollback)이 아닌, 의미론적 취소를 수행하는 보상 트랜잭션(Compensating Transaction)과 시스템이 시간이 흐른 뒤 최종적으로 동일한 상태에 수렴하게 되는 최종 일관성(Eventual Consistency)에 의해 논리적으로 보장됩니다.”
재고 차감에 실패한 서비스는 즉시 ‘재고 부족 실패 이벤트’를 메시지 브로커로 발행합니다. 이 실패 이벤트를 수신한 결제 서비스는 과거에 자신이 수행했던 결제 내역을 취소하는 새로운 로컬 트랜잭션(즉, 환불 처리)을 실행합니다. 이어서 환불 완료 이벤트가 발행되면 주문 서비스가 이를 받아 주문 상태를 ‘취소됨’으로 변경합니다. 이처럼 역순으로 실패를 보정하는 로직을 미리 프로그래밍해 두어 데이터의 논리적 정합성을 맞추는 과정이 바로 보상 트랜잭션의 본질입니다.
실무 적용 시 필수 고려사항 및 MSA 아키텍처 설계 인사이트
결론적으로 마이크로서비스 아키텍처 환경에서 사가 패턴의 도입은 선택이 아닌 필수입니다. 하지만 실무적으로 이를 구현할 때는 네트워크 지연이나 장애로 인해 동일한 실패 이벤트가 두 번 이상 전달될 수 있는 분산 컴퓨팅의 치명적 오류 가능성을 반드시 방어해야 합니다. 따라서 모든 보상 트랜잭션 함수는 동일한 요청이 여러 번 들어와도 결과가 항상 동일하게 유지되는 멱등성(Idempotency)을 원칙으로 설계되어야만 중복 환불과 같은 대형 금융 사고를 막을 수 있습니다.
최근 오픈뱅킹 시스템이나 대규모 핀테크 플랫폼들은 분산 환경에서의 극단적인 스케일 아웃을 감당하기 위해 데이터베이스의 강한 일관성(Strong Consistency)을 과감히 포기하고 있습니다. 대신 카프카(Apache Kafka)와 같은 강력한 이벤트 스트리밍 플랫폼 위에 사가 패턴을 얹어 최종 일관성(Eventual Consistency)을 확보하는 유연한 전략으로 선회했습니다. 🔗 외부 링크 삽입 추천: Microservices.io의 공식 사가(Saga) 패턴 아키텍처 설계 가이드]를 참고하면 이러한 전환의 글로벌 스탠다드를 명확히 확인할 수 있습니다.
데이터의 동기적 잠금에 집착하는 과거의 낡은 엔지니어링 패러다임으로는 초당 수만 건의 트랜잭션이 발생하는 현대 자본 시장의 속도를 결코 따라갈 수 없습니다. 트랜잭션의 실패를 자연스러운 비즈니스의 일부로 인정하고, 정교하게 짜인 보상 트랜잭션의 춤(Choreography)과 지휘(Orchestration)를 통해 오류를 스스로 치유(Self-healing)하는 사가 패턴이야말로, 진정한 클라우드 네이티브 시대를 완성하는 궁극의 소프트웨어 공학적 마스터피스라 할 수 있습니다.