Antigravity Agent
161 lines
6.0 KiB
Markdown
161 lines
6.0 KiB
Markdown
---
|
|
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]]
|