이번에 스프링 프레임워크를 처음 배우게 되었다.(18년 1월 16일 기준) 스프링을 접하고 일주일이 지난 지금 아직까지 잘 모르겠다. 자바 기반의 범용 프레임워크라고 알고 있으며, 스프링 프레임워크가 웹 애플리케이션 개발에 좋은 퍼포먼스를 내기 때문에 많이 이용되고 있다는 것만.
스프링 프레임워크가 어떠한 불편함 때문에 탄생했는지, 어떤 쓰임을 가질려고 나타났는지 본질적으로 알아야 한다고 생각한다. 누군가에게 스프링을 설명할 때, 스프링이 무엇인지 그리고 왜 스프링을 쓰는 것이고, 스프링을 씀으로 해서 얻는 이점은 무엇인지 등과 관련한 이야기들을 나름의 명확한 내용을 가지고 정리해서 나의 표현으로 말할 수 있어야 한다.
글은 길다. 나도 타인의 글을 참고하면서 작성하기 때문에 다만 내가 모르기 때문에 궁금하기 때문에 어쩔 수 없는 부분인 것 같다.
우선 스프링에 대해서 가장 잘 알려진 정의는 다음과 같다고 한다.
자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크
프레임워크가 무엇이냐고 물어본다면, 여기와 여기글을 읽어보길 바란다. 내용은 라이브러리와 프레임워크의 차이를 설명하고 있지만 충분히 이해할 수 있다.
- 애플리케이션 프레임워크 (Applicaton Framework)
애플리케이션 프레임워크는 어느 특정한 업부 문야에 국한되지 않고 앞서 말했듯이 범용적으로 전 영역에 걸쳐서 쓰일 수 있음을 말한다. 그리고 자바 엔터프라이즈, Java EE(Enterprise Edition)은 Java SE(Standard Edition)에 웹서버 역할을 추가한 자바 애플리케이션을 동작시킬 수 있는 컨테이너 등을 표준화한 스펙이다.
스프링 프레임워크의 가장 우선적인 존재목적은 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심 기술을 바탕으로 하여 각 필요한 분야의 특성에 맞게 충족시켜주고 있다. 그러면서도 애플리케이션을 빠르고 효과적으로 개발을 할 수 있는 것에서 찾을 수 있다.
결과적으로 일관된 프로그래밍 모델의 적용과 핵심기술이, 엔터프라이즈 애플리케이션 전 계층과 전 영역에 제공됨으로써, 애플리케이션을 편리하게 개발해주는 애플리케이션 프레임워크로 사용되는 것이다.
- 경량급 (Light Weight)
경량급이라는 표현이 스프링 자체가 아주 가볍거나 혹은 규모가 작음을 이야기하는 것이 아니다. 그럼에도 불구하고 경량급이라고 표현하는 이유는 불필요하게 무겁지 않음을 이야기 한다. 기존 JavaEE 기술의 불필요한 복잡한과 반대되는 개념이다.
여기서 스프링이 처음 등장하던 시절의 자바 주류 기술인 EJB(Enterprise JavBeans)와 같은 과도한 엔지니어링이 적용된 기술과 스프링을 대비시키며 설명하기 위한 표현이다. 당시의 프로젝트 수행을 위한 EJB 이용은
1. 비즈니스 로직 개발
2. 개발환경에서의 테스트 및 디버깅
3. 운영환경에서의 서비스
위와 세가지 과정을 거치게 되는데, 무겁고 복잡하게 만들어졌다. 그리고 EJB가 동작하기 위해선 WAS가 필요했으며 다루기 힘든 설정 파일과 까다로운 패키징 등의 부담과 개발환경 구성이 제대로 갖추어져 있지 않으면 개발하기가 힘들었다고 한다.
그에 반해서 스프링은 개발툴과 기본적인 개발환경으로도 JavaEE 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에 더 나으며, 조금 더 쉽고 좀 더 빠르게 비즈니스 로직을 만들어 낼 수 있다. 또한 단순한 환경에서 EJB와 JaveEE 을 통한 개발의 고급 기술을 사용할 수 있다는 점이다.
따라서 만들어진 코드와 지원하는 수준이 EJB와 비슷하더라도 더 빠르고 간편하게 작성하며 생산성과 품질면에서 유리하다는 것이 경량급이라는 표현을 사용할 수 있는 스프링의 특징인 것이다.
- 스프링의 목적
개발을 함에 있어서 어느 패키지나 혹은 라이브러리나 그리고 프레임워크를 사용한다고 하면 이전 불편사항이 있었기 때문에 나타났을 것이다. 그리고 그 부분을 해소시켜주고자 하는 목적성을 띄기 때문에 스프링의 목적을 아는 것은 중요하다고 생각한다.
2000년대 초반 각종 자바 컨퍼런스에서 자주 논의되던 주제는 왜 JavaEE 프로젝트는 실패하는가 였다. 당시 IT 리서치 기업의 조사에 따르면 80% 이상의 JavaEE 프로젝트가 실패해다고 한다. 그 당시 대표적인 이유는 "엔터프라이즈 시스템 개발의 복잡도" 였다.
왜 복잡한 것일까?
(1) 기술적인 제약조건과 요구사항이 늘어간다.
(2) 엔터프라이즈 시스템은 서버에서 동작하며, 기업과 조직의 업무를 처리해주는 시스템이다.
(3) 많은 유저의 요청을 처리해야하기 때문에, 보안과 안전성 그리고 확장성면에서 뛰어나야 한다. 따라서 비즈니스 로직을 구현하는 것 이외에도 신경써야 할 부분들이 많다.
(4) 그래서 뛰어난 성능과 서비스의 안정성이 요구되며 그러한 개발 기술이 필요하다.
(5) JavaEE 시스템이 기업업무를 처리하는데 핵심적인 역할로 등장하고 점점 기술적인 요구는 심화되어 그에 따른 시스템의 복잡도도 증가한다.
(6) 더불어서 핵심기능의 비즈니스 로직의 복잡도도 증가한다.
이러한 복잡함이 존재하였기 때문에 이를 해결하려고 EJB를 이용하였지만 실패하였다. EJB가 처음 내세웠던 목표는 비즈니스 로직과 기술적인 복잡함을 분리하고자 하는 것이었지만 EJB라는 환경과 스펙에 종속되는 코드로 만들어야하기 때문에 부담이었다.
더욱이 EJB라는 틀 안에서 자바코드를 만들게 강제함으로써, 자바 언어가 가지고 있는 고유의 특성 그리고 장점을 잃어버렸다는 사실이다. EJB는 특정 클래스를 상속하게 함으로써, 더 이상 상속구조를 적용하지 못하게 만들거나 다형성 적용을 근본적으로 제한한다거나 하는 것들이다. 결국 이러한 개발은 자바 고유의 객체지향의 특성을 잃어버리고 있었다.
반면에 스프링은 EJB처럼 어느 기술을 적요하고 그 기술과 관련된 코드나 규약 등이 코드에 등장하는 침투적인 기술이 아닌 비침투적인 기술을 이용했다.(non-invasive) 비침투적인 기술은 기술의 적용 사실이 다른 코드에 반영되지 않음을 이야기한다.
스프링을 사용함으로 인해 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리할 수 있게 되었고, 그 과정에서 스프링은 기술코드가 직접 노출되지 않도록 만들어 주었다. 결국 스프링을 통해 성격이 다른 복잡성에 대해 각각을 효과적으로 상대할 수 있는 기반을 마련하게 되었다.
- 복잡함을 상대하는 스프링의 전략
스프링의 기본적인 전략은
(1) 비즈니스 로직을 담은 애플리케이션 코드
(2) 엔터프라이즈 기술을 처리하는 코드
위의 두가지 내용을 분리시키는 것인데, 이 분리를 통하여 복잡함의 문제를 효과적으로 공략할 수 있게 되었다.
우선 기술적 복잡함을 상대하기 위한 전략으로, 스프링은 서비스 추상화 방법을 이용하였다. 추상화를 통해 로우레벨의 기술 구현 부분을 사용하는 인터페이스를 분리하고, 환경 세부 기술에 독립적인 접근 인터페이스를 제공하였다. 스프링이 제공하는 템플릿/콜백 패턴은 판에 박힌 반복적인 작업 흐름과 API 사용 코드를 제거해준다. 이를 통하여 기술을 사용하는 코드도 최적화된 핵심 로직에만 집중할 수 있도록 도와주는 것이다.
그리고 기술적인 처리를 담당하는 코드가 전혀 다른 성격의 코드와 섞이는 문제가 발생는데, 스프링은 AOP(Aspect Oriented Programming)기법을 통해서 문제를 해결하고 있다. AOP란 공통적인 기능이 발생하는 경우, 공통 기능과 핵심 기능을 분리시켜 놓고 공통 기능을 필요로 하는 핵심 기능들에서 사용하는 방식이다.
AOP는 기술을 다루는 코드로 인한 복잡함을 기술 그 자체 이상으로 불필요하게 증대되지 않도록 도와주는 수단인 것이다. AOP의 전형적인 예로 로깅을 들 수 있는데 로깅 전략은 필연적으로 시스템 상에서 로그되는 모든 부분에 영향을 미치기 때문이다. 그러므로 로깅은 로그가 되는 모든 클래스와 메소드들은 Aspect 한다. AOP는 코드 밖에서 설정된다는 것이 핵심이다.
결국 스프링을 비즈니스 로직의 복잡함을 해결하는 것이고, 그 방식은 객체 지향 기술 그 자체라고 말할 수 있다. 스프링은 특별한 기술이라고 말할 수 있지만 사실 스프링을 통해서 객체 지향 언어 본연의 장점을 살리고 있는 셈이다.
'Spring' 카테고리의 다른 글
| 20180205 <context:component-scan base-package="" /> (수정 : 2018 12 06) (0) | 2018.02.05 |
|---|---|
| 20180202 JSP : Between Different [ include & import ] (0) | 2018.02.02 |
| 20180125 스프링(Spring Framework) 특징 3 : POJO (0) | 2018.01.25 |
| 20180122 스프링(Spring Framework) 특징 2 : 스프링 핵심 (0) | 2018.01.22 |
| 20180122 SpringFramework 입문 (0) | 2018.01.21 |
