UUID 활용 사례 7가지 - 개발자가 꼭 알아야 할 고유 식별자 사용법
중복 없는 고유 ID가 필요할 때 UUID는 어디에 쓰일까요. 데이터베이스 키부터 파일 이름, 세션 관리까지 실무에서 바로 쓰는 활용 사례를 정리했습니다.
여러 서버에서 동시에 데이터를 생성하는데 ID가 겹치면 어떻게 될까요. 주문 번호가 충돌하고, 사용자 계정이 엉키고, 파일이 덮어쓰기됩니다. 자동 증가하는 숫자 ID로는 이 문제를 깔끔하게 풀기 어렵습니다. 이럴 때 등장하는 것이 UUID입니다.
UUID는 Universally Unique Identifier의 약자로, 전 세계 어디서 생성해도 사실상 중복되지 않는 128비트 식별자입니다. 550e8400-e29b-41d4-a716-446655440000 처럼 하이픈으로 구분된 32자리 16진수 형태로 표현됩니다. 그런데 막상 "이걸 어디에 쓰지" 하는 질문에는 막히는 경우가 많습니다. UUID 활용 사례를 구체적으로 살펴보면서 언제 쓰면 좋은지 정리해 보겠습니다.
UUID가 무엇인지부터 짚고 넘어가기
UUID는 128비트, 즉 16바이트로 이루어진 값입니다. 경우의 수가 약 2의 122제곱에 달합니다. 숫자로 환산하면 약 5.3 곱하기 10의 36제곱입니다. 매초 10억 개씩 생성해도 중복이 발생하려면 수백 년이 걸린다는 계산이 나옵니다. 현실적으로 충돌을 걱정하지 않아도 되는 수준입니다.
기존의 자동 증가 ID는 데이터베이스 한 곳에서만 번호를 발급할 수 있습니다. 1, 2, 3 순서대로 늘어나기 때문에 여러 서버가 동시에 ID를 만들면 같은 번호가 나올 위험이 있습니다. 반면 UUID는 중앙 관리자 없이 각 서버가 독립적으로 생성해도 겹치지 않습니다. 이 특성이 UUID의 가장 큰 존재 이유입니다.
UUID의 핵심 가치는 "순서"가 아니라 "고유성"입니다. 정렬이 필요하면 숫자 ID, 중복 방지가 필요하면 UUID라는 기준으로 접근하면 선택이 쉬워집니다.
버전별 차이와 선택 기준
UUID에는 여러 버전이 있고, 생성 방식이 다릅니다. 실무에서 자주 마주치는 것은 버전 1, 4, 7입니다. 용도에 맞게 골라 써야 합니다.
| 버전 | 생성 방식 | 특징 | 추천 용도 |
|---|---|---|---|
| v1 | 시간 + MAC 주소 | 생성 시각 추적 가능, MAC 노출 우려 | 시간순 정렬이 필요한 내부 시스템 |
| v4 | 난수 기반 | 가장 널리 쓰임, 예측 불가 | 일반적인 고유 ID 대부분 |
| v7 | 유닉스 타임스탬프 + 난수 | 시간순 정렬 가능 + 충돌 방지 | 데이터베이스 기본 키 |
특별한 이유가 없다면 v4를 쓰는 것이 무난합니다. 다만 데이터베이스 인덱스 성능까지 고려한다면 v7이 점점 표준으로 자리 잡고 있습니다. v7은 앞부분에 시간 정보가 들어가 정렬이 가능해, 무작위 v4보다 인덱스 단편화가 적습니다.
UUID 활용 사례 7가지
이론보다 실제 쓰임이 중요합니다. 현업에서 UUID가 어떻게 활용되는지 대표적인 사례를 정리했습니다.
1. 데이터베이스 기본 키
가장 흔한 사례입니다. 자동 증가 숫자 대신 UUID를 기본 키로 쓰면, 여러 데이터베이스를 합치거나 분산 환경으로 확장할 때 ID 충돌이 없습니다. 마이크로서비스 구조에서 특히 유용합니다.
2. 분산 시스템의 요청 추적
하나의 요청이 여러 서버를 거칠 때, 요청마다 UUID를 부여하면 로그를 추적하기 쉽습니다. 장애가 발생했을 때 어느 단계에서 문제가 생겼는지 추적 ID 하나로 따라갈 수 있습니다.
3. 파일 이름 충돌 방지
사용자가 동시에 같은 이름의 파일을 업로드해도, UUID를 파일명으로 쓰면 서로 덮어쓰지 않습니다. profile.jpg 대신 a1b2c3d4-....jpg 형태로 저장하는 방식입니다.
4. 세션과 토큰 식별
로그인 세션 ID나 비밀번호 재설정 링크의 토큰으로 UUID v4를 씁니다. 예측이 거의 불가능해 무작위 추측 공격을 막는 데 도움이 됩니다.
5. 멱등성 키
결제 같은 중요한 요청에서 같은 작업이 두 번 실행되지 않도록, 클라이언트가 UUID를 멱등성 키로 보냅니다. 서버는 같은 키의 요청을 한 번만 처리합니다.
6. 오프라인 우선 앱의 임시 ID
인터넷이 끊긴 상태에서 데이터를 만들 때, 기기에서 미리 UUID를 발급해 두면 나중에 서버와 동기화할 때 ID를 다시 받을 필요가 없습니다.
7. 온라인 도구의 임시 작업 식별
웹 기반 유틸리티에서도 UUID는 쓰입니다. 예를 들어 온라인 스톱워치 같은 도구가 여러 사용자의 세션을 구분하거나, 나이 계산기처럼 가벼운 도구라도 백엔드에서 익명 사용 통계를 묶을 때 임시 식별자로 UUID를 활용할 수 있습니다. 개인정보 없이 기록을 그룹화하기에 적합합니다.
- 중복이 치명적인 곳에 우선 적용 - 결제, 주문, 계정
- 분산 환경이라면 거의 필수 - 여러 서버가 동시에 생성
- 외부 노출 식별자는 v4 이상으로 - 보안과 예측 불가성 확보
장점과 주의할 점
UUID가 만능은 아닙니다. 장점이 분명한 만큼 단점도 명확합니다.
- 장점: 중복 없음, 중앙 관리 불필요, 분산 환경에 강함, 예측 어려움
- 단점: 숫자 ID보다 길어 저장 공간을 더 차지, 사람이 읽기 어려움, 무작위 v4는 인덱스 성능 저하
특히 데이터가 수억 건으로 늘어나는 환경에서는 v4 UUID를 기본 키로 쓸 때 인덱스 단편화로 쓰기 성능이 떨어질 수 있습니다. 이때 시간순 정렬이 가능한 v7을 쓰면 상당 부분 해결됩니다.
실무에서 쓸 때 알아두면 좋은 팁
UUID를 도입하기 전에 점검하면 좋은 것들이 있습니다. 무작정 모든 ID를 UUID로 바꾸는 것은 오히려 비효율적일 수 있습니다.
먼저 정말 분산 환경인지 확인하세요. 단일 데이터베이스에서만 동작하는 작은 서비스라면 자동 증가 숫자 ID가 더 단순하고 빠릅니다. UUID는 확장이 필요하거나 중복이 치명적인 곳에 선택적으로 적용하는 편이 좋습니다.
외부 API나 URL에 ID를 노출한다면 순차적 숫자보다 UUID가 안전합니다. 숫자 ID는 /user/1, /user/2 처럼 다음 값을 쉽게 추측할 수 있어, 권한 검사가 허술하면 다른 사용자 데이터에 접근당할 위험이 있습니다. UUID는 이런 추측을 막아줍니다. 다만 UUID 자체가 권한 검증을 대신하지는 않으니, 인증 로직은 별도로 갖춰야 합니다.
마지막으로 대부분의 언어와 프레임워크에 UUID 생성 기능이 내장되어 있습니다. 자바스크립트는 crypto.randomUUID(), 파이썬은 uuid 모듈, 자바는 UUID.randomUUID()로 한 줄이면 됩니다. 직접 구현할 필요가 없습니다.
지금 다루는 서비스에서 ID 충돌이나 분산 확장 문제가 보인다면, 가장 먼저 데이터베이스 기본 키를 v7 UUID로 전환하는 것을 검토해 보세요. 그리고 외부에 노출되는 식별자가 순차 숫자라면 v4 UUID로 바꿔 추측 공격 위험을 줄이는 것을 권합니다.
