밀리초 타임스탬프 기반 Job ID 생성의 함정: 동시성 문제와 MAX_SAFE_INTEGER 회피 전략

핵심 기술: 본 글은 백엔드 시스템에서 고유 ID 생성의 기본적인 중요성을 강조하며, 특히 밀리초 타임스탬프 기반 ID 생성 방식의 잠재적 문제점(동시성 충돌)과 이를 해결하기 위한 timestamp + counter + random 조합 방식, 그리고 JavaScript/TypeScript의 Number.MAX_SAFE_INTEGER 한계 초과 문제를 분석하고 해결책을 제시합니다.

기술적 세부사항:
* 문제점: 밀리초 타임스탬프 기반 ID는 동일한 밀리초 내에 다수의 요청이 발생할 경우 충돌이 발생할 수 있습니다.
* 초기 해결 시도: timestamp + counter + random 조합으로 timestamp * 1000000 + SchedulingService.jobIdCounter * 1000 + randomComponent 방식을 도입하여 동시성 문제와 정렬 가능성을 개선했습니다.
* timestamp: UTC 기준 밀리초 (기본 시간 순서 보장)
* counter: 0~999 순환 카운터 (동일 밀리초 내 요청 구분)
* random: 0~999 랜덤 값 (충돌 가능성 최소화)
* 치명적 문제 (Number.MAX_SAFE_INTEGER): JavaScript/TypeScript의 number 타입은 최대 안전 정수 범위(~9e15)가 제한적입니다. 밀리초 타임스탬프(1.7e12)에 1,000,000을 곱하는 연산은 이 범위를 초과하여 정밀도 깨짐, 잘못된 비교/정렬을 야기할 수 있습니다.
* 최종 해결책: 타임스탬프 단위를 밀리초에서 초 단위로 변경하여 (Math.floor(DateTime.utc().toSeconds())) jobId가 Number.MAX_SAFE_INTEGER 이내로 유지되도록 합니다. 이를 통해 안정성, 정렬성, 유니크함을 모두 확보합니다.
* 대안 ID 방식 비교:
* UUID: 충돌 거의 없음, 전역 유니크하지만 길고 복잡한 문자열.
* Snowflake ID: 시간 정렬 + 유니크, 대규모 분산 환경에 적합하나 구현 복잡, 시간 오류에 취약.

개발 임팩트: 안전하고 효율적인 고유 ID 생성 전략 수립에 대한 실질적인 인사이트를 제공합니다. 특히 JavaScript 환경에서 발생할 수 있는 숫자 정밀도 문제를 인지하고 이를 회피하는 방법을 배울 수 있으며, 이는 시스템의 안정성과 신뢰성을 향상시키는 데 기여합니다.

커뮤니티 반응: 글에서 Cursor AI의 버그 봇이 코드 리뷰를 통해 타임스탬프 기반 ID의 충돌 가능성을 지적한 사례가 언급되며, 자동화된 코드 리뷰 도구의 유용성을 간접적으로 보여줍니다.