기본키 uuid vs serial id
데이터베이스 설계 시 기본키(Primary Key)로 UUID(Universally Unique Identifier)를 사용할지, Serial ID(Auto-increment)를 사용할지는 시스템의 규모와 성능, 확장성을 고려해야 하는 중요한 결정입니다.
두 방식의 특징과 장단점을 상세히 비교해 드립니다.
1. Serial ID (순차적 정수)¶
전통적으로 가장 많이 사용되는 방식으로, 1, 2, 3...과 같이 1씩 증가하는 정수(Integer/BigInt)를 사용합니다.
장점¶
- 성능 최적화: 데이터 타입의 크기가 작고(4~8바이트), 연속적인 숫자이므로 B-Tree 인덱스 구조에서 삽입 속도가 매우 빠릅니다.
- 가독성:
id=42처럼 숫자가 명확하여 디버깅이나 API 호출 시 편리합니다. - 저장 공간 효율: 인덱스 크기가 작아 메모리(Buffer Pool) 효율이 높습니다.
단점¶
- 보안 취약성: ID가 예측 가능하여 URL을 통해 데이터 총량을 추측하거나(
user/1000), 무차별 대입 공격에 노출될 수 있습니다. - 분산 환경의 한계: 여러 DB 서버를 사용하는 분산 시스템에서는 ID 중복을 피하기 위해 중앙 관리 장치가 필요하여 병목 현상이 발생할 수 있습니다.
2. UUID (범용 고유 식별자)¶
128비트(16바이트) 길이의 식별자로, 중앙 제어 없이도 전 세계적으로 중복되지 않는 ID를 생성합니다.
장점¶
- 분산 시스템 최적화: 각 서버나 클라이언트에서 독립적으로 ID를 생성해도 충돌 가능성이 거의 없어 수평 확장(Scaling out)에 유리합니다.
- 보안성: 무작위 문자열 형태이므로 다음 ID를 예측할 수 없고, 내부 데이터 규모를 외부에 노출하지 않습니다.
- 오프라인 생성 가능: DB에 연결되지 않은 상태에서도 ID를 미리 생성하여 들고 있을 수 있습니다.
단점¶
- 성능 저하: UUID v4(랜덤)는 값이 불연속적입니다. 이로 인해 DB의 클러스터드 인덱스(Clustered Index)에서 무작위 삽입이 발생하여 페이지 분할(Page Split) 및 디스크 I/O가 증가합니다.
- 저장 공간 낭비: BigInt(8바이트)보다 2배 큰 16바이트를 차지하며, 인덱스 크기도 커져 캐시 효율이 떨어집니다.
3. 요약 비교표¶
| 비교 항목 | Serial ID (Integer) | UUID (v4 기준) |
|---|---|---|
| 데이터 크기 | 4 ~ 8 Bytes | 16 Bytes |
| 예측 가능성 | 높음 (취약함) | 매우 낮음 (안전함) |
| 분산 환경 | 어려움 (중앙 관리 필요) | 매우 쉬움 (독립 생성) |
| 인덱싱 성능 | 우수 (순차 삽입) | 낮음 (무작위 삽입) |
| 가독성 | 매우 좋음 | 나쁨 (복잡함) |
4. 실무적인 선택 가이드¶
Serial ID를 추천하는 경우¶
- 내부 관리용 시스템이거나 데이터 보안이 크게 중요하지 않은 경우.
- 단일 데이터베이스 서버를 사용하며, 성능과 저장 공간 최적화가 우선순위인 경우.
- 조인(Join)이 매우 빈번하여 인덱스 효율이 극도로 중요한 경우.
UUID를 추천하는 경우¶
- 마이크로서비스 아키텍처(MSA)나 분산 DB 환경인 경우.
- 사용자 ID처럼 URL에 노출되어 보안과 개인정보 보호가 필요한 경우.
- 데이터 통합(Merge)이 잦아 ID 충돌을 원천 차단해야 하는 경우.
[Tip] 보완책: UUID v7¶
최근에는 UUID의 단점인 '무작위성'을 해결하기 위해 UUID v7이 권장됩니다. UUID v7은 앞부분에 타임스탬프를 포함하여 생성되므로, UUID의 고유성을 유지하면서도 Serial ID처럼 시간순 정렬이 가능해져 DB 인덱스 성능 저하를 크게 개선할 수 있습니다.