TL;DR — 요청 카운터로 재전송(replay)을 막고 있었는데, 같은 요청 둘이 동시에 들어오면 둘 다 통과했다. "읽어서 비교하고 → 쓴다" 사이에 다른 요청이 끼어들 수 있는 간격(TOCTOU)이 있었기 때문이다. 비교와 갱신을 한 번의 조건부 갱신으로 합쳐 해결했다.

배경

• 프로젝트/기능: KC License Server — /verify 요청의 재전송 방지
• 환경: Java 21, Spring Boot 3.x, MySQL 8
• 방식: 요청에 실린 카운터가 서버가 기억하는 last_count 와 달라야 통과. 통과하면 last_count를 갱신한다

문제 (증상)

• 단일 요청으로는 재전송이 정상적으로 막힌다
• 그런데 동일한 요청 두 건을 동시에 보내면 둘 다 성공한다 — 재전송 방지가 뚫린다

원인 분석

• 검증 로직이 이렇게 되어 있었다: ① last_count를 읽는다 → ② 요청 값과 비교한다 → ③ 통과하면 갱신한다
• ①과 ③ 사이에 다른 스레드가 끼어들 수 있다. 두 요청이 모두 ①에서 같은 값을 읽으면, 둘 다 ②를 통과하고 ③을 각각 수행한다
• 전형적인 **TOCTOU(검사 시점과 사용 시점의 불일치)**다. 검사는 통과했지만 그 사이 전제가 바뀐다
• 애플리케이션 레벨에서 값을 읽어 판단하는 구조인 한, 잠금 없이는 이 간격이 사라지지 않는다

해결

비교와 갱신을 한 번의 원자적 연산으로 합쳤다.

• 조건을 WHERE 절에 넣은 조건부 UPDATE로 바꿔, "현재 값이 기대한 값일 때만 갱신"하도록 했다
• 갱신된 행 수로 성공/실패를 판정한다 — 동시에 들어온 둘 중 하나만 1을 받고, 나머지는 0을 받아 거부된다
• 판정 근거가 애플리케이션 메모리가 아니라 DB의 원자성이 되어, 인스턴스를 늘려도 같은 보장이 유지된다

결과

• 동일 요청 동시 전송 시 정확히 한 건만 성공