낙관적 검증으로 트랜잭션 충돌을 다루는 방법

잠금 없이 충돌을 마지막에 판정하는 방식

낙관적 검증(Optimistic Concurrency Control)은 트랜잭션의 동시성 제어 기법이다. 충돌이 드물다는 전제 아래, 트랜잭션이 실행되는 동안에는 검사나 잠금(lock)을 최소화하고 종료 시점에 데이터 일관성을 한꺼번에 검증한다.

검증에서 충돌이 확인되면 해당 트랜잭션은 롤백(철회)한 뒤 다시 시작한다. 읽기 비중이 높고 쓰기 충돌이 적은 환경에서 효율을 기대할 수 있으며, 충돌을 사전에 막는 비관적 동시성 제어와 대비된다.

판독부터 기록까지의 흐름

낙관적 검증은 판독, 검증, 기록 단계로 진행된다.

⤢✕

판독 단계에서 로컬 작업 공간을 만든다

트랜잭션은 필요한 데이터를 로컬 작업 공간으로 복사하고, 모든 연산을 이 복사본에서 수행한다. 이 시점에는 잠금을 획득하지 않는다. Start(Ti) 타임스탬프는 판독 단계가 시작된 시간을 기록한다.

검증 단계에서 충돌 여부를 확인한다

로컬 연산이 끝나면 트랜잭션이 데이터베이스의 일관성을 훼손하지 않는지 확인한다. 다른 트랜잭션과 충돌하면 트랜잭션은 철회(abort)되고 재시작된다. Validation(Ti)는 판독 단계가 끝나고 검증이 시작되는 시점의 타임스탬프다.

기록 단계는 검증 성공 뒤에만 수행된다

검증을 통과한 변경사항만 실제 데이터베이스에 반영한다. 기록 단계가 완료되면 Finish(Ti) 타임스탬프를 남기고 트랜잭션을 커밋한다.

트랜잭션 유효성을 판단하는 조건

트랜잭션 Ti는 다음 조건 가운데 하나를 만족하면 Tj에 대해 유효하다고 판단한다.

Finish(Tj) < Start(Ti)

Tj가 Ti의 시작 전에 끝난 경우다. 두 트랜잭션은 시간적으로 분리돼 있다.
Start(Ti) < Finish(Tj) < Validation(Ti)이고, Ti와 Tj의 쓰기 집합이 겹치지 않는 경우다.

병렬로 실행됐더라도 서로 다른 데이터를 수정했다면 충돌하지 않는다.
Start(Ti) < Start(Tj) < Validation(Ti)이고, Ti의 쓰기 집합과 Tj의 읽기 집합이 겹치지 않는 경우다.

Ti가 수정한 데이터를 Tj가 읽지 않은 상태다.

⤢✕

읽기 중심 워크로드에서 얻는 이점과 한계

잠금을 사용하지 않으므로 교착상태(Deadlock)가 발생하지 않는다. 커밋 전 트랜잭션이 다른 트랜잭션에 영향을 주지 않아 Cascading Rollback도 막을 수 있다. 잠금 대기와 잠금 획득·해제 관리 부담이 줄어들고, 읽기 작업이 많은 환경에서는 병렬성과 처리 성능을 높일 수 있다.

대신 충돌이 발생하면 재시작에 따른 자원 낭비가 생긴다. 오래 실행된 트랜잭션은 검증 단계에서 실패했을 때 손실이 더 크며, 검증 로직 자체도 복잡해질 수 있다. 쓰기 작업이 많아 충돌이 빈번한 환경에서는 롤백과 재시작이 반복돼 성능이 저하된다.

비관적 검증과 선택 기준

구분	비관적 검증 (Pessimistic)	낙관적 검증 (Optimistic)
기본 가정	사용자가 동시에 데이터를 수정할 것이라 가정	충돌이 드물게 발생한다고 가정
잠금 방식	Read Phase부터 Lock 획득, 완료 시 Unlock	잠금을 사용하지 않음
충돌 처리	미리 방지 (예방적)	발생 후 처리 (사후 검증)
교착상태	발생 가능	발생하지 않음
적합한 환경	쓰기 작업이 많고 충돌이 빈번한 환경	읽기 작업이 많고 충돌이 적은 환경
트랜잭션 지연	잠금으로 인한 대기 시간 발생	재시작으로 인한 지연 가능성
구현 복잡성	잠금 관리 복잡성	검증 로직 복잡성

웹과 데이터베이스, 분산 환경에서의 활용

웹 애플리케이션에서는 버전 정보인 ETag, Last-Modified를 활용해 낙관적 잠금을 구현할 수 있다. RESTful API의 조건부 요청인 If-Match, If-None-Match도 같은 맥락에서 사용된다. 게시판에서 여러 사용자가 같은 게시물을 수정하는 상황이 한 사례다.

⤢✕

데이터베이스에서는 오라클 데이터베이스의 SELECT FOR UPDATE NOWAIT, MySQL InnoDB 스토리지 엔진의 MVCC(Multi-Version Concurrency Control), JPA/Hibernate의 @Version 어노테이션을 통한 낙관적 잠금 구현이 관련된다.

분산 환경에서는 Git의 브랜치-병합 모델, NoSQL 데이터베이스(MongoDB, Cassandra 등)의 충돌 해결 메커니즘, 클라우드 스토리지 서비스의 파일 동시 편집 기능에서 같은 접근을 찾을 수 있다.

구현에서 놓치기 쉬운 지점

버전 관리는 타임스탬프, 버전 번호, 해시값처럼 일관된 식별자를 기반으로 설계해야 하며, 변경 이력 추적 구조도 함께 필요하다. 충돌이 자동 병합 가능한 경우와 수동 개입이 필요한 경우를 구분하고, 사용자가 충돌을 해결할 수 있는 인터페이스를 마련해야 한다.

재시도에는 지수 백오프(Exponential Backoff) 등의 알고리즘을 적용할 수 있다. 무한 재시도를 막기 위한 최대 시도 횟수도 설정한다. 운영 중에는 충돌 발생 빈도를 추적하고, 재시작 비용을 측정해 최적화 대상으로 삼는다.

낙관적 검증은 읽기 중심 환경에서 잠금 대기를 줄이는 선택지다. 다만 충돌 빈도와 재시작 비용을 함께 봐야 하며, 워크로드 특성에 따라 비관적 검증과 적절히 선택해야 한다.