I. 서론

현대의 데이터베이스 환경에서는 여러 사용자가 동시에 동일한 데이터를 읽고 변경하는 상황이 일상적으로 발생한다. 인터넷과 모바일 서비스의 확산, 비동기 처리 증가, 분산 시스템과 MSA 환경의 확대로 인해 하나의 업무가 여러 트랜잭션에서 동시에 처리되는 경우도 많아졌다.

이러한 환경에서 적절한 동시성 제어가 없다면 다음과 같은 문제가 발생할 수 있다.

동일 데이터의 변경 결과가 사라지는 갱신 손실
서로 다른 트랜잭션으로 인한 데이터 불일치
예약, 주문, 재고 등의 중복 처리
업무 규칙 위반

따라서 데이터 품질을 확보하기 위해서는 데이터 모델이나 제약조건뿐 아니라 트랜잭션과 동시성 제어 방식을 함께 고려해야 한다.
특히 중요한 점은 동일한 SQL이라도 DBMS에 따라 동작 방식이 다를 수 있다는 것이다.

본 글에서는 Lock 기반 동시성 제어와 MVCC의 차이, 트랜잭션 격리 수준, Consistent Read와 Current Read, Oracle의 Restart Mechanism 그리고 실무 동시성 제어 전략을 살펴본다.

II. 트랜잭션 동시성 제어란 무엇인가

동시성 제어란 여러 트랜잭션이 동시에 실행되는 환경에서 데이터의 정합성과 일관성을 유지하는 기술이다.

예를 들어 좌석 예약을 생각해 보자.

사용자 A	사용자B
151번 좌석 조회: FREE 예약처리 완료 (151번)	151 번 자석 상태 조회: FREE 예약처리(151번)

두 사용자가 동시에 FREE 상태를 확인한 뒤 예약을 수행하면 동일 좌석이 중복으로 예약될 수 있다. 이러한 문제를 해결하기 위해 DBMS는 트랜잭션 사이의 데이터 접근을 제어한다.

대표적인 동시성 문제는 다음과 같다.

문제	설명
Lost Update	다른 트랜잭션의 변경 결과가 덮어써짐
Dirty Read	커밋되지 않은 데이터를 읽음
Non-Repeatable Read	같은 데이터를 다시 읽었을 때 값이 변경됨
Phantom Read	같은 조건으로 조회했을 때 새로운 행이 나타남
Write Skew	개별 트랜잭션은 정상이나 전체 정합성이 깨짐

동시성 제어의 목적은 결국 다음 한 가지로 정리할 수 있다.

여러 트랜잭션이 동시에 실행되더라도 데이터의 업무 규칙과 정합성을 유지하는 것이다.

III. Lock 기반 동시성 제어와 MVCC

1. Lock 기반 동시성 제어

Lock 기반 방식은 데이터를 변경하려는 트랜잭션이 해당 데이터에 Lock을 설정하여 다른 트랜잭션의 변경을 제어하는 방식이다.

일반적인 흐름은 다음과 같다.

데이터 접근 🡪 ② Lock 획득 🡪 ③ Current 데이터 확인 🡪 ④ UPDATE 🡪 ⑤ Commit /
Rollback 🡪 ⑥ Lock 해제

예를 들어 두 트랜잭션이 동일한 데이터를 변경한다고 가정해 보자.

트랜잭션1 (TX1)	트랜잭션 2(TX2)
– UPDATE 실행 – LOCK 획득 – COMMIT (LOCK 해제)	– 동일 데이터 UPDATE – 대기 – 최신 데이터 확인 후 UPDATE 실행

이 방식의 특징은 최신(Current) 데이터를 기준으로 처리한다는 점이다.

즉, 데이터 일관성을 높이기 위해 Lock을 강화하면 시스템의 처리량(동시성)이 감소할 수 있다.

2. MVCC(Multi-Version Concurrency Control)

MVCC는 여러 버전의 데이터를 활용하여 읽기와 쓰기 작업의 충돌을 줄이는 방식이다.

대표적으로 다음 DBMS에서 사용된다.

Oracle
PostgreSQL
MySQL
MariaDB
Tibero

MVCC의 핵심은 다음과 같다.

데이터가 변경되는 동안에도 이전 버전을 유지하여 조회 작업이 특정 시점의 데이터를 읽을 수 있도록 한다.

현재 데이터 🡪 UPDATE 발생 🡪 새로운 데이터 생성 🡪 이전 버전 유지 🡪 조회는 필요한 시점의 데이터 사용

따라서 읽기 작업이 변경 작업을 무조건 기다리지 않아도 된다.

3. Lock과 MVCC 비교

구분	Lock 기반	MVCC
읽기 기준	Current Read 중심	Consistent Read
데이터 기준	최신 데이터	특정 시점 데이터
읽기/쓰기 충돌	대기 발생 가능	충돌 감소
동시성	상대적으로 낮음	상대적으로 높음
주요 문제	Blocking, Deadlock	Undo·Version 관리

두 방식의 가장 중요한 차이는 데이터를 어떤 시점 기준으로 읽는가에 있다.

IV. 트랜잭션 격리 수준과 읽기 일관성

트랜잭션 격리 수준은 다른 트랜잭션의 변경 결과를 어느 수준까지 볼 것인지를 결정한다.

대표적인 격리 수준은 다음과 같다.

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read
Read Uncommitted	가능	가능	가능
Read Committed	방지	가능	가능
Repeatable Read	방지	방지	가능
Serializable	방지	방지	방지

격리 수준이 높아질수록 데이터 일관성은 강화되지만 동시성은 낮아질 수 있다. 따라서 모든 시스템에서 가장 높은 격리 수준을 사용하는 것이 최선은 아니다.

업무 특성에 따라 다음 요소를 고려해야 한다.

데이터 정합성 중요도
동시 사용자 수
변경 빈도
Lock 대기 가능성
트랜잭션 처리 시간

Read Committed의 특징

Read Committed에서는 커밋된 데이터만 읽을 수 있다. 따라서 Dirty Read는 방지할 수 있다. 하지만 동일한 트랜잭션에서 데이터를 두 번 조회했을 때 결과가 달라질 수 있다.

트랜잭션1 (TX1)	트랜잭션 2(TX2)
– SELECT 3000 – – SELECT 3500	– UPDATE 3500 – COMMIT

즉, Read Committed는 커밋 되지 않은 데이터는 보지 않지만, 트랜잭션 전체에서 동일한 결과를 항상 보장하지는 않는다.

V. UPDATE와 읽기 방식: Consistent Read와 Current Read

UPDATE 문은 단순히 데이터를 변경하는 하나의 작업처럼 보이지만 실제로는 두 가지 과정으로 나누어 생각할 수 있다.

UPDATE 대상 식별 🡪 실제 데이터 변경

이 과정에서 DBMS별 차이가 발생한다.

1. Lock 기반 UPDATE

Lock 기반 방식은 일반적으로 다음과 같이 동작한다.

Current 데이터 읽기 🡪 조건 확인 🡪 Lock 획득 🡪 UPDATE

즉, 최신 데이터를 기준으로 UPDATE 대상을 판단한다.
대량 UPDATE 중 다른 트랜잭션이 아직 처리되지 않은 데이터를 변경하면 실행 결과에 영향을 줄 수 있다.

2. MVCC 기반 UPDATE

Oracle과 PostgreSQL은 일반적으로 UPDATE 대상 식별과 실제 변경 과정에서 서로 다른 읽기 방식을 사용한다.

① Consistent Read : UPDATE 대상 식별
② Current Read : 실제 UPDATE 수행

즉, 대상은 일관된 시점의 데이터를 기준으로 찾고, 실제 변경은 최신 데이터를 기준으로 수행한다.
이러한 구조는 MVCC 기반 DBMS의 UPDATE 동작을 이해하는 핵심이다.

VI. Oracle Restart Mechanism

Oracle의 동시성 제어에서 중요한 특징 중 하나가Restart Mechanism(재시작 메커니즘)이다.

예를 들어, 최초 부서 20이고 7566번 사원(EMPNO)의 급여(SAL)는 2,975 이다.

<TX1>		<TX2>
UPDATE EMP SET SAL = SAL +200 WHERE EMPNO = 7566;	t1
	t2	UPDATE EMP SET SAL = SAL + 100 WHERE DEPTNO = 20 AND SAL <= 3000;
COMMIT;	t3
	t4	COMMIT;

위의 표는 트랜잭션 처리 SQL 스크립트이다. TX2의 Update가 7566번 사원레코드에 도달하는 순간, SAL 값이 3,175(=2,975+200)로 변경되어 더 이상 Update 조건을 만족하지 않는다.

이 때, PostgreSQL DB는 7566번 사원에 대해 Update 를 실패하더라도 다음 레코드로 계속 진행한다. 반면, Oracle DB는 t2 시점의 Update를 롤백하고 처음부터 업데이트를 다시 시작한다. 위의 결과는 같지만 내부적으로 처리하는 메커니즘은 다르다는 것을 알 수 있다.

즉, Oracle은 단순히 최신 데이터를 읽고 다음 작업을 계속하는 것이 아니라 UPDATE 문장이 일관된 기준으로 수행되도록 재시작 한다.

Oracle과 PostgreSQL의 차이

동시 UPDATE 상황에서 두 DBMS의 처리 방식 차이를 설명한다.

PostgreSQL는 변경된 레코드 처리 🡪 이후 작업 계속 진행

반면 Oracle은 조건절 의미에 영향을 주는 변경이 발생하면 다음과 같이 처리할 수 있다.

기존 UPDATE 작업 -> Rollback 🡪 Restart 🡪 다시 대상 검색

이것이 Oracle의 문장 수준 쓰기 일관성을 이해하는 중요한 특징이다.

VII. 문장 수준과 트랜잭션 수준 일관성

문장 수준에서 일관성이 보장된다고 해서 트랜잭션 전체의 일관성이 보장되는 것은 아니다.

트랜잭션1 (TX1)	트랜잭션 2(TX2)
– SELECT A – SELECT B	– 다른 트랜잭션이 변경

각 SQL 문장은 정상적으로 실행될 수 있다. 하지만 두 SQL 사이에 다른 트랜잭션이 데이터를 변경하면 트랜잭션 전체 관점에서는 서로 다른 시점의 데이터를 볼 수 있다.
따라서 다음은 서로 다른 개념이다.

문장 수준 일관성 ≠ 트랜잭션 수준 일관성

특히 MVCC 환경에서도 Write Skew와 같은 문제가 발생할 수 있다. 따라서 MVCC가 모든 데이터 정합성을 자동으로 보장하는 것은 아니다.

VIII. 실무 동시성 제어 전략

1. 비관적 동시성 제어

비관적 동시성 제어는 다음과 같이 가정한다. 동일 데이터를 동시에 변경할 가능성이 높다.

따라서 데이터를 읽을 때부터 Lock을 획득한다.

특징

충돌 가능성이 높은 업무에 적합
데이터 변경을 강하게 제어
Blocking과 Deadlock 가능성 존재

대표적인 적용 업무는 다음과 같다.

재고 관리
좌석 예약
금융 거래

2. 낙관적 동시성 제어

낙관적 동시성 제어는 데이터 충돌이 자주 발생하지 않는다고 가정한다.
조회 시에는 Lock을 설정하지 않는다. 대신 UPDATE 시점에 데이터 변경 여부를 확인한다.

정상적으로 변경되면: 1 Row Updated
다른 사용자가 먼저 변경했다면: 0 Rows Updated

이 경우 프로그램은 최신 데이터를 다시 조회하거나 사용자에게 변경 사실을 알려줄 수 있다.

비관적 vs 낙관적 동시성 제어

구분	비관적	낙관적
충돌 가정	높음	낮음
조회 시 Lock	사용	사용하지 않음
충돌 발생	대기	변경 실패
동시성	낮음	높음
대표 방식	FOR UPDATE	VERSION
적합 환경	재고·예약	일반 서비스

중요한 것은 하나의 방법을 모든 업무에 적용하지 않는 것이다.업무 특성과 데이터 충돌 가능성을 기준으로 적절한 전략을 선택해야 한다.

IX. 결론

트랜잭션 동시성 제어는 단순히 Lock을 사용하는 기술이 아니다. 동일한 SQL이라도 DBMS에 따라 데이터를 읽고 변경하는 방식이 달라질 수 있다. Lock 기반 DBMS는 일반적으로 최신 데이터를 기준으로 처리하며 Lock을 통해 동시 변경을 제어한다.

반면 MVCC 기반 DBMS는 여러 버전의 데이터를 활용하여 읽기와 쓰기 사이의 충돌을 줄인다. 특히 Oracle은 Consistent Read와 Current Read를 함께 사용하며, UPDATE 수행 중 조건의 의미가 달라질 경우 Restart Mechanism을 통해 SQL을 다시 시작할 수 있다.

하지만 MVCC를 사용한다고 해서 모든 동시성 문제가 자동으로 해결되는 것은 아니다.

실제 시스템에서는 다음 요소를 함께 고려해야 한다.

업무 규칙
데이터 변경 빈도
동시 사용자 수
트랜잭션 범위
충돌 가능성
DBMS의 동시성 제어 방식
적절한 격리 수준

결국 좋은 동시성 제어 전략은 다음 두 가지 사이에서 균형을 찾는 것이다.

“데이터 일관성과 시스템 동시성”

데이터 정합성을 높이기 위해 무조건 강한 Lock을 사용하는 것도, 성능을 위해 무조건 동시성을 높이는 것도 정답은 아니다.
업무 특성과 DBMS의 내부 동작을 이해하고 상황에 맞는 동시성 제어 전략을 선택하는 것이 중요하다.

참고 자료

「DB 트랜잭션 동시성 제어」, 조시형 저자
Oracle Database Documentation
PostgreSQL Documentation
Microsoft SQL Server Documentation
MySQL InnoDB Documentation

본 글은 「DB 트랜잭션 동시성 제어」 자료의 주요 개념과 사례를 기반으로 재구성하였습니다.