Part 1. Spring Framework의 이해
1.1 Spring Framework란?
Spring Framework는 Java 기반 애플리케이션을 효율적으로 개발하기 위한 오픈소스 프레임워크입니다. 현재 Java 백엔드 개발에서 가장 널리 사용되며 웹, 배치, 마이크로서비스 등 다양한 환경에서 활용됩니다. Spring을 제대로 이해하기 위해서는 단순히 어노테이션 사용법을 익히는 것을 넘어, "Spring이 왜 등장했고 어떤 문제를 해결하려 했는가"를 아는 것이 출발점입니다.
Spring Framework의 등장 배경
초기 Java 웹 애플리케이션은 Servlet과 JSP를 중심으로 개발되었습니다.
당시에는 객체를 코드 내부에서 직접 생성하고 연결하는 방식이 일반적이었습니다.
public class MemberService {
// Service가 Repository를 직접 생성
private final MemberRepository memberRepository = new MemberRepository();
public void join(Member member) {
memberRepository.save(member);
}
}
겉보기에는 단순한 코드 같지만, 객체가 의존 객체를 직접 생성하는 구조에는 3가지 치명적인 문제가 존재합니다.
- 책임의 과중: MemberService가 자신의 비즈니스 역할뿐만 아니라 MemberRepository의 생성과 연결까지 direct로 담당합니다.
- 높은 결합도(Coupling): 구현체가 변경되면 이를 사용하는 서비스 코드도 반드시 수정되어야 합니다.(예: 메모리 저장소를 JPA로 변경 시 `new JpaMemberRepository()`로 직접 수정 필요)
- 테스트의 어려움: 가짜 구현체(Mock/Fake)를 외부에서 주입하기 어렵기 때문에, 단순 단위 테스트를 진행하려 해도 실제 DB 환경에 의존해야 합니다.
Spring이 해결하려는 문제
Spring은 객체 생성과 객체 간 연결 책임을 애플리케이션 코드에서 완전히 분리합니다.
개발자는 객체의 역할과 비즈니스 로직에만 집중하고, 객체를 만들어 이어주는 작업은 Spring 컨테이너에 위임합니다.
@Service
public class MemberService {
private final MemberRepository memberRepository;
// 외부(Spring)에서 생성된 객체를 주입받음
public MemberService(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
}
이 코드에는 `new MemberRepository()`가 존재하지 않습니다.
Spring이 필요한 객체를 미리 생성해 두고 주입해 주기 때문입니다.
- 이러한 제어의 흐름이 바뀐 구조를 제어의 역전(IoC, Inversion of Control)이라 합니다.
- 필요한 객체를 외부에서 전달받는 과정을 의존성 주입(DI, Dependency Injection)이라 합니다.
애플리케이션 코드와 인프라 코드의 분리
개발 과정에서 반복적으로 작성되는 기술적 코드(트랜잭션 관리, DB 연결, 로깅, 보안 등) 역시 Spring이 대신 처리해 줍니다.
결과적으로 개발자는 비즈니스 핵심 로직에만 집중할 수 있게 되며, 다음과 같은 명확한 이점을 얻습니다.
- 객체 간 결합도가 낮아져 구현체 변경이 쉬워짐
- 외부에서 가짜 객체(Mock)를 주입할 수 있어 단위 테스트가 용이해짐
- SOLID 같은 객체지향 설계 원칙을 자연스럽게 준수하게 됨
정리
Spring Framework의 핵심은 단순히 "객체를 대신 만들어 주는 편리함"에 있지 않습니다. 객체의 생성과 사용을 분리하여 객체지향 설계를 구조적으로 지원하는 것이 본질입니다. 이 원리를 이해하면 이어지는 IoC, DI, Bean, AOP, Transaction, MVC까지의 모든 개념이 하나의 흐름으로 자연스럽게 이어지게 됩니다.
핵심 질문
Q1. Spring Framework를 사용하는 본질적인 이유는 무엇인가요?
단순히 어노테이션을 제공해 편의성을 높이는 것이 아니라, 객체의 생성과 관리를 컨테이너에 맡김으로써 객체지향 설계 원칙(SOLID)을 자연스럽게 지킬 수 있도록 돕기 때문입니다. 또한 트랜잭션, AOP 등 공통 인프라 코드를 프레임워크가 담당하여 개발자가 비즈니스 로직에만 집중할 수 있게 합니다.
Q2. Spring이 해결하고자 한 전통적인 Java 개발의 문제는 무엇인가요?
객체가 다른 의존 객체를 직접 생성(new)하면서 발생하는 높은 결합도와 테스트의 어려움입니다. 구현체가 변경될 때마다 비즈니스 코드까지 수정해야 하는 문제를 해결하기 위해, 객체의 생성과 연결 책임을 컨테이너로 넘기는 구조를 제시했습니다.
Q3. Spring에서 객체 생성과 의존성 관리는 어디서 담당하나요?
Spring 컨테이너(IoC 컨테이너)가 담당합니다. 애플리케이션 실행 시 필요한 객체(Bean)를 직접 생성 및 관리하며, 필요한 곳에 주입(DI)하여 객체 간의 관계를 완성해 줍니다.
1.2 Spring의 핵심 개념
Spring Framework를 제대로 활용하려면 먼저 Spring을 받치고 있는 5가지 핵심 개념을 이해해야 합니다. Spring은 단순히 웹 애플리케이션을 빠르게 개발하기 위한 도구 모음이 아니라, 객체지향 설계를 가장 효과적으로 적용할 수 있도록 지원하는 프레임워크입니다. Spring의 핵심 철학은 다음 다섯 가지로 요약할 수 있습니다.
- POJO (Plain Old Java Object)
- IoC (Inversion of Control)
- DI (Dependency Injection)
- AOP (Aspect-Oriented Programming)
- PSA (Portable Service Abstraction)
이 개념들은 서로 독립적으로 존재하는 것이 아니라, 객체지향 설계를 완성하기 위해 긴밀하게 연결되어 동작합니다.
1. POJO (Plain Old Java Object)
POJO는 특정 프레임워크나 기술에 강하게 의존하지 않는 순수한 Java 객체를 의미합니다. Spring이 등장하기 이전에는 EJB 같은 기술을 사용하기 위해 프레임워크 전용 클래스를 상속받거나 인터페이스를 강제로 구현해야 했습니다.
// 프레임워크 기술에 강하게 결합된 형태
public class MemberService extends SomeFrameworkService {
public void join(Member member) {
...
}
}
이러한 구조는 애플리케이션 코드가 특정 프레임워크와 강하게 결합되어 종속성을 만듭니다.
반면, Spring은 개발자가 작성하는 비즈니스 코드가 순수한 Java 형태를 유지할 수 있도록 설계되었습니다.
// 순수한 Java 객체 (POJO)
@Service
public class MemberService {
public void join(Member member) {
...
}
}
MemberService는 프레임워크의 특정 클래스를 상속받지 않습니다. 어노테이션을 제외하면 완전히 순수한 Java 코드입니다. Spring은 객체 외부에서 필요한 인프라 기능을 제공하므로, 비즈니스 로직에만 전념하는 POJO 작성이 가능해집니다.
2. IoC (Inversion of Control)
IoC는 제어의 역전을 의미합니다. 애플리케이션 흐름의 주도권이 개발자에서 프레임워크로 넘어간 상태입니다.
일반적인 Java 개발에서는 개발자가 필요한 객체를 직접 생성하고 관리합니다.
// 개발자가 직접 객체 생성 및 생명주기 관리
MemberRepository repository = new MemberRepository();
반면 Spring 환경에서는 객체의 생성, 생명주기, 소멸까지의 관리 책임이 Spring 컨테이너로 이동합니다.
@Service
public class MemberService {
private final MemberRepository repository;
// 객체 생성은 컨테이너가 맡고, 서비스는 주입받아 사용만 함
public MemberService(MemberRepository repository) {
this.repository = repository;
}
}
MemberService는 MemberRepository가 언제, 어떻게 만들어지는지 알 필요가 없습니다.
객체 생성 및 관리에 대한 제어권이 개발자에서 컨테이너로 역전된 것입니다.
3. DI (Dependency Injection)
DI는 의존성 주입을 의미합니다.
객체가 필요로 하는 의존 객체를 직접 만들지 않고, 외부(Spring 컨테이너)에서 생성하여 전달(주입)받는 방식입니다.
- IoC가 개념이라면, DI는 그 개념을 실제로 구현하는 대표적인 구체적 방법입니다.
// 생성자를 통한 의존성 주입 (Constructor Injection)
public MemberService(MemberRepository repository) {
this.repository = repository;
}
Spring은 MemberRepository를 먼저 생성한 후, 이를 필요로 하는 MemberService의 생성자를 통해 전달합니다.
- 구현체 교체의 용이성: 설정 변경만으로 DB 접근 방식을 쉽게 교체 가능
- 테스트 편의성: 단위 테스트 시 가짜 객체(Mock)를 전달하기 쉬움
- 낮은 결합도: 인터페이스에 의존함으로써 코드 변경의 영향을 최소화
4. AOP (Aspect-Oriented Programming)
AOP는 관점 지향 프로그래밍으로, 핵심 비즈니스 로직과 공통으로 반복되는 기술(횡단 관심사)을 분리하는 개념입니다.
애플리케이션 개발 시 비즈니스 로직 외에도 다음과 같은 공통 기능이 끊임없이 반복됩니다.
- 로깅 (Logging)
- 트랜잭션 처리 (Transaction)
- 보안 검사 (Security)
- 실행 시간 측정 (Performance)
AOP가 없다면 모든 메서드에 중복 코드를 작성해야 하므로 핵심 로직이 비대해지고 유지보수가 지저분해집니다.
// AOP 적용 전: 비즈니스 로직과 공통 로직이 섞임
public void join(Member member) {
log.info("회원 가입 시작"); // 공통 로직
memberRepository.save(member); // 핵심 비즈니스 로직
log.info("회원 가입 완료"); // 공통 로직
}
Spring은 AOP를 통해 공통 기능을 한곳에 분리하여 관리합니다. 대표적인 사례가 바로 @Transactional 어노테이션입니다. 개발자가 트랜잭션 시작/커밋/롤백 코드를 작성하지 않아도, Spring이 메서드 실행 전후로 공통 로직을 자동 삽입해 줍니다.
5. PSA (Portable Service Abstraction)
PSA는 일관된 방식으로 다양한 기술을 사용할 수 있도록 제공하는 서비스 추상화입니다. 데이터 접근 기술만 하더라도 JDBC, JPA, MyBatis 등 다양한 선택지가 존재하며 각각의 사용 문법이 다릅니다. Spring은 이 기술들을 일관된 인터페이스로 감싸 추상화(PSA)해 둡니다.
- 대표 사례: PlatformTransactionManager
- JPA를 쓰든, JDBC를 쓰든 @Transactional이라는 동일한 방식으로 트랜잭션을 처리할 수 있는 이유가 바로 PSA 덕분입니다.
기술이 변경되더라도 애플리케이션의 비즈니스 코드는 크게 수정할 필요 없이, 추상화된 인터페이스를 그대로 활용할 수 있어 특정 기술에 종속되지 않는 유연성을 얻게 됩니다.
5가지 핵심 개념의 유기적 관계
이 다섯 가지 개념은 따로 놀지 않고 하나의 큰 그림으로 연결됩니다.

- 개발자는 순수한 Java 객체(POJO)로 비즈니스 로직을 작성
- Spring의 IoC/DI가 객체의 생명주기를 관리하고 의존성을 연결
- 반복되는 인프라 코드는 AOP로 깔끔하게 분리
- 외부 기술이나 DB 연결 기술은 PSA로 추상화하여 일관되게 접근
핵심 질문
Q1. Spring의 5가지 핵심 개념은 무엇이며, 각각 어떤 역할을 하나요?
POJO, IoC, DI, AOP, PSA입니다. POJO는 특정 프레임워크에 종속되지 않는 순수 자바 객체를, IoC/DI는 객체 생성과 의존성 관리의 주도권을 컨테이너로 넘기는 것을, AOP는 로깅/트랜잭션 같은 공통 기능의 분리를, PSA는 다양한 기술을 일관되게 다루기 위한 추상화를 담당합니다.
Q2. IoC와 DI의 개념적 차이는 무엇인가요?
IoC(Inversion of Control)는 객체의 생성과 관리 제어권이 개발자에서 프레임워크로 넘어간다는 '상위의 설계 원칙/개념'입니다. DI(Dependency Injection)는 그 IoC 개념을 달성하기 위해 외부에서 의존 객체를 주입해 주는 '실제 구체적인 패턴/구현 방법'입니다.
Q3. PSA(Portable Service Abstraction)란 무엇이며 왜 필요한가요?
환경이나 밑단에 깔린 기술(JDBC, JPA 등)이 바뀌어도 개발자가 동일한 접근 방식(인터페이스)을 유지할 수 있도록 돕는 서비스 추상화 layer입니다. 특정 기술에 코드가 종속되는 것을 막아 변경과 유연성에 강한 구조를 만들어 줍니다.
1.3 객체지향과 Spring
Spring Framework를 제대로 이해하기 위해서는 객체지향 프로그래밍(OOP)의 기본 원칙을 함께 알아야 합니다. Spring은 세상에 없던 새로운 객체지향 개념을 만들어 낸 것이 아닙니다. 좋은 객체지향 설계를 실무 애플리케이션에 현실적이고 유연하게 적용할 수 있도록 지원하는 프레임워크입니다. 특히 Spring은 다음 3가지 핵심 원칙을 자연스럽게 준수할 수 있도록 돕습니다.
- 역할과 구현의 분리
- DIP (Dependency Inversion Principle, 의존관계 역전 원칙)
- OCP (Open-Closed Principle, 개방-폐쇄 원칙)
역할과 구현의 분리
객체지향 설계의 핵심은 역할(Role)과 구현(Implementation)을 명확히 분리하는 것입니다.
- 역할: 객체가 제공해야 하는 기능의 명세 (Java의 `interface`)
- 구현: 역할을 실제로 수행하는 구체적인 클래스 (Java의 `class`)
예를 들어 회원을 저장하고 조회하는 역할을 인터페이스로 정의합니다.
public interface MemberRepository {
void save(Member member);
Member findById(Long id);
}
이 역할은 다양한 방식으로 구현될 수 있습니다.
// 메모리 저장 방식 구현체
public class MemoryMemberRepository implements MemberRepository {
@Override
public void save(Member member) { ... }
}
// JPA 데이터베이스 저장 방식 구현체
public class JpaMemberRepository implements MemberRepository {
@Override
public void save(Member member) { ... }
}
역할과 구현을 분리하면, 데이터 저장 방식을 메모리에서 DB(JPA)로 변경하더라도 역할을 사용하는 서비스 코드는 전혀 변경할 필요가 없습니다.
인터페이스에 의존하기
객체는 구체적인 구현 클래스보다 인터페이스(추상화)에 의존하는 것이 바람직합니다.
Bad Case: 구현 클래스에 직접 의존하는 경우
public class MemberService {
// 구현체에 직접 의존 -> 저장 기술 변경 시 Service 코드도 수정해야 함
private final JpaMemberRepository repository = new JpaMemberRepository();
}
Good Case: 인터페이스에 의존하는 경우
public class MemberService {
private final MemberRepository repository;
// 외부(Spring)에서 인터페이스의 실제 구현체를 주입받음
public MemberService(MemberRepository repository) {
this.repository = repository;
}
}
MemberService는 MemberRepository라는 인터페이스만 바라봅니다.
실제 들어오는 객체가 메모리 저장소든 JPA든, 비즈니스 로직에는 아무런 영향을 주지 않습니다.
DIP (Dependency Inversion Principle)
DIP는 의존관계 역전 원칙으로, SOLID 원칙 중 하나입니다.
- 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 된다.
- "추상화(인터페이스)에 의존해야지, 구체화(구현 클래스)에 의존해서는 안 된다."
구현 클래스(JpaMemberRepository)에 직접 의존하면 DIP 위반입니다. 반면 MemberRepository 인터페이스에 의존하면 DIP를 만족합니다. Spring은 DI(의존성 주입)를 통해 외부에서 구현체를 넣어줌으로써 개발자가 DIP를 자연스럽게 지키도록 유도합니다.
OCP (Open-Closed Principle)
OCP는 개방-폐쇄 원칙으로, 객체지향 설계의 가장 중요한 목표 중 하나입니다.
- 확장에는 열려(Open) 있어야 하고, 수정에는 닫혀(Closed) 있어야 한다.
- 즉, 기능을 추가하거나 변경해도 기존 비즈니스 코드는 수정하지 않아야 합니다.
Spring 환경에서는 저장 기술을 변경할 때 서비스 코드를 건드리지 않고, 설정 파일(Bean 등록 정보)만 변경하면 됩니다.
// Java Configuration 파일에서 빈 교체만 진행
@Bean
public MemberRepository memberRepository() {
// return new MemoryMemberRepository(); -> Jpa로 변경 시 한 줄만 수정
return new JpaMemberRepository();
}
새로운 기능을 추가하거나 구현체를 교체할 때 기존 비즈니스 로직(MemberService)은 전혀 수정할 필요가 없으므로 OCP를 완벽히 만족하게 됩니다.
Spring이 객체지향 설계를 지원하는 방식
Spring은 좋은 설계를 개발자에게 강제하지 않습니다. 대신 좋은 객체지향 설계를 적용하기 가장 편한 판을 깔아줍니다.
- 운영 환경: JPA 기반 저장소 주입
@Bean public MemberRepository memberRepository() { return new JpaMemberRepository(); } - 테스트 환경: 가짜/메모리 저장소 주입
@Bean public MemberRepository memberRepository() { return new MemoryMemberRepository(); }
어떤 환경이든 MemberService 코드는 단 한 줄도 수정하지 않습니다. Spring이 객체 생성과 연결을 대신해 주기 때문입니다.
정리
객체지향 설계의 핵심은 역할과 구현을 분리하여 추상화(인터페이스)에 의존하는 것입니다. Spring은 IoC와 DI라는 무기를 통해 이러한 객체지향 원칙(DIP, OCP)을 실무 개발에서 자연스럽게 적용할 수 있게 해줍니다. 우리가 Spring을 사용하는 진정한 가치는 단순히 기능이 많아서가 아니라, 유연하고 변경에 강한 좋은 객체지향 애플리케이션을 만들 수 있게 돕기 때문입니다.
핵심 질문
Q1. 역할과 구현을 분리하면 어떤 이점이 있나요?
구현체가 바뀌거나 새로운 기능이 추가되어도 역할(인터페이스)을 사용하는 클라이언트 코드를 전혀 수정할 필요가 없습니다. 이를 통해 시스템의 확장성과 유지보수성이 극대화됩니다.
Q2. DIP(의존관계 역전 원칙)란 무엇이며 Spring은 이를 어떻게 지원하나요?
DIP는 구체적인 구현 클래스가 아닌 추상화(인터페이스)에 의존해야 한다는 원칙입니다. Spring은 IoC 컨테이너가 DI(의존성 주입)를 통해 필요한 구현체 객체를 외부에서 주입해 줌으로써 개발자가 DIP를 쉽게 준수할 수 있도록 돕습니다.
Q3. Spring 환경에서 OCP(개방-폐쇄 원칙)는 어떻게 달성되나요?
DI와 Bean 설정 관리를 통해 달성됩니다. 새로운 구현체로 교체하더라도 설정 코드(Bean 등록 부분)만 변경하면 되며, 핵심 비즈니스 로직(Service)은 수정에 닫힌 상태를 유지하면서 확장에는 열린 구조를 완성할 수 있습니다.
1.4 Spring Framework와 Spring Boot의 차이
Spring을 처음 접할 때 가장 흔히 오해하는 것 중 하나가 Spring Framework와 Spring Boot를 서로 다른 별개의 기술로 보거나, 아예 같은 기술로 치부하는 것입니다. 결론부터 정리하자면, Spring Framework가 애플리케이션 개발의 본질이자 기반 기술이라면, Spring Boot는 이 Spring Framework를 개발자가 훨씬 편리하게 다룰 수 있도록 돕는 도구(추가 도구)입니다.
Spring Framework란?
Spring Framework는 애플리케이션 개발에 필요한 핵심 기능 모음과 원칙을 제공하는 프레임워크입니다.
우리가 흔히 이야기하는 Spring의 본질적 핵심 기능은 전부 Spring Framework가 담당합니다.
- IoC 컨테이너 & DI (객체 생명주기 관리 및 주입)
- Bean 관리
- AOP (공통 관심사 분리)
- Transaction (선언적 트랜잭션 관리)
- Spring MVC (웹 애플리케이션 구조)
- Event, Test Support 등
@Service
public class MemberService {
private final MemberRepository memberRepository;
// @Service를 통한 Bean 등록과 생성자 주입은 모두 Spring Framework의 기능
public MemberService(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
}
이처럼 우리가 작성하는 자바 코드의 핵심 동작은 모두 Spring Framework 기반 위에서 작동합니다.
Spring Boot가 등장한 이유
Spring Framework는 매우 강력하지만, 과거에는 프로젝트 하나를 시작하기 위한 초기 설정(Configuration)이 지나치게 복잡하고 번거롭다는 단점이 있었습니다. 과거에는 프로젝트 시작을 위해 개발자가 직접 다음과 같은 일들을 해주어야 했습니다.
- 수많은 라이브러리 간의 버전 호환성 직접 관리
- DispatcherServlet 및 각종 Resolver, Converter 수동 등록
- Component Scan 범위 및 XML/Java Config 설정
- 외장 WAS(Tomcat 등) 설치, 설정 및 WAR 파일 배포
이러한 수많은 설정 작업은 개발 속도를 저하시켰고, 설정상의 자그마한 실수로 애플리케이션이 구동조차 되지 않는 일이 비일재했습니다. Spring Boot는 바로 이러한 반복적이고 까다로운 설정을 자동화하여 개발 편의성을 높이기 위해 등장했습니다.
Spring Boot가 추가한 핵심 기능
Spring Boot는 Spring Framework 위에 올려진 보조 프레임워크로, 개발 생산성을 대폭 향상시켜 주는 강력한 기능들을 탑재하고 있습니다.
1. 자동 설정 (Auto Configuration)
프로젝트에 포함된 라이브러리(Jar) 패스 상태를 분석하여, 개발자가 하나하나 지정하지 않아도 필요한 Bean 설정을 자동으로 구성합니다.
- 예: 클래스패스에 spring-webmvc가 존재하면, DispatcherServlet, HandlerMapping 등을 보이지 않는 곳에서 알아서 빈으로 등록합니다.
2. Starters (의존성 관리 단순화)
관련된 라이브러리 묶음을 하나의 스타터(Starter) 패키지로 묶어 제공합니다.
// 단 한 줄의 선언으로 웹 개발에 필요한 핵심 라이브러리와 버전이 자동 호환 정리됨
implementation 'org.springframework.boot:spring-boot-starter-web'
개발자가 개별 라이브러리의 버전을 호환성 있게 일일이 맞출 필요 없이, 스타터 하나만 지정하면 안정된 버전 조합이 알아서 당겨져 옵니다.
3. 내장 웹 서버 (Embedded Server)
별도의 외부 Tomcat/Jetty 같은 WAS를 설치하고 설정할 필요 없이, Spring Boot 내부에 Tomcat이 포함되어 작동합니다. 자바 메인 메서드만 실행하면 애플리케이션과 웹 서버가 동시에 구동됩니다.
4. 실행 가능한 Fat JAR (Executable JAR)
WAS 배포용 `WAR` 파일 대신, 내장 서버 및 모든 의존 라이브러리를 하나로 포함한 JAR 파일 생성을 지원합니다.
java -jar application.jar
단 한 줄의 커맨드로 서버 환경 어디서든 복잡한 배포 과정 없이 앱을 바로 실행시킬 수 있습니다.
5. production-ready 운영 기능 (Actuator)
운영 환경에 필요한 Health Check, Metrics 정보, 애플리케이션 모니터링 환경 등을 Spring Boot Actuator를 통해 손쉽게 구성할 수 있습니다.
Spring Framework와 Spring Boot의 관계
Spring Boot는 Spring Framework를 대체하는 기술이 결코 아닙니다.

Spring Boot 내부를 열어보면 실제 비즈니스 로직과 웹 요청을 처리하는 본체는 전부 Spring Framework입니다. Boot는 오직 이를 "더 편하고 빠르게 사용할 수 있게 포장하고 조율해 주는 도구"일 뿐입니다. 실무 환경에서는 100%에 가깝게 Spring Boot를 사용하여 프로젝트를 구성합니다. 하지만 Spring Boot가 뒤에서 알아서 자동화해 주는 원리를 이해하려면, 반드시 Spring Framework의 핵심 원리를 먼저 알아야 합니다.
- 생성자 주입 원리를 모르면, Boot가 자동 주입해 주는 내부 동작을 이해할 수 없습니다.
- DispatcherServlet의 역할을 모르면, Boot가 알아서 등록해 주는 Web MVC 설정의 의미를 파악할 수 없어 트러블슈팅에 한계가 옵니다.
따라서 가장 올바른 학습 단계는 다음과 같습니다.
- Spring Framework의 핵심 원리 (IoC, DI, AOP, Transaction 등) 체득
- Spring Boot의 자동 설정(Auto Configuration) 원리 이해
- Spring Boot를 활용한 실무 프로젝트 개발 및 응용
정리
- Spring Framework: 애플리케이션 개발의 뼈대가 되는 핵심 기능(IoC, DI, AOP, MVC 등)을 다루는 프레임워크입니다.
- Spring Boot: Spring Framework를 시작할 때 발생하는 복잡한 설정 작업을 자동화(Auto-Config, Starter, 내장 Tomcat 등)하여 개발 생산성을 높여주는 도구입니다.
실무 개발은 Spring Boot 환경에서 이루어지지만, 그 안에서 구동되는 모든 원리의 중심에는 Spring Framework가 존재한다는 점을 명심해야 합니다.
핵심 질문
Q1. Spring Framework와 Spring Boot의 핵심 차이는 무엇인가요?
Spring Framework는 IoC/DI, AOP, Transaction, MVC 등 백엔드 개발에 필요한 핵심 기능 원천을 제공하는 프레임워크입니다. Spring Boot는 이러한 Spring Framework를 더 쉽게 시작하고 사용할 수 있도록 자동 설정(Auto Configuration), Starter 의존성 관리, 내장 웹 서버(Tomcat) 등을 제공하는 프로젝트입니다.
Q2. Spring Boot는 Spring Framework를 대체하는 기술인가요?
아니오, 그렇지 않습니다. Spring Boot는 Spring Framework 위에서 구동되는 확장/보조 도구입니다. 실제로 애플리케이션을 지탱하고 비즈니스 로직을 처리하는 핵심 구조(IoC 컨테이너 등)는 모두 Spring Framework의 기능을 그대로 사용합니다.
Q3. Spring Boot가 제공하는 가장 큰 이점(장점)들은 무엇인가요?
1) 복잡한 설정을 자동화해 주는 Auto Configuration, 2) 라이브러리 버전 관리를 단순화하는 Starter, 3) 외부 WAS 설치가 필요 없는 내장 웹 서버(Embedded Tomcat), 4) 단일 파일로 손쉽게 배포·실행 가능한 Executable JAR 제공을 통한 개발 생산성의 극대화입니다.
'🍃SpringBoot' 카테고리의 다른 글
| Spring: Part 3. 의존성 주입(DI)과 활용 (0) | 2026.07.29 |
|---|---|
| Spring: Part 2. IoC 컨테이너와 Bean (0) | 2026.07.29 |
| Spring IoC & DI 완전 정복: Chapter 8. Proxy와 Spring AOP (1) | 2026.07.22 |
| Spring IoC & DI 완전 정복: Chapter 7. BeanPostProcessor와 Spring의 확장 포인트 (0) | 2026.07.22 |
| Spring IoC & DI 완전 정복: Chapter 6. Spring은 의존성을 어떻게 해결할까? (0) | 2026.07.22 |
