# Ask HN: 실제 UUID v4 충돌을 겪었습니다... > Clean Markdown view of GeekNews topic #29330. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29330](https://news.hada.io/topic?id=29330) - GeekNews Markdown: [https://news.hada.io/topic/29330.md](https://news.hada.io/topic/29330.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-10T02:38:30+09:00 - Updated: 2026-05-10T02:38:30+09:00 - Original source: [news.ycombinator.com](https://news.ycombinator.com/item?id=48060054) - Points: 1 - Comments: 1 ## Topic Body - 데이터베이스가 오늘 **중복 UUID v4**를 감지했고, 기존 값은 2025년에 추가된 레코드의 `b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd`와 완전히 같았음 - 사용 중인 패키지는 npm의 **uuid**이며, `import { v4 as uuidv4 } from "uuid";` 뒤 `const document_id = uuidv4();`로 생성해 데이터베이스에 넣는 방식이라고 함 - 데이터베이스에는 약 **15,000개 레코드**만 있어 통계적으로 불가능해 보이는데, 같은 일을 겪은 사람이 있는지 묻고 있음 ## Comments ### Comment 57128 - Author: neo - Created: 2026-05-10T02:38:30+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48060054) - jandrewrogers: 이건 의외로 흔함. **UUIDv4의 안전성**은 고품질 엔트로피 소스가 있다는 가정에 기대는데, 하드웨어 결함, 일반적인 소프트웨어 버그, 개발자의 엔트로피 이해 부족으로 이 가정이 쉽게 깨짐 엔트로피 소스가 망가졌는지 감지하는 건 꽤 비싸서 거의 아무도 안 하고, 결국 충돌이 난 뒤에야 알게 됨. 그래서 많은 고신뢰·고보증 시스템에서는 UUIDv4가 명시적으로 금지됨 - LocalH: 그래서 CloudFlare가 **라바 램프 벽** 같은 걸 만든 것임. 그 자체가 엄청난 엔트로피 소스라기보다는, 난수 생성과 엔트로피 개념을 잘 모르는 사람에게도 눈에 보이게 만드는 효과가 있음 엔트로피 소스는 많을수록 좋고, 상당수는 비결정적이어야 함. 작은 규모의 게임에서도 마우스 좌표, 버튼 입력 간격, 시작 버튼 누르기 전 프레임 수 같은 값을 초기 시드에 섞으면, 내부적으로 의사난수 생성기를 쓰더라도 예측이 훨씬 어려워짐. CloudFlare가 엔트로피 소스를 100개 미만으로 쓴다면 실망스러울 듯함 - Groxx: 불량 하드웨어에서 그럴듯한 중복을 본 적이 있음. 또 일부 UUID 라이브러리에서는 **뒤쪽이 0으로 잔뜩 채워지는 중복 패턴**도 매우 흔했음 예전 Go 쪽처럼 “N바이트 요청했는데 3바이트만 반환됐으니 N-3바이트를 다시 요청해야 한다”는 반환값을 검증하지 않으면 생김. 대부분의 하드웨어나 운영체제에서는 잘 안 터져서 사람들이 확인하지 않고, 어느 날 운영 환경에서 수만 건 충돌로 드러남 - thecloud: 고신뢰 시스템에서는 UUIDv4 대신 어떤 대안을 쓰는지 궁금함 - throwaway_19sz: 믿기 어려운 웃긴 얘기지만 사실임. 10년 전 친구가 고성장 스타트업 CTO로 합류했는데, 개발자가 200명쯤 되는 회사였고 첫 주에 **UUID 생성 전용 마이크로서비스**가 있다는 걸 발견함 엔드포인트 하나에 전담 엔지니어 3명, 심지어 데이터베이스 담당자까지 있었음. 새 “안전한” UUID가 필요하면 모든 팀이 이 서비스를 호출해야 했고, 서비스는 UUID를 생성한 뒤 자체 DB에 기존 발급 UUID가 있는지 확인하고, 없으면 삽입한 다음 반환했음. 마음의 평화를 위한 것이었는지, 그 팀은 자체 칸반 보드와 스프린트도 굴리고 있었음 - Aurornis: 초기에는 자원이 제한된 스타트업에서 일해서, 뭔가를 만들거나 사람을 뽑을 때마다 신중히 결정했음. 그때라면 이 얘기는 소설처럼 보였을 것임 나중에 들어간 스타트업은 누군가 새 걱정거리를 떠올릴 때마다 새 마이크로서비스와 새 팀이 생겼음. 분기 목표가 명시적으로 엔지니어링 팀 규모 확대였고, 3~4명짜리 팀들이 자기 스프린트와 계획 회의에서 스스로 일을 만들어냈음. 안정적인 프로젝트 인력을 급한 일로 옮기자고 제안했지만, 엔지니어 수를 특정 숫자까지 늘려야 하는 KPI와 충돌한다며 막혔음 - wongarsu: 언젠가는 전사 글로벌 **128비트 증가 카운터**로 최적화할 사람이 나올 것임. 커지는 DB를 조회하지 않고 현재 카운터를 가져와 1 증가시켜 나눠주면 O(1)이고 빠름 고가용성과 전 세계 배포를 위해 각 인스턴스에 전용 ID 범위를 주면 샤딩도 가능함. 상위 비트 일부는 데이터센터 ID, 몇 비트는 그 안의 ID 생성기 인스턴스에 예약하면 됨. 잠깐, 이거 어디서 본 것 같은데… Twitter가 아직도 이 방식을 쓰는지, 결국 바꿨는지 궁금함 - roryirvine: 큰 실리콘밸리 기술 회사 깊숙한 곳에서 비슷한 걸 봤음. 다만 사용 중 UUID의 마스터 목록이 다른 부서가 운영하는 외부 **CMDB 서비스**에 있어서 절차가 더 복잡했음 매일 DB 덤프를 받아 “임시” ID 생성 때 확인하고, CMDB에 제대로 제출된 뒤에야 “확정” 상태가 됐음. 임시 ID가 운영에서 쓰이지 않도록 가드레일도 있었고, 쓰지 않은 확정 ID를 재활용하는 절차도 있었음. 마지막으로 들었을 때는 로컬 DB 캐시를 Zookeeper로 옮기는 6개월짜리 프로젝트를 18개월째 하고 있었음 - CodesInChaos: 보통 **시드가 부족한 의사난수 생성기** 때문에 생김. UUID를 백엔드에서 만들었는지 프런트엔드에서 만들었는지가 중요함 프런트엔드는 의도적 충돌을 포함해 여러 이유로 근본적으로 신뢰하기 어려우니 충돌 처리가 필요함. 백엔드는 안정적으로 만들 수 있음. 과거에는 VM에서 이런 문제가 있었지만 요즘은 해결됐어야 하고, 강하게 샌드박싱된 프로세스가 안전하지 않은 대체 난수 경로를 쓰면 여전히 터질 수 있음. 프로세스나 VM 포크도 상태 복제로 충돌을 만들 수 있음 - danpalmer: Segment라는 분석 회사가 웹브라우저에서 생성한 UUID에 제품 전체를 기대고 있었다는 얘기를 들은 적이 있음. 여기저기 **브라우저 UUID 충돌**이 나서, 제품이 근본적으로 유용한 데이터를 만들 수 없는 상태였던 것 같음. 지금은 고쳤기를 바람 - _kst_: “Pro Git”의 한 구절이 떠오름. <[https://git-scm.com/book/en/v2]()> 지구상의 65억 명이 모두 매초 Linux 커널 전체 히스토리 규모의 코드를 만들어 거대한 Git 저장소 하나에 푸시해도, SHA-1 객체 충돌 확률이 50%가 되려면 대략 2년이 걸린다는 예시였음. 그래서 자연적인 SHA-1 충돌은 팀원 전원이 같은 밤 서로 무관한 늑대 습격으로 죽을 확률보다 낮다는 표현이 좋았음. SHA-1 해시는 난수가 아니고 160비트라 UUIDv4와 다르지만, **무관한 늑대 습격**이라는 비유가 마음에 듦 - mega_dean: 카드 한 벌을 섞는 순열이 얼마나 큰지 설명하는 이 페이지가 떠오름: [https://czep.net/weblog/52cards.html]() 적도에서 10억 년에 한 걸음씩 지구를 돌고, 한 바퀴마다 태평양에서 물 한 방울을 빼고, 바다가 비면 종이 한 장을 쌓는 과정을 태양까지 닿을 만큼 반복해도 52!초 타이머의 앞 세 자리는 변하지 않는다는 식의 비유임 - swiftcoder: 반대로 **사전상 공격**은 꽤 현실적이고, 그 테스트 케이스 파일을 생각 없이 Git에 커밋한 사람들이 증언하듯 상당히 골치 아픔 - TacticalCoder: Git 팀이 SHA-1에 더해 SHA256 같은 다른 해시를 선택적으로 제공하려고 열심히 작업 중이지 않았나? - e12e: 관련 논의가 여기 있음: [https://github.com/uuidjs/uuid/issues/546]() 예를 들면 `crypto.getRandomValues()`를 googlebot에서 테스트했더니 **결정적**이었다는 내용이 있음 - D2OQZG8l5BI1S06: 말은 됨. 다만 왜 브라우저에서 UUID를 생성하는지 모르겠음. 목적을 무너뜨리는 것처럼 보임 - adyavanapalli: 지금 말하는 일은 너무 희귀해서, 이 순간 지구 전체가 소행성에 파괴될 가능성이 더 높을 정도임 - thomasmg: 그렇게까지 희귀하진 않음. 계산해 보니 운석에 맞는 것보다는 드물었고, 그 내용과 생일 문제를 Wikipedia의 UUID 문서에 추가한 적이 있음. 몇 년 전 삭제·교체됐지만 실제로 운석에 맞았지만 다리 부상으로 생존한 여성이 있었다고 들었음. UUID 충돌이 났다면 소프트웨어 버그나 컴퓨터 이상일 가능성이 압도적으로 높고, 우주선일 수도 있음. 우주선이 메모리나 CPU를 건드리는 일은 생각보다 흔함 - delichon: 소행성이 말줄임표를 입력하고 댓글 추가 버튼을 누를 확률 정도임 - spindump8930: 다른 사람들이 말했듯 **시드를 잘못 주면** 매우 흔함. 비유하자면 지구가 SF식 고밀도 소행성대에 둘러싸여 있을 때 맞을 확률 정도임 - juancn: 난수 생성기 초기화가 이상하거나 엔트로피가 부족한 것 아닌가? 커스터마이즈하지 않았다면 `crypto.getRandomValues(rnds8)`를 쓰는데, `getRandomValues`는 **최소 엔트로피 양**을 명시하지 않음 - Hizonner: 난수 생성기가 심하게 잘못됐을 가능성이 거의 확실하고, 아마 시드 처리 문제일 것임. 암호화도 같이 망가뜨리고 있을 가능성이 큼 - Geee: 양자역학의 다세계 해석에 따르면 모든 UUID가 같은 우주 분기가 하나쯤은 있을 것임. 그 세계 사람들은 무슨 생각을 하고 있을지 상상됨 - suprjami: 아마 “그 UUID”를 만든 뒤 끝에 증가하는 숫자를 붙여 유일하게 만들 것임. 문제 해결 - BobaFloutist: 그뿐 아니라 UUID 하나만 빼고 전부 같은 우주가 훨씬 더 많을 것임. 다만 그 하나까지 쓰지 못했을 뿐임. 또는 처음 두 개만 유일하고 이후 모든 UUID가 그 둘 중 하나인 우주도 있음 - nyantaro1: 그래서 Everett식 접근을 별로 좋아하지 않음 - mittermayr: 말이 안 된다는 데 완전히 동의함. 그래도 추측해 보면, 예전에는 사용자의 휴대폰에서 UUIDv4를 생성해 DB로 보냈고, 오늘 아침 충돌한 UUID는 Ubuntu 서버에서 생성됐다는 차이가 있음 UUIDv4가 어떻게 생성되는지, 생성 머신의 특성이 알고리즘에 들어가는지는 잘 모르겠지만, 유일하게 떠오르는 변화는 예전에는 기기에서 만들다가 몇 달 전부터 서버에서 만들게 됐다는 것임 - AntiUSAbah: 사용자에게 UUID를 생성하게 했다는 건가? 솔직히 실제 UUID 충돌보다 뭔가 이상한 구현을 했을 가능성이 더 높아 보임. DB가 그 충돌을 어떻게 표시했는지 궁금함 - wongarsu: 둘 다 기기에서 생성한 UUID였다면 충돌 가능성을 이해할 수 있음. 저가형 단말에서 난수 생성기 시드가 제대로 잡히지 않아 “무작위” 값이 충돌한 사례가 있었고, 라이브러리가 제대로 된 암호학적 난수 생성기 대신 값싼 난수 생성기를 쓰면 더 나빠짐 하지만 서버에서는 특히 2026년에는 그러면 안 됨. 과거에는 VM 난수 시드가 문제였지만, 지금은 덜해야 함. 한쪽 UUID가 나쁘게 생성됐더라도 정말 무작위인 UUID가 그것과 충돌할 확률은 매우 낮으니, 양쪽 생성기 모두에 문제가 있어야 함 - stubish: UUIDv4 충돌은 통계적으로 극도로 희박함. 더 그럴듯한 건 두 시스템이 **같은 시드**를 썼다는 것임. 시드가 몇 바이트뿐이면 충돌 가능성이 수십억 분의 1이나 수백만 분의 1까지 올라감 - dweez: 이 재미있는 글을 다시 볼 때임: [https://jasonfantl.com/posts/Universal-Unique-IDs/]() 우주 전체를 거대한 컴퓨터로 바꿔 열죽음까지 UUID만 생성한다면, ID 공간에 몇 비트가 필요할까? - CodeWriter23: 거기까지 갈 거면 이건 필수임: [https://www.decisionproblem.com/paperclips/]() - ipaddr: “지금 지구상의 모든 인간이 운석에 맞을까 걱정하느냐”는 예시는 별로일 수 있음. 운석 하나가 세계를 끝낼 수도 있고, 충분한 시간이 주어지면 그 가능성은 높아짐 - beejiu: UUID를 클라이언트 쪽에서 생성하는지 서버 쪽에서 생성하는지 궁금함. 클라이언트 쪽이라면 크롤러 봇 때문일 수 있음. 예를 들어 **Googlebot**은 결정적 “무작위성”으로 JavaScript를 실행함 - adzm: 그 패키지의 이전 사고에서도 Googlebot의 무작위성 부족이 결론이었음: [https://github.com/uuidjs/uuid/issues/546]() - AgentME: 거의 확실히 이 경우이거나, 시스템 난수 생성기를 제대로 쓰지 못한 패키지의 오래된 버전을 썼거나, JS crypto API를 재구현한 낡고 깨진 폴리필을 로드했거나, 동일한 VM 스냅샷을 여러 서버에서 재개해 난수 상태가 복제되는 이상한 호스팅 구성일 가능성이 큼 이런 종류의 설명이 진짜 무작위 충돌보다 몇 자릿수는 더 그럴듯함 - merlindru: 시드 문제일 가능성이 큼. 아니라는 걸 증명할 수 있다면 아마 조금 유명해질 수 있음 - erlkonig: 데이터가 충분히 많으면 무작위 값은 언젠가 충돌할 수 있고, 그때 소프트웨어가 얼마나 튼튼한지 보게 된다고 계속 팀에 말해 옴 그래도 경력 많은 개발자, 팀 리드, CIO 중에도 불가능하다고 믿고 그 상황을 처리하는 코드를 전혀 쓰지 않는 사람이 많음. 그러면 나쁜 난수 생성기가 언제든 예상보다 훨씬 빨리 시스템을 망가뜨릴 수 있고, 감지·재생성 없이 동시 손상도 가능함. `malloc()` 성공 여부를 확인하지 않는 부류와 같아 보임. “불가능하다면 비트를 너무 많이 쓰는 거 아닌가?”라고 묻곤 함 - leni536: 우연히 일어난 게 아니라 어딘가에 버그가 있음. 대충 보니 패키지는 JS 런타임의 `crypto.randomUUID()`를 호출하는 것 같고, 이건 항상 제대로 시드되어 있어야 함 런타임에 버그가 있을 가능성은 극히 낮아 보이지만 모를 일임. 어떤 **JS 런타임**을 쓰는지 궁금함 - jbverschoor: 가장 그럴듯한 원인은 `uuid` 패키지가 의존하는 난수 생성 패키지가 최근에 침해되어 “무작위” 숫자를 예측 가능하게 만들었다는 것임. 그 결과 공급망 공격으로 많은 암호화, SSL, 통화 관련 프로젝트가 위험해졌을 수 있음 - jbverschoor: 3주 전에 바뀐 `uuid/src/rng.ts`에서 무작위 배열이 `const`가 됐음. 모든 호출이 같은 무작위 배열을 공유하게 됨 이후 호출이 이전 무작위 코드를 갱신하므로, 중요한 걸 생성했다면 행운을 빌어야 함. 예전 코드는 `slice()`로 새 복사본을 만들었음. 의도치 않은 변경일 수도 있지만, 난수 두 개를 만들어 서로 다른지 확인하는 테스트도 안 통과할 것 같은데 어떻게 지나갔는지 모르겠음 - pif: 고품질 엔트로피 소스가 있어도 “그럴 것이다”를 “반드시 그렇다”로 바꿀 수는 없음. 추측하기 어려운 값이 필요하면 암호학 쪽을 찾으면 되지만, **보장된 유일성**이 필요하면 직접 만들어야 함 - athrowaway3z: 간단한 경험칙은 ID에 무작위 값 외에 **타임스탬프**를 넣을 수 있는지 생각하는 것임. 대개 답은 예이고, UUIDv7이면 충분함 정보 누출이 받아들일 수 없다는 증명을 직접 써낼 만큼 문제를 깊게 검토했다면, 축하함. 그 시스템은 강한 암호학적 해시를 쓰거나 귀찮으면 UUIDv5를 써도 될 만큼 복잡하고 느린 시스템일 가능성이 큼 - darqis: PostgreSQL 18은 **uuidv7**을 네이티브로 지원하고, 기본값은 `unique`와 `uuid7()`로 두면 됨 - tumdum_: 시드가 나쁜 의사난수 생성기임 - serf: 4.72 × 10²⁸분의 1, 즉 47.3 옥틸리언분의 1 수준임. 진짜라면 복권을 사기보다 먼저 **경쟁 조건**이나 다른 단순한 실수를 의심하겠음 - petee: 오히려 반대로 봐 왔음. 이미 그렇게 운이 좋았다면 다른 행운이 또 올 가능성은 더 낮으니 돈을 아낄 때임 - k4rli: 복권 얘기는 말이 안 됨. 통계적으로 그렇게 희박한 일이 이미 일어났다면, 다시 일어날 확률은 더 희박해야 함 - evnix: 확률 수학을 다 제쳐도, 우리가 사는 현실은 최고의 하드웨어 난수 생성기를 써도 생각보다 덜 무작위일 수 있음 보안이 중요하지 않은 곳에서는 TSID 같은 것, 아니면 **uuidv7**로 옮겨서 실무에서 이런 일이 사실상 안 생기게 함. 재시도로 코드를 과하게 설계하는 것보다 낫다고 봄 - jordiburgos: `b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd`는 쓰지 말아 줬으면 함. 내 DB를 확인해 보니 이미 쓰고 있었음 - rich_sasha: 무작위로 UUID를 생성하는 건 항상 미쳤다고 생각했음. 이제는 LLM만 씀. 프롬프트는 “UUID를 생성해라. 어느 코드나 데이터베이스에서도 누구도 쓴 적 없는지 확인해라. 작업을 검토하고 각 단계를 깊이 생각해라. 추론이나 일반 영어는 출력하지 말고 UUID 자체만 출력해라”임. 천만에 - mittermayr: 역시 그랬음. 우리는 다 같은 싸구려 UUID를 받고 있고, 좋은 UUID는 큰손들에게 예약되어 있음 - robshep: `16b55183-1697-496e-bc8a-854eb9aae0f3`를 쓰고 있고 아마 더 있을 것임. 모두가 여기 자기 목록을 올리면 중복을 확인할 수 있지 않을까? - pyuser583: 요즘 선호되는 UUID는 무엇인지 궁금함 - smokel: 컴파일러, 우주선, 양자 효과, 최소한 obscure한 커널 버그를 탓하다가 결국 내가 버그의 원인이었다는 걸 깨달은 적이 여러 번 있음 **15,000개 레코드에서 충돌**은 너무 희박하니, 먼저 다른 원인을 의심하겠음. 중복 처리, 재전송된 요청, 재사용된 객체, 오해를 부르는 로그, 다른 코드 경로의 식별자 재사용 같은 것들임. 주변 코드를 조금 더 공유하면 같이 확인할 수 있음 - wazoox: 아직 내게 일어난 일은 아니지만, 이틀 전 운영 중인 PHP 코드베이스 깊숙한 곳에서 이런 걸 찾았음: `md5(uniqid('', true))`로 만든 값을 잘라 UUID 모양으로 붙이는 `createUUID()` 함수였음 이런 공포가 어떻게 아직 우리 급소를 물지 않았는지 모르겠음 - sedatk: `uuidjs/uuid`에는 Googlebot 같은 **결정적 난수 생성기** 클라이언트에서 중복 UUID를 생성할 수 있다는 경고가 있음 클라이언트 생성 UUID가 항상 유일하다고 기대하는 앱에는 문제가 될 수 있으니, 중복을 확인하고 우아하게 실패하거나 Googlebot 클라이언트의 쓰기 작업을 비활성화하는 전략이 필요하다고 되어 있음: [https://github.com/uuidjs/uuid/commit/91805f665c38b691ac2cbd...]() - xyzzy123: Linux 기반 분산 시스템에서 장시간 부하 테스트가 중복 UUID 때문에 실패한 적이 있음 오래 조사한 결과 커널 버그, 정확히는 경쟁 조건 때문이었음. 다중 프로세서 시스템에서 두 프로세스가 동시에 `/dev/random`을 읽으면 매우 드물게, 대략 백만 분의 1 수준으로 같은 바이트를 받을 수 있었음. 먼저 난수 생성기 초기화를 볼 것 같음 - baq: 실행 중인 VM이 엔트로피를 전부 가상화로 날려 버린 것 같음 - Imustaskforhelp: 이 경우가 꽤 그럴듯해 보임. 관련해서 조금 멋진 물건도 있음: [https://eu.mouser.com/new/leetronics/leetronics-infinite-noi...]() - glaslong: 라바 램프를 좀 사야 함 - 0xfffafaCrash: UUID가 프런트엔드에서 생성됐는지 백엔드에서 생성됐는지 궁금함. 프런트엔드라면 엔트로피 문제보다 클라이언트 코드나 요청이 조작되어 **이미 알려진 UUID**가 주입됐을 가능성에 걸겠음 - latentframe: 엔지니어링에서 가장 위험한 말 중 하나가 **통계적으로 불가능**임. 규모가 충분히 커지면 극단적 사례는 이론이 아니라 운영 이벤트가 됨 - 8organicbits: 작년에 실제 충돌과 그 라이브러리까지 포함해 글을 쓴 적이 있음: [https://alexsci.com/blog/uuid-oops/]() UUID가 충돌 저항성을 가지려면 엄격히 지켜야 하는 제약이 많고, 이번 건은 난수 생성기에 문제가 있을 가능성이 커 보임 - nu11ptr: 결국 **엔트로피 소스** 문제임. 그래서 항상 루프 안에서 생성하고 삽입함. 충돌이 나면 우아하게 처리할 수 있음 - sbuttgereit: “기술적으로 불가능”은 아님. 아주 기술적으로 가능함. 좋은 무작위성이 있으면 매우, 매우 희박할 뿐이고, UUIDv4가 중복 값을 생성하는 걸 기술적으로 막는 것은 없음 - beardyw: 멍청한 질문일 수 있지만, 날짜를 16진수 초 단위로라도 붙이면 안 되나? 몇 바이트만 추가해도 지금 괜찮은 건 미래에도 괜찮도록 보장할 수 있을 것 같은데 - flohofwoe: 타임스탬프 데이터를 포함하는 다른 UUID 변형을 쓰면 됨. 예를 들어 v1이나 v7이 있고, MAC 주소를 포함하는 변형도 있음 - itsyonas: 그냥 uuidv7을 쓰면 됨 - mittermayr: 맞음, 어떤 식의 추가적인 준무작위 데이터라도 이런 일을 막는 데 도움이 됐을 것임. 다만 그게 UUIDv4의 아이디어이기도 함. 이미 많은 무작위성과 시간이 들어 있다고 생각했음 - mdavid626: 다른 설명도 가능함. 예를 들어 누군가 요청을 수동으로 건드렸거나 DB를 건드렸을 수 있음 - radial_symmetry: 나도 한 번 이런 일을 겪고 내가 미쳐 가는 줄 알았는데, 여기 댓글을 읽으니 안심됨 - NKosmatos: “기술적으로 불가능”은 아님. 불가능한 게 아니라 아주, 아주 희박한 것임. 복권이나 Powerball을 사 봐야 할 듯함 “improbable”이라는 말을 쓸 때마다 [https://hitchhikers.fandom.com/wiki/Infinite_Improbability_D...]()가 떠오름 - sebazzz: 사실 복권을 사면 안 됨. 그 충돌과 복권 당첨이 둘 다 일어나는 건 더 드묾 - rithdmc: 상상도 못 할 일임 - sudb: 내 프로젝트 중 하나에서 CUID2를 선택한 게 실제로 좋은 생각이었다는 보상을 처음 느꼈음: [https://github.com/paralleldrive/cuid2]()