20180122 스프링(Spring Framework) 특징 2 : 스프링 핵심

- 스프링의 핵심 도구 : OOP & DI

OOP는 객체 지향 프로그래밍의 영어 표현 Oriented-Object Programming 의 약어이고 DI는 Dependency Injection의 약어이다. OOP, 즉 객체지향에 관련한 내용은 여기를 참고하면 좋을 것 같다.

스프링의 목적과 전략을 살펴보면 사실 스프링은 비즈니스의 로직과 기술적인 복잡도를 해결하기 위해서 객체 지향을 이용하고 있다. 하지만 EJB의 등장으로 객체 지향 본연의 특성을 살리지 못한채 특정 기술의 스펙에 종속된 설계 방식을 강요했다는 점이 있었다.

스프링의 기본 모토는 "기본으로 돌아가자" 라고 한다. 자바의 기본인 객체지향에 충실한 설계가 가능하도록 오브젝트로 개발할 수 있으며, 객체 지향의 설계 기법을 잘 적용할 수 있는 구조를 만들기위해 DI 같은 유용한 기술을 이용하는 것이 스프링의 전략이다.

이 글은 참고링크에서 매우 중요하게 생각하고 있는 부분이었다.

객체 지향과 DI는 서로 뗴놓을 수 없습니다. 만약 스프링을 사용하고 DI를 적용했다고 생각할 수 있다. 하지만 기계적인 방법으로 항상 사용하는 틀에 박힌 구조의 빈만 정의하고 나머지 코드에는 DI를 적용해 볼 생각조차 하지 않는다면 DI를 잘못 사용하고 있는 것이다.

기술적인 복잡함을 해결하는 문제나 기술적인 복잡함이 비즈니스 로직에 침범하지 못하도록 분리하는 경우에는 DI가 바탕이 된 여러가지 기법이 활용된다. 반면에 비즈니스 로직 자체의 복잡함을 해결하려면 DI보다는 객체 지향 설계 기법이 더 중요하다.

여기서 왜?? 스프링은 비즈니스 로직 자체와 기술적인 코드와 특정 기술의 스펙이 침범하지 않도록 코드를 만들어주는데 노력을 했을까?? 

좋은 코드는 좀 더 단순하고 명확해지는 이유뿐만 아니라, 순수 비즈니스 로직만을 담고 있는 코드에는 객체 지향 분석과 설계에서 나온 도메인 모델을 쉽게 적용할 수 있기 때문이다.

객체 지향의 장점을 잘 살린 설계 & 기술은 복잡하고 급변하는 업무를 지원하는 시스템을 만들 때에도 손쉽게 대응이 가능한 것이다. 결과적으로 스프링이 가진 기술과 전략들은 자바가 가진 고유의 특성을 훼손하지 않으며 극대화하도록 돕는 것이라고 본다. 

하지만, 스프링만 잘한다고 해서, 자바 언어 자체나 객체 지향 설계와 개발 실력 따윈 별로 신경 쓰지 않아도 복잡한 엔터프라이즈 시스템을 잘할 수 있을거라 생각하면 오산이다.

- POJO Programming

스프링 핵심 개발자들이 함께 쓴 Professional Spring Framework라는 책이 있다. 이 책에서 스프링의 핵심 개발자들은 아래와 같이 얘기하고 있다.

" 스프링의 정수(精髓)는 엔터프라이즈 서비스 기능을 POJO에 제공하는 것 "

엔터프라이즈 서비스는 보안, 트랜잭션과 같은 엔터프라이즈 시스템에서 요구되는 기술들을 의미한다. 이런 기술을 POJO에 제공한다는 말은 엔터프라이즈 서비스 기술과 POJO라는 애플리케이션 로직을 담은 코드를 분리하겠다는 뜻이기도 하다. 

그리고 분리가 되었지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다는 것이 스프링의 가장 강력한 특징과 목표이다.

- 스프링의 핵심 : POJO

아래의 그림은 스프링 소스의 CTO인 아드리안 콜리어가 스프링의 핵심 개념을 설명하기 위해서 만들었다고 한다.

스프링으로 개발한 애플리케이션의 기본 구조를 보여주고 있다. 스프링 애플리케이션은 POJO를 이용해서 만든 (1) 애플리케이션 코드와 함께 POJO가 어떠한 관계를 맺고 동작하는지를 정의해놓은 (2) 설계정보로 구분된다.

DI의 기본 아이디어는 유연하게 확장 가능한 오브젝트를 만들어두고 그 관계는 외부에서 다이내믹하게 설정해준다는 것이고, 이러한 DI의 개념을 애플리케이션 전반에 걸쳐 적용하는 것이 스프링 프로그래밍 모델이다.

스프링의 주요기술인,

- loC/DI

- AOP

- PSA (Portable Server Abstractions)
는 애플리케이션을 POJO로 개발할 수 있게 해주는 기능기술이라고 불리운다.

그럼 POJO란 정확히 무엇인지에 대해 의문이 생긴다. 과연 POJO란 무엇인가?

- POJO (POJO : Plain Old Java Object)
POJO는 한글로 "포조" 라고 읽는다. 이 포조를 알기 이전에, 이 용어의 탄생배경은 재미있다. 한글로2000년대 초반 마틴파울러는 EJB처럼 복잡하고 제한이 많은 기술을 사용하는 것보단, 자바의 단순한 오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하는 편이 낫다고 생각했다고 한다.

하지만 많은 개발자들은 이런 단순 오브젝트를 개발에 사용하길 꺼려했는데, 이유를 알고보니 매우 단순한 이유였다고 한다. EJB와 같은 그럴싸한 이름이 없었기 때문. 그래서 명명한게 "POJO"가 된 것이다. 

그렇다면 POJO 프로그래밍이란 것은 무엇을 의미할까? 단순 EJB를 사용하지 않으면 POJO 프로그래밍이 되는 것인가. 앞서서 말한 자바의 단순 오브젝트라고 하지만 다음의 두가지 조건을 충족해주어야 POJO라고 불리울 수 있는 자격이 생긴다.

(1) 특정 규약에 종속되지 않는다.

POJO는 자바언어와 필요 API이외에는 종속되지 않아야 한다. 따라서 특정 규약을 따라 비즈니스 컴포넌트를 만들어야 하는 경우는 POJO가 아니다. 특정 규약을 따라만들게 되면, 대부분 규약에서 제시하는 특정 클래스를 상속하도록 요구하기 떄문에 단일 상속 제한에 걸려 객체 지향적 설계가 되지 못한다. 그리고 특정 규약을 따라 만들어서 해당 환경에 종속적이라 이식성이 현저히 떨어진다.

결과적으로 객체 지향 설계의 자유로운 적용이 가능한 오브젝트여야만 POJO라고 불리울 수 있는 것이다.

(2) 특정 환경에 종속되지 않는다.

만약 특정 환경에 종속되어야만 동작하는 오브젝트도 POJO라고 할 수 없다. 예를 들면 WebLogic서버에서만 사용 가능한 API를 직접 쓴 코드를 가지고 있거나 특정 OS에서 제공하는 기능을 직접 호출하도록 만들어진 오브젝트 등이 존재한다. 이런 식의 순수한 애플리케이션 로직을 담고 있는 오브젝트 코드가 특정 환경에 종속되게 만드는 경우라면 그것 역시 POJO라고 할 수 없다.

비즈니스 로직을 담은 코드에 HttpServletRequest 혹은 HttpSession, 캐시와 관련된 API가 등장하거나 웹 프레임워크의 클래스를 직접 이용하는 부분이 있다면 그것은 진정한 POJO라고 볼 수 없다.

소스코드에 직접 메타정보를 추가하는 Annotation을 많이 이용한다. 만약 Annotation을 사용했을 경우 POJO인가? 이전 XML에 담긴 설정 정보를 코드로 가져왔으니 POJO가 아니라고 할 수 있지만 꼭 그런건 아니라고 한다.

Annotation이 단지 코드로 표현하기에 적절하지 않은 정보를 담고 있으며, 그로인해 환경에 종속되지 않는다면 POJO라고 할 수 있다. 하지만 Annotation이나 엘리먼트 값에 특정 기술과 환경에 종속적인 정보를 담고 있다면 그때는 POJO로서의 가치를 잃어버린다고 할 수 있다. 

여기서, 특정 규약과 특정 환경에 종속되지 않는다면 POJO라고 말할 수 있는지에 대한 여부이다. 순수하게 JavaSE API와 순수 자바 문법을 사용했다고 해서 그게 POJO가 될 수 없다. POJO는 객체 지향적인 자바의 특징을 가지고 만들어져야 한다. 왜냐하면 자바는 객체 지향 언어이지만 어떻게 쓰느냐에 따라서 객체 지향의 특성을 살릴수도 혹은 잃어버릴 수도 있기 있기 때문이다.

진정한 POJO란, 객체지향적인 원리에 충실히 따르면서, 규약과 환경에 종속되지 않고 필요에 따라 재사용이 가능한 방식으로 설계된 오브젝트를 말한다. 그런 POJO에 애플리케이션의 핵심 로직과 기능을 담아 설계하고 개발하는 방법을 POJO 프로그래밍이라고 할 수 있다. 

[ 참고링크 ]

[ 스프링이란 무엇인가? ]