💭 어떤 기본키 전략을 선택할 것인가
데이터베이스를 설계할 때 대부분의 개발자는 기본키를 AUTO_INCREMENT로 설정한다. MySQL, PostgreSQL 등에서 쉽게 사용할 수 있고, JPA에서는 @GeneratedValue(strategy = GenerationType.IDENTITY) 한 줄이면 자동 증가가 되니까 말이다.
하지만 이번에 진행하는 프로젝트에서는 조금 다르게, 기본키를 UUID로 설정했다. 처음엔 낯설었지만, 직접 써보니 숫자 기반 키와는 확연히 다른 특성이 있었다. 단순히 "이게 더 좋다"가 아니라, 각각의 장단점을 명확히 이해하고 상황에 맞게 선택해야 한다는 걸 깨달았다.
이 글에서는 두 방식의 특징과 실전 활용 사례를 정리해본다.
📍 AUTO_INCREMENT : 단순하고 안정적인 숫자 증가
AUTO_INCREMENT는 말 그대로 "자동 증가"하는 숫자다. 데이터가 추가될 때마다 DB가 알아서 1씩 증가된 값을 부여한다.
CREATE TABLE user (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255)
);JPA에서는 이렇게 사용한다.
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;장점
- 직관적이고 단순하다 : 1, 2, 3... 순서대로 증가하니 이해하기 쉽다
- INSERT 성능이 안정적이다 : 인덱스가 순차적으로 쌓여 B-Tree 구조에서 효율적이다
- 정렬과 조회가 명확하다 : ID만 봐도 생성 순서를 바로 알 수 있다
- 저장 공간이 효율적이다 : BIGINT는 8바이트로 충분하다
단점
- 분산 환경에서 충돌 위험이 있다 : 여러 DB 인스턴스가 동시에 데이터를 생성하면 ID가 겹칠 수 있다
- 보안상 취약할 수 있다 :
/users/101,/users/102처럼 노출되면 다음 ID를 예측할 수 있다 - 마이그레이션 시 충돌 가능성 : 개발/스테이징/운영 환경 간 데이터 이동 시 기존 ID 범위와 겹칠 수 있다
📍 UUID : 전역적으로 유일한 식별자
UUID(Universally Unique Identifier)는 128비트 고유 식별자다. 랜덤 문자열처럼 보이지만, 충돌 확률은 사실상 0에 가깝다.
CREATE TABLE user (
id CHAR(36) PRIMARY KEY, -- 또는 BINARY(16)
name VARCHAR(255)
);JPA에서는 이렇게 사용한다.
@Id
@GeneratedValue(strategy = GenerationType.UUID)
private UUID id;장점
- 전역적 유일성을 보장한다 : 여러 서버, 여러 DB에서 생성해도 ID 충돌이 없다
- 보안상 안전하다 : ID를 보고 다른 데이터를 추측할 수 없다
- 마이그레이션이 자유롭다 : 외부 시스템 연동이나 환경 간 데이터 이동 시 충돌 걱정이 없다
- 애플리케이션 레벨에서 생성 가능하다 : DB에 INSERT 전에 미리 ID를 알 수 있다
단점
- 인덱스 효율이 떨어진다 : 무작위 값이라 B-Tree 인덱스에서 페이지 분할이 자주 발생한다
- 저장 공간을 많이 차지한다 : CHAR(36)은 36바이트, BINARY(16)도 16바이트로 BIGINT보다 크다
- 가독성이 떨어진다 : 로그나 콘솔에서
550e8400-e29b-41d4-a716-446655440000같은 값을 확인하기 불편하다
🤼♂️ 프로젝트 특성에 따라 선택하자!
이번 프로젝트에서 UUID를 선택한 이유는 분산 환경을 고려했기 때문이다. 각 서비스가 독립적으로 데이터를 생성해야 하는 구조(ex. MSA)에서는 UUID가 더 자연스러운 선택이다. 특히 외부 API 연동이나 환경별 데이터 이동이 잦은 상황에서, 충돌 걱정 없이 안정적으로 데이터를 다룰 수 있다.
상황별 추천 방식
| 상황 | 추천 방식 | 이유 |
|---|---|---|
| 단일 DB, 낮은 트래픽 | AUTO_INCREMENT | 단순하고 빠르며 인덱스 효율이 좋다 |
| 여러 서버 / MSA 환경 | UUID | 전역 유일성을 보장한다 |
| 외부 API 노출 가능성 | UUID | 보안상 안전하다 |
| 생성 순서가 중요한 경우 | AUTO_INCREMENT | 정렬과 조회가 명확하다 |
| 데이터 마이그레이션이 잦은 경우 | UUID | 환경 간 충돌 걱정이 없다 |
| 높은 INSERT 성능이 필요한 경우 | AUTO_INCREMENT | 순차적 인덱스가 B-Tree에 유리하다 |
👏 정리
기본키를 숫자로 할지, UUID로 할지는 정답이 있는 문제가 아니다. DB 구조, 트래픽, 분산 여부, 마이그레이션 빈도 등 프로젝트의 성격에 따라 달라진다.
중요한 건 기술 그 자체보다 "왜 이 방식을 선택했는가"다.
- UUID는 분산 시스템에 강하고, 전역 유일성을 보장한다
- AUTO_INCREMENT는 단일 시스템에서 단순하고 빠르며 효율적이다
결국 설계의 출발점은 기술이 아니라, 프로젝트의 맥락과 목적이다.
두 방식의 트레이드오프를 이해하고, 상황에 맞는 선택을 하는 것. 그게 바로 좋은 설계의 시작이다..!
