# Go 표준 라이브러리에 UUID 패키지 추가 제안 > Clean Markdown view of GeekNews topic #27299. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27299](https://news.hada.io/topic?id=27299) - GeekNews Markdown: [https://news.hada.io/topic/27299.md](https://news.hada.io/topic/27299.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-08T09:51:05+09:00 - Updated: 2026-03-08T09:51:05+09:00 - Original source: [github.com/golang](https://github.com/golang/go/issues/62026) - Points: 1 - Comments: 1 ## Topic Body - 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 표준 지원이 공식화 단계에 근접**한 상태임 ## Comments ### Comment 52588 - Author: neo - Created: 2026-03-08T09:51:06+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47283665) - UUID 버전 1~5가 이미 구식이라는 말이 흥미로웠음 하지만 **v4**는 여전히 무작위성이 가장 높고, 분산 DB에서 **핫스팟 문제와 프라이버시 이슈**를 피하기 위해 기본 키로 권장됨 참고 링크: [CockroachDB UUID 문서](https://www.cockroachlabs.com/docs/stable/uuid), [Google Cloud Spanner UUID 가이드](https://docs.cloud.google.com/spanner/docs/schema-design#uuid_primary_key) - 나도 그 말이 이상하다고 생각했음. **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](https://datatracker.ietf.org/doc/html/rfc9562) 나는 Go가 올바른 결정을 내리길 바람. 특히 **TinyGo**는 마이크로컨트롤러용으로 정말 멋짐 - Go를 싫어하는 사람들의 풍경이 재밌음. 이제는 **AI가 코드 보는 시대**라 언어 비판의 재미도 사라진 듯함 - Go가 UUID 생성을 지원하는 건 별로 신경 안 쓰지만, **표준 UUID 타입**이 생기는 건 정말 중요함 JSON, Text, database/sql 등에서 일관된 마샬링이 가능해질 것임 최근 Go 의존성 분석에서 **google/uuid**가 두 번째로 많이 쓰이는 패키지였음 관련 분석: [The most popular Go dependency](https://blog.thibaut-rousseau.com/blog/the-most-popular-go-dependency-is/) - 나도 **dec128** 타입이 표준으로 들어가면 좋겠음. uint128로 변환이 쉬운 구조체 형태로 제공되면 이상적임 - Go의 매력은 **화려한 기능보다 실용성**에 있음 언어가 무너질 정도로 복잡해지지 않고, 필요한 기능만 추가함 - 나도 최근 여러 버전을 건너뛰어 업그레이드했는데 아무 문제 없었음 **호환성 보장** 덕분에 안심하고 쓸 수 있음. 변화는 느리지만 꾸준히 좋아지는 언어임 - Google의 uuid 패키지가 비활성화된 것보다, **gofrs/uuid**가 새 표준을 따르고 활발히 유지된다는 점이 더 중요하다고 생각함 [gofrs/uuid 저장소](https://github.com/gofrs/uuid) - 외부 의존성 없는 라이브러리를 만드는 게 즐거움. 이번 변경으로 그런 작업이 더 쉬워짐 - 하지만 google/uuid는 2024년 이후 릴리스가 없고, 2025년 6월에도 관련 이슈가 열려 있음 [이슈 #194](https://github.com/google/uuid/issues/194) - 이 제안은 이미 **3년 전부터** 논의 중이었음 - UUID를 정말 싫어함. **사람 친화적이지 않은 식별자**임 디버깅이나 쿼리 결과에서 너무 길고 불편함. 물론 완전히 분리된 시스템 간 고유 ID가 필요할 때는 쓸모 있지만, 대부분은 남용되고 있음 일반적인 경우엔 **중앙화된 번호 발급기**가 훨씬 나음. 예를 들어 DB의 **GetNextId** 같은 절차가 더 인간적이고 효율적임 - 예전에 회사에서 6자리 코드로 프로젝트를 관리했는데, 누군가 그걸 UUID로 바꿔버림 결과적으로 **사람이 읽을 수 없는 코드**가 되어버렸고, 심지어 자체 구현이라 이상하게 순차적이었음. 완전히 망한 결정이었음 - 사실 대부분의 경우 **정수 카운터**로 충분함 Postgres에서 카운터 테이블을 쓰면 초당 수만 개 ID를 생성할 수 있음 이렇게 하면 **메모리 절약, 압축 효율, 해시맵 성능**까지 좋아짐 UUID는 편하지만 성능을 망침 - 인간이 읽기 쉬운 요소가 있었으면 좋겠음 예: `BASKETBALL-...-FISH` 같은 형태로 **단어 기반 체크섬**을 붙이면 기억하기 쉬움 - “결정적 난수화”를 언급했는데, 나도 **LFSR(선형 피드백 시프트 레지스터)** 같은 방식이 괜찮다고 생각함 - Go에 UUID가 정말 추가되는 건지 궁금했음 - 현재 **‘Likely accept’** 상태임. [Go 프로젝트 보드](https://github.com/orgs/golang/projects/17/views/1)에서 확인 가능함 특별한 반대가 없으면 포함될 가능성이 높음 - 네, 추가될 예정임 - 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 프로젝트](https://github.com/stateless-me/uuidv47) - 프라이버시가 목적이라면, 그냥 **정수 키를 암호화**하는 게 낫다고 생각함 예를 들어 **Feistel 암호화**를 쓰면 UUID의 성능 문제 없이 불투명한 공개 ID를 만들 수 있음