블록체인을 분산 데이터베이스라고 배웠다면 — 다시 시작하자
블록체인을 처음 배울 때 가장 많이 듣는 설명이 있다. “분산 데이터베이스”, “변조 불가능한 원장”. 틀린 말은 아니지만, 이 정도 이해로는 프로덕션 시스템을 운용하기 어렵다. 트랜잭션이 왜 실패했는지, revert가 왜 일어났는지, 상태가 왜 예상과 다른지 — 이 질문들에 답하려면 더 깊은 모델이 필요하다.
백엔드 개발자 관점에서 블록체인을 정확하게 정의하면 이렇다.
블록체인 = 복제된 상태 머신(Replicated State Machine)
이 한 문장을 제대로 이해하면, 이더리움의 거의 모든 동작이 논리적으로 풀린다.
상태 머신이란 무엇인가
상태 머신(State Machine)은 현재 상태(State)와 입력(Input)이 주어졌을 때 결정론적으로 다음 상태를 만들어내는 시스템이다. 여기서 핵심은 결정론적이라는 단어다. 같은 상태에 같은 입력을 주면 반드시 같은 결과가 나온다.
이더리움에서 이를 대입하면:
- 상태(State) = 모든 주소의 ETH 잔액 + 모든 컨트랙트 코드 + 모든 컨트랙트 Storage + 모든 주소의 nonce
- 입력(Input) = 트랜잭션 집합 (하나의 블록)
- 전이 함수 = EVM(Ethereum Virtual Machine) 실행
블록이 하나 추가될 때마다, 네트워크는 이전 상태에 트랜잭션 집합을 적용해 새로운 상태를 만든다.
상태 S_n + 트랜잭션 집합 T → 상태 S_{n+1}
복제된(Replicated)의 의미
상태 머신이 “복제됐다”는 것은, 전 세계 수만 개의 노드가 동일한 상태를 독립적으로 유지한다는 뜻이다. 어떤 중앙 서버도 없다. 모든 노드가 제네시스 블록부터 현재까지 동일한 트랜잭션 집합을 동일한 순서로 실행했기 때문에, 동일한 상태에 도달해 있다.
이것이 가능한 이유가 바로 합의 알고리즘이다. 합의 알고리즘은 “다음 블록에 어떤 트랜잭션 집합을 어떤 순서로 넣을지”를 전체 네트워크가 동의하도록 만든다. 이더리움은 현재 지분증명(Proof of Stake, PoS)을 사용한다.
이 모델이 실무에서 왜 중요한가
1. 트랜잭션 실패(revert)의 의미
상태 머신 모델에서 트랜잭션 실패는 단순하다. 전이 함수(EVM)를 실행했더니 조건을 만족하지 못했다(require 실패, out of gas 등). 그러면 해당 트랜잭션은 상태에 아무 흔적도 남기지 않는다. 단, 소비된 gas는 환불되지 않는다.
이 점이 중요하다. 트랜잭션이 revert됐다고 해서 “없던 일”이 되는 게 아니다. 그 트랜잭션은 블록체인에 기록되고, gas는 소모됐다. 단지 상태 변화만 롤백됐을 뿐이다.
2. 노드마다 상태가 다를 수 있는 시점
복제된 상태 머신이라고 해서 항상 모든 노드가 동일한 상태를 갖는 것은 아니다. 새 블록이 전파되는 동안, 일부 노드는 최신 블록을 아직 받지 못했을 수 있다. 이 짧은 시간 동안 노드마다 “현재 상태”가 다르다.
이것이 Finality(최종성) 문제다. 트랜잭션이 블록에 포함됐다고 해서 즉시 확정된 게 아니다. 충분한 블록이 쌓여야 비로소 “최종 확정”으로 볼 수 있다. 이더리움 PoS 기준으로는 약 2에포크(~12분)가 지나야 경제적 최종성을 얻는다.
3. Reorg(체인 재구성)가 발생하는 이유
가끔 네트워크에서 두 개의 노드가 거의 동시에 새 블록을 생성하는 경우가 있다. 이때 네트워크는 일시적으로 두 갈래로 분기된다. 결국 더 무거운(검증자 지지를 많이 받은) 체인이 살아남고, 다른 체인의 블록들은 폐기된다. 이 과정이 Reorg다.
Reorg가 발생하면 폐기된 블록에 있던 트랜잭션들이 갑자기 미확정 상태로 돌아간다. 운용 시스템이 “블록 1개 확인됐으니 완료”로 처리했다면 문제가 생긴다. 그래서 중요한 거래는 최소 6블록 이상 확인 후 처리하는 것이 관례다.
이더리움 상태의 실제 구조
이더리움의 “전체 상태”는 Patricia Merkle Trie라는 자료구조로 관리된다. 이 트리의 루트 해시가 블록 헤더에 포함된다(stateRoot). 덕분에 블록 헤더만 있어도 전체 상태가 변조됐는지 검증할 수 있다.
상태는 4가지 Trie로 구성된다:
- State Trie: 모든 계정(EOA + 컨트랙트) 정보
- Storage Trie: 각 컨트랙트의 Storage 변수
- Transaction Trie: 해당 블록의 트랜잭션 목록
- Receipt Trie: 각 트랜잭션의 실행 결과(로그, 가스 사용량 등)
백엔드 개발자가 얻어야 할 핵심 인사이트
전통적인 백엔드 시스템에서 데이터베이스는 중앙화된 단일 진실 원천이다. 트랜잭션이 실패하면 DB가 알아서 롤백한다. 애플리케이션은 DB를 신뢰한다.
블록체인에서는 다르다. 상태 머신이 분산되어 있고, 전이 함수(EVM) 실행 결과가 예상과 다를 수 있다. 가스가 부족하면 revert되고, 네트워크가 혼잡하면 트랜잭션이 mempool에 수시간 대기하며, Reorg가 발생하면 확인된 줄 알았던 트랜잭션이 되돌아온다.
이 모든 상황을 코드로 처리할 수 있어야 프로덕션 블록체인 시스템을 만들 수 있다. 그 시작점이 “블록체인 = 복제된 상태 머신”이라는 정확한 멘탈 모델이다.
다음 단계
상태 머신 모델을 이해했다면, 다음으로 알아야 할 것은 트랜잭션이 어떻게 구성되는지다. 트랜잭션의 각 필드가 무슨 역할을 하는지, nonce가 왜 중요한지, gas 설정을 어떻게 해야 하는지 — 이 내용은 다음 글에서 다룬다.
이더리움 운용 시스템을 만드는 데 필요한 개념들을 시리즈로 정리하고 있습니다. 다음 글도 놓치지 마세요.
About the Author
