devibe
← 홈

UUID는 왜 안 겹칠까 — v4와 v7

550e8400-e29b-41d4-a716-446655440000 — 데이터베이스 키, 업로드 파일명, 주문번호 어디서든 만나는 UUID입니다. 신기한 점은 서로 모르는 컴퓨터들이 조율 없이 각자 만들어도 겹치지 않는다는 것. 그 근거는 마법이 아니라 수학입니다.

128비트라는 크기

UUID는 128비트 값입니다. 16진수 32자리를 하이픈으로 8-4-4-4-12로 끊어 적습니다. 이 중 4비트는 버전 표시, 2비트는 규격 표시로 고정되어 있고 나머지가 실제 내용입니다. «겹치지 않음»은 보장이 아니라 확률입니다 — 다만 그 확률이 상상하기 어려운 수준으로 작아서, 실무에서는 겹치지 않는다고 «취급»해도 안전한 것입니다.

v4 — 전부 무작위

가장 널리 쓰이는 버전 4는 고정 비트를 뺀 122비트를 전부 무작위로 채웁니다. 경우의 수가 약 5.3×10³⁶가지. 생일 역설을 감안해도, 초당 10억 개씩 약 85년을 만들어야 충돌 확률이 겨우 50%에 이릅니다. 어떤 서비스도 그 근처에 가지 않으므로 «조율 없이 만들어도 안 겹친다»가 성립합니다. 단, 이 계산의 전제는 제대로 된 난수입니다 — 브라우저·서버의 암호학적 난수 생성기(crypto 계열)를 써야 하고, 시드가 뻔한 유사 난수로 만들면 전제가 무너집니다.

v1의 교훈 — 정보가 새는 식별자

초기의 버전 1은 «생성 시각 + 컴퓨터의 MAC 주소»로 만들었습니다. 유일성은 확실했지만, 식별자만 보고 언제 어느 기계에서 만들었는지 역산할 수 있다는 문제가 있었습니다. 실제로 문서 파일에 박힌 v1 UUID로 작성 컴퓨터가 추적된 사례가 알려지면서, 무작위 기반인 v4가 기본값 자리를 가져갔습니다. «식별자에 정보를 담으면 그 정보는 노출된다»는 교훈은 지금도 유효합니다.

v7 — 시간순으로 정렬되는 새 표준

v4의 약점은 데이터베이스에서 드러납니다. 완전 무작위 값은 인덱스의 아무 데나 꽂히기 때문에, 데이터가 쌓일수록 삽입 성능이 떨어집니다. 2024년 개정 표준(RFC 9562)에 새로 들어온 버전 7은 앞 48비트에 밀리초 단위 생성 시각을 넣고 나머지를 무작위로 채웁니다. 먼저 만든 값이 문자열로도 앞에 오므로 시간순 정렬이 되고, 인덱스에는 항상 «끝쪽에» 추가되어 삽입이 빠릅니다. 새로 설계하는 시스템의 DB 키라면 v7이, 정렬이 필요 없고 생성 시각조차 숨기고 싶다면 v4가 맞습니다.

만들어 보기

UUID v4 생성기에서 필요한 개수만큼 바로 만들 수 있습니다. 브라우저의 암호학적 난수(crypto.randomUUID)로 생성하므로 위의 확률 계산이 그대로 적용됩니다.

참고·출처

최종 검토: 2026-09-01