리플렉션 (Reflection)

리플렉션이란?

먼저 정의부터 확인해보자.

프로그램 실행 중에 객체나 클래스에 대한 정보(메타데이터)를 동적으로 조사하고 조작할 수 있는 기능

리플렉션은 컴파일 시점이 아니라 런타임에 클래스의 정보를 확인하거나 객체를 다룰 수 있다.

즉, 코드가 작성될 때 어떤 클래스가 올지 몰라도, 프로그램 실행 중에 클래스를 찾아 로드하고 필드, 메서드 호출을 가능하게 하는 기능이다.

코드로 작성된 클래스의 정보가 JVM 메모리에 올라가 있는데, 리플렉션은 이 메모리상의 정보를 읽거나 변경할 수 있다고 이해하면 좀 더 와닿는다.

---

필드 값 확인과 변경은 코드에서도 가능한데, 왜 리플렉션을 사용할까?

바로 리플렉션이 private이나 final 필드 혹은 메서드에도 접근하고 값을 변경할 수 있다는 특징 때문이다.

리플렉션은 JVM 메모리를 통해 접근하기 때문에 private 필드를 외부에서 접근할 수 있으며, final 필드도 기술적으로 변경할 수 있는 방법이 존재하지만, 자바 버전에 따라 제한이 있고 권장되지 않는다.

이와 같은 특징으로 리플렉션은 아주 강력하면서도 위험한 기능이다.

---

리플렉션을 어디에 사용할까?

리플렉션은 주로 프레임워크나 라이브러리에서 사용된다. 대표적인 예시는 아래와 같다.

1. Spring

Spring은 Bean을 관리하고 의존성을 주입할 때 private 필드, 생성자에 접근해야 하는 경우가 있다.
이때 리플렉션을 통해 클래스 구조를 탐색하고, 필드에 값을 주입한다.

Field field = clazz.getDeclaredField("myService");
field.setAccessible(true);
field.set(beanInstance, serviceInstance);

2. JPA, Hibernate 등 ORM 도구

Entity 객체의 필드명을 읽어서 SQL 매핑할 때 리플렉션을 사용한다.

또한 Entity 클래스는 프레임워크가 리플렉션으로 객체를 생성해야 하므로, 외부 코드가 직접 객체를 생성하지 못하도록 생성자를 protected 로 두는 경우가 많다.

이는 프레임워크의 객체 생성 통제를 위한 설계이다.

---

일반 애플리케이션 개발자는 리플렉션을 사용하면 안 될까?

안 될 것은 없지만, 웬만하면 사용하지 않는 것이 권장된다.

아래와 같은 단점이 존재하기 때문이다.

1. 성능 저하

• 메서드 직접 호출보다 느리다.

2. 타입 안정성 상실

• 잘못된 필드명, 메서드명을 쓰면 런타임 에러가 발생한다.

3. 캡슐화 파괴

• 캡슐화를 위한 private 필드와 메서드를 우회해서 접근할 수 있으므로, 캡슐화의 의미가 사라진다.

---

마무리

private, final 등이 안전한 프로그램을 위해 존재할 것이라고 생각했는데, 리플렉션의 존재를 보고 “안전한 프로그램”이 아니라 “불완전한 개발자의 안전한 개발”을 위해 존재한다는 것을 알게 되었다.

이 글은 Entity와 DTO의 생성자 접근 제한 차이를 공부하다가, 간단하게 정리한 리플렉션 내용이기 때문에 내용이 부족할 수 있다.

더 자세히 공부 해봐야겠다.