데이터베이스와 동시성 제어

 

 

트랜잭션의 역할

트랜잭션이란

트랜잭션은 여러 개의 조회나 쓰기를 논리적으로 하나의 연산으로 묶는 데이터베이스의 핵심 기능입니다.
데이터를 다루는 과정에서 발생할 수 있는 다양한 동시성 문제를 처리해줍니다.

 

트랜잭션의 핵심 원칙

원자성 (Atomicity)

• 하나의 트랜잭션에 포함된 모든 쓰기는 모두 적용되거나(커밋) 모두 취소(롤백)됩니다
• 트랜잭션 안의 쿼리 중 하나라도 실패하면 전체 트랜잭션을 롤백함으로써 데이터가 깨지는 것을 방지할 수 있습니다

 

BEGIN;
    -- 여러 작업이 하나의 논리적 단위
    UPDATE account SET balance = balance - 1000 WHERE user_id = 1;
    UPDATE account SET balance = balance + 1000 WHERE user_id = 2;
COMMIT;  -- 모두 성공하거나, 하나라도 실패하면 모두 롤백

 

격리성 (Isolation)

• 동시에 실행되는 여러 트랜잭션이 서로 간섭하지 않도록 격리합니다
• 트랜잭션은 마치 혼자 데이터베이스를 사용하는 것처럼 동작합니다

 

 

동시성 문제의 유형

1. Lost Update (갱신 손실)

가장 흔하고 치명적인 문제입니다.
두 개의 트랜잭션이 같은 데이터를 읽고 수정할 때, 나중에 실행된 트랜잭션이 먼저 실행된 트랜잭션의 변경을 덮어씁니다.

# 사용자 A의 포인트 1000P에서 동시에 적립(+500P)과 차감(-300P) 발생
# 초기: 1000P

시간 | 적립 트랜잭션 (+500)    | 차감 트랜잭션 (-300)
-----|------------------------|-------------------------
T1   | SELECT point = 1000    |
T2   |                        | SELECT point = 1000
T3   | 계산: 1000 + 500        |
T4   |                        | 계산: 1000 - 300
T5   | UPDATE point = 1500    |
T6   |                        | UPDATE point = 700 (덮어씀!)

# 결과: 700P (기대: 1200P) → 500P 손실

2. Dirty Read (오손 읽기)

커밋되지 않은 다른 트랜잭션의 변경사항을 읽는 문제입니다.

3. Non-Repeatable Read (반복 불가능 읽기)

같은 트랜잭션 내에서 같은 데이터를 두 번 읽었을 때 다른 결과가 나오는 문제입니다.

4. Phantom Read (유령 읽기)

같은 조건으로 조회했을 때 이전에 없던 행이 나타나거나 있던 행이 사라지는 문제입니다.

 

 

 

트랜잭션 격리 수준

PostgreSQL은 4가지 격리 수준을 제공하여 동시성과 정합성의 균형을 조절할 수 있습니다.

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	특징
READ UNCOMMITTED	가능	가능	가능	PostgreSQL에서는 READ COMMITTED처럼 동작
READ COMMITTED	방지	가능	가능	PostgreSQL 기본값, 커밋된 데이터만 읽음
REPEATABLE READ	방지	방지	방지	트랜잭션 시작 시점의 스냅샷 사용
SERIALIZABLE	방지	방지	방지	완전한 격리, 성능 저하

-- 격리 수준 설정
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 작업 수행
COMMIT;

 

 

격리 수준만으로 해결되지 않는 문제

격리 수준을 높여도 Lost Update 문제는 완전히 해결되지 않습니다. 이를 위해 명시적인 잠금 기법이 필요합니다.

 

 

 

동시성 제어 전략

데이터베이스는 동시성 제어를 위해 크게 두 가지 잠금 방식을 제공합니다.

1. 비관적 잠금 (Pessimistic Lock)

개념

선점 잠금이라고도 하며, 데이터를 읽는 순간 잠금을 획득하여 다른 트랜잭션의 접근을 차단하는 방식입니다. "충돌이 발생할 것이다"라고 비관적으로 가정하고 미리 잠금을 겁니다.

동작 원리

1. 트랜잭션 1이 먼저 데이터에 대한 잠금을 구하고,
2. 트랜잭션 2는 트랜잭션 1이 끝난 뒤에 완료해서 잠금을 반환할 때까지 대기하여 일관성이 깨지는 문제를 방지.

 

 

1. 주문 취소 트랜잭션이 먼저 주문 상태를 취소 상태로 변경.
2. 배송 시작 트랜잭션이 주문 데이터를 조회하면 취소된 상태이므로, 배송 시작 실패

 

 

 

FOR UPDATE 옵션

-- 포인트 적립
BEGIN;

-- 1. 행 잠금 획득 (다른 트랜잭션은 대기)
SELECT balance FROM point 
WHERE user_id = 1 
FOR UPDATE;  -- 다른 트랜잭션 차단

-- 2. 안전하게 업데이트 (독점 상태)
UPDATE point 
SET balance = balance + 500 
WHERE user_id = 1
RETURNING balance;

INSERT INTO point_history (user_id, amount, reason, balance_after)
VALUES (1, 500, '구매 적립', 1500);

COMMIT; -- 잠금 해제

 

명령어	설명	차단 대상
FOR UPDATE	쓰기 잠금	다른 모든 잠금 차단
FOR NO KEY UPDATE	외래 키 제외 쓰기 잠금	UPDATE 차단, 외래 키 참조는 허용
FOR SHARE	읽기 잠금	UPDATE/DELETE 차단, SELECT는 허용
FOR KEY SHARE	외래 키용 읽기 잠금	DELETE 차단, UPDATE는 허용

 

-- FOR UPDATE: 완전한 쓰기 잠금
SELECT * FROM orders WHERE order_id = 1 FOR UPDATE;

-- FOR SHARE: 읽기는 허용, 쓰기만 차단
SELECT * FROM products WHERE product_id = 1 FOR SHARE;

잠금 타임아웃 설정

-- 잠금 대기 시간 제한 (5초)
SET lock_timeout = '5s';

BEGIN;
SELECT * FROM account WHERE user_id = 1 FOR UPDATE;
-- 5초 이상 대기하면 예외 발생

 

장점

• 정합성 100% 보장: 동시 수정 불가능
• 구현이 단순: SELECT에 FOR UPDATE만 추가
• 예측 가능: 순차적으로 처리되어 결과 예측 가능

단점

• 대기 시간 증가: 동시 요청이 많으면 순차 대기
• 처리량 제한: 병렬 처리 불가능
• 데드락 위험: 여러 자원 잠금 시 순서 관리 필요

적합한 상황

• 재고 차감, 포인트 차감 등 정합성이 절대적으로 중요한 경우
• 결제 처리, 좌석 예약 등 충돌이 빈번하게 발생하는 경우
• 금전 거래, 회계 데이터 등 데이터 손실이 허용되지 않는 경우

 

 

2. 낙관적 잠금 (Optimistic Lock)

개념

비선점 잠금이라고도 하며, 잠금 없이 데이터를 읽고 수정할 때 값을 비교해서 수정하는 방식입니다.
"충돌이 거의 없을 것이다"라고 낙관적으로 가정하고 충돌이 발생하면 그때 처리합니다.

 

동작 원리

1. 비선점 잠금은 우선 데이터 변경을 시도
2. 조회한 버전 값을 비교해서 데이터가 변경되지 않았는지를 확인하고 커밋하거나 롤백 실행

 

 

 

 

PostgreSQL 구현

낙관적 잠금의 핵심은 쿼리 실행을 막지 않으면서 데이터가 잘못 변경되는 것을 방지한다는 점!

-- 포인트 적립
BEGIN;

-- 현재 버전 조회 (잠금 없음)
SELECT balance, version FROM point WHERE user_id = 1;
-- 결과: balance=1000, version=5

-- 버전 확인하며 업데이트
UPDATE point 
SET balance = balance + 500,
    version = version + 1
WHERE user_id = 1 
  AND version = 5;  -- 버전 불일치 시 실패 → 재시도

INSERT INTO point_history (user_id, amount, reason, balance_after)
VALUES (1, 500, '구매 적립', 1500);

COMMIT;​

-- 비관적 잠금: SELECT 시점에 다른 트랜잭션 차단
SELECT * FROM account WHERE user_id = 1 FOR UPDATE;
-- ↑ 다른 트랜잭션은 여기서 대기

-- 낙관적 잠금: SELECT는 모두 허용
SELECT * FROM account WHERE user_id = 1;
-- ↑ 여러 트랜잭션이 동시 조회 가능
-- UPDATE 시점에만 version으로 검증

 

 

 

재시도 로직 (필수)

충돌 발생 시 재시도 로직이 반드시 필요합니다.

-- 애플리케이션 레벨 재시도 로직 예시
DO $$
DECLARE
    retry_count INT := 0;
    max_retries INT := 3;
    rows_affected INT;
    current_version BIGINT;
    current_balance INT;
BEGIN
    LOOP
        -- 현재 값 조회
        SELECT balance, version INTO current_balance, current_version
        FROM account WHERE user_id = 1;
        
        -- 업데이트 시도
        UPDATE account 
        SET balance = current_balance - 300,
            version = version + 1
        WHERE user_id = 1 
          AND version = current_version;
        
        GET DIAGNOSTICS rows_affected = ROW_COUNT;
        
        IF rows_affected > 0 THEN
            EXIT;  -- 성공 시 종료
        END IF;
        
        -- 재시도 카운트 증가
        retry_count := retry_count + 1;
        IF retry_count >= max_retries THEN
            RAISE EXCEPTION '최대 재시도 횟수 초과';
        END IF;
        
        -- 짧은 대기 후 재시도
        PERFORM pg_sleep(0.01 * retry_count);  -- 지수 백오프
    END LOOP;
END $$;

 

장점

• 높은 동시성: 잠금 대기 없이 병렬 처리 가능
• 읽기 성능 우수: SELECT 시 잠금 획득 불필요
• 데드락 없음: 잠금을 사용하지 않아 데드락 발생 안 함

단점

• 재시도 로직 필수: 충돌 시 애플리케이션 레벨 처리 필요
• version 관리: 별도 컬럼 추가 및 관리 필요
• 충돌 빈번 시 비효율: 재시도가 많아지면 오히려 성능 저하

적합한 상황

• 게시물 조회수, 좋아요 등 충돌이 적고 가끔 실패해도 괜찮은 경우
• 통계 데이터, 캐시 갱신 등 정합성보다 성능이 중요한 경우
• 읽기가 많고 쓰기가 적은 경우

 

 

3. 원자적 연산 (추가 전략)

개념

SELECT 없이 UPDATE 문에서 직접 계산하여 읽기-쓰기 갭을 원천적으로 제거하는 방식입니다. 데이터베이스 엔진이 내부적으로 동시성을 보장합니다.

 

PostgreSQL 구현

-- 읽기 없이 바로 업데이트
BEGIN;

UPDATE point 
SET balance = balance + 500 
WHERE user_id = 1
RETURNING balance; -- 업데이트 후 값 반환 필수!

INSERT INTO point_history (user_id, amount, reason, balance_after)
VALUES (1, 500, '구매 적립', 1500);

COMMIT;​

 

장점

• 가장 안전하고 빠름: 내부적으로 동시성 보장
• 코드 간결: 추가 로직 불필요
• 잠금 불필요: 데이터베이스가 알아서 처리

단점

• 단순 연산만 가능: 복잡한 계산이나 조건 처리 불가
• 결과값 필요 시: RETURNING 절 사용 필수

 

 

 

 

데드락 (Deadlock) 방지

데드락이란

두 개 이상의 트랜잭션이 서로가 보유한 잠금을 기다리며 무한 대기 상태에 빠지는 현상입니다.

트랜잭션 A              트랜잭션 B
-----------------      -----------------
잠금(자원1)            잠금(자원2)
대기(자원2) ←-------→  대기(자원1)

 

 

데드락 발생 예시

-- 트랜잭션 A
BEGIN;
UPDATE account SET balance = balance - 100 WHERE user_id = 1;
UPDATE account SET balance = balance + 100 WHERE user_id = 2;  -- 대기
COMMIT;

-- 트랜잭션 B (동시 실행)
BEGIN;
UPDATE account SET balance = balance - 100 WHERE user_id = 2;
UPDATE account SET balance = balance + 100 WHERE user_id = 1;  -- 데드락!
COMMIT;

 

 

 

데드락 방지 전략

1. 잠금 순서 통일

여러 자원을 잠글 때 항상 같은 순서로 잠금을 획득합니다.

-- ✅ 올바른 예: user_id 오름차순으로 잠금
BEGIN;
SELECT * FROM account 
WHERE user_id IN (1, 2) 
ORDER BY user_id ASC  -- 항상 작은 번호부터
FOR UPDATE;

UPDATE account SET balance = balance - 100 WHERE user_id = 1;
UPDATE account SET balance = balance + 100 WHERE user_id = 2;
COMMIT;

 

 

2. 타임아웃 설정

-- 데드락 감지 시간 설정 (기본 1초)
SET deadlock_timeout = '1s';

-- 잠금 대기 최대 시간 설정
SET lock_timeout = '5s';

 

 

3. 트랜잭션 시간 최소화

-- ❌ 나쁜 예: 트랜잭션 안에서 외부 API 호출
BEGIN;
SELECT * FROM orders WHERE order_id = 1 FOR UPDATE;
-- 외부 결제 API 호출S (3초 소요)
UPDATE orders SET status = 'paid';
COMMIT;

-- ✅ 좋은 예: 트랜잭션 전에 외부 작업 완료
-- 외부 결제 API 호출
BEGIN;
SELECT * FROM orders WHERE order_id = 1 FOR UPDATE;
UPDATE orders SET status = 'paid';
COMMIT;

 

 

 

 

 

실무 적용 시나리오

시나리오 1: 포인트 차감 (비관적 잠금 필수)

BEGIN;

-- 1. 포인트 조회 및 잠금 획득 (다른 트랜잭션 차단)
SELECT user_id, balance 
FROM point 
WHERE user_id = 1 
FOR UPDATE;
-- 결과: balance = 10000

-- 2. 잔액 확인 및 차감
UPDATE point 
SET balance = balance - 5000,
    updated_at = CURRENT_TIMESTAMP 
WHERE user_id = 1 
  AND balance >= 5000;  -- 잔액 부족 방지

-- 3. 업데이트 실패 시 예외 처리
IF NOT FOUND THEN
    ROLLBACK;
    RAISE EXCEPTION '포인트 잔액이 부족합니다';
END IF;

-- 4. 차감 이력 저장
INSERT INTO point_history (user_id, amount, reason, balance_after)
SELECT 1, -5000, '상품 구매 (주문번호: ORD-12345)', balance 
FROM point 
WHERE user_id = 1;

COMMIT;  -- 잠금 해제
-- 다른 트랜잭션은 잠금 해제까지 대기하므로 동시 차감 시에도 정합성 보장

 

 

시나리오 2: 조회수 증가 (낙관적 잠금 또는 원자적 연산)

-- 방법 1: 원자적 연산 (권장)
UPDATE posts 
SET view_count = view_count + 1 
WHERE post_id = 1;

-- 방법 2: 낙관적 잠금
UPDATE posts 
SET view_count = view_count + 1,
    version = version + 1 
WHERE post_id = 1 
  AND version = 5;

 

 

시나리오 3: 유저 간 포인트 이동(순서 보장)

핵심 포인트:

• 순서 보장: ORDER BY user_id ASC : 모든 트랜잭션이 동일한 순서(작은 번호 → 큰 번호)로 잠금 획득
• 여러 행을 한 번에 잠금: WHERE user_id IN (1, 2)로 필요한 모든 행을 먼저

BEGIN;

-- 1. user_id 오름차순으로 잠금 획득 (데드락 방지)
SELECT user_id, balance 
FROM point 
WHERE user_id IN (1, 2) 
ORDER BY user_id ASC  -- 항상 작은 번호부터 잠금
FOR UPDATE;

-- 2. 송신자(A) 잔액 확인
DECLARE
    sender_balance INT;
BEGIN
    SELECT balance INTO sender_balance 
    FROM point 
    WHERE user_id = 1;
    
    IF sender_balance < 1000 THEN
        RAISE EXCEPTION '송신자의 포인트 잔액이 부족합니다';
    END IF;
END;

-- 3. 송신자(A) 차감
UPDATE point 
SET balance = balance - 1000,
    updated_at = CURRENT_TIMESTAMP 
WHERE user_id = 1;

INSERT INTO point_history (user_id, amount, reason, balance_after)
SELECT 1, -1000, '포인트 선물 (받는 사람: user_2)', balance 
FROM point 
WHERE user_id = 1;

-- 4. 수신자(B) 적립
UPDATE point 
SET balance = balance + 1000,
    updated_at = CURRENT_TIMESTAMP 
WHERE user_id = 2;

INSERT INTO point_history (user_id, amount, reason, balance_after)
SELECT 2, 1000, '포인트 선물 받음 (보낸 사람: user_1)', balance 
FROM point 
WHERE user_id = 2;

COMMIT;

[데드락 발생]
트랜잭션 A        트랜잭션 B
잠금(user_1)      잠금(user_2)
대기(user_2) ←-→  대기(user_1)  ← 데드락!

[순서 보장으로 방지]
트랜잭션 A               트랜잭션 B
잠금(user_1, user_2)    대기...
작업 완료                대기...
잠금 해제                잠금(user_1, user_2)
                       작업 완료
                       잠금 해제

 

 

결론

1. 트랜잭션은 여러 쿼리를 하나의 논리적 단위로 묶어 동시성 문제를 처리합니다
2. 하나의 트랜잭션은 모두 성공하거나 모두 실패합니다 (원자성)
3. 격리 수준만으로는 Lost Update 문제를 완전히 해결할 수 없습니다
4. 비관적 잠금(선점 잠금)은 데이터를 읽는 순간 잠금을 걸어 충돌을 방지합니다
5. 낙관적 잠금(비선점 잠금)은 쿼리 실행 자체는 막지 않으면서 version 비교로 데이터 변경을 방지합니다
6. 정합성이 중요하면 비관적 잠금, 성능이 중요하고 충돌이 적으면 낙관적 잠금을 사용합니다

 

 

 

DB 레벨의 동시성 제어 외에도, 시스템 안정성과 실무 유연성을 위해 다른 관점들도 함께 고려해보아야 한다!
예를들면 애플리케이션 레벨 락 (Java/Spring 기반), 분산 락 시스템 등
트래픽이 많이 발생하는 실서비스에서는 DB 락만으로는 부족한 경우가 많아,
위와 같이 다계층 동시성 전략을 함께 설계하는 방법도 중요함.