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을 실행해야 합니다.

앞에서 원자성(A)과 내구성(D)이 무엇을 보장하는지 봤습니다. 그런데 DB는 대체 어떤 장치로 "출금만 되고 입금은 안 된 중간 상태"를 막고, 전원이 나가도 커밋된 데이터를 지킬까요? 답은 변경을 데이터 파일보다 로그(WAL)에 먼저 쓰고, COMMIT 시점에 그 로그를 디스크에 확정하는 순서에 있습니다. 이 5단계를 알면 "커밋이 성공을 반환했다"가 정확히 무엇을 약속하는지 단계로 이해할 수 있습니다.

[클라이언트]  BEGIN;
             UPDATE accounts SET balance = balance - 100000 WHERE id = 1;
             UPDATE accounts SET balance = balance + 100000 WHERE id = 2;
             COMMIT;
   │
   ① BEGIN           → 트랜잭션 ID 발급, 여기부터의 변경이 '한 단위'로 묶임
   │
   ② WAL 선기록       → 데이터 파일을 고치기 전에 "무엇을 어떻게 바꿀지"를
   │                   먼저 WAL(redo 로그)에 append (Write-Ahead)
   │
   ③ 버퍼 수정        → 메모리(shared_buffers)의 데이터 페이지만 변경.
   │                   디스크 데이터 파일은 아직 예전 상태
   │
   ④ COMMIT          → 이 트랜잭션의 WAL을 fsync로 디스크에 확정(내구성 확정 지점)
   │                   → 그 다음에야 클라이언트에 '커밋 성공' 반환
   │
   ⑤ 가시화 or 되돌림  → 커밋되면 다른 트랜잭션에 보임.
   │                   ROLLBACK·크래시면 미확정 변경은 되돌려짐(부분 반영 없음)
   ▼
[크래시 후 재시작]  WAL을 재실행(redo)해 커밋된 것 복구, 미커밋은 버림

각 단계에서 무슨 일이 일어나고, 무엇이 보장되나:

정리하면 **"커밋 성공을 반환받았다"는 곧 "④ WAL fsync를 넘겼다"**는 뜻이고, 그래서 그 직후 전원이 나가도 재시작 시 WAL 재실행으로 데이터가 살아남습니다(D). "A에서 출금됐는데 B에 입금 안 된" 중간 상태가 DB에 남지 않는 이유도 여기 있습니다 — ④를 넘기기 전에는 어떤 변경도 확정이 아니고, 롤백이나 크래시면 두 UPDATE가 통째로 되돌아가기 때문입니다(A). 단, 이 보장은 단일 노드에서 synchronous_commit이 켜진 기준이며, 복제까지 얽히면 "어디까지의 내구성인가"가 달라집니다 — 그 여백은 이 모듈 뒤쪽 심화에서 다룹니다.

두 트랜잭션이 동시에 실행 중입니다. 하나가 아직 커밋 전인 데이터를 다른 트랜잭션이 읽었습니다. 그 트랜잭션이 롤백되자 읽은 데이터가 존재하지 않는 데이터가 됩니다. 이게 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를 실행합니다. 주문과 주문 항목은 그대로 유지됩니다.

이 모듈은 "COMMIT 시 WAL이 fsync로 디스크에 기록되므로 내구성(D)이 보장된다"고 배웠습니다. 단일 노드에서는 맞는 말이지만, 실제 운영은 대개 복제본을 두고 굴러가고, 거기서 내구성은 몇 개의 손잡이(knob)에 달려 있습니다. 한 단계 더 들어가 "COMMIT 성공"이 실제로 어디까지 보장하는지 봅니다.

• synchronous_commit — 얼마나 기다렸다 성공이라 말하나: 기본값 on이면 COMMIT은 WAL이 로컬 디스크에 flush될 때까지 기다려, 주 노드가 크래시해도 커밋된 데이터가 남습니다. 반대로 off로 두면 처리량을 위해 flush 전에 성공을 반환합니다 — 크래시 시 최근 커밋 몇 건을 통째로 잃을 수 있습니다(부분 반영은 없고 정합성은 유지되며, '최신 커밋만' 사라짐). 이 손잡이의 의미를 모르고 켰다 끄면 내구성의 강도가 바뀝니다.
• 비동기 복제 — 주는 복제본을 기다리지 않는다: 기본 스트리밍 복제는 비동기입니다. 주(primary)는 복제본이 WAL을 받았는지 확인하지 않고 COMMIT을 확정합니다. 평소엔 문제없지만, 주가 갑자기 죽어 아직 최신 WAL을 못 받은 복제본으로 페일오버하면 그 사이 커밋된 데이터가 사라집니다. 이 손실 구간이 바로 RPO(복구 시점 목표)입니다 — 비동기 복제의 RPO는 0이 아닙니다.
• 무손실을 원하면 동기 복제: synchronous_standby_names로 동기 복제를 켜면, 최소 한 복제본이 WAL을 받은 뒤에야 COMMIT이 확정돼 페일오버 유실이 사라집니다. 대가는 커밋 지연 증가와 가용성 트레이드오프입니다 — 동기 복제본이 죽으면 커밋이 멈출 수 있어, 보통 복제본을 2대 이상 두고 quorum으로 설정합니다.
• 그래서 내구성은 '설정된 약속'이다: "COMMIT이 성공을 반환했다"는 것과 "이 데이터는 어떤 장애에도 살아남는다"는 다른 문장입니다. 팀은 데이터 중요도에 따라 결제·정산은 동기(또는 최소 지연 감시), 로그·통계는 비동기처럼 나눠 설계합니다.

정리하면, WAL은 내구성의 '메커니즘'이고 synchronous_commit·복제 모드는 그 '강도'를 정하는 손잡이입니다. 어느 손잡이가 어디에 걸려 있는지 아는 것이 진짜 내구성 설계입니다.