Go 1.24 릴리즈

 (go.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Go 1.24는 Go 1.23 이후의 정식 업데이트로, 언어 기능부터 런타임·표준 라이브러리·WebAssembly까지 개발자가 바로 체감할 변경을 넓게 포함함
  • 언어 차원에서는 제네릭 타입 별칭을 완전히 지원해 타입 별칭도 정의 타입처럼 매개변수화할 수 있음
  • 런타임은 Swiss Tables 기반 map, 작은 객체 할당 개선, 내부 뮤텍스 변경으로 대표 벤치마크에서 평균 CPU 오버헤드 2–3% 감소를 보임
  • go 명령은 모듈의 도구 의존성을 추적·실행하는 흐름을 추가했고, go vet은 테스트 관련 선언 실수를 더 잘 잡아냄
  • 표준 라이브러리와 플랫폼 지원도 확장되어 FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport, WASI reactor/library 빌드를 확인할 필요가 있음

Go 1.24의 변경 범위

  • Go 1.24는 Go 1.23 대비 여러 개선을 담은 릴리즈이며, 전체 변경 목록은 Go 1.24 release notes에서 확인할 수 있음
  • 새 버전은 Go 다운로드 페이지에서 받을 수 있음

언어 변경: 제네릭 타입 별칭

  • Go 1.24는 generic type aliases를 완전히 지원함
  • 타입 별칭도 정의 타입처럼 매개변수화할 수 있어 제네릭 코드에서 표현 범위가 넓어짐
  • 세부 문법은 language spec에 포함됨

런타임 성능 개선

  • 런타임 개선으로 대표 벤치마크 묶음에서 평균 CPU 오버헤드가 2–3% 감소함
  • 성능 변화의 주요 축은 세 가지임
    • Swiss Tables 기반의 새 내장 map 구현
    • 작은 객체에 대한 더 효율적인 메모리 할당
    • 새 런타임 내부 뮤텍스 구현

Go 도구 개선

  • go 명령은 모듈의 도구 의존성을 추적하는 메커니즘을 제공함
    • go get -tool로 현재 모듈에 tool 지시문을 추가함
    • go tool [tool name]으로 tool 지시문에 선언된 도구를 실행함
    • 자세한 내용은 릴리즈 노트의 go command에 있음
  • go vet 하위 명령에는 새 test 분석기가 추가됨
    • 테스트 패키지의 테스트, 퍼저, 벤치마크, 예제 선언에서 흔한 실수를 보고함
    • 자세한 내용은 릴리즈 노트의 vet에 있음

표준 라이브러리와 런타임 API 추가

  • 표준 라이브러리는 FIPS 140-3 준수를 돕는 새 메커니즘 묶음을 포함함
    • 승인된 알고리듬에 대해 새 메커니즘을 사용하기 위해 애플리케이션 소스 코드 변경이 필요 없음
    • 자세한 내용은 릴리즈 노트의 FIPS 140-3 compliance에 있음
  • FIPS 140 외에도 이전에 x/crypto 모듈에 있던 여러 패키지가 표준 라이브러리에서 제공됨
  • 벤치마크 코드는 testing.B.Loop 메서드를 사용할 수 있음
    • for b.Loop() { ... } 형태로 벤치마크 반복을 수행함
    • for range b.N처럼 b.N을 쓰는 일반적인 루프 구조를 대체할 수 있음
    • 이 방식은 더 빠르고 오류 가능성이 낮음
  • 새 os.Root 타입은 특정 디렉터리 아래로 격리된 파일시스템 작업을 가능하게 함
  • 런타임에는 새 정리 메커니즘 runtime.AddCleanup이 추가됨

WebAssembly 지원 개선

  • Go 1.24는 Go 프로그램이 WebAssembly 호스트로 함수를 내보낼 수 있는 새 go:wasmexport 지시문을 추가함
  • Go 프로그램을 WASI reactor/library로 빌드할 수 있음
  • 자세한 내용은 릴리즈 노트의 WebAssembly에 있음

후속 안내와 피드백

  • 전체 상세 정보는 Go 1.24 release notes에 있음
  • 일부 주제는 후속 블로그 글에서 더 깊게 다룰 예정임
  • 문제가 발견되면 issue를 등록할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 더 빠른 map 구현이 특히 반갑고, text/template이 이제 range-over-func를 지원하는 것도 좋음
    Go 1.23에서 함수 타입에 대한 range가 들어왔지만, Go 템플릿에서는 지금까지 동작하지 않았음

  • 지루할 만큼 무난해서 마음에 듦

  • os.Root의 사용처가 뭘지 궁금함
    이해한 바로는 https://github.com/golang/go/issues/67002처럼 보안과 관련이 있는데, 내부적으로 Chroot를 쓰지 않으니 결국 누군가 Root 밖으로 탈출하는 방법을 찾을 수도 있을 것 같음

    • chroot는 애플리케이션이 앞으로도 단일 디렉터리 안에서만 동작하겠다고 확정할 수 있을 때만 의미가 있음
      게다가 프로세스에 슈퍼유저 권한이 필요해서, 일반 사용자 권한으로 실행되는 애플리케이션에는 쓸 수 없음
      os.Root()는 파일 시스템 작업에 안전벨트를 채우는 쪽에 가까움. 예를 들어 애플리케이션 캐시 관련 작업을 캐시 디렉터리로 제한하거나, 파일 서버가 적절한 공유 디렉터리 안의 파일만 제공하게 하는 식임. chroot처럼 철벽 보장은 아니지만, 단순한 디렉터리 순회 공격은 막아줌
    • 왜 chroot를 써야 하는지 모르겠음
      Capsicum 같은 샌드박스 기능과 함께라면 capability mode에 들어가기 전에 디렉터리를 열어두고, 나중에 os.Root로 그 열린 디렉터리 아래 파일 시스템 트리의 파일을 열 수 있음

  • tools 지시문으로 지정한 도구를 설치할 때 사용할 태그를 지정할 수 있는지 궁금함
    아래처럼 해봤지만 태그 없이 설치되는 것 같음
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • GODEBUG=fips140=only를 쓰면 FIPS 140-3을 준수하지 않는 암호 알고리즘이 오류를 반환하거나 패닉한다고 되어 있는데, 표준 라이브러리가 의도적으로 패닉하는 방식은 썩 마음에 들지 않음
    코드는 아직 안 봤지만, 하위 호환성 때문에 현재 오류를 반환하지 않는 함수들에서만 그러는 건지 궁금함

    • 이건 정부 환경에서 필요한 기능임
      FIPS가 설정돼 있는지 런타임에 확인하지 않으면 컴플라이언스를 깨뜨릴 위험이 있고, 결국 감사와 끝없는 회의로 이어짐. 새 통제와 검증 절차를 세우느라 며칠씩 고생하는 것보다, 패닉으로 30분짜리 장애가 나는 편이 훨씬 낫다고 봄
    • 그러면 그 플래그를 설정하지 않으면 됨
      이런 동작은 런타임에서만 감지 가능한 상황에 유용함. 기초적인 테스트 커버리지만 있어도 바로 드러날 것임
    • 현실적인 대안은 오류를 반환하는 것뿐인데, 오류는 잡아서 무시할 수 있음
      암호화가 걸린 상황에서 그게 바람직한지는 의문임. 경고 로그 수준은 피해야 한다고 봄. 중요하고 조치 가능하면 오류나 치명 로그여야 하고, 그렇지 않다면 정보 로그면 충분함
    • 이 부분은 Go 1.25에서 정리될 것 같다고 읽었음
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • 형제 댓글들처럼 어떤 경우에는 강제가 필요함
      숨은 버그를 피하는 방식으로도 볼 수 있음. "The server chose violence" [1] [2]와 비슷하고, Postel의 법칙이 상호운용성을 얼마나 발목 잡았는지도 생각해볼 만함. 이 점은 FIPS 인증의 여러 측면에서 자주 잊힘
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652

  • 드디어 제네릭 타입 별칭이 들어왔고, 진작 필요했던 기능임

  • 새 tool 플래그가 가장 기대됨. 이제 보기 안 좋은 tools.go를 없앨 수 있음

  • 좋음. 이번 릴리스는 GOAUTH 때문에 기다리고 있었음
    비공개 git 저장소 작업이 덜 귀찮아지길 바라지만, go help goauth를 보니 크게 기대하긴 어려워 보임

답변달기