마이크로서비스 분산 트랜잭션, 우리 팀은 어떻게 해결하고 있습니까?

마이크로서비스 환경에서 분산 트랜잭션은 피할 수 없는 난관입니다. Saga 패턴과 TCC 패턴을 실제 프로젝트에 적용하며 겪었던 시행착오와 실무적인 팁을 공유합니다. 기술 선택의 기로에 선 테크리드를 위한 글입니다.

마이크로서비스 아키텍처(MSA)로 전환을 고민하거나 이미 적용 중인 팀이라면, 한 번쯤 분산 트랜잭션 문제로 밤잠을 설쳤을 것입니다. 단일 서비스 내에서는 ACID(원자성, 일관성, 고립성, 지속성) 트랜잭션으로 데이터 일관성을 쉽게 보장할 수 있지만, 여러 서비스에 걸쳐 비즈니스 로직이 수행될 때 이 벽에 부딪히게 됩니다. 우리 팀도 예외는 아니었습니다. 대규모 e-커머스 시스템을 MSA로 전환하는 과정에서 예상치 못한 데이터 불일치 문제에 직면했고, 이를 해결하기 위해 Saga 패턴과 TCC(Try-Confirm-Cancel) 패턴을 심도 깊게 비교, 적용해 본 경험이 있습니다. 이 글에서는 그 실무적인 과정과 얻은 교훈을 공유하려 합니다.

📑 목차

• 문제 발생: 마이크로서비스 도입 후 예상치 못한 데이터 불일치
• '주문 생성' 과정의 복잡성: 각 서비스의 독립성과 트랜잭션 경계
• 원인 분석: 2PC의 한계와 비즈니스 요구사항의 충돌
• 강결합을 피하면서 신뢰성을 확보하는 방법론 탐색
• 해결 과정: Saga 패턴과 TCC 패턴, 실무에서 비교 적용해 보니
• Saga 패턴: 장기 실행 비즈니스 프로세스에 유연하게 대응
• TCC (Try-Confirm-Cancel) 패턴: 엄격한 자원 예약이 필요한 경우
• Saga 패턴과 TCC 패턴 비교
• 교훈: 우리 팀에 맞는 패턴 선택과 운영의 중요성
• 선택은 끝이 아니다: 지속적인 모니터링과 개선

Image by Couleur on Pixabay

문제 발생: 마이크로서비스 도입 후 예상치 못한 데이터 불일치

저희는 모놀리식 아키텍처의 한계를 극복하고자 핵심 비즈니스 도메인을 중심으로 서비스를 분리했습니다. '주문' 도메인을 예로 들어보겠습니다. 사용자가 상품을 주문하면, '주문 서비스', '결제 서비스', ''재고 서비스', '배송 서비스' 등 여러 독립적인 서비스들이 유기적으로 동작해야 했습니다. 문제는 여기서 발생했습니다.

// 예시: 주문 생성 과정의 일부
void createOrder(OrderRequest request) {
    Order order = orderService.create(request); // 1. 주문 생성
    paymentService.processPayment(order.getOrderId(), request.getAmount()); // 2. 결제 처리
    inventoryService.deductStock(order.getProductId(), order.getQuantity()); // 3. 재고 차감

    // 만약 2번 또는 3번에서 실패하면? 1번은 이미 커밋됨!
}

위 코드처럼 단순하게 순차적으로 호출했을 때, '재고 서비스'에서 재고가 부족해 실패하거나 '결제 서비스'에서 네트워크 오류로 결제가 실패하는 상황이 발생하면 '주문 서비스'에 이미 생성된 주문 데이터는 어떻게 될까요? 주문은 생성되었지만 결제는 되지 않았거나, 재고는 줄지 않았는데 주문만 생성되는 심각한 데이터 불일치가 발생했습니다. 초기에는 수동으로 롤백하거나 배치 작업을 통해 보정했지만, 비즈니스 규모가 커질수록 감당할 수 없는 수준이 되었습니다.

'주문 생성' 과정의 복잡성: 각 서비스의 독립성과 트랜잭션 경계

각 서비스는 독립적인 데이터베이스를 가지고 있었습니다. 이는 MSA의 핵심 원칙 중 하나이지만, 비즈니스 트랜잭션이 여러 서비스에 걸쳐 이루어질 때 전통적인 RDBMS의 2PC(Two-Phase Commit) 방식은 사실상 적용하기 어려웠습니다. 2PC는 서비스 간 강한 결합을 유발하고, 한 서비스라도 실패하면 전체 시스템의 가용성에 영향을 미칠 수 있기 때문입니다. 우리는 MSA의 장점을 유지하면서 어떻게 데이터 일관성을 보장할 것인지에 대한 해답을 찾아야 했습니다.

원인 분석: 2PC의 한계와 비즈니스 요구사항의 충돌

저희 팀이 직면한 문제는 분산 트랜잭션의 본질적인 어려움과 MSA의 철학 사이의 충돌이었습니다. MSA는 서비스의 독립성과 자율성을 강조하며, 이는 각 서비스가 자신의 데이터베이스를 관리하고 다른 서비스의 데이터에 직접 접근하지 않음을 의미합니다. 이러한 환경에서, '모든 서비스가 성공해야만 커밋되고, 하나라도 실패하면 모두 롤백되는' 엄격한 ACID 트랜잭션 모델을 구현하는 것은 매우 복잡하고 시스템 전반의 성능 저하 및 가용성 문제를 야기할 수 있습니다.

강결합을 피하면서 신뢰성을 확보하는 방법론 탐색

우리는 2PC가 마이크로서비스 환경에 적합하지 않다는 결론을 내리고, 궁극적인 일관성(Eventual Consistency) 모델을 기반으로 하는 대안을 모색했습니다. 핵심은 보상 트랜잭션(Compensating Transaction)이었습니다. 즉, 하나의 서비스에서 작업이 성공적으로 수행되었지만 이후의 서비스에서 문제가 발생했을 때, 이미 수행된 작업을 취소하는 보상 작업을 통해 최종적인 일관성을 맞추는 방식입니다. 이 과정에서 Saga 패턴과 TCC 패턴이 가장 유력한 후보로 떠올랐습니다.

Image by jhenning on Pixabay

해결 과정: Saga 패턴과 TCC 패턴, 실무에서 비교 적용해 보니

두 패턴 모두 보상 트랜잭션을 기반으로 분산 트랜잭션을 처리하지만, 접근 방식과 적용 시나리오에 차이가 있었습니다. 우리는 비즈니스 중요도와 복잡성에 따라 두 가지 패턴을 모두 검토하고 일부 영역에 실제 적용해 보았습니다.

Saga 패턴: 장기 실행 비즈니스 프로세스에 유연하게 대응

Saga 패턴은 일련의 지역 트랜잭션(Local Transaction)으로 구성되며, 각 지역 트랜잭션은 자체 데이터베이스에 커밋됩니다. 만약 어느 한 지역 트랜잭션에서 실패가 발생하면, 이전에 성공한 지역 트랜잭션들을 보상 트랜잭션을 통해 취소하여 전체 프로세스를 롤백합니다.

저희는 Saga 패턴을 '주문 생성'과 같이 여러 서비스에 걸쳐 장기적으로 실행되는 비즈니스 프로세스에 우선 적용했습니다. Saga 패턴은 크게 두 가지 방식으로 구현할 수 있습니다.

• Choreography (코레오그래피): 각 서비스가 이벤트를 발행하고 구독하여 서로 조율하는 방식입니다. 초기 구현이 비교적 간단하고 서비스 간 결합도가 낮다는 장점이 있습니다. 하지만 Saga의 전체 흐름을 한눈에 파악하기 어렵고, 실패 시 보상 트랜잭션의 연쇄적인 실행을 추적하고 관리하는 것이 복잡했습니다. 실제로 저희는 몇 차례의 예상치 못한 연쇄 실패 상황에서 원인 파악에 많은 시간을 소모했습니다.
• Orchestration (오케스트레이션): Saga를 전담하는 오케스트레이터(Orchestrator) 서비스가 존재하여 Saga의 전체 흐름을 중앙에서 관리합니다. 오케스트레이터가 각 서비스에 명령을 보내고 응답을 받아 다음 단계를 결정합니다. 초기 구현 비용은 더 들지만, Saga의 흐름을 명확하게 파악할 수 있고 실패 처리가 용이하다는 장점이 있었습니다. 복잡한 비즈니스 로직에 더 적합하다고 판단하여, 핵심 주문 프로세스에는 오케스트레이션 방식을 도입했습니다.

TCC (Try-Confirm-Cancel) 패턴: 엄격한 자원 예약이 필요한 경우

TCC 패턴은 Try, Confirm, Cancel 세 단계로 나뉩니다.

• Try: 자원을 예약하거나 잠재적인 작업을 준비합니다. 실제 작업을 수행하지 않고, 작업 가능 여부만 확인하거나 자원을 선점합니다. (예: 재고를 임시로 홀딩)
• Confirm: 모든 Try 단계가 성공하면, 예약했던 자원을 최종적으로 커밋합니다.
• Cancel: Try 단계 중 하나라도 실패하면, 이전에 예약했던 자원들을 취소합니다.

TCC 패턴은 Saga 패턴보다 더 엄격한 일관성을 제공하며, 특정 자원의 동시성 제어가 필요한 시나리오에 유용합니다. 저희는 '고가 상품의 한정 수량 예약'이나 '특정 금융 거래'와 같이 자원 예약의 실패가 치명적이고 즉각적인 롤백이 필요한 경우에 TCC 패턴을 적용했습니다. 예를 들어, 한정판 상품 구매 시 Try 단계에서 재고를 미리 '예약'하고, 결제까지 완료되면 Confirm으로 재고를 '확정'하는 방식입니다. 만약 결제에 실패하면 Cancel로 예약된 재고를 즉시 '반환'합니다.

Saga 패턴과 TCC 패턴 비교

실제 적용 경험을 바탕으로 두 패턴의 특징을 비교해 보았습니다.

구분	Saga 패턴	TCC 패턴
일관성 모델	궁극적 일관성(Eventual Consistency)	강한 일관성(Strong Consistency)에 가까움 (자원 예약 기반)
구현 복잡도	코레오그래피는 간단하나 추적 어렵고, 오케스트레이션은 복잡도 높음	모든 서비스가 Try/Confirm/Cancel 인터페이스를 구현해야 하므로 복잡도가 높음
롤백 메커니즘	보상 트랜잭션을 순차적으로 실행하여 이전 작업 취소	Cancel 단계를 통해 예약된 자원 해제
주요 사용처	장기 실행 비즈니스 프로세스 (예: 주문 처리, 워크플로우)	자원 예약 및 잠금이 필요한 비즈니스 (예: 금융 거래, 한정 재고 예약)
트랜잭션 오버헤드	낮음 (이벤트 기반 비동기 통신)	높음 (3단계 동기 호출, 자원 잠금)
장점	서비스 간 느슨한 결합 유지, 높은 가용성	강력한 데이터 일관성 보장, 중간 상태의 명확한 관리
단점	디버깅 및 모니터링 복잡성, 보상 트랜잭션 구현의 어려움	서비스 간 강한 결합, 구현 복잡도, 타임아웃 처리의 어려움

교훈: 우리 팀에 맞는 패턴 선택과 운영의 중요성

두 패턴을 적용하면서 얻은 가장 큰 교훈은 '은총알은 없다'는 것이었습니다. 어떤 패턴이든 완벽한 해결책은 없으며, 팀의 상황, 비즈니스 요구사항, 그리고 각 패턴이 가진 장단점을 명확히 이해하고 선택해야 한다는 점입니다.

• 비즈니스 특성 고려: '주문 생성'처럼 장기 실행되고 여러 단계가 비동기적으로 진행되어도 무방한 프로세스에는 Saga 패턴이, '한정판 상품 예약'처럼 즉각적인 자원 확보와 롤백이 중요한 경우에는 TCC 패턴이 더 적합했습니다.
• 복잡도 관리: Saga 패턴의 코레오그래피는 단순한 시나리오에 적합하지만, 비즈니스 로직이 복잡해질수록 오케스트레이션 방식이 관리 측면에서 유리했습니다. TCC 패턴은 모든 서비스가 Try/Confirm/Cancel 인터페이스를 구현해야 하므로, 개발 초기 단계에 설계 부담이 컸습니다.
• 모니터링과 가시성: 분산 트랜잭션은 실패 지점을 파악하고 롤백 과정을 추적하는 것이 매우 중요합니다. Saga 패턴의 경우, 오케스트레이터를 통해 상태를 중앙에서 관리하거나 분산 로깅 및 트레이싱 도구를 적극 활용하여 가시성을 확보하는 데 집중했습니다.
• 멱등성(Idempotency) 구현: 보상 트랜잭션이나 재시도 과정에서 동일한 작업이 여러 번 실행될 수 있으므로, 모든 서비스 작업은 멱등성을 갖도록 설계하는 것이 필수적이었습니다.

선택은 끝이 아니다: 지속적인 모니터링과 개선

패턴을 선택하고 적용하는 것만큼 중요한 것은 운영 과정에서의 지속적인 모니터링과 개선입니다. 저희는 아래와 같은 사항들을 중점적으로 관리했습니다.

• 실패 알림 시스템: 분산 트랜잭션 실패 시 즉각적으로 담당자에게 알림이 가도록 시스템을 구축했습니다.
• 재시도 정책: 일시적인 네트워크 오류 등으로 인한 실패는 자동 재시도 로직을 통해 처리했습니다.
• 수동 보정 프로세스: 자동 롤백이나 재시도로 해결되지 않는 복잡한 실패 상황에 대비하여, 운영자가 개입하여 데이터를 수동으로 보정할 수 있는 절차와 도구를 마련했습니다.

결론적으로, 마이크로서비스 환경에서 분산 트랜잭션 문제를 해결하는 것은 단순히 기술 패턴을 적용하는 것을 넘어, 비즈니스 요구사항과 시스템의 복잡도를 깊이 이해하고 팀의 역량에 맞는 최적의 균형점을 찾아 나가는 여정입니다. 우리 팀은 이 과정을 통해 기술 선택의 폭을 넓혔을 뿐만 아니라, 복잡한 시스템을 안정적으로 운영하는 귀중한 경험을 얻을 수 있었습니다.

여러분 팀은 분산 트랜잭션 문제를 어떻게 해결하고 계신가요? 여러분의 경험과 노하우를 댓글로 공유해 주시면 감사하겠습니다.

📌 함께 읽으면 좋은 글

• [테스트 QA] 개발자 면접 필수! Cyclomatic Complexity와 Maintainability Index, 7가지 오해와 진실
• [이슈 분석] 개발 생산성 30% 높인 마법의 숫자 제거 경험: PM/기획자가 알아야 할 코드 품질 개선
• [이슈 분석] 오래된 COM/DCOM 컴포넌트, 현대 웹 서비스와 유연하게 연결하는 실전 전략

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.