1. 문제 상황
나: 커튼 결제 전 주문 취소
백화점: 네!
그런데 커튼이 배송됨
이 상황은 여러 부서나 서비스가 나뉘어 있을 때 발생할 수 있는 문제이다.
예를 들어 주문 시스템이 다음처럼 나뉘어 있다고 하자.
- 주문 생성
- 결제
- 재고 확보
- 배송 생성
하나의 긴 트랜잭션으로 처리하면 전체 흐름을 한 번에 관리할 수 있지만,
SoA나 마이크로서비스 환경에서는 각 기능이 독립된 서비스로 나뉘어 있다.
따라서 긴 트랜잭션을 하나로 묶기 어렵고,
각 작업을 짧은 트랜잭션으로 나누어 독립적으로 수행해야 한다.
2. Saga Pattern (서사 패턴)
Saga Pattern은 긴 트랜잭션을 여러 개의 짧은 트랜잭션으로 나누어 처리하는 방식이다.
각 서비스는 자기 역할에 해당하는 로컬 트랜잭션을 수행하고,
중간에 실패가 발생하면 이전에 성공한 작업을 되돌리는 compensation, 즉 보상 작업을 수행한다.
예시:
- 주문 생성
- 결제
- 재고 확보
- 배송 생성
이를 실제 부서로 나누면 다음과 같다.
- 주문 생성: 고객 주문 접수 부서
- 결제: 총무부서
- 재고 확보: 재고관리팀
- 배송 생성: 물류팀
이때 결제와 재고 확보는 서로 독립적이므로 병렬로 처리될 수 있다.
주문 생성
→ 결제 처리 || 재고 확보
→ 배송 생성
전체 작업 순서는 Automated Planning을 통해 자동으로 구성할 수 있다.
여기서 ||는 병렬 처리를 의미한다.
병렬적으로 상호작용할 때, 그 흐름이 올바른지는 PI-Calculus 같은 기법으로 검증할 수 있다.
3. 실패 상황과 Compensation
예를 들어 다음과 같은 상황이 발생할 수 있다.
- 주문 생성 성공
- 결제 성공
- 재고 확보 실패
- 배송 생성 불가
이 경우 결제는 이미 성공했지만, 재고 확보에 실패했기 때문에 배송을 진행할 수 없다.
따라서 성공했던 결제를 다시 취소해야 한다.
재고 확보 실패
→ 결제 rollback
→ compensate 수행
여기서 compensation은 이미 실행된 작업을 되돌리기 위한 보상 트랜잭션이다.
| 기존 작업 | Compensation |
|---|---|
| 주문 생성 | 주문 취소 |
| 결제 완료 | 결제 취소 / 환불 |
| 재고 차감 | 재고 복구 |
| 배송 생성 | 배송 취소 |
4. Compensation의 리스크
Saga Pattern은 실패 상황을 처리할 수 있지만,
compensation의 비용이 클 수 있다는 리스크가 있다.
예를 들어 커튼 주문을 취소했는데 이미 배송이 시작되었다면,
단순히 데이터만 되돌리는 것이 아니라 실제 물류 처리까지 되돌려야 한다.
즉, compensation은 항상 쉬운 작업이 아니다.
이미 배송된 상품을 회수해야 할 수도 있고,
환불 처리, 고객 응대, 물류 비용 등이 추가로 발생할 수 있다.
그래서 Saga Pattern에서는 단순히 실패 후 되돌리는 것만 중요한 것이 아니라,
애초에 잘못된 다음 단계가 실행되지 않도록 제약 조건을 두는 것도 중요하다.
5. Constraint의 필요성
커튼 예시에서 문제는 다음과 같다.
결제 완료가 확정되기 전에 주문만으로 배송 프로세스가 시작됨
이를 방지하려면 다음과 같은 제약이 필요하다.
결제 완료 확인이 전달되었을 때만 물류팀에서 배송 프로세스를 시작한다.
즉, 배송 생성은 아무 때나 실행되면 안 되고,
반드시 결제 완료 및 최종 확인이라는 조건을 만족해야 한다.
- 커튼을 장바구니에 넣음
- 결제 완료 및 최종 확인
- 결제 완료 확인이 전달됨
- 그때만 물류팀에서 배송 프로세스 시작
이처럼 Saga Pattern에서는 각 작업이 실행되기 위한 constraint, 즉 제약 조건을 명확히 해야 한다.
배송을 빠르게 시작하는 것도 중요하지만, 잘못 배송된 상품을 반품받는 비용이 더 클 수 있다.
6. Choreography와 Orchestration
Saga Pattern을 구현하는 방식에는 크게 두 가지가 있다.
Choreography
Choreography는 중앙 조정자 없이 각 서비스가 이벤트를 보고 알아서 다음 작업을 수행하는 방식이다.
예를 들어 주문 서비스가 주문 생성됨 이벤트를 발행하면,
결제 서비스와 재고 서비스가 그 이벤트를 보고 각자 작업을 수행한다.
특징:
| 항목 | 내용 |
|---|---|
| 중앙 관리자 | 없음 |
| 동작 방식 | 각 서비스가 이벤트에 반응 |
| 장점 | 서비스 간 결합도가 낮음 |
| 단점 | 전체 흐름 파악이 어려움 |
| 위험 | 예상하지 못한 순서로 작업이 진행될 수 있음 |
Orchestration
Orchestration은 중앙 조정자, 즉 Orchestrator가 전체 흐름을 관리하는 방식이다.
Orchestrator가 각 서비스에게 어떤 작업을 언제 수행할지 지시한다.
특징:
| 항목 | 내용 |
|---|---|
| 중앙 관리자 | 있음 |
| 동작 방식 | Orchestrator가 다음 작업 지시 |
| 장점 | 전체 흐름과 책임이 명확함 |
| 단점 | Orchestrator가 복잡해질 수 있음 |
| 위험 | 중앙 조정자에 의존하게 됨 |
7. 예시 1: 재고 소진과 생산량 조정
G₀
HQ orders Dealers to clear out
→ 본사가 딜러들에게 재고를 소진하라고 지시함.
G₁
Marketing team notifies sales update to Factory
→ 마케팅팀이 공장에 판매량 업데이트를 알림.
G₂
Operations manager orders production rate change to Factory
→ 운영 관리자가 공장에 생산 속도/생산량 변경을 지시함.
Gₓ
Dealers to ask Coordinator to pick the next task
→ 딜러들이 Coordinator에게 다음 작업을 선택해달라고 요청함.
이 예시의 핵심은 Gₓ이다.
HQ가 Dealers에게 재고 소진을 지시한 뒤,
그다음에 어떤 작업을 해야 하는지는 여러 선택지가 있을 수 있다.
예를 들어:
- 마케팅팀이 판매량 업데이트를 공장에 알릴 수도 있음
- 운영 관리자가 생산량 조정을 공장에 지시할 수도 있음
이때 딜러가 임의로 다음 작업을 정하는 것이 아니라,
Coordinator가 다음에 수행할 작업을 선택해주는 구조이다.
즉, 여러 서비스나 부서가 연결된 상황에서는
다음 작업을 누가 결정할 것인지가 중요하다.
8. 예시 2: Fraud Warning과 Refund 처리
G₀
Auditing partner sends fraud warnings to Accounting partner
→ 감사 파트너가 회계 파트너에게 부정 거래 경고를 보냄.
Gₓ
Accounting partner orders customer service to issue refund
→ 회계 파트너가 고객 서비스팀에게 환불 처리를 지시함.
G₁
Customer service issues refund to Customer
→ 고객 서비스팀이 고객에게 환불을 진행함.
이 예시에서도 핵심은 Gₓ이다.
단순히 부정 거래 경고가 발생했다고 해서
Customer service가 바로 고객에게 환불을 해서는 안 된다.
중간에서 Accounting partner가 상황을 판단하고,
환불이 필요하다고 결정한 뒤 Customer service에게 지시해야 한다.
만약 이 단계가 생략되면 문제가 생길 수 있다.
- 고객 서비스팀이 어떤 근거로 환불해야 하는지 불명확함
- 환불 승인 책임이 누구에게 있는지 애매함
- 잘못된 환불이나 중복 환불이 발생할 수 있음
따라서 이 그림은 Saga 흐름에서
작업 순서와 책임을 명확하게 조정하는 단계가 필요하다는 것을 보여준다.
9. AI와의 연결
Yann LeCun은 현재의 LLM이 인간 지능에 도달하기 어렵다고 보았다.
그 이유는 LLM이 다음 능력들을 충분히 갖추지 못했기 때문이다.
- Physical world understanding 부족
→ 실제 물리 세계가 어떻게 작동하는지 이해하지 못함. - Persistent memory 부족
→ 장기적으로 정보를 기억하고 누적해서 사용하는 능력이 약함. - Reasoning 부족
→ 엄밀한 의미의 논리적 추론 능력이 약함. - Planning 부족
→ 목표를 위해 여러 단계를 세우고 계층적으로 실행하는 능력이 부족함.
1. Persistent Memory가 없어?
→ 작업을 잘라서 agentic workflow로 처리
→ Saga Pattern과 연결됨
즉, AI가 긴 작업 전체를 한 번에 기억하고 처리하기 어렵다면,
작업을 여러 단계로 나누고 각 단계를 독립적으로 처리하도록 만들 수 있다.
2. Plan을 못해?
→ Automated Planning
AI가 스스로 적절한 실행 계획을 세우지 못한다면,
자동 계획법을 통해 어떤 작업을 어떤 순서로 수행해야 하는지 구조화할 수 있다.
3. Definition이 약해?
→ Neuro-Symbolic AI
AI가 개념이나 조건을 명확하게 정의하지 못한다면,
신경망 기반 AI와 symbolic reasoning을 결합한 Neuro-Symbolic AI가 필요할 수 있다.
12. RLSF와 Constrained Learning
RLSF
AI는 이미지 속 식을 볼 때 정답을 확정적으로 아는 것이 아니라, 각 문자와 기호를 확률적으로 인식한다.
예를 들어 이미지 속 식이 3 + 5라면 AI는 다음처럼 판단할 수 있다.
3일 확률 0.9,8일 확률 0.1+일 확률 0.9,÷일 확률 0.15일 확률 0.95,6일 확률 0.05
그래서 3 + 5라고 판단할 확률은
0.9 × 0.9 × 0.95이고, 잘못해서 8 ÷ 6이라고 판단할 가능성도 있다.
하지만 3 + 5 = 8이라는 것은 연산 프로그램으로 검증할 수 있다.
즉, AI가 추론한 결과를 symbolic system이 검증하고, 그 결과를 다시 AI에게 피드백으로 주는 방식이다.
AI가 식을 인식함
→ 연산 프로그램이 정답인지 검증함
→ 검증 결과를 피드백으로 줌
→ AI가 다시 학습함이것이 RLSF의 핵심이다.
Constrained Learning
Constrained Learning은 단순히
A + B = C가 되도록 학습하는 것이 아니다.
더 중요한 것은 아래 조건을 항상 만족하도록 학습하는 것이다.
| A + B - C | == 0이 조건을 invariant라고 한다.
즉, AI가 단순히 정답을 외우는 것이 아니라,
“더하기의 결과는 항상 조건을 만족해야 한다”는 규칙을 지키도록 학습하는 것이다.
14. 전체 핵심 정리
이 강의의 전체 흐름은 다음과 같다.
SoA나 마이크로서비스 환경에서는 하나의 긴 트랜잭션을 한 번에 처리하기 어렵다.
따라서 긴 트랜잭션을 여러 개의 짧은 트랜잭션으로 나누고,
각 서비스가 독립적으로 작업을 수행하게 한다.
이때 중간에 실패하면 이미 성공한 작업을 되돌리는 compensation이 필요하다.
이 구조가 Saga Pattern이다.
하지만 compensation은 비용이 클 수 있기 때문에,
애초에 잘못된 다음 작업이 실행되지 않도록 constraint를 명확히 해야 한다.
Saga Pattern을 실행하는 방식에는
각 서비스가 이벤트를 보고 알아서 움직이는 Choreography 방식과,
중앙 조정자가 다음 작업을 지시하는 Orchestration 방식이 있다.
복잡한 프로세스에서는 어떤 작업을 어떤 순서로 수행할지 결정해야 하므로
Automated Planning이 필요할 수 있다.
또한 AI 시스템에서는 단순히 정답을 맞히는 것뿐 아니라,
| A + B - C | == 0 같은 제약 조건을 만족하도록 학습하는 것이 중요하다.
이를 위해 신경망 기반 AI와 symbolic reasoning을 결합한
Neuro-Symbolic AI가 활용될 수 있다.
