스프링프레임워크는 IoC 컨테이너가 아니다

구글의 미친 밥(Crazy Bob)은 자기 블로그에 올린 스프링 비판(I don’t get Spring)으로 스프링 개발자들 사이에 유명하다. 그는 로드존슨과 스프링 개발자들에게 Effective Java를 읽고 자바의 기초를 좀 배우라고 비아냥 거리기도 했을 정도로 스프링과 그 개발자들을 좋아하지 않는 것 같다. 그의 스프링 비판은 인신공격이나 감정적인 비난은 아니다. 나름 논리를 가지고 있는 것처럼 보인다. 하지만 그의 글을 자세히 읽어보면 스프링의 절대적인 인기에 불만인 것처럼 보이기도 한다. 어쩌면 대중으로부터 절대적인 인기가 있는 기술에 대해서는 일부러 더 삐딱하게 보기를 좋아하는 사람일지도 모르겠다.

그의 글에 대해서는 키스 도날드(Keith Donald)가 댓글을 통해서 열심히 토론을 했다. 자세한 내용은 53개나 달린 댓글을 보면 알 수 있을 것이다.

나는 그의 비판의 내용을 보면서 그의 이야기를 나름 이해할 수 있었다. 그렇다고 그의 스프링에 대한 비판에 동의한다는 뜻은 아니다. 다만 스프링에 대해 잘 모를때 생길 수 있는 자연스러운 반응이라는 점에서 이해할 수 있을 뿐이다.

많은 사람들은 스프링을 단지 IoC 컨테이너라고 생각한다. 물론 스프링의 핵심기술 중의 하나가 Dependency injection/IoC이고 모든 스프링의 기능은 DI/IoC기반위에서 동작하게 되어있다. 하지만 그렇다고 스프링이 하나의 IoC/DI컨테이너라고 생각하는 것은 윈도우를 파일관리하는 프로그램이라고 생각하는 것과 다를바 없다. 파일과 디렉토리의 입출력과 관리는 윈도우의 많은 기능이 동작하게 하는 가장 기본이 되는 핵심기능인 것은 분명하지만 그렇다고 해서 그까짓 파일관리를 위해서 뭐 그리 윈도우가 복잡하냐, 그 정도는 나도 쉽게 만들 수 있다라는 식으로 얘기할 수는 없을 것이다.

결국 Bob Lee는 자신의 주장을 증명하기 위해서였는지 자기 스스로 심플한 IoC/DI 프레임워크를 만들어서 공개했다. 구글주스(Google Guice)라는 이름의 이 IoC프레임워크는 Annotations, Generics를 적극적으로 활용하고 심플한 Interceptor도 사용할 수 있도록 되어있다고 한다. 단지 IoC/DI기능만 필요한 특별한 환경과 조건에서라면 어쩌면 스프링의 IoC컨테이너보다 어떤 점에서는 나을 지도 모르겠다. 사실 나는 아직 이 프레임워크를 살펴보지도 않았고 아마 당분간은 관심이 없을 것 같다. 나에게 단지 IoC/DI기능만 필요로하는 애플리케이션을 제작할 일이 거의 없을 것 같기 때문이다.

Joe Walker처럼 구글주스가 스프링의 경쟁자라고 생각하는 것은 Hibernate3(JPA engine)가 WebLogic10(JEE5 WAS)의 경쟁자라고 생각하는 것과 다를바 없다.

어떤 사람이 오해하는 것처럼은 스프링은 단순히 IoC컨테이너가 아니다. IoC는 스프링의 가장 기초가 되는 기술일 뿐이다. 로드존슨은 한번도 스프링이 IoC컨테이너 또는 AOP프레임워크라고 얘기한 적이 없다. 스프링은 그 문서와 웹사이트에서 정의 하듯이 “Full Stack Application Framework”이다. 스프링은 복잡한 JEE애플리케이션을 더욱 심플하고 더욱 파워풀하게 만들 수 있도록 도와주는 도와주는 애플리케이션 프레임워크이다. IoC컨테이너는 스프링의 중요한 기술이지만 스프링을 그것만으로 이해하는 것은 잘못된 생각이다.

한가지만 더 얘기하자면 Bob Lee의 스프링비판중에 API Doc이 쓸데없이 복잡하다는 얘기가 나온다. 사용자들이 사용할 스펙에 해당하는 퍼블릭API만 나와있으면 되지 그 구현까지 복잡하게 설명했냐는 비판이다. 나 또한 비슷한 생각을 해본적이 있다. 왜 스프링의 내부 구조까지 상세하게 설명하기 위해서 기반이 되는 인터페이스 하나하나에 대해서 그토록 상세한 API Doc을 달았을까하고. 결국 알게 된 것은 스프링은 사용자들에게 공개된 외부API와 구현을 위해서 사용한 내부 구현코드의 구분이 없다는 것이다. 스프링은 그 코드베이스를 거의 수정하지 않고 3년이 넘도록, 2.0이 되도록 계속 발전해 왔다. 스프링의 거의 모든 API가 사용자들이 필요하면 사용할 수 있는 Public API이다. 필요하면 원하는 레벨에서 그것을 사용하거나 이를 확장하고 발전시켜서 사용하도록 권장한다. 그것이 JEE의 스펙/구현 구조나 버전업되면 Public API까지 변경되 버리는 대부분의 프레임워크와 스프링의 가장 큰 차이점일 것이다.

Bob Lee의 글에서 한가지 동감하는 것은 스프링에 대해서 비판적인 자세를 가지라는 것이다. 의심도 없이 사람들이 좋다고 하니 무조건 적으로 특정 기술과 제품을 선호하는 것은 결코 바람직한 태도가 아니다. 스프링에 대한 애정이 담긴 비판과 개선의 요청이 지금의 Spring2.0을 만들어온 원동력일 것이다. 로드 존슨은 그의 책에서 자신의 말도 “무조건 믿지 말라”고 했다. 스스로 검증하고 확인하라는 것이다.

그와 스프링 개발팀은 아직까지도 어노테이션을 통한 DI설정이 XML을 이용하는 것에 비해서 그다지 장점이 없을 뿐더러 별로 바람직하지 않다는 입장을 가지고 있다. 하지만  로드존슨은  “정말 그 기능을 추가하는 것이 스프링 사용에 혼란을 주기보다는 더 나은 결과를 가져올 수 있다”는 증거를 찾고 분명한 확신이 생긴다면 언제든지 자신의 오류를 인정하고 그것을 추가할 것이라고 했다. TSE에서는 아무때고 스프링 개발팀에게 다가와서 어렵고 중요한 문제에 대해서 도전하라고 얘기하기도 했다. 그것이 내가 스프링을 좋아하는 가장 큰 이유이다.

update. Joe Walker의 블로그의 글이 업데이트 됐길래 가보니 몇몇 사람들이 나와 비슷한 지적을 했나 보다.

No related posts.