2nd/10_Wiki/Topics/Topic_Programming/Coding/Optimistic_Concurrency_Control.md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, created_at, updated_at, last_reinforced, review_reason, merge_history, tags, raw_sources, tech_stack, applied_in

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

낙관적 동시성 제어

충돌은 드물다고 가정하고 락 없이 진행. 충돌이 발생하면 버전 비교로 감지하고 재시도하거나 사용자에게 알린다. 비관적 락보다 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)

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

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

// 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

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

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