−두 편집기가 같은 글의 버전 0을 읽었다. A가 먼저 저장했는데 B가 옛 본문을 그대로 저장하면 A의 수정이 사라질 수 있다. 동시성 제어는 이처럼 겹쳐 진행되는 작업이 어떤 순서와 조건으로 공유 데이터를 바꿀지 정한다. 여기서는 먼저 작업할 권리를 확보하는 잠금과, 저장할 때 읽어둔 버전을 검사하는 방법을 비교한다.
잠금의 규칙과 낙관적 검증의 역사
Eswaran·Gray·Lorie·Traiger의 1976년 논문은 트랜잭션·일관성·실행 순서를 형식화하고, 잠금 프로토콜과 논리적 조건으로 지정한 데이터 집합의 보호를 다뤘다. 1974년 IBM 연구 보고서 선행본도 있으므로 1976년을 잠금이나 트랜잭션의 최초 발명년으로 단정할 수는 없다.[각주 1]
Kung과 Robinson은 1981년 논문에서 지역 복사본을 다루는 읽기 단계, 충돌을 확인하는 검증 단계, 변경을 반영하는 쓰기 단계를 설명했다. 읽기·쓰기 집합으로 트랜잭션의 충돌을 검증하는 알고리즘이다. 웹 API에서 자주 쓰는 한 행의 버전 검사는 이 생각을 작은 범위에 적용하지만, 논문의 전체 검증 알고리즘을 구현한 것과는 구별한다.[각주 2]
두 방식의 차이는 “잠금이 있느냐 없느냐”로만 설명하기 어렵다. 낙관적 조건부 갱신도 DB 내부에서는 쓰기 잠금을 사용할 수 있고, 원논문 역시 검증과 쓰기의 임계구역을 다룬다. 애플리케이션이 충돌을 언제 발견하고 사용자에게 어떤 선택을 돌려주는지가 중요한 차이다.
비교와 쓰기를 한 문장에 넣기
다음 PostgreSQL 예제는 한 글을 버전 0에서 1로 바꾼 뒤, 버전 0을 들고 온 다른 수정 요청을 거절한다. 순서가 정해진 두 쓰기로 오래된 요청의 처리 계약을 확인한다.
CREATE TEMP TABLE posts (
id integer PRIMARY KEY,
body text NOT NULL,
version bigint NOT NULL CHECK (version >= 0)
);
INSERT INTO posts VALUES (1, 'original', 0);
UPDATE posts
SET body = 'edited by A', version = version + 1
WHERE id = 1 AND version = 0
RETURNING body, version;
UPDATE posts
SET body = 'edited by B', version = version + 1
WHERE id = 1 AND version = 0
RETURNING body, version;
SELECT body, version FROM posts WHERE id = 1;
첫 갱신은 edited by A, 1을 반환하고 두 번째는 0행을 반환한다. 최종 내용은 A의 수정이다. 호출자는 0행을 성공으로 처리하지 말고 “없거나, 읽어둔 버전과 맞지 않는다”는 사전조건 실패로 알려야 한다. 두 경우를 따로 구별하려면 추가 조회의 시점과 정보 노출 정책도 정한다.
버전을 먼저 조회한 뒤 조건 없는 UPDATE를 보내면 두 문장 사이에 다른 요청이 끼어들 수 있다. 위처럼 저장 문장의 WHERE에 조건을 넣어 DB가 비교와 변경을 함께 처리하도록 한다. HTTP의 ETag와 If-Match도 읽은 표현이 여전히 일치할 때만 변경한다는 조건을 전달하는 방법이며, 서버는 그 조건을 실제 저장까지 연결해야 한다.[각주 3]
먼저 잠그고 작업한다면
PostgreSQL에서 트랜잭션 안의 SELECT ... FOR UPDATE는 선택한 행을 잠가 충돌하는 갱신이나 잠금 획득을 기다리게 할 수 있다. 잠금은 트랜잭션이 끝날 때 해제된다. 일반 스냅샷 SELECT까지 모두 막는 잠금은 아니므로, 무엇이 기다리는지 구별해서 읽어야 한다.[각주 4]
이 방식은 짧은 트랜잭션 안에서 같은 대상을 검사하고 바꿀 때 유용하다. 사람이 편집하는 몇 분 동안 DB 잠금을 계속 잡는 대신, 편집 완료 시 버전을 검사해 충돌을 보여주는 방식이 더 어울리는 상황도 있다. 이는 사용자 대기 시간과 충돌 처리 방식을 고르는 문제이며, 어느 방식이 항상 빠르다는 결론은 데이터와 부하 측정 없이 낼 수 없다.
한 행 밖의 규칙은 누가 지킬까
자원 7의 예약이 아직 없다면 WHERE resource = 7 FOR UPDATE는 잠글 기존 행도 찾지 못한다. 두 트랜잭션이 모두 0행을 읽고 각각 예약을 넣을 수 있으므로, PostgreSQL의 행 잠금을 “앞으로 생길 행까지 잠근다”고 이해하면 규칙에 빈틈이 생긴다. 자원당 예약 하나가 정확한 규칙이라면 UNIQUE(resource)가 이를 직접 표현한다. 여러 행의 합계나 조회 조건이 규칙이라면 대표 행의 잠금, 적합한 제약, 직렬가능한 실행 등 그 규칙에 맞는 보호가 필요하다.[각주 1][각주 4]
버전 검사에도 수명 조건이 있다. 글을 삭제하고 같은 ID·버전 0으로 다시 만들면, 예전 버전 0 요청이 새 글에 일치할 수 있다. 모든 쓰기가 버전을 올리는지, ID를 다시 쓰는지, 다른 행까지 읽은 판단을 무엇이 검증하는지 함께 확인한다. 멱등성이 같은 요청의 반복 효과를 다룬다면, 버전 검사는 그 요청이 어떤 상태를 기준으로 했는지 검사한다.
예제 환경: PostgreSQL 18. 한 행의 조건부 갱신을 보여주며 여러 행 전체의 직렬가능성을 증명하는 코드는 아니다.
+개요
동시성 제어(concurrency control)는 겹쳐 진행되는 작업이 공유 상태를 읽고 바꿀 때, 허용할 순서와 결과를 정하는 방법이다. 작업이 실제로 여러 CPU에서 같은 순간에 실행되는 병렬성뿐 아니라, 한 작업이 입출력을 기다리는 동안 다른 작업이 진행되는 상황도 포함한다.
편집자 A와 B가 같은 글을 읽은 뒤 A가 먼저 고쳐 저장하고, 이후 B가 처음 읽은 내용을 바탕으로 저장하면 A의 수정이 사라진다. 데이터베이스의 재고나 예약에서도 같은 일이 생긴다. 작업 하나하나는 올바른 절차를 따라도, 서로 끼어드는 순서에 따라 전체 규칙이 깨질 수 있다.
이를 다루려면 무엇을 한 번의 작업으로 보고, 어떤 데이터를 공유하며, 어느 결과를 올바른 것으로 받아들일지 정해야 한다. 한 변수의 원자적 갱신, 한 행의 버전 검사, 여러 행을 읽는 트랜잭션의 직렬가능성은 보호하는 범위가 다르다.
이 문서는 데이터베이스 동시성 제어를 중심으로, 잠금·낙관적 검증·다중 버전이 이어져 온 계보와 서로의 관계를 다룬다. 운영체제의 mutex나 언어의 원자 연산도 공유 상태를 조정하지만, DB 트랜잭션과 같은 경계와 실패 모델을 갖지는 않는다.
연혁
1976년: Eswaran·Gray·Lorie·Traiger가 「The Notions of Consistency and Predicate Locks in a Database System」에서 트랜잭션·일관성·스케줄을 정의하고, 이 개념들과 2단계 잠금의 관계를 분석했다. 물리적인 레코드와 조건으로 선택한 데이터 집합의 차이도 같은 논문에서 다뤘다.[각주 1]
1981년: Kung과 Robinson이 「On Optimistic Methods for Concurrency Control」에서 작업을 먼저 진행하고 충돌은 나중에 검증하는 낙관적 방법을 제시했다.[각주 2]
1983년: Philip A. Bernstein과 Nathan Goodman이 「Multiversion Concurrency Control—Theory and Algorithms」에서 다중 버전 스케줄의 정확성을 설명하고 여러 알고리즘을 다뤘다. 여러 버전을 쓰는 실행을 하나의 이론으로 정리한 기록이며, MVCC의 최초 발명일을 확정하는 자료는 아니다.[각주 3]
1995년: Berenson 등이 「A Critique of ANSI SQL Isolation Levels」에서 SQL 격리 수준의 정의와 스냅샷 격리를 분석하고, 스냅샷 격리에서 생기는 쓰기 왜곡을 사례로 들었다.[각주 4]
1997년 1월: HTTP/1.1의 RFC 2068이 If-Match를 정의하고, 읽은 뒤 바뀐 자원을 잘못 수정하지 않도록 요청에 엔터티 태그를 넣는 용도를 설명했다.[각주 5]
2022년: RFC 9110이 If-Match 조건의 의미를 규정했다.[각주 6]
잠금 규칙과 보호 대상 (1976)
Eswaran·Gray·Lorie·Traiger의 1976년 논문이 다룬 다중 사용자 DB에서는 읽기와 쓰기가 섞이는 순서부터 분석해야 한다. 순서가 달라져도 무결성을 지키려면 “여기에 잠금을 건다”는 결정만으로는 모자라고, 잠금을 얻고 놓는 규칙이 함께 있어야 한다. 2단계 잠금에서는 잠금을 늘리는 단계에서 줄이는 단계로 넘어간 뒤 새 잠금을 얻지 않는다.[각주 1]
Eswaran 등이 구분한 물리적인 레코드와 조건으로 선택한 데이터 집합은 예약을 예로 들면 구별하기 쉽다. “이미 존재하는 예약 행”과 “이 날짜에 생길 수 있는 예약”은 서로 다른 보호 대상이다. 동시성 제어가 지킬 범위를 논리적 규칙에서 읽어야 한다는 문제는 이 시기에 분명하게 드러났다.
낙관적 검증 (1981)
Kung과 Robinson이 1981년에 제시한 낙관적 방법에서 작업은 읽기·검증·쓰기 단계를 거치고, 어떤 실행을 허용할지는 작업들의 읽기·쓰기 집합 사이의 관계로 정한다. 충돌이 드물면 미리 기다리는 비용을 줄일 여지가 있지만, 검증에 실패한 작업은 버려진다. 낙관적이라는 이름은 성공을 가정하고 검증 시점까지 진행하는 운영 방식에서 나왔다.[각주 2]
웹 편집기의 버전 검사는 이 생각을 한 행에 적용한 예다. 저장하려는 행의 버전이 읽어둔 값과 같을 때만 변경하며, 논문의 전체 트랜잭션 검증 알고리즘보다 좁은 범위를 보호한다.
다중 버전의 이론화 (1983)
Bernstein과 Goodman의 1983년 논문은 다중 버전 스케줄의 정확성을 설명하고 새 알고리즘과 기존 알고리즘을 같은 이론으로 분석했다. 읽는 작업에 필요한 이전 버전을 남겨 두면 쓰기와 읽기 사이의 대기 관계가 달라진다. 어느 버전을 읽게 하고 어떤 실행을 거절할지는 별도의 규칙이므로, 버전을 보관하는 일과 직렬가능성의 조건은 나눠서 봐야 한다.[각주 3]
오늘날의 제품은 여러 기법을 함께 쓴다. MVCC DB가 쓰기 충돌에는 잠금을 쓰기도 하고, 애플리케이션의 낙관적 검사가 DB 내부의 쓰기 잠금과 함께 작동할 수도 있다.
스냅샷 격리와 쓰기 왜곡 (1995)
Berenson 등이 1995년에 분석한 쓰기 왜곡은 스냅샷 격리와 직렬가능성이 갈라지는 지점을 보여준다. 두 작업이 같은 스냅샷을 읽더라도 서로 다른 행을 바꾸면 전체 규칙이 깨질 수 있다.[각주 4]
한 행의 갱신 유실을 막는 일과 여러 행에 걸친 규칙을 지키는 일은 서로 다르다. 모든 행이 자기 버전 검사를 통과하더라도, 함께 읽은 조건이 더는 유지되지 않으면 업무의 결과가 달라질 수 있다. 그래서 잠금·검증·버전이라는 구현 이름보다, 어떤 작업 집합의 결과를 어떤 직렬 실행과 같게 만들지가 더 근본적인 질문이다.
HTTP 조건부 요청 (1997–2022)
1997년 RFC 2068은 HTTP/1.1의 조건부 요청을 정의했고, 2022년 RFC 9110은 그 의미를 다시 규정했다. DB 내부의 동시성 이론과 HTTP 조건부 요청은 서로 다른 계층에서 오래된 관찰에 근거한 쓰기를 막는다. 요청에 If-Match 조건이 붙어 오면 서버는 그 조건을 실제 저장까지 연결해야 한다.[각주 6]
사람이 편집하는 시간 내내 DB 잠금을 잡아 두는 대신 저장 시점의 버전을 확인하는 UI도 이 관점으로 읽을 수 있다. 충돌이 난 뒤 기다릴지, 다시 조회할지, 사용자에게 병합을 요청할지는 애플리케이션이 결정한다.
PostgreSQL 행 잠금과 남는 보호 범위
PostgreSQL의 SELECT ... FOR UPDATE는 선택한 행에 대한 충돌하는 갱신을 조정하며, 이 잠금은 트랜잭션이 끝날 때까지 유지된다. 이 행 잠금은 일반 SELECT를 막지 않고, 같은 행을 갱신·삭제·잠금하려는 작업을 기다리게 한다. 서로의 잠금을 기다리면 교착상태가 생길 수도 있다.[각주 7]
예약이 없는 자원을 조회해 0행을 얻으면 잠글 예약 행도 없다. 이때는 고유 제약, 대표 자원 행의 잠금, 적합한 격리 규칙처럼 업무 조건에 맞는 보호를 골라야 한다. 현재 PostgreSQL도 MVCC 위에서 서로 다른 격리 수준을 제공한다.[각주 8][각주 7][각주 9]
잠금 규칙, 낙관적 검증, 다중 버전 이론, HTTP의 사전조건은 모두 공유 상태의 관찰과 변경을 연결하는 문제를 다룬다. 각 기법의 계약을 읽을 때 기준이 되는 것은 그 기법이 무엇을 보호 범위로 삼는지다.
한 행의 버전 조건 예제
아래 PostgreSQL 코드는 “읽은 버전과 같을 때만 저장한다”는 조건을 저장 문장에 넣는다. 순서를 고정한 두 갱신으로 오래된 수정이 거절되는지 확인한다.
CREATE TEMP TABLE posts (
id integer PRIMARY KEY,
body text NOT NULL,
version bigint NOT NULL
);
INSERT INTO posts VALUES (1, 'original', 0);
UPDATE posts
SET body = 'edited by A', version = version + 1
WHERE id = 1 AND version = 0
RETURNING body, version;
UPDATE posts
SET body = 'edited by B', version = version + 1
WHERE id = 1 AND version = 0
RETURNING body, version;
SELECT body, version FROM posts WHERE id = 1;
첫 갱신은 edited by A, 1을 반환하고 두 번째는 0행을 반환한다. 최종 본문은 A의 수정이다. 기본 격리 수준(READ COMMITTED)에서는 두 갱신이 실제로 겹쳐도 두 번째 갱신이 바뀐 행에 WHERE 조건을 다시 평가해 0행을 반환하므로, 호출자는 0행을 변경 성공과 구별해야 한다. REPEATABLE READ 이상에서 갱신이 겹치면 0행 대신 직렬화 오류가 날 수 있다. 이 예제의 검사는 한 행의 버전에 한정된다.
