[스프링 교과서] 1장 현실 세계의 스프링

마이크로서비스 아키텍처로 진화

애플리케이션 프레임워크

• 우리가 애플리케이션을 구축하는 기능의 집합으로, 앱을 구축하는데 사용할 수 있는 광범위한 도구와 기능을 제공한다. 
• 프레임워크가 제공하는 모든 기능을 사용할 필요는 없으며, 만들려는 앱이 요구하는 사항에 따라 사용할 프레임워크 부분을 적절히 선택하면 된다(올바른 결과를 얻기 위해 어떤 기능을 선택하고 어떻게 조립해야 할지 알아야 한다).

 

유사한 요구사항

• 로깅 오류, 경고(warning), 정보(info) 메시지는 모든 앱에서 발생한다.
• 대부분의 애플리케이션은 트랜잭션을 사용하여 데이터 변경을 처리한다. 트랜잭션은 데이터 일관성을 관리하는 중요한 메커니즘을 나타낸다.(13장)
• 애플리케이션 대부분은 공통으로 발생하는 동일한 취약점에 보호 메커니즘을 사용한다.
• 애플리케이션 대부분은 유사한 방법으로 상호 통신한다.
• 애플리케이션 대부분은 캐싱 또는 데이터 압축처럼 성능을 향상하는 데 유사한 메커니즘을 사용한다.

 

앱에서 구현된 비즈니스 로직의 코드양은 애플리케이션 엔진을 구성하는 휠과 벨트보다 훨씬 작다.

 

비즈니스 로직 코드

• 애플리케이션의 비즈니스 요구 사항을 구현하는 코드
• 애플리케이션에서 사용자가 기대한 것을 구현한다.
• 기능적 관점에서 애플리케이션을 다른 애플리케이션과 구분 짓게 만드는 요소이다.

 

---

스프링 생태계

소프트웨어 기능 일부분

1. 스프링 코어(Spring Core)
   • 기본 기능을 포함하는 스프링의 기반 부분 중 하나
   • 스프링 컨텍스트 : 스프링이 앱의 인스턴스를 관리할 수 있게 하는 스프링 프레임워크의 기본 기능
   • 스프링 애스펙트(aspect) : 스플깅이 앱에서 정의한 메서드를 가로채고 조작할 수 있다.(6장)
   • 스프링 표현 언어(SpEL) : 특정 언어를 사용하여 스프링 구성 내용을 작성할 수 있다.
2. 스프링 모델-뷰-컨트롤러(MVC)
   • HTTP 요청을 처리하는 웹 애플리케이션을 개발할 수 있게 하는  스프링 프레임워크 일부분
3. 스프링 데이터 액세스(Spring Data Access)
   • SQL 데이터베이스에 연결하여 앱 영속성 계층을 구현하는 데 사용할 수 있는 기본 도구 제공(13장)
4. 스프링 테스팅
   • 스프링 애플리케이션 테스트를 작성하는 데 필요한 도구를 담고 있다.(15장)

 

스프링 코어의 이해: 스프링 기초

스프링 코어는 앱에 통합되는 기본 메커니즘을 제공하는 스프링 프레임워크 일부분이다.

 

스프링은 제어 역전(Inversion of Control, IoC) 원칙을 기반으로 작동한다. 이 원칙을 사용하면 앱이 실행을 제어하는 대신 다른 소프트웨어 부분(여기에서는 스프링 프레임워크)에 제어 권한을 넘긴다. 

• 역전 : 앱이 자체 코드로 실행을 제어하거나 의존성을 사용하지 못하는 대신 프레임워크(의존성)가 앱과 앱의 코드를 제어한다는 의미
• 제어 : '인스턴스 생성' 또는 '메서드 호출'같은 작업을 나타낸다.
  • 스프링은 특정 메서드를 가로채서 메서드 실행 중에 나타날 수 있는 오류를 기록할 수 있다.

• IoC 사용X : 애플리케이션이 필요한 의존성을 실행하고 제어(사용)한다.
• IoC 사용 : 애플리케이션은 프레임워크(의존성)로 제어되어 실행한다.

 

IoC 컨테이너는 애플리케이션의 스프링 구성 요소와 애플리케이션의 구성 요소를 프레임워크에 결합한다. 종종 스프링 컨텍스트라고하는 IoC 컨테이너를 사용하여 특정 객체를 스프링에 전달해서 프레임워크가 구성한 방식으로 객체를 사용할 수 있게 한다.

 

스프링은 IoC 컨테이너에 추가된 인스턴스를 제어할 수 있으며, 가능한 작업 중 하나는 이 인스턴스의 동작인 메서드를 가로채는 것이다. 이 기능을 메서드 에스펙팅(aspecting the method)라고 한다.

 

 

스프링 데이터 액세스 기능을 사용한 앱 영속성 구현

애플리케이션 대부분에서는 처리하는 데이터를 유지하는 것이 중요하다. 

스프링에서는 많은 경우에 데이터 영속성을 관리하는 데 데이터 액세스(Data Access) 모듈을 사용한다. 스프링 데이터 액세스에는 JDBC 사용, 하이버네이트(Hibernate)와 같은 객체 관계형 매핑(ORM) 프레임워크와 통합, 트랜잭션 관리가 포함된다.

 

 

 

스프링 부트

구성보다 관례 개념을 도입한 스프링 생태계의 프로젝트 중 하나이다.

 

이 개념의 주요 사상은 프레임워크의 모든 구성을 사용자가 직접 설정하는 대신 스프링 부트가 필요에 따라 정의할 수 있는 기본 구성을 제공하는 것이다.  → 알려진 규칙을 따르고 앱은 서로 차이가 크지 않아 코드를 덜 작성하게 된다.

 

---

실제 시나리오에서 스프링

백엔드 앱 개발에서 스프링 사용

백엔드 애플리케이션은 시스템의 한 부분으로, 서버 측에서 실행되고 데이터를 관리하며 클라이언트 애플리케이션 요청을 처리한다.

 

클라이언트 앱은 백엔드 앱에 사용자 데이터 작업을 요청한다. 백엔드 앱은 데이터베이스를 사용하여 데이터를 저장하거나 다른 방식으로 다른 백엔드 앱과 통신할 수 있다.

 

사용자의 트랙잭션을 관리하려면 백엔드 애플리케이션은 다른 백엔드 솔루션과 통신해야하고, 관리하는 일부 데이터는 데이터베이스에 유지해야한다. 

 

 

 

자동화 테스트 앱에서 스프링 사용

자동화 테스트는 개발 팀에서 애플리케이션이 예상대로 작동하는지 확인하는 데 사용하는 소프트웨어 구현체를 말한다. 소규모 팀에서는 수동으로 테스트할 수 있지만, 언제나 테스트 케이스를 자동화하는 것이 더 낫다.

 

앱은 스프링 IoC 컨테이너를 사용하여 코드를 보다 쉽게 유지 관리할 수 있도록 객체 인스턴스를 관리할 수 있다. 스프링 데이터를 사용하면 데이터 유효성을 검사해야 하는 데이터베이스에 연결할 수도 있다.  또 특정 시나리오를 시뮬레이션하거나 단순히 스프링을 사용하여 일부 REST 엔드포인트를 호출하고자 브로커 시스템의 큐나 토픽에 문자를 보낼 수도 있다.

 

 

데스크톱 앱 개발에서 스프링 사용

데스크톱 앱은 스프링 IoC 컨테이너를 효과적으로 사용하여 객체 인스턴스를 관리할 수 있다. 이렇게 하면 앱 구현이 더 깔끔해지고 유지 보수성도 향상된다. 또 앱은 스프링 도구나 백엔드나 다른 구성 요소와 통신하거나 캐싱을 구현하는 등 다양한 기능을 구현할 수 있다.

 

 

---

프레임워크를 사용하지 말아야 할 때 

프레임워크를 사용해야 할 때와 사용하지 말아야 할 때를 아는 것은 중요하다. 작업에 너무 많은 도구를 사용하면 때로는 더 노력하고도 더 나쁜 결과를 얻을 수 있다.

 

작게 만들어야 한다.

가능한 한 작은 공간에 특정 기능을 구현해야 한다. 이때 공간(footprint)은 앱의 파일들이 차지하는 저장소 메모리를 의미한다.

 

오늘날 많은 시스템에서는 서비스를 컨테이너로 제공하고 있다. 컨테이너는 애플리케이션을 포함하는 작은 상자와 같아서 애플리케이션을 작고 가볍게 만들 수 있다. 중요한 점은 컨테이너를 쉽게 폐기하고 재생성할 수 있어야 한다는 것이다. 즉, 앱의 크기를 줄여 초기화 시간을 단축해야 한다.

 

그렇다고 컨테이너로 배포된 모든 앱에 프레임워크를 사용하지 않는다는 것은 아니다. 그러나 일반적으로 크기가 매우 작은 앱의 경우, 프레임워크를 추가하는 것보다 초기화를 개선하고 앱을 더 작게 만드는 것이 더 좋다.

 

서버리스 함수는 이런 작은 애플리케이션의 좋은 예이다. 서버리스 함수는 컨테이너에 배포되며, 마치 서버 없이 실행되는 것처럼 보인다. 이 앱들은 크기가 작아야 하므로, 프레임워크를 추가하지 않는 것이 좋다.

 

 

 

 

보안에는 맞춤형 코드가 필요하다.

특정 보안 요구 사항으로 오픈 소스 프레임워크를 사용하지 않고 앱에서 맞춤형 코드를 구현해야 한다.

 

누군가가 특정 취약점을 발견하고 알렸을 때, 해커는 이 사실을 악용할 수 있게 된다. 따라서 제삼자 소스를 사용하는 대신 기능을 다시 만들어야할 수도 있다.

 

 

 

기존의 과도한 맞춤화로 프레임워크가 실용적이지 못하다.

프레임워크에서 과도한 맞춤화 작업이 필요해서 사용하지 않을 때보다 더 많은 코드를 작성해야 한다.

 

프레임워크는 앱을 실현하기 위해 비즈니스 코드로 조합하는 부분을 제공한다. 프레임워크에서 제공하는 이런 구성 요소는 꼭 들어맞지는 않기에 다양한 방식으로 맞춤화해야 한다. 기능을 처음부터 개발하기보다 프레임워크의 구성 요소와 조합 방식을 맞춤화하는 것이 정상적이다. 그러나 앞서 언급한 과도한 맞춤화 상황에 처했다면 부적합한 프레임워크를 선택했거나 아예 사용하지 말았어야 한다.

 

 

 

 

프레임워크로 바꾸어도 이점이 없다.

이미 해당 기능을 제공하는 앱이 있고 프레임워크를 사용하도록 변경해도 아무런 이점을 얻을 수 없다.

 

 

 

 

 

 

---

잡담

이 책은 메이븐을 사용해서 하던데 난 gradle만 사용해봤다. 2장을 들어가기 전에 둘의 차이점부터 공부해야겠다.