[ Spring 심화 ] 9주차 - 스프링이란 무엇인가?

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

8.1 스프링의 정의

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

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

애플리케이션 프레임워크

라이브러리/프레임워크는 특정 업무 분야나 한 가지 기술에 특화된 목표를 가지고 만들어 진다.

하지만 스프링은 특정 계층, 기술, 업무 분야에 국한되지 않고 애플리케이션 전 영역을 포괄하는 범용적ㅇ니 프레임워크다.

역사
스프링은 2003년에 출간된 로드 존슨의 Expert One-on-One J2EE Design and Development라는 책에서 탄생했다.
이 책은 J2EE 애플리케이션 설계와 개발에 대한 책이었고 개발 전략과 기존 기술에 대한 대안을 샘플 애플리케이션 형태로 제공했다.
이 책에서 강조한 전략이 "항상 프레임워크 기반으로 접근하라"는 것인데, 책의 예제가 바로 이런 방식으로 프레임워크를 만들고 -> 그 프레임워크를 사용하는 방식으로 작성되었다. 이 예제의 프레임워크가 스프링의 기원이다.

스프링은 단지 여러 계층의 다양한 기술을 그저 한데 모았다는 데 의미가 있는게 아니다.
스프링의 일차적인 목적은 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능을 제공함으로써 애플리케이션 개발을 편하게 하는데 있다.

경량급

스프링이 가볍거나 작은 규모의 코드라는걸까? 아니다. '경량'의 의미는 불필요하게 무겁지 않다는 뜻이다.
스프링이 처음 등장했던 시절의 자바 주류 기술인 EJB의 과도한 엔지니어링에 대비되도록 사용한 표현이다.
스프링은 EJB에 비해 가장 단순한 서버 환경인 Tomcat이나 Jetty에서도 동작하고, EJB처럼 난해한 설정파일 구조를 다루지 않고, 까다로운 패키징이나 불편한 서버 배치등의 부담 없이, 서블릿 컨테이너만으로도 동작한다.

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

스프링이 말하는 '편하게'는 단순히 편리한 도구나 기능을 제공하는 것이 아니다. 엔터프라이즈 개발의 근본적 문제점에 도전하여 해결책을 제시한다.
재밌는 점은 EJB도 이러한 슬로건을 내걸었다는 것.

목표는 결국 편리한 애플리케이션 개발이란 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션 개발의 비즈니스 로직을 빠르고 효과적으로 구현하는 것을 말한다.

오픈소스

스프링은 오픈소스 프로젝트 방식으로 개발돼왔다. 스프링에 적용된 오픈소스 라이선스는 오픈소스 라이선스 중에서도 비교적 제약이 적고 사용이 매우 자유로운 편인 아파치 라이선스 버전 2.0이다.

오픈소스기에 공개된 커뮤니티에서 투명한 방식으로 다양한 참여를 통해 개발되기 때문에 매우 빠르고 유연한 개발이 가능하고, 다양한 환경의 버그가 커뮤니티를 통해 빠르게 전달되고 해결될 수 있다는 장점이 있다.

하지만 개발의 지속성과 안정성이 불확실하다는 단점이 있다. 기존 오픈소스 개발 방식의 단점을 극복할 수 있는 대안은 기업이나 기관의 지원을 받는 전문 개발자가 오픈소스 개발을 책임지게 하는 것이다.스프링을 개발하고 있는 스프링소스는 스프링의 창시자인 로드 존슨을 비롯해 스프링이 오픈소스화되는 데 가장 큰 역할을 한 유겐 횔러Juergen Hoeller와 자바 엔터프라이즈 세계에서 손꼽히는 최상급 개발자들이 주축이 돼서 만든 회사다.

스프링 개발업체인 스프링소스는 2009년에 세계적인 IT 기업인 VMWare에 전략적으로 합병됐다. 그 덕분에 이전보다 더욱 안정된 환경과 조직의 지원을 통해 오픈소스 스프링의 개발에 더욱 전념할 수 있었다.

8.2 스프링의 목적

정의대로 스프링은 '경량급 프레임워크인 스프링을 활용해서 엔터프라이즈 애플리케이션 개발을 편하게' 하는 것이 목적이다. 그런데 왜 굳이 스프링을 사용해서 엔터프라이즈 애플리케이션 개발을 편하게 하고싶어 할까?

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

1. 기술적 제약조건과 요구사항이 늘어남

엔터프라이즈 시스템이란 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템을 말한다. 엔터프라이즈 시스템은 많은 사용자의 요청을 동시에 처리해야 하기 때문에 서버의 자원을 효율적으로 공유하고 분배해서 사용할 수 있어야 한다. 또한 중요한 기업의 핵심 정보를 처리하거나 미션 크리티컬한 금융, 원자력, 항공, 국방 등의 시스템을 다루기도 하기 때문에 보안과 안정성, 확장성 면에서도 뛰어나야 한다.

즉 엔터프라이즈 시스템을 개발하는 데는 순수한 비즈니스 로직을 구현하는 것 외에도 기술적으로 고려할 사항이 많다는 뜻이다.

• 웹을 통한 사용자 인터페이스뿐만 아니라, 타 시스템과의 자동화된 연계와 웹 이외의 클라이언트와의 접속을 위한 리모팅 기술도 요구된다.
• 기업의 시스템이 복잡함에 따라 다중 데이터베이스를 하나의 트랜잭션으로 묶어서 사용하는 분산 트랜잭션의 지원도 필요하다.
  문제는 이러한 엔터프라이즈 시스템의 기술적인 요구사항은 단순히 고가의 애플리케이션 서버WAS나 툴을 사용한다고 충족될 수 있는 게 아니라는 점이다.

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

이전에는 회계처럼 복잡한 계산이나 빠른 분석 작업이 필욯나 영역에서나 IT 시스템을 활용했다.
하지만 갈수록 대부분의 업무 처리를 컴퓨터로 하게 되었고 그만큼 다양하고 복잡한 업무 처리 기능을 엔터프라이즈 시스템에서 구현해야 했다.

또한 2000년 전후의 글로벌 경제위기 이후, 기업이 경제 흐름, 사회의 변화, 업계의 추이를 따라 수시로 업무 프로세스를 변경하는 체질로 변했다.
그만큼 시스템 개발-유지보수-추가 개발의 부담은 커지고, 그에 따라 난이도도 상승한 것이다.

복잡함을 가중시키는 원인

예시
추천상품 선정 로직을 구현하기 위해서는 다음과 같은 기술적 요소들이 필요하다:

• XML 파싱을 위한 파서 라이브러리
• 캐시 API와 JDBC API를 이용한 DB 조회
• 분산 파일 시스템 기반 로깅
• 보안 API를 통한 권한 체크
• JTA를 이용한 트랜잭션 처리

이처럼 하나의 비즈니스 로직을 구현하는데도 많은 기술적 요소들이 복잡하게 얽혀있다.

복잡함을 해결하려는 도전

엔터프라이즈 개발의 복잡함은 제거할 수 없지만, 효과적으로 다룰 수 있는 전략이 필요하다. 비즈니스 로직의 복잡함과 기술적인 복잡함은 서로 다른 방식으로 다뤄야 하므로, 이 둘을 분리하는 것이 중요하다.

실패한 해결책: EJB
EJB는 기술적 복잡함을 일부 분리하는데 성공했으나, EJB 환경에 종속적인 개발을 강제함으로써 더 큰 복잡함을 만들었다. 특히 자바의 객체지향적 특성을 제한하는 등 근본적인 문제를 야기했다.

효과적인 해결책: 스프링
스프링은 비침투적(non-invasive) 방식을 채택했다. 이는 기술 적용이 코드에 직접적으로 드러나지 않고, 코드의 설계와 구현을 제한하지 않는 특징을 가진다. 스프링은 이를 통해 기술적 복잡함과 비즈니스 로직을 깔끔하게 분리하면서도, 불필요한 복잡함을 추가하지 않는데 성공했다.

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

스프링의 기본적인 전략은 비즈니스 로직을 담은 애플리케이션 코드와 엔터프라이즈 기술을 처리하는 코드를 분리시키는 것이다. 이 분리를 통해 두 가지 복잡함의 문제를 효과적으로 공략하게 해준다.
1. 기술에 대한 접근 방식의 일관성 부재와 환경 종속성 문제
서버나 환경이 바뀔 때마다 코드를 변경해야 하는 문제가 있다. 이는 서로 다른 API와 기술들이 혼재하기 때문이다.

스프링은 이를 서비스 추상화로 해결한다:

• 트랜잭션, OXM, 데이터 액세스 등의 추상화 제공
• 로우레벨 기술 구현과 인터페이스를 분리
• 템플릿/콜백 패턴으로 반복 작업 제거
• 환경과 기술에 독립적인 인터페이스 제공

2. 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.
트랜잭션, 보안, 로깅, 감사 등의 기술적 처리가 비즈니스 로직과 혼재되어 있다. 계층을 구분하고 의존성을 제거해도 엔터프라이즈 서비스를 사용하는 한 이 문제는 피할 수 없다.

스프링은 이를 AOP로 해결한다. AOP는 애플리케이션 로직에서 기술 관련 코드를 깔끔하게 분리하여 별도 모듈로 관리하게 해준다. 이를 통해 기술과 비즈니스 로직의 혼재 문제를 해결하고, 기술적 코드의 중복도 제거할 수 있다. AOP는 기술 관련 코드로 인한 불필요한 복잡도 증가를 방지하는 강력한 도구이다.

비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략

기술적인 코드와 침투적인 기술을 제거하면 순수한 애플리케이션의 주요 기능과 비즈니스 로직만 남게 된다. 비즈니스 로직은 애플리케이션에서 가장 중요한 핵심이며, 업무 변화에 따라 자주 변경되는 부분이다.

비즈니스 로직의 오류는 시스템에 치명적인 영향을 미칠 수 있다. 예를 들어 증권사의 거래 시스템에서 기술적 문제는 서버 증설 등으로 해결할 수 있지만, 거래 체결이나 계좌 잔액 계산의 오류는 회사의 존폐와 직결될 수 있다.

과거에는 비즈니스 로직을 DB에 두는 것이 일반적이었으나, 시스템이 복잡해지면서 이는 확장성과 유지보수성 측면에서 문제가 되었다. 현재는 비즈니스 로직을 애플리케이션 서버에서 처리하는 것이 추세이다. 이는 다음과 같은 장점이 있다:

• 확장이 용이하고 비용이 저렴
• 테스트가 쉬움 (목 오브젝트 활용 가능)
• 객체지향 설계 원칙 적용이 용이

결국 비즈니스 로직의 복잡함을 상대하는 전략은 자바라는 객체지향 기술 그 자체다. 스프링은 단지 객체지향 언어의 장점을 제대로 살리지 못하게 방해했던 요소를 제거하도록 도와줄 뿐이다.

핵심 도구: 객체지향과 DI

스프링은 객체지향(OO)을 통해 기술과 비즈니스 로직의 복잡함을 해결한다. 스프링 개발자들은 자바의 가장 큰 장점이 객체지향 설계와 프로그래밍이라고 보았으나, EJB가 이를 제한했다고 생각했다.

스프링의 핵심 전략은 '기본으로 돌아가자'이다. 단순한 객체 개발과 객체지향 설계 기법을 적용할 수 있도록 DI 같은 기술을 지원한다.
서비스 추상화, 템플릿/콜백, AOP 등 스프링의 기술은 모두 DI를 기반으로 한다. DI는 객체지향 설계의 자연스러운 산물이며, 동시에 좋은 객체지향 설계로 이끄는 도구이다.
비즈니스 로직의 복잡함은 주로 객체지향 설계 기법으로 해결한다. 스프링은 기술적 코드와 특정 기술 스펙이 비즈니스 로직을 침범하지 않도록 도와준다.

결론적으로 스프링의 모든 기술과 전략은 자바의 객체지향이라는 강력한 도구를 최대한 활용할 수 있도록 돕는 것이다. 하지만 실제로 좋은 애플리케이션을 만드는 것은 개발자의 객체지향 활용 능력에 달려있다.

8.3 POJO 프로그래밍

스프링이 지향하는 목적을 좀 더 기술적으로 정의해보자.

스프링의 핵심 개발자들이 함께 쓴 Professional Spring Framework라는 책에서 스프링의 정수essence는 엔터프라이즈 서비스 기능을 POJO에 제공하는 것이라고 했다.
엔터프라이즈 서비스는 보안, 트랜잭션 등 기업용 시스템에 필요한 기술이다. 스프링은 이러한 기술을 POJO 기반의 핵심 로직과 분리하되, POJO에 필요한 엔터프라이즈 서비스를 제공하는 것을 목표로 한다.

스프링의 핵심: POJO

스프링 애플리케이션은 POJO를 이용해서 만든 애플리케이션 코드와, POJO가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계정보로 구분된다. DI의 기본 아이디어는 유연하게 확장 가능한 오브젝트를 만들어두고 그 관계는 외부에서 다이내믹하게 설정해준다는 것이다. 이런 DI의 개념을 애플리케이션 전반에 걸쳐 적용하는 것이 스프링의 프로그래밍 모델이다. 스프링의 주요 기술인 IoC/DI, AOP와 PSAPortable Service Abstraction는 애플리케이션을 POJO로 개발할 수 있게 해주는 가능기술enabling technology이라고 불린다.

Plain Old Java Object, 간단히 POJO는 말 그대로 해석을 하면 오래된 방식의 간단한 자바 오브젝트라는 말로서 Java EE 등의 중량 프레임워크들을 사용하게 되면서 해당 프레임워크에 종속된 "무거운" 객체를 만들게 된 것에 반발해서 사용되게 된 용어이다. 2000년 9월에 마틴 파울러, 레베카 파슨, 조쉬 맥킨지 등이 사용하기 시작한 용어로서 마틴 파울러는 다음과 같이 그 기원을 밝히고 있다. [1]

POJO의 조건

그렇다면 POJO 프로그래밍은 무엇인가?

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

POJO는 자바 언어와 필수 API 외에는 종속되지 않아야 한다. 특정 규약을 따르거나 특정 클래스를 상속해야 하는 경우는 POJO가 아니다. 예를 들어:

• EJB2처럼 특정 규약을 따라야 하는 경우
• 스트럿츠1처럼 특정 클래스 상속이 필요한 경우

이러한 종속성은 다음과 같은 문제를 야기한다:

• 자바의 단일 상속 제한으로 인한 객체지향 설계의 제약
• 특정 환경에 종속되어 이전이 어려움
• 추가적인 DTO 생성 등 불필요한 작업 발생

따라서 POJO는 특정 규약에 종속되지 않고 객체지향 설계를 자유롭게 적용할 수 있어야 한다.

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

특정 환경에 종속적인 오브젝트는 POJO가 아니다. 예를 들어:

• EJB 3는 JNDI라는 서버 서비스에 의존
• 특정 벤더의 서버나 프레임워크에서만 동작하는 코드
• WebLogic 서버 전용 API나 특정 OS 기능을 직접 호출하는 코드
• 비즈니스 로직에 웹 기술(HttpServletRequest, HttpSession 등)이 포함된 경우

애노테이션의 경우 부가 정보만 담고 있고 환경에 종속되지 않으면 POJO로 인정된다. 하지만 특정 기술/환경에 종속적인 정보를 담으면 POJO가 아니다.

또한 단순히 Java SE API만 사용했다고 POJO인 것은 아니다. 객체지향 원리를 따르지 않는 코드(책임과 역할이 뒤섞인 큰 클래스, 강한 결합도, if/switch 남용 등)는 POJO라 할 수 없다.

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

POJO의 장점

그렇다면 POJO 프로그래밍의 장점은 무엇인가? 바로 POJO의 조건 그자체가 장점이 된다.

1. 깔끔한 코드 작성 가능

• 특정 기술/환경에 종속되지 않아 비즈니스 로직이 깔끔하게 분리됨
• 코드 이해와 디버깅, 유지보수가 용이

2. 테스트 용이성

• 환경 제약 없이 자유로운 테스트 가능
• 빠르고 명확한 테스트 작성 가능

3. 자유로운 객체지향 설계

• 도메인 모델과 디자인 패턴을 자유롭게 적용 가능
• 복잡한 엔터프라이즈 시스템에서 객체지향 설계의 장점 활용 가능

과거 EJB와 같은 무거운 프레임워크가 선호되었던 것은 엔터프라이즈 시스템 개발이라는 복잡한 과제에 대한 잘못된 접근 방식 때문이었다.

POJO 프레임워크

스프링은 POJO 기반의 엔터프라이즈 애플리케이션 개발을 위한 대표적인 POJO 프레임워크이다. 하이버네이트가 주로 DB 관련 기술에 초점을 맞춘 것과 달리, 스프링은 엔터프라이즈 애플리케이션의 모든 영역에서 POJO 방식 개발을 지원한다.

1. 비즈니스 로직과 기술적 복잡함의 분리

• 핵심 비즈니스 로직은 POJO로 구현
• 기술적인 부분은 프레임워크가 담당

2. 최소한의 침투적 프로그래밍

• 프레임워크 자신을 직접 노출하지 않음
• 데이터 액세스나 웹 UI 로직에만 최소한으로 관여

3. 객체지향 설계 지원

• 개발자가 객체지향적 설계에 집중할 수 있도록 지원
• 프레임워크 사용 시 자연스럽게 좋은 객체지향 설계 유도

스프링을 사용한다고 해서 객체지향 분석과 설계에 대한부담이 줄어드는 아니지만, 그래도 복잡한 엔터프라이즈 기술보단 이러한 객체지향적 설계와 개발의 원리에 좀 더 집중할 기회를 만들어 준다. 동시에 스프링이 제공하는 기술, 프레임워크 API 및 확장 포인트를 사용하다 보면 자연스럽게 객체지향적 원리를 따라가도록 이끌어준다. 이게 바로 스프링의 전세계적 인기의 비결이다. 누구나 자연스럽게 좋은 코드를 만들게 해준다!

8.4 스프링의 기술

스프링은 POJO 프로그래밍을 지원하기 위해 세 가지 핵심 기술(IoC/DI, AOP, PSA)을 제공한다. 이 기술들은 스프링 이전에도 존재했던 것들이지만, 스프링은 이를 통합적이고 세련된 방식으로 제공한다.
하지만 스프링을 단순히 이러한 기술을 제공하는 프레임워크로만 이해하면 안 된다. 이 기술들은 POJO 기반의 엔터프라이즈 개발이라는 스프링의 궁극적 목표를 달성하기 위한 도구일 뿐이다. 또한 이 기술들은 스프링이 중요시하는 객체지향 원리를 적용한 결과물이기도 하다.
스프링 사용자는 스프링이 제공하는 기술을 단순히 사용하는 것을 넘어, 필요한 경우 직접 PSA를 구현할 수 있어야 한다. 이것이 스프링의 철학에 부합하는 올바른 사용법이다.

제어의 역전(IoC) / 의존관계 주입(DI)

IoC/DI는 스프링의 가장 핵심적인 기술이자 개발 원칙이다. AOP와 PSA도 IoC/DI를 기반으로 하며, 템플릿/콜백 패턴도 IoC/DI 원리를 따른다.

IoC/DI의 핵심은 오브젝트 간의 느슨한 결합을 통한 유연한 확장성이다. 이는 객체지향 설계의 개방 폐쇄 원칙(OCP)과 일맥상통한다.

• 개방: 의존 대상을 자유롭게 확장/변경 가능
• 폐쇄: 기존 코드의 변경 없이 재사용 가능

예를 들어 A-B 관계에서 B를 B1, B2, B3로 자유롭게 변경할 수 있으면서도(개방), A는 수정할 필요가 없다(폐쇄).

DI의 활용 방법

1. 핵심기능의 변경

• 의존 대상의 구현을 바꾸는 가장 대표적인 DI 적용 방법
• 전략 패턴이 대표적인 예시로, A의 기능 일부를 B에게 위임할 때 B의 구현을 B1, B2, B3로 바꾸는 것
• 예를 들어 DAO 구현을 JDBC에서 JPA, 하이버네이트 등으로 변경하거나 사용자 등급 결정 정책을 변경하는 것

2. 핵심기능의 동적인 변경

• 의존 오브젝트의 핵심기능을 애플리케이션 동작 중에 다이내믹하게 변경 가능
• 예를 들어 사용자 등급에 따라 다른 DataSource를 사용하게 하거나
• 사용자별로 독립적인 의존 오브젝트를 유지하게 하는 것이 가능

3. 부가기능의 추가

• 핵심기능은 그대로 두고 부가기능을 추가하는 데코레이터 패턴 적용
• 트랜잭션, 로깅, 보안 처리 등의 부가 기능을 추가 가능
• 더 일반화하여 여러 대상에 적용하면 AOP가 됨

4. 인터페이스 변경

• 호환되지 않는 인터페이스를 가진 오브젝트 사용을 위한 어댑터 패턴 적용
• 클라이언트가 사용하는 인터페이스와 실제 구현 오브젝트 사이의 불일치 해결
• PSA처럼 일관된 인터페이스로 다양한 구현 기술을 추상화하는데 활용

5. 프록시

• 지연 로딩을 위한 프록시 패턴 적용이 가능
• 원격 오브젝트를 로컬처럼 사용하게 해주는 원격 프록시 구현
• 스프링의 다양한 리모팅 기술(EJB, 웹서비스, REST 등) 지원에 활용

6. 템플릿과 콜백

• 반복되는 작업 흐름과 자주 바뀌는 부분을 분리하여 재사용성 향상
• 콜백을 템플릿에 주입하는 방식으로 DI 원리에 충실한 구현
• OCP 원칙을 잘 따르는 설계 패턴으로 스프링에서 많이 활용됨

7. 싱글톤과 오브젝트 스코프

• DI 컨테이너가 오브젝트의 생명주기를 제어하여 효율적인 리소스 관리
• 기본적으로 싱글톤 스코프를 제공하며 HTTP 요청/세션별 스코프도 지원
• 개발자가 직접 커스텀 스코프를 정의하여 사용 가능

8. 테스트

• 의존 오브젝트를 목 오브젝트로 대체하여 효과적인 단위 테스트 가능
• 복잡한 테스트 환경 구축 없이도 핵심 로직 검증 가능
• DI를 통해 테스트용 설정을 별도로 관리하고 목 오브젝트 주입이 용이

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

AOP 설명

• 스프링의 3대 핵심기술 중 하나
• 객체지향 프로그래밍(OOP)의 한계와 단점을 보완하는 보조적인 프로그래밍 기술
• OOP를 더욱 OOP답게 만들어주는 역할
• 90년대부터 연구되었으며 스프링이 엔터프라이즈 개발에 성공적으로 보급
• POJO 프로그래밍을 지원하기 위한 중요한 역할 수행
• IoC/DI만으로는 해결하기 어려운 엔터프라이즈 서비스를 POJO에 선언적으로 제공

AOP 적용 기법

1. 다이내믹 프록시를 사용하는 방법

• 스프링의 기본적인 AOP 구현 방식
• 데코레이터 패턴을 응용하여 기존 코드에 영향을 주지 않고 부가기능 적용
• 메소드 호출 지점에만 적용 가능하다는 제약이 있음
• 엔터프라이즈 개발에 필요한 대부분의 AOP 구현 가능

2. AspectJ를 이용한 방법

• 자바 언어의 한계를 넘어서는 언어 확장 방식
• 메소드 호출뿐 아니라 인스턴스 생성, 필드 액세스 등 다양한 조인 포인트 제공
• AOP 컴파일러나 바이트코드 조작 등 별도 처리 필요
• 사용이 복잡하지만 프록시 방식으로 불가능한 작업 수행 가능

AOP 적용 단계

1. 미리 준비된 AOP 이용

• 스프링이 제공하는 트랜잭션, @Configurable 등의 AOP 기능 활용
• 간단한 설정만으로 적용 가능
• AOP 입문 단계에서 적합

2. 전담팀을 통한 정책 AOP 적용

• 보안, 로깅, 트레이싱, 성능 모니터링 등 정책적 기능에 활용
• 소수의 AOP 담당자가 관리
• 개발 정책이나 표준 검증에 활용 가능
• 기존 코드 수정 없이 기능 추가/제거 가능

3. AOP의 자유로운 이용

• 개발자가 직접 AOP를 활용하는 단계
• 특정 모듈이나 기능 내에서 유용한 AOP 구현
• 다른 팀의 코드에 영향을 주지 않도록 주의 필요

포터블 서비스 추상화

PSA(Portable Service Abstraction)

• 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 기술
• POJO 코드가 특정 환경이나 기술에 종속되지 않도록 보장
• 스프링은 다양한 엔터프라이즈 기술에 대한 서비스 추상화 제공

주요 특징

• AOP나 템플릿/콜백 패턴과 결합하여 사용 가능
• 설정을 통해 사용할 기술 지정 가능
• 트랜잭션, OXM, JavaMail 등 다양한 기술에 대한 추상화 제공

활용

• 스프링이 제공하는 추상화 활용
• 필요시 직접 서비스 추상화 구현 가능
• DI를 통한 구현이 핵심
• 테스트 용이성 향상과 외부 설정 제어를 위해서도 활용

8.5 정리

• 스프링의 개발 철학
• 스프링의 목표
• 스프링은 POJO를 이용함으로써 자바의 객체지향적 장점을 포기하지 않으면서 앤터프라이즈 시스템 개발의 복잡함을 해결할 수 있게 지원해준다.
• POJO 방식 개발을 돕기 위해 스프링은 IoC/DI, AOP, PSA 같은 기능기술을 프레임워크와 컨테이너라는 방식으로 제공한다.