[JAVA] Generic의 Type Erasure란 무엇인가? 컴파일 타임의 마법과 런타임의 진실

Generic의 Type Erasure

 

자바 5(Java 5)에서 제네릭(Generic)이 도입되었을 때, 이는 혁명적인 변화였습니다. 코드의 재사용성을 높이고 컴파일 시점에 강력한 타입 체크를 가능하게 했기 때문입니다. 하지만 많은 자바 개발자가 간과하는 사실이 하나 있습니다. 우리가 코드에 정성껏 작성한 <T>나 <String> 같은 타입 정보가 컴파일이 끝난 뒤에는 바이트코드에서 흔적도 없이 사라진다는 점입니다. 오늘은 이 현상인 Type Erasure(타입 소거)의 본질과 자바가 왜 이런 방식을 택했는지, 그리고 이로 인해 발생하는 제약 사항들을 심층적으로 파헤쳐 보겠습니다.

---

1. Type Erasure(타입 소거)란 무엇인가?

Type Erasure는 자바 컴파일러가 제네릭 타입을 처리하는 방식입니다. 컴파일러는 컴파일 시점에만 제네릭 타입 정보를 사용하여 타입 안정성을 검사하고, 검사가 완료되면 런타임 호환성을 위해 타입 정보를 제거합니다. 즉, 런타임에는 List<String>과 List<Integer>가 모두 동일한 List(Raw Type)로 취급됩니다.

이 메커니즘은 크게 세 가지 단계로 이루어집니다.

• 타입 치환: 제네릭 타입 파라미터(<T>)를 해당 타입의 경계(Bound)가 있다면 경계 타입으로, 없다면 Object로 바꿉니다.
• 타입 캐스팅 추가: 타입 안정성을 보장하기 위해 필요한 경우 적절한 타입 변환(Type Cast) 코드를 삽입합니다.
• 브리지 메서드(Bridge Method) 생성: 확장된 제네릭 타입에서 다형성을 보존하기 위해 보조 메서드를 생성합니다.

---

2. 왜 자바는 Type Erasure 방식을 선택했는가?

C#의 제네릭은 런타임에도 타입 정보가 유지(Reification)되는 반면, 자바는 소거 방식을 택했습니다. 그 가장 큰 이유는 하위 호환성(Backward Compatibility) 때문입니다.

하위 호환성	제네릭 이전 버전(Java 1.4 이하)과 완벽 호환	새로운 런타임 구조 필요, 이전 버전과 호환성 낮음
런타임 오버헤드	거의 없음 (Object로 처리)	각 타입별로 별도의 클래스 정보 관리 필요
런타임 타입 확인	불가능 (instanceof 사용 제약)	가능
성능	컴파일 시점 오버헤드 위주	런타임 생성 비용 발생 가능

---

3. Type Erasure의 동작 방식 (Sample Example)

실제 코드가 컴파일을 거치며 어떻게 변하는지 살펴보면 이해가 빠릅니다.

컴파일 전 코드 (Generic)

public class Box<T> {
    private T data;
    public void setData(T data) { this.data = data; }
    public T getData() { return data; }
}

컴파일 후 바이트코드 상태 (Erasure 적용)

public class Box {
    private Object data; // T가 Object로 치환됨
    public void setData(Object data) { this.data = data; }
    public Object getData() { return data; }
}

만약 <T extends Number>와 같이 경계가 설정되어 있다면, Object 대신 Number로 소거됩니다.

---

4. Type Erasure로 인한 제약 사항과 주의점

타입 소거 때문에 자바 제네릭에는 몇 가지 기술적 한계가 존재합니다.

1. 런타임에 타입 확인 불가: if (list instanceof List<String>)와 같은 코드는 컴파일 에러가 발생합니다. 런타임에는 List일 뿐 String 정보가 없기 때문입니다.
2. 제네릭 배열 생성 불가: new T[10]과 같은 코드는 허용되지 않습니다. 배열은 런타임에도 자신의 원소 타입을 알아야 하는데, 제네릭은 이를 제공하지 못하기 때문입니다.
3. 기본 타입(Primitive Type) 사용 불가: List<int> 대신 List<Integer>를 써야 합니다. 소거 후 Object로 변환되어야 하는데 int는 객체가 아니기 때문입니다.
4. 정적 컨텍스트 제약: 클래스의 static 필드나 메서드는 제네릭 타입 파라미터를 사용할 수 없습니다.

---

5. 결론: 제네릭을 더 깊이 이해하기

자바의 Type Erasure는 하위 호환성이라는 거대한 목표를 위해 선택된 영리한 절충안입니다. 비록 런타임에 타입 정보가 사라지는 제약이 있지만, 컴파일 시점의 강력한 타입 체크만으로도 자바는 충분히 안전한 언어로 거듭날 수 있었습니다. 개발자로서 이러한 내부 동작을 이해하는 것은 단순히 에러를 피하는 것을 넘어, 프레임워크 개발이나 라이브러리 설계 시 발생할 수 있는 'Unchecked cast' 경고를 적절히 처리하고 더 견고한 아키텍처를 설계하는 밑거름이 될 것입니다.

---

참고 문헌 및 출처

• Oracle Java Documentation. "Type Erasure".
• Joshua Bloch. (2018). "Effective Java 3rd Edition". Item 28: Prefer lists to arrays.
• Baeldung. "Java Type Erasure Explained".