작성한 질문수 87

7

proxyBeanMethods는 스프링 5.2에서 처음 등장했습니다. 그 전에 이미 @Configuration이 아닌 일반 빈 클래스에서 @Bean을 사용할 수 있게 해주는 @Bean Lite Mode도 소개됐습니다.

여러가지 이유를 생각해볼 수 있습니다.

첫째는@Configuration 클래스에 cglib 런타임 코드 생성 기술을 적용해서 프록시 방식으로 감싸서 동작하기 때문에 생성 비용이 더 크기 때문이다를 들 수 있는데, 사실 이건 아주 미미합니다. 초기에 딱 한번 빈 생성할 때 일어날 뿐이고 사실 요즘 하드웨어에서 느낄 수 있을만큼의 성능저하가 있는 것도 아닙니다. 그렇게 치면 프록시를 cglib으로 만드는 @Transactional도 AOP 프록시 생성 비용 문제가 있을텐데 그 이상의 유용함이 있고, 성능 영향은 아주 미미하기 때문에 디폴트로 cglib proxy 방식을 사용합니다.

둘째는 @Configuratin의 프록시 방식 @Bean 메소드가 여러번 호출할 때 매번 동일 오브젝트가 실행되는 것이 자바 코드를 봤을 때 기대하는 방식과 다르다는 것인데요. 제 입장은 이게 더 중요하다고 봅니다. 해당 클래스를 테스트 등에서 직접 사용해서 @Bean 메소드를 호출했을 때와 런타임에 스프링에 올라가서 사용되었을 때 동작 방식이 다르다는 것은, 상당한 인지 부하들 줄 뿐더러 코드의 동작 방식을 이해하는데 방해가 됩니다. 게다가 @Bean Lite-mode의 메소드와 @Configuration @Bean 메소드가 동작하는 방식이 다르다는 것도 혼동을 줄 여지가 큽니다.
물론 그래야만 했던, 싱글톤 스코프의 빈 오브젝트 생성 메소므를 다른 빈 오브젝트를 생성하는 코드에서 여러번 호출했을 때 여러 개의 오브젝트가 만들어지는 문제를 해결해야 한다는 이유가 있긴하죠. 그런데 이건 메소드 직접 호출 대신에 @Bean 메소드 파라미터로 주입 받는 방식을 이용하면 프록시 없이도 간단히 해결됩니다.

Lite Mode와의 일관성, 그리고 코드가 환경에 따라 다르게 동작하는 문제, 자바 언어의 기본 동작 방식을 위배한다는 문제가 있었고, 대안도 충분히 있기 때문에 proxy 없는 @Configuration을 사용하게 하는게 지금은 권장 비슷하게 되고 있긴한데요.

여전히 스프링 3 이후 코드와의 호환성 때문에 proxy=true가 디폴트일 수 밖에 없긴합니다. 하지만 강의에서도 설명했듯이 스프링 부트의 자동 구성 @Configuration 클래스들은 대부분 proxyBeanMethods=false를 사용합니다.

그리고 이 옵션이 들어가던 즈음이 GraalVM의 네이티브 컴파일 기능을 적극 수용하려고 스프링이 노력하고 있던 때였는데 런타임의 코드 생성 기술인 cglib은 잘 맞지 않는 장애물로 보였을 것입니다. 그래서 cglib을 최대한 사용하지 않도록 개선하려는 노력을 했다는 이야기도 얼핏 들었는데 이건 확실히 모르겠습니다.