Java 제네릭(Generic) 완전 정복

Java 제네릭(Generic) 완전 정복 (정의 ~ 컬렉션까지, 코드 한 줄씩 설명)

1. 제네릭(Generic)이란?

자바에서 변수/매개변수/반환값은 모두 자료형(Type) 을 가집니다.

그런데 실제 개발에서는 아래처럼 “동작은 똑같은데 다루는 타입만 다른” 상황이 정말 많습니다.

• 프린터에 재료를 넣고 꺼내기 (Powder / Plastic)
• 리스트에 요소를 저장하고 꺼내기 (String / Integer)
• 어떤 객체를 담는 박스(Box) 만들기

이때 타입마다 클래스를 매번 새로 만들면 코드가 중복되고, Object로 통합하면 꺼낼 때마다 형변환(캐스팅)이 필요하고 런타임 오류 위험이 커집니다.

✅ 그래서 등장한 것이 제네릭(Generic) 입니다.

제네릭(Generic) 이란
“클래스/메소드에서 사용할 자료형을 나중에(사용 시점에) 결정하도록 하는 방식”입니다.
즉, 타입을 마치 파라미터처럼 받아서 코드를 재사용할 수 있게 합니다.

---

2. 제네릭의 장점

(1) 컴파일 시 강한 타입 체크 (Type Safety)

제네릭을 사용하면 “잘못된 타입”을 실행 전에(컴파일 단계에서) 잡아줍니다.

• 제네릭 없음 → 실행하다가 ClassCastException 같은 런타임 오류 발생 가능
• 제네릭 있음 → 애초에 컴파일이 안 되게 막아줌

(2) 형변환(캐스팅) 제거

제네릭이 없으면 Object로 꺼내오게 되어 캐스팅이 필요합니다.
제네릭을 사용하면 “꺼낼 때 이미 타입이 확정”이므로 캐스팅이 필요 없습니다.

---

3. 제네릭 도입 전: Raw Type(List) 사용 시 문제점 (형변환 + 런타임 오류)

아래 코드는 제네릭을 쓰지 않은 List(= raw type) 예시입니다.

 

✅ 한 줄씩 설명

• List list = new ArrayList();
  • List<T>처럼 타입 파라미터가 없으므로 어떤 타입이든 저장 가능한 상태가 됩니다.
  • 이걸 raw type(로 타입) 이라고 합니다.
• list.add(10);
  • 10은 int(기본형)인데, List는 객체만 저장 가능
  • 자바가 자동으로 Integer(10)으로 바꾸어 저장합니다 (오토박싱)
• list.add("초코");
  • String도 문제없이 들어갑니다.
  • 즉, 지금 list에는 서로 다른 타입이 섞여 있는 상태입니다.
• int num = (Integer) list.get(0);
  • raw type의 get()은 사실상 Object를 반환한다고 보면 됩니다.
  • 그래서 개발자가 직접 (Integer)로 캐스팅해줘야 합니다.
• int snacks = (Integer) list.get(1);
  • list.get(1)은 "초코"(String)인데 Integer로 캐스팅하려고 함
  • 컴파일은 되지만 실행하면 아래 오류 발생:
  • ✅ ClassCastException

결론: 제네릭이 없으면 “섞여 들어가는 것”을 컴파일러가 막지 못하고,
“꺼낼 때 실수하면 런타임에 폭발”합니다.

---

4. 타입별 클래스를 만들면? (중복 코드 폭증)

3D 프린터 예시로 보겠습니다. 재료 타입만 다를 뿐 로직은 동일합니다.

Powder 전용 프린터

 

Plastic 전용 프린터

 

✅ 문제점

• 재료 타입만 다르지 코드는 거의 복붙
• 재료가 늘어날수록 클래스가 계속 증가

---

5. Object로 통합하면? (클래스는 1개지만 매번 캐스팅)

중복을 줄이기 위해 Object로 통합할 수는 있습니다.

 

테스트 코드

 

✅ 한 줄씩 설명

• private Object material;
  • 어떤 재료든 저장 가능해짐
• printer.setMaterial(p1);
  • Powder는 Object의 자식이므로 업캐스팅은 자동 (안전)
• Powder p2 = (Powder) printer.getMaterial();
  • getMaterial()은 Object를 주기 때문에
  • 다시 원래 타입으로 다운캐스팅을 해야 함 (위험)
  • 잘못 캐스팅하면 런타임 오류 발생 가능

✅ 결론

• Object는 “유연하지만 위험하고 불편”합니다.

---

6. 제네릭으로 해결: GenericPrinter<T>

이 문제를 깔끔하게 해결하는 방식이 제네릭입니다.

 

 

✅ 한 줄씩 설명

• public class GenericPrinter<T>
  • T는 “나중에 정해질 타입 자리”입니다.
  • 클래스 사용 시점에 T가 실제 타입으로 치환됩니다.
• private T material;
  • material의 타입이 Powder일 수도, Plastic일 수도 있음 (아직 미정)
• setMaterial(T material)
  • “T 타입만” 받아서 저장
• T getMaterial()
  • 저장된 값을 “T 타입 그대로” 반환
  • 즉, Object가 아니므로 캐스팅이 필요 없음
• toString()
  • 어떤 객체든 toString()은 기본적으로 가지므로 출력 가능

---

7. 제네릭 테스트: 캐스팅 없이 안전하게 사용

재료 클래스:

테스트 코드:

 

✅ 한 줄씩 설명

• GenericPrinter<Powder> powderPrinter = new GenericPrinter<>();
  • 여기서 T는 Powder로 결정됩니다.
• powderPrinter.setMaterial(new Powder());
  • T=Powder이므로 Powder만 저장 가능
• Powder powder = powderPrinter.getMaterial();
  • 반환 타입이 T=Powder이므로 형변환이 필요 없음
• 만약 아래처럼 잘못 넣으려 하면?

 

powderPrinter.setMaterial(new Plastic());

✅ 컴파일 에러 발생
→ 실행 전에 실수를 막아줌(타입 안전)

---

8. 제네릭과 static: 왜 static에는 T를 못 쓸까?

제네릭 타입 T는 인스턴스를 만들 때 결정됩니다.

• GenericPrinter<Powder> → T가 Powder로 정해짐
• GenericPrinter<Plastic> → T가 Plastic으로 정해짐

하지만 static 멤버는 객체 생성 전에 클래스 로딩 시점에 먼저 만들어집니다.
즉, static이 만들어질 시점에는 T가 뭔지 아직 결정되지 않았기 때문에 사용할 수 없습니다.

---

9. 컬렉션 프레임워크에서의 제네릭 (ArrayList<E>)

ArrayList는 내부적으로 이런 형태로 선언되어 있습니다(개념):

 

public class ArrayList<E> { public E get(int index) { return ...; } }

• E는 관용적으로 Element(요소) 를 의미합니다.

예시:

✅ 한 줄씩 설명

• ArrayList<String> list = new ArrayList<>();
  • 이 리스트는 String만 저장하도록 고정
• list.add("hello");
  • String OK
• String s = list.get(0);
  • get()의 반환 타입이 E인데 여기서 E=String
  • 그래서 반환이 String으로 확정 → 캐스팅 불필요

---

마무리 요약

• 제네릭은 타입을 나중에 결정해서 코드 재사용성을 높이고
• 컴파일 단계에서 타입 오류를 잡아주는 타입 안전성을 제공하며
• Object 기반 프로그래밍의 형변환 지옥/런타임 오류 위험을 제거합니다.
•  

---

“Object가 아니므로 캐스팅이 필요 없음” = 반환값의 타입이 이미 확정이라서 ‘확인 작업(캐스팅)’을 안 해도 된다는 말이야.

 

1) 캐스팅(casting)이 뭐야? (한 문장)

캐스팅 = “이 값은 지금 Object로 보이지만, 사실은 ○○타입이야”라고 강제로 타입을 바꿔서 쓰는 것

2) 왜 Object면 캐스팅이 필요해?

✅ Object는 “정체가 안 보이는 값”이야

Object 타입 변수에는 아무 객체나 들어갈 수 있어.

그래서 Object로 받으면 컴파일러 입장에선 이렇게 생각해:

“이 값이 String인지 Integer인지 Powder인지 난 몰라.
그냥 Object일 뿐이야.”

근데 너는 “이걸 String으로 쓰고 싶어!” 라고 하면
컴파일러가 말해:

“난 몰라. 네가 직접 증명해(캐스팅해).”

그래서 캐스팅을 해야 해:

 

3) 그럼 “Object가 아니면” 왜 캐스팅이 필요 없지?

✅ 반환값이 이미 “정체가 확실한 타입”이면 캐스팅이 필요 없어

예를 들어 반환 타입이 Powder면:

여기서는 컴파일러가 이미 알아:

“아 반환값이 Powder구나. 그럼 Powder 변수에 넣어도 안전하네.”

그래서 (Powder) 같은 캐스팅이 필요가 없어.

---

4) 핵심 비교: Object 프린터 vs 제네릭 프린터

❌ (A) Object로 반환하는 프린터      ✅ (B) 제네릭으로 반환하는 프린터 (T)

 

왜 필요하냐면 getMaterial()이 Object를 반환하기 때문이야.
즉, “정체를 모르니까” 네가 직접 Powder라고 증명해야 함.

---

 

왜 캐스팅이 없냐면,
여기서 T는 이미 Powder로 정해졌기 때문이야.

즉 컴파일러 입장에서는:

• printer는 GenericPrinter<Powder>
• 그러면 getMaterial()은 Powder를 반환
• 그래서 Powder p = ...가 자동으로 안전함

---

5) 쉬운 비유 하나로 끝내기

• Object 반환 = 검은 봉투로 받기
  • “안에 뭐 들었는지 몰라”
  • 꺼낼 때 “이거 사과 맞지?” 하고 확인(캐스팅) 해야 함
• Powder/T=Powder 반환 = 라벨 붙은 투명 박스로 받기
  • “Powder 전용”이라고 써있음
  • 그냥 꺼내면 Powder임 → 확인(캐스팅) 필요 없음

---

6) 한 줄로 정확하게 다시 말하면

✅ “Object가 아니므로 캐스팅이 필요 없음”이란 뜻은:

반환값이 Object처럼 “정체 불명”이 아니라
Powder(혹은 T=Powder)처럼 타입이 이미 확정된 형태로 반환되기 때문에
개발자가 (Powder) 같은 캐스팅을 쓸 필요가 없다.

 

 

제네릭(Generic)을 쓰는 이유

1) 타입 실수를 “컴파일 단계”에서 막기 위해 (Type Safety)

제네릭이 없으면(= Object/raw type) 다른 타입이 섞여 들어가도 컴파일은 되고, 실행하다가 터질 수 있어요.

• 제네릭 없음 → 런타임에 ClassCastException 같은 오류 가능
• 제네릭 있음 → 애초에 컴파일 에러로 막아줌

✅ 즉, “실행해보기 전에” 타입 버그를 예방합니다.

---

2) 형변환(캐스팅)을 안 하려고 (편하고 안전)

Object로 받으면 꺼낼 때마다 (Powder), (String)처럼 캐스팅을 해야 해요.
제네릭을 쓰면 반환 타입이 이미 확정이라 캐스팅이 필요 없습니다.

• 제네릭 없음:
•  
  Object x = list.get(0); String s = (String) x;
• 제네릭 있음:
•  
  String s = list.get(0);

✅ 코드가 짧아지고, 캐스팅 실수로 터질 위험도 사라집니다.

---

3) 같은 로직을 “타입만 바꿔서” 재사용하려고 (재사용성/유지보수)

타입만 다르다고 클래스/메소드를 계속 복붙하면 코드가 늘고 유지보수가 어려워요.
제네릭은 “타입 자리(T)”만 바꿔서 같은 코드를 재사용할 수 있게 해줍니다.

예: 프린터 로직은 동일, 재료만 다름

• 복붙 방식: PowderPrinter, PlasticPrinter, … 계속 늘어남
• 제네릭 방식: GenericPrinter<T> 하나로 끝

✅ 중복 제거 + 확장 쉬움 + 유지보수 쉬움.