분리 트랜잭션 + 보상이란

이해하고 나면 “아 그래서 레이어를 깨는구나”가 연결되는 핵심 개념이다.
차근차근, 실무 기준으로 풀어보자.

---

0️⃣ 한 줄 번역부터

분리 트랜잭션 + 보상이란
👉 “한 번에 다 성공시키지 말고,
👉 단계별로 확정하고,
👉 나중에 문제 생기면 되돌리는 방식”이다.

전통적인 트랜잭션 사고부터 깨야 이해된다.

---

1️⃣ 기존 방식: 강결합 트랜잭션 (한 방에 몰아넣기)

전통적 사고

주문 생성
→ 결제 승인
→ 재고 차감
→ 배송 등록
→ 커밋
(중간 하나라도 실패하면 전부 롤백)

이건 DB 하나, 시스템 하나일 때는 훌륭하다.

그런데 문제는?

• 결제는 외부 PG
• 재고는 WMS
• 배송은 외부 택배사
• 정산은 배치

👉 하나의 DB 트랜잭션으로 묶을 수가 없다.

그래서 현실에서는 이런 일이 터진다.

• 결제는 됐는데 재고 실패
• 재고는 빠졌는데 배송 실패
• 롤백하려고 했더니 이미 외부 시스템 반영됨

---

2️⃣ 그래서 등장한 개념: 트랜잭션을 “쪼갠다”

분리 트랜잭션의 핵심

• 각 단계는 독립적으로 커밋
• 앞 단계가 성공하면 “확정”으로 간주
• 뒤 단계 실패 시 이전 단계 취소는 보상으로 처리

즉:

 

[주문 생성]      COMMIT
[결제 승인]      COMMIT
[재고 차감]      COMMIT
[배송 등록]      실패 ❌
→ 배송 취소 보상
→ 재고 복구 보상
→ 결제 취소 보상

여기서 중요한 포인트:

❌ DB ROLLBACK 아님
⭕ 의미적 되돌림(보상)

---

3️⃣ “보상”이란 정확히 뭐냐

보상은 이렇게 생각하면 된다.

• 시간을 되돌리는 게 아니라
• 반대 행위를 한 번 더 하는 것

예시

• 재고 차감 → 재고 증가
• 결제 승인 → 결제 취소
• 포인트 적립 → 포인트 차감

즉,

보상 = 반대 방향의 비즈니스 이벤트

그래서 보상은:

• 즉시 안 될 수도 있고
• 실패할 수도 있고
• 재시도가 필요하다

이게 핵심이다.

---

4️⃣ 왜 “단계별 커밋”이 필수인가

대규모 시스템에서는 이 전제가 무너진다.

❌ “전부 성공해야 커밋”
⭕ “여기까지는 진실로 인정”

예를 들면:

• 결제 승인 = 법적/금전적 사실
• 이건 되돌릴 수 없는 경계

그래서 AA는 이렇게 판단한다.

• “결제 승인 이후는 롤백 불가”
• “실패는 보상으로 처리”

이 판단이 없으면:

• 개발자는 계속 롤백을 꿈꾸고
• 운영은 수작업으로 복구한다

---

5️⃣ 왜 이게 “대규모 시스템 필수”냐

소규모 시스템

• DB 하나
• 서버 하나
• 사용자 적음

→ 강결합 트랜잭션 OK

---

대규모 시스템

• 서비스 분리
• 외부 시스템 다수
• 비동기 처리 필수
• 장애는 “언젠가는 반드시 발생”

여기서는 이 전제가 성립한다.

실패는 예외가 아니라 정상 흐름

그래서:

• 실패를 전제로 설계해야 하고
• 롤백이 아니라 **회복(resilience)**이 필요하다

분리 트랜잭션 + 보상은
실패를 시스템의 정상 상태로 끌어들이는 설계다.

---

6️⃣ 그림으로 보면 이렇게 된다

이 구조를 실무에서는 보통 이렇게 부른다.

• Saga 패턴
• 보상 트랜잭션
• Eventually Consistent 시스템

---

7️⃣ AA가 이걸 문서로 고정하는 이유

AA가 반드시 적어야 하는 문장들은 이거다.

• 어디까지 커밋인가
• 어디부터는 롤백 불가인가
• 실패 시 보상 주체는 누구인가
• 재시도는 누가 책임지는가
• 중복 실행 시 안전한가(idempotent)

이게 없으면:

• 개발자는 “롤백될 줄 알고” 짜고
• 운영은 “이미 반영됐는데요?”를 말한다

---

8️⃣ 한 문장으로 정리

분리 트랜잭션 + 보상이란
“현실은 되돌릴 수 없다는 사실을
설계에 반영한 트랜잭션 전략”이다.

이걸 이해하면 바로 다음 질문이 자연스럽게 나온다.

👉 “그럼 이 흐름에서 레이어드는 어디까지 유지해야 하나?”
👉 “보상 로직은 Service에 두나, Domain에 두나?”

이 지점부터가
AA ↔ Clean ↔ DDD가 실제로 맞물리는 구간이다.