---
id: 14
title: "낙관적 동시성 제어(OCC) 입문: 데이터베이스에서 온체인 실행까지"
slug: optimistic-concurrency-control-intro
date: 2026/08/29
summary: 낙관적 동시성 제어는 1981년 데이터베이스 연구에서 시작되어 오늘날 많은 병렬 EVM을 떠받칩니다. 이 입문 글은 읽기–검증–쓰기 단계를 설명하고, OCC를 비관적 잠금 및 MVCC와 대비하며, 블록체인이 추가하는 결정성과 비잔틴 제약을 정리합니다.
keywords: 낙관적 동시성 제어,OCC,읽기/쓰기 집합,직렬화 가능성,병렬 EVM
heroImage: /images/community-bg.png
---

병렬 EVM 논의는 같은 동사를 계속 재활용합니다. 병렬로 실행하고, 충돌을 확인하고, 필요하면 롤백하고 재시도한다. 체인 고유의 발상처럼 들리지만 골격은 데이터베이스에서 왔습니다. 1981년 H. T. Kung과 John T. Robinson은 ACM TODS에 "On Optimistic Methods for Concurrency Control"을 발표하며 "낙관적"을 분석 가능한 동시성 기법으로 만들었습니다. 그 논리가 명확해지면 Block-STM이나 병렬 EVM 엔진은 훨씬 덜 신비롭게 보입니다.

이 글은 데이터베이스 렌즈로 OCC의 가정과 세 단계를 설명하고, 비관적 잠금 및 MVCC와 구분한 뒤, 블록체인이 이 골격을 빌려올 때 추가하는 제약을 나열합니다. 낙관적 병렬화가 왜 EVM 호환 경로에 맞는지에 대한 사전 지식이며, 특정 제품의 파라미터 설명서가 아닙니다.

## 낙관성이 거는 내기

전통적 동시성 제어는 잠금에 기댑니다. 접근 전에 획득하여 읽는 동안 아무도 바꾸지 못하게 합니다. 잠금은 정확성을 증명할 수 있지만 잠금 테이블, 교착 탐지, 잠금을 오래 쥔 트랜잭션이 높은 동시성 아래에서 눈에 띄는 오버헤드가 됩니다. OCC의 반직관적 제안은 이렇습니다. 대부분 트랜잭션의 읽기/쓰기 집합이 겹치지 않는다면 먼저 실행하게 하고, 충돌 검사를 커밋 직전까지 미루어 일어나지 않을 수도 있는 충돌에 잠금 비용을 쓰지 않습니다. 논문은 백업을 주된 제어로 취급합니다. "낙관적"이란 경합이 드물기를 바란다는 뜻입니다.

충돌을 부정하는 것이 아니라, 충돌을 다루는 시점을 옮깁니다. 실행 전 예방에서 커밋 근처의 검증으로 이동합니다. 시점이 바뀌면 설계 병목도 "얼마나 세밀하게 잠글까"에서 "얼마나 저렴하게 탐지하고 재실행을 어떻게 줄일까"로 옮겨갑니다.

## 읽기, 검증, 쓰기: 3단계 골격

고전적 OCC는 트랜잭션을 세 단계로 나눕니다.

읽기 단계: 트랜잭션이 데이터베이스를 자유롭게 읽습니다. 쓰기는 사설 작업 공간에만 남고 공유 상태를 즉시 오염시키지 않습니다. 관찰자에게 검증되지 않은 부수 효과는 보이지 않거나 격리 수준에서만 보입니다.

검증 단계: 트랜잭션이 타임스탬프나 일련번호를 받고, 시스템이 읽기 집합이 여전히 유효한지 확인합니다. 즉 읽은 뒤에 순서상 앞서야 할 다른 트랜잭션이 그 데이터를 덮어썼는지 봅니다. 읽기 집합이 오래되었다면 검증이 실패하고 트랜잭션은 중단 후 재시도합니다. 검증은 실질적으로 직렬화 가능성에 관한 것입니다. 병렬 인터리빙이 어떤 직렬 순서와 동등해질 수 있는가?

쓰기 단계: 검증을 통과하면 사설 쓰기 집합을 공유 데이터베이스에 병합합니다. 논문은 직렬 검증과 병렬 검증도 구분합니다. 전자는 검증과 쓰기를 더 강한 원자적 단계로 묶어 단순하고, 후자는 더 많은 동시성을 허용하지만 커밋이 서로 모순되지 않도록 추가 장치가 필요합니다.

블록체인 병렬 실행에 대응시키면 거의 일대일입니다. 트랜잭션이 추측 실행되며 읽기/쓰기 집합을 수집하고, 블록의 고정 순서에 대해 검증하며, 커밋 담당이 상태를 적용하고 실패는 의존성을 따라 재실행됩니다. 이름이 STM이든 Block-STM이든 "낙관적 병렬 EVM"이든 골격은 여전히 OCC입니다.

## 비관적 잠금이 무겁게 느껴지는 이유

2단계 잠금(2PL)은 관계형 데이터베이스의 고전적 비관 기법입니다. 트랜잭션은 끝날 때까지 잠금만 획득합니다. 정확성을 논하기 쉽지만 비용도 마찬가지입니다. 잠금 메모리, 교착, 선두 차단입니다. 경합이 낮으면 2PL의 "예방세"가 OCC의 간헐적 재실행보다 클 수 있고, 경합이 높으면 OCC의 재실행 폭풍이 잠금보다 비쌀 수 있습니다. 그래서 OCC는 오래도록 "경합이 낮을 때 더 이득"이라는 꼬리표가 붙었습니다. 온체인에서는 이렇게 번역됩니다. 블록 안의 읽기/쓰기 집합이 거의 겹치지 않으면 낙관적 병렬화가 이기고, 모두가 같은 AMM 풀을 때리면 엔지니어링이 재실행을 제한하지 못하는 한 숫자가 나빠집니다.

성능 공개가 워크로드 유형과 테스트 조건을 명시해야 하는 이유도 여기 있습니다. 무관한 이체를 쏟아붓는 실험실 부하와 메인넷 DEX 경로의 피크는 충돌 구조가 전혀 다릅니다. 같은 OCC 엔진이 한 자릿수 차이로 느껴질 수 있습니다.

## MVCC: 관련은 있지만 다른 손잡이

다중 버전 동시성 제어(MVCC)는 OCC 옆에 자주 등장하지만 다른 질문에 답합니다. MVCC는 읽는 쪽이 일관된 스냅샷을 보게 하여 읽기가 쓰기를 막지 않게 합니다. 핵심은 버전 저장과 가시성 규칙입니다. OCC의 핵심은 검증 실패 시 무슨 일이 일어나는가입니다. 둘은 조합됩니다. 버전으로 읽기/쓰기 충돌을 줄이고, 낙관적 검증으로 쓰기/쓰기 충돌의 승자를 정합니다. Hekaton, Silo, TicToc 같은 시스템은 타임스탬프, 분산 검증, 지연된 시퀀스 할당을 갖춘 변형을 보여줍니다. 공통점은 순수 비관적 잠금이 멀티코어 하드웨어에서 너무 비싸다는 것을 인정하고, 버전 관리와 지연된 검증으로 처리량을 사는 것입니다.

온체인 엔지니어에게 이 구분은 논문과 문서를 읽을 때 도움이 됩니다. "우리는 MVCC를 쓴다"는 상태 표현만 설명할 수 있습니다. 병렬 EVM의 동작을 실제로 결정하는 것은 대개 검증 규칙과 재실행 스케줄, 즉 OCC 계열의 질문입니다.

## 블록체인이 추가하는 규칙

데이터베이스 OCC는 보통 로컬 재시도와 중단을 관찰할 수 있는 클라이언트를 가정합니다. 블록체인은 두 가지 단단한 제약을 더합니다.

첫째, 네트워크 전체의 결정론적 재현입니다. 모든 정직한 노드는 같은 블록에 대해 같은 최종 상태에 도달해야 합니다. 낙관적 실행은 노드 내부에서 병렬화할 수 있지만, 커밋은 정규 순서와 동등한 상태로 수렴해야 합니다. "이 머신은 스케줄러 운으로 다른 쓰기 집합을 제출했다"는 금지됩니다. 따라서 구현은 스레드 스케줄링이 의미론의 일부가 되지 않도록 미리 정한 순서나 정규 시퀀스를 프로토콜에 새겨 넣습니다.

둘째, 비잔틴 환경입니다. 단일 실행자를 정직하다고 가정할 수 없습니다. 노드는 거짓말하거나 누락하거나 다른 이를 늦추기 위해 충돌을 조작할 수 있습니다. 그래서 병렬 엔진은 더 큰 합의와 검증 흐름 안에 놓입니다. 합의가 순서와 최종성 경로를 정하고, 실행은 효율적이고 결정론적으로 상태 루트를 계산하며, 라이트 클라이언트와 풀 노드는 중간의 낙관적 추측이 아니라 검증 가능한 최종 상태에 의존합니다.

Block-STM 관련 작업에서 Aptos 팀은 엔진을 STM과 OCC 전통에 놓고, "순서"를 저주에서 성능 조건으로 바꾸는 데 무게를 둡니다. 순서가 주어지면 병렬성은 그 순서로의 수렴을 가속할 뿐입니다. 같은 해석이 병렬 EVM에도 맞습니다. EVM 트랜잭션은 이미 블록이 정렬된 세계에 살고 있고, OCC는 그 순서를 취소하는 것이 아니라 그 아래에서 멀티코어를 위해 경쟁합니다.

## 읽기/쓰기 집합: 추상적으로는 단순하고, 엔지니어링에서는 어렵다

교과서적 읽기/쓰기 집합은 EVM에서 잔액, nonce, 스토리지 슬롯, 간헐적 로그나 환불 부수 효과에 대응합니다. 키가 너무 거칠면 거짓 충돌을 만들어 병렬성을 낭비하고, 너무 미세하면 추적과 검증 비용이 오릅니다. 동적 점프와 외부 호출, 프록시는 정적 사전 분석을 불완전하게 만듭니다. EVM이 결정론적 사전 선언에 어려움을 겪고 런타임 읽기/쓰기 집합 수집이 기본값이 된 이유입니다.

충돌이 트랜잭션 하나를 재실행하는지, 의존성 폐포를 재실행하는지, 배치 전체를 재실행하는지가 테일 지연을 결정합니다. 강한 OCC 구현은 검증 실패를 예외 분기가 아니라 예상되는 핫 경로로 취급합니다. 그런 세부는 구체적 엔진의 몫이고, 이 입문 글은 판단력만 세웁니다. 어떤 병렬 EVM이 높은 처리량을 주장하면 테스트넷이나 벤치마크 조건을 묻기 전에 충돌률 가정과 재실행 정책을 먼저 물어야 합니다.

## 직관에서 다음 포지셔닝 글로

블록체인 실행을 데이터베이스 OCC로 읽으면 논의가 구호에서 검증 가능한 메커니즘으로 돌아옵니다. 무엇을 가정하는지, 검증이 무엇을 확인하는지, 실패 비용을 누가 지불하는지입니다. Bitroot와 다른 낙관적 병렬 EVM 프로젝트는 "OCC를 쓰는가"에서 좀처럼 갈리지 않고, 읽기/쓰기 집합을 어떻게 포착하는지, 충돌을 어떻게 계층화하는지, 합의가 실행과 별도로 파이프라인되는지에서 갈립니다. 다음 글은 Bitroot에 초점을 맞춥니다. 확장 지도와 세 가지 병렬 경로에서 어느 칸을 차지하고, 경계는 어디이며, 어떤 주장이 테스트 조건 아래의 엔지니어링 목표로 남아야 하는지입니다.

## 더 읽기

- 이전 글: ["병렬 실행의 세 가지 경로: 결정론적 스케줄링, 낙관적 OCC, 객체 모델"](/ko/blog/parallel-execution-approaches)
- 다음 글: ["Bitroot 포지셔닝: 낙관적 병렬 EVM L1의 경계"](/ko/blog/bitroot-positioning)
- 관련 글: ["Bitroot의 병렬화 EVM 기술 해설: 낙관적 병렬화"](/ko/blog/bitrootevm-), ["성능 지표 용어집: TPS, BPS, 확인 지연, 최종성, 충돌률"](/ko/blog/performance-metrics-glossary)