---
kind: CASE
slug: a-boundary-that-leaks-only-under-load
title: 부하 아래에서 지키라고 만든 경계가 부하 아래에서만 샌다
topic: duplicate-mechanisms
topicName: 중복 장치 — 조립된 쪽이 약한 쪽일 때
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: case:a-boundary-that-leaks-only-under-load
source:
  - final/document.md#8-2
  - final/document.md#a20
  - final/document.md#5-5
  - final/document.md#8-2 항목 6
  - final/document.md#a20 §7
---

# 부하 아래에서 지키라고 만든 경계가 부하 아래에서만 샌다

같은 가족의 구현 중 하나가 제한값 검사와 증가를 분리해서 수행하고, 다른 구현은 CAS loop로 두 동작을 하나의 원자적 갱신으로 묶는다. 정적 코드 비교로 경계 차이는 확인했지만 실제 경쟁 부하는 재현하지 않았다.

## 관계

- **중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다**
  같은 목적의 구현이 둘일 때 실제 호출 경로가 어느 쪽인지 확인하는 기준이다.
- **CAS tuple과 update count**
  경쟁 상태에서 읽기와 쓰기를 분리하지 않는 상태 전이 규칙을 설명한다.

## 문제

제한값을 읽어 “아직 여유가 있다”고 확인한 뒤 별도 연산으로 값을 증가시키면 두 worker가 같은 이전 값을 동시에 읽을 수 있다. 각 worker는 개별적으로는 검사를 통과하지만 합산 결과는 경계를 넘을 수 있다.

같은 가족에는 CAS loop로 읽은 revision과 기대 값을 WHERE 조건에 포함해 한 worker만 갱신하도록 만든 구현이 있다.

## 결론

이 경계는 단일 worker 테스트만으로는 충분히 검증되지 않는다. 제한 확인과 증가가 하나의 원자적 상태 전이가 아니면 경쟁 부하에서만 초과가 나타날 수 있다.

현재 판정은 두 구현의 코드 구조 비교다. 실제 concurrent load를 걸어 초과를 재현하지 않았으므로 발생 빈도나 임계 동시성은 주장하지 않는다.

## 검증 환경

sourceRevision : 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
현재 source repository 재대조 : UNVERIFIABLE
확인 방식 : 동일 가족 구현의 정적 비교

## 재현 조건

1. 제한 확인과 증가가 분리된 구현의 read/write 순서를 확인한다.
2. 같은 가족의 CAS 구현이 기대 값과 revision을 갱신 조건에 포함하는지 확인한다.
3. source repository가 있는 환경에서는 두 worker 이상으로 같은 경계를 동시에 갱신해 실제 초과 여부를 측정한다.

## 본문

<!-- body:start -->

## 단일 요청에서 보이지 않는 이유

worker 하나만 실행하면 “읽기 → 검사 → 증가” 사이에 다른 쓰기가 끼어들지 않는다. 따라서 기능 테스트는 정상 범위만 관측할 수 있다.

## CAS 구현과 비교한다

대조 구현은 현재 값을 읽은 뒤 기대 revision을 포함한 갱신을 시도한다. 경쟁자가 먼저 값을 바꾸면 update count가 0이 되고 다시 읽어 판정한다. 이 차이가 두 구현의 concurrency 보장 차이다.

## 확인하지 못한 것

실제 부하에서 경계를 넘기는 실행은 이번 검토에서 재현하지 않았다. 코드 구조상 race 가능성을 확인한 상태다.

<!-- body:end -->