혹시 UUID로 시간 순 정렬이 가능하다는 것 아셨나요? - UUID v6, v7

안녕하세요. 오늘은 시간 순 정렬이 가능한 UUID v6, v7에 대해 공부하면서 UUID에 대한 내용을 간단히 정리해봤습니다.

• 참고: https://www.rfc-editor.org/rfc/rfc9562.html

 
저는 무작위 문자열을 생성해주는 UUID v4까지만 알고 있었는데 2024년 5월에 v6, v7이 RFC 9562 표준으로 채택되었더라고요.

• 링크드인에서 우연히 레몬트리 강대명님이 작성해주신 UUID, ULID 관련 글을 보고 알게 되었습니다.

 
글에서는 가장 흔하게 사용되는 v4 기준으로 UUID를 설명했으니 오해 없으시길 바랍니다 :)

---

0. UUID가 뭐에요?

Universially Unique IDentifier의 약자로 리소스의 식별자를 고유하게 생성하는 방법입니다.

• 데이터베이스의 PRIMARY KEY를 생성하는 방법 중 하나라고 생각하시면 이해하는데 도움이 될 것 같습니다.

3f1866e7-9468-4a37-a912-5929841598d9 과 같은 형태의 리소스 ID를 보신 적이 있다면 바로 그게 UUID일 거에요!
 
UUID는 중복이 발생하지 않는다고 가정해도 될 정도로 중복 확률이 매우 매우 매우 낮다는 특징이 있습니다.

• 참고: https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions

 

1. UUID를 왜 사용하는 거에요? - 매우 매우 낮은 중복 확률로 빠른 유일성 보장

혹시 'PRIMARY KEY 만드는데 복잡한 방법이 필요한가?' 라고 생각하신 분 있으실까요?
PostgreSQL의 SERIAL 타입과 같이 리소스가 생성될 때마다 ID를 1씩 증가시키면 간단하게 해결되는데 말입니다.
 
저도 처음에는 이렇게 생각했지만 서버쪽 개발을 진행하면서 단순한 문제가 아니란 것을 알게 되었습니다.
 
질문1. 만약 동시다발적으로 많은 수의 리소스 생성 요청이 서버로 전달되면 리소스 ID를 어떻게 생성해야 할까요?

동시다발적으로 많은 수의 리소스 생성 요청이 올 때

 
서버에서 뮤텍스를 사용하거나 DB의 AUTO INCREMENTAL 기능을 이용하면 됩니다. 간단합니다.
 
질문2: 하지만 서비스 사용자가 너무 많아서 분산 시스템 구조인 서비스에서는 어떻게 생성해야 할까요?

분산시스템에서 많은 수의 리소스 생성 요청이 올 때

 
이전과 같은 방법을 적용한다면, 여러 서버 인스턴스, DB 인스턴스 간의 원자성을 보장하기 위해서 지연 시간이 발생하게 됩니다.

• 서버 인스턴스 간 원자성 보장을 위한 분산락
• DB 간 리소스 ID 유일성 확인

 
지연 시간을 해소할 수 있는 방법은 없을까요? UUID의 매우 매우 매우 낮은 중복 확률이 해결책이 될 수 있습니다.
 
UUID를 사용해서 리소스 ID를 생성하면 ID가 중복될 일이 없기 때문에 인스턴스 간 검증이 필요 없어집니다.
그냥 마구 마구 리소스를 생성할 수 있는 것이죠!
 
+++
또한, UUID로 생성된 리소스 ID는 예측할 수 없기 때문에 공격자가 데이터에 무단 접근하는 경우도 막을 수 있다는 장점이 있습니다.
 

2. UUID를 사용했을 때 단점은 없을까요?

UUID는 무작위 문자열을 생성하기 때문에 식별자로 사용할 경우에 생성 시간 순 정렬이 어렵습니다.
이를 해결하기 위해서 created_at 과 같이 생성 시간을 저장하는 속성을 추가하는 것이 일반적인 방법입니다.
 
하지만 대규모 분산 시스템에서는 1) created_at도 중복이 발생할 수 있다는 점과 2) 추가적인 index로 인한 부하가 생긴다는 아쉬움이 있습니다.
 
그런데 이 아쉬움을 해결할 수 있는 것이 바로 UUID v6, v7인 것이죠!
 

3. UUID v6, v7은 어떻게 시간 순 정렬이 가능한 거에요? - 시간 정보 저장

UUID v6, v7은 시간 정보를 가장 앞단에 저장하기 때문에 시간 순 정렬이 가능합니다.

UUID v6와 v7의 형식

 
v6는 v1과의 호환성을 위해 만들어진 버전으로 일반적인 경우에는 v7을 사용하는 것이 좋습니다!
 
만약 리소스 ID 타입을 고민 중이시라면 UUID v7도 후보로 고려해보시는 것을 추천드립니다!

• 저는 이미 v4를 사용하고 있었어서 v7으로의 전환과 created_at 속성을 동시에 진행해야 합니다 ㅜ

 
하지만 이렇게 좋아보이는 UUID도 단점이 있습니다. 가독성이 부족하고 36 글자라서 꽤나 무겁습니다.

무작위로 생성되는 문자열로 인해서 올바른 사용자라고 하더라도 리소스 ID를 기억하기 너무 어렵고
다른 타입에 비해서 데이터베이스 용량을 많이 차지하는 것이 문제가 될 수 있습니다...!