Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

9.5 KiB

Raw Blame History

title, source_type, url, archive_url, vendor, author, published, related_branches, related_projects, tags, created, status, confidence, last_reviewed

title

source_type

url

archive_url

vendor

author

published

related_branches

related_projects

IETF RFC 9562 — Universally Unique IDentifiers (UUIDs)

Layer: raw/official-docs/ — IETF 표준 원문 발췌 및 출처 기록. 검증된 요약은 /ingest 후 wiki/concepts/ 에 별도 작성. 본 파일은 raw 에 영구 보관.

Parent / 활용 branch

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-resource-identifier-contract	D1 (resource ID default 형식) — UUID v7 후보의 IETF 표준 normative basis
raw/branch-notes/feature-resource-identifier-contract	D7 (timestamp leak) — UUID v7 의 48bit millisecond timestamp 평문 노출 범위 및 보안 고려
raw/branch-notes/feature-resource-identifier-contract	D10 (DB primary key) — UUID v7 vs v4 monotonicity / k-sortability 가 DB index 성능에 미치는 영향의 normative basis

출처 / Source

원본 URL: https://www.rfc-editor.org/rfc/rfc9562.html
아카이브 URL: (미등록 — RFC editor 자체가 영구 URI)
저자 / 조직: K. Davis, B. Peabody, P. Leach / IETF
발행일: 2024-05 (May 2024)
마지막 확인일: 2026-05-31

왜 저장했는지 / Why archived

ca-skeleton 의 resource ID 형식 결정(D1)에서 UUID v7 후보의 normative basis 가 필요하다. RFC 9562 는 2024년 5월에 IETF 가 ratify 한 UUID 표준으로, v1/v3/v4/v5 의 기존 표준을 대체하며 v6(재정렬 v1)·v7(Unix epoch 기반 시간 정렬)·v8(커스텀) 을 새로 정의한다. D7(timestamp leak)과 D10(DB index 성능)의 normative 근거로도 직접 인용 가능한 유일한 공식 출처.

핵심 인용 / Key quotes (verbatim, 5개)

[§5.7, section-5.7-1] "UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded."

[§5.7, section-5.7-6.2] "48-bit big-endian unsigned number of the Unix Epoch timestamp in milliseconds as per Section 6.1. Occupies bits 0 through 47 (octets 0-5)."

[§5.6, section-5.6-1] "UUIDv6 is a field-compatible version of UUIDv1, reordered for improved DB locality. It is expected that UUIDv6 will primarily be implemented in contexts where UUIDv1 is used. Systems that do not involve legacy UUIDv1 SHOULD use UUIDv7 instead."

[§6.2, section-6.2-1] "Monotonicity (each subsequent value being greater than the last) is the backbone of time-based sortable UUIDs. Normally, time-based UUIDs from this document will be monotonic due to an embedded timestamp; however, implementations can guarantee additional monotonicity via the concepts covered in this section."

[§8, section-8-4] "Timestamps embedded in the UUID do pose a very small attack surface. The timestamp in conjunction with an embedded counter does signal the order of creation for a given UUID and its corresponding data but does not define anything about the data itself or the application as a whole. If UUIDs are required for use with any security operation within an application context in any shape or form, then UUIDv4 (Section 5.4) SHOULD be utilized."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
RFC9562-C1	UUID v7 은 Unix Epoch 밀리초 timestamp 를 기반으로 한 시간 정렬(time-ordered) UUID 이며, 48bit 는 밀리초 단위 Unix timestamp 를 담는다	[§5.7] "UUIDv7 features a time-ordered value field derived from the widely implemented and well-known Unix Epoch timestamp source, the number of milliseconds since midnight 1 Jan 1970 UTC, leap seconds excluded."	`official-standard`	UUID v7 를 생성·소비하는 모든 구현체	UUID v7 이 UUID v4 보다 DB index 성능이 반드시 우월하다는 것 (측정 근거는 별도 필요)
RFC9562-C2	UUID v7 의 unix_ts_ms 필드는 48bit big-endian unsigned 이며 bits 0-47 (octets 0-5) 을 점유한다 — 나머지 74bit (version·variant 제외) 는 random 또는 sub-millisecond+counter+random 조합	[§5.7] "48-bit big-endian unsigned number of the Unix Epoch timestamp in milliseconds as per Section 6.1. Occupies bits 0 through 47 (octets 0-5)."	`official-standard`	UUID v7 비트 레이아웃 구현 정밀도가 필요한 모든 컨텍스트	rand_a / rand_b 의 구체적 값이 예측 불가능함 (CSPRNG 의존)
RFC9562-C3	UUID v6 은 UUIDv1 의 field-compatible 재정렬 버전이며, RFC 는 레거시 UUIDv1 이 없는 시스템에서는 UUIDv7 사용을 SHOULD 권고한다	[§5.6] "UUIDv6 is a field-compatible version of UUIDv1, reordered for improved DB locality. Systems that do not involve legacy UUIDv1 SHOULD use UUIDv7 instead."	`official-standard`	신규 시스템의 ID 형식 선택 결정	v7 이 모든 사용 사례에서 v6 보다 우월하다는 것 — 레거시 UUIDv1 마이그레이션 경로에서는 v6 가 적합할 수 있음
RFC9562-C4	Monotonicity (이전 값보다 큰 값이 보장되는 성질) 는 시간 기반 sortable UUID 의 핵심이며, UUID v6·v7 은 embedded timestamp 덕에 기본적으로 monotonic 하다	[§6.2] "Monotonicity (each subsequent value being greater than the last) is the backbone of time-based sortable UUIDs. Normally, time-based UUIDs from this document will be monotonic due to an embedded timestamp"	`official-standard`	DB B-tree index 성능 최적화가 필요한 컨텍스트	동일 밀리초 내 대량 생성 시 추가 카운터 없이 monotonicity 가 보장된다는 것 (§6.2 Method 1/2/3 중 선택 필요)
RFC9562-C5	UUID 에 embedded 된 timestamp 는 생성 순서를 signal 하는 "very small attack surface" 이며, 보안 연산(security operation)에 UUID 가 필요하다면 UUIDv4 SHOULD 사용 권고	[§8] "Timestamps embedded in the UUID do pose a very small attack surface. [...] If UUIDs are required for use with any security operation within an application context in any shape or form, then UUIDv4 (Section 5.4) SHOULD be utilized."	`official-standard`	D7 (timestamp leak) 완화 정책 결정 및 D9 (enumeration/timing attack 방어) 결정	UUIDv7 이 일반 resource ID 로 사용하기에 부적합하다는 것 — "security operation" 의 정의는 application 맥락에 의존

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:

RFC9562-C1: UUID v7 의 설계 목적 (time-ordered), timestamp 출처 (Unix Epoch milliseconds)
RFC9562-C2: UUID v7 의 비트 레이아웃 — unix_ts_ms 48bit (bits 0-47), rand_a 12bit (bits 52-63), rand_b 62bit (bits 66-127)
RFC9562-C3: IETF 의 공식 권고 — 신규 시스템은 UUIDv6 대신 UUIDv7 SHOULD 사용
RFC9562-C4: UUID v7 의 monotonicity 특성이 시간 기반 sortability 를 제공한다는 규범적 사실
RFC9562-C5: UUID embedded timestamp 가 생성 순서를 노출하며, 보안 민감 컨텍스트에서는 UUIDv4 권고

이 자료가 증명하지 않는 것:

UUID v7 vs UUID v4 의 실제 DB index 성능 차이 수치 (정량 벤치마크는 별도 company-tech-blog 근거 필요)
Java 21 또는 특정 프레임워크에서 UUID v7 의 지원 여부 (라이브러리 호환성은 별도 조사 필요)
CUID2, ULID 등 다른 후보들과의 우열 비교 (각 후보의 공식 spec 을 별도 raw 에 보관 후 비교 필요)
UUID v7 의 timestamp leak 이 GDPR/CCPA 위반을 구성하는지 (법적 해석은 GDPR 원문 + legal 근거 별도 필요)
"security operation" 의 구체적 범위 — 이는 application 맥락 의존이며 RFC 가 명시하지 않음

내 프로젝트에 적용하려면 추가 확인이 필요한 것:

Java 생태계에서 UUID v7 생성 라이브러리 (uuid-creator, com.fasterxml.uuid) 의 실제 동작 검증 (D16)
PostgreSQL uuid native type 이 UUID v7 를 저장하는 방식 및 index locality 실측 (D10)
ca-skeleton 의 도메인 레이어에서 UUID v7 factory 구현 패턴 (D5)

메모 / Notes

§5.7-4: "Implementations SHOULD utilize UUIDv7 instead of UUIDv1 and UUIDv6 if possible" — 이 권고는 D1 결정에서 UUID v7 의 normative basis 로 직접 인용 가능.
§6.2 에서 동일 밀리초 내 monotonicity 보장 방법 3가지 (Method 1: fixed counter / Method 2: monotonic random / Method 3: sub-millisecond precision) 가 각각 rand_a 필드 활용 방식으로 설명됨. ca-skeleton 에서 어떤 method 를 선택할지는 라이브러리 의존.
§6.1 에서 UUID v7 timestamp 는 2024 기준 year 10889 AD 까지 유효 (48bit milliseconds 의 최대값).
§8-1: "Implementations SHOULD NOT assume that UUIDs are hard to guess. [...] MUST NOT be used as security capabilities" — 이는 UUID 가 token/secret 역할 불가임을 명시. D9 근거로도 활용 가능.
company-tech-blog 기반 DB 벤치마크 결과(uuid-v7-performance-benchmark)와 함께 D10 결정에 사용할 것.

같은 주제 다른 raw: raw/official-docs/ulid-spec (ULID D1 후보), raw/official-docs/cuid2-spec (CUID2 D7 완화 후보)
이 자료를 인용한 wiki 요약: (생성 시 추가)

9.5 KiB Raw Blame History