데이터베이스 테이블에 기본키를 뭘로 줄지 고민하다가 UUID를 처음 접했다. 1, 2, 3 같은 순번 대신 550e8400-e29b-41d4-a716-446655440000 같은 긴 문자열을 쓰는 이유가 뭘까.
UUID가 뭔가
UUID(Universally Unique Identifier)는 128비트 길이의 고유 식별자다. 전 세계 어디서 누가 만들어도 겹치지 않도록 설계돼 있다. 32개의 16진수 문자를 하이픈으로 구분한 8-4-4-4-12 형식으로 표기한다.
충돌 확률 UUID v4를 초당 10억 개씩 85년 동안 생성해야 겹칠 확률이 50%에 도달한다. 사실상 충돌이 일어나지 않는다고 봐도 무방하다.
auto increment 대신 UUID를 쓰는 이유
- 분산 시스템
- 서버가 여러 대일 때 auto increment는 ID 충돌 위험이 있다. UUID는 중앙 서버 없이 각 서버에서 독립적으로 생성해도 겹치지 않는다.
- 보안
- 순번 ID는 /users/1, /users/2처럼 다른 데이터를 유추할 수 있다. UUID는 무작위라서 다음 값을 예측하기 어렵다.
- 데이터 병합
- 여러 데이터베이스를 합칠 때 순번 ID는 충돌하지만, UUID는 그대로 합쳐도 문제없다.
UUID의 단점
- 저장 공간: 정수 4바이트 vs UUID 16바이트. 데이터가 수천만 건이면 인덱스 크기 차이가 난다
- 가독성: 디버깅할 때 긴 문자열을 눈으로 비교하기 힘들다
- 정렬 불가: v4는 생성 순서와 무관하므로 시간순 정렬이 안 된다 (v7은 시간 기반이라 정렬 가능)
테스트 데이터나 API 키를 빠르게 만들어야 할 때 UUID 생성기에서 원하는 개수만큼 한 번에 뽑을 수 있다. 하이픈 제거, 대문자 변환, 중괄호 형식 같은 포맷 옵션도 지원해서 용도에 맞는 형식을 바로 복사할 수 있다.
모든 상황에 UUID가 정답은 아니다. 단일 서버에 단순한 CRUD라면 auto increment가 더 낫고, 분산 환경이나 보안이 중요한 곳에서는 UUID가 합리적인 선택이다.