[Spring] 스프링 프레임워크(Spring framework)의 탄생 배경 (feat. CGI, Servlet, JSP, J2EE, EJB) - 3편(최종)

아직 1편, 2편을 안보셨다면 먼저 보고와주세요~!

• [Spring] 스프링 프레임워크(Spring framework)의 탄생 배경 (feat. CGI, Servlet, JSP, J2EE, EJB) - 1편
• [Spring] 스프링 프레임워크(Spring framework)의 탄생 배경 (feat. CGI, Servlet, JSP, J2EE, EJB) - 2편

자 드디어 스프링의 탄생이 코앞까지 왔습니다.

 

1편, 2편을 요약해서 다시 한번 스프링의 탄생으로 이어지는 순서만 되짚어볼까요?

1. HTTP통신으로 정적인 데이터만 전송
2. 서버와 통신하여 동적으로 페이지를 보여줄 수 있는 개념의 인터페이스 CGI(Common Gateway Interface) 등장
3. 자바(Java)버전 CGI라고 불리는 서블릿(Servlet) 등장
4. 서블릿의 html 작성방식의 불편함을 줄인 JSP(Java Server Page) 등장
5. 자바로 기업 환경의 어플리케이션을 만드는데 필요한 스펙들을 모아둔 J2EE (후에 Java EE로 개칭) 등장

사실 J2EE는 출시 당시 "니가 뭘 좋아할지 몰라서 전부 다 넣어봤어^^" 급으로 말그대로 정리가 되지 않은 여러 스펙의 집합체였습니다. 이 J2EE에 포함된 EJB로 인해 자바와 자바 개발자들은 "추운 겨울"이라고 부를만큼 어려운 시기를 겪게 되는데요. 바로 EJB로 이어서 시작해보겠습니다~!

---

EJB (Enterprise Java Bean)

EJB는 J2EE의 구성요소이기 때문에 2편 마지막 부분에서 소개했던 J2EE의 대표 구성요소를 다시 한번 요약해보겠습니다.

• Servlet/JSP
• EJB(Enterprise Java Beans): 대규모 분산 객체 시스템을 구축하기 위한 기술
• RMI(Remote Method Invocation): 메소드를 실행시키기위한 기술입니다.
• JNDI(Java Naming Directory Interface): 객체에 이름을 붙여 찾을 수 있는 단일 인터페이스
• JDBC(Java Database Connector): 여러 종류의 DB에 접근하는 단일한 인터페이스
• JCA(Java Connector Architecture): 여러 플랫폼을 통합할 수 있는 인터페이스
• JMS(Java Message Service): 여러 가지 메시징 시스템에 대한 인터페이스

EJB를 설명하는 분산 객체 시스템이란 무엇이고, 왜 저 많은 스펙중에 EJB 하나로 인해 자바 진영에 추운 겨울이 오게된걸까요? 지금부터 천천히 알아봅시다.

 

분산 객체 시스템

분산 객체 시스템을 이해하기 위해서는 먼저 분산 컴퓨팅과, 분산 객체에 대한 이해가 필요합니다.

• 분산 컴퓨팅: 네트워크에서 서로 다른 시스템 간에 응용 프로그램을 분산해서 처리하는 환경. 즉 하나의 컴퓨터에 존재하는 Application이나 프로세스에서 혼자 수행하기 어려운 작업을 다중 프로세서나 컴퓨터에 분산 시키는 것.
• 분산 객체: 분산 컴퓨팅 기술이 객체 지향과 접목되어 하나의 프로세서나 컴퓨터에서 실행되는 객체가 다른 프로세서나 컴퓨터에서 객체와 통신이 가능 하도록 하는 기술. 분산 객체란 자신이 존재하는 런타임 환경과는 다른 런타임에 있는 객체와 통신이 가능한 객체.

EJB(Enterprise Java Bean)란?

따라서 EJB는 이러한 분산 객체를 대규모로 처리하기 위한 기술입니다. 단순 기술이 아니라 자바 표준으로서 기업 환경의 시스템을 구현하기 위한 서버의 기본 컴포넌트 처리 모델이 되었죠. 표준이 되었기 때문에 자바 객체를 컴포넌트화(객체 재사용 가능하도록 하는)시킬 수 있는 코딩 방침이라고 할 수도 있습니다. (bean은 쉽게 component 또는 객체라고 이해하면 됩니다)

엄청 큰 개념에서 비유해서 말하면, J2EE에서 JSP는 프론트엔드, EJB는 백엔드를 담당하는 기술이었던 샘이죠. (EJB의 역할을 큰 틀에서 쉽게 설명하기 위한 비유지만, 절대 정확한 비유가 아닙니다)

 

EJB 컨테이너

EJB는 비즈니스 객체들을 관리하는 컨테이너 기술, 설정에 의한 트랜잭션 기술 등이 담겨 있었습니다. 여기서 컨테이너 기술은 혁신적이자 동시에" EJB를 정말 사용하기 어렵게 만들어버린 주범"입니다.

 

개발을 하다보면 많은 객체를 만들게 되는데, 컨테이너 기술이란 이러한 비즈니스 객체들을 관리하는 컨테이너를 만들어서 필요할 때마다 컨테이너로 부터 객체를 받는 기술입니다. 왜 필요하게 되었냐면 동시접속자 수가 많을 때 객체를 그때그때 생성한다면 상당히 오래걸리고 부하도 크겠죠 트랜잭션 처리는 말도 못하겠고요 (EJB 자체가 동시접속자수가 10,000명 이상인 사이트 구축시 사용하는 기술로 명시되어있습니다).

 

그래서 EJB 컨테이너는

• 인스턴스 폴링: 객체를 미리 생성하여 메모리에 저장하여 사용준비 상태에 들어가도록함
• 트랜젝션 처리: 자동으로 컨테이너가 모든 처리 메소드에 대한 트랜잭션 처리를 해줌
• 외 다수 기술

을 포함하여 2000년대 초반에는 획기적이라는 평가를 받고, Java 진영에서 표준으로 인정한 기술이기 때문에 많이 사용되었습니다. 하지만...

 

EJB의 한계

이렇듯 취지는 좋았으나, 개발자들은 개발하면서 뭔가 이상함을 느낍니다. EJB의 다양한 기술들을 사용하기 위해서는 반드시 EJB 스펙을 사용해야 했고, EJB 컨테이너를 사용하기 위해 상투적인 코드(상속 and 구현 해야하는 클래스)가 많았습니다. 따라서 서비스의 비즈니스 로직을 구현하는 것보다 EJB 컨테이너를 사용하기 위해 설정하는 시간이 더 오래걸렸고, 어렵게 작성된 코드는 당연히 EJB 컨테이너가 없으면 사용이 불가능했습니다.

 

더 심각한 것은, (2편에서 J2EE는 검증만 되면 모든 벤더가 기여가능하다고 했던 것 기억하시나요?) 벤더 사마다 EJB 컨테이너를 구현한 내용이 다르기 때문에 다른 벤더 사의 컨테이너로 변경에 어려움이 있었고, 개발자가 원하는건 단순히 비즈니즈 로직이 잘 실행되는건데 실행 환경을 구축하는것만 점점 더 복잡해지는 점점 배보다 배꼽이 커지는 현상이 생깁니다.

 

문제점을 요약하면, 프로젝트 자체가 특정 기술(개발 툴 등)에 종속되어 침투(Invasive)되는 문제가 생긴겁니다. 이는 시간이 지날 수록 악화되었죠.. 악순환이 반복되어 자바 개발이 너무나도 힘들어진 "추운 겨울"의 시기가 온것입니다.

---

겨울에 대항하다 (feat. 왕좌의게임 - 존 스노우)

겨울을 맞서는 존 스노우

[Spring] POJO (Plain Old Java Object) 란? 에서 왜 POJO가 EJB를 배제하기위해 직접적으로 겨냥한 단어인지 이제 이해가 가시나요? 위 같은 문제점 때문에 자바가 특정 프레임워크에 종속되는 패턴을 극복하고 순수한 본래 형태로 돌아가야 한다는 일종의 개혁적인 메세지를 담고 있었던 것이죠.

 

그리고 마침내, 자바 진영에 새로운 봄을 알리는 두 가지 사건이 발생하게 되니 그것은 바로 하이버네이트(Hibernate)와 훗날 스프링(Spring)이라는 이름으로 불리게 될 로드 존슨(Rod Johnson)의 3만여줄의 코드입니다.

 

하이버네이트(Hibernate) (영어뜻: 겨울잠을 자다)

게빈 킹(Gavin King, RedHat에서 프로그래밍 모델, 프레임워크, 플랫폼 구축 등을 이끄는 개발자)은 당시 EJB에서 제공하는 Entity Bean에 많은 문제점이 있다는 생각을 하고 있었습니다.

Entity Bean
쉽게 말해 DB에 가져온 데이터들을 담는 그릇입니다. Entity Bean 하나의 객체는 DB 테이블의 하나의 row와 mapping 됩니다. Persistence(지속성)성질을 통해 Entity Bean 의 내용을 수정하면, 자동으로 DB에 있는 값이 저절로 바뀝니다. EJB컨테이너가 DB를 연결하는 코드를 자동으로 만들어줍니다.

그는 이에 하이버네이트(Hibernate)라는 새로운 기술을 만들게 되었고 EJB의 Entity Bean을 대체할 수 있던 기술이 되었죠. 당시 EJB의 Entity Bean의 문제점에 시름하고 있던 개발자들이 많았던 터라 하이버네이트는 배포 이후 꾸준히 점유율을 높일 수 있었고 결국 자바 표준 논의 기관은 게빈 킹을 스카웃하여 JPA라는 기능을 만들어 자바 표준으로 삼게 됩니다. JPA는 하이버네이트를 계승한 기술입니다.

 

로드 존슨(Rod Johnson)의 코드

2002년 로드 존슨은 책 출간합니다. EJB의 고질적인 문제점을 지적했고, 지적에서 그치지 않았습니다. 그는 EJB 없이도 충분히 고품질의 확장 가능한 애플리케이션을 개발할 수 있음을 보여주고, 30,000라인 이상의 기반 기술을 예제 코드로 선보였죠. 여기에는 지금의 스프링 핵심 개념과 기반 코드가 들어가 있었습니다. BeanFactory, ApplicationContext, POJO, (IoC)제어의 역전, (DI)의존관계 주입 등 많은 것을 고려한 코드였죠. 책 출간 직후 '유겐 휠러', '얀 카로프'가 로드 존슨에게 오픈소스 프로젝트를 제안했고, J2EE (EJB) 라는 겨울을 넘어 새로운 시작이라는 뜻으로 이름을 지은 스프링(Spring)을 만들게 됩니다!!

---

새로운 시대가 열리다 : 스프링(Spring) 의 탄생

드디어...!! 들리시나요 봄이오는 소리가?

이렇게 탄생한 스프링(Spring)은 한문장으로 정의하기가 매우 어렵습니다. 당초에 스프링을 개발한 개발자들이 스프링이라는 단어는 모호한 단어다, 라고 표현했을 만큼 스프링은 정말로 거대하고 복잡하기 때문이죠. 따라서 스프링은 특정한 '하나'가 아니라 '여러 기술'들의 모음이라고 하는게 더 정확한 표현입니다.

 

결론적으로 스프링은 일반적으로 3가지의 표현 중 하나로 사용되는데 그는 아래와 같습니다.

• 스프링 DI 컨테이너 기술
• 스프링 프레임워크
• 스프링 생태계

실제로 스프링 공식 홈페이지에 방문해보면 스프링 안에 정말 많은 프로젝트가 포함되어 있다는 것을 발견할 수 있습니다. 따라서 스프링은 단순히 스프링 프레임워크(Spring Framework)를 표현할 때도 있고, 스프링 부트(Spring Boot), 스프링 데이터(Spring Data), 스프링 세션(Spring Session), 스프링 시큐리티(Spring Security) 등 스프링을 구성하는 수많은 생태계를 의미하기도 합니다.

 

드디어 "추운겨울"이 지나고 봄(Spring)이 온것이죠. 그래서 스프링(Spring)의 철학은 확고합니다.

특정 기술에 종속되지 않고(기술 비침투적) 객체를 관리할 수 있는 컨테이너를 제공하는 것이 스프링의 기본 철학이다

---

먼 길을 돌아서 드디어 스프링의 탄생까지 오게 되었습니다.

 

이렇게 보면 정말 처음부터 완벽한 설계라는건 없는것 같네요. 오히려 처음부터 완벽하지 않았고 시행착오를 거치고 여러번 문제점과 수정을 거치면서 점점 완벽함에 가까워지는 과정을 보니 스프링이 더 멋있게 느껴집니다. 겨울을 버티고 따뜻한 봄이 온 느낌이네요

 

혹시 잘못된 부분이나, 빠진 부분 혹은 더 추가해야할 부분이 보인다면 댓글로 알려주세요. 감사합니다 :)

 

출처:
- EJB(Enterprise JavaBeans)란 무엇인가.
- EJB와 스프링 개론
- 엔터프라이즈 자바빈즈 (EJB, Enterprise Java Beans)
- Entity Bean
- 스프링 핵심 원리 1일차(스프링의 역사, 좋은 객체 지향 프로그래밍, 다형성, 역할과 구현)