토비의 스프링(8) - 스프링이란 무엇인가?

#8장. 스프링이랑 무엇인가?

요약 및 결론

스프링의 개발철학과 목표를 분명히 이해하고 사용해야 한다.

멋진 애플리케이션을 위해서

책 내용

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

기술적 복잡함과 비즈니스 로직의 복잡함을 해결하기 위해 등장했다.

핵심은 POJO위에서 IoC/DI, AOP, PSA

POJO는 사실 그럴싸하게 이름만 붙여놓은 것

1. 스프링의 정의

스프링을 짧게 설명하는 것은 쉽지 않고 짧은 설명으로 충분하지도 않다.
가장 잘 알려진 정의
-> 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

• 애플리케이션 프레임워크
  • 특정 계층, 기술, 업무 분야에 국한되지 않고 애플리케이션 전 영역을 포괄하는 범용적인 프레임워크
  • 스프링은 처음부터 독자적인 프레임워크로 개발된 것이 아니다.(로드 존슨 책에서 프레임워크)
• 경량급 : 불필요하게 무겁지 않다는 의미
• 자바 엔터프라이즈 개발을 편하게
  • 편리한 애플리케이션 개발? 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 안쓰면서 비즈니스 로직을 빠르고 효과적으로 구현하는 것
  • EJB는 고민과 부담을 덜어주었지만 이 과정에서 다른 차원의 더 큰 복잡함을 끌고들어왔다.
• 오픈소스
  • 언제 지원이 중단될지 알 수 없는 오픈소스의 단점을 극복하기 위해 전문기업을 만들었다.
  • VMWare에서 스프링소스를 인수(현재 스프링은 VMWare 산하 Pivotal에서 운영)

    2. 스프링의 목적

    스프링을 더 잘 사용하기 위해 스프링의 개발 철학과 궁극적인 목표를 알아보자
    - 엔터프라이즈 개발이 복잡했고 문제는 무엇이였나?
    - 어떻게 해결하고자 했었는가?
    - 스프링은 어떻게 했었나?

1. 엔터프라이즈 개발의 복잡함
   • 복잡함의 근본적인 이유
     • 기술적인 제약조건과 요구사항이 늘어갔기 때문
       • 비즈니스로직 구현 외 기술적으로 고려할 사항이 많아졌다.
     • 비즈니스 로직 자체의 복잡도가 높아졌다.
       • 시간이 지날 수록 엔터프라이즈 시스템이 기업의 핵심업무 처리를 담당하는 비중이 늘어갔다.
       • 많은 업계에서 변화가 빠르게 일어나며 기능 요구사항과 업무 정책등이 바뀌기 때문에 애플리케이션을 자주 수정해야했다.
   • 복잡함을 가중시키는 원인
     • 세부 요소가 이해하기 힘든 방식으로 얽혀있어서 유지보수하기 힘들었다.
     • 전통적인 JavaEE 개발 기법은 비즈니스 로직의 복잡한 구현 코드와 기술적인 코드가 혼재될 수 밖에 없는 방식이였다.
2. 복잡함을 해결하려는 도전
   • 제거될 수 없는 근본적인 복잡함
     • 비즈니스 로직의 적용범위를 줄이고 기술적인 요구조건을 일부 생략하는 것은 해결 방법이 아니다.
     • 비즈니스 로직의 복잡함과 기술적인 복잡함은 처리하는 방법이 다르다.
     • 둘을 분리해내야 변화에 잘 대응할 수 있다.
   • 실패한 해결책: EJB
     • EJB의 기본 전략도 위 2 종류의 복잡함을 분리하는 것이었다.
     • 기술적인 복잡함을 덜어주려다 더 큰 복잡함을 추가해버렸다.
     • 발전 주기도 너무 느려서 엔터프라이즈 개발 기술의 발전을 따라잡지 못하는 것도 문제점이다.
   • 비침투적인 방식을 통한 효과적인 해결책: 스프링
     • EJB의 실패를 교훈으로 삼아서 출발했다.
     • 침투적(invasive)인 기술 : 기술과 관련된 코드나 규약 등이 애플리케이션 코드 여기저기에 불쑥 등장하는 기술
3. 복잡함을 상대하는 스프링의 전략
   • 기술적 복잡함을 상대하는 전략
     • 문제1. 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다.
       • 애플리케이션 환경에 따라 코드가 바뀌어야 한다면 심각한 문제다.
       • 스프링의 전략은 서비스추상화
     • 문제2. 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.
       • 기술과 비즈니스 로직의 혼재로 발생하는 복잡함(트랜잭션, 보안, 로깅이나 감사 등)
       • 스프링의 전략은 AOP
   • 비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략
     • 복잡한 비즈니스 로직을 상대하는 전략은 자바라는 객체지향 기술 그 자체이다.
     • 스프링은 단지 객체지향 언어의 장점을 제대로 살리지 못하게 방해했던 요소를 제거하도록 도와줄 뿐이다.
   • 핵심 도구: 객체지향과 DI
     • 기술과 비즈니스 로직의 복잡함을 해결하는 데 스프링이 공통적으로 사용하는 도구는 객체지향이다.
     • 그러나 객체지향 언어를 사용한다고 해서 자연스럽게 객체지향 설계가 되고 객체지향 프로그래밍을 할 수 있는 것은 아니다.
     • 이런 면에서 DI는 객체지향적인 설계와 개발을 이끌어주는 좋은 동반자이다.
     • 틀에 박힌 구조의 빈만 정의하고 나머지 코드에는 DI를 적용해볼 생각조차 안한다면 DI를 잘못 사용하고 있는 것이다.

       3. POJO 프로그래밍

4. 스프링의 핵심: POJO
   • 스프링 애플리케이션은 POJO를 이용해서 만든 애플리케이션 코드와, POJO가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계정보로 구분된다.
5. POJO란 무엇인가?
   • Plain Old Java Object
   • 단순한 자바객체를 사용하는게 좋아보이는데 그럴싸한 이름이 없어서 만들어 본 것
6. POJO의 조건
   • 특정 규약에 종속되지 않는다.
     • 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 한다.
     • 별다른 가치를 주지도 못하는 규약에 종속돼서는 안된다.
     • 객체지향 설계의 자유로운 적용이 가능한 객체여야만 POJO라고 불릴 수 있다.
   • 특정 환경에 종속되지 않는다.
     • 평범한 자바 클래스로만 개발했다면 모두 POJO인가?
     • POJO는 객체지향적 설계와 객체지향적인 원리에 충실해야만 한다.
7. POJO의 장점
   • POJO가 될 수 있는 조건이 그대로 장점이 된다.
   • 특정한 기술과 환경에 종속되지 않고 객체지향적으로 설계된 프로그램
8. POJO 프레임워크
   • 스프링은 POJO 프로그래밍이 가능하도록 기술적 기반을 제공하는 프레임워크이기 때문에 POJO 프레임워크이다.
   • 또 다른 POJO 프레임워크 : 하이버네이트, CDI (https://en.wikipedia.org/wiki/Plain_old_Java_object#Transparently_adding_services)
   • 비즈니스 로직의 복잡함은 POJO로 상대하고, 엔터프라이즈 기술의 복잡함은 스프링 프레임워크가 상대한다.
   • 좋은 프레임워크는 그것을 사용해서 만들어지는 코드가 나쁜코드가 되기 어렵다는 특징을 갖는다.

     4. 스프링의 기술

     IoC/DI, AOP, PSA는 스프링이 있기 이전에도 여러가지 형태로 시도됐다.
     객체지향의 설계와 개발원리를 잘 적용하다 보면 자연스럽게 만들어지는 것이기도 하다.

9. 제어의 역전(IoC) / 의존관계 주입(DI)
   • IoC/DI는 스프링의 가장 기본이 되는 기술이자 스프링의 핵심 개발 원칙이기도 하다.
   • DI는 OCP원칙으로 잘 설명될 수 있다. 변경에는 닫혀있고 확장에는 열려있기 때문
   • DI 활용 방법
     • 핵심 기능의 변경 : 의존 대상의 구현을 바꾸는 것(ex_ DAO)
     • 핵심 기능의 동적인 변경 : 조건에 따라 의존대상을 동적으로 변경할 수 있다.
     • 부가기능의 추가 : 핵심기능은 그대로 둔 채로 부가기능을 추가하는 것
     • 인터페이스의 변경 : 인터페이스가 일치하지 않는 호출이 필요한 경우
     • 프록시
     • 템플릿과 콜백 : 콜백을 템플릿에 주입하는 방식의 동작은 DI의 원리에 가장 충실한 응용 방법이다.
     • 싱글톤과 오브젝트 스코프 : DI 할 객체의 생명주기 제어
     • 테스트 : 목 객체를 DI
10. 애스펙트 지향 프로그래밍(AOP)
    • AOP와 OOP는 서로 배타적이 아니다.
    • AOP를 활용하면 OOP를 더욱 OOP답게 만들 수 있다.
    • AOP 적용 기법
      • 기법1. 스프링과 같이 다이내믹 프록시를 사용하는 방법
        • 기존 코드에 영향을 주지 않고 부가기능을 적용하게 해주는 데코레이터 패턴을 응용한 것
        • 엔터프라이즈 개발에서 필요로 하는 AOP는 대부분이 이 프록시 방식의 AOP면 된다.
      • 기법2. 자바언어의 한계를 넘어서는 언어의 확장을 이용하는 방법(AspectJ)
        • 프록시 방식의 AOP에서는 불가능한 다양한 조인 포인트를 제공한다.
        • 사용하기 까다롭고 번잡하다.
    • AOP의 적용 단계
      • 제대로 적용하려면 충분한 시간과 노력이 필요하다.
      • 단계1. 미리 준비된 AOP 이용
        • 스프링의 트랜잭션
        • AspectJ를 이용한 @Configurable
      • 단계2. 전담팀을 통한 정책 AOP 적용
        • 개발 정책을 위반한 호출에 대해 정책위반 예외를 던지도록 AOP 모듈을 만들 수 있다.
      • 단계3. AOP의 자유로운 이용
11. 포터블 서비스 추상화(PSA)
    • PSA는 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해준다.
    • 스프링에서는 다양한 서비스 추상화 기능을 제공하기 때문에 직접적으로 서비스를 이용할 필요 없이 설정만 해주면 된다.
    • 필요하다면 직접 추상 레이어를 도입하고 일관성 있는 API를 정의해서 사용하면 된다.
    • DI를 적극 활용해서 개발한다면 서비스 추상화는 자연스럽게 만들어 쓸 수 있다.

      5. 정리

• 스프링의 상세한 기술을 공부하기 전에 먼저 이해하고 기억해야 할 사항
• 스프링은 그 개발철학과 목표를 분명히 이해하고 사용해야 한다.
• 스프링은 오픈소스 소프트웨어이며, 애플리케이션 개발의 모든 기술과 영역을 종합적으로 다루는 애플리케이션 프레임워크이다.
• 스프링의 탄생 배경은 기존 접근법이 비즈니스 로직과 기술적인 복잡도를 낮추지 못하고 객체지향적 장점을 포기해야하는 문제가 있었기 때문이다.
• 스프링은 자바의 근본인 객체지향적 원리에 충실하게 개발할 수 있으며, 환경과 규약에 의존적이지 않은 POJO를 이용한 애플리케이션 개발은 엔터프라이즈 개시스템 개발의 복잡함이 주는 많은 문제를 해결할 수 있다.
• 스프링의 목적은 이런 POJO를 이용해 엔터프라이즈 애플리케이션을 쉽고 효과적으로 개발할 수 있도록 지원해주는 데 있다.
• POJO 방식의 개발을 돕기 위해 스프링은 IoC/DI, AOP, PSA와 같은 기능기술을 프레임워크와 컨테이너라는 방식을 통해 제공한다.