8장) 8.1 스프링의 정의 ~ 8.2 스프링의 목적

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

8.1 스프링의 정의

• 스프링의 가장 대중적인 정의
  • 자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션
• 애플리케이션 프레임워크
  • 일반적인 라이브러리, 프레임워크
    • 특정 업무 분야나 한 가지 기술에 특화된 목표를 가지고 만들어짐
      • ex) 웹 계층을 MVC로 쉽게 만듦, 포맷과 출력장치를 유연하게 변경할 수 있는 애플리케이션 로그 기능 제공, ORM 등
  • 스프링
    • 애플리케이션 프레임워크
      • 특정 계층이나, 기술, 업무 분야에 국한되지 않고 애플리케이션 전 영역을 포괄하는 범용적인 프레임워크
      • 자바 엔터프라이즈 개발의 이상적인 프로그래밍 모델을 추구하는 데 필요한 기반이 돼주는 코드, 즉 프레임워크가 지금 스프링의 원시버전
      • 애플리케이션 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심 기술을 바탕으로, 각 분야의 특성에 맞는 필요를 채워주고 있기 때문에 애플리케이션을 빠르고 효과적으로 개발 가능
      • 핵심 기술에 담긴 프로그래밍 모델을 일관되게 적용해서 엔터프라이즈 애플리케이션 전 계층과 전 영역에 전략과 기능 제공
        • 애플리케이션을 편리하게 개발하게 해주는 애플리케이션 프레임 워크로 사용됨
• 경량급
  • 기술수준이 가볍다거나, 용도가 제한적인 의미가 아닌, 불필요하게 무겁지 않음을 의미
    • 스프링이 처음 등장했을 시절의 자바 주류 기술인 이전 EJB 같은 과도한 엔지니어링이 적용된 기술과 스프링을 대비해 설명했던 표현
• 자바 엔터프라이즈 개발을 편하게
  • 근본적인 부분에서 엔터프라이즈 개발의 복잡함을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시
  • 편리한 애플리케이션 개발 == 개발자가 복잡하고 실수하기 쉬운 로우레벨 기술에 신경을 덜쓰고 애플리케이션의 핵심인 요구사항(비즈니스 로직)을 빠르고 효과적으로 구현하는 것
    • EJB
      • EJB의 비전과 목표도 편리한 애플리케이션 개발이었지만, 이 과정에서 다른 차원의 더 큰 복잡함을 애플리케이션 개발에 끌고 들어왔음
    • 스프링
      • 애플리케이션 개발자들이 프레임워크가 제공하는 기술이 아니라 자신의 애플리케이션 로직에 더 많은 관심과 시간을 쏟게 도와줌
      • 엔터프라이즈 개발의 기술적인 복잡함과 그에따른 수고를 제거
      • 필연적으로 요구되는 기술적인 요구를 충족하면서도 개발을 복잡하게 만들지 않음
• 오픈소스
  • 오픈소스 프로젝트 방식으로 개발
  • 개발 과정에 많은 사람이 자유롭게 참여
    • 거대하고 활발한 커뮤니티
    • 잠재적인 버그와 문제점이 빠르게 발견되고 해결
    • 라이선스 비용에 대한 부담이 X
  • 지속적이고 안정적인 개발이 계속될지 불확실하다는 단점이 존재

8.2 스프링의 목적

• 스프링의 개발 철학과 궁극적인 목표 생각하기

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

• 2000년대 초반 자바 컨퍼런스에서 자주 논의된 주제는 왜 자바 엔터프라이즈(JAVA EE) 프로젝트는 실패하는가?
  • 여러 원인 중 가장 대표적인 이유는, 엔터프라이즈 시스템 개발이 너무 복잡해져서
• 복잡함의 근복적인 이유 두 가지
  • 기술적인 제약조건과 요구사항이 늘어가기 때문
    • 엔터프라이즈 시스템
      • 서버에서 동작하며 기업과 조직의 업무를 처리해주는 시스템
      • 많은 사용자의 요청을 동시에 처리 ~> 서버 자원을 효율적으로 공유하고 분배하여 사용
      • 중요한 기업 핵심 정보 처리 및 미션 크리티컬한 시스템을 다룸 ~> 보안, 안정성, 확장성에 뛰어나야함
      • 타 시스템과의 자동화된 연계, 리모팅 기술, 분산 트랜잭션 지원 등 요구됨
      • 순수 비즈니스 로직 구현 외 기술적 고려 사항이 많음
  • 엔터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문
    • 엔터프라이즈 시스템이 관여하는 업무의 비율이 급격하게 커지며 애플리케이션 개발이 힘들고 복잡해짐
    • 수시로 업무 프로세스를 변경하고 조종하는 것이 상시화될 정도로 변화의 속도가 빨라짐
    • 시스템 개발 및 유지보수, 추가 개발 등의 작업에 대한 부담이 커지고 난이도가 상승
• 복잡함을 가중시키는 원인
  • 엔터프라이즈 애플리케이션 개발이 실패하는 주요 원인은 비즈니스 로직의 복잡함과 기술적인 복잡함이 한데 얽혀 있기 때문
    • ex) 고객의 거래내역 분석 ~> 특성 파악 ~> 추천상품 선정 로직
      • 비즈니스 로직 + 다양한 기술 문제 존재(기술 선정 및 유지보수 등)
      • 복잡하게 얽힌 코드를 수정하다 새로운 버그 양산 가능성이 높아짐

8.2.2 복잡함을 해결하려는 도전

• 제거될 수 없는 근본적인 복잡함
  • 엔터프라이즈 개발의 근본적인 복잡함의 원인은 제거 대상 X
  • 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요
  • 비즈니스 로직의 복잡함을 효과적으로 다루기 위한 방법,
    기술적인 복잡함을 효과적으로 처리하는데 적용되는 방법이 서로 다름
    • 성격이 다른 이 두 가지 복잡함을 분리해야함
• 실패한 해결책: EJB
  • EJB의 목표 또한 위의 두 복잡함을 분리하는 것
  • 기술적인 복잡함을 애플리케이션 핵심 로직에서 일부분 분리에 성공
    • EJB라는 환경과 스펙에 종속되는 코드로 만들어져야 하는 더 큰 부담을 만듦
    • EJB 틀 안에서 자바코드를 강제 ~> 자바 언어가 원래 갖고 있던 장점을 상실
    • 객체 지향적인 특성은 잃어버린 밋밋한 서비스 스크립트성 코드로 변질
• 비침투적인 방식을 통한 효과적인 해결책: 스프링
  • EJB와 같은 목표로 출발
  • 침투적인 기술 vs 비침투적인 기술
    • 침투적인 기술
      • EJB처럼 어떤 기술을 적용했을 때 그 기술과 관련된 코드나 규약 등이 코드에 등장하는 경우
    • 비침투적인 기술
      • 기술의 적용 사실이 코드에 직접 반영되지 않는 특징
  • 스프링은 비침투적인 기술 전략
    • 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리
      • 이 과정에서 스프링 스스로가 애플리케이션 코드에 불필요하게 나타나지 않음
      • 꼭 필요할 것 같은 경우 조차 직접 노출되지 않음

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

• 기술적 복잡함을 상대하는 전략
  • 엔터프라이즈 기술을 적용했을 때 발생하는 복잡함의 문제 두 가지
  • 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다
    • 일관성 없는 기술과 서버환경의 변화에 대한 스프링의 공략 방법은 서비스 추상화
      • ex) 트랜잭션 추상화, OXM 추상화, 데이터 엑세스 기술에 독립적으로 적용 가능한 트랜잭션 동기화 기법 등
    • 기술적인 복잡함은 추상화로 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리, 환경과 세부 기술에 독립적인 접근 인터페이스를 제공하는 것이 좋음
    • 테스트 편의성 증대, 기술에 대한 세부 설정과 환경에 독립적인 코드 작성 가능
  • 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다
    • 근본적으로 엔터프라이즈 서비스를 적용하는 한, 책임에 따라 계층을 구분하고 그 사이에 서로 기술과 특성에 의존적인 인터페이스나 예외처리 등을 최대한 제거한다해도 쉽게 해결 불가
    • 스프링의 해결 방법 AOP
      • 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술
      • AOP 적용 이전의 문제
        • 기술과 비즈니스 로직이 지저분하게 얽혀 다루기 힘듦
        • 기술적인 코드가 중복되는 문제
      • AOP는 기술을 다루는 코드로 인한 복잡함이 기술 그 자체 이상으로 불필요하게 증대되지 않도록 도와주는 가장 강력한 수단
• 비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략
  • 비즈니스 로직을 담은 코드는 애플리케이션의 가장 중요한 핵심
    • 자주 변경되거나 수정되고 복잡함
    • 핵심 코드에 오류가 있으면 업무에 큰 지장을 주거나 치명적인 손실을 유발
  • 예전에는 비즈니스 로직의 상당 부분을 DB에 두는 것이 유행
    • 엔터프라이즈 시스템 규모가 커지고, 복잡함이 증가하면서 DB에 두는 것이 불편하고 위험해짐
    • 많은 비용이 드는 공유 자원인 DB에 커다란 부담을 주고, 개발 & 유지보수, 테스트도 매우 어려움
  • 비즈니스 로직은 애플리케이션 안에서 처리하도록 만들도록 발전
  • 자바는 객체지향 언어의 장점을 살려 설계된 언어
    • 객체지향 프로그래밍 기법과 언어가 주는 장점인 유연한 설계가 가능하고 재사용성이 높다는 점을 잘 활용하면 자주 바뀌고 조건이 까다로운 비즈니스 로직을 효과적으로 구현해낼 수 있음
    • 객체지향 분석과 설계를 통해 작성된 모델을 코드로 구현하고 지속적으로 발전시킬 수 있음
  • 비침투적인 기술인 스프링은 핵심 로직을 다루는 코드에는 스프링의 흔적을 찾을 수 없을 만큼 드러내지 않음
    • 뒤에서 비즈니스 로직을 담당하는 오브젝트들에게 적절한 엔터프라지 기술 서비스가 제공되도록 도움
  • 비즈니스 로직의 복잡함을 상대하는 스프링의 전략은 자바라는 객체지향 기술 그 자체
• 핵심 도구: 객체지향과 DI
  • 기술과 비즈니스 로직의 복잡함을 해결하는 데 스프링이 공통적으로 사용하는 도구는 객체지향oo
  • 스프링의 모토는 기본으로 돌아가자
    • 자바 엔터프라이즈 기술의 가장 큰 장점은 객체지향 설계와 프로그래밍을 가능하게 해주는 자바 언어
    • 자바의 기본인 객체지향에 충실한 설계까 가능하도록 단순한 오브젝트로 개발, 구조를 만들기 위해 DI 같은 유용한 기술을 편하게 적용하도록 도와주는 것이 스프링의 기본 전략
    • 서비스 추상화, 템플릿 / 콜백, AOP와 같은 스프링의 기술은 DI없이 존재할 수 없음
  • DI는 유연하게 확장할 수 있는 오브젝트를 설계를 하다보면 자연스럽게 적용되는 객체지향 프로그래밍 기법
    • 스프링은 이를 편하고 쉽게 사용할 수 있게 도와줌
  • 기술적인 복잡함을 해결하는 문제나 기술적인 복잡함이 비즈니스 로직에 침범하지 못하도록 분리하는 경우에도 DI가 바탕이 된 여러 가지 기법이 활용
  • 비즈니스 로직 자체의 복잡함을 해결하려면 DI보다는 객체지향 설계 기법이 더 중요
  • 스프링은 비즈니스 로직 자체를 기술적인 코드와 특정 기술의 스펙이 침범하지 않는데 집중
    • 순수한 비즈니스 로직만을 담고 있는 코드는 객체지향 분석과 설계에서 나온 도메인 모델을 쉽게 적용할 수 있기 때문
    • 상속, 다형성, 위임을 포함한 많은 객체지향 디자인 패턴과 설계 기법이 잘 녹아들을 수 있음
• 스프링의 기술과 전략은 객체지향이라는 자바 언어가 가진 강력한 도구를 극대화해서 사요할 수 있도록 돕는 것