POJO 중심
비즈니스 로직 클래스가 프레임워크 인터페이스를 상속하지 않습니다. 프레임워크를 바꿔도 로직은 남습니다.
이 파트에서 다루는 내용
Spring이 등장한 이유DI와 IoCSpring Boot가 없앤 작업국내 현장 맥락
01
Spring은 무거운 표준을 대신하려고 나왔습니다
2000년대 초 자바 엔터프라이즈 개발의 표준은 EJB였습니다. 트랜잭션과 분산 처리를 표준으로 제공했지만, 간단한 기능 하나를 만들기 위해 정해진 인터페이스를 구현하고 배포 서술자를 작성해야 했습니다. 테스트를 하려면 서버에 올려야 했습니다.
Spring은 여기에 반대 방향으로 답했습니다. 특별한 규약을 상속하지 않은 평범한 자바 객체(POJO)로 비즈니스 로직을 작성하고, 객체를 엮는 일은 프레임워크가 맡는 구조입니다.
이 선택 덕분에 비즈니스 로직이 프레임워크에서 분리됐고, 서버 없이 테스트할 수 있게 됐습니다. 지금 우리가 당연하게 여기는 서비스 클래스 단위 테스트가 이때 가능해진 것입니다.
IoC 컨테이너
객체 생성과 연결을 개발자가 아니라 컨테이너가 담당합니다. 코드가 '무엇을 쓸지'만 선언하고 '어떻게 만들지'는 맡깁니다.
AOP
트랜잭션, 로깅, 보안처럼 여러 곳에 반복되는 처리를 비즈니스 코드에서 떼어냅니다. @Transactional이 동작하는 원리입니다.
이식 가능한 서비스 추상화
DB, 메시징, 캐시 같은 기술을 추상화해 구현체를 바꿔도 코드가 크게 흔들리지 않게 합니다.
02
의존성 주입은 '누가 객체를 만드느냐'의 문제입니다
DI(Dependency Injection, 의존성 주입)는 어렵게 설명될 때가 많지만, 핵심은 한 문장입니다. 필요한 객체를 내가 직접 new 하지 않고 밖에서 받는다는 것입니다.
직접 new 하면 그 클래스는 특정 구현에 묶입니다. 테스트할 때 가짜 객체로 바꿀 수 없고, 구현을 교체하려면 코드를 고쳐야 합니다.
밖에서 주입받으면 실행 환경에서는 실제 구현을, 테스트에서는 가짜 구현을 넣을 수 있습니다. 결합도를 낮춘다는 말의 실제 의미가 이것입니다.
직접 생성과 주입의 차이java
// 직접 생성: OrderService가 특정 구현에 묶입니다
public class OrderService {
private final PaymentClient paymentClient = new TossPaymentClient();
}
// 주입: 무엇을 넣을지 밖에서 결정합니다
@Service
public class OrderService {
private final PaymentClient paymentClient;
public OrderService(PaymentClient paymentClient) {
this.paymentClient = paymentClient;
}
}아래 방식은 운영에서는 실제 결제 클라이언트를, 테스트에서는 가짜 구현을 넣을 수 있습니다. 코드 수정 없이 바뀝니다.
정리
DI는 문법이 아니라 설계 방식입니다. Spring을 쓰지 않아도 생성자로 받으면 DI입니다. Spring은 이 연결을 자동으로 해 주는 컨테이너를 제공할 뿐입니다.
03
Spring Boot는 Spring을 쓰기 위한 준비 작업을 없앴습니다
Spring은 강력했지만 시작이 무거웠습니다. XML 설정을 작성하고, 라이브러리 버전 조합을 직접 맞추고, 톰캣을 설치해 WAR로 배포해야 했습니다. 프로젝트를 시작하는 데만 며칠이 걸리기도 했습니다.
Spring Boot는 이 준비 작업을 걷어냅니다. 새로 만든 기능이 아니라 '이미 있던 Spring을 바로 쓸 수 있게 포장한 것'에 가깝습니다.
자동 설정
클래스패스에 무엇이 있는지 보고 필요한 설정을 대신 등록합니다. DB 드라이버가 있으면 DataSource를, 웹 라이브러리가 있으면 웹 환경을 준비합니다.
스타터
spring-boot-starter-web처럼 목적별로 필요한 라이브러리를 묶어 둡니다. 버전 조합을 직접 맞출 필요가 없습니다.
내장 서버
톰캣이 애플리케이션 안에 들어갑니다. 서버를 따로 설치하지 않고 java -jar로 실행합니다.
실행 가능한 jar
빌드 결과물 하나로 어디서든 같은 방식으로 실행됩니다. 컨테이너 이미지로 만들기도 쉬워집니다.
Actuator
헬스체크, 메트릭, 환경 정보 같은 운영용 엔드포인트를 기본 제공합니다. 트랙 D에서 자세히 다룹니다.
설정 외부화
같은 jar를 개발·운영에서 서로 다른 설정으로 실행합니다. Part 4에서 다룹니다.
자주 하는 오해
Spring Boot는 Spring을 대체하지 않습니다. 내부는 그대로 Spring이고, Boot는 설정과 실행 방식을 자동화한 계층입니다. 그래서 문제가 생기면 결국 Spring의 동작 원리를 알아야 해결됩니다.
04
국내 현장에서는 표준프레임워크 맥락을 알아야 합니다
국내 공공 사업에서는 전자정부 표준프레임워크가 개발 표준으로 지정되는 경우가 많습니다. 이 프레임워크는 Spring을 기반으로 만들어졌기 때문에, Spring을 이해하면 표준프레임워크도 크게 낯설지 않습니다.
다만 버전 차이가 큽니다. 오래된 사업은 XML 설정과 WAR 배포를 그대로 쓰고, 최근 사업은 Spring Boot 기반 구성을 사용합니다. 투입되는 현장이 어느 쪽인지 먼저 확인해야 합니다.
레거시 구성에서 만나는 것
- XML 기반 빈 설정과 web.xml
- WAR 배포와 별도 톰캣 설치
- MyBatis 중심 데이터 접근
- JDK 8 또는 11 기준 코드
Boot 기반 구성에서 만나는 것
- 애노테이션과 yml 설정
- 실행 가능한 jar 배포
- JPA 또는 MyBatis 선택 사용
- JDK 17 이상 기준 코드
학습 순서 제안
레거시 현장에 있더라도 Spring Boot 기준으로 개념을 익히는 편이 낫습니다. Boot는 Spring의 설정을 감춘 것이라, Boot를 이해하면 XML 설정도 '이게 자동으로 되던 그것'으로 읽힙니다. 반대 순서는 훨씬 오래 걸립니다.
버전
3.x와 4.x 차이
본문은 현장에서 가장 많이 쓰는 3.x 기준입니다. 4.x에서 달라진 부분만 아래에 정리합니다.
- Spring Boot 3.x는 Spring Framework 6, Jakarta EE 9+, Java 17 이상을 기준으로 합니다. javax 패키지가 jakarta로 바뀐 것이 2.x와의 가장 큰 차이입니다.
- Spring Boot 4.0(2025년 11월)은 Spring Framework 7 기반이며, 자동설정 JAR을 기술별 모듈로 분리했습니다. 최소 Java 버전은 17로 동일합니다.
- 4.1(2026년 6월)이 현재 최신입니다. 3.5.x는 2026년 6월 30일 오픈소스 지원이 종료됐고 상용 지원만 남아 있습니다. 버전 판단은 Part 14에서 자세히 다룹니다.
체크