데이터베이스 테이블을 설계할 때 기본키(PK)를 뭘로 쓸지 고민하게 된다. 숫자를 1부터 순서대로 넣는 auto increment가 익숙한데, 최근에는 UUID를 쓰는 프로젝트가 많아졌다. 이유가 있다.
UUID가 뭔가
UUID(Universally Unique Identifier)는 128비트 길이의 고유 식별자다. 550e8400-e29b-41d4-a716-446655440000처럼 생겼고, 전 세계 어디서 누가 만들어도 같은 값이 나올 확률이 거의 0에 가깝다. 그래서 서로 다른 시스템 간에 데이터를 주고받을 때 ID 충돌 걱정 없이 사용할 수 있다.
auto increment 대신 UUID를 쓰는 이유
| 항목 | auto increment | UUID v4 |
|---|---|---|
| 고유성 범위 | 테이블 내 | 전 세계 |
| 예측 가능성 | 다음 ID 추측 가능 | 완전 랜덤 |
| 분산 환경 | 서버 간 충돌 가능 | 충돌 없음 |
| 보안 | URL에 노출 시 위험 | ID로 정보 유추 불가 |
| 크기 | 4~8바이트 | 16바이트 |
마이크로서비스 아키텍처처럼 여러 서버에서 독립적으로 데이터를 생성하는 환경에서는 UUID가 거의 필수다. 서버끼리 통신해서 ID를 조율할 필요 없이 각자 생성하면 되니까 구조가 단순해진다.
UUID v4의 생성 원리
UUID에는 여러 버전이 있는데, 가장 많이 쓰이는 건 v4다. v4는 암호학적 난수 생성기를 사용해서 122비트를 랜덤으로 채우고, 나머지 6비트에 버전(4)과 변형 정보를 넣는다. 이론적으로 중복이 발생하려면 1초에 10억 개씩 만들어도 수십 년이 걸린다.
UUID를 생성하는 방법
코드에서 직접 만들 수도 있지만, 테스트 데이터가 필요하거나 빠르게 몇 개만 만들고 싶을 때는 UUID 생성기가 편하다. 한 번에 최대 1,000개까지 대량 생성이 되고, 하이픈 제거, 중괄호 감싸기, URN 형식 등 4가지 출력 포맷을 선택할 수 있다. 결과를 TXT 파일로 다운로드하는 것도 가능하다.
TIP UUID를 DB 인덱스로 쓸 때는 정렬 성능이 떨어질 수 있다. 이를 보완한 UUID v7(시간 기반 정렬)이 2024년 표준화됐으니, 새 프로젝트라면 v7도 검토해볼 만하다.
고유한 ID가 필요할 때 UUID v4를 쓰면 대부분의 상황을 커버할 수 있다. 개념을 이해하고 나면 어렵지 않다.