UUID/GUID: 무엇이며 언제 사용해야 하는가

2026년 3월 31일 · 12분 읽기

UUID 심층 이해

대량의 데이터를 다루는 소프트웨어 프로젝트를 진행해본 적이 있다면, UUID 또는 범용 고유 식별자(Universally Unique Identifier)라는 용어를 접해봤을 것입니다. 이 128비트 식별자는 서로 다른 시스템, 데이터베이스, 심지어 조직 간에도 각 데이터가 고유함을 보장해야 할 때 매우 유용합니다.

UUID를 사물에 부여하는 매우 긴 이름으로 생각해보세요. 그래서 누구도 같은 이름을 갖지 않게 됩니다. 데이터를 위한 바코드와 같으며, 다음과 같은 형태입니다: 550e8400-e29b-41d4-a716-446655440000. 구조는 하이픈으로 구분된 5개 그룹으로 나뉜 32개의 16진수 문자로 구성됩니다.

UUID의 아름다움은 통계적 고유성에 있습니다. 2¹²⁸개의 가능한 조합(약 340언데실리온)으로, 중복된 UUID를 생성할 확률은 천문학적으로 낮아 실용적인 목적으로는 무시할 수 있는 수준입니다. 이를 관점에서 보면, 향후 100년 동안 매초 10억 개의 UUID를 생성해도 충돌 가능성은 거의 0에 가깝습니다.

현대 소프트웨어에서 UUID가 중요한 이유

제품으로 가득 찬 거대한 창고를 상상해보세요. 모든 품목에는 고유한 라벨이 필요합니다. UUID는 시스템이 여러 작업을 동시에 처리하더라도 각 제품이 고유한 식별자를 갖도록 보장하여 혼동을 방지합니다. 이는 ID를 발급하는 중앙 권한이 없는 여러 위치에 분산된 시스템에 특히 유용합니다.

분산 애플리케이션에서 ID 충돌을 방지하여 각 시스템이 다른 시스템의 데이터와 충돌하지 않고 독립적으로 작동할 수 있게 합니다. 이러한 분산형 ID 생성 방식이 마이크로서비스 아키텍처, 분산 데이터베이스, 클라우드 네이티브 애플리케이션에서 UUID를 필수적으로 만듭니다.

UUID 구조 및 버전

내부적으로 UUID는 충돌을 피하는 데 도움이 되는 신중하게 설계된 구조를 가지고 있습니다. 생성 방식에는 버전에 따라 타임스탬프, 호스트 식별자, 난수와 같은 정보 비트가 포함됩니다. 이 설정은 여러 플랫폼에 걸친 시스템에서 작업할 때 핵심인 모든 것을 고유하게 유지하는 데 도움이 됩니다.

UUID 구성 요소 분석

표준 UUID는 다음 형식을 따릅니다: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• Time-low (16진수 8자리): 타임스탬프의 처음 32비트
• Time-mid (16진수 4자리): 타임스탬프의 중간 16비트
• Time-high-and-version (16진수 4자리): 타임스탬프의 상위 12비트와 4비트 버전 번호
• Clock-seq-and-reserved (16진수 4자리): 클록 시퀀스 및 변형 비트
• Node (16진수 12자리): 48비트 노드 식별자(주로 MAC 주소 또는 난수 값)

UUID 버전 설명

UUID 사양은 각각 다른 사용 사례에 최적화된 여러 버전을 정의합니다. 이러한 버전을 이해하면 애플리케이션에 적합한 버전을 선택하는 데 도움이 됩니다.

버전 4: 랜덤 UUID

사람들이 버전 4 UUID에 대해 이야기할 때, 타임스탬프나 호스트 식별자의 힌트 없이 완전히 무작위인 ID를 의미합니다. ID가 생성된 시기나 장소에 대한 정보 유출을 원하지 않는 프라이버시가 중요한 상황에 완벽합니다.

버전 4는 간단하고 안전하며 시스템 간 조정이 필요하지 않기 때문에 가장 일반적으로 사용되는 UUID 버전입니다. 무작위성은 암호학적으로 안전한 난수 생성기에서 나오므로 예측 불가능성을 보장합니다.

실제로 어떻게 작동하는지 보려면 UUID 생성기 도구로 직접 UUID를 생성해보세요.

버전 1과 6: 시간 기반 UUID

버전 1 UUID는 타임스탬프와 생성 머신의 MAC 주소를 포함합니다. 이는 생성 시간별로 정렬할 수 있어 데이터베이스 및 로깅 시스템에 유용할 수 있습니다. 그러나 MAC 주소 포함은 생성 머신에 대한 정보를 드러내므로 프라이버시 문제를 야기합니다.

버전 6은 타임스탬프 비트를 재정렬하여 UUID를 자연스럽게 정렬 가능하게 만들어 버전 1의 일부 단점을 해결하는 새로운 사양입니다. 이는 데이터베이스 인덱스 성능을 크게 향상시킵니다.

버전 7: 현대적 선택

버전 7은 UUID 제품군의 최신 추가 사항이며 두 세계의 장점을 나타냅니다. 정렬 가능성을 위해 Unix 타임스탬프를 사용하지만 프라이버시를 위해 MAC 주소를 난수 데이터로 대체합니다. 이는 성능과 보안이 모두 필요한 현대 분산 시스템에 이상적입니다.

많은 개발자들이 시간 기반 정렬의 이점과 무작위 생성의 프라이버시를 결합하기 때문에 이제 새 프로젝트의 기본 UUID 버전으로 버전 7을 선택하고 있습니다.

논쟁: UUID vs. 자동 증가 ID

데이터베이스 설계에서 가장 뜨거운 논쟁 중 하나는 기본 키로 UUID를 사용할지 전통적인 자동 증가 정수를 사용할지입니다. 두 접근 방식 모두 장점이 있으며, 올바른 선택은 특정 요구 사항에 따라 달라집니다.

UUID의 장점

• 분산 생성: 중앙 권한이나 데이터베이스 시퀀스 불필요
• 병합 친화적: ID 충돌 없이 여러 소스의 데이터를 쉽게 결합
• 모호함을 통한 보안: 비순차적 ID로 유효한 식별자 추측 어려움
• 오프라인 생성: 데이터베이스 삽입 전에 ID 생성 가능
• 분산 시스템: 마이크로서비스 및 샤딩된 데이터베이스에 완벽
• 경쟁 조건 없음: 여러 시스템이 동시에 ID 생성 가능

자동 증가 ID의 장점

• 작은 크기: UUID의 16바이트 대비 4-8바이트
• 더 나은 인덱스 성능: 순차적 정수가 캐시 친화적
• 사람이 읽기 쉬움: 대화 및 디버깅에서 참조하기 쉬움
• 예측 가능한 순서: 자연스러운 시간순 정렬
• 적은 저장 공간: 대규모 데이터베이스에서 상당한 절약
• 빠른 조인: 정수 비교가 계산적으로 저렴

성능 비교

하이브리드 접근 방식

많은 현대 애플리케이션은 하이브리드 전략을 사용합니다: 내부 데이터베이스 작업에는 자동 증가 ID를, 외부 API에는 UUID를 사용합니다. 이는 내부적으로 정수의 성능 이점을 제공하면서 외부 세계에 비순차적이고 안전한 식별자를 노출합니다.

예를 들어, 데이터베이스에는 자동 증가 정수가 있는 id 열과 API 응답 및 URL에 사용되는 별도의 uuid 열이 있을 수 있습니다. 이 접근 방식은 전자상거래 플랫폼과 SaaS 애플리케이션에서 일반적입니다.

UUID를 사용해야 할 때: 이상적인 시나리오

UUID가 빛나는 시기를 이해하면 정보에 입각한 아키텍처 결정을 내리는 데 도움이 됩니다. 다음은 UUID가 유익할 뿐만 아니라 종종 필수적인 시나리오입니다.

분산 시스템 및 마이크로서비스

마이크로서비스 아키텍처에서는 서로 다른 서비스가 독립적으로 레코드를 생성해야 하는 경우가 많습니다. UUID는 ID를 생성할 때 서비스 간 조정의 필요성을 제거합니다. 각 서비스는 다른 서비스와의 충돌을 걱정하지 않고 자체 식별자를 생성할 수 있습니다.

이는 시스템의 모든 서비스에서 생성할 수 있는 고유 식별자가 필요한 이벤트가 있는 이벤트 기반 아키텍처에서 특히 유용합니다.

데이터 동기화 및 복제

여러 소스 간에 데이터를 동기화할 때