UUID: Auto-Increment가 충분하지 않을 때

데이터베이스가 자동 증가 ID를 써. 1, 2, 3, 4... 간단해.

그러다 두 데이터베이스를 병합해. 또는 URL에 ID를 노출해. 또는 누가 URL의 ID를 증가시켜서 다른 사용자의 데이터를 추측할 수 있다는 걸 알아내.

순차 ID는 문제가 있어. UUID가 그 중 일부를 해결해.

UUID가 뭐야?

Universally Unique Identifier. 128비트 숫자, 보통 대시가 있는 32개 16진 문자로 표시돼:

550e8400-e29b-41d4-a716-446655440000

UUID 생성 뒤의 수학이 충돌을 천문학적으로 불가능하게 만들어. 다른 머신에서, 다른 시간에, 조율 없이 UUID를 생성할 수 있고 충돌하지 않아.

왜 그냥 Auto-Increment를 안 써?

보안. 순차 ID는 정보를 누출해. 사용자 ID가 15847이면 공격자는 최소 15846명의 다른 사용자가 있다는 걸 알아. 순차 ID를 시도해서 리소스를 열거할 수 있어.

분산 시스템. ID를 생성하는 여러 서버가 중복을 피하려고 조율이 필요해. UUID는 조율이 필요 없어.

데이터 병합. 순차 ID가 있는 데이터베이스를 결합하는 건 악몽이야. UUID는 깔끔하게 병합돼.

오프라인 생성. 모바일 앱이 UUID로 오프라인에서 레코드를 만들 수 있어. 서버 할당 ID를 기다릴 필요 없어.

UUID 버전

모든 UUID가 같은 방식으로 만들어지는 건 아니야.

버전 1: 타임스탬프와 MAC 주소 기반. 고유하지만 언제 어디서 만들어졌는지 드러내.

버전 4: 무작위. 가장 흔해. 정보 누출 없음.

버전 7: 타임스탬프 기반이지만 정렬 가능. 더 새로운 데이터베이스가 이득.

대부분의 사용은 버전 4 (무작위)가 올바른 선택이야.

트레이드오프

UUID는 무료가 아니야.

크기. 정수의 32비트 vs 128비트. 더 큰 인덱스, 더 많은 저장소.

가독성. user/15가 user/550e8400-e29b-41d4-a716-446655440000보다 기억하기 쉬워.

성능. 무작위 UUID가 어떤 데이터베이스에서 인덱스 단편화를 일으켜. UUID v7이 이걸 해결해.

디버깅. 로그에서 UUID 검색하는 건 단순 숫자보다 지루해.

언제 뭘 쓸지

Auto-increment를 써:

• 내부 전용, 사용자에게 절대 노출 안 됨
• 단순 애플리케이션, 단일 데이터베이스
• 인간 가독성이 중요

UUID를 써:

• ID가 URL이나 API에 나타남
• 여러 시스템이 레코드 생성
• 모호함을 통한 보안이 도움
• 데이터 병합이 가능

실전 팁

MySQL에서 UUID를 기본 키로 쓰지 마. 대신 보조 고유 컬럼으로 써. MySQL의 클러스터 인덱스는 무작위 UUID로 성능이 나빠.

UUID v7 고려. 데이터베이스가 지원하면 타임스탬프 정렬 가능 UUID가 양쪽의 장점을 줘.

URL용 대시 제거. 550e8400e29b41d4a716446655440000은 여전히 유효한 UUID고 URL에서 더 짧아.

---

UUID는 순차 ID가 할 수 없는 실제 문제를 해결해. 하지만 항상 올바른 선택은 아니야. UUID가 더 전문적으로 들리기 때문이 아니라 실제 요구사항에 따라 골라.