A 계좌에서 100만원을 출금했는데 시스템이 B 계좌 입금 직전에 죽었습니다. 돈은 사라졌습니다. 트랜잭션이 없으면 이런 중간 상태가 DB에 그대로 남습니다. ACID는 이런 상황에서 "전부 성공하거나 전부 없던 일로 돌아가는" 것을 보장하는 4가지 속성입니다. 금융, 재고, 예약처럼 정확성이 중요한 시스템은 모두 이 보장에 의존합니다.

트랜잭션 기본 문법

트랜잭션은 BEGIN으로 시작해 COMMIT(확정) 또는 ROLLBACK(취소)으로 끝납니다. MySQL에서는 BEGIN 대신 START TRANSACTION을 사용하기도 합니다.

BEGIN;

UPDATE accounts SET balance = balance - 100000 WHERE id = 1;
UPDATE accounts SET balance = balance + 100000 WHERE id = 2;

COMMIT;

실행 완료 또는 조회 결과가 표시됩니다.

ACID 4가지 속성

ACID는 Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(내구성)의 약자입니다. 각 속성이 무엇을 보장하는지 은행 이체 예시로 살펴봅니다.

A — Atomicity (원자성): 전부 아니면 전무

원자성은 트랜잭션 내의 모든 작업이 하나의 단위로 처리된다는 보장입니다. 이체 중 서버가 다운되더라도 출금만 되고 입금이 안 되는 상황은 발생하지 않습니다. 두 작업이 모두 성공해야만 COMMIT되고, 하나라도 실패하면 전체가 ROLLBACK됩니다.

BEGIN;

UPDATE accounts
SET balance = balance - 100000
WHERE id = 1 AND balance >= 100000;

UPDATE accounts
SET balance = balance + 100000
WHERE id = 2;

COMMIT;

C — Consistency (일관성): 제약조건 항상 유지

일관성은 트랜잭션 실행 전후에 데이터베이스가 정의된 규칙(제약조건)을 항상 만족해야 한다는 보장입니다. 잔액이 음수가 되는 이체 시도는 CHECK 제약 위반으로 자동 롤백됩니다.

CREATE TABLE accounts (
    id      BIGINT PRIMARY KEY,
    name    VARCHAR(100) NOT NULL,
    balance NUMERIC(15, 2) NOT NULL DEFAULT 0,
    CONSTRAINT chk_balance_positive CHECK (balance >= 0)
);

BEGIN;
UPDATE accounts SET balance = balance - 1000000 WHERE id = 1;
COMMIT;

잔액이 음수가 되는 순간 CHECK 제약 위반으로 ERROR: new row for relation "accounts" violates check constraint "chk_balance_positive" 오류가 발생하고 트랜잭션이 롤백됩니다.

I — Isolation (격리성): 트랜잭션 간 간섭 방지

격리성은 동시에 실행 중인 트랜잭션들이 서로의 중간 상태를 볼 수 없도록 격리해야 한다는 보장입니다. 어느 정도까지 격리할지는 "격리 수준"으로 조정하며, 다음 섹션에서 자세히 다룹니다.

BEGIN;
UPDATE accounts SET balance = balance - 50000 WHERE id = 1;
-- 아직 COMMIT하지 않은 상태

SELECT balance FROM accounts WHERE id = 1;
-- 격리 수준에 따라 다른 트랜잭션에서 변경 전 값을 보거나 변경 후 값을 봄
COMMIT;

D — Durability (내구성): 커밋된 데이터는 영구 보존

내구성은 COMMIT된 데이터는 이후 시스템 장애(전원 차단, 서버 크래시)가 발생해도 손실되지 않는다는 보장입니다.

데이터베이스는 WAL(Write-Ahead Log) 메커니즘으로 내구성을 구현합니다. COMMIT 시 실제 데이터 파일을 수정하기 전에 변경 내용을 WAL 로그에 먼저 디스크에 기록합니다. 서버가 다운되더라도 재시작 시 WAL 로그를 재실행해 커밋된 데이터를 복구합니다.

커밋 과정 요약:

1. 변경 내용을 WAL에 먼저 기록하고 디스크에 동기화
2. 실제 데이터 파일에 변경 적용
3. 서버 재시작 시 WAL을 재실행해 복구

실전 트랜잭션 패턴

애플리케이션 코드에서 트랜잭션을 사용할 때는 예외 발생 시 ROLLBACK이 자동으로 이루어지도록 try/catch(또는 언어별 동등 구조)와 함께 사용합니다. 아래는 재고 차감과 주문 생성을 하나의 트랜잭션으로 처리하는 표준 패턴입니다.

BEGIN;

UPDATE inventory
SET stock = stock - 1
WHERE product_id = 42 AND stock > 0;

INSERT INTO orders (user_id, product_id, status)
VALUES (1, 42, 'confirmed');

COMMIT;

재고가 부족해 UPDATE가 0행을 변경했다면 애플리케이션 레이어에서 이를 감지하고 ROLLBACK을 실행해야 합니다.

두 트랜잭션이 동시에 실행 중입니다. 하나가 아직 커밋 전인 데이터를 다른 트랜잭션이 읽었습니다. 그 트랜잭션이 롤백되자 읽은 데이터가 존재하지 않는 데이터가 됩니다. 이게 Dirty Read입니다. 격리 수준이 낮으면 이런 문제가 생기고, 너무 높이면 성능이 떨어집니다. 각 수준이 어떤 문제를 막는지 알아야 서비스에 맞는 격리 수준을 선택할 수 있습니다.

격리 수준 4단계와 발생 가능 문제

격리 수준이 높을수록 데이터 일관성은 높아지지만 동시성(처리량)은 낮아집니다. 실무에서는 대부분 기본값인 Read Committed 또는 Repeatable Read를 사용합니다.

DB별 기본 격리 수준이 다릅니다. PostgreSQL의 기본값은 Read Committed이고, MySQL(InnoDB)의 기본값은 Repeatable Read입니다. 다른 DB를 함께 사용하거나 이식성이 중요한 코드에서는 이 차이를 반드시 고려해야 합니다.

3가지 동시성 문제 설명

Dirty Read — 미커밋 데이터 읽기

트랜잭션 A가 변경했지만 아직 커밋하지 않은 데이터를 트랜잭션 B가 읽는 현상입니다. A가 롤백하면 B는 실제로 존재하지 않는 데이터를 읽은 셈이 됩니다. Read Uncommitted 격리 수준에서만 발생합니다.

시간 흐름 (T1 → T5):

Non-repeatable Read — 같은 쿼리, 다른 결과

같은 트랜잭션 내에서 동일한 SELECT를 두 번 실행했을 때 결과가 달라지는 현상입니다. 다른 트랜잭션이 중간에 해당 행을 수정하고 커밋했기 때문입니다.

Phantom Read — 새로운 행이 나타남

같은 트랜잭션 내에서 동일한 범위 조회를 두 번 했을 때 처음에 없던 행이 나타나는 현상입니다. 다른 트랜잭션이 중간에 새 행을 INSERT하고 커밋했기 때문입니다.

격리 수준 설정

세션 전체 또는 개별 트랜잭션에 격리 수준을 지정할 수 있습니다. 금융 거래처럼 완벽한 일관성이 필요한 경우에는 Serializable을 사용하고, FOR UPDATE로 조회한 행에 잠금을 겁니다.

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance - 50000 WHERE id = 1;
COMMIT;

SAVEPOINT — 부분 롤백

SAVEPOINT는 트랜잭션 중간에 체크포인트를 만드는 기능입니다. ROLLBACK TO SAVEPOINT로 전체 트랜잭션을 취소하지 않고 특정 지점까지만 되돌릴 수 있습니다. 쿠폰 적용처럼 "실패해도 주문 자체는 유지해야 하는" 선택적 단계에 유용합니다.

BEGIN;

INSERT INTO orders (user_id, total) VALUES (1, 50000);
SAVEPOINT order_created;

INSERT INTO order_items (order_id, product_id, quantity)
VALUES (LASTVAL(), 42, 2);
SAVEPOINT items_added;

UPDATE coupons SET used_at = NOW() WHERE code = 'DISC10' AND used_at IS NULL;

ROLLBACK TO SAVEPOINT items_added;

COMMIT;

쿠폰 UPDATE가 0행을 변경하면(쿠폰 없음 또는 이미 사용됨) 애플리케이션에서 이를 감지하고 ROLLBACK TO SAVEPOINT items_added를 실행합니다. 주문과 주문 항목은 그대로 유지됩니다.