[Spring] Spring은 왜 많이 쓰일까? -1-

Spring?

간단히 설명했을 때 Spring은 Java 오픈소스 애플리케이션 프레임워크입니다.
엔터프라이즈( Enterprise : 대규모 사업, 기업 )급 애플리케이션을 개발하기 위한 모든 기능을 종합적으로 제공하는 경량화된 솔루션입니다.

즉, 대규모 데이터 처리와 트랜잭션이 동시에 여러 사용자로부터 행해지는 매우 큰 규모의 환경을 개발할 수 있도록 형성된 프레임 워크입니다.

그리고 가장 큰 특징 중 하나인 경량 컨테이너로 자바 객체를 담고 직접 관리하고, 객체의 생성 및 소멸 그리고 라이프 사이클을 관리하는 등의 기능으로 IoC 기반의 프레임워크임을 알 수 있습니다.

Spring이 흥하게 된 계기 이전에 Java EE라는 서버 개발 플랫폼을 알아야 합니다.
→ 플랫폼 : 일반적으로 플랫폼은 컴퓨터의 아키텍처, 운영 체제( Operating System ), 프로그램 언어, 관련 런타임 라이브러리 또는 GUI를 포함함.

Java는 왜 Java일까? - 쉬어가는 타임

단어 리스트 중 무작위로 뽑은 이름이 자바( Java )여서 이름이 자바( Java )가 되었다.

Java EE?

웹 프로그래밍에 필요한 기능을 다수 포함하고 있는 서버 개발 플랫폼.
JSP, Servlet, JDBC, JNDI, JTA, EJB

WAS에서 동작하는 장애복구 및 분산 멀티티어를 제공함.
→ WAS : Java EE 스펙에 따라 제품으로 구현한 것.

대규모, 다계층, 확장성, 신뢰성, 보안 네트워킹 API, 환경 등을 제공

Java EE의 역사

본래 Java의 역할

• 초창기 Java의 초점은 애플릿과 같은 클라이언트 GUI를 구성하는 데 맞춰져 있었다.

서버 개발의 가능성

• 클라이언트 GUI 시장 초점으로 맞춰진 Java는 곧 서버 시장에서의 가능성에도 주목 받게 됩니다.

왜 서버 시장에서 주목하게 되었을까?

• 당시엔 기업용 ( Enterprise ) 서버 소프트웨어 개발이라는 것이 C나 C++을 사용해 다양한 회사의 미들웨어 제품들을 사용해서 개발하는 방식이었기 때문입니다.

그것이 왜 Java의 장점이 되었을까?

• 위와 같이 미들웨어 제품을 사용해 개발하는 방식은 운영체제와 사용하는 미들웨어 제품에 종속될 수밖에 없다. 하지만 'Java의 플랫폼 독립적 특성을 활용해서 미들웨어에 필요한 공통 API를 제공하면 그런 문제를 해결할 수 있지 않을까?'라는 물음의 Java의 서버 개발 가능성을 열어주었습니다.

미들웨어란?

• 응용 소프트웨어가 운영체제로부터 제공받는 서비스 이외에 추가적으로 이용할 수 있는 서비스를 제공하는 것.
  → 응용 소프트웨어는 유연하고 확장, 축소가 편리해야 하며 이러한 장점을 충족하기에 다른 기종간 플랫폼을 다시 구축할 필요가 없어야 한다.

미들웨어는 무엇을 처리하나요?

• route handler 이전에 호출되어 비즈니스 로직 처리 이후 handler로 이어지는 역할을 합니다. Interceptor와 차이점은 Interceptor는 handler 이전과 이후 모두 개입 할 수 있다는 차이점이 있습니다.

미들웨어를 사용한 이유는?

• Naming, Clustering, Thread, Time-out, Replication, Locking, License, Debug, XDR의 기능을 담당하기에 서버에서 미들웨어가 주는 이점은 충분히 컸습니다.

미들웨어 사용 예시

• 클라이언트가 웹 페이지에 접속 했을 때 로그가 필요할 때 미들웨어에서는 사용자가 접속한 로그를 받아 오거나 사용자 인증 등을 수행할 수 있습니다.

Java가 서버 개발 플랫폼으로 등장하다.

• 서버 개발에 필요한 기능을 모아서 J2EE ( 당시 Jave EE 명칭입니다. )라는 표준을 만들고, 각 기업들을 해당 표준을 준수하는 미들웨어 제품을 판매하면 개발자들을 어느 제품을 사용하더라도 API를 새로 공부하거나 제품이나 운영체제에 따라 이식( porting ) 하지 않아도 되도록 했습니다. 흔히 'WAS'로 부르는 Java EE 애플리케이션 서버의 시작이었습니다.

서버 개발자들의 뜨거운 관심을 가지게 된 Java EE

• 출발부터 많은 관심을 받으며 출발했습니다. 기업들은 웹 로직( WebLogic )이나 웹 스피어( WebSphere ) 등 Java EE와 호환되는 애플리케이션 서버 제품을 앞다투어 출시하게 됐습니다. 특히 웹 개발을 위해 Java EE 표준에 포함된 서블릿( Servlet ) 과 JSP는 당시 유행하던 PHP나 ASP와 함께 CGI를 몰아내며 자바 언어가 인기를 얻는데 한몫을 담당합니다.

Java EE 핵심은 EJB?

• Java EE의 핵심은 EJB( Enterprise Java Beans )라는 기술이었는데, 서블릿이나 JSP가 웹 GUI를 만들기 위해 필요한 기술인 반면, EJB는 Java EE가 대체하는 미들웨어에서 구동되던 기업의 핵심 서비스를 만들기 위한 분산처리 및 트랜잭션, 보안 등을 지원하는 컴포넌트 모델을 제공하는 기술이었기 때문이다.

속 빈 강정 EJB

• EJB는 개발자들의 주목을 받으며 널리 쓰이게 되었지만 시간이 지남에 따라 심각한 문제들이 발견됩니다. 실무와 거리가 있는 아키텍트들이 실용성보다는 API의 모양새나 플랫폼 독립성이라는 자바의 특성만을 강조한 설계를 하다 보니 정작 실제 사용할 때 불편한 점이 너무 많았던 것입니다. e.g. EJB 기능 중 하나인 ORM 기능에서 2.x 버전이 나올 때까지 결괏값을 정렬( order by ) 할 수 있는 표준적인 방법조차 제공하지 않음. → 이로 인해 Java EE 서버를 판매하던 회사들이 각자 다른 방식으로 구현해서 제공하여 특정 Java EE 서버 제품에 종속되어 가장 큰 장점으로 언급되었던 플랫폼 독립적 특성에서 멀어지는 결과를 야기했습니다.

XML 지옥 Java EE

• 당시 디자인 패러다임은 '필요함의 존재하는 기본값', 'CoC ( Convention over Configuration : 설정보다 관행, 관례 )' 같은 패러다임이 널리 쓰이기 이전이었기 때문에, Java EE 서버에 산출물을 배포하기 위해선 상당한 분량의 XML 설정을 작성해야 했습니다. 당시 EJB 하나를 배포하려면 XML을 3, 4개를 작성해야 했다고 합니다.

Spring Framework의 등장

• 이러한 문제점을 개선하기 위해 처음 개발되었고, 특히 고가의 풀스택 Java EE 서버가 아닌 Tomcat과 같은 일반 서블릿 컨테이너에서도 구동 된다는 것이 큰 강점으로 작용했습니다.

Tomcat의 시작

• 원래 Tomcat은 Java EE 표준의 일부인 서블릿 기술의 참조 구현( reference implementation )으로 출발했습니다.
• 즉, 원래의 용도는 실제 서비스에 사용하기 보다는 서블릿이나 JSP라는 기술이 이런 것이라는 것을 보여 주기 위한 용도로 쓰였지만, 점차 성능이나 안정성이 개선되면서 이 시점에는 이미 실무에서 사용해도 문제없는 수준으로 발전하게 됩니다.
  → 참조 구현으로 시작 했지만 점차 발전하여 상업 구현의 수준까지 발전함.
• 참조 구현 ( reference implementation )이란? - 특정표준의 구현을 다른사람들이 쉽게 하기 위해서 만든 해당표준을 구현한 샘플 프로그램
• 참조 구현의 목적 - 개발자간의 커뮤니티에서 해당표준에 대한 관심을 증가시키기 위함.
• 참조 구현과 상업 구현의 수준 차이 - 참조 구현은 기술적으로 가능하다는 수준, 좀 더 실용적이면서 고객중심의 사업을 진행하려면 해당 표준의 상업 구현( commercial implementation )을 개발하거나 구매를 해야 함.
• 참조 구현의 필요성 - 표준 스펙의 에러와 모호함을 발견하는데 필요.

Spring Framework가 빠르게 확산된 이유

• Tomcat과 같은 일반 서블릿 컨테이너에서 구동이 가능하다는 점은 더 이상 비싼 Java EE 서버를 구매하지 않아도 EJB보다 훨씬 간편한 방식으로 EJB가 제공하던 선언적 트랜잭션 및 보안 처리, 분산 환경 지원 등 주요 기능을 모두 사용할 수 있게 되었음을 뜻하며, 무엇보다 이제는 더 이상 각 Java EE 서버 제품에 특화된 설정을 따로 공부하거나 서버 제품을 바꿀 때마다 이식 작업이 필요 없이 Spring만 이용하면 Tomcat이든 레진( Resin )이든 기존의 풀스택 Java EE 서버이든 관계없이 간단하게 배포가 가능하다는 뜻입니다.
• 위와 같은 이유로 Spring은 곧바로 개발자들 사이에 빠르게 확산되었고, 특히 국내에선 EJB의 부족한 기능과 개념에 대한 오해 등이 맞물려서 심각한 실패를 경험하는 경우가 잦았는데, 이 때의 트라우마로 인해 Spring이 인기를 얻자 EJB는 완전히 사장 되었고 Spring 일색의 개발 관행이 자리잡게 됩니다.

해외에서는?

• 해외에서는 여전히 Java EE 역시 명맥을 유지할 수 있었는데, 이는 데이터베이스 중심적인 개발 관행이 강하고 Java로는 주로 웹 UI를 만드는데 주력했던 국내와는 달리, 해외에선 본래의 목적대로 Java EE 기반으로 기업의 핵심 인프라를 구축한 사례도 많았기 때문에 그런 크고 복잡한 시스템을 쉽게 Spring으로 이행할 수 없었던 이유도 있습니다.

Spring과 Java EE의 경쟁

• Spring이 인기를 얻은 이후 Java EE 역시 Spring 같은 오픈소스 성공 사례를 적극적으로 받아들여 대폭적인 개선을 했던 점도 크게 영향을 주었습니다.
  → 이로 인해 영향을 받게 된 것 중 가장 대표적인 것이 Spring에서 의존성 주입을 표준 스펙으로 제공하게 되면서 @Autowired 라는 Annotation이 생기게 되었고 이후 Java EE가 이를 받아 들여 표준으로 @Inject라는 개념을 만들고, 다시 Spring이 Java EE 표준을 지원하는 과정에서 양쪽을 모두 사용할 수 있게 된 결과입니다. 결론적으로는 둘 다 같은 개념이라는 것 입니다.

마무리

• 국내에선 Spring이 대세가 되는 바람에 Java EE 기반 프로젝트가 거의 자취를 감추다시피 했지만, Java EE는 기업형 시스템 구축을 위한 Java의 기술 표준으로 꾸준히 발전하고 있습니다. 기능적으로 보면 지금은 Spring을 사용하지 않아도 Java EE 서버에서 개발한다면 DI( Dependency Injection : 의존성 주입 )이나 스케줄러, 배치 작업, 트랜잭션 자동화, ORM 등 서버 개발에 필요한 거의 모든 기술을 편리하게 사용할 수 있습니다.
• 지금까지 역사를 봤을 때 Spring을 많이 쓰게 된 계기는 좋은 Framework라는 이유도 있지만 Java를 많이 사용하는 개발 관행과 Java EE EJB에 대한 트라우마 등 여러가지가 겹쳐서 빠르게 확산된 케이스 인 것 같습니다.
• Framework는 프로젝트의 규모에 따라 정하는 것이 가장 이상적인 것 같습니다. 빠르게 결과를 내야하고 소규모의 프로젝트라면 Python의 Django나 Javascript의 Express 등을 사용하는 것이 더 좋은 것 처럼 이번 정리를 하면서 Spring이 꼭 정답은 아닌 것을 알 수 있었습니다.

참고 자료

• 자바EE의 역사 및 스프링과의 관계
• What is Servlet Container?
• Apache? Tomcat?? 둘이 무슨 차이지?
• API와 미들웨어
• 데이터베이스 중심 프로그래밍