Spring 의 정의와 목적

* 본 포스팅 내용은 [토비의 스프링3]를 정리한다.


Spring 이란 무엇인가?


자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크
창시자 : Rod Johnson
기원 : Expert One-on-One J2EE Design and Development (2003) 의 sample code

- 애플리케이션 프레임워크

일반적으로 라이브러리나 프레임워크는 특정 업무 분야나 한가지 기술에 특화된 목표(예를들면, 웹 계층을 MVC구조로 변경한다거나, 간단한 설정만으로 RDB와 java object를 매칭해주는 ORM기술 제공등)를 가지고 만들어 지지만, 애플리케이션 프레임 워크란 특정 계층이나, 기술, 업무분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 볌용적인 프레임워크이다. 애플리케이션 프레임워크는 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는데 일차적인 목표를 두는 프레임워크이다.

- 경량급(lightweiight)

스프링 자체가 아주 가볍다거나 작은 규모의 코드로 이뤄졌다는 뜻이 아니다. 스프링은 20여개의 모듈로 세분화 되고 수십만 라인에 달하는 코드를 가진 방대한 규모의 프레임워크이다. 경량급의 의미는 EJB같은 과도한 엔지니어링이 적용된 기술에 대비하여 불필요하게 무겁지 않다는 의미이다.

EJB : 고가의 WAS필요, 난해한 설정파일, 까다로운 패키징, 불편한 deploy 등으로 인한 부담으로 인해 고가의 제품으로 구성된 제대로된 개발환경이 없이 개발이 어려움. 스프링은 tomcat 이나 jetty 에서도 완벽하게 동작한다. 즉, 서블릿 컨테이너만으로 충분하니, EJB컨테이너나 기타 기능을 사용하지 않아도 된다.

(1) 개발환경의 lightweight
(2) 서버 환경의 lightweight
(3) 코드의 상대적인 lightweight

- 자바 엔터프라이즈 개발을 편하게

로우레벨의 트랜잭션이나 상태관리, 멀티스레딩, 리소스 풀링 같은 복잡한 로우레벨 API 를 이해하지 못하더라도 아무런 문제 없이 어플리케이션을 개발할 수 있다.(From Enterprise JavaBeans 1.0 Specification, Chapter 2 Goals)

로우레벨 기술에 신경쓰지 않으면서, 애플리케이션의 핵심인 사용자의 요구사항, 비즈니스 로직을 빠르고 효과적으로 구현하는 것. 즉, 초기에 스프링의 기본 설정과 적용기술만을 잘 이해하고 있으면, 애플리케이션 개발중에는 스프링 관련 Code 에 신경쓸 필요가 없다.

- 오픈소스

스프링은 오픈소스 프로젝트 방식으로 개발되왔다. 지금도 여전히 오픈 소스 개발 모델과 라이선스를 가지고 개발하는 중이다.

라이센스 : Apache Licence Ver 2.0 (스프링을 상업제품에 포함시키거나 비공개프로젝트에서 사용해도 된다. (수정자유롭고 수정된 소스 공개 필요없음)

Spring 의 Goal

- 엔터프라이즈 개발의 복잡함

2000년대 초반 80% 이상의 자바 enterprise project 가 실패했다. 가장 대표적인 이유는 엔터프라이즈 시스템 개발이 너무 복잡해서 이다.

왜 복잡한가? 비즈니스 로직 이외에도 기술적으로 고려해야 할 사항들이 많다.(타시스템 과의 연계, 다양한 형태의 클라이언트 접속을 위한 리모팅 기술, 분산 트랜잭선의 지원, 보안 등) 또한 비즈니스 로직 자체도 점점 복잡해지고 잦은 변경이 요구된다)게다가 이런 엔터프라이즈 기술의 복잡함과 비즈니스 로직의 복잡함이 한데 얽혀서 복잡함이 배가된다.

- 복잡함을 해결하려는 도전

근본적으로 엔터프라이즈 기술의 복잡함과 비즈니스 로직의 복잡함은 줄일수 없다. 그러나 이 두가지 성질이 다른 복잡함을 분리해 낼수 있다. EJB도 이 목표를 지향하여 선언전 트랜잭션이나 선언적 보안, 컨테이너를 통한 리모팅 기술의 적용, 컴포넌트 단위의 배치, JNDI 를 통한 서비스 검색지원, 서비스 오브젝트의 풀링, 컴포넌트의 생명주기 관리등을 수행하여 이 목표를 달성하려 하였으나, 이를 위해 EJB라는 환경과 스펙에 종속되는 코드로 만들어야 하는 더 큰 복잡함을 안게되어 실패하였다. 게다가 EJB라는 틀 안에서 특정클래스를 상속하게 함으로 자바 언어의 원래 장점마저 상실하고 객체지향적인 특성을 잃어버진 서비스 스크립트성 코드로 변질돼 갔다.

스프링은 EJB와는 다르게 비침투적(non-invasive)기술을 적용하였고, 이는 코드상에 스프링과 관련된 규약과 코드가 등장하지 않는 것을 의미한다. 즉, 스프링이 코드에 불필요하게 등장해서 복잡함을 가중시키지 않는다.

- 복잡함을 상대하는 스프링의 전략

** 기술적 복잡함은 아래와 같이 서비스의 추상화와 AOP 로 상대한다.

1. 서비스의 추상화

트랜잭션 추상화, OXM 추상화, 데이터 액세스에 관한 일관된 예외변환 기능, 데이타 액세스 기술에 독립적인 트랜잭션 동기화 기능 등. 기술적인 복잡함은 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 사용기술에 독립적인 접근 인터페이스를 제공한다.

2. AOP (Aspect Oriented Programming)

비즈니스 로직 전후로 경계가 설정되어야 하는 트랜잭션, 보안적용, 예외처리, 로깅, 감사 등 기술과 비즈니스 로직의 혼재는 최대한 제거해도 완전히 해결할 수 없으며, 이를 해결하기 위한 스프링의 전략이 AOP 이다. AOP는 최후까지 애플리케이션 로직에 남아있는 기술관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력할 기술이다.

** 비즈니스 로직의 복잡함을 상대하는 전략은 객체지향과 DI이다.

1. OOAD (Object Oriented Analysis & Design)

복잡함을 단순화 할 수 있는 것은 객체지향 기술 자체이며, 스프링은 환경 종속적이지 않고 비침투적인 기술이므로 핵심로직을 다루는 코드에는 스프링이 드러나지 않는다. 따라서 객체지향언어의 장점을 살려 로직의 복잡함을 효과적으로 다루어야 한다.

2. DI (Dependency Injection)

DI는 특별한 기술이라기 보다는 유연하게 확장가능한 오브젝트 설계를 하다보면 자연스럽게 적용하게 되는 객체지향 프로그래밍 기법이다. 스프링은 단지 그것을 더욱 편하고 쉽게 사용하도록 도와줄 뿐이다. DI는 적용하려다 보면 자연스럽게 확장성이 좋은 설계로 이끌어진다. 즉, 바뀔 수 있는 것은 무엇인가? 무엇이 성격이 다른가? 를 지속적으로 고민하게 되고 대상이 되는 Object는 DI를 적용해 분리하고, 인터페이스를 도입하고, DI로 관계를 연결해 주게 되므로 DI를 열심히 적용하다 보면 객체지향 설계의 원칙을 잘 따르고 그 장점을 살린 설계가 나올수도 있다.