Road to Web3 (15) 배치 정산 모델: 빠른 UX 오프체인 + 강한 신뢰 온체인의 타협

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

이번 편의 목표는 한 문장입니다.

• 즉시 UX를 주려면 오프체인이 필요하고, 최종 신뢰를 만들려면 온체인 커밋이 필요하다

즉, 문제는 기술이 아니라 의사결정입니다.

• 언제 무엇을 온체인에 커밋할 것인가

제가 처음 이 문제를 접할 때 했던 오해는 이렇습니다.

• 온체인이 느리면 그냥 오프체인으로 처리하면 된다
• 오프체인으로 처리해도 언젠가 다 온체인에 올리면 된다
• 배치 정산은 단순히 트랜잭션을 모아서 보내는 최적화다

현실은 이렇습니다.

• 오프체인은 승인 단계에 가깝고, 온체인은 정산 확정에 가깝다
• 배치 정산은 비용 절감만이 아니라, 신뢰 경계를 설계하는 일이다
• 서비스 안정성은 상태 머신과 리컨실리에이션에서 나온다

web2 결제로 번역하면

• 빠른 UX는 승인
• 강한 신뢰는 정산
• 둘 사이의 갭을 메우는 게 서비스다

---

 

요약

선택	장점	리스크	필요한 운영 장치
즉시 온체인	강한 신뢰, 단순한 회계	느림, 실패 비용, UX 나쁨	가스비 전략, 재시도 정책
즉시 오프체인	빠름, 저렴, 유연	이중지출, 되돌림, 분쟁	상태 머신, 멱등성, 리컨실
오프체인 후 배치 온체인	UX와 신뢰의 절충	배치 지연, 정산 실패, 운영 복잡도	배치 커밋, 증빙, 백필, 알람

---

 

1) 배치 정산 모델이란 무엇인가

배치 정산 모델은 요약하면 이 흐름입니다.

1) 사용자는 빠르게 승인받는다 오프체인
2) 서비스는 제공을 시작한다
3) 일정 주기나 조건에 따라 온체인으로 정산 커밋한다
4) 온체인 결과를 기준으로 최종 회계를 고정한다

 

이 모델은 web2에서 너무 익숙합니다.

• 카드 승인 이후 매입과 정산이 늦게 일어난다
• PG 승인 이후 정산 배치는 따로 돈다

롤업에서도 비슷합니다.

• L2 included가 빠른 UX
• L1 finalized가 강한 정산 확정

배치 정산은 이 둘 사이를 서비스 관점에서 다시 한 번 설계하는 것입니다.

---

 

2) 무엇을 온체인에 커밋할까: 모든 걸 올릴 필요는 없다

온체인 커밋은 비쌉니다. 그래서 커밋 단위를 쪼개는 게 핵심입니다.

대표 선택지 4가지

A. 개별 결제 건마다 온체인 결제

• 가장 단순
• 가장 비쌈
• 실패 비용과 UX 부담이 큼

B. 오프체인 원장만 유지하고, 온체인은 안 올림

• 가장 빠름
• 신뢰가 전부 서비스에 있음
• 외부 검증이 불가능해지고 분쟁 리스크가 커짐

C. 요약 커밋: 일정 구간의 결과만 온체인에 앵커링

• 예: 하루치 매출 총합
• 예: 사용자별 소진 총합
• 예: 머클 루트나 해시 체인

이렇게 하면

• 온체인은 증빙 anchor
• 상세 내역은 오프체인 DB

가 됩니다.

D. 정산 커밋: 실제 자금 이동을 온체인으로 처리

• 최종 신뢰를 온체인으로 고정
• 배치 주기와 실패 처리가 운영 포인트

---

 

3) 서비스가 안정적으로 돌아가는 조건: 상태 머신이 전부다

배치 정산 모델에서 진짜 어려운 지점은

• 승인 상태와 정산 상태가 다르다

입니다.

그래서 서비스는 거래 단위를 상태 머신으로 다룹니다.

권장 상태

• authorized: 오프체인 승인됨
• provided: 서비스 제공 시작됨
• queued_for_settlement: 배치 정산 대기
• settling: 온체인 커밋 진행
• settled: 온체인 정산 성공
• reversed: 승인 취소 또는 정산 실패로 되돌림
• disputed: 분쟁 처리 중

이 상태 머신이 없으면

• 중복 제공
• 중복 정산
• 환불 누락
• CS 지옥

이 바로 옵니다.

 

web2 공통점

• 승인 단계에서 멱등성 키로 중복 청구를 막는다
• 정산 단계에서 매칭과 리컨실로 누락을 막는다

체인 차이점

• 정산 트랜잭션 실패도 비용이 든다
• 확정 전 되돌림 reorg 가능성까지 고려해야 한다

---

 

4) 언제 온체인 커밋할까: 정책으로 고정해야 한다

배치 커밋 트리거는 보통 3종류입니다.

• 시간 기준: N분마다, 하루 1번
• 규모 기준: 건수 M개, 금액 X 이상
• 리스크 기준: 특정 고객, 특정 상품은 즉시 커밋

여기서 중요한 건

• 정책을 CS와 회계 언어로 고정하는 것

입니다.

e.g.

• 소액은 승인 즉시 제공, 하루 1회 정산
• 고액은 승인 후 즉시 온체인 정산
• 위험 계정은 확정 깊이 k를 더 크게

---

 

5) 실패 시나리오와 대응: 누가 손해를 보나

배치 정산 모델에서 실패는 3군데에서 옵니다.

5.1 오프체인 승인 후 정산 전에 사용자 이탈

• 제공을 이미 했다면 회수는 어렵다
• 그래서 승인 단계에서 신용 정책이 필요하다

web2에서는 신용과 한도, 부정거래 탐지가 이 역할을 합니다.

5.2 온체인 정산 트랜잭션 실패

• 컨트랙트 revert
• 가스 부족
• nonce 충돌
• 네트워크 혼잡

대응

• 정산 전 사전 시뮬레이션
• 멱등성 키와 배치 재시도 정책
• 실패 시 reversed로 상태 전환하고 보상 정책을 실행

5.3 확정 전 되돌림

• 확정 깊이를 두지 않고 settled처럼 처리하면 위험하다

대응

• settled과 finalized를 분리한다
• 회계 확정은 더 보수적인 기준으로 잡는다

---

 

6) 체크리스트

1) 승인과 정산을 같은 의미로 쓰지 않는다
2) 거래 단위 상태 머신을 반드시 둔다
3) 멱등성 키로 승인과 제공 중복을 막는다
4) 정산 배치도 멱등하게 만든다
5) 오프체인 원장은 커서와 리컨실로 관리한다
6) 온체인 커밋은 요약 또는 정산 중 무엇인지 정의한다
7) 확정 깊이 정책을 레이어별로 분리한다 L2와 L1
8) 고액과 위험군은 즉시 커밋으로 전환한다
9) 정산 실패 비용을 운영 비용으로 계산한다
10) 시뮬레이션으로 실패를 사전에 줄인다
11) CS 문구는 승인과 정산 용어로 분리한다
12) 회계 기준 시점은 더 보수적으로 잡는다
13) 배치 커밋 지연은 대시보드로 공개한다 내부적으로
14) 분쟁 상태를 따로 두고 프로세스를 분리한다
15) 로그와 증빙을 남겨 사후 감사가 가능해야 한다
16) 백필 잡으로 누락을 복구할 수 있어야 한다
17) 리컨실 결과 불일치율을 지표로 본다
18) 제품은 결국 리스크와 UX의 타협이라는 걸 문서화한다

---

 

결론

• 배치 정산은 단순 최적화가 아니라 신뢰 경계 설계다
• 빠른 UX는 오프체인 승인, 강한 신뢰는 온체인 정산 확정이다
• 안정성은 상태 머신, 멱등성, 리컨실리에이션에서 나온다