---
id: optimistic-concurrency-control
title: 낙관적 동시성 제어 (Optimistic Concurrency Control)
category: Coding
status: draft
canonical_id: optimistic-concurrency-control
aliases: [OCC, optimistic locking, version field, ETag, 낙관적 락]
duplicate_of: null
source_trust_level: B
confidence_score: 0.9
verification_status: conceptual
created_at: 2026-05-09
updated_at: 2026-05-09
last_reinforced: 2026-05-09
review_reason: ""
merge_history: []
tags: [coding, concurrency, database, http, vibe-coding]
raw_sources: ["P-Reinforce session 2026-05-09 — bulk Coding seed batch 1"]
tech_stack:
  language: "SQL / TypeScript / HTTP"
  applicable_to: ["Backend", "REST API", "DB write paths"]
applied_in: []
---

# 낙관적 동시성 제어

> 충돌은 드물다고 가정하고 락 없이 진행. 충돌이 발생하면 **버전 비교로 감지하고 재시도하거나 사용자에게 알린다**. 비관적 락보다 throughput 높지만 충돌이 잦으면 retry 폭주.

## 📖 핵심 개념

두 사용자가 같은 레코드를 동시에 수정할 때:
- **비관적(pessimistic) 락**: 한 명이 잠금 → 다른 명은 대기. throughput 낮음, deadlock 위험.
- **낙관적(optimistic)**: 둘 다 진행, 마지막 commit 시점에 "내가 읽은 버전이 아직도 유효한가?" 확인. 깨졌으면 reject.

낙관적 락은 다음 둘 중 하나로 구현:
1. **Version 컬럼** (정수 또는 timestamp): UPDATE 시 `WHERE version = ?` 조건. 변경 시 version+1.
2. **HTTP ETag / If-Match**: 서버가 ETag 발급 → 클라이언트가 PUT 시 `If-Match` 헤더로 보냄.

## 💻 코드 패턴

### 1. Version 컬럼 (SQL)

```sql
ALTER TABLE orders ADD COLUMN version INT NOT NULL DEFAULT 0;
```

```ts
async function updateShipping(orderId: string, addr: Address, expectedVersion: number) {
  const result = await db.query(
    `UPDATE orders
     SET shipping = $1, version = version + 1
     WHERE id = $2 AND version = $3`,
    [addr, orderId, expectedVersion]
  );

  if (result.rowCount === 0) {
    // 누군가 이미 수정했거나 주문이 없음
    throw new ConflictError('Concurrent update detected — re-read and try again');
  }
}
```

### 2. HTTP ETag

```ts
// GET — ETag 발급
app.get('/api/orders/:id', async (req, res) => {
  const order = await db.findOrder(req.params.id);
  res.setHeader('ETag', `"${order.version}"`);
  res.json(order);
});

// PUT — If-Match 검증
app.put('/api/orders/:id', async (req, res) => {
  const ifMatch = req.header('If-Match');
  if (!ifMatch) return res.status(428).json({ error: 'If-Match required' });

  const expected = parseInt(ifMatch.replace(/"/g, ''), 10);
  try {
    await updateShipping(req.params.id, req.body.shipping, expected);
    res.status(204).end();
  } catch (e) {
    if (e instanceof ConflictError) return res.status(412).json({ error: 'Version mismatch' });
    throw e;
  }
});
```

### 3. 자동 재시도 wrapper

```ts
async function retryOnConflict<T>(
  op: () => Promise<T>,
  { maxAttempts = 3, backoffMs = 50 }: { maxAttempts?: number; backoffMs?: number } = {}
): Promise<T> {
  let lastErr: unknown;
  for (let i = 0; i < maxAttempts; i++) {
    try {
      return await op();
    } catch (e) {
      if (!(e instanceof ConflictError)) throw e;
      lastErr = e;
      await new Promise(r => setTimeout(r, backoffMs * Math.pow(2, i)));
    }
  }
  throw lastErr;
}
```

`op()` 안에서 항상 **다시 read → 변경 → write** 흐름이어야 한다. 같은 expectedVersion 으로 재시도하면 영원히 실패.

### 4. Document DB (MongoDB) — findOneAndUpdate with filter

```ts
const result = await orders.findOneAndUpdate(
  { _id: orderId, version: expectedVersion },
  { $set: { shipping: addr }, $inc: { version: 1 } },
  { returnDocument: 'after' }
);
if (!result.value) throw new ConflictError('version mismatch');
```

## 🤔 의사결정 기준

| 상황 | OCC 적합 | 비관적 락 적합 |
|---|---|---|
| 충돌 빈도 < 5% | ✅ | ❌ |
| 충돌 빈도 > 30% | ❌ (retry 폭주) | ✅ |
| 트랜잭션이 짧음 | ✅ | — |
| 트랜잭션이 길고 사용자 대기 중 | ✅ (사용자에게 충돌 알림) | ❌ (deadlock) |
| 분산 환경 (DB 여러 대) | ✅ | 어려움 |
| 잔액 / 재고 같은 strict invariant | OCC 가능하지만 SELECT FOR UPDATE 또는 `UPDATE ... WHERE balance >= ?` 사용 | ✅ |

## ❌ 안티패턴

- **버전 비교 없이 `UPDATE SET ... WHERE id = ?`**: lost update. 마지막 쓰기가 이전 쓰기를 조용히 덮어씀.
- **클라이언트가 보낸 version 을 그대로 신뢰 후 검증 안 함**: 클라이언트가 의도적으로 옛 version 보내면 항상 통과.
- **재시도 시 같은 expectedVersion 사용**: 영원히 실패. 재시도 안에서 **다시 read** 해야 함.
- **충돌 시 묵묵히 무시**: 사용자는 자기 변경이 적용되었다고 믿음. 실제로 사라짐. 명시적 4xx 응답 + UI 알림.
- **Version 을 timestamp 로**: 같은 ms 에 두 update 가 들어오면 둘 다 통과. 정수 시퀀스가 안전.
- **모든 곳에 자동 retry**: 사용자가 form 에 입력한 값을 자동 재시도 = 사용자가 본 데이터와 다를 수 있음. UI 가 "다른 사람이 수정했어요. 다시 보시겠어요?" 묻기.
- **OCC 와 application-level 캐시 결합**: 캐시가 stale version 을 들고 있으면 영원히 충돌. 캐시 invalidation 정책 필수.

## 🤖 LLM 활용 힌트

- LLM에게 SQL UPDATE 작성: "**WHERE 조건에 version = expected 추가, rowCount 0 이면 ConflictError throw**" 명시.
- REST API: "**GET 응답에 ETag, PUT 요청에 If-Match 강제 (없으면 428)**" 패턴 요청.
- retry wrapper: "**read → modify → write 흐름이어야 retry 의미 있음. 같은 expected 로 재시도 금지**" 강조.

## 🧪 검증 상태

- verification_status: `conceptual`
- JPA `@Version`, Hibernate optimistic locking, REST API ETag 표준 (RFC 7232) 의 핵심 패턴.
- 적용 사례 발견 시 `applied_in` 추가.

## 🔗 관련 문서

- [[Idempotent_Operations]]
- [[Backpressure_Patterns]]
- [[Error_Handling_Result_vs_Throw]]