UUID vs 자동증가 ID 비교 - 성능, 보안, 확장성으로 본 기본키 선택 가이드
데이터베이스를 설계할 때 기본키로 자동증가 정수를 쓸지 UUID를 쓸지 고민되시나요. 성능과 저장 공간, 보안, 분산 환경까지 실제 차이를 비교해 상황별 최적의 선택을 정리했습니다.
데이터베이스 테이블을 처음 설계할 때 누구나 한 번은 멈칫합니다. 기본키를 그냥 자동증가 정수로 둘지, 아니면 UUID를 쓸지 결정해야 하기 때문입니다. 작은 프로젝트라면 별 차이가 없어 보이지만, 데이터가 수백만 건으로 늘어나거나 서버를 여러 대로 나누는 순간 이 선택의 무게가 확 달라집니다.
둘 다 행을 고유하게 식별한다는 목적은 같습니다. 하지만 저장 방식, 성능, 보안, 확장성에서 분명한 차이가 있습니다. 하나씩 짚어보겠습니다.
자동증가 ID와 UUID, 무엇이 다른가
자동증가 ID는 1, 2, 3처럼 순차적으로 증가하는 정수입니다. MySQL의 AUTO_INCREMENT, PostgreSQL의 SERIAL이 대표적입니다. 데이터베이스가 새 행을 넣을 때마다 직전 값에 1을 더해 자동으로 채워줍니다.
UUID(Universally Unique Identifier)는 128비트 크기의 식별자입니다. 550e8400-e29b-41d4-a716-446655440000처럼 하이픈으로 구분된 36자 문자열로 표현됩니다. 사실상 중복될 확률이 0에 가까워 어디서 생성하든 겹치지 않습니다.
UUID에도 버전이 있다
- v1: 타임스탬프와 네트워크 노드 정보(MAC 주소)를 조합. 생성 시각 추적이 가능
- v4: 122비트가 완전 무작위. 가장 널리 쓰이지만 정렬이 안 됨
- v7: 앞부분에 타임스탬프를 넣어 시간순 정렬이 가능. 인덱스 친화적이라 최근 주목받는 버전
성능과 저장 공간 비교
가장 큰 실질적 차이는 인덱스 성능입니다. 자동증가 ID는 항상 마지막에 값이 추가되므로 B-Tree 인덱스의 끝부분에만 데이터가 쌓입니다. 페이지 분할이 거의 없어 삽입이 빠릅니다.
반면 UUID v4는 값이 무작위라 인덱스 곳곳에 흩어져 삽입됩니다. 이 과정에서 페이지 분할과 단편화가 발생해 쓰기 성능이 떨어지고 인덱스 크기도 커집니다. v7이 등장한 이유가 바로 이 문제를 풀기 위해서입니다.
| 비교 항목 | 자동증가 ID | UUID (v4) |
|---|---|---|
| 저장 크기 | 4~8바이트 (INT/BIGINT) | 16바이트(BINARY) / 36바이트(문자열) |
| 생성 위치 | DB 서버 | 애플리케이션 등 어디서나 |
| 인덱스 정렬 | 순차적, 효율적 | 무작위, 단편화 발생 |
| 추측 가능성 | 높음 (다음 값 예측 가능) | 거의 불가능 |
| 가독성 | 좋음 | 나쁨 |
보안과 정보 노출 측면
자동증가 ID의 가장 큰 약점은 예측 가능성입니다. URL이 /users/1024라면 누구나 /users/1025를 시도해볼 수 있습니다. 권한 검증이 허술하면 다른 사용자의 데이터에 접근하는 IDOR 취약점으로 이어집니다.
또한 순차 ID는 사업 규모를 그대로 노출합니다. 주문 번호가 order/3201이면 경쟁사가 대략적인 누적 주문량을 짐작할 수 있습니다. UUID는 무작위라 이런 추론이 불가능합니다.
식별자를 외부에 그대로 드러내는 순간, 그 식별자는 단순한 번호가 아니라 정보가 됩니다.
이 때문에 외부에 노출되는 링크는 식별자를 가리는 경우가 많습니다. 미투 단축URL 같은 단축 서비스가 긴 주소를 짧은 무작위 키로 바꿔주는 것도 같은 맥락입니다. 원본 자원의 구조를 숨기면서 공유는 간편해집니다.
분산 시스템에서의 차이
서버가 한 대일 때는 자동증가가 편합니다. 하지만 데이터베이스를 여러 대로 샤딩하거나, 여러 서비스가 동시에 데이터를 만들면 문제가 생깁니다. 각 DB가 1번부터 번호를 매기면 ID가 충돌하기 때문입니다.
UUID는 중앙 조율 없이 어디서든 고유한 값을 만들 수 있습니다. 애플리케이션 코드, 모바일 기기, 다른 마이크로서비스 어디서 생성해도 겹치지 않습니다. DB에 저장하기 전에 ID를 미리 알 수 있다는 점도 큰 장점입니다.
어떤 상황에 무엇을 선택할까
- 자동증가 ID 추천: 단일 DB, 내부 관리용 테이블, 최고의 쓰기 성능이 필요할 때
- UUID 추천: 분산/샤딩 환경, 외부에 노출하는 식별자, 클라이언트에서 ID를 먼저 만들어야 할 때, 데이터 병합이 잦을 때
실무에서는 둘을 섞기도 합니다. 내부 기본키는 BIGINT 자동증가로 두어 성능을 챙기고, 외부에 노출하는 식별자만 UUID로 따로 두는 방식입니다. 정렬 성능이 중요하면서 UUID의 장점도 원한다면 v7을 검토할 가치가 있습니다.
핵심은 두 가지입니다. 첫째, 외부에 노출되는 식별자는 순차 정수를 피하세요. 둘째, 분산 확장 계획이 있다면 처음부터 UUID(가능하면 v7)를 고려하는 편이 나중의 마이그레이션 비용을 줄여줍니다.
