실무 코드 분석 중, 고유 식별자 생성하는 로직에서 UUID가 아닌 Snowflake를 사용하는 것을 보고 둘 차이가 궁금해졌다.

---

UUID

UUID는 유일성이 보장되는 8-4-4-4-12 형태의 숫자 문자열이다.

고유 식별자뿐만 아니라 Transaction ID, URI 등 고유한 값을 생성할 때 자주 사용된다.

UUID가 중복될 가능성은 매우 낮다.
중복될 확률을 50%로 높이기 위해서는 2.71경의 UUID가 생성되어야 하는데, 이는 초당 10억 개의 UUID를 100년 동안 생성해야 하는 수준이라고 한다.

구조

UUID는 총 5개의 부분으로 구성된다.

버전

UUID는 1부터 5까지의 버전이 있다.

v.1 & v.2: Timestamp UUID

UUID 생성 시점과 기기 정보를 알 수 있다.

v.3 & v.5: Namespace UUID

Namespace를 Hash 알고리즘으로 암호화해 생성하는 UUID이다. 다른 정보와 연결된 값을 만들고 싶을 때 사용하면 좋다.

v.4

가장 흔히 사용하는 UUID로, 다른 버전과 달리 외부 정보에 의존하지 않고 완전히 랜덤한 값으로 생성된다.
시간, 기기 정보, 네임스페이스 등의 정보가 없기 때문에 어디서 어떻게 생성됐는지 알 수 없어 보안 측면에서 뛰어나다.

특징

중앙 시스템에 등록하고 발급하는 과정이 없어서 생성이 빠르고 간단하다.

하지만 128bit의 길이로 인해 저장 공간을 더 많이 차지한다.
또, 순차적이지 않아서 인덱스 성능이 저하될 수 있으며, MySQL(Innodb) 환경에서 Insert, Select, Order 등의 연산 처리 시 성능 저하가 발생할 수 있다.

Snowflake ID

Snowflake ID는 유일성을 보장하는 64bit의 10진수로 이루어진 숫자다. 2010년에 Twitter에서 만들었으며 분산 환경에서 사용할 수 있다.

구조

Snowflake ID는 총 4개의 부분으로 구성되어 있다.

• sign (1bit) : 음수 양수 구분
• timestamp (41bit) : 기원 시각(epoch) 이후로 몇 밀리초가 경과했는지 나타내는 값
• worker_id (10bit) : 데이터 센터 ID 5bit + 서버 ID 5bit
• sequence (12bit) : ID 생성할 때마다 1만큼 증가. 1밀리초 경과할 때마다 0으로 초기화

특징

64bit 크기로 길이가 짧고, timestamp 기반이라 순차적이다.
데이터베이스 성능에 유리하다.

다만, timestamp 기반으로 생성되기 때문에 OS별, 인스턴스별 시간차 발생 가능성이 있으며, UUID에 비해 사용 방법이 복잡하다.

ULID

정렬 불가능한 UUID의 단점을 보완하기 위해 만들어진, 정렬 기능이 추가된 UUID이다.

구조

ULID는 대소문자를 구별하지 않고, 시간을 나타내는 값과 임의의 값으로 구성된다.

특징

timestamp 기반으로 생성하기 때문에 UUID와 달리 시간순으로 정렬이 가능하다.

하지만 UUID만큼 보편적이지 않아 지원하지 않는 시스템이 있을 수 있다는 단점도 있다.
또, timestamp 부분이 동일하면 뒤의 random 값에 따라 정렬되기에 시간순 정렬이 어렵다.

결론

빠른 식별자 생성이 목적이라면 UUID를 사용하면 되지만
실무에서는 시간순 정렬이 가능한 거래 번호 생성이 목적이기 때문에 순차적인 Snowflake를 선택했다는 것을 알게 되었다.

항상 고유 식별자는 습관처럼 UUID로 만들어 왔었는데
앞으로는 조금 더 알아보고 찾아본 후에 나에게 더 적합한 것을 적용해야겠다고 생각했다.