요약 — KC License Server의 요청 카운터를 읽어 비교한 뒤 갱신하던 경로에서 동일 요청의 동시 통과 문제를 발견했다. 조건부 UPDATE와 영향 행 수 판정으로 비교·갱신을 원자화했다. 다만 마지막 값과의 불일치 검사는 전체 과거 요청의 replay 방지와 같지 않으며, A→B→A 재전송·롤백·재시작은 별도 검증 대상이다.

배경

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

문제 (증상)

• 마지막 카운터와 같은 값을 바로 다시 보내는 단일 요청은 거부한다. 이는 직전 값의 반복에 대한 검사이며 전체 과거 요청의 재전송을 막는 보장은 아니다.
• 그런데 동일한 요청 두 건을 동시에 보내면 둘 다 성공한다 — 재전송 방지가 뚫린다

원인 분석

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

해결

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

• 조건부 UPDATE의 WHERE last_count <> :n 조건으로 비교·갱신을 한 DB 연산으로 합쳤다. 이는 요청값과 현재 마지막 값의 불일치 검사이지, 이전에 읽은 값과의 CAS 비교나 단조 증가 검사를 뜻하지 않는다.
• 갱신된 행 수 1/0으로 성공·거부를 판정한다. 동일 행에 같은 카운터를 동시에 갱신하고 첫 갱신이 커밋되는 조건에서 중복 성공을 제한하는 구조다. 중간의 다른 요청·트랜잭션 롤백까지 포함한 보장은 따로 검증해야 한다.
• 상태 판정을 공유 DB의 조건부 갱신에 둬 프로세스 메모리에만 의존하던 간격을 줄였다. 여러 인스턴스가 같은 DB 행을 갱신한다는 전제와 커밋·영향 행 수 판정이 필요하다.

결과

• 기존 기록의 동일 요청 동시 전송 개선 사례는 보존한다. 이번 문서 교정에서 동시 요청을 독립 재실행한 결과는 아니므로 현재 시험 PASS로 보고하지 않는다. A→B→A처럼 마지막 값이 바뀐 뒤 과거 요청을 다시 보내는 경우는 이 조건만으로 거부되지 않을 수 있다.