요약 및 비교
| 분류 | 추천 기술 | 특징 및 장점 | 적합한 유스케이스 |
| 시간 정렬 (DB PK용) | UUID v7 | 2024년 최신 RFC 표준, 128bit 호환성 | DB의 메인 PK, 범용적인 분산 ID |
| 시간 정렬 문자열 | ULID | 26자리 Base32 문자열, URL Safe, 높은 가독성 | API 응답, NoSQL 키, 로그 추적 ID |
| 보안 및 비예측성 | CUID2 | 순차적 유추 불가, 충돌 방지 최적화 | 외부에 노출되는 식별자 (공유 링크 등) |
1. UUID v7 (가장 추천하는 최신 표준)
기존의 UUID v4(랜덤)는 RDBMS의 Primary Key로 사용할 경우 인덱스 단편화(Index Fragmentation)를 일으켜 성능 저하를 유발하는 치명적인 단점이 있었습니다. 이를 해결하기 위해 2024년 5월 RFC 9562로 새롭게 제정된 최신 표준이 바로 UUID v7입니다.
- 특징: 128비트 중 앞부분 48비트를 Unix Timestamp(밀리초)로 사용하여 시간순 정렬이 가능합니다. (TSID와 유사한 개념을 UUID 표준으로 가져온 것입니다.)
- 장점:
- 데이터베이스 인덱스 성능에 매우 친화적입니다 (Sequential IO 보장).
- 독자적인 포맷이 아닌 글로벌 표준(RFC)이므로 호환성이 뛰어납니다.
- Java 도입 방안: Java 표준 java.util.UUID는 아직 v7을 기본 지원하지 않지만, 외부 통신 없이 로컬에서 동작하는 가벼운 라이브러리(예: TSID를 만드신 f4b6a3의 uuid-creator)를 추가하거나, 비트 연산을 통해 직접 구현하기 매우 쉽습니다.
2. ULID (Universally Unique Lexicographically Sortable Identifier)
ULID는 TSID와 유사하지만, 특히 문자열 기반으로 데이터를 다룰 때 매우 강력한 대안입니다.
- 특징: 128비트(48비트 시간 + 80비트 랜덤)로 구성되며, Crockford's Base32로 인코딩되어 26자리의 문자열로 표현됩니다. 01ARZ3NDEKTSV4RRFFQ69G5FAV 같은 형태입니다.
- 장점:
- 시간순으로 정렬 가능한 문자열(Lexicographically Sortable)입니다.
- I, L, O, U 등 헷갈리기 쉬운 문자를 제외하여 가독성이 높고 URL Safe합니다.
- 밀리초가 같아도 Monotonic(단조 증가) 속성을 보장하여 충돌 확률이 극히 낮습니다.
- Java 도입 방안: 역시 의존성이 없는 가벼운 라이브러리(예: ulid-creator)가 널리 사용됩니다.
3. CUID2 (보안 및 예측 불가능성이 중요할 때)
Snowflake나 TSID, ULID 같은 '시간 기반(Time-sorted)' ID는 생성 시간을 유추할 수 있고, ID가 순차적으로 증가하므로 경쟁사가 비즈니스 규모를 추론하거나 악의적인 크롤링을 시도할 수 있는 보안 취약점이 존재합니다. CUID2는 이러한 식별자 예측(Sequential guessing)을 방지하기 위해 설계된 모던 ID 포맷입니다.
- 특징: NanoID처럼 랜덤성이 강하지만, 해시 함수와 지문(Fingerprint), 카운터를 복합적으로 사용하여 분산 환경에서의 충돌 저항성을 극대화했습니다.
- 장점:
- 시간 정보나 순서가 노출되지 않아 보안상 매우 안전합니다.
- URL Safe하며 길이를 원하는 대로 조절할 수 있습니다.
- 추천 대상: 외부 API 사용자에게 노출되는 식별자이거나, 보안상 예측 불가능해야 하는 식별자가 필요할 때 NanoID의 훌륭한 대체제가 됩니다.
기타 참고
- Time-Sorted Unique Identifiers (TSID)
- NanoID
- snowflake
- instagram
- 개인적으로 과거에 해당 방식으로 종종 개발
- https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c