토비의 스프링 - 8.2 스프링의 목적

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

• 경량급 프레임워크인 스프링을 활용해서 엔터프라이즈 개발은 편하게 하는 것임
• 굳이 스프링을 사용하는 이유는 엔터프라이즈 개발이 편하지 않고 복잡하기 때문임
• 엔터프라이즈 개발이 복잡한 이유는 크게 두 가지가 있음
  1. 기술적인 제약조건과 요구사항이 늘어가기 때문
     • 엔터프라이즈 시스템이란, 서버에서 동작하며 기업과 조직의 업무를 처리하는 시스템임
     • 엔터프라이즈 시스템은 많은 사용자의 요청을 동시에 처리해야하기 때문에 서버 자원의 효율적 배분이 필요함
     • 또한 금융, 원자력, 항공 등 미션 크리티컬한 곳에도 다뤄지기 때문에 보안성 및 안정성이 뛰어나야 함
     • 이러한 이유들 때문에 엔터프라이즈 시스템을 개발하는데 비즈니스 로직 구현 뿐만이 아니라 기술적 고려사항이 있음
     • 엔터프라이즈 시스템이 기업 업무를 처리하는데 핵심적인 역할로 등장하고 중요해지면서 기술적 요구는 심화되고 그에 따른 복잡도가 증가하고 있음
     • 때문에 개발자 개개인이 져야 할 기술적 부담은 점점 커져감
  2. 엔터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문
     • 점차 엔터프라이즈 시스템을 이용해 기업의 핵심 업무를 처리하는 비율이 늘어 엔터프라이즈 시스템에 대한 업무 의존도가 높아졌음
     • 그만큼 다양하고 복잡한 업무 처리 기능을 엔터프라이즈 시스템이 구현해야 함
     • 복잡한 업무 처리 기능이 많아져 다양한 예외 상황 및 처리 규모도 상당함

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

• 전통적 자바 엔터프라이즈 개발 기법은 비즈니스 로직과 기술적인 로직이 혼재될 수 밖에 없음
• 개발자가 비즈니스 로직과 기술적인 로직은 한 번에 신경을 써야하기 때문에 복잡함이 몇 배는 더 가중됨
• 요구되는 비즈니스 로직과 필요한 기술적 로직은 삭제시킬 수 없음
• 즉, 엔터프라이즈의 근본적인 복잡함의 원인은 제거할 수 없음
• 다만 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요함
• 가장먼저 할 일은 비즈니스 로직과 기술적인 로직 이 두 가지 복잡함을 분리하는 것임

8.2.3 실패한 해결책 : EJB

• EJB의 기본 전략도 이 두 가지 복잡함을 분리하는 것임
• EJB는 기술적인 복잡함을 애플리케이션 핵심 로직인 비즈니스 로직에서 일부분 분리하는데 성공했음
• 하지만, 특정 인터페이스 구현 및 상속을 해야하고 서버에 종속적인 서비스를 통해서만 접근을 해야 함
• 애플리케이션 핵심 로직에서 기술적인 코드가 제거되었지만, 오히려 EJB라는 환경과 스펙에 종속되는 코드로 만들어야 하는 부담이 생김
• EJB 틀 안에서 자바 코드를 만들게 강제함으로써 자바 언어가 원래 갖고 있던 장점마저 잃어버림
• 또한, EJB의 발전주기가 너무 느려 엔터프라이즈 개발 기술의 발전을 따라잡지 못함

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

• 스프링은 EJB의 실패를 교훈으로 삼아서 출발했음
• EJB의 처음 목표와 마찬가지로 기술적인 복잡함을 애플리케이션 핵심 로직의 복잡함에서 제거하는데 목표를 뒀음
• EJB처럼 어떤 기술을 적용했을 때 그 기술과 관련 코드나 규약등이 코드에 등작하는 것을 침투적 기술이라 함
• 물론 꼭 필요한 기능을 사용해야 하기 때문에 특정 기술의 API를 이용하는것 어쩔 수 없음
• 반면에 비침투적 기술은 기술의 적용 사실이 코드에 직접 반영되지 않는다는 특징이 있음
• 또한, 코드의 설계와 구현 방식을 제한하지 않음
• 스프링은 비침투적 기술을 사용해 성공할 수 있었음
• 스프링을 적용한다고 해서 근본적인 복잡함의 원인이 사라지지는 않지만, 성격이 다른 복잡함들을 깔끔하게 분리했기 때문에 각각을 효과적으로 상대할 수 있는 기반이 됐음

8.2.5 기술적 복잡함을 상대하는 스프링의 전략

• 스프링의 기본적인 전략은 비즈니스 로직을 담은 애플리케이션 코드와 엔터프라이즈 기술을 처리하는 기술적 로직을 분리하는 것임
• 스프링은 기술적 로직의 문제를 두 가지로 분류해 적절한 대응 방법을 제공함
  1. 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적임
     • 환경, 서버, 조건이 바뀌면 적용하는 기술이 달라지고 그에 따른 코드가 변경되는 것은 심각한 문제임
     • 코드를 일일이 변경하는 것은 매우 번거로움
     • 스프링의 일관성 없는 기술과 특정 기술에 종속적인 코드의 공략 방법은 서비스 추상화임
     • 예시
       1. 트랜잭션 추상화
       2. OXM 추상화
       3. 데이터 액세스에 관한 일관된 예외변환 가능
       4. 데이터 액세스 기술에 독립적으로 적용가능한 트랜잭션 동기화 기법
     • 기술적인 복잡함은 일단 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 독립적인 접근 인터페이스를 제공하는 것이 가장 좋은 해결책임
     • 또한, 자바 메일과 같이 테스트를 어렵게 만드는 기술에도 서비스 추상화를 적용할 필요가 있음
     • 테스트 편의성 증가 및 기술에 대한 세부 설정과 변경으로 부터 독립적인 코드를 만들 수 있음
     • 반복적인 작업 흐름과 특정 기술이 발생하는 예외에 종속적인 코드를 해결할 수 있음
  2. 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장함
     • 비즈니스 로직 전후로 경계가 설정되는 트랜잭션, 보안, 데이터와 예외의 일관 변환, 로깅 등이 대표적인 예시임
     • 의존적인 인터페이스나 예외처리 등을 최대한 제거한다 해도, 근본적 엔터프라이즈 서비스를 적용하는 한 비즈니로 로직 전후로 나타나는 문제를 쉽게 해결할 수 없음
     • 스프링이 기술과 비즈니스 로직의 혼재로 발생하는 복잡성의 문제를 AOP로 해결함
     • AOP는 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드르 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술임
     💡 AOP는 부가기능과 타깃이 같은 인터페이스를 구현하고, 위임을 통해 복잡성 문제를 해결함[6장 참고]

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

• 사용자 인터페이스와 같은 기술적인 문제의 오류시 발생하는 문제는 크지 않음
• 하지만, 애플리케이션의 핵심 로직인 비즈니스 로직 오류시 큰 문제가 발생할 수 있음
• 예를 들어, 계좌 송금과 같은 미션 크리티컬한 문제인 비즈니스 로직 오류는 크나큰 손실을 야기할 수 있음
• 과거 비즈니스 로직의 중요함 때문에, 비즈니스 로직의 상당 부분을 DB에 두는 것이 유행이었음
• SQL을 통해 비즈니스 로직을 표현함
• 하지만, 엔터프라이즈의 규모가 커지고 복잡성이 증대되면서 DB에 비즈니스 로직을 두는것은 불편 및 위험함
• 현재 개발 흐름은 비즈니스 로직을 애플리케이션 안에서 처리하는 방향으로 흘러가고 있음
• 기술과 비즈니스 로직의 복잡함을 해결하는데 스프링이 공통적으로 사용하는 도구 가 바로 객체지향임
• 스프링은 객체지향에 충실하도록 구조를 만들기 위해 DI 같은 기술을 편하게 적용할 수 있게 함
• 서비스 추상화, 템플릿/콜백, AOP와 같은 스프링의 기술은 DI 없이 존재할 수 없음
• DI는 자연스럽게 객체지향적인 설계와 개발로 이끌어주는 좋은 동반자임
• 변화되는 부분에 인터페이스르 도입하고, DI로 관계를 연결해 주는 구조를 갖게 되면 발빠른 요구사항 변화에 대응할 수 있음