[Spring Framework] 스프링을 사용하는 이유

 

 

이전 포스팅에서도 작성을 했지만, 

스프링을 사용하지 않았을 때의 문제 세 가지를 꼽자면 다음과 같다.

- 오브젝트의 생명 주기 문제
- 부품화 문제
- 기술 은닉과 부적절한 기술 은닉 문제 

 

이러한 문제를 해결하지 않는 한 웹 애플리케이션은 리소스를 잘 이용하지 못하고, 테스트하기 어려우며, 확장이나 변경도 어려워질 것이다. 스프링은 이러한 문제를 해결하기 위해 태어난 컨테이너라고도 할 수 있다. 자세한 내용은 나중에 설명하겠지만, 스프링은 다음처럼 문제를 해결해줄 수 있다.

 

- 오브젝트의 생명 주기 문제는 DI 컨테이너로 해결
- 부품화 문제는 DI 컨테이너로 해결
- 기술 은닉과 부적절한 기술 은닉 문제는 AOP로 해결

 

 

스프링은 Java/Java EE용 오픈 소스 프레임워크이고, 현재는 Pivotal 사의 소수 정예 엔지니어가 관리하고 있다. 가끔 시스템을 개발할 때 오픈 소스는 '누가 만드렁ㅆ는지 알 수 없다'는 이유로 채택을 주저한다는 이야기가 들리지만, 스프링에 한해서는 처음 등장할 때부터 Pivotal사에서 관리-운영되고 있는 오픈 소스여서, 다른 회사에서 제품으로 팔고 있는 프레임워크나 패키지와 같이 안심하고 사용할 수 있다.

시스템을 개발할 때 '앞으로의 유지 보수를 생각해서 표준인 Java EE가 좋다'라는 생각으로 스프링 채택을 주저한다는 이야기도 들린다. 

 

하지만, 생각해보면 표준이 우선이라고 생각하는 것은 IT 세계에서 별로 도움이 되지 않는다. 예를 들어 EJB 버전 1을 이용해 만든 시스템을 개선할 때, EJB가표준이었다는 것에 얼마나 의미가 있었는가 하는 것이다.

또한, Java EE의 CDI(Contexts and Dependency Injection)는 스프링 DI보다 늦게 나왔고, 구글과 스프링의 영향으로 만들어졌다는 이야기도 있다. JPA도 마찬가지로 오픈 소스 하이버네이트의 영향을 많이 받았고, 또 Java EE7에서 발표된 자바 배치 (Batch Applications for the Java Platorm jBatch)는 스프링 배치를 참고하고 있다. 

결국, Java EE의 사양은 스프링과 하이버네이트를 지지하는 분들도 참가해서 만들어지고 있으며, Java EE가 널리 사용될 때 오픈 소스는 다음 세대의 기술을 적용하고 있을 것이고, Java EE는 결국 오픈 소스를 참고해서 수정해갈 것이다. 덧붙여 Java EE는 스프링과 하이버네이트보다 대응할 수 있는 범위가 좁다.

시스템에 지금 필요한 최신 기능을 이용할 때는 Java EE보다는 스프링이 유리할 것이다. 예를 들어 과거 웹소켓(WebSocket)을 사용할 필요가 있었을 때 Java EE는 이용할 수 있는 서버를 몇 년 동안 기다려야 했지만, 스프링은 바로 이용할 수 있었다. 또, 다음 시대를 예견하는 마이크로서비스 아키텍처와 클라우드 네이티브의 애플리케이션은 스프링 부트를 제외하고는 말할 수 없을 것이다.

이러한 이유로 스프링은 앞으로도 계속 많이 사용될 것이고, 지금 스프링을 이용할지 말지 고민하고 있다면 이용해보자.