스프링 이란?
웹(Web)을 공부하다 보면 가장 많이 나오는 키워드 중 하나는 스프링 프레임워크 일것이다. 많은 IT 업체가 채용 시 스프링 개발 경험을 요구하고 국비지원교육 커리큘럼에 포함되기도 한다. 그리고 공공기관 프로젝트에 권장되는 전자정부 프레임워크도 스프링을 기반으로 만들어졌다.
왜 스프링 프레임워크인가?
프로그램을 만드는 방식은 다양하다. 언어도 다양하고 기술들도 다양하다. 꼭 스프링이 아니라도 웹 애플리케이션을 만들 수 있다. 그렇다면 왜 수많은 IT 업체들이 스프링 프레임워크를 사용할까? 우선 스프링의 탄생 배경부터 알아보자.
자바 엔터프라이즈 개발을 편하게
웹 애플리케이션을 만들 때 개발자는 고객의 요구사항을 분석하고 요구사항에 맞는 코드를 작성하게 된다. 이를 비즈니스 로직이라고 부르는데 프로젝트에서 가장 중요한 사항 중 하나다. 한마디로 고객이 원하는 방식으로 프로그램이 동작해야 한다.
하지만 프로그램은 비즈니스 로직만으로는 동작하지 않는다. 그 외에도 프로그램 동작을 위한 수많은 로직들이 추가되어야 한다. (트렌잭션, 상태관리, 멀티스레딩, 리소스 풀링과 같은)
이때 등장한 것이 EJB(Enterprise Java Beans)라는 자바 표준 기술이다. EJB를 사용하면 앞서 말한 로우레벨(트렌잭션, 상태관리, 멀티스레딩 등) 기술에 신경쓰지 않고 핵심인 비즈니스 로직을 빠르고 효과적으로 구현할 수 있었다.
자바 진영의 추운 겨울
편리한 애플리케이션 개발이란 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션의 핵심인 사용자의 요구사항, 즉 비즈니스 로직을 빠르고 효과적으로 구현하는 것을 말한다. EJB의 비전과 목표는 바로 이것이었다.
EJB는 약속대로 일정 부분에서는 엔터프라이즈 개발의 고민거리와 부담을 덜어줬다. 문제는 이 과정에서 다른 차원의 더 큰 복잡함을 애플리케이션 개발에 끌고 들어오는 실수를 저질렀다는 점이다.
- EJB의 문제점
- 객체지향적이지 않음
- 복잡한 프로그래밍 모델
- 특정 환경, 기술에 종속적인 코드
- 자동화 된 테스트가 매우 어렵거나 불가능
- 부족한 개발 생산성, 이동성
구현할 비즈니스 로직보다 EJB 컨테이너를 사용하기 위한 상투적인 코드들이 많다는 불편함은 물론이고 테스트가 어렵다는 문제점등이 있었다. 한마디로 매우 무겁고 복잡하다.
이로 인해, 마틴 파울러는 EJB에 반발해 오래된 방식의 간단한 자바 오브젝트로 돌아가자는 말을 했고, 이는 POJO(Plain Old Java Object)라는 용어의 기원이 되었다.
겨울을 넘어 봄으로
2002년 로드존슨은 Expert One-on-One J2EE Design and Development라는 책을 출간한다. 이 책은 J2EE 애플리케이션 설계와 개발의 모든 영역에 대한 개발 전략을 다룬 책으로 개발 전략과 기존 기술에 대한 대안을 설명으로만 그치지 않고, 그 개념을 증명할 수 있도록 만들어진 3만 라인가량의 샘플 애플리케이션 형태로 제공됐다.
이 책에서 강조한 중요한 전략 중 하나는 “항상 프레임워크 기반으로 접근하라”는 것이었다. 책의 예제는 프레임워크를 먼저 만들고 나서, 프레임워크를 이용하는 코드를 만드는 방식으로 작성됐다. 이 예제에 포함된 프레임워크가 스프링 프레임워크의 기원이다.
오픈소스 프로젝트의 시작
책 출간 직후 예제로 제공된 프레임워크에 매료된 개발자 Juergen Hoeller(유겐 휠러), Yann Caroff(얀 카로프)가 로드 존슨에게 오픈소스 프로젝트를 제안하였고 정식으로 스프링 프레임워크라는 이름의 오픈소스 프로젝트가 시작돼서 오늘날에 이른 것이다.
현재까지 스프링의 핵심 코드의 상당수는 유겐 휠러가 개발하고 있다.
스프링 이름은 전통적인 J2EE(EJB)라는 겨울을 넘어 새로운 시작이라는(봄) 뜻으로 지어졌다.
릴리즈
- 2003년 스프링 프레임워크 1.0 출시 - XML
- 2006년 스프링 프레임워크 2.0 출시 - XML 편의 기능 지원
- 2009년 스프링 프레임워크 3.0출시 - 자바 코드로 설정
- 2013년 스프링 프레임워크 4.0 출시 - 자바8
- 2014년 스프링 부트 1.0 출시
- 2017년 스프링 프레임워크 5.0, 스프링 부트 2.0 출시 - 리엑티브 프로그래밍 지원
- 2022년 1월 현재 스프링 프레임워크 5.3.14, 스프링 부트 2.6.2
스프링 생태계
 | 스프링 프레임 워크 |
- 핵심기술: 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술: 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술: 트랜잭션, JDBC, ORM지원, XML 지원
- 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
- 테스트: 스프링 기반 테스트 지원
- 언어: 코틀린, 그루비
- 최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용
 | 스프링 부트 |
- 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
- 손쉬운 빌드 구성을 위한 starter 종속성 제공
- 스프링 3rd parth(외부) 라이브러리 자동 구성
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
- 관례에 의한 간결한 설정
그외
 | 스프링 데이터 |  | 스프링 세션 |
 | 스프링 시큐리티 |  | 스프링 배치 |
 | 스프링 클라우드 |  | 스프링 RestDocs |
엔터프라이즈 개발의 복잡함
2000년대 초반 각종 자바 컨퍼런스에서 자주 논의됐던 주제는 “왜 자바 엔터프라이즈 JavaEE 프로젝트는 실패하는가?”였다. 당시 IT 리서치기업의 조사에 따르면 80% 이상의 자바 엔터프라이즈 프로젝트가 실패했다고 한다. 그 과정에서 밝혀진 여러 가지 원인이 있었지만, 그중 가장 대표적인 게 “엔터프라이즈 시스템 개발이 너무 복잡해져서”였다.
복잡함을 해결하려는 도전, 실패한 해결책 EJB
EJB는 일부 기술적인 복잡함을 떨어주려는 시도를 하다가 오히려 더 큰 복잡함을 추가하는 실수를 범했다. 가장 치명적인 건, EJB라는 틀 안에서 자바 코드를 만들게 강제함으로써 자바 언어가 원래 갖고 있던 장점마저 잃어버렸다는 사실이다.
효과적인 해결책 스프링
스프링은 EJB 의 실패를 교훈으로 삼아서 출발했다. 스프링 핵심 개발자들은 “스프링의 정수는 엔터프라이즈 서비스 기능을 POJO에 제공히는 것”이라고 했다.
스프링은 단지 객체지향 언어의 장점을 제대로 살리지 못하게 방해했던 요소를 제거하도록 도와줄 뿐이다.
스프링의 핵심 개념, 컨셉
- 스프링은 자바 언어 기반의 프레임워크
- 자바 언어의 가장 큰 특징 - 객체 지향 언어
- 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
- 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
Comments powered by Disqus.