이 글은 ID를 “유일한 값"으로만 보지 않고, 정렬성, 분산 생성 가능성, 인덱스 비용, 노출 안전성, 장애 복구성을 함께 보는 플레이북입니다. 같이 보면 좋은 글은 DB 스키마 설계 기본기, 샤딩과 Consistent Hashing, Clock Skew 시간 의미론, 멱등성 설계입니다.

이 글에서 얻는 것

• UUIDv4, UUIDv7, Snowflake, DB sequence를 언제 고르면 되는지 기준을 잡을 수 있습니다.
• ID의 정렬성과 랜덤성이 B-Tree 인덱스, 파티셔닝, 쓰기 처리량에 주는 영향을 이해할 수 있습니다.
• 외부 노출 ID와 내부 PK를 분리해야 하는 조건을 판단할 수 있습니다.
• ID 생성 장애, clock rollback, worker id 충돌 같은 운영 리스크를 숫자 기준으로 점검할 수 있습니다.

핵심 개념/이슈

1) ID는 유일성보다 접근 패턴이 먼저다

ID 전략을 고를 때 첫 질문은 “충돌하지 않는가"가 아니라 “이 ID로 어떻게 읽고 쓰는가"입니다. 예를 들어 단일 DB에 주문을 저장하고 최신순 목록을 자주 본다면 단조 증가 bigint나 UUIDv7처럼 시간 정렬성이 있는 ID가 유리합니다. 반대로 외부에 공개되는 초대 코드나 다운로드 토큰처럼 추측이 어려워야 하는 값은 랜덤성이 더 중요합니다.

실무에서는 아래처럼 나눠 보는 편이 안전합니다.

핵심은 하나의 ID가 모든 요구를 만족하지 않는다는 점입니다. 내부 PK는 bigint로 두고 외부 노출용 public_id는 UUIDv7이나 난수 slug로 별도 관리하는 설계가 흔히 더 낫습니다. 특히 외부 API에서 order_id=12345처럼 연속값을 노출하면 고객 수, 주문량, 데이터 증가 속도가 추측될 수 있습니다.

2) UUIDv4는 편하지만 쓰기 인덱스에는 비용이 있다

UUIDv4는 중앙 조율 없이 만들 수 있고 충돌 가능성이 매우 낮습니다. 그래서 마이크로서비스나 클라이언트 생성 ID에 편합니다. 문제는 랜덤성입니다. B-Tree 인덱스는 정렬된 키에 최적화되어 있는데, UUIDv4는 새 값이 인덱스 여기저기에 꽂힙니다. 테이블이 커질수록 page split, cache miss, 인덱스 bloat가 늘 수 있습니다.

쓰기량이 낮은 관리 테이블이나 외부 공개 식별자에는 UUIDv4가 충분합니다. 하지만 초당 수천 건 이상 쓰는 주문, 이벤트, 로그 테이블의 클러스터링 키로 UUIDv4를 쓰면 비용이 커질 수 있습니다. 이때는 UUIDv7이나 Snowflake처럼 시간 정렬성이 있는 ID를 검토합니다. UUIDv7은 표준 UUID 형식을 유지하면서 앞부분에 시간 정보를 담아 정렬성을 개선합니다. Snowflake 계열은 보통 timestamp, worker id, sequence를 조합해 64bit 정수로 만듭니다.

단, 시간 정렬 ID는 “시간을 믿는 설계"가 됩니다. clock skew와 rollback을 다루지 않으면 같은 worker에서 역전 ID가 생기거나, 밀리초당 sequence 한도를 넘을 수 있습니다. 이 부분은 Clock Skew 시간 의미론과 연결해서 봐야 합니다.

3) Snowflake는 빠르지만 운영 계약이 필요하다

Snowflake 계열 ID는 대개 아래 구조를 가집니다.

timestamp bits | worker bits | sequence bits

예를 들어 41bit timestamp, 10bit worker id, 12bit sequence를 쓰면 worker당 밀리초 4096개 수준의 ID를 만들 수 있습니다. 장점은 빠르고, 정렬 가능하며, bigint라 DB 인덱스와 조인에 유리하다는 점입니다. 단점은 worker id 중복과 clock rollback에 민감하다는 점입니다.

운영 기준은 숫자로 정해야 합니다.

Snowflake를 단순 유틸 클래스로 넣으면 위험합니다. ID generator는 사실상 작은 인프라 컴포넌트입니다. 배포, 재시작, 오토스케일링, 리전 장애, 시간 동기화 정책과 함께 운영해야 합니다. 특히 컨테이너가 빠르게 뜨고 지는 환경에서는 worker id를 환경변수로 손으로 넣는 방식이 오래가지 않습니다.

4) DB sequence는 구식이 아니라 강한 선택지다

분산 시스템을 공부하다 보면 중앙 sequence를 무조건 피해야 할 것처럼 느끼기 쉽습니다. 하지만 단일 primary DB 안에서 쓰는 핵심 도메인 테이블이라면 DB sequence는 여전히 좋은 선택입니다. 충돌이 없고, 작고, 정렬되고, FK와 조인 비용이 낮습니다. 트랜잭션과 백업, 복제도 DB가 책임집니다.

문제는 범위입니다. 여러 서비스가 각자 DB를 갖고 같은 ID 공간을 공유해야 하거나, 오프라인 생성이 필요하거나, 리전별 쓰기가 필요하면 단일 sequence가 병목 또는 결합점이 됩니다. 반대로 한 서비스의 내부 row id인데 괜히 UUIDv4를 PK로 쓰면 인덱스와 저장 비용만 늘어날 수 있습니다.

의사결정 기준은 간단합니다.

1. 단일 쓰기 DB가 있고 ID를 DB 밖에서 먼저 알아야 할 필요가 없다면 sequence를 우선 검토합니다.
2. API 요청 전에 클라이언트가 ID를 만들어 재시도해야 한다면 UUID 계열을 검토합니다.
3. 다중 writer에서 정렬 가능한 bigint가 필요하면 Snowflake 계열을 검토합니다.
4. 외부 노출과 내부 조인 요구가 충돌하면 내부 PK와 public id를 분리합니다.

실무 적용

1) 내부 PK와 외부 ID를 분리한다

가장 실용적인 기본안은 내부 PK와 외부 노출 ID를 분리하는 것입니다.

CREATE TABLE orders (
  id BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  public_id UUID NOT NULL UNIQUE,
  user_id BIGINT NOT NULL,
  status VARCHAR(30) NOT NULL,
  created_at TIMESTAMP NOT NULL
);

CREATE INDEX idx_orders_user_created ON orders (user_id, created_at DESC, id DESC);

내부 로직과 FK는 id를 쓰고, 외부 API는 public_id를 씁니다. 이 구조는 저장 비용이 조금 늘지만 운영상 이점이 큽니다. 내부 조인은 빠르게 유지하면서도 외부에서는 연속값을 숨길 수 있습니다. 고객 지원, 로그 추적, API 응답에서는 public id를 쓰고, 내부 배치와 DB 조인은 numeric id를 쓰면 됩니다.

단, public id를 만들 때도 정책을 정해야 합니다. 단순 조회 URL에 쓰는 값이면 UUIDv7로 정렬성을 얻을 수 있고, 보안 토큰처럼 예측 불가능성이 핵심이면 충분한 난수 기반 token을 별도로 써야 합니다. public id와 secret token을 같은 것으로 쓰지 않는 것이 좋습니다.

2) ID 전략을 테이블 유형별로 나눈다

모든 테이블에 같은 전략을 강제하면 비용이 생깁니다. 출발점은 아래 정도가 현실적입니다.

샤딩이 들어가면 ID는 더 중요해집니다. ID 안에 tenant나 shard hint를 넣을지, 별도 shard key를 둘지 결정해야 합니다. 이 부분은 샤딩과 Consistent Hashing과 DB 스키마 설계 기본기를 같이 봐야 합니다.

3) ID 생성기를 관측 가능하게 만든다

ID 생성은 너무 기본 기능이라 모니터링에서 빠지기 쉽습니다. 하지만 생성기가 멈추면 쓰기 경로 전체가 멈춥니다. 최소한 아래 지표는 남깁니다.

• id_generation_latency_p95
• id_generation_error_total
• clock_rollback_detected_total
• worker_id_conflict_total
• sequence_overflow_wait_total
• generated_id_monotonic_violation_total

Snowflake 계열은 특히 clock rollback과 worker id 충돌을 알람으로 둬야 합니다. UUID 계열은 충돌보다 라이브러리 버전, 형식 검증, 저장 타입이 중요합니다. DB에는 가능하면 문자열 UUID보다 native UUID 타입이나 binary 타입을 검토하고, 정렬과 인덱스 조건을 실제 데이터량으로 확인합니다.

트레이드오프/주의점

첫째, 정렬 가능한 ID는 추측 가능성도 일부 생깁니다. UUIDv7이나 Snowflake는 시간 정보가 들어가기 때문에 “언제 생성됐는가"를 어느 정도 드러낼 수 있습니다. 공개 URL에서 생성 시각 자체가 민감하면 별도 random token을 쓰는 편이 낫습니다.

둘째, Snowflake는 라이브러리 하나로 끝나지 않습니다. worker id 배정, 시간 동기화, overflow 대기, 장애 시 생성 중단 정책이 없으면 운영 중 더 어려워집니다. 초당 생성량이 크지 않다면 UUIDv7이나 DB sequence가 더 단순할 수 있습니다.

셋째, DB sequence는 중앙화가 단점이지만 동시에 장점입니다. 단일 DB 트랜잭션 안에서 생성되고 커밋되므로 추적이 쉽습니다. 실제 병목이 sequence인지 확인하기 전에 “분산형이 더 멋있다"는 이유로 바꾸면 구조만 복잡해질 수 있습니다.

넷째, ID는 멱등성과 다릅니다. 주문 ID가 같다고 같은 요청이라는 뜻은 아닙니다. 재시도 중복을 막으려면 멱등성 설계와 UPSERT, UNIQUE 제약, 멱등 키처럼 별도 처리 이력을 설계해야 합니다.

체크리스트 또는 연습

운영 체크리스트

• 내부 PK와 외부 노출 ID를 분리할지 결정했다.
• ID 전략을 테이블 유형별로 문서화했다.
• 외부에 auto increment 값을 직접 노출하지 않는다.
• UUIDv4를 고쓰기 테이블 PK로 쓸 때 인덱스 bloat와 쓰기 p95를 측정했다.
• Snowflake 계열이면 worker id 중복, clock rollback, sequence overflow 정책이 있다.
• ID 생성 실패 지표와 알람이 있다.
• 멱등 키를 비즈니스 ID와 혼동하지 않는다.

연습

1. 현재 서비스의 상위 쓰기 테이블 5개를 고르고 PK 타입, 외부 노출 여부, 초당 쓰기량, 주요 조회 패턴을 표로 정리해 보세요.
2. UUIDv4 PK 테이블이 있다면 최신순 조회와 대량 insert에서 인덱스 크기, p95 지연, page split 징후를 확인해 보세요.
3. 주문 생성 API를 가정하고 내부 id, 외부 public_id, 재시도용 idempotency_key를 각각 어떤 타입으로 둘지 설계해 보세요.
4. Snowflake ID generator를 쓴다고 가정하고 clock rollback 20ms, worker id 중복, millisecond sequence overflow가 발생했을 때의 동작을 문서화해 보세요.

좋은 ID 전략은 가장 최신 기술을 고르는 것이 아니라, 읽기·쓰기·노출·운영 복구 요구를 분리해서 가장 단순한 조합을 고르는 것입니다. ID는 한 번 퍼지면 바꾸기 어렵습니다. 그래서 초기에 30분 더 써서 기준을 세우는 것이, 나중에 수십억 row를 마이그레이션하는 것보다 훨씬 쌉니다.