Spring 3.0 (55) getBean(Class) 등장

이번주는 스프링과 Groovy/Grails의 공동 컨퍼런스인 SpringOne2GX가 열리는 기간이다. 컨퍼런스 발표와 개발자간의 교류, 각종 파티 등으로 분주하게 보내고 있어야 할 시간이지만 우리의 착실한 유겐은 오늘도 열심히 스프링 3.0 마무리 작업에 애를 쓰고 있는 것 같다. 그러나 RC2 이슈가 줄지는 않고 오히려 새로운 이런 저런 기능을 만들고, 기존에 추가한 기능과 코드를 다듬는 작업을 열심히 하고 있다. 유겐은 자신이 만든 코드를 꾸준히 다듬는다. 테스트 코드도 리팩토링 하고 정리하는 등에도 적지 않은 시간을 투자하는 것 같다. 클린업 밥 삼촌이 보면 좋아할 일이다. 새로운 기능이 꾸준히 깔끔하게 추가되려면 먼저 기존 코드들과 설계와 심지어 테스트 조차 잘 정리가 되 있어야 한다. 그래서 남은 이슈를 빨리 줄이는데보다 이런 저런 코드를 다듬어나가는 데 시간을 들이는 것 같다.

아무튼 어제 올라온 업데이트를 보다가 한가지 눈에 띄는 것 발견. 스프링에서 가장 오래된, 무려 8년이 넘은 인터페이스이자 스프링 IoC/DI의 핵심이라고 할 수 있는 BeanFactory에 새로운 메소드가 추가됐다. 

추가된 메소드는 getBean()이다.

<T> T getBean(Class<T> requiredType) throws BeansException;

이미 여러 개의 getBean()이 있는데 뭘 또 추가한 것일까? 그것도 이 시점에서?

사실 나는 이 메소드가 왜 등장하지 않는지에 대해서 2.5 시절부터 의아해했다. 2.5의 대표적인 추가기능은 바로 @Autowired이다. Fine-grained Type Autowiring이라고도 불리는  @Autowired는 타입을 이용한 자동와이어링 기법을 프로퍼티나 메소드 단위로 세밀하게 지정할 수 있도록 만들어준 것이다. 특별한 경우가 아니고는 한 컨테이너에 올라가는 빈들은 대부분 고유한 타입을 가지고 있다. 즉, 대부분 타입당 하나의 빈이 존재한다. 따라서 관리대상인 오브젝트를 후보로 해서 대입가능한 타입을 추적하면 쉽게 DI할 대상을 찾을 수 있다. 나는 이 방식이 사실상 스프링의 표준 DI방식으로 자리잡고 있다고 생각된다.

그런데 스프링 DI의 가장 기본이 되는 BeanFactory 인터페이스의 메소드에는 이렇게 타입을 가지고 고유한 빈을 찾는 메소드가 존재하지 않았다. 물론 일반적으로는 getBean()을 직접 사용하는 경우가 거의 없겠지만, 그래도 종종 테스트나 학습을 위한 목적으로 AC나 BF를 직접 사용하다보면 항상 아쉬운게 이 것이었다. 왜 getBean()은 다 이름으로만 찾도록 만들었을까.

재밌는 것은 빈의 이름은 타입으로 찾는 기능이 있었다는 사실. BeanFactory에 있는 것은 아니지만 대표적인 BF구현인 DefaultListableBeanFactory(AC가 사용하는게 이 놈이다)에는 getBeanNamesForType(Class)라는 것이 있다. 타입을 주면 그에 해당하는 빈 이름들을 배열로 돌려준다.

아무튼 무슨 생각에서였는지 유겐은 이제야 타입을 가지고 빈 오브젝트를 바로 찾아주는 getBean(Class) 메소드를 추가했다. 개념은 @Autowired랑 같다. 주어진 타입과 일치하는 빈이 하나만 존재하면 그것을 돌려주고, 하나 이상이면 예외를 발생시킨다.

getBean(이름) 시대는 이제 서서히 사라지는 것일지도 모르겠다.