모든 V4 UUID

 (everyuuid.com)
3P by GN⁺ | ★ favorite | 댓글 2개
  • everyuuid.com은 숫자 인덱스와 UUID 문자열을 나란히 보여주는 단순 목록형 페이지임
  • 각 항목은 긴 0 패딩 숫자와 인덱스, 다음 줄의 하이픈 포함 UUID로 구성됨
  • UUID 문자열은 세 번째 그룹이 4로 시작하는 V4 UUID 형식을 따르며, 497dcba3-ecbf-4587-a2dd-5eb0665e6880 같은 값이 표시됨
  • 본문에는 생성 방식, 사용법, API, 코드 설명이 없어 목록 자체를 열람하는 형태에 가까움
  • 확인된 범위는 0부터 49까지이며, 페이지의 실질적 정보는 제목과 UUID 목록에 집중됨

숫자와 UUID를 나란히 보여주는 구성

  • 제목은 Every UUID V4임
  • 본문은 숫자 항목과 UUID 문자열이 반복되는 목록으로 구성됨
  • 요약된 범위는 0부터 49까지임

항목이 표시되는 방식

  • 각 항목은 두 줄 구조임
    • 첫 줄: 긴 0 문자열 뒤에 인덱스 숫자가 붙음
    • 둘째 줄: 하이픈으로 구분된 UUID 문자열이 표시됨
  • 앞부분 예시는 다음과 같음
    • 000000000000000000000000000000000000 0
    • 497dcba3-ecbf-4587-a2dd-5eb0665e6880
  • 마지막으로 제공된 항목은 다음과 같음
    • 00000000000000000000000000000000000 49
    • 08716598-71f7-4e8b-9fff-e36d2c5d21fe

설명보다 데이터 목록에 가까운 페이지

  • UUID 문자열들은 하이픈으로 구분된 UUID 표기 형식을 사용함
  • UUID 생성 원리, 정렬 기준, 전체 범위, 검색 기능, 라이선스, 구현 방식에 대한 설명은 없음
  • 기술 해설이나 사용 안내 없이 데이터 목록만 제공됨

함께 보면 좋은 글 β

nemorize   [-]

The most offensive sentence I could come up with leetspeak/hexspeak is this one:
fe11a710-babe-4150-ace5-b19b1accd1cc
(Yes it's a valid UUID)
(I am so sorry)

oh... 👀

답변달기
GN⁺   [-]
Hacker News 의견들

  • 검색이 실제로 동작한다는 점이 가장 인상적임. 훌륭한 마술이 늘 그렇듯, 설명을 듣고 나면 아주 단순해 보이기도 함
    궁금한 사람을 위한 프로젝트 동작 설명 글: https://eieio.games/blog/writing-down-every-uuid/
    처음에는 정확한 UUID만 검색해봤는데, 전문 검색까지 지원한다는 걸 알고 더 놀랐음

    • 그 트릭이 마술처럼 느껴졌다니 정말 기쁨. 이게 가능하다는 걸 깨달았을 때 나도 놀라고 즐거웠는데, 다른 사람도 같은 감정을 느낄지 확신이 없었음
      물론 이렇게 많은 실용성을 제공하는 것도 자랑스러움. 드디어 필요에 딱 맞는 UUID를 찾아 쓸 수 있게 됨
    • Teller가 말한 “마술은 때로 누군가가 합리적으로 기대할 수 있는 것보다 훨씬 더 많은 시간을 어떤 일에 쓴 것일 뿐”이라는 관찰의 좋은 예임
    • 전문 검색 설명은 처음 예상했던 것보다 약간 더 영리했음. 처음엔 다음/이전 버튼의 검색 방향에 맞는 UUID가 나올 때까지 생성한다고 생각했는데, 실제로는 가능한 결과를 여러 개 만든 뒤 그중 최선을 고르는 방식이었음
      검색 결과를 앞뒤로 이동할 때마다 다른 결과가 나오는 걸 보고 그렇게 추측했는데, 실제로 몇 개나 생성하는지 궁금함
    • 전문 검색은 처음엔 순서대로 검색하는 것처럼 보이지만 실제로는 그렇지 않아서 약간 헷갈림. “next”를 몇 번 누른 뒤 같은 횟수만큼 “prev”를 눌러도 반드시 원래 UUID로 돌아가진 않음
      그래도 꽤 멋진 트릭처럼 보임
    • 검색 방식은 순진한 맞춤법 검사기를 만드는 흔한 접근과 아주 비슷함. 입력값이 주어지면 그 입력이 포함될 수 있는 모든 가능한 일치 항목을 생성하는 방식임
      말뭉치에서 검색하는 게 아니라, 입력을 이용해 말뭉치의 색인을 생성하는 셈임. 여기서는 UUID 목록이고, 맞춤법 검사기에서는 사전의 단어 목록임

  • 어떤 해커가 모든 UUID를 유출한 것 같음
    내 UUID가 유출 목록에 포함됐는지 확인해봐야 함

    • 모든 ATM PIN이 유출된 이후 최대 해킹임: https://pastebin.com/SmJRB8eQ
    • 이걸 보안 부서에 알리면 분명 바로 달려들 것 같음
    • “havemyuuidsbeenpwned.com” 서비스가 기대됨
    • 10b82756-f8b4-4fee-a508-adeadbeef5eb
      어쩔 수 없네, 이제 포맷할 시간임
    • 지금 회사 일이 이런 상태라 개인 데이터 보안에서 이 유출을 완화할 시간이 도저히 없음. 공식적으로 포기함

  • 아주 유용함. UUID를 잊어버리면 참고하겠음. 비트코인 개인 키를 기억할 때도 이 사이트를 늘 씀: https://privatekeys.pw/keys/bitcoin/1

    • 무작위 키: 잔고 0
      실제 키: 잔고가 이제 0
    • 사람들이 재미로 약한 BTC 키를 만든다는 걸 몰랐음. 일부는 봇 유인용 덫으로도 쓰일 것 같음
    • 실제 개인 키를 검색해서 잠재적으로 유출하는 사람도 분명 있을 것 같음
    • 이것도 참고: https://keys.lol/

  • 가끔 UUID를 생성해놓고 아무 데도 쓰지 않으면 괜히 미안한 느낌이 듦. 낭비한 것 같음

    • 그렇게 느끼는 건 혼자가 아님: https://wasteaguid.info/
    • UUID는 충분히 많아서, 어딘가에 기록하지 않음으로써 오히려 더 희소한 자원을 아끼는 셈임
    • 생성하지 않아서 태어나지도 못한 UUID들에 대해서는 얼마나 미안함?
    • 회사 클릭스트림 데이터에는 event_uuid 컬럼이 있는데, UUID, 큰 정수, 계정 번호와 그 밖의 식별자 10개쯤을 합친 형태임
      어떤 컬럼으로 조인해야 할지 모를 때 조인이 아주 편해짐
    • 예전에 수백만 건짜리 테이블에서 레코드 하나를 고르려고 SELECT TOP 1 ... ORDER BY NEWID()를 쓴 적이 있음
      UUID가 수백만 개 생성됐고, 그중 하나가 우연히 가장 낮은 값으로 뽑혀 연결된 레코드가 반환됐음. 엄청난 낭비임

  • “브라우저는 1조의 1조 픽셀보다 높은 창을 렌더링하고 싶어 하지 않아서 스크롤과 렌더링을 직접 처리해야 했다”는 부분이 재밌음. 실제로 이런 걸 시도하면 꽤 실망스럽고, 1조 픽셀 근처에도 못 감
    5년 전 Fastmail에서 일할 때 IE 사용 고객이 메일함에 약 20만 개 이메일을 넣자 스크롤바가 깨져서 확인했던 한계는 이랬고, 몇 개는 방금 다시 확인함
    Firefox는 예전엔 17,895,697픽셀보다 큰 값으로 해석되는 선언을 무시했음. 지금은 그 지점에서 클램프하지만 3픽셀 정도 차이가 있어 정확히 무슨 일이 일어나는지는 바로 분명하지 않음
    IE는 10,737,418.23픽셀 이상으로 해석되는 선언을 무시함. WebKit은 대략 2²⁵, 즉 33,554,432픽셀 근처에서 값을 클램프함
    Chromium은 예전 테스트 때 WebKit과 같았는데, 지금은 약 22,360,882픽셀 근처에서 클램프함. 현재 1.5배율 디스플레이라 2²⁵가 장치 픽셀과 관련 있을 수도 있지만, 처음 테스트할 때는 2배율 디스플레이였던 것 같음
    관련 소스 코드 링크와 함께 더 자세히 쓴 글도 있음: https://news.ycombinator.com/item?id=34299569

    • 이거 좋음. 글을 쓰면서 비교적 최신의 브라우저 최대 높이 목록을 찾으려 했음. 업데이트에 이 댓글을 링크해도 되는지 궁금함
      또 그 숫자들이 어떻게 정해졌는지, 한계가 없으면 무엇이 깨지기 시작하는지도 무척 궁금함. clientHeight 주변의 이상한 동작 예가 그 힌트일 수도 있겠음
    • 요소 너비에도 비슷한 한계가 있음. 최근에 너비를 45678910px로 설정하려다 알게 됨: https://thewisenerd.com/works/45678910px.html

  • 새 npm 패키지 get-uuid를 발표하고 싶음. 내부적으로는 everyuuid.com을 불러오고, 무작위 행 번호를 골라 그 UUID를 반환함

    • 훌륭한 아이디어임. 나도 그 패키지를 사용하는 npm 패키지를 만들어서 숫자 사이의 -를 제거한 GUID를 반환하게 하겠음. 코드 재사용 만세
    • 라이브러리의 API 호환성은 한 달에 5번까지만 깨뜨려주면 좋겠음. 그 이상은 너무 많음
      그리고 내가 네 패키지가 원하는 걸 정확히 하지 않는다는 걸 깨닫고 포크할 날도 기대해줘
    • AI가 미적으로 보기 좋은 UUID를 골라주면 더 좋겠음. 원하면 PR 올릴 수 있음
    • UUID가 존재하는지 확인하는 함수도 추가해줄 수 있음?

  • https://libraryofbabel.info/가 떠오름. 지금은 내려간 것 같으니 Archive를 시도해볼 수 있음: https://web.archive.org/web/20241112121646/https://libraryof...
    단편 https://en.wikipedia.org/wiki/The_Library_of_Babel에서 영감을 받은 재미있는 구현이고, “현재 가능한 모든 3200자 페이지를 담고 있다”고 함. 다만 문자 집합이 제한되어 있어 하이픈이 없으므로 이 UUID들은 찾을 수 없음

    • Steven L. Peck의 A Short Stay in Hell(2009)이라는 변주도 있음
      크고 큰 수를 이해한다면 재미있고 무서운 읽을거리임

  • 유효한 UUID인 모든 .com 도메인 목록일 줄 알았음. 실제로 그런 도메인이 얼마나 있을지 궁금해짐
    업데이트: 다른 댓글에서 이미 공유함: https://news.ycombinator.com/item?id=42342653

  • 압축 기술이 너무 발전해서 이제 340언데실리언 바이트가 넘는 웹페이지를 탐색할 수 있음
    정말 경이로운 시대에 살고 있음

    • 이건 Weissman 점수 최고 기록을 새로 세운 게 거의 확실함
    • 별거 아님. 몇 년 전 Cookie Clicker에서 내 빵집들은 언데실리언 단위 생산도 문제없이 해냈음

  • 한 화면을 넘는 분량의 내용이 한 번에 들어 있는데도, 스크롤할 때 몇 초짜리 로딩 애니메이션이 나오지 않는 웹사이트라니 놀라움
    현대 웹 애플리케이션 개발자들이 이 기술을 어떻게든 활용할 수 있을지 궁금함

    • 완전히 동의함. 나도 바로 “와, 빠르고 부드럽고 반응성이 좋다!”고 생각했음
      컴퓨터 하드웨어는 1995년, 30년 전보다 1000배 빨라졌는데 소프트웨어는 너무 비대해져서 여전히 더 느리다는 게 터무니없음
      관련 영상: “Will Software Stop Getting Slower?” Jonathan Blow
      https://www.youtube.com/watch?v=4ka549NNdDk
답변달기