[코드잇][위클리페이퍼][4주차] Spring Framework의 탄생 배경

아래는 4주차 위클리페이퍼 주제이다.

• Spring Framework가 탄생하게 된 배경과 이를 통해 해결하고자 했던 문제점에 대해 설명하세요.
• 프레임워크와 라이브러리의 차이점을 제어 흐름의 주체와 사용 방식을 중심으로 설명하고, Spring Framework와 일반 Java 라이브러리를 예시로 들어 설명하세요.

이번 포스팅에서는 첫 번째 주제에 대해서 다룬다.

이번 주제는 스토리텔링 방식으로 서사를 나열하려고 한다.

 

혹독한 겨울을 지나, 봄(Spring)이 오다

스프링 프레임워크라는 이름에는 단순히 '봄'이라는 계절 이상의 의미가 담겨있다.

바로 EJB(Enterprise JavaBean)이라는 혹독한 겨울에서의 해방이라는 의미를 가지고 있다.

도대체 EJB가 무엇이고 어떤 문제점이 있길래 혹독한 겨울이라고 불렸을까? EJB가 등장하게 된 배경과 그 한계를 살펴보자.

 

엔터프라이즈 개발의 난관과 EJB의 등장

1990년대 후반, 자바 진영에 서블릿과 JSP가 등장했다. 이 기술들은 정적인 HTML만 보여주던 웹을 동적으로 바꾸는 혁명이었고 많은 개발자들이 자바로 웹을 만들기 시작했다. 하지만 이 기술을 은행 등 규모가 큰 엔터프라이즈 시스템에 적용하여 개발하려고 하니 큰 문제가 발생하였다. 트랜잭션, 보안 처리, 분산 처리와 페일 오버와 같은 비기능적 요구사항을 구현하다보니 스파게티 코드가 되어 유지보수가 매우 어렵고, 비즈니스 로직에 집중할 수 없었다. 이 상황을 해결하기 위해 썬 마이크로시스템즈에서 주도하여 IBM과 BEA 등의 벤더 기업과 함께 인프라(트랜잭션, 보안 등)을 알아서 해주는 컨테이너를 만들었고 이게 바로 EJB(Enterprise JavaBeans)이다.

 

EJB가 가져온 또 다른 겨울 (문제점)

EJB는 이론적으로는 완벽했지만 또다른 문제를 불러일으켰다. 가장 큰 문제점은 침투성이었는데 프레임워크가 코드의 주인이 되는 것으로, 간단한 비즈니스 로직을 작성하려고 해도 EJB가 강요하는 상속과 인터페이스를 붙여야했다. 이는 자바의 최대 장점인 객체지향을 활용할 수 없게 하였고 유지보수가 어려운 코드가 되게 하였다.

또한, EJB는 매우 무거운 WAS(WebLogic, WebSphere) 위에서만 돌아갔고, 이는 코드를 한 줄만 수정해도 엄청난 로딩을 기다린 후에 결과를 확인할 수 있는 문제가 있었다. 그리고 EJB 코드는 EJB 컨테이너(위에서 언급한 WAS가 가지고 있음)에서만 작동했기에 단위 테스트는 불가능했다.

 

스프링(Spring)의 탄생과 해결책

바로 위의 상황이 스프링이 탄생하게 된 배경이다. 위에서 언급한 문제점을 해결하기 위해 등장한게 바로 Spring이며 그 시초는 2002년에 로드존슨 이 발매한 <Expert One-on-One J2EE Design and Development> 책에 있는 3만 줄의 예제 코드다.

이 예제 코드가 발전하여 현재의 Spring Framework가 되었으며, 스프링은 다음과 같은 전략으로 EJB의 문제점을 해결했다.

• POJO (Plain Old Java Object) : 특정 기술에 종속되지 않는 순수한 자바 객체를 사용해서 객체지향 특징 살림.
• DI (Dependency Injection) / IoC (Inversion of Control): 객체의 생성과 관계 설정을 개발자가 직접 하는 게 아니라 컨테이너에게 제어권을 넘겨서(IoC), 컨테이너가 의존성을 주입(DI)해 주게 만듦. 이로써 객체 간 결합도를 낮춤.
• AOP (Aspect Oriented Programming): 트랜잭션이나 로깅 같은 부가 기능을 핵심 로직에서 분리하여 코드를 간결하게 함.

같은 문제의식 속에서 개빈 킹은 EJB의 가장 큰 난제였던 엔티티 빈을 대체하기 위해 Hibernate를 만들었다. 하이버네이트는 POJO 기반으로 데이터베이스를 다룰 수 있게 해주는 ORM 기술의 선구자가 되었으며, 이는 훗날 자바 표준인 JPA의 모태가 된다.

결국 스프링은 하이버네이트와 같은 혁신적인 기술들을 유연하게 수용했고, 덕분에 개발자들은 수억 원짜리 무거운 WAS(WebLogic, WebSphere) 대신 톰캣(Tomcat) 같은 가볍고 단순한 WAS(서블릿 컨테이너)만으로도 엔터프라이즈급 시스템의 요구사항을 충족할 수 있게 되었다.

 

마무리

결국 스프링의 탄생 배경은 EJB가 해결하고자 했던 '개발자가 인프라가 아닌 비즈니스 로직에만 집중하게 하겠다'는 이상을 진정으로 실현하기 위함이다.

 

이번 내용을 정리하면서 Spring이 제공하는 기능이 왜 필요한지 간접적으로 느낄 수 있었고, 어떠한 이유로 스프링을 사용하는 표준 형태가 등장하는지 알 것 같다. 앞으로 Spring을 사용할 때 단순히 돌아가는 코드에 만족하지 않고, 객체지향적 특징을 살려고 가독성과 유지보수가 좋은 코드를 만들도록 노력하겠다.