제네릭 클래스와 타입 매개변수

게시판 프로그램을 만들다 보면 값 하나를 담아 두었다가 나중에 꺼내 쓰는 작은 상자가 여러 곳에서 필요해집니다. 어떤 곳에는 조회 수를, 어떤 곳에는 게시글 제목을 담습니다. 상자가 하는 일은 넣기(set)와 꺼내기(get)뿐이라서, 담는 값의 타입만 다르고 코드는 똑같습니다. 그렇다면 이 상자를 한 번만 만들어 여러 타입에 쓸 수는 없을까요?

이 글에서는 먼저 지금까지 배운 문법으로 할 수 있는 두 가지 방법을 시험해 봅니다. 타입마다 상자 클래스를 따로 만드는 방법과, Object 하나로 모든 값을 받는 방법입니다. 두 방법이 각각 어디서 막히는지 확인한 다음, 자바가 이 문제를 풀려고 Java 5에서 도입한 제네릭(generics)으로 상자를 다시 만듭니다. 제네릭은 꺾쇠괄호로 코드를 줄여 쓰는 문법이 아니라, '이 상자에 어떤 타입이 들어 있는가'를 컴파일러가 기억하고 검사하게 하는 장치입니다.

타입마다 상자를 만들면 코드가 복제된다

가장 먼저 떠오르는 방법은 담을 타입마다 클래스를 하나씩 만드는 것입니다. 조회 수를 담는 IntegerBox와 제목을 담는 StringBox를 만들면 다음과 같습니다.

class IntegerBox {
    private Integer value;
    void set(Integer value) { this.value = value; }
    Integer get() { return value; }
}

class StringBox {
    private String value;
    void set(String value) { this.value = value; }
    String get() { return value; }
}

이 방법은 안전합니다. IntegerBox의 set은 Integer만 받으므로 문자열을 넣으려 하면 컴파일 오류가 나고, get은 처음부터 Integer를 돌려주므로 꺼낼 때 캐스팅할 필요도 없습니다. 문제는 두 클래스가 타입 이름만 빼면 똑같다는 점입니다. 게시글을 담을 상자가 필요하면 PostBox를 또 복사해야 하고, 상자에 기능을 더하거나 버그를 고칠 때는 복사한 클래스를 모두 찾아 똑같이 고쳐야 합니다. 복사본 하나만 다르게 고쳐졌을 때 어떤 일이 생기는지는 다음 글에서 직접 확인합니다.

Object 하나로 합치면 타입 검사가 실행 시점으로 밀린다

복사를 피하는 두 번째 방법은 모든 클래스의 조상인 Object를 쓰는 것입니다. 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; }
    }
}

실행하면 viewCount=로 시작하는 줄은 끝내 출력되지 않고 예외가 납니다. 첫 줄은 예외의 종류와 메시지이고, 둘째 줄은 예외가 난 위치입니다.

Exception in thread "main" java.lang.ClassCastException: class java.lang.String cannot be cast to class java.lang.Integer (java.lang.String and java.lang.Integer are in module java.base of loader 'bootstrap')
	at ObjectBoxCastFailure.main(ObjectBoxCastFailure.java:7)

한 줄씩 따라가 보겠습니다. box.set(40)에서 int 값 40은 매개변수 타입 Object에 맞추기 위해 Integer 객체로 박싱되어 들어갑니다. 문자열 역시 Object 변수에 담을 수 있으므로 다음 줄의 box.set("forty")도 문제없이 컴파일되고, 이 문자열이 앞의 40을 덮어씁니다. get()의 반환 타입은 Object라서 조회 수로 쓰려면 (Integer)로 다운캐스팅해야 하는데, 이때 상자에 실제로 들어 있는 것은 String입니다. 업캐스팅과 다운캐스팅에서 본 것처럼 캐스트는 객체를 바꾸지 않고 실행 중에 검사만 하므로, 7번째 줄에서 ClassCastException이 나고 println은 실행되지 않습니다.

여기서 눈여겨볼 점은 오류가 보고된 곳과 실수한 곳이 다르다는 것입니다. 스택 트레이스는 캐스팅한 7번째 줄을 가리키지만, 잘못은 문자열을 넣은 5번째 줄에서 이미 일어났습니다. 이 예제는 두 줄이 붙어 있어 금방 찾을 수 있지만, 실제 프로그램에서는 값을 넣는 코드와 꺼내는 코드가 서로 다른 클래스에 있고 실행되는 시점도 다른 경우가 많습니다. 그러면 예외를 보고도 누가 잘못된 값을 넣었는지 거꾸로 추적해야 합니다.

컴파일러가 이 실수를 막지 못한 이유는 막을 정보가 없었기 때문입니다. set(Object value)라는 선언은 '아무 객체나 받는다'는 뜻이니 문자열을 거부할 이유가 없고, get()이 돌려주는 값도 컴파일러가 아는 한 그저 Object입니다. (Integer) 캐스트는 '이 값은 Integer다'라는 프로그래머의 주장일 뿐이어서, 컴파일러는 그 주장이 맞는지 실행할 때 확인하도록 미뤄 둡니다.

정리하면 타입별 상자는 안전하지만 코드가 복제되고, Object 상자는 코드가 하나지만 타입 검사가 실행 시점으로 밀립니다. 우리가 원하는 것은 둘의 장점을 합친 상자, 즉 구현은 하나이면서 쓰는 곳마다 컴파일러가 타입을 검사해 주는 상자입니다.

타입을 매개변수로 받는 Box<T>

제네릭은 타입을 메서드의 매개변수처럼 다룹니다. 메서드가 값을 매개변수로 받아서 호출할 때마다 다른 값으로 일하듯이, 제네릭 클래스는 타입을 매개변수로 받아서 쓰는 곳마다 다른 타입으로 일합니다. 다음 프로그램은 상자 클래스 Box<T> 하나로 조회 수와 제목을 각각 담습니다.

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

클래스 이름 뒤의 <T>가 핵심입니다. class Box<T>는 'Box는 아직 정하지 않은 타입 하나를 받고, 그 타입을 T라고 부른다'는 선언이며, 이 T를 타입 매개변수(type parameter)라고 합니다. 클래스 안에서 T는 보통의 타입 이름처럼 쓰입니다. 그래서 필드 value의 타입도, set의 매개변수 타입도, get의 반환 타입도 모두 T입니다.

T가 실제로 무엇인지는 상자를 쓰는 쪽에서 정합니다. Box<Integer> viewCountBox라고 선언하면, 이 변수로 다루는 상자에서는 T가 모두 Integer인 것으로 검사됩니다. 그래서 viewCountBox.set(45)는 45가 Integer로 박싱되어 통과하고, viewCountBox.get()의 결과는 캐스팅 없이 바로 Integer 변수에 담깁니다. Box<String> titleBox에서는 같은 클래스의 T가 String이 되므로 titleBox.get()은 String을 돌려줍니다. 마지막 줄은 이렇게 꺼낸 제목과 조회 수를 =로 이어 붙여 제네릭 질문=45를 출력합니다.

이때 Box 클래스는 하나뿐입니다. Box<Integer>용 클래스와 Box<String>용 클래스가 따로 만들어지는 것이 아니라, 컴파일러가 하나의 구현을 두고 쓰는 곳마다 다른 타입 정보로 검사합니다. 타입별 상자의 안전성과 Object 상자의 '구현은 하나'라는 장점을 함께 얻은 것입니다.

이제 Object 상자에서 사고를 일으킨 실수를 제네릭 상자에 그대로 해 보겠습니다. 조회 수를 담는 Box<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; }
    }
}

이 파일은 컴파일되지 않습니다. javac lab/WrongGenericAssignmentFailure.java를 실행하면 다음 오류가 납니다.

lab/WrongGenericAssignmentFailure.java:4: error: incompatible types: String cannot be converted to Integer
        box.set("forty");
                ^
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error

box는 Box<Integer>이므로 set의 매개변수 타입은 Integer인데, "forty"는 String이라 Integer로 바꿀 수 없다는 뜻입니다. 오류가 가리키는 곳은 문자열을 넣으려 한 4번째 줄, 즉 실수가 일어난 바로 그 자리입니다. Object 상자에서는 실행 중에, 그것도 값을 꺼내는 곳에서 드러나던 문제가 이제는 실행하기도 전에 값을 넣는 곳에서 드러납니다. 끝의 Note 줄은 진단 메시지를 간단하게 줄여 보여 줬다는 안내이니 신경 쓰지 않아도 됩니다.

제네릭의 진짜 가치는 캐스트 몇 글자를 덜 쓰는 데 있지 않고 이 컴파일 오류에 있습니다. 잘못된 값이 처음 들어가려는 순간에 빌드가 멈추므로, 잘못된 값이 프로그램 안을 돌아다니다가 엉뚱한 곳에서 터지는 일이 없습니다. 아래 도표는 지금까지 본 세 프로그램을 나란히 놓고, 각각 어느 단계에서 끝나는지 비교합니다.

더 깊이: 컴파일된 Box는 Object 상자와 닮았다

GenericBoxTypeSafety.java를 컴파일하면 클래스 파일은 GenericBoxTypeSafety.class와 GenericBoxTypeSafety$Box.class 두 개만 생깁니다. 타입 인자마다 클래스가 복제되지 않는다는 뜻입니다. 컴파일러는 타입 검사를 마친 뒤, 실행에 쓰이는 필드와 메서드의 타입에서 T를 지우고 그 자리를 Object로 바꿉니다. 이를 타입 소거(type erasure)라고 합니다. 클래스 선언에 <T>가 있었다는 정보는 리플렉션과 컴파일러를 위한 부가 정보로 남지만, 실행되는 코드는 T를 모릅니다.

대신 컴파일러는 Integer viewCount = viewCountBox.get();처럼 값을 꺼내는 곳에 Integer로의 캐스트를 직접 넣어 둡니다. 그러니 실행되는 코드만 보면 제네릭 상자도 앞의 Object 상자와 거의 같습니다. 차이는 그 캐스트를 누가 넣었고, 넣기 전에 무엇을 검사했느냐입니다. 컴파일러는 set으로 들어오는 값을 미리 검사했으므로, 뒤에서 볼 raw 타입처럼 검사를 건너뛰는 코드가 끼어들지 않으면 이 캐스트가 실패할 일은 없습니다. 타입 소거가 실행 중에 어떤 제약을 남기는지는 타입 소거와 런타임 한계에서 자세히 다룹니다.

제네릭 용어 정리하기

제네릭을 다루는 글이나 컴파일러 메시지에는 비슷해 보이는 용어가 여러 개 나옵니다. 메서드의 매개변수와 인자를 구분하던 방식대로 정리하면 헷갈리지 않습니다. void set(Integer value)의 value는 매개변수(parameter)이고, set(45)로 호출할 때 넘기는 45는 인자(argument)입니다. 제네릭에서도 선언에 쓰는 이름과 사용할 때 채우는 타입을 구분합니다.

이 비유가 들어맞지 않는 부분도 있습니다. 메서드 인자는 실행할 때 호출마다 넘어가는 값이지만, 타입 인자는 Box<Integer>처럼 코드에 적힌 타입의 일부이고 컴파일러가 검사할 때 씁니다. 앞의 '더 깊이'에서 본 것처럼, 실행 중인 상자 객체는 자기가 Box<Integer>로 만들어졌는지 기억하지 않습니다.

타입 매개변수의 이름은 관례적으로 대문자 한 글자를 씁니다. 가장 흔한 T는 Type의 머리글자이고, 컬렉션의 원소(Element)에는 E, 키와 값(Key, Value)에는 K와 V, 숫자(Number)에는 N, 결과(Result)에는 R을 자주 씁니다. 타입이 둘 이상이면 Pair<K, V>처럼 역할이 드러나는 글자를 고르고, 특별한 역할이 없으면 T 다음에 S, U 같은 글자를 이어 씁니다.

이 관례는 문법 규칙이 아니라서 class Box<Item>처럼 써도 컴파일됩니다. 그래도 한 글자 관례에는 이유가 있습니다. Item은 클래스 이름처럼 보이기 때문에, 읽는 사람은 Item이라는 클래스가 어디 있는지부터 찾게 됩니다. 대문자 한 글자는 '이것은 타입 매개변수'라는 신호가 되어 코드를 빨리 읽게 해 줍니다.

다이아몬드 <>로 타입 인자 줄여 쓰기

앞 예제의 Box<Integer> viewCountBox = new Box<>();를 보면, 오른쪽에는 타입 인자 없이 빈 꺾쇠괄호 <>만 있습니다. 모양 때문에 다이아몬드(diamond)라고 부르는 이 표기는 Java 7부터 쓸 수 있으며, 타입 인자를 문맥에서 알아내라는 뜻입니다. 여기서 문맥은 왼쪽 변수의 타입입니다. 변수가 Box<Integer>이므로 컴파일러는 오른쪽을 new Box<Integer>()로 읽습니다. 이처럼 컴파일러가 코드에 적히지 않은 타입을 문맥에서 알아내는 것을 타입 추론(type inference)이라고 합니다.

다이아몬드는 타입 정보를 없애는 것이 아니라, 같은 정보를 두 번 적지 않게 해 줄 뿐입니다. 그래서 추론할 단서가 없으면 결과가 달라집니다. Java 10부터 쓸 수 있는 var는 지역 변수의 타입을 오른쪽 식에서 정하라고 컴파일러에게 맡기는 선언인데, var와 다이아몬드를 함께 쓰면 왼쪽에도 오른쪽에도 타입 인자가 없게 됩니다. 다음 프로그램은 두 선언을 비교합니다.

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

titles는 왼쪽에 Box<String>이 적혀 있으므로 String 상자이고, 첫 줄에 넣은 safe가 그대로 나옵니다. 반면 var general = new Box<>();에는 T를 정할 단서가 하나도 없습니다. 이럴 때 컴파일러는 T가 될 수 있는 가장 넓은 타입, 즉 아무 제한이 없는 이 Box에서는 Object로 추론해 general을 Box<Object>로 만듭니다. 그래서 general.set("first")도 general.set(7)도 정상적인 호출이고, 두 번째 값이 첫 번째 값을 덮어씁니다.

둘째 줄의 7:Integer는 마지막에 넣은 7과, 그 값이 실행 중에는 Integer 객체라는 사실을 보여 줍니다. getClass()는 실제 객체의 클래스를 알려 줄 뿐이고, general.get()의 컴파일 타입은 여전히 Object입니다. 그렇다고 general이 타입 검사를 받지 않는 것은 아닙니다. 타입이 Box<Object>로 정해졌으니 컴파일러는 그 타입대로 검사해서, Integer n = general.get();이라고 쓰면 Object cannot be converted to Integer, Box<String> other = general;이라고 쓰면 Box<Object> cannot be converted to Box<String>이라는 컴파일 오류를 냅니다.

문제는 검사의 기준이 너무 넓다는 데 있습니다. 담을 값의 종류를 제한하려던 것이라면 Box<String> titles = new Box<>();처럼 왼쪽에 타입을 적거나, var titles = new Box<String>();처럼 오른쪽에 타입 인자를 적어야 합니다.

기본형 대신 래퍼 클래스를 쓰는 이유

타입 인자에는 참조 타입만 올 수 있습니다. 조회 수 상자를 Box<int>로 선언하면 unexpected type이라는 컴파일 오류가 나고, 참조 타입이 필요한데 int가 왔다는 설명(required: reference, found: int)이 붙습니다. 앞의 예제들이 Box<Integer>를 쓴 이유가 이것입니다. 제네릭 클래스는 T 자리에 언제나 객체가 온다고 보고 만들어지기 때문에(컴파일된 코드에서 T는 Object로 바뀝니다), 객체가 아닌 기본형 값은 T 자리에 들어갈 수 없습니다.

Box<Integer>로 써도 set(45)나 Integer viewCount = box.get();이 자연스럽게 동작하는 것은 래퍼 클래스와 박싱·언박싱에서 배운 오토박싱 덕분입니다. 다만 래퍼의 성질도 함께 따라옵니다. 아무것도 넣지 않은 Box<Integer>의 get()은 필드의 기본값인 null을 돌려주므로, int viewCount = box.get();처럼 기본형 변수로 받으면 언박싱하다가 NullPointerException이 납니다. 반복문 안에서 박싱과 언박싱이 쌓이는 비용도 래퍼를 직접 쓸 때와 똑같습니다.

raw 타입: 타입 인자를 빼면 검사도 빠진다

제네릭 클래스를 타입 인자 없이 Box라고만 쓸 수도 있습니다. 이렇게 쓴 타입을 raw 타입(raw type)이라고 합니다. 우리말로는 비매개변수화 타입이나 원시 타입이라고도 옮기는데, 원시 타입은 int 같은 기본형을 부르는 말과 헷갈리기 쉬워서 이 글에서는 raw 타입이라고 쓰겠습니다.

raw 타입이 남아 있는 이유는 호환성입니다. 제네릭이 생기기 전에 작성된 코드는 타입 인자 없이 클래스를 썼고, 새 컴파일러에서도 그런 코드가 계속 컴파일되도록 타입 인자를 생략하는 것을 허용한 것입니다. 대신 raw 타입을 거치면 컴파일러의 타입 검사도 함께 빠집니다.

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; }
    }
}

이 프로그램은 컴파일도 되고 실행도 됩니다. 다만 javac src/RawTypeWarningBoundary.java로 컴파일하면 다음 안내가 함께 나옵니다.

Note: src/RawTypeWarningBoundary.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

실행하면 예외 없이 한 줄을 출력합니다. 컴파일러의 안내는 경고일 뿐 오류가 아니므로 .class 파일은 정상적으로 만들어지고, 실행도 평소처럼 할 수 있습니다.

runtime-type=Integer

Box raw = typed;는 새 상자를 만들지 않습니다. typed가 가리키는 바로 그 객체를 raw라는 다른 이름으로도 가리키게 할 뿐입니다. raw 타입으로 보면 set의 매개변수가 Object로 취급되므로, raw.set(100)은 String 상자에 Integer 100을 넣는데도 컴파일됩니다. 그 결과 Box<String>으로 만든 상자 안에 Integer가 들어 있게 됩니다. 이 main은 값을 Object 변수로 꺼내 실제 클래스 이름만 출력하므로 runtime-type=Integer가 나오고 정상 종료합니다.

컴파일러가 남긴 안내대로 -Xlint:unchecked 옵션을 붙여 javac -Xlint:unchecked src/RawTypeWarningBoundary.java로 다시 컴파일하면, 어느 줄이 문제인지 알려 줍니다.

src/RawTypeWarningBoundary.java:7: warning: [unchecked] unchecked call to set(T) as a member of the raw type Box
        raw.set(100);
               ^
  where T is a type-variable:
    T extends Object declared in class Box
1 warning

raw 타입 Box의 멤버로 set(T)를 호출했으므로, 컴파일러가 타입을 확인하지 못한(unchecked) 호출이라는 경고입니다. 경고는 오류가 아니어서 클래스 파일은 만들어지지만, 컴파일러가 이 줄의 타입 안전성은 확인할 수 없다고 알려 주는 신호입니다.

문제는 나중에 드러납니다. 이 main의 끝에 String title = typed.get(); 한 줄을 덧붙여 실행하면, 그 줄에서 ClassCastException: class java.lang.Integer cannot be cast to class java.lang.String이 납니다. typed는 Box<String>이므로 컴파일러가 get()의 결과에 String으로의 캐스트를 넣어 두었는데, 실제로 들어 있는 것은 Integer이기 때문입니다. 실수는 raw.set(100)에서 했는데 예외는 엉뚱한 읽기에서 나는, Object 상자의 문제가 그대로 돌아온 것입니다. 아래 도표는 덧붙이기 전의 원래 main이 같은 상자에 쓰고 읽는 과정을 차례로 보여 줍니다.

Java 언어 명세는 raw 타입을 오래된 코드와의 호환을 위해서만 허용한다고 밝히고, 제네릭이 도입된 뒤에 작성하는 코드에서는 쓰지 말라고 강하게 권합니다. 앞으로의 버전에서 raw 타입이 금지될 수도 있다는 말도 덧붙여 두었습니다(JLS §4.8). 새 코드에서 어떤 객체든 담는 상자가 필요하다면 raw Box가 아니라 Box<Object>라고 의도를 적으세요. Box<Object>는 raw 타입과 달리 타입 검사를 그대로 받습니다. 예를 들어 Box<Object> anything = typed;는 Box<String> cannot be converted to Box<Object>라는 컴파일 오류가 나므로, 위 예제처럼 String 상자에 다른 이름을 붙여 엉뚱한 값을 넣는 일이 처음부터 막힙니다.

더 깊이: 오래된 raw 코드와 함께 써야 할 때

javac는 기본 설정에서 unchecked 경고를 파일 단위의 Note 두 줄로만 알려 줍니다. -Xlint:unchecked를 붙이면 경고마다 줄 위치를 보여 주고, -Xlint:rawtypes를 함께 켜면 Box raw = typed;처럼 raw 타입을 쓴 선언 자체도 found raw type: Box라고 짚어 줍니다. 빌드 설정에서 이 경고들을 켜 두면 raw 타입이 새로 끼어드는 순간을 놓치지 않습니다.

그래도 제네릭 이전에 만들어진 라이브러리처럼 raw 타입을 돌려주는 코드를 꼭 써야 할 때가 있습니다. 이럴 때는 그 값을 받는 메서드 한 곳에서 원소마다 instanceof로 실제 타입을 확인한 뒤, 새로 만든 타입 안전한 객체로 옮겨 담습니다. 그러면 raw 타입은 그 메서드 안에만 머물고, 나머지 코드는 평범한 제네릭 코드로 남습니다.

경고를 숨기는 @SuppressWarnings("unchecked")는 왜 안전한지 설명할 수 있는 가장 좁은 범위, 예를 들어 변수 선언 하나나 메서드 하나에만 붙이고 그 이유를 주석으로 적어 둡니다. SuppressWarnings의 API 문서도 이 애노테이션을 효과가 있는 가장 안쪽 요소에 붙이라고 권합니다. 클래스 전체에 붙이면 나중에 생긴 새 경고까지 함께 가려지기 때문입니다.

Box<Dog>는 Box<Animal>이 아니다

Dog가 Animal을 구현한다면 Dog 객체는 Animal 변수에 담을 수 있습니다. 그렇다면 Box<Dog>도 Box<Animal> 변수에 담을 수 있을까요? 답은 '아니요'입니다.

Box<Dog> dogBox = new Box<>();
Box<Animal> animalBox = dogBox; // 컴파일 오류

error: incompatible types: Box<Dog> cannot be converted to Box<Animal>

이 대입이 허용된다고 가정하고 따라가 보면 이유가 보입니다. animalBox의 set은 Animal을 받으므로 animalBox.set(new Cat())이 컴파일됩니다. 그런데 animalBox와 dogBox는 같은 상자이므로, 이제 dogBox.get()은 Dog를 돌려준다고 선언되어 있으면서 실제로는 Cat을 꺼내게 됩니다. raw 타입에서 본 문제가 다시 생기는 것입니다. 그래서 자바는 Dog와 Animal의 관계와 상관없이 Box<Dog>와 Box<Animal>을 서로 관계없는 타입으로 다루는데, 이런 성질을 불공변(invariant)이라고 합니다.

그렇다고 개 상자와 고양이 상자를 함께 받는 메서드를 만들 수 없는 것은 아닙니다. 여러 매개변수화 타입을 안전하게 받는 방법은 와일드카드를 다루는 글에서 배웁니다.

더 깊이: 배열은 반대쪽을 택했다

배열은 제네릭과 반대로 동작합니다. Dog[]는 Animal[] 변수에 대입할 수 있는데, 이런 성질을 공변(covariant)이라고 합니다. 대신 그렇게 대입한 배열에 Cat을 넣으면 컴파일은 되지만, 실행 중에 JVM이 배열의 실제 원소 타입을 확인하고 ArrayStoreException을 던집니다. 배열은 대입을 허용하고 실행 중에 검사하는 쪽을, 제네릭은 대입을 막아 컴파일할 때 문제를 잡는 쪽을 택한 것입니다. 두 방식이 한 코드에서 만날 때 생기는 제약은 타입 소거와 런타임 한계에서 다룹니다.

제네릭으로 만들 만한 클래스

제네릭이 잘 맞는 것은 담는 값의 타입만 다르고 하는 일은 같은 클래스입니다. 이 글의 상자처럼 값을 보관하고 꺼내는 방법이 타입과 상관없다면, 타입 매개변수 하나로 모든 타입을 처리할 수 있습니다. 반대로 타입마다 동작과 지켜야 할 규칙이 크게 다르다면, 하나의 제네릭 클래스에 억지로 합치기보다 타입마다 자기 클래스를 두는 편이 낫습니다. 타입 매개변수가 너무 많아서 쓰는 사람이 매개변수 사이의 관계를 이해하기 어렵다면 더 작은 타입으로 나누는 것도 방법입니다.

정리

• Object로 값을 받는 클래스는 구현이 하나지만, 잘못 넣은 값을 컴파일러가 막지 못하고 꺼낼 때의 캐스팅에서 실행 중에 실패합니다. 타입마다 클래스를 만들면 안전하지만 코드가 복제됩니다.
• 제네릭 클래스는 class Box<T>처럼 타입 매개변수를 선언하고, 사용하는 쪽이 Box<Integer>처럼 타입 인자를 정합니다. 구현은 하나이고 쓰는 곳마다 컴파일러가 타입을 검사하므로, 잘못된 값은 넣는 줄에서 컴파일 오류가 됩니다.
• 다이아몬드 <>는 타입 인자를 문맥에서 추론하게 합니다. var와 함께 쓰면 단서가 없어 Box<Object>가 되므로, 이때는 오른쪽에 타입 인자를 적습니다.
• 타입 인자에는 참조 타입만 올 수 있습니다. int 대신 Integer를 쓰고, null 언박싱에 주의합니다.
• raw 타입은 오래된 코드와의 호환을 위해 남은 표기로, 타입 검사를 건너뜁니다. unchecked 경고를 무시하지 말고, 아무 객체나 담으려면 Box<Object>를 씁니다.
• Dog가 Animal의 하위 타입이어도 Box<Dog>는 Box<Animal>의 하위 타입이 아닙니다.

연습 문제

1. 두 값을 묶는 Pair<F, S>를 작성하세요. 첫 값과 둘째 값의 타입은 서로 달라도 됩니다. 생성자에서 두 값을 받고 first()와 second()로 읽게 하며, 만든 뒤에는 값을 바꿀 수 없어야 합니다. 게시글 제목과 조회 수("제네릭 질문"과 50), 회원 이메일과 활성 상태("[email protected]"과 true)를 각각 묶어 first=second 형식으로 한 줄씩 출력하세요. 다 만들었다면 같은 구현으로 Pair<Integer, String>에 7과 "draft"를 넣을 때 first()와 second()의 반환 타입과 출력을 예상해 보세요.

2. 다음 코드에서 ①부터 ⑤까지의 각 줄이 컴파일 오류인지, 경고만 나는지, 문제없이 컴파일되는지 예상하세요. Box는 이 글의 Box<T>와 같습니다.

   Box<String> a = new Box<>();
   a.set(10);              // ①
   var b = new Box<>();
   b.set(10);              // ②
   Integer n = b.get();    // ③
   Box c = a;
   c.set(10);              // ④
   Box<Object> d = a;      // ⑤

3. Dog와 Cat이 모두 Animal을 구현한다고 합시다. 자바가 Box<Dog>를 Box<Animal> 변수에 대입하도록 허용한다면 어떤 코드가 문제를 일으킬지 네 줄 안팎으로 써 보고, 문제가 어디서 드러날지 설명하세요.

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

Box<Dog> dogBox = new Box<>();
Box<Animal> animalBox = dogBox;  // 허용된다고 가정
animalBox.set(new Cat());        // Animal 상자이므로 통과
Dog dog = dogBox.get();          // 실제로는 Cat이 나온다

다음 글

타입별 클래스 중복을 제네릭으로 줄이기에서는 개 병원과 고양이 병원처럼 타입마다 복사한 클래스가 시간이 지나며 어떻게 서로 다른 규칙을 갖게 되는지 확인하고, 공통 알고리즘을 제네릭 클래스 하나로 모으는 방법을 살펴봅니다.