Object 박스와 제네릭 타입

제네릭은 꺾쇠 문법을 줄여 쓰는 기능이 아니라 “이 컨테이너가 어떤 타입을 보관하는가”를 컴파일러가 추적하게 하는 장치입니다.

타입별 클래스를 복사하면 중복이 늘고, Object 하나로 합치면 잘못 넣은 값 때문에 나중에 캐스팅에서 실패합니다.

두 실패를 모두 피하는 과정을 JDK 25 컴파일과 실행으로 확인합니다.

Object 박스의 타입 오류

Object는 모든 참조 타입을 담을 수 있으므로 숫자용으로 생각한 박스에도 문자열을 저장할 수 있습니다.

get의 반환도 Object라 호출자가 원하는 타입으로 다운캐스팅해야 합니다.

public final class ObjectBoxCastFailure {
    public static void main(String[] args) {
        ObjectBox box = new ObjectBox();
        box.set(40);
        box.set("forty");

        Integer viewCount = (Integer) box.get();
        System.out.println("viewCount=" + viewCount);
    }

    private static final class ObjectBox {
        private Object value;
        void set(Object value) { this.value = value; }
        Object get() { return value; }
    }
}

java.lang.ClassCastException:
class java.lang.String cannot be cast to class java.lang.Integer

오류 원인은 캐스팅 문장에 보이지만 실제 잘못은 앞선 set에서 시작됐습니다.

두 지점이 멀수록 스택 추적만으로 누가 잘못된 값을 넣었는지 찾기 어렵습니다.

타입 안전성이 런타임까지 미뤄졌다는 뜻입니다.

타입별 IntegerBox, StringBox, PostBox를 만들면 잘못 넣는 문제는 막지만 필드·setter·getter가 똑같이 반복됩니다.

새 타입마다 클래스를 하나 더 만들고 버그 수정도 여러 파일에 적용해야 합니다.

타입 매개변수와 다중 계약

클래스 선언의 <T>는 아직 정해지지 않은 타입 매개변수입니다.

사용할 때 Box<Integer>처럼 타입 인자를 전달하면 set과 get의 T가 모두 Integer인 것으로 검사됩니다.

실제 코드 복사본을 여러 개 만드는 것이 아니라 컴파일러가 한 구현에 전달된 타입 정보를 적용합니다.

public final class GenericBoxTypeSafety {
    public static void main(String[] args) {
        Box<Integer> viewCountBox = new Box<>();
        viewCountBox.set(45);
        Integer viewCount = viewCountBox.get();

        Box<String> titleBox = new Box<>();
        titleBox.set("제네릭 질문");
        String title = titleBox.get();

        System.out.println(title + "=" + viewCount);
    }

    private static final class Box<T> {
        private T value;
        void set(T value) { this.value = value; }
        T get() { return value; }
    }
}

제네릭 질문=45

호출자는 다운캐스팅하지 않습니다.

Box<Integer>에는 String을 넣을 수 없고 get()은 Integer를 반환합니다.

잘못된 값은 저장 지점에서 즉시 컴파일 오류가 되므로 원인과 진단 위치가 가까워집니다.

public final class WrongGenericAssignmentFailure {
    public static void main(String[] args) {
        Box<Integer> box = new Box<>();
        box.set("forty");
    }

    private static final class Box<T> {
        private T value;
        void set(T value) { this.value = value; }
    }
}

error: incompatible types: String cannot be converted to Integer

제네릭의 가치는 캐스팅 글자 수보다 이 컴파일 실패에 있습니다.

값이 잘못 들어간 최초 지점에서 빌드를 멈춥니다.

제네릭 용어의 구분

class Box<T>에서 T는 선언 측의 타입 매개변수입니다.

Box<Post>에서 Post는 사용 측의 타입 인자입니다.

타입 인자가 적용된 Box<Post>는 매개변수화 타입이고, <T>를 가진 Box 선언은 제네릭 타입입니다.

이름은 보통 T(Type), E(Element), K(Key), V(Value), R(Result)을 사용합니다.

의미가 둘 이상이면 Pair<K, V>처럼 역할을 드러냅니다.

관례는 짧은 코드를 읽기 위한 공통 언어이지 반드시 한 글자여야 한다는 문법 규칙은 아닙니다.

생성식 오른쪽의 타입 인자는 왼쪽 변수 선언과 인수 문맥에서 추론할 수 있어 new Box<>()로 생략할 수 있습니다.

이것이 타입 추론이며, 다이아몬드가 타입 자체를 없애는 것이 아니라 컴파일러가 같은 정보를 계산한다는 뜻입니다.

var box = new Box<>()처럼 양쪽에 근거가 없으면 Object로 추론될 수 있어 의도한 계약이 약해집니다.

두 선언을 같은 작은 프로그램에서 비교하면 추론의 근거가 보입니다. 왼쪽에 String을 선언한 박스는 String 계약을 유지합니다. 반면 아래 var 선언의 생성식에는 특정 타입을 정할 인수나 목표 타입이 없으므로 Box<Object>로 추론됩니다. 이것은 raw 박스가 아니며 Object라는 타입 인자가 정해진 박스입니다.

예시

public final class DiamondInferenceContext {
    public static void main(String[] args) {
        Box<String> titles = new Box<>();
        titles.set("safe");
        var general = new Box<>();
        general.set("first");
        general.set(7);
        Object observed = general.get();
        System.out.println("title=" + titles.get());
        System.out.println("general=" + observed + ":"
                + observed.getClass().getSimpleName());
    }

    private static final class Box<T> {
        private T value;
        void set(T value) { this.value = value; }
        T get() { return value; }
    }
}

title=safe
general=7:Integer

문자열 뒤 정수를 넣는 것이 이 general 박스에서는 정상 계약입니다. 값의 종류를 제한하고 싶다면 왼쪽 타입 또는 생성식의 타입 인자를 명시해야 합니다. 런타임 클래스 이름을 출력하는 일은 이미 정해진 컴파일 타입을 바꾸지 않습니다.

기본형은 타입 인자로 사용할 수 없으므로 Box<int>가 아니라 Box<Integer>를 씁니다.

오토 박싱이 입출력을 돕지만 null 가능성과 언박싱 비용은 래퍼 계약 그대로 남습니다.

비매개변수화 타입의 제한

Box box = new Box()처럼 타입 인자를 생략한 비매개변수화 타입(raw type)은 제네릭 이전 코드와의 호환을 위해 남아 있습니다.

내부적으로 타입 검사가 약해져 다시 Object 박스와 비슷한 위험이 생깁니다.

public final class RawTypeWarningBoundary {
    public static void main(String[] args) {
        Box<String> typed = new Box<>();
        typed.set("safe");

        Box raw = typed;
        raw.set(100);

        Object observed = raw.get();
        System.out.println("runtime-type=" + observed.getClass().getSimpleName());
    }

    private static final class Box<T> {
        private T value;
        void set(T value) { this.value = value; }
        T get() { return value; }
    }
}

runtime-type=Integer

컴파일러는 unchecked 경고를 내지만 호환 때문에 빌드를 허용할 수 있습니다.

이후 typed.get()을 String으로 받으면 컴파일러가 삽입한 캐스팅에서 ClassCastException이 납니다.

경고를 무시하지 말고 raw API 입구에서 검증·복사해 타입 안전 영역으로 옮깁니다.

단순히 모든 값을 담고 싶다면 raw가 아니라 Box<Object>로 의도를 명시합니다.

제네릭 도입 범위

값의 타입만 달라지고 보관·조회 알고리즘이 같다면 제네릭 타입이 적합합니다.

반대로 타입마다 행동과 불변식이 크게 다르면 하나의 Box에 억지로 합치지 말고 각 도메인 타입이 책임을 갖게 합니다.

제네릭 매개변수가 많아 호출자가 관계를 이해하기 어렵다면 API를 작은 타입으로 나눕니다.

Box<Dog>와 Box<Animal>은 서로 다른 타입입니다.

Dog가 Animal의 자식이어도 제네릭 타입이 자동으로 같은 상속 관계를 만들지 않습니다.

그렇지 않으면 Box<Animal>으로 받은 코드가 Cat을 넣어 원래 Dog 박스를 오염시킬 수 있습니다.

이 불공변성 문제는 뒤의 와일드카드에서 안전한 읽기·쓰기 범위로 해결합니다.

프로젝트 환경은 JDK 25의 javac와 java를 같은 버전으로 사용합니다.

제네릭 진단은 컴파일 단계에서 발생하므로 IDE의 빨간 줄만 믿지 않고 실제 빌드 명령으로 확인합니다.

-Xlint:unchecked는 비매개변수화 타입과 확인되지 않은 캐스팅 경계를 찾는 데 유용합니다.

컴파일 경고를 분류할 때는 경고가 생긴 가장 작은 경계를 찾습니다.

레거시 라이브러리에서 받은 raw 값 하나 때문에 서비스 전체에 @SuppressWarnings("unchecked")를 붙이면 이후 새 위험까지 보이지 않습니다.

어댑터 메서드 안에서 원소를 하나씩 Class.isInstance로 확인한 뒤 새 컬렉션에 복사하고, 정말 증명 가능한 캐스팅 한 줄에만 억제를 제한합니다.

억제 주석에는 어떤 외부 계약 때문에 안전한지 근거를 남깁니다.

빌드와 실행 JDK가 다르면 최신 문법 지원 여부뿐 아니라 진단 위치도 달라질 수 있습니다.

이 교재 예제는 java -version과 javac -version이 모두 25인지 확인하고 같은 소스를 매번 독립 컴파일합니다.

IDE가 내부 증분 빌드 캐시로 성공시킨 결과보다 깨끗한 명령행 컴파일을 최종 계약으로 삼습니다.

제네릭은 런타임 테스트만으로 모든 잘못된 조합을 방문할 수 없으므로, 의도한 컴파일 실패 자체도 중요한 학습 결과입니다.

연습 문제

첫 값과 둘째 값의 타입이 독립적인 Pair<F, S>를 작성하세요.

생성 뒤 값을 바꾸지 못하게 만들고, 게시글 제목·조회 수와 회원 이메일·활성 상태를 각각 묶어 보세요.

Pair는 두 값을 생성자에서 받고 first()와 second()로 읽게 합니다. setter는 제공하지 않습니다. 게시글은 "제네릭 질문"과 50, 회원은 "[email protected]"과 true를 입력하고 각 쌍을 first=second 형식으로 출력합니다. 두 타입 인자는 서로 같을 필요가 없으며 null 검증은 이번 연습의 요구에 넣지 않습니다.

같은 구현으로 Pair<Integer, String>에 7과 "draft"를 넣을 때 두 접근자의 반환 타입과 출력 한 줄도 먼저 예상하세요.

public final class GenericPairExercise {
    public static void main(String[] args) {
        Pair<String, Integer> post = new Pair<>("제네릭 질문", 50);
        Pair<String, Boolean> member = new Pair<>("[email protected]", true);

        System.out.println(post.first() + "=" + post.second());
        System.out.println(member.first() + "=" + member.second());
    }

    private record Pair<F, S>(F first, S second) { }
}

제네릭 질문=50
[email protected]=true