550. 사가 패턴 (Saga Pattern) - 로컬 트랜잭션들의 연속된 체인

핵심 인사이트 (3줄 요약)

1. 본질: 사가(Saga) 패턴은 분산된 50개의 마이크로서비스 DB를 동시에 묶어버리는 멍청한 글로벌 자물쇠(2PC)를 도끼로 찍어내고, 각 서비스가 철저하게 "자기 앞마당(로컬 DB)만 Commit 치고 빠진 뒤" 다음 서비스로 릴레이 바통(비동기 이벤트)을 던지는 극강의 이어달리기(Chain) 아키텍처다.
2. 가치: 락(Lock)을 전혀 걸지 않기에 전사 시스템의 속도(가용성)가 미친 듯이 펌핑된다. 만약 릴레이 중간에 배송 서버가 터졌다면? 시스템 전체가 멈추거나 마법처럼 롤백되는 게 아니라, 바통을 거꾸로 역주행시키며 "야 취소해! 돈 돌려줘!"라는 보상(Compensation) 편지를 뿌려 물리적 에러를 논리적 환불로 우아하게 뒷수습해 내는 클라우드의 생존 헌법이다.
3. 융합: "100% 실시간 무결성(ACID)"을 버리고 "찰나엔 데이터가 틀려도 결국엔 맞는다(BASE/Eventual Consistency)"라는 타협을 이뤘으며, 이벤트를 어떻게 던질지에 따라 **오케스트레이터(552장)**의 중앙 지휘 방식과 **코레오그래피(553장)**의 무법 지대 비보이 댄스 방식으로 나뉘며 EDA(이벤트 주도) 생태계와 완벽히 융합된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: '사가(Saga)'는 원래 장편 대서사시를 뜻하는 단어다. 1초 만에 쾅 찍고 끝나는 원시적 DB 쿼리가 아니라, 주문 ➡ 결제 ➡ 포장 ➡ 배송으로 이어지는 기나긴 여정(Long-lived Transaction)을 쪼개어 놓은 것이다. 1번 앱이 자기 DB에 저장(Commit)하고 Kafka에 이벤트를 쏘면 ➡ 2번 앱이 주워 먹고 저장하고 쏘고 ➡ 3번 앱이 주워 먹는, **서로 100% 격리된 '로컬 트랜잭션들의 연속된 체인'**이다.

• 필요성: 이전 장(549장)에서 2PC(Two-Phase Commit)가 클라우드 환경의 네트워크 딜레이를 만나 분산 모놀리스를 낳으며 무참히 멸망했다는 것을 보았다. "아니, 여러 대의 서버 DB를 동시에 락(Lock)으로 묶으니까 다 같이 렉이 걸려 뻗어버리잖아! 그럼 락을 다 풀어버려! 그냥 지 로컬 DB에만 빠르게 저장하고 다음 놈한테 메시지 카톡으로 던지고 신경 끄자!" 이 발상의 전환이 무정지(Zero-Downtime) MSA를 위해 반드시 필요했다.

• 💡 비유: 사가 패턴은 아마존(AWS)의 **'택배 배달 릴레이'**와 똑같습니다. 옛날(2PC)엔 판매자, 포장 직원, 배달부 3명이 한 줄로 서서 동시에 손을 잡고 물건을 넘겨야만 했습니다. 한 명이 똥 싸러 가면 전체가 멈췄죠. 사가 패턴은 그냥 판매자가 물건을 박스에 넣고 허공(컨베이어 벨트)에 툭 던져버립니다(Commit 쾅! 락 없음). 포장 직원이 자기 편할 때 그걸 주워다 포장하고 던집니다. 배달부가 오토바이 타다 넘어졌나요? 그럼 롤백하는 게 아니라 반송 딱지(보상 트랜잭션)를 붙여서 거꾸로 컨베이어 벨트에 태워 환불 처리하면 끝입니다. 아무도 서로를 무식하게 기다리지 않습니다.

• 등장 배경 및 발전 과정:

  1. Hector Garcia-Molina 논문 (1987): 30년 전에 이미 "졸라 긴 트랜잭션은 중간에 락 걸지 말고 걍 쪼개서 실행하다 터지면 반대 로직(보상)으로 수습해!"라는 미친 논문이 나왔지만, DB 1대 짜리 시절이라 다들 무시했다.
  2. Microservices의 대유행 (2010s): DB가 서비스마다 찢어지자 글로벌 롤백(Rollback)이 물리적으로 불가능해졌다. 옛날 1987년 사가 논문이 부활하며 "아, 분산 환경에선 락을 걸면 죽는구나. 이벤트 기반의 사가 패턴만이 유일한 생명줄이구나!"라며 클라우드의 표준으로 채택됐다.

• 📢 섹션 요약 비유: 로컬 트랜잭션(모놀리식)이 **'도미노 1만 개를 단 1초 만에 마법처럼 다 넘어뜨리는 신의 손짓'**이라면, 사가 패턴은 **'사람 5명이 한 줄로 서서 도미노를 한 블록씩 릴레이로 넘어뜨려 가는 인간의 노가다'**입니다. 3번째 사람이 실수해서 도미노가 끊어지면? 1번 사람이 신의 마법처럼 시간을 되돌릴 순 없으니, 그냥 뒤로 걸어가면서 쓰러진 도미노를 다시 하나씩 손으로 직접 세워놓는 눈물겨운 뒷수습(보상 트랜잭션) 릴레이가 사가 패턴의 민낯이자 위대함입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

1. 사가(Saga) 패턴의 정상 릴레이 동작 (Happy Path)

자물쇠(Lock)가 완전히 배제된 순수한 릴레이 아키텍처.

[ 🛡️ 주문 ➡ 결제 ➡ 재고 (정상 흐름) ]

1. 주문 로컬 TX (T1): 주문 서버가 자기 DB에 Status: PENDING(대기 중)으로 인서트 때린다(Commit). 락 안 걸고 바로 끝! 그리고 Kafka에 주문 생성됨 이벤트 훅 던짐.
2. 결제 로컬 TX (T2): 결제 서버가 이벤트 읽고 자기 DB에서 고객 돈 1만 원 깎는다(Commit). 끝! Kafka에 결제 완료됨 이벤트 던짐.
3. 재고 로컬 TX (T3): 재고 서버가 이벤트 읽고 상품 1개 깐다(Commit). 끝! Kafka에 재고 차감 완료 이벤트 던짐.
4. 최종 완료: 주문 서버가 그 이벤트 듣고 자기 DB를 Status: COMPLETED(완료)로 업데이트한다. ▶ 특징: 그 어디에도 3개 DB를 동시에 묶는 락(Global Lock)이 없다. 각자 10ms 만에 치고 빠졌다.

2. 에러 폭발과 보상 트랜잭션 역주행 (Failure Path) 💥 (핵심)

데이터 정합성을 유지하는 사가 패턴의 진짜 마술.

[ 💥 재고 서버 품절로 인한 롤백 방어선 ]

1. T1(주문) ➡ T2(결제 완료)까지는 위와 똑같이 시원하게 돈 뺐다.
2. 재고 에러 폭발: 재고 서버가 까보니까 물건이 품절이다. 로컬 저장 실패!
3. 보상 트랜잭션 T2 (C2) 발동: 재고 서버는 로컬 롤백 치고 ➡ Kafka에 재고 없으니 싹 다 취소해!(Compensation Event) 쏜다.
4. 결제 서버가 이걸 줏어먹는다. 과거에 이미 Commit 한 건 물리적 롤백이 안 되니까, 로직으로 고객 돈 +1만 원(환불) 쿼리를 때린다(C2 Commit).
5. 주문 서버가 Status: CANCELED(취소됨)로 바꾸며 전체 거대한 트랜잭션 여정을 아무도 피 흘리지 않고 무사히 종료(0원 원상 복구)시킨다.

• 📢 섹션 요약 비유: 정상 사가(Saga) 흐름이 **'A역 -> B역 -> C역으로 무정차 직진하는 쾌속 KTX 기차'**라면, 에러 났을 때의 사가는 **'C역에서 철로가 끊긴 걸 보고, 기관사가 기차 후진 기어를 넣고 덜컹덜컹 B역(환불) -> A역(취소)으로 힘겹게 역주행하여 출발지로 승객을 온전히 데려다 놓는 역방향 백무빙(보상 트랜잭션)'**입니다. 2PC처럼 중간에 선로에 멈춰서 수갑 차고 있는 일은 절대 없습니다.

Ⅲ. 융합 비교 및 다각도 분석

1. 분산 트랜잭션 철학 비교 (2PC vs Saga)

어디가서 아는 척하기 제일 좋은 트레이드오프 표.

과목 융합 관점

• 클라우드 컴퓨팅 (Eventual Consistency, 결과적 정합성): 사가 패턴의 영혼이다. 로컬 DB는 데이터를 넣자마자 누구나 100% 똑같이 보는(Strong Consistency) 세계다. 그러나 사가는 결제 서버가 1만 원을 빼고 ➡ Kafka에 메시지가 1초 동안 날아가는 ➡ 그 '1초의 아찔한 틈(Gap)' 동안 유저는 "돈은 빠졌는데 결제 대기 중이네?"라는 이질적인 짝짝이 상태를 보게 된다. 이걸 Soft State라 부른다. 하지만 1초 뒤 메시지가 도착하면 결국(Eventually) 상태가 100% 깔끔하게 일치하게 된다. 이 '찰나의 불일치'를 허용하는 대가로 우리는 10만 명 접속을 버티는 미친 속도를 얻었다.

• 소프트웨어 공학 (멱등성, Idempotency): 551장에서 심화할 내용이다. 배송 실패해서 환불(-100원) 편지를 날렸다 쳐보자. 네트워크가 미쳐서 환불 편지가 결제 서버에 3장 날아갔다. 결제 서버가 무지성으로 환불을 3번 때려버리면 고객은 100원을 결제하고 300원을 환불받는 돈 복사 버그가 터진다. 아키텍트는 반드시 모든 보상 트랜잭션 수신단에 "이 주문번호 환불은 1번만 적용돼!"라는 멱등성(Idempotency) 로직을 겹겹이 떡칠해 놔야 사가 패턴의 붕괴를 막을 수 있다.

• 📢 섹션 요약 비유: 2PC의 ACID는 **'은행 금고 안에서 조용히 1초 만에 계좌 이체를 끝내는 완벽한 마술'**입니다. 밖에서는 과정이 전혀 안 보입니다. 사가 패턴(BASE)은 **'직원 3명이 돈다발을 들고 길거리를 1km 릴레이로 뛰어가는 공개 운송'**입니다. 밖에서 사람들이 "어? 돈이 1번 직원한테서 2번 직원한테 날아가고 있네?"(격리성 상실, Dirty Read) 과정을 다 구경할 수 있습니다. 하지만 결국 마지막 3번 직원 은행에 안전하게 돈이 꽂힌다(Eventual)는 점에서, 엄청나게 유연하고 시스템이 멈추지 않는 최고의 분산 운송법입니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — '시맨틱 락(Semantic Lock)' 없는 더티 리드(Dirty Read)의 파국: 게임 회사에서 아이템 구매를 사가 패턴으로 짰다. [결제(T1)] ➡ [재고 확인(T2)] ➡ [아이템 지급(T3)] 순서다. 유저가 1만 원을 결제했다. 결제(T1)가 성공하고 로컬 DB에 Commit이 쾅 박혔다! 이제 T2, T3 메시지가 날아가는 3초가 떴다. 해커가 이 3초 사이에 재빠르게 접속해서 "어? 내 결제 DB 보니까 1만 원 결제됐네? 환불 버튼 당장 눌러!" 라며 돈을 1만 원 돌려받았다. 3초 뒤, 게임 아이템 지급(T3) 서버에 뒤늦게 카프카 메시지가 도착하여 해커 계정으로 100만 원어치 아이템이 콸콸 지급되었다. 돈은 환불받고 아이템은 훔쳐 먹은 완벽한 시차 사기(Anomaly)다.

   • 아키텍트의 해결책: 격리성(Isolation) 상실에 대한 락(Lock)의 어플리케이션 레벨 부활이다. DB가 안 막아주니 개발자가 손으로 막아야 한다! 아키텍트는 결제(T1)를 할 때 DB 상태 값을 결제_완료로 때리면 절대 안 된다. 반드시 **처리_중 (PENDING)**이라는 시맨틱 락 상태를 박아둬야 한다. 그리고 환불 서버 쪽에 "상태가 PENDING인 놈이 환불 요청하면 403 뱉어!"라고 하드코딩 룰을 짜둬야 한다. 사가가 완전히 종료되어 COMPLETED로 간판이 바뀐 뒤에야 다른 로직들이 데이터를 건드릴 수 있도록, 개발자가 코드 레벨에서 멱살을 잡는 땀내 나는 방어술이다.

2. 시나리오 — 꼬여버린 무정부 상태: 코레오그래피(Choreography)의 스파게티 지옥: 스타트업에서 트렌디하게 코레오그래피 사가(대빵 없이 각자 알아서 Kafka로 핑퐁 치는 구조)를 도입했다. 1년 뒤, 서비스가 10개로 늘어났다. 유저가 회원가입을 했는데 환영 쿠폰이 안 들어왔다. 버그를 잡으려는데 미쳐버릴 노릇이다. 가입 앱 ➡ 이벤트 ➡ 포인트 앱 ➡ 이벤트 ➡ 알림 앱 ➡ 이벤트 ➡ 쿠폰 앱... 메시지가 핑퐁을 10번 치는데, 전체 거대한 흐름(비즈니스 룰)을 한눈에 볼 수 있는 소스코드가 지구상 어디에도 없다! 개발자 5명이 각자 지들 파트 로그만 뒤지다 "내 쪽은 정상인데?"라며 1달 내내 버그를 못 잡았다.

   • 아키텍트의 해결책: 서비스 개수가 임계점을 넘은 순간, 오케스트레이터(Orchestrator) 사가 체제로의 중앙 집권화 전환이다. 도메인이 4~5개를 넘어가면 릴레이(핑퐁) 방식은 무조건 추적 불가 지옥에 빠진다. 아키텍트는 중간에 'Order Saga 중앙 관제탑 서버(대빵)'를 하나 파야 한다. 이 대빵이 혼자서 "1번 찔러! 2번 찔러! 어 에러 났어? 그럼 1번 다시 뒤로 롤백시켜!"라고 모든 통제 코드를 독점하게 만든다. 개발자는 버그 나면 이 대빵 코드 딱 1곳만 뒤지면 흐름이 1초 만에 파악되는, 엔터프라이즈의 거대한 관리 통제권(552장 연계)을 수복해 낸다.

도입 체크리스트

• 비즈니스적: "보상 트랜잭션의 구현 비용이, 락(Lock)을 안 걸어서 얻는 트래픽 수익을 이기는가?" 무서운 진실이 있다. 사가 패턴을 도입하면 개발 일정이 최소 2배 이상 늘어난다. "돈 빼기" API 하나 짜기도 벅찬데, "돈 돌려주기(환불/보상)" API를 한 세트로 일일이 생코딩해서 다 짜붙여야 한다. 만약 회사 MAU가 10만 명도 안 되는 조촐한 서비스라면? 괜히 사가 패턴 한다고 오버엔지니어링(Over-engineering) 치다가 개발팀 공중분해 된다. 그냥 DB 1통에 합쳐서 로컬 트랜잭션 롤백 꿀 빨면서 돈 버는 게 최고다. 넷플릭스나 쿠팡급 메가 트래픽 병목이 터질 때만 이 사가 지옥문을 여는 게 아키텍트의 양심이다.
• 기술적: 아웃박스 패턴(Outbox Pattern)이 장착되어 있는가? 결제 서버가 자기 DB에 Commit 치고 ➡ Kafka에 메시지 던진다! 이 두 짓거리 사이에 0.001초 텀이 있다. DB에 Commit 박았는데 0.001초 뒤에 서버 랜선이 뽑혔다? Kafka에 이벤트가 영원히 안 날아가서 배송 서버는 평생 배송을 안 해준다! (이중 쓰기 문제, Dual Write Problem). 아키텍트는 반드시 자기 DB 안에 Outbox (임시 보관함) 테이블을 파서 비즈니스 데이터와 메시지를 1개의 로컬 트랜잭션으로 동시에 쾅 박아두고, 외부 데브옵스 봇(Debezium/CDC)이 그걸 안전하게 퍼가도록 방파제를 융합해 둬야 유실 0% 사가가 굴러간다.

안티패턴

• "보상 트랜잭션(환불) 로직을 대충 대충 짜기": 초보 주니어가 제일 많이 하는 짓이다. "결제(+100원)" 짜는 건 재밌으니까 TDD 해가며 짰다. "환불(-100원, 보상)" 짜는 건 귀찮으니까 그냥 UPDATE balance = balance - 100 1줄 대충 쳐놓고 퇴근했다. 1달 뒤 시스템 에러가 터져 환불 큐가 미친 듯이 3번 재전송(Retry) 돌았더니, 고객 잔고가 -300원이 깎이는 대재앙이 터졌다. "명심해라. 정상 트랜잭션보다 100배 더 무겁고 보수적으로(멱등성, 재시도, 예외 알람) 짜야 하는 것이 보상 트랜잭션이다. 보상 코드가 뻗는 순간, 당신의 데이터베이스는 영원히 수습 불가능한 핵폐기물이 된다."

• 📢 섹션 요약 비유: 사가 패턴에서 아웃박스(Outbox) 없이 카프카를 쏘는 짓은 **'내가 일기장에 "친구한테 욕했다"고 쓴 뒤(DB 저장), 친구한테 진짜 욕하러(Kafka 메시지) 가는 길에 교통사고로 기절하는 것'**과 같습니다. 일기장에는 욕했다고 적혀있는데 현실 친구는 욕을 들은 적이 없는 미친 미스매치입니다. 아웃박스 패턴은 '내가 일기장에 욕 썼다는 사실을 내 비서(CDC 데몬)가 몰래 읽고 있다가, 내가 기절해도 비서가 대신 친구한테 찾아가 멱살 잡고 욕을 전달해 주는(메시지 100% 보장)' 완벽한 보완재입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• Eventual Consistency(결과적 정합성)의 극한 타협 시대: 과거엔 은행에서 Saga를 쓰면 "잠깐 돈 안 맞는 게 말이 돼!"라며 거품을 물었다. 하지만 토스(Toss), 카카오페이 등 현대 핀테크가 MSA를 위해 과감히 Saga를 도입하고, 0.1초의 데이터 불일치를 "고객에게 애니메이션 로딩창을 3초 띄워서 시각적으로 속이는(UX 융합)" 천재적 꼼수들로 커버하기 시작했다. 아키텍처의 구멍을 프론트엔드 UX와 비즈니스 타협(포인트 더 줄 테니 롤백 기다려)으로 메우는 기상천외한 융합 설계가 차세대 엔터프라이즈의 표준으로 정착하고 있다.
• Workflow / Micro-Tx 프레임워크의 천하통일: 사가 짜다가 다 퇴사하는 비극을 멈추기 위해 거대 프레임워크가 코드를 삼켜먹고 있다. AWS Step Functions나 Temporal 같은 놈들이다. 이젠 개발자가 직접 Kafka 쏘고 줏어먹는 거 안 짠다. 그냥 파이썬 코드로 결제(), 배송(), 쿠폰() 함수 3개만 짜서 Temporal 엔진에 던져주면, 인프라가 알아서 트래픽 핑퐁 쳐주고, 뻗으면 멱살 잡고 멱등성 재시도 1만 번 돌려주고, 터지면 환불 함수 강제 역주행 호출까지 다 해주는 '무뇌 인프라 기반 자율 주행 트랜잭션' 시대가 MSA의 넥스트 스텝으로 군림할 것이다.

참고 표준

• Saga Pattern 논문 (1987, Hector Garcia-Molina): 무려 30년 전에 "데이터베이스 락(Lock) 걸면 뻗으니까, 그냥 쪼개서 넣고 에러 나면 보상(Compensation) 쳐라!"라고 시대를 앞서간 외계인들의 대서사시 논문. 클라우드 시대가 도래하며 예언서로 추앙받게 됨.
• CAP 정리 (Availability vs Consistency): 사가 패턴이 존재하는 철학적 이유. 사가 패턴은 파티션(네트워크 끊어짐, P) 상황에서, 완벽한 일치(C)를 포기하는 대신 시스템이 멈추지 않는 미친 가용성(A)을 택한 인류 최고의 트레이드오프 승부수다.

사가 패턴 (Saga Pattern)은 소프트웨어 공학이 '절대 틀리지 않는 무결점의 신(God)'이 되기를 쿨하게 포기하고, '넘어지더라도 재빠르게 상처에 연고를 바르고 다시 뛰는 터프한 야생마(Resilience)'로 태도 전환을 이뤄낸 가장 아름다운 백기 투항이다. 2PC로 100만 명의 트래픽을 거대한 자물쇠(Lock)로 틀어막던 낡은 시대의 허세는, 결국 연쇄 셧다운이라는 참혹한 핏빛 로그 창을 남기고 죽었다. 클라우드 시대의 아키텍트는 데이터베이스의 멱살을 잡지 않는다. 그들은 데이터를 바람(이벤트)에 흩날려 보낸다. 1만 원이 결제 DB에 쾅 박히자마자 락(Lock)을 미련 없이 풀어버리고, 카프카(Kafka)라는 거대한 허공에 "나 돈 뺐다!"라는 깃발 하나를 툭 던져두고 쿨하게 돌아서는 배짱. 만약 저 끝 배송 DB에서 치명적 버그가 터진다면, 깃발은 역풍을 타고 돌아와 아키텍트가 정성스레 손으로 짜둔 '환불(-1만 원)'이라는 논리적 붕대(보상)를 감아 시스템의 숨통을 다시 원상 복구시킨다. 찰나의 순간(1초) 데이터는 춤을 추듯 어긋나 보이지만, 거대한 릴레이 체인이 끝나는 순간 결국 하나로 수렴(Eventual)하는 이 눈부신 비동기의 곡예, 그것이 1조 원의 비즈니스를 단 1초도 멈추지 않게 굴려내는 현대 분산 아키텍처의 살아있는 심장이다.

• 📢 섹션 요약 비유: 사가 패턴은 **'위험한 빙벽을 오르는 5명의 등반가(로컬 DB들)'**와 같습니다. 옛날(2PC)엔 5명이 하나의 밧줄(Lock)로 허리를 묶고 올랐습니다. 한 명이 미끄러지면 다 같이 절벽 아래로 롤백(전멸)했죠. 사가 패턴은 밧줄을 싹둑 끊어버린 채 **'각자 자기 피켈(도끼)로 얼음을 찍으며 릴레이로 올라가는 고수들'**입니다. 3번째 놈이 발을 헛디뎌 추락해도(에러), 1, 2번째 놈은 자기가 찍어둔 위치(Commit)에서 튼튼하게 버팁니다. 그리고 천천히 아래로 안전하게 레펠을 타고 내려와(보상 트랜잭션, 환불) 다친 3번 놈을 수습하여 베이스캠프로 평화롭게 돌아가는 완벽한 각개전투 생존술입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 친구 3명이 **'릴레이 만화 그리기(Saga 패턴)'**를 했어요. 1번 친구가 토끼를 그리고(저장 쾅!) 스케치북을 2번한테 던져줬어요(락킹 없음, 짱 빠름!).
2. 그런데 3번 친구 차례에 실수로 만화에 커피를 엎질렀어요(에러 폭발!). 만약 옛날(2PC) 같았으면 토끼 그린 것도 다 찢어버리고 엉엉 울었을 거예요(롤백).
3. 하지만 우리는 똑똑해서 지우개와 화이트(보상 트랜잭션)를 써서, 커피 묻은 곳만 예쁘게 덮어서 구름 모양으로 고쳐 그리고(환불/수습) 만화를 무사히 완성하는 짱 유연한 이어달리기 수습 방법을 **'사가 패턴'**이라고 부른답니다!