ID 형식 고르기: UUID, ULID, Snowflake, 자동 증가

자동 증가 정수

고전적인 데이터베이스 ID: 1, 2, 3 … 식으로 데이터베이스가 발급합니다. 아주 작고, 인덱싱이 빠르며, 생성 순서대로 자연스럽게 정렬됩니다. 단일 데이터베이스라면 흔히 이것으로 충분합니다.

약점은 가장자리에서 나타납니다. 중앙 데이터베이스만 발급할 수 있어, 독립 서비스나 오프라인 클라이언트는 ID를 미리 생성할 수 없습니다. 또한 정보를 흘립니다: 경쟁자가 당신의 송장 번호를 읽어 주문량을 추정할 수 있고, URL의 순차 ID는 이웃 레코드를 추측하도록 유도합니다.

UUID 버전 4 (무작위)

v4 UUID는 122비트의 난수로, 보통 36자로 씁니다. 누구나, 어디서나, 어떤 조율도 없이 생성할 수 있고 충돌 확률이 사실상 0이라, 분산 시스템·병합 친화적 키·추측 불가능해야 하는 공개 식별자에 이상적입니다.

대가는 크기와 정렬입니다. 정수보다 훨씬 크고, 완전히 무작위라 시간순이 아닙니다 — 무작위 키를 일반적인 B-트리 인덱스에 삽입하면 쓰기가 흩어져 규모가 커질수록 데이터베이스 성능을 해칠 수 있습니다. 또한 내장 정보가 없는데, 이는 때로 장점이고 때로 한계입니다.

시간순 ID: UUID v7, ULID, Snowflake

더 새로운 계열은 선행 비트에 타임스탬프를 넣어 정렬 문제를 해결합니다. 그래서 나중에 생성된 ID가 먼저 것보다 뒤로 정렬되면서도 전역적으로 고유합니다. UUID v7은 표준 UUID 형식 안에서 이를 합니다. ULID는 같은 일을 26자의 간결하고 URL 친화적이며 대소문자 구분 없는 인코딩으로 합니다. Snowflake ID(트위터가 대중화)는 타임스탬프·머신 ID·밀리초당 카운터를 64비트 정수에 담습니다.

시간순은 인덱스 친화적 삽입과 공짜 시간순 정렬을, 중앙 권한 없이 제공합니다. 트레이드오프는 이제 생성 시각이 ID에 드러난다는 점입니다 — 보통은 무해하지만, 가끔은 노출하고 싶지 않은 것일 수 있습니다.

이 선택이 실제로 영향을 주는 것

형식을 고를 때 네 가지 속성이 함께 움직이므로, 명시적으로 따져 보는 것이 좋습니다.

• 조율: 어느 노드든 혼자 ID를 만들 수 있나(UUID/ULID/Snowflake), 아니면 중앙 데이터베이스만(자동 증가)?
• 정렬: ID가 생성 시각순으로 정렬되나(자동 증가, v7, ULID, Snowflake) 아닌가(UUID v4)?
• 크기와 인덱스 비용: 정수가 가장 작고; 무작위 UUID가 가장 크고 인덱스 친화성이 가장 낮습니다.
• 정보 누출: 순차 정수는 물량을 드러내고 열거를 유도; 무작위 UUID는 아무것도 드러내지 않음; 시간순 ID는 타임스탬프를 드러냄.

합리적인 기본값

데이터베이스가 하나이고 ID를 공개로 노출하지 않는다면, 자동 증가 정수가 단순하고 효율적입니다. ID가 공개되거나, 여러 서비스가 생성하거나, URL 슬러그로 쓰인다면 UUID를 택하세요 — 데이터베이스 효율을 위해 대략 시간순이길 원하면 v7이나 ULID, 아무것도 드러내지 않길 특별히 원하면 v4.

무엇을 고르든 한 시스템 안에서는 일관되게 하고, 같은 종류의 엔티티에 형식을 섞지 마세요. 최악의 ID 전략은 대개 우연히 정해진 것입니다.