발표자: 토스코어 개발팀 김학현님 / 주제: 분산 환경에서의 트랜잭션 불일치 문제 해결을 위한 트리 기반 설계 모델
1. 발표 의도 및 구성
- 기존의 투 페이즈 커밋(2PC)이나 사과 패턴(SAGA)처럼 널리 알려진 접근법이 아닌, 새로운 개론 수준의 트랜잭션 관리 접근을 제안하는 것이 목적이다.
- ‘개론’이라는 명칭은 완성된 해결책이 아닌 새로운 개념과 방향을 제시하고자 하는 의도를 담고 있으며, 청중이 처음 접할 수 있는 관점을 쉽게 풀어내기 위해 선택됨.
- 구현 세부보다는 아이디어와 구조 중심으로 설명
2. 문제 인식: 분산 트랜잭션의 불일치와 상태 정의의 복잡성
- 단순한 API 두 번 호출 수준의 트랜잭션도, 실제 환경에서는 성공, 실패, 알 수 없음(Unknown) 세 가지 상태를 반드시 고려해야 함.
- 예외 상황은 실무에서 매일 발생하고, 예를 들어:
- 은행 점검
- 지원 서비스 장애
- 불안정한 네트워크 환경
등으로 인해 짧게는 수 분, 길게는 수 시간 동안 상태 확인이 불가능한 경우가 발생함.
- 트랜잭션이 1개만 추가되어도 가능한 경우의 수가 기하급수적으로 늘어난다.
- 이처럼 분산 환경에서는 즉시 일관성을 보장할 수 없으며, 3가지가 필요하다고 판단함.
- 복잡한 상황을 나타낼 수 있는 표현 모델
- 일관성을 보장할 방법
- 일관성을 보장하는 시점
3. 해결 전략: 트리 기반 상태 표현 모델
3.1 트리 구조의 도입
- 태스크(Task)를 서브 테스크와 하위 트랜잭션으로 구성된 계층적 트리 구조로 모델링.
- 이 구조를 통해 다음이 가능해짐:
- 각 단계의 명확한 상태 표현
- 독립적/복합적 결제 수단의 유연한 모델링
- 확장성 (새 수단, 새 절차 추가)
3.2 상태 정의와 리졸브
- 리프 노드에는 트랜잭션 결과(API 응답 결과)가 위치.
- 각 노드의 상태는 직계 하위 노드의 상태만으로 정의됨.
- 이 상향식 상태 집계 과정을 **리졸브(resolve)**라 명명.
- 트리 크기나 복잡도와 무관하게 2단계 하위 노드만 고려하면 되므로 계산 복잡도를 낮춤.
3.3 상태 불일치
- 만약 토스머니 사용의 상태가 성공으로 판명되었다면 토스머니는 성공 상태로 resolve 된다.
- 결제 승인 노드입장에서는 하위노드의 상태가 일치하지 않으므로 여전히 알 수 없는 상태.
- resolve는 현재 상태를 규명만 하고 근본적 불일치 해결이 어렵다. 그래서 불일치 해결 방법이 필요하다.
4. 상태 불일치의 해결: 보정(Correction)
4.1 보정 전략
- 리졸브는 단순한 상태 판별일 뿐이며, 상태 불일치는 그대로 존재할 수 있음.
- 이를 해결하기 위해 보정이 필요하며, 보정에는 다음 두 가지 방향이 존재:
- 성공으로 보정 – 실패한 트랜잭션 재시도
- 실패로 보정 – 성공한 트랜잭션을 롤백
- 성공으로 보정 – 실패한 트랜잭션 재시도
4.2 보정 주체와 정책 위임
- 보정을 위해서는 성공,또는 실패등 보정 방향을 결정하고 실행할 주체가 필요하다.
- 보정 방향과 실행은 각 노드가 자체적으로 판단하도록 설계.
- 재시도 + 보상이라는 이중 보정 전략을 가짐.
5. 최종적 일관성 보장을 위한 운영 설계
- API 응답 타이밍 내에서 완전한 일관성 확보는 불가능
- 그래서 분산환경에서는 최종적 일관성을 보장하는 것이 필연적.
- 이 시스템은 설계 레벨에서 자동으로 정합성을 회복할 수 있도록 구성됨.
- 사람이 개입하여 조정하는 기존 방식과 달리, 자동화된 리졸브 + 보정 로직이 배치로 실행되어 운영 효율성 확보.
6. 실제 구현
6.1 테이블 설계
- 트리 구조는 실제 DB 테이블로 구현.
- 각 트리 레벨마다 개별 테이블 구성.
- 이는 각 레벨의 관심사, 추상화 수준이 다르기 때문.
6.2 실행 주기
- 분 단위 배치로 정기적인 리졸브 및 보정 수행.
- 이후 특정 사건을 계기로, 트랜잭션 처리 시점(API 요청 응답 중)에도 최소한의 보상 트랜잭션을 함께 수행하도록 개선.
7. 정책 설계 기준
보정 정책은 다음 세 가지 기준을 기반으로 함:
- 심리적 가치 차이
- 사용자가 현금 등 실질 가치 있는 수단에 민감하게 반응함.
- 포인트/할인 실패보다 현금 환급 실패가 훨씬 큰 불만을 초래.
- 보상 트랜잭션의 난이도
- 계좌로 돈을 입금하는 것이 출금하는 것보다 훨씬 쉬움.
- 예: 환불보다 결제 차단이 더 어렵다.
- 내부 vs 외부 재화의 다룸 정도
- 토스 포인트/할인(내부)보다 외부 계좌(토스머니 등)가 더 복잡하고 리스크 큼.
정책의 응용
- 결제 수단마다 승인/환불 순서를 지정하거나, 필수 성공 대상 지정 가능.
- 언론 상태의 전파 범위도 제어 가능 (정책 위임).
8. 트랜잭션의 상대성
- 트랜잭션은 절대적인 물리적 단위가 아닌, 추상화 레벨에 따라 상대적으로 정의되는 논리 단위임.
예시:
관점트랜잭션 단위
| 결제 승인 | 할인, 포인트, 머니 |
| 토스 머니 | 충전, 사용 |
| 토스 머니 서버 | 더 하위 단계 |
| 사용자 | 주문 전체 (상품+결제+배송) |
- 서비스 간 관계는 자연스럽게 트리 구조를 이루고 있으며, 설계자가 명시하지 않더라도 모든 시스템은 거대한 트리의 일부로 동작하고 있었음을 역설적으로 설명함.
9. 결론
- 트랜잭션의 불일치는 분산 환경에서 불가피하며, 이를 해결하기 위해 트리 구조, 리졸브, 보정, 최종적 일관성의 조합이 필요함.
- 각 노드에 책임을 위임하고, 운영단에서 자동 정합성을 유지하도록 설계함으로써 사람 개입 없는 복구 가능 구조를 실현.
- 트랜잭션의 본질을 상대적이고 계층적인 개념으로 재정의함으로써 보다 유연하고 확장 가능한 시스템 설계가 가능함.