UUIDv7은 시간순 정렬과 단조 증가를 보장하지 않음, 시계가 뒤로 가면 타임스탬프가 폭주함

나는 UUIDv7을 여러 아이디어가 섞인 물건으로 봄. 구현마다 속성 강도가 다른 게 오히려 괜찮은 거 같음. 대충 단조 증가하는 비트만 확실히 있으면 충분하고, UUIDv8로 가는 건 싫음.

UUID 자체가 필요 없는 경우가 많음. 'You probably don't need a UUID' 글 보면 답 나옴.

SQLite 쓰는데 rowid가 자동으로 정렬 키 역할을 해서 KSUID 플러그인 만들었다가 안 씀. 웹앱에 중앙 DB면 그냥 정수 PK 쓰면 끝임.

웹앱만 하는 사람 기준으로 저런 단정은 별로 도움 안 됨. 분산 환경 하는 사람도 있음. 에이전트 쪽은 ID가 토큰을 많이 먹어서 UUID 안 쓴다는 얘기도 있더라.

이거 TOCTOU 같은 문제로 이어질 수 있는지 궁금함. 클라이언트에서 UUIDv7 찍던 팀이 규모 커지니까 시간 문제로 고생했음. 중앙 시간 서비스나 메시지 큐로 순서 맞추는 게 나을지 모르겠음.

NTP, Lamport 시계, 벡터 시계 쪽 찾아보면 됨. Spanner는 원자 시계 써서 잘 하는데 돈이 엄청 듦.

그냥 UUID는 랜덤 식별자로 쓰면 됨. 거기다 타임스탬프 욱여넣지 마라.

타임스탬프 넣은 이유가 DB 인덱스 성능 때문임. UUIDv4는 그쪽으로 진짜 별로임.

이 글 좀 트집 잡기 심하다 싶음. 나는 랜덤 UUID를 PK로 쓰면 DB 성능이 망가져서 그거 해결하려고 씀. 근데 serial PK가 그것도 해결하고 더 작아서 낫더라.

나도 2015년쯤 MySQL에서 랜덤 ID 쓰다가 성능 문제 겪어서 UUIDv7 비슷한 걸 직접 만들어 아직도 씀. 인덱스가 RAM에 안 들어가면 시간 기반이 확실히 낫음.

글이 UUIDv7 핵심 장점을 한 문장으로 넘겨버린 느낌임. 커서, 스트리밍, 채팅 메시지 정렬에 좋은 게 핵심이고, 정확한 타임스탬프가 안 나오는 건 충돌을 막으려면 오히려 필요한 거임.

맞음. 근데 '대충 정렬됨'이라는 단서를 마케팅이 빼먹는 게 문제임. 포렌식이나 은행 감사 쪽에서 잘못 쓰면 설계 망함.

UUIDv1도 다 똑같은 얘기임. 진짜 아무것도 새면 안 되면 v4 쓰면 되는데 2026년에도 이걸 모르는 개발자가 많음.

파이썬 구현은 순서 보장하려고 타임스탬프를 그냥 앞으로 밀어버리는 거임. 단조 증가 원하면 이게 맞는 동작임.

나는 uuid4만 씀. 타임스탬프 노출이 괜찮고 인덱스 성능이 중요한 특수한 경우 말고는 uuid7 쓰라는 조언이 너무 많음. 특히 Postgres PK 얘기에서 그러더라.