[Spring] Spring 생태계에 대한 개요

이 포스트는 글또 10기 내 독서 모임에 참여하여 읽기 시작한 '스프링 교과서'를 읽고 정리한 내용을 바탕으로 작성했습니다.

 

 

Spring 생태계

생태계? 다소 용어다. 그동안 내가 알았던 것은 Spring과 Spring Boot의 차이였을 뿐, build.gradle에 import 되는 수많은 라이브러리를 직접 뜯어보고 분석할 생각까지는 하지 못했다. 1장을 읽으면서 이 내용을 알 수 있었다: "Spring은 여러 프레임워크가 얽혀 있다."

 

책에서 소개한 대표적인 프레임워크는 아래 4개였고, Spring Core라는 태양을 중심으로 나머지 3개가 행성처럼 주위를 돌고 있다고 표현했다.

 

1. Spring Core

Foremost amongst these is the Spring Framework’s Inversion of Control (IoC) container. A thorough treatment of the Spring Framework’s IoC container is closely followed by comprehensive coverage of Spring’s Aspect-Oriented Programming (AOP) technologies. The Spring Framework has its own AOP framework, which is conceptually easy to understand and which successfully addresses the 80% sweet spot of AOP requirements in Java enterprise programming.

Coverage of Spring’s integration with AspectJ (currently the richest — in terms of features — and certainly most mature AOP implementation in the Java enterprise space) is also provided.

AOT processing can be used to optimize your application ahead-of-time. It is typically used for native image deployment using GraalVM.

(출처: https://docs.spring.io/spring-framework/reference/core.html)

 

Spring Framework의 핵심이 되는 부분으로, '제어 역전(IoC)'과 '의존성 주입(DI)'를 지원한다. 참고로 공식 문서의 설명에 등장하는 표현인 'IoC Container'가 바로 Spring 컨테이너다. Spring Core는 Spring Context와 Spring Aspect, SpEL(Spring 표현 언어) 등이 포함한다. 이 3개를 간단하게 정리하면 아래와 같다.

• Spring Context: Spring이 앱의 인스턴스를 관리할 수 있게 하는 Spring Framework의 기본 기능
• Spring Aspect: Spring이 앱에서 정의한 메서드를 가로채고 조작할 수 있음
• SpEL: 특정 언어를 사용하여 Spring 구성 내용을 작성할 수 있음

Spring은 제어 역전(IoC) 원칙을 기반으로 작동한다. 이것이 무슨 뜻일까? 일단 책의 표현을 빌리자면, '앱이 실행을 제어하는 대신 Spring Framework에 제어 권한을 넘기는 것'이다. 이를 위해 Configuration을 이용하여 앱 로직을 정의하도록 작성된 코드 관리 방법을 프레임워크에서 지시한다.

 

여기까지 읽고 '이게 대체 무슨 뜻이지?' 싶었지만 다행히 '제어 역전(IoC)'에 대한 더 자세한 설명이 있어 정리했다.

 

'제어'란 '인스턴스 생성'이나 '메서드 호출' 같은 작업을 의미한다. 즉, 프레임워크는 앱에서 정의한 클래스의 객체를 생성할 수 있다. 그리고 우리가 작성한 Configuration을 기반으로 Spring은 메서드를 가로채서 다양한 기능으로 보강한다. 아! 그렇다면 '역전'은 무슨 뜻일까?

 

'역전'은 앱이 자체 코드의 실행을 제어하거나 의존성을 사용하지 못하는 대신 프레임워크(의존성)가 앱과 앱의 코드를 제어한다는 의미이다. 위 내용들을 그림으로 표현하면 아래와 같다.

 

IoC를 사용하지 않을 때(왼쪽), IoC를 사용할 때(오른쪽)

 

또, IoC 컨테이너(= Spring 컨테이너)는 애플리케이션의 Spring 구성 요소와 애플리케이션의 구성 요소를 프레임워크에 결합한다. 또, Spring 컨테이너는 BeanFactory와 ApplicationContext로 나눌 수 있다.

 

Spring 컨테이너가 Bean을 관리하는 방법 (출처: https://www.geeksforgeeks.org/spring-ioc-container/)

 

이때 주로 쓰이는 컨테이너가 바로 Spring Context다. Spring Context는 특정 객체를 Spring에 전달해서 프레임워크가 구성한 방식으로 객체를 사용할 수 있게 한다. (이때, Spring Context에 추가되는 인스턴스를 Bean이라고 한다.)

 

따라서, Spring은 IoC 컨테이너에 추가된 인스턴스를 제어할 수 있으며, 인스턴스의 동작인 메서드를 가로챌 수 있다. 이 기능을 Method Aspecting이라고 하며, Spring AOP는 프레임워크가 앱과 상호 작용하는 일반적인 방법 중 하나이다.

 

2. Spring MVC

Spring Web MVC is the original web framework built on the Servlet API and has been included in the Spring Framework from the very beginning. The formal name, "Spring Web MVC," comes from the name of its source module (spring-webmvc), but it is more commonly known as "Spring MVC".

Parallel to Spring Web MVC, Spring Framework 5.0 introduced a reactive-stack web framework whose name, "Spring WebFlux," is also based on its source module (spring-webflux).

(출처: https://docs.spring.io/spring-framework/reference/web/webmvc.html)

 

HTTP 요청을 처리하는 웹 애플리케이션을 개발할 수 있게 하는 Spring Framework의 일부분으로, Servlet API를 기반으로 작성되었다고 한다. 여기서 말하는 MVC는 Model, View, Controller의 그 MVC가 맞다.

 

3. Spring Data Access

This part of the reference documentation is concerned with data access and the interaction between the data access layer and the business or service layer.

Spring’s comprehensive transaction management support is covered in some detail, followed by thorough coverage of the various data access frameworks and technologies with which the Spring Framework integrates.

(출처: https://docs.spring.io/spring-framework/reference/data-access.html)

 

데이터베이스에 연결하여 앱 영속성 계층을 구현하는 데 사용할 수 있는 기본 도구를 제공한다. 즉, 데이터 영속성을 관리하는 데 사용되는 모듈이다. 내가 그동안 많이 사용했던 JDBC, Hibernate와 같은 ORM Framework 등이 여기에 포함된다.

 

더 찾아보니, 데이터베이스와의 연결 설정, 트랜잭션 처리, 예외 처리 등도 간소화하여 개발자가 비즈니스 로직에 집중할 수 있도록 도와준다고 한다.

 

4. Spring Testing

This chapter covers Spring’s support for integration testing and best practices for unit testing. The Spring team advocates test-driven development (TDD). The Spring team has found that the correct use of inversion of control (IoC) certainly does make both unit and integration testing easier (in that the presence of setter methods and appropriate constructors on classes makes them easier to wire together in a test without having to set up service locator registries and similar structures).

(출처: https://docs.spring.io/spring-framework/reference/testing.html)

 

Spring 애플리케이션 테스트를 작성하는 데 필요한 도구를 담고 있으며, 단위 및 통합 테스트 모두를 포함한다. 그리고 공식 문서의 설명에서 흥미로운 내용을 발견할 수 있었는데, 'setter들과 적절한 생성자들의 존재로 IoC를 정확하게 사용하면 테스트를 더 편리하게 할 수 있다'이다. (이게 무슨 의미인지는 이 책 15장까지 가봐야 정확히 알 것 같다...)

 

크게 이렇게 4개를 언급한 후, Spring Data, Spring Security, Spring Cloud, Spring Batch, Spring Boot 같은 Spring 생태계 안의 다른 프로젝트에 대해서도 언급했다. 이 중에서도 강조된 2개의 프로젝트는 Spring Data와 Spring Boot였다.

 

Framework란? 장점은?

책에서는 Spring 생태계를 설명하기에 앞서 'Framework'에 대한 내용을 언급하고 넘어갔는데, 이에 대해서도 정리했다.

 

'Framework'란, 애플리케이션을 개발하는 기본 구조를 제공하는 공통 소프트웨어 기능의 집합으로, 좀 더 수월하게 애플리케이션을 구현하게 한다. 다시 말해, 애플리케이션을 구축하는 기능의 집합으로, 앱을 구축하는 데 사용할 수 있는 광범위한 도구와 기능(혹은 다양한 소프트웨어)을 제공한다.

 

이를 사용해서 얻는 장점은, 필요한 부분의 재사용으로 인한 시간과 비용의 절약할 수 있고, 버그의 위험성이 Framework를 사용하지 않고 직접 구현하는 방법에 비해 상대적으로 낮고, 공통부분이 많아 더 많은 사람과 커뮤니티 혜택을 공유할 수 있다는 것이다.

 

여기서 재사용되는 부분은 비즈니스 로직 코드보다는 트랜잭션, 보안, 로깅, 데이터 영속성, 데이터 전송, 캐싱 등이다. (이렇게 보니 AOP를 이용할 수 있는 부분과 많이 겹치는 것 같다.) 그렇다면 모든 무조건 프레임워크를 사용하는 것이 좋을까? 답은 '아니다'이다.

 

Framework를 사용하지 않아야 하는 상황

책에서는 Framework를 사용하는 것이 오히려 안 좋은 상황을 아래와 같이 설명했다.

 

1. 애플리케이션의 크기를 작게 만들어야 하는 상황

2. 강력한 보안이 요구되는 상황

3. 과도한 Customization 작업이 필요해 오히려 코드 양이 늘어나는 상황

4. Framework 도입 후 이점이 없는 상황

 

나머지는 이미 알고 있던 내용이었지만, 1번에 대해서는 마침 Docker를 공부하고 있기 때문에 새롭게 생각해 볼 수 있는 기회가 되었다.

 

후기

1장에서는 이전까지 한 번도 생각해 보지 않았던 Spring 생태계에 대해 이해하려고 노력했다. 특히, 어떤 프로젝트가 어떤 이유로 어디에 쓰이는지를 파악하려고 했으나... 아직은 잘 모르겠다. 다만 바로 뒷장부터 이어서 각 프로젝트에 대한 설명이 코드와 함께 이어지기 때문에 얼른 공부하러 가야겠다!