스프링이란 왜 스프링? IoC·DI 생태계 역사 📝 문제풀이
◀ 이전 📋 목차 CH 02 ▶
🍃 CHAPTER 01 · 입문

스프링은 무엇을 대신 해줄까?

문법을 외우기 전에, 스프링이 어떤 고통을 덜어주려고 나왔는지부터 알면 전부 이해돼요. 이번 장은 큰 그림과 이야기 중심입니다. 자바를 아는 태호님껜 술술 읽혀요.

🎯 이 장을 끝내면
📖
스프링이란
스프링(Spring)이 뭔가요?
한 문장으로 먼저 잡고, 천천히 풀어볼게요.

스프링은 "자바로 서버(백엔드) 애플리케이션을 쉽고 견고하게 만들도록 도와주는 프레임워크"예요. 우리가 매번 똑같이 짜야 하는 귀찮고 복잡한 공통 작업(객체 연결·트랜잭션·웹 요청 처리 등)을 스프링이 대신 처리해줘서, 개발자는 진짜 중요한 비즈니스 로직에 집중할 수 있어요.

🔤
프레임워크(Framework) — 프로그램의 큰 뼈대(틀)를 미리 만들어 둔 것이에요. 집으로 치면 기둥과 골조가 이미 세워진 상태라, 개발자는 그 정해진 자리에 방 인테리어(내 코드)만 채우면 되는 셈이에요. (바로 아래에서 라이브러리와 비교해 볼게요.)
🔤
백엔드(Backend) — 사용자 눈에 보이는 화면(프론트엔드) 뒤에서 일하는 부분이에요. 서버에서 데이터를 저장하고 꺼내오고 계산하는 "보이지 않는 주방" 같은 곳이죠. 스프링은 이 백엔드를 만드는 도구예요.
🔤
비즈니스 로직(Business Logic) — "주문을 받으면 재고를 줄이고 결제한다"처럼 그 서비스가 진짜 하고 싶은 핵심 규칙이에요. 스프링은 이 핵심을 뺀 나머지 잡일(연결·설정 등)을 대신 해줘서, 우리가 핵심에만 집중하게 해줘요.
🏗️ 라이브러리 vs 프레임워크 라이브러리는 내가 필요할 때 불러 쓰는 도구예요(내가 주도).
프레임워크큰 틀(뼈대)을 먼저 제공하고, 나는 그 안의 정해진 자리에 내 코드를 채워 넣어요(프레임워크가 주도). 스프링은 프레임워크예요. "언제 무엇을 실행할지"의 흐름은 스프링이 쥐고, 개발자는 정해진 자리(컨트롤러·서비스 등)에 코드를 채워요. 이 "주도권이 프레임워크에 있다"가 바로 뒤에 나올 IoC의 씨앗이에요.
Spring IoC DI Bean 컨테이너 Spring Boot Rod Johnson POJO
🧭
이번 장의 읽는 법. 억지로 외우지 마세요. "아, 스프링이 이런 걸 대신 해주는구나" 하는 맥락만 잡으면 다음 장부터 나오는 어노테이션·설정이 훨씬 쉽게 붙습니다.
😣
왜 스프링?
스프링 없이 짜면 무엇이 힘들까
문제를 알면 스프링의 고마움이 보여요.
🧱 순수 자바로만 짜면 — 객체 연결이 손일 필요한 객체를 내가 직접 new로 만들고, 그 객체가 또 필요로 하는 객체까지 일일이 만들어 넣어줘야 해요. 규모가 커지면 이 "누가 누구를 만들고 연결하나"가 얽히고설켜 관리가 어려워져요.
// 내가 모든 걸 직접 생성·연결
Repository repo = new Repository();
Service service = new Service(repo);   // service가 repo에 의존
Controller ctrl = new Controller(service);
🍃 스프링이 있으면 — 연결을 대신 해줌 "이 객체들이 필요해"라고 표시만 해두면, 스프링이 객체를 대신 만들고 알아서 연결(주입)해줘요. 개발자는 new와 연결 코드를 거의 쓰지 않아요. 여기에 더해 스프링은 트랜잭션·보안·웹 요청 처리 같은 공통 인프라도 대신 처리해줘요. 그래서 우리는 비즈니스 로직에 집중할 수 있어요.
💡
IoC·DI
스프링의 심장: IoC와 DI
이 둘만 이해하면 스프링의 절반은 끝나요. (자세한 건 CH 02)

방금 본 "객체를 일일이 new로 만들고 연결하는 번거로움" 기억하시죠? 바로 그 문제를 풀려고 나온 아이디어가 IoC와 DI예요. 이름은 어렵지만, 핵심은 "객체를 만들고 연결하는 귀찮은 일을 개발자 대신 스프링이 맡는다" 딱 하나예요. 천천히 볼게요.

🔄 IoC (Inversion of Control, 제어의 역전) 원래는 개발자가 객체를 만들고 흐름을 제어했어요. 스프링에서는 객체의 생성·연결·생명주기 관리를 스프링(컨테이너)이 가져가요.제어권이 개발자 → 프레임워크로 넘어가요. 이걸 "제어의 역전"이라 해요.
💉 DI (Dependency Injection, 의존성 주입) IoC를 구체적으로 실현하는 방법이에요. 어떤 객체가 필요로 하는 다른 객체(의존성)를, 직접 new 하지 않고 외부(스프링)가 만들어 넣어주는(주입) 것이에요. 💡 비유: 요리사가 재료를 직접 사러 가는(new) 대신, 주방 보조가 필요한 재료를 척척 가져다주는(DI) 것. 요리사(내 로직)는 요리에만 집중하면 돼요.
🙋
개발자
"이 객체 필요해" 표시만
🍃
스프링 컨테이너
객체 생성·연결(주입)·관리
완성
내 로직에만 집중
🧩 IoC와 DI, 단계별로 제대로 — new 부터 회사 비유까지 — 펼쳐 보기
IoC와 DI를 한꺼번에 들으면 헷갈려요. 순서대로 하나씩 보면 쉬워요.

1단계 — 원래 자바는 "내가 직접" 만들어요
Engine engine = new Engine();
Car car = new Car(engine);   // 내가 new 하고, 내가 연결
객체 생성·연결의 제어권이 전부 개발자에게 있어요.

2단계 — 객체가 많아지면?
Engine engine = new Engine();
Wheel wheel = new Wheel();
Seat seat = new Seat();
Car car = new Car(engine, wheel, seat);
프로그램이 커질수록 "누가·언제 만들지, 누가 연결하지" 코드가 폭증해요.

3단계 — IoC (제어의 역전)
그래서 스프링이 말해요: "객체 만드는 건 내가 할게." 객체 생성·관리의 제어권이 개발자 → 스프링으로 넘어가요. 그래서 '역전'이에요.
[예전] 개발자 → 객체 생성 [스프링] 스프링 → 객체 생성 (제어권이 넘어감 = IoC)
4단계 — DI (의존성 주입)
스프링이 객체를 만들었으면, 필요한 곳에 넣어줘야 해요.
class Car {
  private Engine engine;
  public Car(Engine engine) { this.engine = engine; }   // Car는 Engine이 필요
}
예전엔 new Engine() 해서 내가 넣었죠. 스프링에선 Engine 생성 → Car 생성 → Engine을 Car에 넣어줌을 스프링이 대신 해요. 이게 DI(의존성 주입)예요.

IoC와 DI의 관계 — 같은 게 아니에요
많은 초보자가 IoC = DI로 오해하는데, 사실은 포함 관계예요.
IoC (큰 개념: 객체를 스프링이 관리) └── DI (그걸 실현하는 대표 방법)
🏢 회사 비유
예전엔 직원이 의자·컴퓨터·책상을 직접 샀어요. 회사에선 직원이 "컴퓨터 필요합니다" 하면 총무팀이 준비해서 지급하죠.
직원: "컴퓨터 필요합니다" ↓ 총무팀: 준비해서 지급 · 총무팀이 관리하는 것 → IoC · 필요한 걸 직원에게 가져다줌 → DI
👉 핵심 한 줄: IoC = 객체를 만들고 관리하는 주체가 개발자 → 스프링으로 바뀌는 것. DI = 스프링이 필요한 객체를 만들어 넣어주는 것(IoC를 실현하는 방법).
📘 더 깊게 — 강한/느슨한 결합, 주입 3가지 방법(생성자·필드·세터), @AutowiredCH 02 「IoC와 DI」 에서 이어져요.
▲ 접기
🌿
생태계
스프링은 하나가 아니라 "생태계"예요
특히 Spring Boot가 요즘의 표준 출발점이에요.
이름역할
Spring FrameworkIoC/DI 컨테이너 등 핵심 기반. 모든 것의 뿌리.
Spring Boot복잡한 설정을 자동으로 해주고 바로 실행되게 해줌. 요즘의 출발점. (CH 05)
Spring Data (JPA)데이터베이스 접근을 간편하게. (CH 08)
Spring Security인증·인가(로그인·권한) 처리.
💡
Spring Framework vs Spring Boot. Spring Boot는 별개가 아니라, Spring Framework를 더 쉽게 쓰도록 감싼 것이에요. 설정을 자동으로 해줘서 "설정 지옥"을 없애줘요. 실무 프로젝트는 대부분 Spring Boot로 시작해요.
🌱
역사
복잡함에 대한 반발로 태어났어요
이름 "Spring"에는 "겨울(복잡한 옛 기술) 다음의 봄"이라는 의미가 담겨 있어요.
2002~03
🌱 로드 존슨(Rod Johnson)이 시작
당시 자바 엔터프라이즈 표준이던 EJB가 너무 무겁고 복잡했어요. 로드 존슨이 책에서 대안을 제시했고, 그게 스프링 프레임워크로 발전했어요. 가볍고(POJO 기반) 실용적인 게 핵심 철학이었어요.
2014
🚀 Spring Boot 등장
스프링의 강력함은 좋지만 설정이 여전히 번거로웠어요. Spring Boot가 설정을 자동화하고 내장 서버까지 넣어주면서, 스프링이 훨씬 쉬워졌어요.
지금
🏢 자바 백엔드의 사실상 표준
국내외 대부분의 자바 백엔드가 Spring Boot로 만들어져요. 채용에서도 자바+스프링은 최상위 수요예요.
🔤
EJB(Enterprise JavaBeans) — 스프링 이전에 자바 서버 개발의 표준이던 기술이에요. 강력하긴 했지만 규칙이 많고 설정이 복잡해서 "무겁다"는 원성이 자자했어요. 스프링은 바로 이 무거움에 대한 가벼운 반발로 태어났어요.
🔤
POJO(Plain Old Java Object) — 직역하면 "그냥 평범하고 오래된 자바 객체"예요. 특정 프레임워크의 규칙(꼭 무엇을 상속해라 등)에 얽매이지 않는 순수한 자바 객체를 뜻해요. EJB처럼 무거운 규약이 없어서 가볍고 테스트하기 쉬운 것이 장점이에요.
👤
스프링을 만든 사람은 로드 존슨(Rod Johnson)이에요. 무거운 EJB에 대한 가볍고 실용적인 대안으로 출발했다는 맥락을 기억하면 스프링의 성격이 이해돼요.
🧠 이 장 핵심 요약
📝
문제풀이 · 점검
배운 걸 가볍게 점검해봐요
시험이 아니라 "내가 이해했나" 확인용이에요. 틀려도 바로 해설이 나와요.
🧪
문제를 풀면 즉시 정답과 해설이 나오고, 위쪽 바에 점수가 쌓여요. 네 가지 유형(객관식 · O/X · 빈칸 · 개념)을 섞어 두었어요.
CH 02 💉 IoC와 DI — 스프링의 심장을 코드로 제대로 파헤치기