영문원문 :
http://www.oreillynet.com/onjava/blog/2006/08/ten_common_misconceptions_abou.html
http://jspgeek.com/18674?category=1
스프링 프래임워크를 처음 접한 사람들에게는 우리가 느끼는 것처럼 몇 가지 에로사항들이 있을 것이다. 사실 아래에 열거한 목록들은 스프링
사용자 교육이나 자바 개발자 커뮤니티의 토론이나 포럼에서 얻은 경험을 바탕으로 만들었다. 이런 이슈사항들을 설명함으로써, 다음 프로젝트에서
스프링을 채택하는 것과 관련해서 더 많은 정보를 바탕으로 판단하였으면 하는 게 우리의 바람이다.
1. 스프링은 경량컨테이너가 아니다. 모든 것을 통합하려는 목표 때문에, 점점 더 비대해지고 비대해진다.
스프링의 주요 목표는 POJO를 기반으로 개발을 단순하게 하는 것이다. 개발자는 해당 업무의 비즈니스 로직에만 신경을 써야지, 구조적인 문제나
복잡한 상호관계에 신경을 써서는 안 된다는 것이다. 프래임워크를 통해서 관련사항들을 반드시 풀 수 있어야 한다.
그러나 엔터프라이즈급 애플리케이션을 만들려면 신경써야할 부분들이 한두 가지가 아니다. 그래서 어떤 의미에선, 엔터프라이즈 애플리케이션 개발자가
엔터프라이즈급 프래임워크에서 생각할 수 있는 모든 기능을 제공하자는 게 스프링의 목표라 할 수 있다. 스프링은 이런 방대한 엔터프라이즈
서비스뿐만 아니라 third party 제품을 지원하고 있어서, 처음에는 방대하고 비대하다고 느낄 수도 있을 것이다. 그러나 엔터프라이즈 급
개발뿐만 아니라 POJO 기반 개발도 할 수 있는 종합적인 통합 플랫폼을 제공하기 위해서, 스프링 프래임워크는 처음부터 서로 독립적이고 모듈화가
가능하도록 디자인하였다. 프로젝트에서 단지 처음에만 필요한 것이 무엇인지 파악하고, 요구사항을 수집하면서 모듈을 추가하거나 제거하기만 하면
된다. 스프링 개발팀은 가능한 모든 것이 단순함을 유지하는데 중점을 두고 있다. 이런 개념은 스프링 자체에도 적용되고, 가장 중요하게 적용되는
곳은 스프링이 적용될 애플리케이션일 것이다.
2. 스프링은 단순한 애플리케이션에서는 쥐약이다.
앞에서 지적한대로, 스프링 프래임워크를 사용하면 단순화시킬 수 있다. 처음에는 처음에 필요한 것만 가지고 개발을 시작하고, 요구사항에 따라
애플리케이션을 만들고 확장하면 된다. 일리에 맞는 것이, 이런 환경은 단순한 애플리케이션을 만드는데 좋은 조건이 될 수 있다.
한 가지를 예로 들어보자. 아무리 단순한 애플리케이션이라고 해도, 일반적으로 트랜잭션 관리처럼 몇 가지 엔터프라이즈 서비스가 필요하기도 하다.
그런 경우, 가장 쉽게 적용할 수 있는 방법이 스프링의 데이터 접근 모듈을 사용하고 트랜잭션 관리를 선언하는 방법이다. 이외에도 단순한
프로토타입이 상용 애플리케이션으로 탈바꿈할 수 있는 상상을 초월할 만한 방법이 스프링에는 있다. 여러분이 이런 애플리케이션을 만들고 있다면,
이런 요구사항을 처리하다 보면 가벼우면서도 확장 가능한 프래임워크의 진가를 알게 될 것이다.
3. 스프링은 대규모 애플리케이션을 감당할 만한 확장성이 없다.
스프링을 기반으로 한 대규모 애플리케이션을 사용하는 곳은 수백의 전 세계 기업들이다. 스프링 프래임워크는 엔터프라이즈 개발 분야에서 확고한
위치를 자리 잡아 왔고, 은행, 정부기관 또는 항공사의 요구사항을 충족시키고 있다.
그 중 한 예가 Voca이다. Voca에서 제공하는 가정의 결제 서비스는 영국 인구의 약 70%를 감당하고 있고, 영국 급여처리의 90%를
담당하고 있다. 2005년에는 50억 건 이상의 거래를 스프링으로 처리하였고, 하루 최고 7,200만 건을 처리하기도 하였다.
스프링을 이용한 애플리케이션의 생산성 및 성능을 입증하는 다른 사례로는 Accenture가 구축한 French Taxation Office
온라인 시스템과 European Patent Office를 들 수 있다.(SpringOne 2006 Keynote, Antwerp,
Belgium)
4. 스프링을 사용하면 아직 표준화되지 않은 AOP(Aspect-Oriented Programming)를 억지로 사용해야만 한다.
스프링의 강력한 기능 중 하나는 AOP(Aspect-Oriented Programming)라는 기술을 사용할 수 있다는 것이다. 그러나 언제나
그런 것처럼 이런 기능은 여러분의 의사에 따라 사용해도 되고, 사용하지 않아도 된다.
스프링 2.0에서는 AOP 기능을 현격히 개선해서 AspectJ를 통합하였는데, 이 말은 여러분이 선택할 수 있는 AOP 종류의 폭이 넓어졌다는
것이다. 많은 사용자들은 스프링의 프락시 기반 AOP를 통해서, AOP의 핵심적인 개념에 한 발작 다가섰으며, 더 많은 기능이 필요할 경우
AspectJ를 적용하기 시작했다.
여러분의 의사결정 과정에서 FUD가 먹혀들기 전에, 반드시 알아야 할 것이 몇 가지 있다. 첫째, 스프링에서 사용하는 프락시를 이용한 AOP
구현 접근 방식은 JDK의 표준 다이내믹 프락시를 사용하고 있다. 이 말은 곧, 실제로 이 기능은 자바 언어의 핵심 표준이라는 것이다. 둘째,
AspectJ는 수년에 걸쳐서 연구한 것으로 현 시점에서는 잘 구축된 사실상의 AOP 표준이다. 셋째, AOP는 OOP(Object-Oriented
Programming )의 특수한 한계에 초점을 맞추고 있기 때문에, 혁명적인 기술이라고 보기 보다는, OOP를 보완하는 기술로 보는 것이 가장
적합하다.
전통적인 OOP는 특정 '관점'을 모듈화할 수 없기 때문에, 코드 중복과 감시, 보안 등의 로직들이 여기 저기 들어가게 된다. AOP를 학습할
때 일단 한번 처음에 고비만 넘긴다면(AOP와 관련된 FUD를 극복하면 아주 쉽게 달성할 수 있다), AOP는 여러 가지 문제들을 해결할 수
있는 가장 자연스러운 접근 방식이라는 것을 깨달을 것이다. 예를 들자면, 스프링 기반 애플리케이션에서는 소스 코드 수정 없이 트랜잭션 관리를 할
수 있다. 곧, 애플리케이션 자체가 매우 유연하며 유지보수도 더 쉬워졌다는 것이고, 소스 코드는 단지 해당 비즈니스 로직만을 담고 있다는
것이다. 이런 유사한 기능덕분에, 점점 더 많은 개발자들이 AOP를 가지고 문제점을 해결하려고 하는 등 실험을 하고 있는 지도 모르겠다.
5. 스프링은 Java Enterprise Edition (JEE)를 대체한다.
이것이야 말로 스프링과 관련된 아주 흔한 오해이며, 아직도 많은 사람들이 이런 식으로 얘기를 하고 있다. 사실, 조금 과장해서 말하자면 스프링은
Java Enterprise Edition을 통합하는 것이다. 스프링이 제시하는 것은 JEE 표준의 기능을 100% 활용하면서, 무겁고 전통적인
Enterprise JavaBean 컴포넌트 모델에 대한 주목할 만한 대안이 될 수 있다는 것이다. 한 가지 목적은, 개발자들이 어쩔 수 없이
상당량의 코드를 반복해서 코딩해야하는데, 쉬운 JEE API를 사용해서 이런 일을 막아 보자는 것이다. 또 다른 목적은 애플리케이션 코드와
엔터프라이즈 서비스를 분리하자는 것이다. 스프링을 사용하면 일관된 생산성과 유연성을 기대할 수 있다.
스프링에서 제공하는 JEE API 목록은 아래와 같다.
· Java Message Service (JMS)
· Java Management Extensions (JMX)
· Java Transaction API
· JEE Connector Architecture (JCA)
· Java API for XML-based Remote Procedure Calls (JAX-RPC)
· JavaMail
· Java Naming and Directory Interface (JNDI)
· and Enterprise JavaBeans (EJB) including version 3.
이외에도 아주 중요한 Java Standard Edition 기술들도 포함된다. Java Database Connectivity (JDBC),
Remote Method Invocation (RMI) 뿐만 아니라 JEE 5에 추가된 Java Persistence API (JPA or
the EJB3 persistence specifications)를 들 수 있다. Hibernate, iBATIS, Quartz, Hessian
등 확고한 위치를 다지고 있는 third party 제품들도 통합하고 있다.
스프링의 JEE 통합은 결코 "가장 낮은 수준의 공통분모"만을 대상으로 하지 않는다. 그 반대로, 모든 기반 기술을 100% 활용할 수 있는
방향으로 접근하고 있다. 다른 말로 하자면, 80%의 개발 시간에 20%의 기능만 사용한다. 나머지 80%의 기능은 필요할 때나 그 가치가 있는
것이다.
이 논제에 대한 심도 있는 읽을거리는 Rod Johnson과 Juergen Hoeller가 집필한 "Expert One-on-One J2EE
Development without EJB"를 참고하기 바란다.
6. 스프링과 EJB는 상호 배타적이다.
앞서 지적한 바대로, 우리는 스프링을 EJB에 대한 "주목할 만한 대안"이라고 표현하였다. 그러나 스프링은 선택을 권장한다. EJB 사용에 대한
선택까지도 말이다. 스프링의 support 클래스를 이용하면, EJB를 구현하거나 스프링 컨테이너의 빈에 접근할 수 있다. 스프링에는 설정
가능한 프락시 메커니즘이 있어서 EJB 클라이언트 코드는 간단한 비즈니스 인터페이스를 통해서 의존성을 가질 수 있다. EJB remote
access, JNDI lookups 그리고 관련 exception은 프락시 뒤에 숨기고 모두 스프링이 관리한다. 이런 추상화는 EJB 기반
레거시 코드와 POJO 기반 신규 코드를 통합하는데 매우 유용하게 사용할 수 있다. 클라이언트는 더 이상 이런 세세한 것까지 몰라도 되기
때문에, 이런 접근 방식은 EJB와 POJO 사이의 마이그레이션을 편하게 해 준다. 흥미로운 것은, EJB3과 POJO 기반 JPA 모델을 함께
사용하기로 했다면, 스프링 기반 애플리케이션을 마이그레션 하는 것이 기존의 EJB 버전의 애플리케이션보다 쉽다는 것을 알 수 있다. 이 외에도,
원한다면, EJB3 없이도 스프링으로 JPA를 사용할 수 있다.
7. 스프링은 EJB3에서 가능한 Java 5 annotation을 사용할 수 없다.
Pitchfork, 스프링 프래임워크의 add-on으로 JSR-250과 JSR-220 (EJB3) annotations의 일부를 지원한다.
Pitchfork는 Interface21과 BEA의 공동연구 결과물로써, Apache 2.0 license로 공개되었다. Pitchfork는
WebLogic의 EJB3 구현의 기반을 제공할 뿐만 아니라, 스프링 프래임워크를 통해서 EJB3을 확장할 수 있다.
스프링 2.0의 핵심중 하나는 JPA (EJB3 persistence)와 annotation을 100% 지원한다는 것이다. 스프링에 포함되어
있는 다른 annotation으로는 transaction management, JMX configuration, 그리고 dependency
validation 등이 있다.
8. 대규모 애플리케이션의 경우 스프링의 XML 파일을 관리하는 것은 짜증 그 자체이다.
잘 관리하지 않았다면, 스프링의 XML 파일은 관리할 수 없을 만큼 정말로 수정하기가 너무 힘들어 진다. 여기서 우리는 적합한 도구와 올바른
기술을 이용해서 직면해 있는 여러 가지 문제점들을 해결하는 방법에 대해서 알아 볼 것이다.
실수 가능성 농후
적합한 도구를 사용하는 것이 필수이다. XML 에디터는 DTD나 XML Schema Definition (XSD)으로 자동완성이나 밸리데이션
기능을 제공한다. 스프링 2.0의 주요 사항 중 하나는 XSD를 기반으로 한 설정이다. 이런 기능은 에디터에게 상당히 많은 정보를 제공할 수
있다. IntelliJ나 이클립스용 스프링 IDE 플러그인을 이용하면 추가적으로 활용할 수 있는 기능이 더 있는데, 클래스 이름 자동 완성과 빈
설정에서 사용 가능한 프러퍼티를 제안해 준다. 드랍다운 목록에서 이름을 선택하면, 시간도 줄이고 실수도 줄일 수 있다.
알아보기가 어렵다
애플리케이션 모듈의 구조에 맞게 반드시 XML 파일을 분리해야 한다. 코드처럼 관련된 설정 정보들은 한 곳으로 묶어 놓고, 주제별로 확실하게
분리해야 한다.
간단한 프러퍼티를 자주 변경하는 경우 상당히 귀찮다
key/value를 쌍으로 하는 설정들은 프로퍼티 파일로 분리시켜야 한다. 이렇게 하면, 간단한 프러퍼티를 바꾸느냐고 XML 설정 파일을 바꿀
필요가 없다. 스프링에서는 configuration과 관련된 다양한 옵션이 있어서, 빈 설정 시 이 configuration 값을 사용할 수
있다.
너무 반복적이다
빈 설정 상속 개념을 활용하면, 여러 곳에서 사용하는 공통 프러퍼티에 대한 반복을 피할 수 있다. 예를 들어, 1개의 "dataSource" 빈
설정은 데이터에 접근하는 여러 빈에서 필요하다. 그런 경우, 추상화된 부모 빈 설정을 통해서 프러퍼티를 공유할 수 있다.
너무 포괄적이다
스프링 2.0의 주요 추가 사항 중 하나는 XSD 지원과 도메인별 네임스페이스이다. 이 기능을 활용하면 공통적으로 설정된 아이템들을 간결하게
사용할 수 있다. 또한 아주 쉽게 네임스페이스를 구미에 맞게 만들 수 있어서, 빈 설정에 도메인별 configuration을 설정할 수 있고,
다른 프래임워크와 통합할 수도 있다.
9. 스프링은 모든 곳에 reflection을 사용하기 때문에, 속도가 느리다.
스프링은 모든 곳에 reflection을 사용하지 않는다. 그러나 reflection을 더 확장해서 사용할 수 있다. 그래서 스프링에서
reflection의 역할을 정확히 알아보고, 일반적인 관점에서 reflection의 성능에 대해서 같이 생각해 보자.
스프링은 의존성을 삽입할 때 reflection을 사용한다. 그러나 정확히 이해해야할 점은 이런 일은 시스템 설정 시간(빈이 서로 역일 때)에만
일어난다. 운영 시 성능 측면에서는 생각해 보면, 자바 코드에 명시적으로 의존성을 삽입한 것과 별반 차이가 없다. 스프링은 스프링 AOP
프래임워크의 JDK 표준인 다이내믹 프락시 객체를 통해서 reflection을 사용한다. 일반적으로 이런 프락시 객체는 transaction
management, security, 또는exporting objects via remote access 같은 기능을 제공하는 서비스에서
사용한다. 네트워크 또는 데이터베이스 접근과 관련된 메서드를 호출하고 실행한다면, 프락시에서 사용하는 reflection으로 인한 성능 저하는
무시해도 좋을 만하다.
어떤 경우에라도, 성능과 같은 의사결정은 적절한 벤치마크를 기준으로 해야지 육감이나 소문으로 결정을 내려선 안 된다. 만일 java 1.3을
사용하고 있다면, reflection과 같은 고전적인 문제점들은 문제가 될 것이다. 그러나 1.4에서는 reflection API의 성능이
2,000%나 향상되었다.
10. 스프링 mvc는 복잡하고 스프링의 다른 부분처럼 간단치가 않다
스프링 mvc는 인터페이스 기반 디자인 덕분에 상당히 확장성이 있고 자유자재로 구성할 수 도 있다. strategy (예 ViewResolver)와
template method (예 SimpleFormController) 같이 잘 알려진 디자인 패턴을 사용하고 있다. 불행하게도, 복잡하다면
설정이나 확장을 잘 못 하기 쉽다. 스프링이 항상 그런 것처럼, 필요한 것만 사용하면 된다. 그러나 선택사항이 무엇이 있는지 잠깐 시간을 내어
파악을 하면 상당한 도움이 될 것이다. 스프링 mvc 컴포넌트들의 단순함과 구성을 보면 얼마나 잘 되어 있는지 절로 감탄사가 나올 것이다.
각각의 모듈들은 HTTP 요청을 처리하고 view를 만드는 라이프사이클의 한 작은 부분에 초점을 맞추고 있다. 이렇게 하면 비즈니스 로직과
프레젠테이션 로직을 분리할 수 있어, 애플리케이션은 강력해지고 유연해진다. 프로젝트에 한번 스프링 mvc를 사용해 보라. 그러면, 강력한 기능과
편리한 사용성의 진가를 맛볼 수 있을 것이다. 작고, 간단한 프로젝트는 스프링 mvc로 분명히 아주 쉽게 구현할 수 있다.
