토비의 스프링 Vol.1 - 8장 스프링이란 무엇인가?

2020-11-03

스프링이란 무엇인가?

스프링의 정의

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

  • 애플리케이션 프레임워크
    • 일반적으로 라이브러리나 프레임워크는 특정 업무 분야나 한 가지 기술에 특화된 목표를 가지고 만들어진다. 하지만 스프링은 이와 다르게 ‘애플리케이션 프레임워크’라는 특징을 갖고 있다.
    • 애플리케이션 프레임워크는 특정 계층이나, 기술 업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다. 애플리케이션 프레임워크는 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는데 일차적인 목표를 두는 프레임워크다.
    • 애플리케이션의 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심 기술을 바탕으로 해서 각 분야의 특성에 맞는 필요를 채워주고 있기 때문에, 애플리케이션을 빠르고 효과적으로 개발할 수가 있다.
    • 스프링의 일차적인 존재 목적은 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능을 제공해줌으로써 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임워크로 사용된다.
  • 경량급
    • 스프링이 경량급이라는 건 스프링 자체가 아주 가볍다거나 작은 규모의 코드로 이뤄졌다는 뜻은 아니다. 오히려 스프링은 20여 개의 모듈로 세분화되고 수십만 라인에 달하는 코드를 가진 매우 복잡하고 방대한 규모의 프레임워크다.
    • 그럼에도 스프링이 가볍다고 하는 이유는 불필요하게 무겁지 않다는 의미다. 스프링은 가장 단순한 서버환경인 톰캣이나 제티에서도 완벽하게 동작한다. 단순한 개발툴과 기본적인 개발환경으로도 엔터프라이즈 개발에서 필요로 하는 주요한 기능을 갖춘 애플리케이션을 개발하기에 충분하다.
    • 같은 기능을 수행하는 코드인데도 스프링 기반의 코드가 가벼운 이유는 코드에 불필요하게 등장하던, 프레임워크와 서버환경에 의존적인 부분을 제거해주기 때문이다.
  • 자바 엔터프라이즈 개발을 편하게
    • 스프링은 근본적인 부분에서 엔터프라이즈 개발의 복잡함을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시한다. 엔터프라이즈 개발의 근본적인 문제점에 도전해서 해결책을 제시한다는 것이 기존 기술의 접근 방법과 스프링의 접근 방법의 차이점이다.
    • 애플리케이션 개발이란 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 많은 신경을 쓰지 않으면서도 애플리케이션의 핵심인 사용자의 요구사항, 즉 비즈니스 로직을 빠르고 효과적으로 구현하는 것을 말한다.
    • 스프링은 애플리케이션 개발자들이 스프링이라는 프레임워크가 제공하는 기술이 아니라 자신이 작성하는 애플리케이션의 로직에 더 많은 관심과 시간을 쏟게 해준다. 초기에 스프링의 기본 설정과 적용 기술만 잘 선택하고 준비해두면, 이후로 애플리케이션 개발 중에는 스프링과 관련된 코드나 API에 대해 개발자가 거의 신경 쓸 일이 없다.
    • 스프링은 또한 엔터프라이즈 개발의 기술적인 복잡함과 그에 따른 수고를 제거해준다. 엔터프라이즈 개발에서 필연적으로 요구되는 기술적인 요구를 충족하면서도 개발을 복잡하게 만들지 않는다는 점이 스프링의 뛰어난 면이다.
  • 오픈소스
    • 오픈소스란 말 그대로 소스가 모두에게 공개되고, 특별한 라이선스를 취득할 필요 없이 얼마든지 가져다 자유롭게 이용해도 된다는 뜻이다.
    • 하지만 공식적인 개발은 제한된 인원의 개발자에 한정된다. 개발팀이 폐쇄적으로 운영되고 있따는 사실은 미션크리티컬한 시스템 개발에도 사용되는 엔터프라이즈 프레임워크인 스프링 입장에서는 중요한 의미가 있다.
    • 전문 개발팀이 개발함으로써 지속적이고 안정적인 개발이 계속될지가 불확실한 오픈소스의 문제점과 한계를 극복할 수 있는 것이다.

      스프링은 오픈소스의 장점을 충분히 취하면서 동시에 오픈소스 제품의 단점과 한계를 잘 극복하고 있는, 전문적이고 성공적인 오픈소스 소프트웨어라고 할 수 있다.

스프링의 목적

자바 언어와 JDK 라이브러리는 모두 일종의 편리한 도구로서 자바 언어의 특징인 객체지향 프로그래밍을 좀 더 손쉽게 할 수 있도록 돕고 있을 뿐이다. 자바의 근본적인 목적은 객체지향 프로그래밍을 통해 유연하고 확장성 좋은 애플리케이션을 빠르게 만드는 것이다. 자바를 가져다가 절차지향 언어처럼 사용한다면 자바를 사용하는 가치를 얻을 수 없다.

스프링의 목적은 경량급 프레임워크인 스프링을 활용해서 엔터프라이즈 애플리케이션 개발을 편하게 하는 것이다. 왜냐하면 엔터프라이즈 개발이란 편하지 않기 때문이다.

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

복잡함의 근본적인 이유
  1. 기술적인 제약조건과 요구사항이 늘어가기 때문이다.
    • 엔터프라이즈 시스템이란 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템을 말한다.
    • 엔터프라이즈 시스템은 많은 사용자의 요청을 동시에 처리해야 하기 때문에 서버의 자원을 효율적으로 공유하고 분배해서 사용할 수 있어야 한다.
    • 중요한 기업의 핵심 정보를 처리하거나 미션 크리티컬한 금융, 원자력, 항공, 국방 등의 시스템을 다루기도 하기 때문에 보안과 안정성, 확장성 면에서도 뛰어나야 한다.
    • 뛰어난 성능과 서비스의 안정성이 요구되고 그런 점을 고려한 개발 기술이 필요하다.
    • 순수한 비즈니스 로직을 구현하는 것 외에도 기술적으로 고려할 사항이 많다.
    • 엔터프라이즈 시스템이 기업 업무를 처리하는 데 핵심적인 역할로 등장하고 중요해지면서 점점 더 기술적인 요구는 심화되고 그에 따른 복잡도는 증가한다.
  2. 엔터프라이즈 애플리케이션이 구현해야 할 핵심 대상인 비즈니스 로직의 복잡함이 증가하기 때문이다.
    • 다양하고 복잡한 업무 처리 기능을 엔터프라이즈 시스템이 구현해야 했다.
    • 엔터프라이즈 시스템이 관여하는 업무의 비율이 급격하게 커지고 있으니 당연히 애플리케이션 개발도 힘들고 복잡해져 간다.

      2000년 전후로 전 세계에 불어 닥친 경제위기가 기업의 체질을 크게 바꿨다. 경제 흐름과 사회의 변화, 업계의 추이에 따라서 수시로 업무 프로세스를 변경하고 조종하는 것을 상시화할 만큼 변화의 속도가 빨라졌다. 따라서 엔터프라이즈 시스템의 변경을 요구했고 그만큼 이전과 다르게 시스템 개발과 유지보수, 추가 개발 등의 작업에 대한 부담은 커지고 그에 따른 개발의 난이도는 더욱 증가한 것이다.

      복잡함을 가중시키는 원인

      엔터프라이즈 애플리케이션 개발이 실패하는 주요 원인은 비즈니스 로직의 복잡함과 기술적인 복잡함이다. 하나씩 놓고 봐도 만만치 않은데, 두 가지를 한 번에 다뤄야 하니 복잡함이 몇 배로 가중되는 것이다.

      복잡함을 해결하려는 도전

      제거될 수 없는 근본적인 복잡함

      근본적으로 엔터프라이즈 개발에 나타나는 복잡함의 원인은 제거 대상이 아니다. 그 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요하다. 비즈니스 로직의 복잡함을 효과적으로 다루기 위한 방법과 기술적인 복잡함을 효과적으로 처리하는 데 적용되는 방법이 다르다. 따라서 두 가지 복잡함이 코드에 한데 어우러져 나타나는 전통적인 개발 방식에서는 효과적으로 복잡함을 다루기가 힘들다.
      따라서 가장 먼저 할 일은 성격이 다른 이 두 가지 복잡함을 분리해내는 것이다.

      실패한 해결책: EJB

      EJB는 기술적인 복잡함을 애플리케이션의 핵심 로직에서 일부분 분리하는 데 성공하긴 했지만 EJB환경에서 동작하기 위해 특정 인터페이스를 구현하고, 특정 클래스를 상속하고, 서버에 종속적인 서비스를 통해서만 접근하고 사용이 가능하게 만드는 등의 EJB 개발 방식은 잘못됐다. 애플리케이션 로직을 담은 핵심 코드에서 일부 기술적인 코드가 제거된 건 사실이지만, 오히려 EJB라는 환경과 스펙에 종속되는 코드로 만들어져야 하는 더 큰 부담을 안게 됐다.

      비침투적인 방식을 통한 효과적인 해결책: 스프링

      비침투적인 기술은 기술의 적용 사실이 코드에 직접 반영되지 않는다는 특징이 있다. 스프링을 이용하면 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리할 수 있다. 중요한 점은 이 과정에서 스프링 스스로가 애플리케이션 코드에 불필요하게 나타나지 않는다.

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

      스프링의 기본적인 전략은 비즈니스 로직을 담은 애플리케이션 코드와 엔터프라이즈 기술을 처리하는 코드를 분리시키는 것이다. 이 분리를 통해 두 가지 복잡함의 문제를 효과적으로 공략하게 해준다.

      기술적 복잡함을 상대하는 전략
  3. 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다.
    • 기술적인 복잡함은 일단 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부기술에 독립적인 접근 인터페이스를 제공한다.
  4. 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다.
    • AOP는 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 기술이다. AOP는 기술을 다루는 코드로 인한 복잡함이 기술 그 자체 이상으로 불필요하게 증대되지 않도록 도와주는 수단이다. ##### 비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략 기술적인 코드, 침투적인 기술이 가져온 불필요한 흔적 등을 제거하고 나면 순수하게 애플리케이션의 주요 기능과 비즈니스 로직을 담은 코드만 독립적으로 존재하게 된다.

자바는 객체지향 언어의 강점을 잘 살려서 설계된 언어다. 객체지향 프로그래밍 기법과 언어가 주는 장점인 유연한 설계가 가능하고 재사용성이 높다는 점을 잘 활용하면 자주 바뀌고 조건이 까다로운 비즈니스 로직을 효과적으로 구현해낼 수 있다. 객체지향 분석과 설계를 통해서 작성된 모델을 코드로 구현하고 지속적으로 발전시킬 수도 있다. ##### 핵심 도구: 객체지향과 DI 기술과 비즈니스 로직의 복잡함을 해결하는 데 스프링이 공통적으로 사용하는 도구가 바로 객체지향이다.

기술적인 복잡함을 효과적으로 다루게 해주는 기법은 모두 DI를 바탕으로 하고 있다. 서비스 추상화, 템플릿/콜백, AOP와 같은 스프링의 기술은 DI 없이는 존재할 수 없다.

그리고 DI는 객체지향 설계 기술이 없이는 그 존재의미가 없다. DI란 특별한 기술이라기보다는 유연하게 확장할 수 있는 오브젝트 설계를 하다 보면 자연스럽게 적용하게 되는 객체지향 프로그래밍 기법일 뿐이다. 스프링은 단지 그것을 더욱 편하고 쉽게 사용하도록 도와줄 뿐이다.

모든 스프링의 기술과 전략은 객체지향이라는 자바 언어가 가진 강력한 도구를 극대화해서 사용할 수 있도록 돕는 것이다.

POJO 프로그래밍

스프링의 핵심: POJO

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

POJO란 무엇인가?

POJO는 Plain Old Java Object의 첫 글자를 따서 만든 약자다. 자바의 단순한 오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하는 편이 좋다.

POJO의 조건

  1. 특정 규약에 종속되지 않는다.
    • POJO는 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 한다.
    • 규약이 적용된 환경에 종속적이 되기 때문에 다른 환경으로 이전이 힘들다는 문제점이 있다.
    • 별다른 가치를 주지도 못하는 규약 따위에 종속되지 않아야 하고, 객체지향 설계의 자유로운 적용이 가능한 오브젝트여야만 POJO라고 불릴 수 있다.
  2. 특정 환경에 종속되지 않는다.
    • 특정 환경이 의존 대상 검색 방식에 종속적이라면 POJO라고 할 수 없다.
    • 순수한 애플리케이션 로직을 담고 있는 오브젝트 코드가 특정 환경에 종속되게 만드는 경우라면 그것 역시 POJO라고 할 수 없다.
  3. POJO는 객체지향적인 자바 언어의 기본에 충실하게 만들어져야 한다.
    • 자바 언어 문법을 사용했다고 해서 자동으로 객체지향 프로그래밍과 객체지향 설계가 적용됐다고 볼 수는 없다.

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

      POJO의 장점

      POJO가 될 수 있는 조건이 그대로 POJO의 장점이 된다.

    • 특정한 기술과 환경에 종속되지 않는 오브젝트는 그만큼 깔끔한 코드가 될 수 있다.
    • POJO로 개발된 코드는 자동화된 테스트에 매우 유리하다.
    • 객체지향적인 설계를 자유롭게 적용할 수 있다.

      POJO 프레임워크

      POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크를 POJO 프레임워크라고 한다. 스프링 프레임워크와 하이버네이트를 대표적인 POJO 프레임워크로 꼽을 수 있다. 주로 DB 이용 기술에 POJO를 적용하는 것을 목적으로 하는 하이버네이트와 달리, 스프링은 엔터프라이즈 애플리케이션 개발의 모든 영역과 계층에서 POJO 방식의 구현이 가능하게 하려는 목적으로 만들어졌다.

스프링을 이용하면 POJO 프로그래밍의 장점을 그대로 살려서 엔터프라이즈 애플리케이션의 핵심 로직을 객체지향적인 POJO를 기반으로 깔끔하게 구현하고, 동시에 엔터프라이즈 환경의 각종 서비스와 기술적인 필요를 POJO 방식으로 만들어진 코드에 적용할 수 있다.

POJO 프레임워크로서 스프링은 자신을 직접 노출하지 않으면서 애플리케이션을 POJO로 쉽게 개발할 수 있게 지원해준다.

스프링은 개발자들이 복잡한 엔터프라이즈 기술보다는 객체지향적인 설계와 개발의 원리에 좀 더 집중할 수 있도록 기회를 준다. 동시에 스프링이 제공하는 기술과, 프레임워크 API 및 확장 포인트는 그것을 이용하는 코드가 자연스럽게 객체지향적인 설계원리를 따라가도록 이끌어주기도 한다.

스프링의 기술

기술과 비즈니스 로직을 분리하고 POJO 방식의 애플리케이션 개발을 가능하게 한다는 스프링의 목적을 쉽게 이루려면 스프링과 같은 POJO 프레임워크가 필요하다. 스프링에는 POJO 프로그래밍을 손쉽게 할 수 있도록 지원하는 세 가지 가능기술을 제공한다. 바로 IoC/DI, AOP, PSA다.

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

IoC/DI는 스프링의 가장 기본이 되는 기술이자 스프링의 핵심 개발 원칙이기도 하다. 나머지 두 가지 기술인 AOP와 PSA도 IoC/DI에 바탕을 두고 있다.

DI는 개방 폐쇄 원칙이라는 객체지향 설계 원칙으로 잘 설명될 수 있다. 유연한 확장이라는 장점은 OCP의 ‘확장에는 열려 있다’에 해당한다. DI는 역시 OCP의 ‘변경에는 닫혀 있다’라는 말로도 설명이 가능하다. 폐쇄 관점에서 볼 때 장점은 ‘재상용이 가능하다’라고 볼 수 있다.

DI의 활용 방법
  • 핵심 기능의 변경
    • DI의 가장 대표적인 적용 방법은 바로 의존 대상의 구현을 바꾸는 것이다. 실제 의존하는 대상이 가진 핵심기능을 DI 설정을 통해 변경하는 것이 대표적인 DI의 활용 방법이다.
  • 핵심 기능의 동적인 변경
    • 의존 오브젝트의 핵심기능 자체를 바꾼다. 일반적인 DI를 이용한 변경 방법과는 달리, 동적으로 매번 다르게 변경할 수 있다. DI를 잘 활용하면 애플리케이션이 동작하는 중간에 그 의존 대상을 다이내믹하게 변경할 수 있다.
  • 부가기능의 추가
    • 핵심기능은 그대로 둔 채로 부가기능을 추가한다. 핵심기능과 클라이언트 코드에는 전혀 영향을 주지 않으면서 부가적인 기능을 추가할 수 있다.
  • 인터페이스의 변경
    • 사용하려고 하는 오브젝트가 가진 인터페이스가 클라이언트와 호환되지 않는 경우나, 여러 종류의 인터페이스를 가졌지만 사실은 비슷한 기능을 담당하는 오브젝트를 바꿔가면서 사용하고 싶을 때. 클라이언트가 사용하는 인터페이스와 실제 오브젝트 사이에 인터페이스가 일치하지 않는 경우에도 DI가 유용하다.
    • PSA는 클라이언트가 일관성 있게 사용할 수 있는 인터페이스를 정의해주고 DI를 통해 어댑터 역할을 하는 오브젝트를 이용하게 해준다. 이를 통해서 다른 인터페이스를 가진 로우레벨의 기술을 변경하거나 확장해가면서 사용할 수 있는 것이다.
  • 프록시
    • 필요한 시점에서 실제 사용할 오브젝트를 초기화하고 리소스를 준비하게 해주는 지연된 로딩(lazy loading)을 적용하려면 프록시가 필요하다.
    • 원격 오브젝트를 호출할 때 마치 로컬에 존재하는 오브젝트처럼 사용할 수 있게 해주는 원격 프록시를 적용하려고 할 때도 프록시가 필요하다.
    • 두 가지 방법 모두 DI를 필요로 한다.
  • 템플릿과 콜백
    • 반복적으로 등장하지만 항상 고정적인 작업 흐름과 그 사이에서 자주 바뀌는 부분을 분리해서 템플릿과 콜백으로 만들고 이를 DI 원리를 응용해 적용하면 지저분하게 매번 만들어야 하는 코드를 간결하게 만들 수 있다.
    • 콜백을 템플릿에 주입하는 방식으로 동작하게 하는 것은 DI의 원리에 가장 충실한 응용 방법이다.
    • 콜백을 얼마든지 만들어서 사용할 수 있다는 건 개방을 통한 유연한 확장성을 보여주는 것이며, 템플릿은 한 번 만들어두면 계속 재사용할 수 있다는 건 기능의 확장에도 변하지 않는다는 OCP의 폐쇄 원칙에 가장 잘 들어맞는 것이다.
  • 싱글톤과 오브젝트 스코프
    • DI가 필요한 중요한 이유 중 한 가지는 DI 할 오브젝트의 생명주기를 제어할 수 있다는 것이다. DI를 프레임워크로 이용한다는 건 DI 대상 오브젝트를 컨테이너가 관리한다는 의미다. 오브젝트의 생성부터 관계설정, 이용, 소멸에 이르기까지의 모든 과정을 DI 컨테이너가 주관하기 때문에 그 오브젝트의 스코프를 자유롭게 제어할 수 있다.
  • 테스트
    • 여타 오브젝트와 협력해서 동작하는 오브젝트를 효과적으로 테스트하는 방법은 가능한 한 고립시키는 것이다. 즉 다른 오브젝트와의 사이에서 일어나는 일을 테스트를 위해 조작할 수 있도록 만든다. 그래야만 테스트 대상인 오브젝트의 기능에 충실하게 테스트가 가능하다.
    • DI를 위해 만든 수정자 메소드를 사용하면 테스트 코드 안에서 수동으로 목 오브젝트를 주입할 수 있다. 또는 테스트용으로 설정을 별도로 만드는 방법도 있다.

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

      AOP는 객체지향 기술의 한계와 단점을 극복하도록 도와주는 보조적인 프로그래밍 기술이다. AOP를 사용하면 그 결과로 OOP를 더욱 OOP답게 만들 수 있다.

      AOP의 적용 기법
      1. 스프링과 같이 다이내믹 프록시를 사용하는 방법
  • 기존 코드에 영향을 주지 않고 부가기능을 적용하게 해주는 데코레이터 패턴을 응용한 것이다. 자바의 객체지향 패턴을 활용한 방법이기 때문에 만들기 쉽고 적용하기 간편하지만 부가기능을 부여할 수 있는 곳은 메소드의 호출이 일어나는 지점뿐이라는 제약이 있다.
    1. 자바 언어의 한계를 넘어서는 언어의 확장을 이용하는 방법
  • 유명한 오픈소스 AOP 툴인 AspectJ는 고급 기능을 가진 AOP를 제공한다. 메소드 호출뿐 아니라 인스턴스 생성, 필드 액세스, 특정 호출 경로를 가진 메소드 호출 등에도 부가기능을 제공할 수 있다. 하지만 그만큼 사용하기 까다롭고 번거롭다.
    AOP의 적용 단계
    1. 미리 준비된 AOP 이용
  • 스프링이 미리 만들어서 제공하는 AOP 기능을 그대로 가져다 적용한다. 대표적인 AOP는 트랜잭션이다.
    1. 전담팀을 통한 정책 AOP 적용
  • 애플리케이션 전체적으로 이용 가능한 것을 소수의 AOP 담당자 관리하에 적용해 본다.
    1. AOP의 자유로운 이용
  • 첫 번째와 두 번째 단계를 거쳐서 AOP에 어느 정도 친숙해지고, 그 장단점과 응용 전략, 위험성 등을 어느 정도 이해했다면 이제는 개발자 스스로가 AOP를 활용할 수 있는 단계로 넘어갈 수 있다.

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

    세 번째 가능기술은 환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 PSA다. POJO로 개발된 코드는 특정 환경이나 구현 방식에 종속적이지 않아야 한다. 이를 위해 스프링이 제공하는 대표적인 기술이 바로 일관성 있는 서비스 추상화 기술이다.

엔터프라이즈 개발에 사용되는 기술은 끊임없이 쏟아져 나온다. 표준 기술뿐 아니라 오픈소스 라이브러리, 상용 프레임워크 형태로도 새로운 기술이 등장한다. 보편적으로 사용되는 기술이라면 아마도 다음 버전의 스프링에서 서비스 추상화 대상으로 포함시킬 가능성이 있다. 하지만 그것을 굳이 기다려야 할 이유는 없다. 필요하면 직접 추상 레이어를 도입하고 일관성 있는 API를 정의해서 사용하면 된다.

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

정리

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

출처 : https://github.com/Masssidev/toby-vol1