Hacker News 의견들

• UUID 버전 1~5가 이미 구식이라는 말이 흥미로웠음
  하지만 v4는 여전히 무작위성이 가장 높고, 분산 DB에서 핫스팟 문제와 프라이버시 이슈를 피하기 위해 기본 키로 권장됨
  참고 링크: CockroachDB UUID 문서, Google Cloud Spanner UUID 가이드

  • 나도 그 말이 이상하다고 생각했음. v7은 단조성이 필요할 때 좋지만, 타임스탬프가 시스템 정보를 노출할 수 있음. 그래서 v4는 여전히 유효함
  • “outdated”라는 표현은 부적절하다고 봄. 문제는 요구사항 불일치이지 나이 때문이 아님
    각 UUID 버전(v4 포함)은 특정 상황에서 결함이 있음. 실제로 많은 조직은 표준 UUID 대신 순수 128비트 값을 자체 정의해 사용함
    결국 UUID의 설계 한계를 넘어서는 복잡한 요구사항이 많아졌음
  • v4가 기본 선택이고, 특별히 순서 보존이 필요할 때만 다른 버전을 씀
  • 정말 128비트 무작위성이 필요하다면 그냥 128비트 난수를 쓰면 됨. UUID 포맷에 끼워 맞출 필요는 없음
  • 하지만 v4는 B-Tree 삽입을 엉망으로 만들 수 있음. 커널의 페이지 캐싱 효율 때문에 v7이 훨씬 빠르다고 배웠음

• 오늘 HN에 이런 소소한 Go 관련 뉴스가 올라온 게 반가움
  요즘은 프로그래밍의 미래나 AI 얘기뿐이라 이런 기술 토픽이 신선함

  • 오랜만에 깊이 있는 기술 토론을 보니 기분이 좋음
  • AI 관련 공포(FUD)에서 잠시 벗어나서 마음이 편해짐. 예전엔 HN을 열면 불안해지지 않았는데 요즘은 다들 “망할 거야” 얘기뿐이었음
  • 겉보기엔 작은 기술 이슈지만, 사실 Go 언어의 아키텍처와 리더십 방향을 좌우하는 큰 결정임
    완벽주의자, 실무 개발자, 그리고 crypto 커뮤니티가 각기 다른 입장을 가짐
    관련 문서: RFC 9562
    나는 Go가 올바른 결정을 내리길 바람. 특히 TinyGo는 마이크로컨트롤러용으로 정말 멋짐
  • Go를 싫어하는 사람들의 풍경이 재밌음. 이제는 AI가 코드 보는 시대라 언어 비판의 재미도 사라진 듯함

• Go가 UUID 생성을 지원하는 건 별로 신경 안 쓰지만, 표준 UUID 타입이 생기는 건 정말 중요함
  JSON, Text, database/sql 등에서 일관된 마샬링이 가능해질 것임
  최근 Go 의존성 분석에서 google/uuid가 두 번째로 많이 쓰이는 패키지였음
  관련 분석: The most popular Go dependency

  • 나도 dec128 타입이 표준으로 들어가면 좋겠음. uint128로 변환이 쉬운 구조체 형태로 제공되면 이상적임

• Go의 매력은 화려한 기능보다 실용성에 있음
  언어가 무너질 정도로 복잡해지지 않고, 필요한 기능만 추가함

  • 나도 최근 여러 버전을 건너뛰어 업그레이드했는데 아무 문제 없었음
    호환성 보장 덕분에 안심하고 쓸 수 있음. 변화는 느리지만 꾸준히 좋아지는 언어임

• Google의 uuid 패키지가 비활성화된 것보다, gofrs/uuid가 새 표준을 따르고 활발히 유지된다는 점이 더 중요하다고 생각함
  gofrs/uuid 저장소

  • 외부 의존성 없는 라이브러리를 만드는 게 즐거움. 이번 변경으로 그런 작업이 더 쉬워짐
  • 하지만 google/uuid는 2024년 이후 릴리스가 없고, 2025년 6월에도 관련 이슈가 열려 있음
    이슈 #194
  • 이 제안은 이미 3년 전부터 논의 중이었음

• UUID를 정말 싫어함. 사람 친화적이지 않은 식별자임
  디버깅이나 쿼리 결과에서 너무 길고 불편함.
  물론 완전히 분리된 시스템 간 고유 ID가 필요할 때는 쓸모 있지만, 대부분은 남용되고 있음
  일반적인 경우엔 중앙화된 번호 발급기가 훨씬 나음.
  예를 들어 DB의 GetNextId 같은 절차가 더 인간적이고 효율적임

  • 예전에 회사에서 6자리 코드로 프로젝트를 관리했는데, 누군가 그걸 UUID로 바꿔버림
    결과적으로 사람이 읽을 수 없는 코드가 되어버렸고, 심지어 자체 구현이라 이상하게 순차적이었음. 완전히 망한 결정이었음
  • 사실 대부분의 경우 정수 카운터로 충분함
    Postgres에서 카운터 테이블을 쓰면 초당 수만 개 ID를 생성할 수 있음
    이렇게 하면 메모리 절약, 압축 효율, 해시맵 성능까지 좋아짐
    UUID는 편하지만 성능을 망침
  • 인간이 읽기 쉬운 요소가 있었으면 좋겠음
    예: BASKETBALL-...-FISH 같은 형태로 단어 기반 체크섬을 붙이면 기억하기 쉬움
  • “결정적 난수화”를 언급했는데, 나도 LFSR(선형 피드백 시프트 레지스터) 같은 방식이 괜찮다고 생각함

• Go에 UUID가 정말 추가되는 건지 궁금했음

  • 현재 ‘Likely accept’ 상태임. Go 프로젝트 보드에서 확인 가능함
    특별한 반대가 없으면 포함될 가능성이 높음
  • 네, 추가될 예정임

• Kotlin도 최근 2.3 버전에서 RFC 9562 기반 UUID 버전 지원을 표준 라이브러리에 추가했음
  JVM, JS, WASM, Native 모두 지원함.
  IETF RFC가 안정화된 만큼 Go도 따라가는 게 합리적임

• Go가 이런 기본 기능 지원이 부족한 점은 아쉬움

  • 어떤 언어가 이런 걸 더 잘 표준화했는지 궁금함. Java 정도일까? Python이나 Rust도 비슷한 상황임
  • “배터리 포함”의 의미가 20년 사이 많이 달라졌음. 아마 Google 내부에서 필요하지 않았던 기능일 수도 있음
  • UUID는 결국 16바이트 배열일 뿐임. v4 생성은 몇 줄이면 끝남. 큰일은 아님
  • 어떤 기능이 부족하다고 느끼는지 궁금함
    개인적으로는 Go의 로깅 시스템이 너무 단순해서 직접 구현해야 했음
    slog 모듈은 느리고 불편함. 엔터프라이즈 환경만 고려한 듯함
  • 그래도 Go의 표준 라이브러리 품질은 최고 수준임. 일상 개발에서 가장 많이 쓰이는 stdlib이라고 생각함

• v7의 DB 클러스터링 효율과 v4의 무작위성을 동시에 얻을 방법이 있을까 고민했음
  내부적으로 v7을 쓰고, 외부로 보낼 때 XOR이나 AES로 스크램블링하면 가능할 듯함

  • 실제로 그런 시도가 있음: uuidv47 프로젝트
  • 프라이버시가 목적이라면, 그냥 정수 키를 암호화하는 게 낫다고 생각함
    예를 들어 Feistel 암호화를 쓰면 UUID의 성능 문제 없이 불투명한 공개 ID를 만들 수 있음