▲

Go 표준 라이브러리에 UUID 패키지 추가 제안

 (github.com/golang)
1P by GN⁺ 1달전 | ★ favorite | 댓글 1개
  • Go 언어에 UUID 생성 및 파싱 기능을 표준 라이브러리로 포함하자는 제안이 GitHub에서 논의됨
  • 제안자는 현재 대부분의 Go 서버·DB 프로젝트가 github.com/google/uuid 같은 외부 패키지에 의존하고 있음을 근거로 제시
  • C#, Java, Python 등 주요 언어는 이미 표준 라이브러리 수준에서 UUID 지원을 제공하고 있음
  • 논의 과정에서 UUIDv7 등 최신 사양과 RFC 9562 준수 여부, 파싱 기능 포함 범위, API 일관성 등이 주요 쟁점으로 다뤄짐
  • 이 제안은 이후 crypto/rand 패키지의 UUIDv4·UUIDv7 지원 제안(#76319) 으로 통합되어 진행 중임

제안 개요

  • Go 표준 라이브러리에 UUID 생성 및 파싱 API를 추가하는 방안 제시
    • 대상 버전은 UUID v3, v4, v5
    • 주요 근거는 외부 패키지 의존도와 다른 언어의 표준 지원 사례
  • UUID는 RFC 4122(이후 RFC 9562)에 정의된 국제 표준임
  • 제안자는 Go가 주요 언어 중 UUID 표준 지원이 없는 예외적 사례라고 지적

초기 반응과 논의

  • 일부 참여자는 과거에도 유사 제안이 있었으나 거절된 전례를 언급 (#23789, #28324)
    • 이유는 외부 패키지 사용이 충분히 간편하고, 표준 라이브러리보다 릴리스 주기가 유연하다는 점
  • 제안자는 “대부분의 프로젝트가 매번 외부 패키지를 임포트해야 한다면, 차라리 표준에 포함하는 것이 낫다”고 주장
  • 다수의 언어가 UUID를 crypto 관련 표준 라이브러리에 포함하고 있다는 점이 지지 근거로 제시됨

최신 UUID 버전 및 RFC 반영

  • 일부 의견은 UUID v1~v5는 구식이며, v7이 최신이자 유망한 버전이라고 지적
    • v7은 다양한 구현 옵션이 존재하며, 적용 결과를 지켜볼 필요가 있음
  • RFC 초안에서는 UUID를 불필요하게 파싱하지 말고 불투명한 식별자로 다루는 것을 권장
  • 이후 RFC 9562가 정식 발행되면서, 관련 논의가 UUIDv7 지원 중심으로 이동

제안의 수정 및 병합

  • 2025년, RFC 9562가 공식화되자 PostgreSQL 18이 UUIDv7을 지원했다는 언급 등장
  • 이후 Go 측에서는 crypto/rand 패키지에 UUIDv4·UUIDv7 생성 기능만 추가하는 별도 제안(#76319)을 개시
    • 파싱 기능은 RFC 권고에 따라 제외
  • 원 제안(#62026)은 중복(duplicate) 으로 처리되어 닫힘

API 설계 논의

  • uuid.New() 기본 동작을 v4로 둘지, 향후 변경 가능성을 둘지 논의
    • 일부는 “버전 변경 시 호환성 문제가 생길 수 있다”며 항상 v4로 고정할 것을 제안
  • Compare, MustParse, Parse 등 메서드 제공 여부 논의
    • Compare는 RFC 정의에 따라 정렬 가능한 UUID 지원을 위해 필요하다는 의견
    • MustParse는 표준 내 다른 Must* 함수들과 일관성을 유지하기 위해 포함
  • IsZero() 메서드는 UUID 타입에 불필요하다는 결론
  • Generator 구조체 도입, 버전별 타입 분리(UUIDv4, UUIDv7 등) 등 다양한 설계 제안이 제시됨
  • 일부는 New() 함수의 모호성을 지적하며, 명시적 버전 함수(NewV4, NewV7) 만 제공하자는 의견 제시

주요 기술 쟁점

  • UUID 정렬(sorting) 정의가 v6·v7에만 명확히 존재하는지 여부 논의
  • UUIDv7 생성 시 시간 기반 정렬 보장 및 동시성 충돌 방지(counter 방식) 구현 방법 검토
  • 버전별 의미 차이(예: v1은 MAC 주소 포함, v7은 시간 기반)로 인해 단일 타입 설계의 한계 지적
  • 일부는 버전별 타입 분리 및 명시적 변환 메서드(AsV4(), AsV7() 등) 도입을 제안

결론 및 현재 상태

  • Go 커뮤니티는 UUID 표준 지원 필요성에는 대체로 동의
  • 다만, 표준 라이브러리의 단순성 유지와 RFC 권고 준수를 위해
    • 파싱 기능은 제외
    • UUIDv4·UUIDv7 생성 기능만 crypto/rand에 추가하는 방향으로 정리
  • 원 제안(#62026)은 #76319 제안으로 통합되어 진행 중이며,
    Go 언어의 UUID 표준 지원이 공식화 단계에 근접한 상태임

함께 보면 좋은 글 β

▲
GN⁺ 1달전  [-]
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를 만들 수 있음
답변달기