스프링 AOP 프록시와 final 키워드의 충돌: `@Repository`의 예상치 못한 NPE 발생 원인 분석

핵심 기술

이 글은 스프링 프레임워크의 AOP(Aspect-Oriented Programming) 프록시 메커니즘, 특히 CGLIB 프록시 생성 방식과 final 키워드의 사용이 어떻게 예상치 못한 NullPointerException(NPE)을 유발하는지, @Repository 어노테이션과 @Component 어노테이션의 차이점을 통해 깊이 있게 분석합니다.

기술적 세부사항

• 문제 상황 재현: @Repository로 지정된 클래스가 추상 클래스를 상속받고, 생성자에서 주입받은 의존성(Dao)이 getAll() 메서드 호출 시 null로 나타나는 NPE 현상을 제시합니다.
• CGLIB Proxy 동작: 스프링이 @Repository와 같이 AOP 대상이 되는 클래스에 대해 CGLIB 라이브러리를 사용하여 프록시 객체를 동적으로 생성하는 원리를 설명합니다.
  • CGLIB는 원본 클래스를 상속받아 프록시 클래스를 생성합니다.
  • 프록시 객체는 실제 로직 수행을 위해 MethodInterceptor를 사용합니다.
  • 프록시 객체의 내부 필드는 생성자 없이 Objenesis를 통해 초기화되므로 기본값(null, 0, false)으로 설정됩니다.
• final 클래스 제한: final 클래스는 CGLIB 프록시 생성이 불가능하여 AopConfigException이 발생함을 보여줍니다.
• final 메서드의 함정:
  • final로 선언된 메서드는 CGLIB 프록시 클래스에서 재정의되지 않습니다.
  • 프록시 객체에서 원본 클래스의 final 메서드를 호출하면, 프록시 객체 자체의 비어있는(null로 초기화된) 필드를 참조하게 되어 NPE가 발생합니다.
  • @Repository 대신 @Component를 사용하면 이 문제가 해결되는 이유는, @Component는 AOP 프록싱 대상에 기본적으로 포함되지 않아 일반 빈으로 등록되기 때문입니다.
• 프록시 객체와 원본 객체 구분: 프록시 객체의 super 호출은 원본 객체가 아닌 프록시 객체의 비어있는 필드를 참조하게 된다는 점을 명확히 합니다.
• @Transactional과 final 메서드: @Transactional과 같은 스프링의 부가 기능이 final 메서드에는 적용되지 않는 이유를 프록시 메커니즘으로 설명합니다.

개발 임팩트

• 스프링 AOP 및 프록시 메커니즘에 대한 깊이 있는 이해를 제공하여, 개발자가 빈 등록 및 라이프사이클 관리 시 발생할 수 있는 잠재적 문제를 사전에 인지하고 방지할 수 있도록 돕습니다.
• final 키워드의 사용이 스프링 프레임워크의 동적 프록시 기능과 충돌할 수 있음을 명확히 경고하며, 스프링 애플리케이션 설계 시 final 키워드 사용에 대한 주의를 환기시킵니다.
• 문제 해결 경험을 공유하며, 개발 과정에서의 '삽질'이 기술적 깊이 있는 이해로 이어질 수 있음을 보여줍니다.

커뮤니티 반응

콘텐츠 작성자가 비슷한 문제를 경험한 동료 개발자와 함께 해결하며 깊이 있는 이해를 얻었다는 점을 언급하며, 실질적인 문제 해결 과정과 학습 경험을 공유하고 있습니다.