한정 수량 쿠폰은 어떻게 무너지고,
락은 그것을 어디서 막는가

본문에 들어가기 전, 일곱 가지만 챙기자

이 글은 "동시성 제어를 한 번도 해본 적 없는" 백엔드 개발자를 기준으로 쓴다. 아래 일곱 개념은 본문 어딘가에서 반드시 발목을 잡는 것들이다. 이미 아는 카드는 건너뛰어도 된다 — 각 카드 하단에 어느 장면에서 필요한지 적어 두었으니, 막히면 돌아와서 읽으면 된다.

P7 보충 — 거절을 가르는 한 가지 질문

409와 503은 같은 "거절"처럼 보이지만 책임의 소재가 다르다. 기준은 하나 — 다시 보내면 결과가 달라질 수 있는가?

밑줄 점선이 그어진 용어는 호버/탭으로 정의를 볼 수 있고, 전체 목록은 맨 아래 부록에 있다.

사건 — 장부는 100이라고 말했다

발급 한도 total=100인 쿠폰에 500명의 가상 사용자가 10초간 동시에 달려들었다. 결과를 두 가지 방법으로 세어 보자.

두 숫자가 갈라졌다. 카운터는 100을 가리키는데, 실제 발급 이력은 999행이다. 카운터가 거짓말을 한 게 아니라, 카운터를 갱신하는 과정 자체가 동시성 앞에서 무너진 것이다. 이 현상이 lost update(갱신 손실)다.

코드로 보면 — 트랜잭션은 있었다

// v1 — @Transactional은 걸려 있다. 초과는 트랜잭션 부재가 아니라 동시성 제어 부재에서 난다.
@Transactional
public CouponIssueResponse issue(Long couponId, Long userId) {
    Coupon coupon = couponRepository.findById(couponId).orElseThrow(...);
    ...
    coupon.issue();   // 내부: if (issued < total) issued++  ← check-then-act, 비원자
    couponIssueRepository.save(new CouponIssue(couponId, userId));
    ...
}

coupon.issue() 안에서 일어나는 읽고(read) → 확인하고(check) → 더하는(increment) 세 단계가 하나의 원자적 동작이 아니다(선수지식 P1). 500개의 트랜잭션이 거의 같은 순간 같은 issued 값을 읽으면, 전부 "아직 한도 미만"이라는 확인을 통과해 버린다. 직접 눌러 보자.

해결의 방향은 단순하다 — 한 번에 한 명만 장부를 고치게 만들면 된다. 그 "한 번에 한 명"을 강제하는 장치가 락(lock)이고, 보호해야 하는 구간 — 여기서는 read·check·increment·insert — 을 임계 구간이라 부른다. 이제부터의 질문은 "락을 걸까 말까"가 아니라 — 락을 어디에 두고, 어떻게 운영할 것인가다.

버전을 가르는 세 개의 축

지금부터 다섯 버전이 나온다. 미리 못 박아 둘 것이 하나 있다 — 이 다섯은 "낮은 게 틀리고 높은 게 맞는" 등급이 아니다. 각자 다른 조건에서 각자 정답인 다섯 개의 도구다. "누가 빠른가"로 줄을 세우면 틀린 결론에 빠진다 (왜 그런지는 §5에서 직접 증명한다). 대신 이 세 가지 질문으로 읽으면 각 버전의 정체가 드러난다.

한 문제, 다섯 번의 답

각 칸은 같은 구조로 읽는다 — 앞 칸에서 막힌 것 → 그 자리의 선택지 → 채택과 구현 → 실측 → 새로 드러난 한계. 한계가 다음 칸의 문이 된다.

// 파사드 — 모니터가 트랜잭션 경계를 감싼다 (락 ⊃ tx)
public CouponIssueResponse issue(Long couponId, Long userId) {
    synchronized (lock) {                       // ① 모니터 획득 — tx 밖
        return inner.issueTx(couponId, userId); // ② "별도 빈" 프록시 호출 → 시작·커밋이 모니터 안에서 완료
    }                                            // ③ 커밋이 끝난 뒤에야 모니터 해제
}

// v3 — 하나의 @Transactional 안: 행 락 → 검사 → 발급 → 커밋(=락 해제)
@Transactional
public CouponIssueResponse issue(Long couponId, Long userId) {
    Coupon coupon = couponRepository.findByIdForUpdate(couponId)  // SELECT ... FOR UPDATE — 행 락 획득(대기)
            .orElseThrow(...);
    ...                                                          // 락을 쥔 채 검사·발급
    coupon.issue();
    couponIssueRepository.save(new CouponIssue(couponId, userId));
    ...
}                                                                // 커밋 — 이 순간 행 락이 풀린다

RLock lock = redissonClient.getLock("lock:coupon:" + couponId);
boolean locked = lock.tryLock(0, TimeUnit.SECONDS);  // waitTime=0 — 못 잡으면 즉시 503 (fail-fast)
                                                       // leaseTime 미지정 — 워치독이 보유 중 자동 연장
if (!locked) throw new LockNotAcquiredException(couponId);
try {
    return inner.issueTx(couponId, userId);            // 별도 빈 @Transactional — 락 ⊃ tx (v2와 같은 골격)
} finally {
    if (lock.isHeldByCurrentThread()) lock.unlock();   // 미보유 unlock 금지 — 거절이 500으로 새는 것 방지
}

// 획득 — 비어 있을 때만 내 토큰으로 세팅 (원자적)
redis.opsForValue().setIfAbsent(key, token, Duration.ofMillis(ttl));   // SET NX PX

// 해제 — 내 토큰일 때만 삭제 (Lua라서 get-비교-del이 원자적)
"if redis.call('get', KEYS[1]) == ARGV[1]
   then return redis.call('del', KEYS[1]) else return 0 end"

한눈에 — 막대의 위치가 정합 범위를 정한다

락을 바깥으로 옮길수록 더 넓은 범위를 아우르지만 — 그만큼 새로운 비용(운영, SPOF)과 새로운 실패 양식이 따라온다. 그 실패 양식이 바로 다음 장이다.

락을 쥔 채 만료되면 — fencing의 부재

통제 실험이다. 한도 1짜리 쿠폰에 TTL 1초 < 작업 정지(stall) 3초를 일부러 박았다. 홀더 A가 락을 쥔 채 3초간 멈추는 동안 — GC pause나 네트워크 단절이 현실에서 일으키는 바로 그 상황 — A의 TTL이 먼저 만료된다. 그 순간 B가 "비어 있는" 고리에 자기 이름표를 건다.

이 한 줄이 시리즈 전체에서 가장 중요한 발견이다:

안전한 해제(오해제 차단)와 상호배제(동시 점유 차단)는 별개다. compare-del은 전자만 준다. 후자 — 만료-중간탈취로 두 홀더가 겹치는 것 — 는 fencing token (자원 측에서 번호표를 검증하는 장치) 없이는 어느 분산 락도 막지 못한다. 워치독(v4)도 마찬가지다 — GC pause나 네트워크 단절 앞에서는 갱신 자체가 멈추므로 같은 구멍이 열린다.

왜 처리량으로 우승자를 뽑지 않았나

다섯 버전의 성공 처리량을 한 줄에 적으면 이렇다 — 404.0 / 263.6 / 317.5 / 6.3 / 28.4 (/s). 이 숫자들을 나란히 놓고 "v4가 제일 느린 락"이라거나 "DB 락이 synchronized보다 빠르다"고 읽고 싶어진다. 둘 다 틀린 독해다. 이 실험에서 가장 공들인 규율이 바로 이것이다.

함정 1 — 변한 건 락의 위치만이 아니다

v2·v3은 막히면 기다리고(park / DB 대기열), v4·v5는 막히면 즉시 거절한다(fail-fast). 같은 "성공 처리량" 컬럼이라도, 대기 정책은 경합을 전부 성공으로 흘려보내고 거절 정책은 경합의 99%를 503으로 배출한 뒤의 숫자다. 락 위치와 경합 정책이 동시에 움직였으니, 처리량 격차의 원인이 어느 쪽인지 이 측정만으로는 가릴 수 없다 — 교란 변수다. 사과(지연으로 흡수)와 오렌지(거절로 배출)를 한 그래프에 그린 셈이다.

그래서 별도의 통제 재실험을 돌렸다 — 경합 정책을 전 버전 "유한 대기"로 통일하고 락 위치만 바꿔서. 그러자 원래의 극적인 격차는 작은 단조 비용(락이 멀수록 약간 비쌈)으로 수렴했고, v3 > v2 같은 "반전"도 함께 무너졌다. 원래 격차의 지배 변수는 락의 기질이 아니라 경합 처리 방식이었던 것이다. 잘 나온 자기 수치라도, 교란이 있으면 헤드라인으로 쓰지 않는다.

함정 2 — 정상 부하는 갱신 정책을 가릴 수 없다

v5(28.4/s)가 v4(6.3/s)보다 빨랐다고 "고정 TTL이 워치독보다 빠르다"고 읽어도 틀린다. 락 보유 시간(수 ms)이 TTL(30s)보다 압도적으로 짧아, 정상 부하에선 고정 TTL이 중간에 만료될 일이 없다 — 즉 워치독이 막아줄 사건 자체가 안 생긴다. 두 버전의 처리량 차이는 갱신 정책이 아니라 대기/락 구현의 아티팩트(Redisson의 pub/sub + 갱신 스케줄링 vs 가벼운 SET NX)다. 갱신 정책의 진짜 차이는 §4처럼 보유 시간 > TTL인 조건에서만 드러난다.

합법적인 비교 — 세 축으로 본 다섯 버전

사다리를 한 칸 내려와서 — v3

분산 락까지 직접 구현해 보고 — 정규 발급 경로 POST /api/coupons/issue는 v3(DB 비관적 행 락)에 배선했다. v1·v2·v4·v5는 비교 실험용으로 코드에 공존하되 운영 트래픽과 무관하다.

핵심 근거 — 락과 데이터가 한몸이다

이 워크로드의 임계 구간은 그 자체로 DB 쓰기다(coupon 행 UPDATE + coupon_issue INSERT). 보호할 대상이 이미 DB 안에 있다. v3는 락(FOR UPDATE 행 락)과 데이터가 같은 DB, 같은 트랜잭션 안에 있어 원자적이다 — 락은 커밋과 함께 풀리므로 "쥔 채 만료"가 성립하지 않고, fencing 틈이 구조적으로 없다. 락을 Redis로 빼는 순간 락↔데이터가 다른 시스템으로 분리되고 그 틈이 열린다 — §4 스톨 데모의 actual=2가 그 틈의 실측 증거다.

그래서 v3는 v4·v5보다 단지 "충분"한 게 아니라, 이 워크로드에선 더 안전하다. "왜 분산 락(트렌드)을 안 썼나"의 답은 트렌드 무지가 아니라 워크로드 적합성 판단이다 — 사다리를 끝까지 올라가 본 뒤에 내린.

근거 보강 — 그리고 정직한 꼬리표

다중 인스턴스 정합도 v3가 이미 준다. 공유 DB 행 락이라 인스턴스를 늘려도 모두 같은 행 락을 거친다 — Redis는 스케일아웃의 전제가 아니다. v4·v5가 v3 너머로 더해주는 건 정합의 범위가 아니라 "DB 밖 임계 구간 보호"뿐이다. (단, 이 다중 인스턴스 정합은 단일 JVM 측정에선 개념적 보장이다 — 다중 인스턴스 실측은 다음 과제로 백로그에 명시해 두었다.)

대가는 수용 가능하다. v3의 풀 압박(active 10/10, pending 189)은 측정·튜닝 가능한 비용이고 이 워크로드 규모에서 감당된다. 그리고 처리량은 근거로 쓰지 않았다 — §5의 규율 그대로. 결정의 근거는 빠름이 아니라 구조적 안전이다.

이 결정의 범위 — 조건이 바뀌면 답도 바뀐다

이 선택은 인프라 맥락의 함수다. Redis가 이미 핵심 캐시로 깔려 있고, DB 부하 분리가 절실하고, 보호 대상이 DB 밖(외부 API 호출의 멱등성 같은)이라면 — 그때는 락을 데이터에서 떼어낼 수밖에 없으니 분산 락이 본래 자리를 찾고, v4로 간다. 분산 락이 틀린 도구인 게 아니라, DB 행을 보호하는 일에 락을 데이터에서 떼어내는 것이 역효과(fencing 틈 + SPOF)일 뿐이다.

용어 정리

본문에 점선 밑줄로 등장한 용어 + 함께 알아두면 좋은 용어. 가나다·알파벳 혼합 순.