[Java] 제네릭

🚀 이 주제를 선택한 이유 & 학습 목표

• 선택 배경: 자바 컬렉션 프레임워크를 사용하면서 List<String>, Map<Integer, String>과 같이 타입을 지정하는 문법을 당연하게 사용해왔습니다. 하지만 제네릭이 내부적으로 어떻게 동작하는지, 왜 필요한지에 대한 깊이 있는 이해가 부족하다고 느껴졌습니다. 특히 면접에서 타입 소거(Type Erasure)나 와일드카드(Wildcard)에 대한 질문을 받을 경우 명확하게 설명하기 위해 이번 기회에 제대로 정리하고 싶었습니다.
• 학습 목표:
  • 제네릭의 필요성과 장점을 명확히 설명할 수 있게 됩니다.
  • 타입 소거(Type Erasure)의 개념과 그로 인해 발생하는 제약을 이해합니다.
  • 제네릭 와일드카드(Wildcards)의 종류(? extends T, ? super T)를 이해하고, PECS 원칙을 설명할 수 있게 됩니다.
  • 제네릭 메소드와 제네릭 클래스를 직접 정의하고 활용할 수 있게 됩니다.

---

📚 핵심 개념 및 원리

자바 제네릭은 클래스나 메소드에서 사용할 데이터 타입을 컴파일 시점에 미리 지정하는 방식입니다. 이를 통해 런타임에 발생할 수 있는 타입 관련 오류를 컴파일 시점에 잡아낼 수 있어 코드의 안정성을 높여줍니다.

1. 주요 용어 정의

• 제네릭 (Generic): 데이터 타입을 일반화(Generalize)하는 것을 의미합니다. 클래스나 메소드를 작성할 때, 특정 타입에 종속되지 않고 다양한 타입을 다룰 수 있도록 해주는 기능입니다.
• 타입 매개변수 (Type Parameter): 제네릭 클래스나 메소드를 선언할 때 사용하는, 실제 타입을 대체하는 '플레이스홀더'입니다. 보통 <T> (Type), <E> (Element), <K> (Key), <V> (Value) 와 같이 대문자 한 글자로 표현합니다.
• 타입 소거 (Type Erasure): 자바 컴파일러가 제네릭 코드를 컴파일하는 과정에서 타입 매개변수 정보를 지우고, 대신 특정 타입(주로 Object 또는 지정된 상한 타입)으로 변환하는 과정을 말합니다. 이는 제네릭이 도입되기 이전 버전(Java 5 이전)의 코드와 호환성을 유지하기 위한 메커니즘입니다.
• 와일드카드 (Wildcard): 제네릭 타입을 유연하게 처리하기 위해 사용되는 '알 수 없는 타입'이라는 의미의 기호 ? 입니다. 종류에 따라 상한 경계(<? extends T>)와 하한 경계(<? super T>)를 지정할 수 있습니다.

2. 핵심 원리/동작 방식

제네릭의 핵심은 컴파일 시점의 타입 체크와 자동 형변환입니다.

1. 컴파일 시점 타입 체크: 개발자가 제네릭을 사용하여 List<String>을 선언하면, 컴파일러는 해당 리스트에 String 타입 외의 다른 타입의 객체가 추가되려고 할 때 컴파일 오류를 발생시킵니다.
2. 타입 소거 및 형변환: 컴파일이 완료된 바이트코드(.class 파일)에는 제네릭 타입 정보가 사라집니다 (타입 소거). 예를 들어, List<String>은 그냥 List로, T는 Object로 변환됩니다. 그리고 제네릭을 통해 데이터를 가져올 때는 컴파일러가 자동으로 원래 지정했던 타입으로 형변환 코드를 추가해줍니다.

// 제네릭을 사용하는 간단한 클래스 예시
class Box<T> {
    private T item;

    public void setItem(T item) {
        this.item = item;
    }

    public T getItem() {
        return item;
    }
}

public class GenericExample {
    public static void main(String[] args) {
        // Box<String>을 생성하여 String 타입만 다루도록 제한
        Box<String> stringBox = new Box<>();
        stringBox.setItem("Hello, Generics!");
        // stringBox.setItem(123); // 컴파일 에러 발생! String 타입이 아님

        String content = stringBox.getItem(); // 별도의 형변환(casting)이 필요 없음
        System.out.println(content);

        // 제네릭이 없던 과거의 방식 (Object 사용)
        // Box objectBox = new Box();
        // objectBox.setItem("some text");
        // String text = (String) objectBox.getItem(); // 매번 강제 형변환이 필요하며, 런타임 오류 가능성 존재
    }
}

---

💡 장점, 단점 및 고려사항

장점

• 타입 안정성 (Type Safety): 컴파일 단계에서 의도치 않은 타입의 객체가 저장되는 것을 막아 런타임에 발생할 수 있는 ClassCastException을 예방할 수 있습니다.
• 코드 재사용성 (Code Reusability): 특정 타입에 종속되지 않는 클래스나 메소드를 작성할 수 있어, 다양한 타입에 대해 동일한 로직을 재사용할 수 있습니다. ArrayList가 ArrayList<String>, ArrayList<Integer> 등으로 재사용되는 것이 대표적입니다.
• 가독성 및 유지보수성 향상: 코드에서 다루는 데이터의 타입을 명확하게 알 수 있어 가독성이 높아지고, 불필요한 형변환 코드가 사라져 코드가 간결해집니다.

단점 및 고려사항 (주로 타입 소거로 인해 발생)

• 원시 타입 사용 불가: List<int> 와 같이 원시 타입(primitive type)은 타입 매개변수로 사용할 수 없습니다. 대신 List<Integer>와 같은 래퍼 클래스(Wrapper Class)를 사용해야 합니다.
• 제네릭 타입 객체 생성 불가: new T() 와 같이 타입 매개변수 T를 사용하여 직접 객체를 생성할 수 없습니다. 타입 소거로 인해 컴파일 시점에는 T가 어떤 타입이 될지 알 수 없기 때문입니다.
• instanceof 연산자 제약: instanceof 연산자는 제네릭 타입에 직접 사용할 수 없습니다. if (myList instanceof ArrayList<String>) 과 같은 코드는 컴파일 오류를 발생시킵니다.

유사 기술/개념과의 비교: 제네릭 컬렉션 vs Raw 타입 컬렉션

특징	제네릭 컬렉션 (예: List<String>)	Raw 타입 컬렉션 (예: List)
타입 체크 시점	컴파일 시점 (Compile-time)	런타임 시점 (Run-time)
타입 안정성	높음	낮음 (어떤 타입의 객체든 추가 가능)
형변환	필요 없음 (컴파일러가 자동 처리)	수동으로 필요 (예: (String) list.get(0))
오류 발생 가능성	ClassCastException 예방	ClassCastException 발생 가능성 높음

---

🔧 실제 활용 사례 또는 적용 분야

• Java 컬렉션 프레임워크 (JCF): List<E>, Set<E>, Map<K, V> 등 거의 모든 컬렉션 클래스들이 제네릭을 기반으로 구현되어 있습니다. 이는 JCF의 핵심적인 부분입니다.
• API 및 라이브러리 설계: 다양한 데이터 타입을 처리해야 하는 공통 유틸리티 클래스나 API를 설계할 때 제네릭이 필수적으로 사용됩니다. 예를 들어, 데이터베이스의 결과를 특정 도메인 객체로 매핑해주는 ORM 프레임워크(JPA 등)나, HTTP 요청의 응답을 특정 객체로 변환해주는 라이브러리(Spring의 ResponseEntity<T>) 등에서 널리 쓰입니다.
• 커스텀 자료구조 구현: 직접 스택, 큐, 트리 등의 자료구조를 구현할 때 제네릭을 사용하면, 특정 타입에 국한되지 않는 범용적인 자료구조를 만들 수 있습니다.

---

🤔 나의 이해와 생각 정리 (회고)

• 핵심 요약: 제네릭은 '타입'을 파라미터로 받아 컴파일 시점에 타입 체크를 수행함으로써 코드의 안정성과 재사용성을 극대화하는 자바의 필수 기능이다. 내부적으로는 타입 소거를 통해 하위 호환성을 지키지만, 이로 인한 몇 가지 제약사항도 존재한다.
• 새롭게 깨달은 점: '타입 소거'가 단순히 타입 정보를 지우는 것을 넘어, 왜 그렇게 설계되었는지(하위 호환성)를 이해하게 되었습니다. 또한 와일드카드의 상한/하한 경계(extends, super)가 각각 '데이터를 읽는 경우'와 '데이터를 쓰는 경우'에 대한 유연성을 제공하기 위한 것이라는 점(PECS: Producer-Extends, Consumer-Super)이 명확해졌습니다.
• 더 궁금해진 점 / 의문점: 제네릭과 배열을 함께 사용할 때 발생하는 문제(new T[] 불가 등)의 근본적인 원인은 무엇일까? 리플렉션(Reflection)을 사용하면 런타임에 제네릭 타입 정보를 어느 정도까지 알아낼 수 있을까?

---

✨ 마무리하며

이번 스터디를 통해 막연하게 사용하던 제네릭의 동작 원리를 깊이 있게 파고들 수 있었습니다. 특히 타입 소거라는 '타협'의 산물을 이해함으로써 제네릭의 제약사항들을 명확히 인지하게 되었습니다. 앞으로는 단순히 제네릭을 사용하는 것을 넘어, API를 설계하거나 복잡한 자료구조를 다룰 때 제네릭의 특성을 100% 활용하여 더 견고하고 유연한 코드를 작성할 수 있을 것 같습니다.