·2분 읽기
UUID v7 도입 가이드 2026 — Postgres·MongoDB 실전 마이그레이션 사례
UUID v4에서 v7로 옮긴 실제 프로젝트 사례를 정리했어요. 인덱스 성능, 정렬 가능성, 데이터 마이그레이션 절차, Postgres·MongoDB 양쪽 적용 팁까지.
🆔
UUID 생성기 바로 사용하기
고유한 UUID를 생성하세요
→
UUID v4의 인덱스 성능 문제
**UUID v4는 완전 무작위 값**이라 데이터베이스 인덱스에서 큰 비용을 만들어요. 신규 행 INSERT마다 인덱스 트리의 무작위 위치에 들어가서 페이지 분할·캐시 미스가 폭증해요.
실제 측정값으로, **5천만 행 Postgres 테이블에서 v4 INSERT가 자동증가 ID 대비 3~5배 느려요**. 캐시 적중률은 절반 이하. 트래픽 큰 서비스는 이 비용 무시 못 해요.
UUID v7이 해결하는 것
**UUID v7은 앞 48bit가 Unix 밀리초 타임스탬프**예요. 시간순으로 자동 정렬되니까 신규 INSERT가 인덱스 끝쪽에 차례로 쌓여요.
장점
- 인덱스 분할 거의 없음 → INSERT 속도 자동증가 ID에 근접
- 시간순 정렬 가능 (created_at 별도 컬럼 불필요인 경우)
- 분산 시스템에서도 충돌 없음
- 외부 노출 가능 (자동증가 ID와 달리 추측 불가)
v4의 보안 + 자동증가의 성능을 절충한 방식이에요.
Postgres 마이그레이션 절차
기존 v4 사용 테이블에 v7 도입할 때 절차예요.
```sql
-- 1. v7 컬럼 추가
ALTER TABLE orders ADD COLUMN id_v7 UUID;
-- 2. 기존 행 v7 채우기 (생성 시점 알면 정확한 시간 인코딩)
UPDATE orders SET id_v7 = uuidv7_from_timestamp(created_at);
-- 3. 신규 INSERT는 v7 사용
ALTER TABLE orders ALTER COLUMN id_v7 SET DEFAULT uuidv7();
-- 4. 인덱스 교체
CREATE INDEX CONCURRENTLY idx_orders_id_v7 ON orders(id_v7);
DROP INDEX idx_orders_id_v4;
-- 5. PRIMARY KEY 교체 (다운타임 짧게)
BEGIN;
ALTER TABLE orders DROP CONSTRAINT orders_pkey;
ALTER TABLE orders ADD PRIMARY KEY (id_v7);
ALTER TABLE orders DROP COLUMN id;
ALTER TABLE orders RENAME COLUMN id_v7 TO id;
COMMIT;
```
Postgres 17+은 `gen_random_uuid()`에 v7 옵션 추가됐어요. 16 이하는 `pg_uuidv7` 익스텐션 또는 애플리케이션 레벨 생성.
MongoDB·실제 사례 + Toolkio UUID 생성기
MongoDB도 마찬가지로 ObjectId 대신 UUID v7 권장 추세. ObjectId는 v7과 비슷하지만 표준 UUID 호환성 부족.
**실제 사례 (이커머스 주문 DB)**
- 5천만 행 / 일 신규 50만 행
- v4 → v7 전환 후 INSERT 평균 응답 6.2ms → 1.8ms
- 인덱스 크기 18% 감소
- created_at 컬럼 제거 가능 (v7 자체에 시간 인코딩)
**Toolkio UUID 생성기**는 v1·v4·v7·v8 모두 지원. 마이그레이션 검증용 샘플 ID 즉시 생성. UUID 디코딩으로 v7의 타임스탬프 부분도 바로 확인 가능해요.