1 - 스프링 생태계

스프링의 중심은 웹·DB 기능의 모음이 아니라 애플리케이션 객체를 생성하고 연결하고 관리하는 IoC 컨테이너입니다.

시작하며

처음 스프링을 배울 때는 @Controller, @Service, @Repository 같은 애너테이션이나 REST API를 만드는 방법부터 보게 됩니다. 그러다 보면 스프링을 “백엔드 개발에 필요한 라이브러리를 모아 놓은 프레임워크” 정도로 이해하기 쉽습니다.

 

하지만 MVC, 데이터 접근, 테스트 지원을 하나로 이어 주는 중심에는 스프링 코어와 IoC 컨테이너가 있습니다. 스프링을 이해한다는 것은 기능 목록을 외우는 것보다 누가 객체를 만들고, 누가 의존성을 연결하며, 누가 객체의 수명주기를 관리하는가를 이해하는 데서 시작합니다.

스프링 생태계를 하나의 구조로 보기

 

스프링 프레임워크는 필요한 영역을 선택해서 사용할 수 있는 모듈 구조입니다. 그 중심에는 구성 모델과 의존성 주입을 제공하는 코어 컨테이너가 있고, 그 위에 웹, 데이터 접근, 테스트 같은 기능이 연결됩니다.

Spring Core

스프링의 기반입니다. 특히 ApplicationContext로 대표되는 IoC 컨테이너가 객체를 생성하고 구성하고 조립합니다. 스프링이 관리하는 객체를 Bean이라고 부릅니다.

 

코어 영역에는 다음 개념도 포함됩니다.

• Spring Context: Bean과 의존 관계, 설정과 생명주기를 관리합니다.
• Spring AOP: 프록시 등을 이용해 로깅, 트랜잭션 같은 횡단 관심사를 메서드 실행 전후에 적용합니다.
• SpEL: 설정과 런타임 객체를 표현식으로 조회하거나 계산할 수 있는 표현 언어입니다.

IoC와 AOP를 같은 뜻으로 보면 안 됩니다. IoC는 객체 생성과 의존성 제어의 방향을 바꾸는 원리이고, AOP는 여러 기능에 반복되는 부가 로직을 분리하는 방법입니다.

Spring MVC

Servlet 기반 웹 애플리케이션을 만들기 위한 모듈입니다. HTTP 요청을 Controller에 연결하고, 요청 값을 객체로 변환하며, 검증 결과나 반환 값을 HTTP 응답으로 만드는 흐름을 지원합니다.

 

MVC가 요청을 받아도 실제 비즈니스 로직을 담당하는 Service와 데이터 접근 객체는 IoC 컨테이너가 조립한 Bean인 경우가 많습니다. 웹 계층도 코어 컨테이너와 따로 떨어져 있지 않습니다.

Data Access

JDBC, 트랜잭션, ORM 연동처럼 영속성 계층을 구현할 때 반복되는 기반 작업을 지원합니다. 예외 변환과 선언적 트랜잭션을 사용하면 비즈니스 코드가 연결 관리나 커밋·롤백 같은 세부 구현에 덜 묶이게 할 수 있습니다.

 

여기서 Spring Framework의 데이터 액세스 지원과 별도 프로젝트인 Spring Data를 구분할 필요가 있습니다. 둘은 관련되어 있지만 같은 범위를 뜻하지 않습니다.

Testing

단위 테스트 자체는 스프링 없이도 작성할 수 있습니다. 오히려 생성자 주입을 잘 사용한 객체는 컨테이너 없이 직접 생성해서 테스트하기 쉽습니다.

 

스프링은 여기에 TestContext Framework, MockMvc 같은 통합 테스트 도구를 제공합니다. 애플리케이션 컨텍스트 구성, 트랜잭션 테스트, MVC 요청 매핑 등을 실제 스프링 동작과 가깝게 검증할 수 있습니다.

IoC는 무엇이 뒤집힌 것일까

IoC는 Inversion of Control, 제어의 역전을 뜻합니다. 이름만 보면 애플리케이션의 모든 제어권을 프레임워크가 빼앗는 것처럼 들립니다. 실제로 뒤집히는 핵심은 객체가 자신의 의존성을 직접 만들고 찾던 책임입니다.

스프링이 없다면 OrderService가 자신에게 필요한 구현체를 직접 생성할 수 있습니다.

class OrderService {
    private final PaymentClient paymentClient = new HttpPaymentClient();
}

 

이 코드는 간단하지만 OrderService가 HttpPaymentClient라는 구체 구현의 생성 방법까지 알고 있습니다. 구현을 바꾸거나 테스트 대역을 사용하려면 서비스 코드를 수정해야 합니다.

의존성을 외부에서 받도록 바꾸면 객체의 책임이 달라집니다.

class OrderService {
    private final PaymentClient paymentClient;

    OrderService(PaymentClient paymentClient) {
        this.paymentClient = paymentClient;
    }
}

 

이제 OrderService는 결제 기능을 사용한다는 사실만 알면 됩니다. 어떤 구현체를 만들고 전달할지는 외부 조립자가 결정합니다. 스프링에서는 IoC 컨테이너가 설정 정보를 읽고 이 역할을 맡습니다.

@Configuration
class PaymentConfig {

    @Bean
    PaymentClient paymentClient() {
        return new HttpPaymentClient();
    }

    @Bean
    OrderService orderService(PaymentClient paymentClient) {
        return new OrderService(paymentClient);
    }
}

 

제어의 방향은 다음처럼 바뀝니다.

직접 제어
OrderService → 구현체 선택 → 객체 생성

IoC 적용
설정 정보 → Spring Container → 객체 생성과 의존성 연결 → OrderService

IoC와 DI의 관계

IoC는 더 넓은 설계 원리이고 DI, Dependency Injection은 이를 구현하는 대표적인 방법입니다.

• IoC: 객체 생성과 연결을 누가 제어하는가에 관한 원리
• DI: 객체가 필요한 의존성을 외부에서 전달받도록 만드는 방법
• Spring Container: 설정을 읽어 Bean을 생성하고 DI를 수행하는 실행 주체

Spring 공식 문서는 DI를 IoC의 특수한 형태로 설명합니다. 객체는 생성자, 팩터리 메서드의 인자 또는 프로퍼티를 통해 필요한 의존성을 선언하고, 컨테이너가 Bean을 만들 때 이를 주입합니다.

스프링이 관리하는 객체는 무엇이 달라질까

스프링 Bean도 본질적으로는 평범한 자바 객체입니다. 차이는 생성된 이후에 생기는 특별한 능력이 아니라, 객체의 생성과 조립 과정에 컨테이너가 참여한다는 데 있습니다.

 

컨테이너는 설정에 따라 다음을 관리할 수 있습니다.

• 객체 생성 방식
• 다른 Bean과의 의존 관계
• Singleton, Prototype 같은 Scope
• 초기화와 소멸 Callback
• AOP Proxy와 후처리기 적용

그렇다고 모든 객체를 Bean으로 만들어야 하는 것은 아닙니다. 값 객체나 메서드 내부에서 잠깐 사용하는 객체까지 컨테이너에 맡기면 오히려 구조가 복잡해집니다. 애플리케이션의 주요 협력 객체와 인프라 의존성을 중심으로 관리하는 것이 자연스럽습니다.

IoC가 실무에서 주는 이점

구현을 교체하기 쉬워진다

서비스가 구체 클래스의 생성 방법을 모르면 운영용 구현과 테스트용 구현을 외부에서 바꿔 끼울 수 있습니다.

테스트하기 쉬워진다

생성자 인자로 가짜 구현을 전달할 수 있으므로 단위 테스트에서 전체 Spring Context를 띄우지 않아도 됩니다.

공통 정책을 적용할 지점이 생긴다

컨테이너가 객체 생성 과정에 참여하므로 Scope, Lifecycle, AOP 같은 공통 정책을 일관되게 적용할 수 있습니다.

애플리케이션 조립과 비즈니스 로직을 분리한다

비즈니스 객체는 무엇을 할지에 집중하고, 어떤 구현을 사용해 전체 애플리케이션을 구성할지는 설정이 담당합니다.

결론

스프링의 MVC, 데이터 액세스, 테스팅 기능을 따로 외우면 스프링이 거대한 도구 상자처럼 보입니다. 하지만 중심에는 IoC 컨테이너가 있습니다.

 

객체가 필요한 의존성을 직접 만들고 찾지 않게 하고, 컨테이너가 설정을 바탕으로 객체를 생성하고 연결하게 만드는 것.

 

이 관점이 잡히면 이후에 배우는 Bean 등록, Component Scan, 생성자 주입, Scope, AOP와 트랜잭션도 서로 떨어진 기능이 아니라 컨테이너가 객체를 관리하기 때문에 가능한 기능으로 연결됩니다.

핵심 원리

1. 스프링 생태계의 중심에는 Core Container가 있습니다.
2. IoC는 객체 생성과 의존성 조립 책임의 방향을 바꿉니다.
3. DI는 객체가 의존성을 외부에서 전달받게 하는 IoC의 구현 방식입니다.
4. Bean은 Spring Container가 관리하는 평범한 객체입니다.
5. 컨테이너가 객체 생성에 참여하므로 Scope, Lifecycle과 AOP 같은 정책을 적용할 수 있습니다.

출처

• Spring Framework Overview
• Introduction to the Spring IoC Container and Beans
• Dependency Injection
• Spring Testing