토비의스프링3.1 [8장] 스프링이란 무엇인가?

8장 스프링이란 무엇인가?

스프링은 기본적으로 IoC와 DI를 위한 컨테이너로서 작동하지만 그렇다고 
“스프링은 단지 IoC/DI 프레임워크다” 라고는 말할 수 없다.
그렇다면 과연 스프링이란 무엇이고 어떻게 설명할 수 있을까?

8.1 스프링의 정의

스프링에 대해 가장 잘 알려진 정의는 이렇다.

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

이 정의에는 스프링의 중요한 특징이 잘 담겨 있다.

 

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

일반적으로 라이브러리나 프레임워크는 특정 업무 분야나 한 가지 기술에 특화된 목표를 가지고 만들어진다. 하지만 스프링은 이와 다르게 ‘애플리케이션 프레임워크’라는 특징을 가지고있다.

애플리케이션 프레임 워크는 특정 계층이나, 기술, 업무에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다. 

이는 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는데 일차적인 목표를 두는 프레임워크다.

 

재밌게도 스프링의 기원은 J2EE기술서적에 딸린 예제 코드다. 스프링을 처음 만든 사람은 로드 존슨이라는 유명한 자바 개발자다. 그가 출간한 서적은  J2EE 애플리케이션 설계와 개발의 모든 영역에 대한 개발 전략을 다룬 책이다. 바로 이 책에 딸린 예제코드가 스프링의 기원이 되었다.

 

스프링을 MVC 프레임워크나 또는 JDBC/ORM 지원 프레임워크라고 생각하는 것은 스프링ㄴ이 다루는 일부 영역만 봤기 때문이다. 또, 스프링을 IoC/DI 프레임워크나 AOP툴이라고 보는 이유는 스프링이 제공하는 핵심 기술에만 주목했기 때문이다.

 

스프링의 일차적인 존재목적은 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능을 제공해줌으로써 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임워크로 사용되는 것임을 기억해두자.

 

 

• 경량급

스프링이 경량급이라는 건 스프링자체가 아주 가볍거나 작은 규모의 코드로 이뤄졌다는 뜻은 아니다. 오히려 20여개의 모듈로 세분화되고 수십만 라인에 달하는 코드를 가진 매우 복잡하고 방대한 규모의 프레임워크다.

 

그럼에도 스프링이 가볍다고 하는 이유는 무엇일까? 그것은 불필요하게 무겁지 않다는 의미다.

스프링은 가장 단순한 서버환경인 톰캣이나 제티에서도 완벽하게 작동한다. 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에는 충분하다. 서블릿 컨테이너만으로 충분하니 EJB 컨테이너를 비롯해 복잡한 기능이 잔뜩 포함된 고급WAS를 굳이 사용하지 않아도 된다. 스프링의 장점은 그런 가볍고 단순한 환경에서도 복잡한 EJB와 고가의 WAS를 갖춰야만 가능했던 엔터프라이즈 개발의 고급 기술을 대부분 사용할 수 있다는 점이다.

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

스프링뿐 아니라 기존에 등장했던 대부분의 자바 엔터프라이즈 기술과 프레임워크는 저마다 ‘개발을 편하게 해준다’고 주장하고 있다. 하지만 스프링이 말하는 말의 무게와는 다르다.

 스프링은 근본적인 부분에서 엔터프라이즈 개발의 복잡함을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시한다.

 

 

• 오픈소스

스프링은 오픈소스 프로젝트 방식으로 개발돼왔다. 지금도 여전히 오픈소스 개발 모델과 오픈소스 라이센스를 가지고 개발되는 중이며, 이 사실은 앞으로도 바뀌지 않을 것이다.

 

스프링이 적용된 오픈소스 라이센스는 비교적 제약이 적고 사용이 매우 자유로운 편인 아파치 버전 2.0 이다. 아파치 라이센스에 따르면 스프링을 상업적인 목적의 제품에 포함시키거나 비공개 프로젝트에 자유롭게 이용해도 된다. 다만 스프링을 사용한다는 점과 원 저작자를 밝히고 제품을 패키징할 때 라이센스 정보를 포함시키는 등의 기본적인 의무사항을 따르면 된다. 소스코드를 가져와 수정해도 수정한 코드를 공개해야하는 의무는 없다.

 

하지만 오픈소스개발 모델에도 단점이 있다. 지속적이고 안정적인 개발이 계속될지 불확실하다는 것이다. 상당수의 오픈소스는 핵심 개발자의 여가시간을 이용해 일종의 취미활동으로 만들어진다. 그래서 더이상 개발을 진행할 수 없다면, 단순한 버그 픽스도 몇 년씩 걸리게 되며 프로젝트 자체가 사장되는 최악의 상황까지도 갈 수 있다. 스프링 같은 프레임워크는 기업의 가장 중요한 핵심 업무를 관장하는 엔터프라이즈 시스템의 개발에 사용된다. 그렇기 때문에 해당 단점은 치명적일 수 있다. 그런 이유 때문에 사용자에게 지속적인 신뢰를 줄 수 있게 전문 기업을 만들었다. 정규 업무시간에 풀타임으로 오픈소스 개발에 전념할 수 있게하여, 안정적이고 전문화된 개발과 품질관리가 가능해 졌다.

8.2 스프링의 목적

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

2000년대 초반 각종 자바 컨퍼런스에서 자주 논의됐던 주제는 ‘왜 자바 엔터프라이즈(JavaEE) 프로젝트는 실패했는가?’ 였다. 정해진 기간과 계획된 예산을 맞추지 못한 경우가 그만큼 많다는 뜻이다. 자바 엔터프라이즈 개발이 실패하는 이유에 대해 많은 논의가 있었고, 그 과정에서 밝혀진 여러 가지 원인이 있었지만, 그중 가장 대표적인게 ‘엔터프라이즈 시스템 개발이 너무 복잡해져서’ 였다.

 

복잡함의 근본적인 이유

• 기술적인 제약조건과 요구사항이 늘어가기 때문이다.

• 엔터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문이다.

더 큰 문제는 기업의 체질이 크게 바뀌었다는 것이다. 한번 업무 프로세스와 정책이 결정되면 제법 오랫동안 유지하던 전통적인 기업조차도 경제 흐름과 사회의 변화, 업계의 추이에 따라서 수시로 업무 프로세스를 변경하고 조종하는 것을 상시화할 만큼 변화의 속도가 빨라졌다.

 

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

기술적 복잡함을 상대하는 전략

• 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다.

• 기술적인 복잡함은 일단 추상화를 통해 로우레벨의 기술 구현부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부기술에 독립적인 접근 인터페이스를 제공하는 것이 가장 좋은 해결책이다.

• 스프링이 제공하는 템플릿/콜백 패턴은 판에 박힌 반복적인 작업 흐름과 API 사용코드를 제거해준다.

• 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.

• AOP는 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술이다.

 

핵심 도구: 객체지향과 DI

지금까지 살펴봤듯이 기술적인 복잡함을 효과적으로 다루게 해주는 기법은 모두 DI를 바탕으로 하고 있다. 그리고 DI는 객체지향 설계 기술이 없이는 그 존재의미가 없다. 1장에서 살펴봤듯이 DI란 특별한 기술이라기보단 유연하게 확장할 수 있는 오브젝트 설계를 하다 보면 자연스럽게 적용하게 되는 객체지향 프로그래밍 기법일 뿐이다. 스프링은 단지 그것을 더욱 편하고 쉽게 사용하도록 도와줄 뿐이다.

 

8.3 POJO 프로그래밍

스프링 핵심 개발자들은 “스프링의 정수는 엔터프라이즈 서비스 기능을 POJO에 제공하는 것”이라고 했다. 엔터프라이즈 서비스라고 하는 것은 보안, 트랜잭션과 같은 엔터프라이즈 시스템에서 요구되는 기술을 말한다. 이런 기술을 POJO에 제공한다는 말은, 뒤집어 생각해보면 엔터프라이즈 서비스 기술과POJO라는 애플리케이션 로직을 담은 코드를 분리했다는 뜻이기도 하다.

 

8.3.1 스프링의 핵심:POJO

스프링의 주요 기술인 IoC/DI, AOP와 PSA(Portable Service Abstraction)는 애플리케이션을 POJO로 개발할 수 있게 해주는 가능기술(enabling technology)이라고 불린다.

 

8.3.2 POJO란 무엇인가?

POJO는 plain Old Java Object 의 약자다.

해당 용어를 만들어낸 재미난 이유가있다. 마틴 파울러는 당시 인기를 끌고있던 EJB처럼 복잡하고 제한이 많은 기술을 사용하는 것보다는 자바의 단순한 오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하는 편이 낫다고 생각했다.

이에 그럴싸한 이름을 붙인것 뿐이다. 평범한 자바오브젝트에 멋진 이름을 붙여줬던 시도는 기대이상으로 성공적이었다.

 

8.3.3 POJO의 조건

• 특정 규약에 종속되지 않는다.

• 특정 규약을 따라 만들게 하는 경우는 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구한다. 그럴 경우 자바의 단일 상속 제한 때문에 더 이상 해당 클래스에 객체지향적인 설계 기법을 적용하기가 어려워지는 문제가 생긴다.

• 별다른 가치를 주지도 못하는 규약 따위에 종속되지 않아야 하고, 객체지향 설계의 자유로운 적용이 가능한 오브젝트여야만 POJO라고 불릴 수 있다.

• 특정 환경에 종속되지 않는다.

 

그럼 특정 기술규약과 환경에 종속되지 않으면 모두 POJO라고 말할 수 있는가? 많은 개발자가 크게 오해하는것 중 하나가 바로 이것이다. 단지 자바 문법을 지키고, 순수하게 JavaSE API만을 사용했다고 해서 그 코드를 POJO라고 할 수는 없다. POJO는 객체지향적인 자바 언어의 기본에 충실하게 만들어져야 하기 때문이다.

 

진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

8.3.4 POJO의 장점

POJO로 개발된 코드는 자동화된 테스트에 매우 유리하다. 환경의 제약은 코드의 자동화된 테스트를 어렵게 한다.  POJO 코드는 매우 유연한 방식으로 원하는 레벨에서 코드를 빠르고 명확하게 테스트 할 수 있다.

객체지향적인 설계를 자유롭게 적용할 수 있다는 것도 큰 장점이다.

 

8.4 스프링의 기술

스프링은 POJO 프로그래밍을 손쉽게 할 수 있도록 지원하는 세 가지 가능기술을 제공한다.

그 세가지 기술은 바로 IoC/DI, AOP, PSA다.

스프링의 기술들은 스프링 프레임워크가 만들어진 진정한 목표인 POJO 기반의 엔터프라이즈 개발을 편리하게 해주는 도구일 뿐이다. 

8.4.2 애스펙트 지향 프로그래밍(AOP)

AOP도 스프링의 3대 가능기술의 하나다. 스프링은 객체지향 기술과 프로그래밍을 위해 존재하는 프레임워크라고 설명했는데, 난데없이 애스펙트 지향 프로그래밍이라는 새로운 프로그래밍 패러다임이 왜 필요할까? AOP와OOP는 서로 배타적이 아니기 때문이다.

AOP 적용기법

• 스프링과 같이 다이내믹 프록시를 사용하는 방법

• 기존 코드에 영향을 주지 않고 부가기능을 적용하게 해주는 데코레이터 패턴을 응용한 것이다.

• 스프링의 기본적인 AOP구현 방법은 다이내믹 프록시를 이용하는 프록시AOP 방식이다.

• 자바 언어의 한계를 넘어서는 언어의 확장을 이용하는 방법

• AspectJ 는 프록시 방식의 AOP에서는 불가능한 다양한 조인포인트를 제공한다.

• 인스턴스 생성, 필드 액세스, 특정 호출경로를 가진 메소드 호출등에도 부가기능 제공.

• 별도의 AOP컴파일러를 이용한 빌드과정 혹은 클래스가 메모리 로딩 때 바이트코드를 조작하는 위빙과같은 방법을 이용

8.4.3 포터블 서비스 추상화(PSA)

PSA는 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근 할 수 있게 해준다.

POJO로 개발된 코드는 특정 환경이나 구현 방식에 종속적이지 않아야 한다. 

서비스 추상화를 위해 필요한 기술은 DI뿐이다. 결국 DI응용 방법의 한 가지이므로 DI를 적극 활용해서 개발한다면 서비스 추상화는 자연스럽게 만들어 쓸 수 있다.