---
id: 13
title: "병렬 실행의 세 가지 경로: 결정론적 스케줄링, 낙관적 OCC, 객체 모델"
slug: parallel-execution-approaches
date: 2026/08/27
summary: 단일 스레드 실행을 넘어서는 세 가지 성숙한 경로가 있습니다. Sealevel 방식의 결정론적 사전 선언, Block-STM 방식의 낙관적 동시성 제어, Sui 방식의 객체 모델입니다. 이 글은 각 접근의 전제와 개발자 비용, 그리고 EVM 호환성과의 관계를 비교합니다.
keywords: 병렬 실행,Sealevel,Block-STM,낙관적 동시성 제어,객체 모델
heroImage: /images/community-bg.png
---

단일 스레드 EVM은 결정성을 비교적 저렴하게 삽니다. 순서가 고정되어 있고 재현이 단순합니다. 그러나 목표가 "검증 가능한 정확성을 깨뜨리지 않으면서 실행 폭을 넓히는 것"이 되는 순간, 설계자는 같은 갈림길에 부딪힙니다. 두 트랜잭션을 함께 실행해도 되는지를 누가 판단하는가 — 개발자가 미리 선언하는가, 아니면 런타임이 나중에 발견하는가?

이 선택은 프로그래밍 모델과 마이그레이션 비용, 그리고 핫 경합 상황에서의 실제 처리량을 좌우합니다. 업계는 비교적 뚜렷한 세 가지 경로를 걸어왔습니다. Solana의 Sealevel로 대표되는 결정론적 병렬화, Aptos의 Block-STM과 여러 병렬 EVM으로 대표되는 낙관적 동시성 제어(OCC), 그리고 Sui로 대표되는 객체 모델입니다. 셋 모두 "병렬화"하지만 전제와 비용은 크게 다릅니다.

## 결정론적 병렬화: 의존성을 트랜잭션에 적는다

결정론적 경로는 각 트랜잭션이 읽고 쓸 계정(또는 리소스) 전체 목록을 읽기 전용 또는 쓰기 가능으로 표시해 함께 제출할 것을 요구합니다. 실행 전에 런타임이 그래프를 만들 수 있습니다. 쓰기 충돌이 없으면 병렬 안전이고, 읽기를 공유하면 함께 스케줄링할 수 있으며, 쓰기를 공유하면 직렬화합니다. 스케줄러는 실행 도중 의존성을 추측할 필요가 없습니다. 충돌 구조는 큐에 들어가는 시점에 대략 알 수 있습니다. Solana의 Sealevel은 이 경로에서 가장 많이 인용되는 엔지니어링 사례이며, 계정 모델과 런타임 스토리지 설계에 긴밀하게 묶여 있습니다.

장점은 예측 가능성입니다. 일단 수락된 실행 경로는 "중간에 충돌을 발견하고 시도 전체를 폐기하는" 낭비를 덜 합니다. 비용은 개발자와 툴링에 떨어집니다. 단순 이체는 선언 비용이 낮지만, 접근 경로가 런타임 조건에 따라 달라지는 복잡한 분기를 가진 프로그램은 과잉 선언(병렬성 축소)이나 누락 선언(트랜잭션 실패) 중 하나를 택해야 합니다. 고전적인 EVM의 스토리지 슬롯 접근은 컨트랙트 내부 조건으로 결정되는 경우가 많고, 바이트코드 자체는 Sealevel식 계정 목록을 담지 않습니다. 사전 선언을 강제하면 바이트코드 수준 호환성이 즉시 깨집니다. 컨트랙트와 감사 가정을 모두 다시 써야 합니다.

사전 선언이 애플리케이션 계층의 핫스팟을 없애주지는 않습니다. DEX 풀, 청산, 인기 민팅은 여전히 쓰기 집합을 소수 계정에 집중시킵니다. 충돌 체인이 길어지고, 병렬성은 스케줄러가 아니라 상태 설계에 의해 제한됩니다. 결정론적 경로가 해결하는 것은 "스케줄 시점에 의존성을 아는가"이지 "상태가 분산되었는가"가 아닙니다. 워크로드가 어떻게 핫스팟을 만드는지는 다른 글에서 다룹니다. 여기서는 모든 이가 같은 슬롯을 두고 경쟁하는 컨트랙트 구조는 어떤 엔진도 구할 수 없다는 점만 기억해 둡니다.

## 낙관적 동시성 제어: 병렬을 가정하고 오류에서 수렴한다

OCC는 가정을 뒤집습니다. 대부분의 트랜잭션은 충돌하지 않으므로 먼저 병렬로 실행하고, 그다음 읽기 집합이 여전히 유효한지 검증합니다. 충돌이 있으면 중단하고 정규 순서로 재실행하여 결과가 어떤 직렬 순서와 동일해질 때까지 반복합니다. 소프트웨어 트랜잭션 메모리(STM)와 데이터베이스 OCC가 이론적 골격을 제공하고, Aptos의 Block-STM은 블록체인 맥락에서 널리 인용되는 구현입니다. 미리 정해진 순서 아래에서 낙관적으로 실행하고, 실행 과정에서 의존성을 발견해 협력적으로 스케줄링하며 작업을 재실행하여 실제로 영향을 받은 트랜잭션만 롤백하는 것을 목표로 합니다.

공개 자료에 등장하는 높은 TPS 수치는 대개 특정 벤치마크, 하드웨어, 트랜잭션 구성(예를 들어 실험실이나 테스트 환경의 비자명한 Move 트랜잭션)에서 나온 것입니다. 메인넷의 혼합 부하에서의 사용자 경험과 맞바꿔 쓸 수 없습니다. 중요한 것은 메커니즘의 형태입니다. 정확성은 "결국 주어진 순서와 동등해짐"에 의존하고, 성능은 "충돌률이 충분히 낮거나 재실행이 충분히 저렴함"에 의존합니다.

여러 EVM 호환 체인이 OCC를 선택하는 이유는 일관됩니다. 트랜잭션을 수신하는 시점에는 모든 스토리지 접근을 정적으로 알 수 없고, 실행만이 그것을 드러냅니다. 런타임이 실제 읽기/쓰기 집합을 기록하고, 충돌하는 부분집합은 직렬로 수렴하며, 나머지는 병렬 이득을 유지합니다. Monad, Sei 등은 스냅샷과 커밋 순서, 합의와 실행의 분리 여부에서 차이가 있지만 "개발자 사전 선언이 필요 없다"는 호환성 전제를 공유합니다.

OCC의 핵심 위험도 똑같이 공개되어 있습니다. 충돌률이 치솟으면 재실행이 병렬 이득을 잡아먹고, 극단적으로는 처리량이 단순 직렬+잠금 전략에 근접하거나 그보다 낮아질 수 있습니다. 선택적 롤백, 실행 중 탐지, 배치 분할, 읽기/쓰기 집합의 입자성이 낙관적 가정이 실패할 때의 테일 비용을 결정합니다. 다음 글에서는 데이터베이스 관점에서 OCC의 읽기–검증–쓰기 단계를 설명합니다.

## 객체 모델: 원장 구조를 바꿔 병렬 경계를 바꾼다

세 번째 경로는 계정 모델을 덧대지 않고 원장 구조 자체를 바꿉니다. Sui는 자산을 고유 ID를 가진 객체로 모델링하고, 소유 객체와 공유 객체로 나눕니다. 소유 객체는 단일 작성자를 가지므로 관련 트랜잭션이 낮은 지연의 경로를 탈 수 있고 전역 순서 요구가 약해집니다. 공유 객체는 다수가 접근할 수 있으므로 합의를 통해 순서를 정해야 합니다. 병렬성은 소유권 문제가 됩니다. 자연스럽게 단일 소유자인 흐름은 확장되고, 진짜 다자간 공유 상태는 전역 순서 비용을 지불합니다.

이 모델은 NFT와 개인 간 자산 이동에 우호적입니다. AMM 풀과 전역 경매처럼 공유 객체가 많은 애플리케이션은 여전히 핫 경합에 부딪히는데, 다만 계정-슬롯이 아니라 객체 입자성에서 발생합니다. 비용은 패러다임과 언어 마이그레이션입니다. Move와 객체 소유권은 Solidity의 계정 모델과 다릅니다. 기존 이더리움 컨트랙트와 Foundry/Hardhat 워크플로를 "그대로 옮길" 수 없고, 생태계는 병렬성을 위해 학습과 감사 비용을 지불합니다.

객체 모델은 실행 병렬화가 "선언"이나 "낙관" 스케줄링만이 아니라 상태 토폴로지라는 또 다른 지렛대를 가질 수 있음을 보여줍니다. 동시에 EVM 호환 경로에 경고를 줍니다. 계정과 전역 상태를 유지한다는 것은 객체 모델이 사주는 구조적 병렬성 일부를 포기한다는 뜻이므로, 런타임 스케줄링이 더 많은 부담을 져야 합니다.

## 세 가지 경로 비교

| 차원 | 결정론적(Sealevel류) | 낙관적 OCC(Block-STM류) | 객체 모델(Sui류) |
|------|----------------------|--------------------------|-------------------|
| 의존성을 아는 시점 | 제출 전 선언 | 실행 중/후 발견 | 객체 소유권에서 도출 |
| 개발자 부담 | 높음(접근 목록) | 낮음(익숙한 컨트랙트 작성 방식 유지) | 높음(새 모델/언어) |
| 고전적 EVM과의 호환 | 어려움(의미 충돌) | 비교적 가능 | 마이그레이션 필요 |
| 주요 실패 모드 | 과잉/누락 선언, 핫스팟은 여전히 직렬화 | 높은 충돌률의 재실행 폭풍 | 공유 객체 핫스팟, 생태계 마이그레이션 |

패턴은 분명합니다. 핵심 제품 제약이 기존 이더리움 컨트랙트 및 도구와의 바이트코드 수준 호환이라면, 결정론적 사전 선언과 객체 모델은 모두 재작성이나 스택 교체를 강제하므로 현실적인 선택은 대개 OCC로 수렴합니다. 이것은 OCC가 모든 부하에서 이론적으로 최선이라는 주장이 아닙니다. 결정론적 경로와 객체 경로는 각자의 생태계에서 강한 처리량을 보여주었습니다. 다만 호환성이라는 제약이 설계 공간을 압축한다는 인정입니다.

낙관적 병렬 EVM으로 자리매김한 L1에게 OCC 선택은 제약 아래의 수렴이지 구호가 아닙니다. 진짜 엔지니어링 질문은 읽기/쓰기 집합을 어떻게 정의하고, 충돌을 얼마나 일찍 탐지하며, 핫 부하에서 재실행을 어떻게 제한할 것인가입니다. 이는 OCC의 데이터베이스 직관과 워크로드 핫스팟에 대한 솔직한 평가 위에 서 있습니다.

## 더 읽기

- 이전 글: ["블록체인 확장 지도: L1 병렬화, L2, 샤딩, DA가 각각 해결하는 것"](/ko/blog/blockchain-scaling-map)
- 다음 글: ["낙관적 동시성 제어(OCC) 입문: 데이터베이스에서 온체인 실행까지"](/ko/blog/optimistic-concurrency-control-intro)
- 관련 글: ["Bitroot의 병렬화 EVM 기술 해설: 낙관적 병렬화"](/ko/blog/bitrootevm-), ["충돌 핫스팟과 워크로드: 병렬 EVM이 실제로 도움이 될 때"](/ko/blog/parallel-evm-workload-hotspots)