---
id: db-transaction-isolation
title: DB Transaction Isolation Levels — 실전 선택
category: Coding
status: draft
source_trust_level: B
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
tags: [database, transaction, isolation, postgres, vibe-coding]
tech_stack: { language: "SQL / Postgres", applicable_to: ["Backend"] }
applied_in: []
aliases: [SERIALIZABLE, REPEATABLE READ, READ COMMITTED, phantom read]
---

# DB Transaction Isolation

> Postgres default = **READ COMMITTED**. 충분한 경우 많지만 race 가 진짜로 위험한 곳에는 **SERIALIZABLE** + retry. 무지성 SERIALIZABLE 은 throughput 폭락.

## 📖 핵심 개념
4 단계 (SQL standard):
- **READ UNCOMMITTED**: dirty read 허용 (Postgres 는 실제로 READ COMMITTED 처럼 동작).
- **READ COMMITTED**: 디폴트. 같은 트랜잭션 안에서 다른 SELECT 가 다른 결과 가능 (non-repeatable).
- **REPEATABLE READ** (Postgres = snapshot): 트랜잭션 시작 시점 snapshot. 같은 SELECT = 같은 결과.
- **SERIALIZABLE**: 직렬 실행한 것과 같은 결과 보장. 충돌 시 SerializationFailure throw.

## 💻 코드 패턴

### 명시적 isolation
```sql
BEGIN ISOLATION LEVEL SERIALIZABLE;
-- ...
COMMIT;
```

### Node + pg
```ts
await client.query('BEGIN ISOLATION LEVEL SERIALIZABLE');
try {
  // ... business logic ...
  await client.query('COMMIT');
} catch (e: any) {
  await client.query('ROLLBACK');
  if (e.code === '40001') {  // serialization_failure
    // 재시도 가능
  }
  throw e;
}
```

### Race condition 예시 — 잔액 차감

```sql
-- ❌ READ COMMITTED 에서 race
BEGIN;
SELECT balance FROM accounts WHERE id = 1;  -- 100
-- 다른 트랜잭션이 동시 동일 작업 진행
UPDATE accounts SET balance = balance - 50 WHERE id = 1;  -- 50
COMMIT;
-- 두 트랜잭션 모두 50 으로 끝나는 게 아니라 0 으로 끝남 (UPDATE 의 expression 은 안전)
-- BUT: 절차상 잔액 < 50 검사를 SELECT 후 했다면 둘 다 통과 → 음수 가능
```

해결 방법 4가지:

```sql
-- 1) 단일 UPDATE 에서 검사 + 차감 (가장 단순)
UPDATE accounts SET balance = balance - 50
  WHERE id = 1 AND balance >= 50
  RETURNING balance;
-- rowCount = 0 → 잔액 부족
```

```sql
-- 2) SELECT FOR UPDATE — 잠금
BEGIN;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE; -- 다른 tx 블록
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;
```

```sql
-- 3) SERIALIZABLE — 직렬 보장
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT balance FROM accounts WHERE id = 1;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
COMMIT;
-- 충돌 시 SerializationFailure → app 에서 재시도
```

```sql
-- 4) Optimistic — version
UPDATE accounts SET balance = balance - 50, version = version + 1
  WHERE id = 1 AND version = $expected;
```

## 🤔 의사결정 기준
| 상황 | 권장 |
|---|---|
| 일반 CRUD | READ COMMITTED (default) |
| 복잡 read-write 한 트랜잭션 안에서 일관성 필요 | REPEATABLE READ |
| 잔액 / 재고 / 좌석 예약 (strict) | SERIALIZABLE + retry, OR 단일 UPDATE 표현식 |
| Read-only report (스냅샷 일관) | REPEATABLE READ |
| 단순 검사+수정 | `UPDATE ... WHERE 조건` 한 줄로 |

## ❌ 안티패턴
- **모든 곳 SERIALIZABLE**: throughput 폭락. 정말 필요한 곳만.
- **SERIALIZABLE 인데 retry 없음**: SerializationFailure 에 사용자 에러 노출.
- **트랜잭션 안에서 외부 API 호출**: 트랜잭션 길어짐 → lock contention.
- **lock 순서 일관성 없음**: deadlock. 항상 같은 순서로 row 잠금 (보통 ID ASC).
- **트랜잭션 너무 큼 (수천 row 변경)**: 다른 트랜잭션 blocking. 작은 batch.
- **autocommit 끄고 commit 잊음**: 영구 lock + 메모리 leak. 명시적 commit/rollback.
- **READ UNCOMMITTED 가정**: Postgres 에서 동작 다름. 디폴트 READ COMMITTED 가정.

## 🤖 LLM 활용 힌트
- "단일 row 검사+수정은 한 UPDATE 표현식. 여러 row 일관성 필요면 SERIALIZABLE + retry" 명시.
- 트랜잭션 안에서 외부 호출 금지 강제.

## 🔗 관련 문서
- [[Optimistic_Concurrency_Control]]
- [[DB_Connection_Pool]]