Road to Web3 (5) 온체인 vs 오프체인: 임의 처리가 아니라 합의 경계

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.
이 글에서 온체인, 오프체인은 기술 스택이 아니라 합의가 보장하는 경계로 정의합니다.

 

 

 

제가 처음 온/오프 체인을 접했을 때 인상은 다음과 같았습니다.

• 오프체인 = 서비스가 마음대로 처리하는 것
• 온체인 = 블록체인에 올리기만 하면 끝

하지만 둘 다 절반만 맞습니다.

서비스는 마음대로 처리할 수 있지만, 그 순간 신뢰는 내가 책임져야 합니다.
그래서 핵심은 기술이 아니라 경계입니다.

온체인과 오프체인의 차이는 저장 위치가 아니라, 합의가 보장하는 책임 범위다

---

 

요약

구분	한 줄 정의	누가 보장하나	실패했을 때
온체인	합의된 상태 전이를 체인에 기록	네트워크 합의 + 검증	되돌리기 어렵고 모두가 같은 결과를 본다
오프체인	합의 밖에서 상태를 관리	서비스 운영자 + 인프라	오류, 부정, 누락은 서비스가 책임진다
하이브리드	온체인은 최종 원장, 오프체인은 UX	둘 다	정산 시점에 불일치가 드러날 수 있다

---

 

1) 정의부터 고정하자: 온체인, 오프체인은 합의 경계다

온체인 on chain

다음 조건을 만족하면 온체인입니다.

• 트랜잭션이 블록에 포함되고
• 합의 규칙으로 정답 체인에 남고
• 모든 노드가 같은 규칙으로 재실행해 같은 상태를 갖게 된다

온체인은 결과가 느릴 수 있지만 강합니다.

• 제3자가 검증 가능
• 규칙이 코드로 고정
• 정산과 분쟁 해결에 유리

오프체인 off chain

오프체인은 반대로, 합의 밖에서 발생한 상태 변화입니다.

• DB 업데이트
• 캐시 업데이트
• 큐 처리
• 배치 정산
• 내부 원장 ledger

오프체인은 빠르지만 책임이 커집니다.

• 내가 틀리면 내가 손해다
• 부정과 장애 모델을 내가 설계해야 한다

---

 

2) 오프체인은 임의 처리가 아니라 설계된 신뢰 모델이다

오프체인이 임의 처리처럼 느껴지는 이유는 이겁니다.

• 합의가 없으니 누구도 강제로 지켜주지 않는다
• 그래서 운영자가 마음대로 바꾸는 것도 가능하다

하지만 제대로 만든 오프체인은 임의가 아니라 규칙과 증거가 있습니다.

• 상태 머신으로 흐름을 고정한다
• idempotency 로 중복을 막는다
• 감사 로그 audit log 로 추적한다
• 필요하면 온체인 증거로 커밋한다

즉,

• 오프체인 = 임의 처리
  가 아니라
• 오프체인 = 내가 합의 대신 책임지는 영역

---

 

3) 무엇을 온체인에 맡기고, 무엇을 서비스가 책임질까

여기서부터는 의사결정 프레임입니다.
다음 질문으로 분리하면 결정이 쉬워집니다.

질문 1. 이 행위는 되돌리기 어려운 가치 제공인가

• 크레딧 지급, 출금 승인, 재고 확정, 티켓 발권
  → 온체인 확정 또는 강한 확정 정책이 유리

질문 2. 이 행위는 빈번하고 지연에 민감한가

• 클릭, 조회, 추천, 실시간 UX
  → 오프체인이 유리

질문 3. 제3자 검증이 필요한가

• 분쟁 가능, 파트너 정산, 공개 투명성
  → 온체인이 유리

질문 4. 실패했을 때 누구의 돈이 나가나

• 사용자 돈이 나가면 더 보수적
• 서비스 돈이 나가면 정책으로 완충 가능

 

---

 

4) 하이브리드가 기본값이다: 빠른 UX + 강한 신뢰

현실의 web3 서비스는 보통 하이브리드입니다.

• 오프체인으로 빠르게 처리하고
• 온체인으로 최종 원장을 남긴다

결제 비유로 말하면

• 승인 authorization 은 빠르게
• 매입 capture 또는 정산 settlement 은 더 강하게

이때 중요한 것은 정산 모델입니다.

• 언제 온체인에 커밋할 것인가
• 커밋하는 단위는 무엇인가
• 불일치가 발생했을 때 어떤 원장을 정답으로 볼 것인가

---

 

5) 오프체인을 쓴다면 온체인에 나중에 올려야 할까?

항상은 아닙니다. 여기서도 경계가 핵심입니다.

케이스 A 온체인이 최종 진실인 경우

• 오프체인은 캐시, 인덱스, UI 상태
  → 온체인이 정답이고, 오프체인은 따라간다
  → 나중에 올린다는 개념이 아니다, 따라잡는 개념이다

케이스 B 오프체인이 먼저 진실인 경우

• 빠른 UX 를 위해 오프체인에서 먼저 확정처럼 보이게 한다
• 나중에 온체인으로 정산한다
  → 이때는 언젠가 온체인에 올려야 신뢰가 완성된다
  → 대신 실패 시 보상, 롤백, 재시도 정책이 필요하다

이 글에서 말하는 배치 정산 모델은 보통 케이스 B 입니다.

---

 

5-1) 오프체인으로 먼저 처리했다가 나중에 뒤집히면 어떻게 될까?

이 질문은 사실 결제 시스템에선 꽤 익숙한 패턴입니다.

• 카드 결제: 승인 authorization 은 빠르게, 매입 capture/정산 settlement 은 나중에
• 오프체인 선처리: 프로비저널 provisional 로 먼저 반영, 온체인 확정으로 나중에 정산

여기서 오프체인 선처리를 한다는 건 한 문장으로 말하면 이겁니다.

온체인 확정 전에, 회사가 사용자에게 신용 또는 서비스를 먼저 제공하는 모델이다

 

그래서 뒤집힘이 발생하면, 그건 기술 이슈가 아니라 리스크가 현실화된 것입니다.

 

케이스

케이스	체인 상태	의미	회사 관점
아직 확정이 덜 됨	included 는 됐고 confirm/finality 대기	시간 문제일 가능성	트래킹 계속
아예 못 받음	미포함 dropped/replaced 또는 reorg 로 사라짐	정산 실패	원복/회수/손실 처리

1) 사용자는 금액을 지불하나

• 온체인에 성공적으로 반영되지 않았다면, 체인 기준으로는 지불이 아닙니다.
• 따라서 오프체인에서 이미 혜택을 줬다면, 회사는 돈을 못 받았는데 뭔가를 제공한 상태가 될 수 있습니다.

1-1) 회사는 환불해줘야 할까

여기서 환불이라는 단어는 상황에 따라 의미가 달라집니다.

• 온체인에서 실제로 돈을 받은 적이 없다면
  → 엄밀히는 환불이 아니라 오프체인 원복 또는 제공 혜택 회수입니다.
• 온체인에서 돈을 실제로 받았다면
  → 진짜 환불은 보통 온체인 환불 트랜잭션이 필요합니다.

1-2) 그럼 회사는 계속 트랙킹해야 할까

네. 오프체인 선처리를 선택한 순간, 백엔드는 결제 시스템처럼 정산 파이프라인이 필요합니다.

• tx hash 를 받았다: receipt 로 포함 확인 → confirmations/finality 까지 추적
• tx hash 가 없다: 결제 시도를 만료 처리하거나 재전송 유도

실무에서는 무한 폴링이 아니라, 상태 머신 + 재검증 스케줄 + 타임아웃으로 운영합니다.

1-3) 환불은 꼭 온체인이어야 할까

• 온체인에서 실제로 받았다면: 환불을 원칙적으로는 온체인으로 하는 편이 명확합니다.
• 온체인에서 못 받았다면: 온체인 환불은 할 게 없고, 오프체인 원복이 전부입니다.

2) 회사는 서비스를 제공할까

정답은 정책입니다. 다만 안전한 기본값은 단계화입니다.

• pending: 제공하지 않거나 매우 제한된 제공
• included + 약한 confirmations: 제한적 제공
• finalized 또는 강한 기준: 비가역 혜택 제공

2-1) 제공했는데 포함/확정이 안 되면 취소해야 할까

가능하면 회수 가능한 형태로 설계하는 게 운영 난이도를 결정합니다.

• 회수 가능한 서비스: 권한/구독/콘텐츠 잠금해제 → 실패 시 회수 가능
• 회수 불가능한 서비스: 실물 배송, 영구 크레딧, 외부 비용 발생 → 확정 기준을 더 강하게 잡거나 선제공을 금지

결론: 거래소처럼 숫자로 관리하면 상관 없을까?

거래소 모델은 내부를 숫자로 굴릴 수 있습니다. 하지만 그건

• 거래소가 자산을 커스터디하고
• 내부 원장을 중앙화 DB 로 운영하며
• 신뢰의 책임을 거래소가 전부 떠안기 때문입니다.

즉, 오프체인 선처리의 극단형이 거래소 모델이고, 대신 보안과 운영 리스크도 같이 커집니다.

5-2) 거래소는 어떻게 굴러갈까? : 내부 원장 + (입출금만) 온체인 정산

거래소를 이해하면 온체인 vs 오프체인 경계가 한 번에 정리됩니다.
핵심은 이겁니다.

거래소의 대부분 기능은 중앙화된 내부 원장 DB에서 돌아가고, 온체인은 주로 입출금 정산에만 쓴다

1) 원화 입금: 완전 오프체인

• 사용자가 은행 계좌에서 거래소 지정 계좌로 송금
• 거래소가 은행/정산 시스템을 통해 입금 확인
• 거래소 내부 원장 DB 에서 사용자의 원화 잔고를 증가

즉, 원화 잔고는 블록체인과 무관한 전통 결제 레일에서 확정됩니다.

2) 코인 매수/매도: 보통 오프체인 매칭 + 내부 원장 분개

사용자가 거래소에서 코인을 산다는 것은 대개

• 주문 생성 오프체인
• 매칭 엔진이 체결 처리 오프체인
• 체결 결과를 내부 원장에 분개

예시로 보면

• KRW 잔고 감소
• BTC 잔고 증가

하지만 이 단계에서 코인이 온체인에서 내 주소로 이동한 것은 아닙니다.
거래소 장부가 내 몫을 기록한 상태입니다.

3) 코인 출금: 여기서 온체인 트랜잭션 발생

사용자가 개인 지갑으로 출금하면 그때는

• 거래소가 자신의 핫월렛 또는 콜드월렛에서
• 사용자 주소로 전송하는 온체인 트랜잭션을 생성/서명/전파
• 블록 포함과 확정이 되면 진짜로 사용자 지갑에 도착

그래서 거래소에서 코인을 샀다는 말은 보통

• 출금 전: 내부 원장상의 권리
• 출금 후: 온체인 상 내 주소의 코인

으로 나뉩니다.

왜 이렇게 할까?

매매를 체결할 때마다 온체인에 올리면

• 지연이 커지고
• 수수료가 커지고
• 처리량이 부족해서

거래소 운영이 불가능합니다.
그래서 내부에서 빠르게 처리하고, 온체인은 정산 레이어로만 쓰는 구조가 됩니다.

결론: 숫자로 굴릴 수 있지만, 신뢰의 책임도 같이 온다

거래소 모델은 내부를 숫자로 굴릴 수 있습니다. 하지만 그건

• 거래소가 자산을 커스터디하고
• 내부 원장을 중앙화 DB 로 운영하며
• 신뢰와 보안과 운영 리스크를 거래소가 떠안기 때문입니다.

즉, 빠른 UX 와 강한 신뢰를 분리하는 대신, 빠름의 대가로 중앙화된 신뢰를 선택한 형태라고 볼 수 있습니다.

6) 실무 패턴: 합의 경계를 코드로 고정하기

패턴 1. 상태 머신으로 단계 분리

• pending, included, confirmed, finalized
• offchain provisional, onchain settled

패턴 2. 멱등성과 재시도

• idempotency key 를 모든 결제 또는 제공에 붙인다
• reorg, 중복 이벤트에 견딘다

패턴 3. 증거 기반 설계

• 요청, 응답, 서명, 영수증 receipt 를 전부 로그로 남긴다
• 분쟁 시 재현 가능하게 만든다

---

 

7) 결론

• 온체인 vs 오프체인은 저장 위치가 아니라 합의 경계다
• 오프체인은 임의 처리가 아니라, 합의 대신 내가 책임지는 영역이다
• 현실은 하이브리드이며, 정산 모델이 핵심이다
• 무엇을 온체인에 맡길지 결정하려면 되돌림 가능성, 검증 필요성, 지연 민감도를 기준으로 잡자

---