2025-09-20 22:11

스프링 프레임워크는 과거 자바(J2EE) 개발의 복잡성을 해결하기 위해 등장한 경량 솔루션이다.
의존성 주입(DI)과 관점 지향 프로그래밍(AOP)을 핵심 철학으로 삼아, 객체 간 결합도를 낮추고 코드의 재사용성을 극대화한다.
현대 개발에서는 스프링 부트(Spring Boot)를 통해 복잡한 설정 없이 빠르고 간편하게 애플리케이션을 구축하는 것이 표준이다.

스프링 프레임워크 A to Z 완벽 핸드북

자바(Java)로 서버 애플리케이션을 개발한다면 ‘스프링(Spring)‘이라는 이름은 피할 수 없는 산과 같습니다. 누군가에게는 처음 넘어야 할 거대한 장벽처럼 느껴지고, 다른 누군가에게는 든든한 베이스캠프가 되어주기도 합니다. 스프링은 오늘날 자바 생태계를 지배하는 가장 강력하고 대중적인 프레임워크입니다.

이번 핸드북에서는 스프링 프레임워크가 왜 만들어졌는지, 어떤 철학을 가지고 있는지, 그리고 어떻게 사용해야 하는지에 대해 A부터 Z까지 상세하게 다루어 보겠습니다. 이 글을 끝까지 읽는다면 스프링이라는 거대한 산의 지도를 손에 넣게 될 것입니다.

1. 스프링의 탄생 배경 J2EE의 겨울

스프링을 이해하려면 먼저 스프링이 등장하기 전, ‘J2EE(Java 2 Platform, Enterprise Edition)’ 시대의 풍경을 알아야 합니다. 2000년대 초반, 자바로 기업용 애플리케이션을 만드는 표준 기술은 J2EE였고, 그 중심에는 EJB(Enterprise JavaBeans)가 있었습니다.

EJB는 분산 트랜잭션, 보안, 원격 호출 등 기업 환경에 필요한 고급 기능들을 제공했지만, 몇 가지 치명적인 문제점을 안고 있었습니다.

극도의 복잡성: EJB를 사용하려면 수많은 XML 설정 파일과 인터페이스를 작성해야 했습니다. 간단한 “Hello, World!”를 출력하는 데도 엄청난 양의 코드가 필요했습니다.
무거운 프레임워크: EJB는 EJB 컨테이너라는 특수한 환경에서만 동작했습니다. 이 컨테이너는 매우 무거워서 애플리케이션을 한번 실행하고 테스트하는 데 수 분이 걸리기 일쑤였습니다. 개발 속도는 더딜 수밖에 없었습니다.
낮은 테스트 용이성: EJB 컴포넌트는 컨테이너 없이는 테스트하기가 거의 불가능했습니다. 이는 단위 테스트를 어렵게 만들어 코드의 품질을 보장하기 힘들게 했습니다.
특정 기술에 대한 종속성: 코드가 EJB 기술에 깊이 종속되어, 순수한 자바 객체(POJO)가 가진 유연성과 객체 지향의 장점을 제대로 살리지 못했습니다.

이러한 문제들로 인해 개발자들은 극심한 피로감을 느꼈고, 생산성은 바닥을 쳤습니다. 이 시기를 **‘J2EE의 겨울’**이라고 부릅니다.

이때, 로드 존슨(Rod Johnson)이라는 개발자가 2002년 자신의 저서 *‘Expert One-on-One J2EE Design and Development’*를 통해 EJB의 문제점을 신랄하게 비판하고, EJB 없이도 충분히 훌륭한 엔터프라이즈 애플리케이션을 만들 수 있는 대안을 제시했습니다. 이 책에서 소개된 3만 줄의 코드가 바로 스프링 프레임워크의 모태가 되었습니다.

스프링은 ‘J2EE의 겨울을 끝내고 봄을 가져오겠다’는 의미를 담고 있습니다. 복잡하고 무거운 EJB를 대체하여, 더 가볍고(Lightweight), 단순하며, 유연한 개발을 가능하게 하는 것이 스프링의 탄생 목표였습니다.

2. 스프링의 핵심 철학 및 구조

스프링은 단순히 기능을 모아놓은 라이브러리가 아닙니다. 좋은 코드를 작성하도록 유도하는 강력한 철학을 기반으로 설계되었습니다. 그 중심에는 IoC/DI와 AOP라는 두 개의 기둥이 있습니다.

가. 제어의 역전 (Inversion of Control, IoC)과 의존성 주입 (Dependency Injection, DI)

이것은 스프링의 심장과도 같은 가장 핵심적인 개념입니다.

전통적인 방식에서는 객체가 자신이 사용할 다른 객체(의존성)를 직접 생성하고 관리했습니다.

// 전통적인 방식
public class Car {
    private Tire tire = new KoreaTire(); // Car 객체가 직접 Tire 객체를 생성

    public void move() {
        // ...
    }
}

위 코드에서 Car 객체는 KoreaTire라는 특정 구현체에 강하게 의존하고 있습니다. 만약 타이어를 AmericaTire로 바꾸려면 Car 클래스의 코드를 직접 수정해야 합니다. 이를 **강한 결합(Tight Coupling)**이라고 하며, 유지보수를 어렵게 만듭니다.

**제어의 역전(IoC)**은 이 제어 흐름을 뒤집는 개념입니다. 객체가 자신의 의존성을 직접 관리하는 것이 아니라, 외부의 어떤 존재(컨테이너)가 이를 관리하고 주입해주는 것입니다. 그리고 이 IoC를 구현하는 패턴이 바로 **의존성 주입(DI)**입니다.

스프링에서는 **스프링 컨테이너(IoC 컨테이너)**가 이 역할을 담당합니다.

// 스프링(DI) 방식
public class Car {
    private Tire tire;

    // 생성자를 통해 외부에서 Tire 객체를 주입받음
    public Car(Tire tire) {
        this.tire = tire;
    }

    public void move() {
        // ...
    }
}

// 스프링 설정
@Configuration
public class AppConfig {
    @Bean
    public Tire tire() {
        return new AmericaTire(); // 타이어를 바꾸고 싶으면 여기만 수정
    }

    @Bean
    public Car car() {
        return new Car(tire()); // 컨테이너가 Tire 객체를 생성해서 Car에 주입
    }
}

이제 Car는 KoreaTire나 AmericaTire 같은 구체적인 클래스를 알지 못합니다. 그저 Tire라는 인터페이스에만 의존합니다. 어떤 타이어를 장착할지는 외부의 AppConfig가 결정하고, 스프링 컨테이너가 이를 Car에 주입해줍니다.

이를 **느슨한 결합(Loose Coupling)**이라고 합니다. 자동차를 조립하는 공장에 비유할 수 있습니다. 자동차(객체)가 스스로 엔진과 타이어(의존성)를 만드는 것이 아니라, 공장(스프링 컨테이너)이 각 부품을 조달하여 완성차를 조립하는 것과 같습니다.

DI의 장점:

유연성 증가: 부품(구현체)을 쉽게 교체할 수 있습니다.
테스트 용이성: 실제 객체 대신 가짜 객체(Mock Object)를 주입하여 단위 테스트를 쉽게 작성할 수 있습니다.
코드의 재사용성 및 가독성 향상: 각 객체의 책임이 명확해지고 코드가 단순해집니다.

나. 관점 지향 프로그래밍 (Aspect-Oriented Programming, AOP)

AOP는 훌륭한 객체 지향 설계를 돕는 보조적인 기술입니다. 애플리케이션의 여러 부분에서 공통적으로 나타나는 기능들을 **‘횡단 관심사(Cross-cutting Concerns)‘**라고 부릅니다. 예를 들어 로깅, 보안, 트랜잭션 처리 등이 여기에 해당합니다.

기존 방식에서는 모든 비즈니스 로직 메서드에 로깅이나 트랜잭션 코드를 반복적으로 추가해야 했습니다.

public class OrderService {
    public void placeOrder() {
        System.out.println("트랜잭션 시작"); // 횡단 관심사
        try {
            // 핵심 비즈니스 로직
            System.out.println("주문 처리 로직 실행");
            System.out.println("트랜잭션 커밋"); // 횡단 관심사
        } catch (Exception e) {
            System.out.println("트랜잭션 롤백"); // 횡단 관심사
        } finally {
            System.out.println("로깅: placeOrder 종료"); // 횡단 관심사
        }
    }
}

위 코드에서 핵심 비즈니스 로직은 단 한 줄이지만, 이를 둘러싼 횡단 관심사 코드가 훨씬 더 많습니다. 이는 코드 중복을 유발하고, 비즈니스 로직의 본질을 파악하기 어렵게 만듭니다.

AOP는 이러한 횡단 관심사를 별도의 모듈(Aspect)로 분리하여 관리하는 기술입니다. 마치 연극의 주인공(비즈니스 로직)은 연기에만 집중하고, 무대 조명이나 음향 효과(횡단 관심사)는 별도의 스태프가 관리하는 것과 같습니다.

스프링 AOP는 프록시(Proxy) 패턴을 사용하여 이를 구현합니다. 스프링 컨테이너는 비즈니스 로직을 담은 실제 객체 대신, 횡단 관심사 로직이 추가된 프록시 객체를 생성하여 주입합니다. 그리고 이 프록시 객체가 호출될 때, 핵심 기능 실행 전후에 공통 기능을 실행하는 방식입니다.

AOP의 장점:

핵심 비즈니스 로직의 순수성 유지: 비즈니스 로직 코드에서 공통 기능 코드가 제거되어 가독성과 유지보수성이 향상됩니다.
코드 중복 제거: 공통 기능을 한 곳에서 관리하므로 재사용성이 높아집니다.
개발 생산성 향상: 개발자는 비즈니스 로직에만 집중할 수 있습니다.

다. 이식 가능한 서비스 추상화 (Portable Service Abstraction, PSA)

스프링은 특정 기술에 종속되지 않도록 서비스 추상화를 제공합니다. 예를 들어, 데이터베이스 트랜잭션을 처리할 때 JPA를 쓰든, JDBC를 쓰든, Hibernate를 쓰든 개발자는 @Transactional이라는 일관된 어노테이션 하나로 트랜잭션을 관리할 수 있습니다.

스프링이 중간에서 각 기술의 복잡한 API를 감싸고, 개발자에게는 단순하고 일관된 사용법을 제공하는 것입니다. 덕분에 기술을 변경하더라도 비즈니스 코드는 거의 수정할 필요가 없어 유연성이 극대화됩니다.

3. 스프링 생태계와 모듈

스프링은 단일 프레임워크가 아니라, 수많은 프로젝트의 집합체인 거대한 생태계입니다. 각 프로젝트는 특정 목적을 위한 모듈로 제공되어 필요한 것만 가져다 쓸 수 있습니다.

구분	주요 모듈	설명
코어(Core)	Spring Core, Beans, Context, SpEL	DI, IoC 컨테이너 등 스프링의 근간을 이루는 핵심 기능 제공
웹(Web)	Spring MVC, WebFlux	웹 애플리케이션 개발을 위한 모듈. (동기/블로킹 방식, 비동기/논블로킹 방식)
데이터 접근	JDBC, ORM, Transactions	데이터베이스 연동, 트랜잭션 관리를 추상화하여 제공
테스트(Test)	Spring Test	스프링 환경에서 단위 테스트 및 통합 테스트를 쉽게 작성하도록 지원
AOP	AOP, Aspects	관점 지향 프로그래밍 지원
스프링 부트	Spring Boot	스프링 설정을 자동화하여 빠르고 간편하게 애플리케이션을 생성하는 프로젝트
기타 프로젝트	Spring Data, Security, Cloud 등	데이터 접근, 보안, 클라우드/마이크로서비스 등 다양한 영역을 지원

이 모든 것을 처음부터 알 필요는 없습니다. 현대 스프링 개발의 표준은 **스프링 부트(Spring Boot)**에서 시작됩니다.

4. 현대의 표준: 스프링 부트 (Spring Boot)

과거의 스프링은 강력했지만 여전히 XML 기반의 복잡한 설정이 필요했습니다. 스프링 부트는 이러한 설정 과정을 최소화하고 개발자가 비즈니스 로직에만 집중할 수 있도록 탄생했습니다.

스프링 부트의 핵심 철학: “Just Run”

스프링 부트의 목표는 단지 실행만 하면 되는 독립적인(stand-alone) 상용 등급의 스프링 기반 애플리케이션을 만드는 것입니다.

스프링 부트의 주요 특징:

자동 설정 (Auto-configuration): 개발자가 추가한 라이브러리(의존성)를 감지하여, 그에 필요한 스프링 설정을 자동으로 처리합니다. 예를 들어, spring-boot-starter-web 의존성을 추가하면 내장 웹 서버(Tomcat)와 Spring MVC 관련 빈(Bean)들이 자동으로 설정됩니다.
내장 서버 (Embedded Server): Tomcat, Jetty, Undertow 같은 웹 서버를 내장하고 있어, 별도의 서버를 설치하고 배포하는 과정 없이 애플리케이션을 즉시 실행할 수 있습니다.
스타터 의존성 (Starter Dependencies): spring-boot-starter-web, spring-boot-starter-data-jpa처럼 특정 기능 개발에 필요한 의존성들을 묶어서 제공합니다. 개발자는 스타터 하나만 추가하면 관련 라이브러리들이 자동으로 추가되고 버전 관리도 쉬워집니다.
XML 설정 불필요: 더 이상 복잡한 XML 파일을 작성할 필요가 없습니다. 모든 설정은 자바 코드나 간단한 application.properties 파일로 관리할 수 있습니다.

간단한 스프링 부트 애플리케이션 예제

스프링 부트를 이용하면 웹 애플리케이션을 만드는 것이 얼마나 간단해지는지 확인해 보겠습니다.

1. build.gradle (의존성 설정)

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

웹 애플리케이션 개발에 필요한 모든 것을 담은 spring-boot-starter-web 하나만 추가하면 됩니다.

2. DemoApplication.java (메인 클래스)

@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

@SpringBootApplication 어노테이션 하나가 자동 설정, 컴포넌트 스캔 등 수많은 작업을 대신해줍니다. 이 클래스를 실행하면 내장 웹 서버가 구동됩니다.

3. HelloController.java (컨트롤러)

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello, Spring Boot!";
    }
}

@RestController는 이 클래스가 REST API의 요청을 처리함을 의미하고, @GetMapping("/hello")는 HTTP GET /hello 요청이 오면 이 메서드를 실행하라고 알려줍니다.

이제 애플리케이션을 실행하고 웹 브라우저에서 http://localhost:8080/hello로 접속하면 “Hello, Spring Boot!”라는 문자열이 출력됩니다. 별도의 XML 설정이나 복잡한 서버 배포 과정 없이 단 3개의 파일만으로 웹 애플리케이션이 완성되었습니다. 이것이 바로 스프링 부트의 강력함입니다.

5. 결론: 왜 아직도 스프링인가?

스프링 프레임워크는 20년이 넘는 시간 동안 자바 생태계의 왕좌를 지켜왔습니다. 그 이유는 시대의 변화에 발맞춰 끊임없이 진화했기 때문입니다.

변하지 않는 가치: IoC/DI와 AOP를 통해 객체 지향의 원칙을 지키면서 유연하고 확장 가능한 설계를 유도하는 핵심 철학은 여전히 유효합니다.
끊임없는 혁신: EJB의 복잡성을 해결하며 등장했고, XML 설정의 번거로움을 스프링 부트로 해결했으며, 최근에는 비동기/논블로킹 프로그래밍을 위한 WebFlux를 선보이는 등 항상 새로운 패러다임을 수용하고 있습니다.
강력한 생태계: 웹, 데이터, 보안, 클라우드, 배치 등 애플리케이션 개발에 필요한 거의 모든 영역을 지원하는 방대한 프로젝트들이 존재합니다. 어떤 문제를 만나든 스프링 생태계 안에서 해결책을 찾을 수 있습니다.

스프링은 더 이상 단순한 프레임워크가 아니라, 자바 엔터프라이즈 개발의 표준이자 플랫폼입니다. 이 핸드북이 스프링이라는 거대한 산을 등반하는 여러분에게 좋은 나침반이 되기를 바랍니다.

시스매

탐색기

스프링 프레임워크 A to Z 완벽 핸드북

스프링 프레임워크 A to Z 완벽 핸드북

1. 스프링의 탄생 배경 J2EE의 겨울

2. 스프링의 핵심 철학 및 구조

가. 제어의 역전 (Inversion of Control, IoC)과 의존성 주입 (Dependency Injection, DI)

나. 관점 지향 프로그래밍 (Aspect-Oriented Programming, AOP)

다. 이식 가능한 서비스 추상화 (Portable Service Abstraction, PSA)

3. 스프링 생태계와 모듈

4. 현대의 표준: 스프링 부트 (Spring Boot)

간단한 스프링 부트 애플리케이션 예제

5. 결론: 왜 아직도 스프링인가?

그래프 뷰

목차

백링크