UUID v4와 v7 중 무엇을 써야 할까요? 이유도 함께 알아봐요

무작위 식별자만 필요하다면 UUID v4를 쓰세요. 식별자가 데이터베이스 키가 되거나 생성 시각 순으로 정렬하고 싶다면 UUID v7을 쓰세요. 두 버전 모두 128비트이고 36자리 같은 형식으로 적지만, 비트를 배열하는 방식이 달라요. 아래 UUID 생성기에서는 두 버전 모두 한 번에 1개에서 500개까지 브라우저 안에서 만들 수 있어요.

UUID 생성기코드에 쓸 고유 ID가 필요해요무료로 사용하기

UUID는 어떻게 생겼을까요

UUID, 즉 범용 고유 식별자는 128비트 숫자를 16진수 32자리로 적은 것이에요. 8, 4, 4, 4, 12자리 다섯 묶음으로 나뉘고 하이픈으로 구분해요. 예를 들면 3f2b8c1e-6d4a-4f7b-9c2e-8a1d5e0b7f63 같은 모습이에요.

숫자 가운데 고정된 부분이 두 곳 있어요. 4비트는 버전을 나타내서, v4는 셋째 묶음이 4로, v7은 7로 시작해요. 2비트는 변형(variant)을 나타내서, 넷째 묶음이 8, 9, a, b 중 하나로 시작해요. 나머지 자리가 식별자 자체를 담아요. 버전과 변형 비트가 있기 때문에 v4 UUID의 무작위 비트는 128비트가 아니라 122비트예요.

UUID v4: 무작위

v4 UUID는 고정된 비트를 빼면 나머지가 모두 무작위예요. 122개의 무작위 비트 덕분에 같은 값이 나올 확률이 아주 낮아요. v4 UUID를 10억 개 만든다고 가정해 봐요. 그중 두 개가 같을 확률은 대략 n의 제곱을 가능한 값 개수의 두 배로 나눈 값으로 구하는데, 약 10의 −19제곱 수준이에요. 즉, 중복을 막으려고 따로 설계할 필요는 거의 없어요.

이 계산은 생성기가 암호학적 난수 소스에서 비트를 가져온다는 전제에서 성립해요. 예측할 수 있는 생성기라면 이 계산은 무너져요. 이 도구는 브라우저의 암호학적 난수 소스를 사용해요. 즉 crypto.randomUUID 또는 crypto.getRandomValues를 거쳐 만들어요.

UUID v7: 시간이 먼저

v7은 RFC 9562에서 정의해요. 앞의 48비트에 밀리초 단위 유닉스 시간을 담아요. 그래서 나중에 만든 ID의 앞부분이 먼저 만든 ID보다 커요. 그다음에 버전 비트, 무작위 비트, 변형 비트, 그리고 또 무작위 비트가 이어져요. 무작위 영역 일부는 카운터로 쓸 수 있어서, 같은 밀리초 안에 여러 개를 만들어도 순서가 유지돼요.

시간이 앞에 오기 때문에, 대소문자를 통일한 상태에서 v7 ID를 문자열로 정렬하면 밀리초 단위까지 생성 시각 순으로 정렬돼요. 16진수 자리수가 고정되어 있고 시간이 앞쪽 글자에 있어서 가능한 일이에요.

시간 정보는 누구에게나 보여요. v7 UUID를 읽는 사람은 대략 언제 만들어졌는지 알 수 있어요. UUID 생성기의 검사 칸에 값을 넣어 직접 확인해 볼 수 있어요. 앞의 48비트를 날짜와 시각으로 바꿔서 보여줘요.

v7이 데이터베이스 인덱스에 어울리는 이유

데이터베이스 인덱스는 보통 B-트리 구조예요. 키 순서대로 정렬된 상태를 유지해요. 키가 v4처럼 무작위면 새 행이 인덱스의 임의의 위치에 들어가요. 그러면 데이터베이스는 인덱스의 여러 부분에 쓰기를 해야 하고, 페이지 분할과 캐시 미스가 더 많이 생겨요. 테이블이 크면 이 비용이 쌓여요.

v7 키는 시간 부분이 계속 커지므로 인덱스에 이미 있는 거의 모든 키보다 커요. 새 행은 인덱스의 끝 부분에 추가되는데, 자동 증가 숫자를 쓸 때와 비슷해요. 최근 인덱스 페이지가 메모리에 남아 있고, 쓰기도 깔끔하게 이뤄져요. 이 차이는 계속 커지는 대형 테이블에서 가장 뚜렷하고, 작은 테이블에서는 거의 드러나지 않아요.

v4와 v7 선택하기

• 데이터베이스 기본 키, 또는 시간이 지날수록 커지는 모든 테이블: v7. 인덱스가 질서 있게 유지돼요.
• 로그, 이벤트, 메시지처럼 시간순으로 자주 정렬하는 데이터: v7. ID 자체에 순서가 담겨 있어요.
• 생성 시각을 비공개로 두어야 하는 공개 ID: v4. v7 ID로는 언제 만들어졌는지 드러나요.
• 시계가 부정확한 여러 기기: v4와 v7 모두 고유성은 유지돼요. 무작위 비트가 그 역할을 하기 때문이에요. v7의 정렬 순서만 시계가 정확해야 맞아요.

두 버전 모두 표준이지만, 오래된 라이브러리는 v4만 지원하기도 해요. RFC 4122는 여러 해 동안 버전 1에서 5까지를 정의했어요. RFC 9562는 2024년 5월에 발표됐고, RFC 4122를 대체하며 버전 6, 7, 8을 정의해요. 의존하기 전에 사용 중인 라이브러리가 v7을 지원하는지 꼭 확인하세요.

UUID 저장하기

UUID를 문자열로 적으면 36자예요. 16바이트를 이진 형식으로 저장하면 훨씬 적은 공간을 써요. 많은 데이터베이스에는 이를 위한 UUID 타입이나 16바이트 이진 컬럼이 있고, 문자열보다 비교도 빨라요.

형식은 하나로 정해서 일관되게 쓰세요. 사람이 보기에는 대문자, 소문자, 하이픈, 중괄호가 모두 같은 UUID지만, 데이터베이스나 문자열 비교에서는 서로 다른 값으로 취급할 수 있어요. 생성기의 대문자, 하이픈 없음, 중괄호 옵션은 특정 형식이 필요한 시스템을 위해 있어요.

UUID를 비밀로 쓰지 마세요

UUID는 식별자예요. 비밀번호, 세션 토큰, 접근 키가 아니에요. 고유하도록 만든 값이지, 추측할 수 없도록 만든 값이 아니에요. v7 UUID에는 생성 시각도 담겨 있어요. 게다가 식별자는 링크, 로그, 이메일, 스크린숏에 그대로 붙여 넣게 되는데, 이를 본 누구나 다시 사용할 수 있어요.

접근 권한 확인은 서버에서 해야 해요. ID를 안다고 해서 그 ID가 가리키는 데이터를 보거나 바꿀 수 있어서는 안 돼요. 비밀번호, 암호문, 토큰이 필요하다면 비밀 값용으로 만들어진 생성기를 쓰세요. 비밀번호 생성기는 기기 안에서 안전한 난수로 무작위 비밀번호나 단어 조합형 암호를 만들고, 강도도 추정해 줘요. 길이와 무작위성이 왜 중요한지 더 알고 싶다면 강력한 비밀번호와 엔트로피를 읽어 보세요.

도구 사용법

1. 무작위 ID가 필요하면 버전 4를, 시간순으로 정렬되는 ID가 필요하면 버전 7을 고르세요.
2. 한 번에 만들 개수를 1개에서 500개 사이로 정하세요.
3. 특정 형식이 필요하면 대문자, 하이픈 없음, 중괄호 없음 옵션을 체크하세요.
4. 전체를 복사하거나 목록을 .txt 파일로 내려받으세요.
5. 검사 칸에 UUID를 붙여 넣으면 버전, 변형, 그리고 v7이라면 그 안에 담긴 시간을 확인할 수 있어요.

빠른 답변

v4 UUID는 고유한가요? 실제로는 그래요. 122개의 무작위 비트 덕분에 중복될 가능성이 아주 낮아서, 중복을 따로 확인할 필요는 없어요.

모든 곳에 v7을 써도 되나요? 항상 그렇지는 않아요. 데이터베이스 키나 시간순으로 정렬하는 데이터에는 v7을 쓰세요. 생성 시각을 숨겨야 한다면 v4를 쓰세요.

UUID를 비밀번호로 쓸 수 있나요? 아니요. UUID는 식별자예요. 비밀로 유지해야 하는 값에는 비밀번호 생성기를 쓰세요.

이 도구가 ID를 어디로 보내나요? 아니요. ID는 브라우저 안에서 만들어져 보여지고, 서버로 전송되지 않아요.