# 핵심 타입(Core Types) 제거와 Go 언어의 간결한 진화

> Clean Markdown view of GeekNews topic #20008. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20008](https://news.hada.io/topic?id=20008)
- GeekNews Markdown: [https://news.hada.io/topic/20008.md](https://news.hada.io/topic/20008.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-03-28T10:03:14+09:00
- Updated: 2025-03-28T10:03:14+09:00
- Original source: [go.dev](https://go.dev/blog/coretypes)
- Points: 3
- Comments: 6

## Topic Body

- Go 1.18에서 제네릭(generics) 기능 도입과 함께 새로운 개념인 **핵심 타입(core type)** 이 추가되었으나, **1.25에서 제거하기로 결정**   
- 핵심 타입은 컴파일러 구현 편의를 위한 추상 개념으로, 제네릭 타입 피연산자 처리 시 기존의 기저 타입(underlying type)을 대체함  
- 언어 명세에서도 기존의 "기저 타입"을 "핵심 타입"으로 대체하여 사용함  
  
### 타입 매개변수와 타입 제약  
  
- 타입 매개변수는 미래에 결정될 타입을 위한 자리 표시자 역할을 하며 컴파일 시점에 결정됨  
- 타입 제약은 해당 매개변수 타입으로 가능한 연산을 결정함  
- Go에서는 메서드와 타입 요구사항을 조합하여 타입 제약을 정의하며, 이를 통해 타입 집합(type set)을 형성함  
- 타입 집합은 특정 인터페이스를 만족하는 모든 타입의 모임을 의미함  
  ```go   
  type Constraint interface {  
    ~[]byte | ~string  
    Hash() uint64  
  }  
  ```  
- 이러한 타입 집합 기반의 방식은 제네릭 타입 연산을 정의하는 데 매우 유연하고 강력함  
  ```go   
  func at[bytestring Constraint](s bytestring, i int) byte {  
    return s[i]  
  }  
  ```  
  
### 핵심 타입의 도입과 한계  
  
- 핵심 타입은 일부 연산에서 제네릭 타입의 사용을 간단하게 만들기 위한 규칙으로 정의됨  
- 핵심 타입 정의 방식:  
  - 일반 타입인 경우, 핵심 타입은 해당 타입의 기저 타입과 동일함  
  - 타입 매개변수인 경우, 타입 집합 내 모든 타입이 동일한 기저 타입을 가져야 핵심 타입이 존재함  
- 하지만 이 방식은 다음과 같은 문제점을 유발함:  
  - 언어 명세가 복잡해져 단순한 규칙도 이해하기 어려워짐  
  - 비제네릭 코드에도 불필요하게 핵심 타입 개념이 언급됨  
  - 핵심 타입 개념이 있는 일부 연산은 과도하게 제한적이 되어 실제론 안전한 연산도 허용되지 않음  
  - 핵심 타입을 사용하지 않는 규칙들과의 불일치로 인해 언어 설계 전반에 일관성이 떨어짐  
  
### Go 1.25에서 핵심 타입 제거  
  
- Go 1.25 릴리스(2025년 8월 예정)에서는 핵심 타입 개념을 언어 명세에서 제거하기로 결정함  
- 각 연산마다 필요한 제약을 명시적인 문장으로 기술하는 방식으로 전환됨  
- 변경의 주요 효과:  
  - 개념 수를 줄여 Go 언어 학습이 더 쉬워짐  
  - 비제네릭 코드가 제네릭 개념에 의존하지 않고 명확해짐  
  - 특정 연산별로 더 유연한 규칙 설계 가능  
  - 향후 기능 확장을 위한 토대 마련 (예: 공통 필드 접근, 슬라이스 기능 강화, 타입 추론 개선 등)  
  
### 주요 적용 사항 및 기대 효과  
  
- 핵심 타입을 언급하던 모든 명세 문구가 제거되거나 명시적인 문장으로 교체됨  
- 컴파일러 에러 메시지에서도 핵심 타입이라는 용어가 제거되고 더 구체적인 설명이 제공됨  
- 기존 Go 프로그램의 동작에는 영향 없음  
- 언어 명세는 더 간단해지고, 사용자 입장에서 Go 언어는 더 직관적이고 명확해짐

## Comments



### Comment 36448

- Author: neo
- Created: 2025-03-28T10:03:14+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43483842) 
- Go 팀이 사양 변경을 매우 신중하게 다루는 점이 좋음
  - Go 제네릭은 큰 변화이며 사용하기 어려울 수 있음
  - 제약이 제네릭의 과도한 사용을 막아준다고 생각함
  - Java와 Typescript 프로젝트에서 타입 시스템을 과도하게 사용하여 코드가 불명확해지는 경우를 봄
  - Go 팀이 언어에 보수적으로 접근하길 바람

- Go 개발팀의 지난 10년은 기능과 단순성 사이의 균형을 찾는 과정이었음
  - 제네릭은 이러한 동적의 핵심을 잘 보여줌
  - Go 위에 Rust와 같은 타입 시스템을 구현하는 것은 복잡성이 너무 큼
  - 단순성을 중시하는 방향으로의 약간의 회귀가 좋음
  - Go는 중급 엔지니어 팀에게 더 나은 Java가 되는 것이 목표임

- Go 1.25는 실제 언어 기능을 추가하지 않음
  - 1.30에서는 sum types가 추가될 수도 있음

- Go를 Windows 빌드 이전부터 따라왔음
  - 2011년에 배운 모든 것이 여전히 유효함
  - Go로 작업할 기회가 없었지만 작은 프로젝트로 학습함
  - Go 개발자 인터뷰에서 제네릭이 Go에 도입되지 않을 것 같다는 발언이 실망스러웠음
  - 이제 제네릭이 도입되어 Go로 사이드 프로젝트를 시작할 계획임

- `close`의 인자가 타입 파라미터일 때 모든 타입은 동일한 요소 타입의 채널이어야 한다는 것은 사실이 아님
  - 요소 타입은 `close`에 영향을 주지 않으며, 다른 요소 타입을 가진 타입 세트를 사용할 때도 컴파일이 잘 됨
  - 문서 개선이 필요함
  - 공유 필드와 같은 유연성 확장이 가속화되길 바람

- Go를 천천히 배우고 있으며, C++ 배경이 있음
  - 템플릿 특수화와 유사한 것인지 궁금함
  - 더 많은 언어가 이를 지원하길 바람

- [dead]

- 이제 생성 AI가 코드를 작성할 수 있게 되었는데, 가비지 컬렉터가 여전히 필요한지 궁금함

### Comment 36454

- Author: aer0700
- Created: 2025-03-28T12:23:41+09:00
- Points: 1
- Parent comment: 36448
- Depth: 1

이제 생성 AI가 코드를 작성할 수 있게 되었는데, 가비지 컬렉터가 여전히 필요한지 궁금함  
> 의미심장하네요...

### Comment 36501

- Author: galadbran
- Created: 2025-03-29T21:25:16+09:00
- Points: 1
- Parent comment: 36454
- Depth: 2

호오.. AI가 그 수준의 코드 (메모리 관리를 완벽하게 하는 코드)를  작성해 내는 수준이 되면 사람 개발자가 지금과 같은 역할로 있기는 힘들겠네요

### Comment 36460

- Author: kandk
- Created: 2025-03-28T13:25:52+09:00
- Points: 1
- Parent comment: 36454
- Depth: 2

1+1=2 를 수학으로 풀 수 있는데 굳이 AI로 풀 이유가..

### Comment 36459

- Author: jeiea
- Created: 2025-03-28T13:08:19+09:00
- Points: 1
- Parent comment: 36454
- Depth: 2

사람이 읽는 보일러플레이트와 추적해야 할 코드 문맥을 줄이는 면에선 GC도 의미가 있지 않을까요?  
코드를 읽을 필요조차 없어질 거라고 예측하는 거라면 그건 또 모르겠네요.  
원래 코멘트도 흐림 처리된 걸 보면 많이 공감받진 않는 것 같아요.

### Comment 36456

- Author: savvykang
- Created: 2025-03-28T12:50:19+09:00
- Points: 1
- Parent comment: 36454
- Depth: 2

메모리 할당과 해제시점을 컴파일 시점에 계산 가능할 때 레퍼런스 카운팅을 제거할 수 있지 않나요? 해커뉴스 원 댓글 작성자가 메모리 재활용 문제를 이해하지 못하고 있는 것으로 보입니다