LLM 기반 워크플로우의 신뢰성 확보: Saga 패턴과 Event Sourcing으로 분산 트랜잭션 문제 해결하기

안녕하세요, 아키텍처 설계의 깊은 고민을 즐기는 개발자 여러분.

최근 LLM(Large Language Model)의 발전은 우리 시스템의 '지능' 레이어를 혁신적으로 끌어올렸습니다. RAG(Retrieval-Augmented Generation)를 통해 외부 지식을 검색하고, LLM이 그 결과를 바탕으로 복잡한 API 호출(Tool Calling)을 수행하며, 최종적으로 DB에 상태를 기록하는 워크플로우는 그야말로 마법처럼 보입니다.

하지만 이 '마법'의 이면에는 아키텍처 엔지니어들이 밤잠을 설칠 만한 거대한 숙제가 숨어있습니다. 바로 '분산 트랜잭션의 일관성(Consistency)' 문제입니다.

만약 LLM이 사용자 요청을 받아 $\rightarrow$ 외부 검색 API를 호출 $\rightarrow$ 결제 게이트웨이 API를 호출 $\rightarrow$ 내부 DB에 기록하는 4단계 워크플로우를 설계했다고 가정해 봅시다. 이 중 3단계(결제)는 성공했지만, 4단계(DB 기록)에서 네트워크 오류로 실패한다면? 시스템은 어떤 상태로 돌아가야 할까요?

기존의 단일 데이터베이스 환경에서는 ACID 트랜잭션으로 이 문제를 깔끔하게 해결했지만, 마이크로서비스 아키텍처(MSA)와 LLM의 비결정론적 흐름이 결합된 오늘날의 시스템에서는 ACID가 더 이상 충분하지 않습니다.

이 글에서는 이 복잡한 트랜잭션 딜레마를 해결하기 위한 두 가지 강력한 패턴, Saga 패턴과 Event Sourcing을 심도 있게 파헤치고, 이 둘을 결합하여 LLM 기반 워크플로우의 신뢰성을 극대화하는 실전 아키텍처 청사진을 제시하겠습니다.

1. LLM 시대의 트랜잭션 딜레마: 왜 ACID는 더 이상 충분하지 않은가?

우리가 흔히 아는 트랜잭션의 원칙은 ACID입니다. 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability). 이 네 가지는 단일 트랜잭션 경계 내에서 완벽하게 작동합니다.

하지만 MSA 환경에서는 트랜잭션 경계가 여러 서비스와 네트워크를 가로지릅니다. 이럴 때 가장 먼저 떠오르는 해결책이 **2PC (Two-Phase Commit)**입니다. 마치 모든 서비스가 '준비(Prepare)' 단계에서 모두 '예스'라고 대답해야만 '커밋(Commit)'하는 방식이죠.

문제점은 명확합니다:

1. 블로킹(Blocking): 2PC는 모든 참여 서비스가 트랜잭션이 끝날 때까지 자원을 잠가두는(Locking) 경향이 있습니다. 이는 시스템의 가용성(Availability)을 심각하게 저해합니다.
2. 결합도(Coupling): 모든 서비스가 트랜잭션의 성공 여부에 직접적으로 의존하게 만들어, 서비스 간의 결합도가 지나치게 높아집니다.

LLM 기반 워크플로우는 본질적으로 비동기적이며, 여러 외부 API 호출을 포함합니다. 여기에 2PC를 적용하는 것은 시스템 전체를 거대한 단일 트랜잭션으로 묶어버리는 것과 같아, 현대의 유연하고 확장 가능한 아키텍처 목표와 정면으로 충돌합니다.

2. 분산 트랜잭션의 표준 해법: Saga 패턴 심층 분석

2PC의 대안으로 가장 널리 사용되는 것이 바로 Saga 패턴입니다.

💡 Saga 패턴이란?

Saga는 '하나의 거대한 트랜잭션'을 여러 개의 **로컬 트랜잭션(Local Transaction)**의 순차적인 조합으로 간주합니다. 만약 중간 단계 중 하나라도 실패하면, Saga는 처음부터 다시 시작하는 대신, **'보상 트랜잭션(Compensation Transaction)'**을 실행하여 이미 성공했던 이전 단계들을 되돌리는 메커니즘을 가집니다.

쉽게 비유하자면, 여러 사람이 함께 큰 프로젝트를 진행하는데, 한 명이 실수해서 망쳤을 때, 전체를 처음부터 다시 하는 대신, '이전까지 했던 작업들을 역순으로 취소하는 회의'를 여는 것과 같습니다.

Saga 구현 방식 비교: 오케스트레이션 vs. 코레오그래피

Saga를 구현하는 방식은 크게 두 가지로 나뉩니다.

📌 실전 적용 팁: LLM 기반의 복잡한 워크플로우에서는 오케스트레이션 방식을 메인 컨트롤러(예: Workflow Engine 또는 전용 서비스)로 두고, 이 컨트롤러가 **메시지 브로커(Kafka 등)**를 통해 각 서비스에 명령을 내리는 하이브리드 방식이 가장 안정적입니다.

🛠️ 필수 예시: 주문 처리 워크플로우 (Saga 적용)

사용자가 주문을 시도하는 워크플로우를 예로 들어보겠습니다.

1. [Start] 주문 서비스가 요청 수신.
2. [Step 1] 주문 서비스 $\rightarrow$ 재고 서비스에 재고 차감 요청 이벤트 발행.
3. [Step 2] 재고 서비스 $\rightarrow$ 재고를 차감하고 재고 차감 성공 이벤트 발행.
4. [Step 3] 결제 서비스가 이 이벤트를 구독 $\rightarrow$ 결제 API 호출 $\rightarrow$ 결제 성공 이벤트 발행.
5. [Step 4] 주문 서비스가 이 이벤트를 구독 $\rightarrow$ DB에 최종 주문 기록 및 주문 완료 처리.

만약 Step 3에서 결제 실패가 발생한다면?

• 실패 감지: 결제 서비스가 실패 이벤트를 발행합니다.
• 롤백: 주문 서비스는 이 이벤트를 받아, Step 2에서 발생했던 '가상 재고 할당'을 취소하는 **보상 트랜잭션(Compensation Transaction)**을 실행합니다.

🚀 다음 단계: 상태 추적과 보상 트랜잭션

이 과정에서 가장 중요한 것은 **'어떤 단계까지 성공했고, 어떤 단계에서 실패했는지'**를 정확하게 추적하는 상태 머신(State Machine) 구현과, 실패 시 이전 단계를 되돌리는 보상 트랜잭션 설계 능력입니다.

🧠 심화 학습: Event Sourcing과 Saga 패턴

이러한 복잡한 분산 트랜잭션을 관리하는 가장 대표적인 아키텍처 패턴이 바로 Saga 패턴입니다. Saga는 여러 서비스에 걸친 분산 트랜잭션을 일련의 로컬 트랜잭션(Local Transaction)들의 시퀀스로 보고, 실패 시에는 보상 트랜잭션들을 실행하여 일관성을 유지합니다.

이러한 패턴을 구현하기 위해 **이벤트 소싱(Event Sourcing)**을 활용하는 것이 가장 강력한 방법론 중 하나입니다.

💡 요약 및 액션 플랜

다음 학습 목표: Saga 패턴을 구현하기 위해 Kafka와 같은 메시지 브로커를 활용하여, 서비스 간의 비동기적인 이벤트 흐름을 설계하고 구현하는 연습을 해보시는 것을 추천합니다.