풀스택 백엔드 2026.06.11

[SECTION 05. 스프링을 이해하는 첫 걸음 — 싱글톤 패턴]

대표적인 디자인 패턴

패턴	한 줄 설명
싱글톤 (Singleton)	객체를 딱 1개만 생성해서 공유
팩토리 (Factory)	객체 생성을 별도 클래스에게 위임
전략 (Strategy)	알고리즘을 캡슐화해서 바꿔 끼울 수 있게
옵저버 (Observer)	상태 변화를 다른 객체에게 자동으로 알림
데코레이터 (Decorator)	기존 코드 변경 없이 기능을 동적으로 추가

이 중에서 스프링을 이해하는 데 가장 중요한 패턴이 바로 싱글톤

---

• 싱글톤(Singleton) = 애플리케이션 전체에서 특정 클래스의 인스턴스가 딱 1개만 존재하도록 보장하는 패턴

객체가 1개만 생성되고 모든 요청이 이 객체를 공유합니다.

SECTION 01의 서블릿에서 이미 경험했습니다. 서블릿도 Tomcat이 싱글톤으로 관리합니다. init()이 딱 1번만 호출되고,이후 모든 요청은 같은 서블릿 객체가 처리하는 것이 바로 그 예입니다.

---

@Component vs @Bean

	@Component	@Bean
붙이는 위치	내가 만든 클래스에 직접	@Configuration 클래스 안의 메서드에
대상	내가 만든 클래스	외부 라이브러리 클래스
예시	MemberService, MemberRepository	DataSource, HikariCP

---

섹션 정리

개념	핵심 내용
디자인 패턴	반복되는 설계 문제의 검증된 해결책
싱글톤 패턴	인스턴스를 딱 1개만 생성해서 공유하는 패턴
private 생성자	외부에서 new로 객체 생성을 막음
getInstance()	유일한 인스턴스를 반환하는 메서드
stateless	싱글톤은 상태를 갖지 않아야 안전
스프링 빈	스프링이 자동으로 싱글톤으로 관리하는 객체
@Component	내가 만든 클래스를 스프링 빈으로 등록
@Bean	외부 라이브러리 클래스를 스프링 빈으로 등록

---

[SECTION 06. 자바의 봄, 스프링(Spring)의 등장]

• EJB = Sun Microsystems(현 Oracle)가 만든 Java EE(Java Enterprise Edition)의 핵심 기술로, 분산 처리, 트랜잭션, 보안 등 기업용 기능을 제공

---

EJB의 문제점 정리

문제	내용
복잡성	비즈니스 로직보다 EJB 규칙을 따르는 코드가 더 많음 (종속성)
특정 환경 종속	EJB 컨테이너 없이는 테스트조차 불가능
무거움	서버 시작에만 수십 분이 걸림
비싼 비용	EJB 서버(WebLogic 등) 라이선스 비용이 매우 비쌈
객체지향 파괴	EJB 규칙에 맞추다 보면 순수한 Java 객체를 만들 수 없음

---

• POJO = 특정 프레임워크나 규약에 종속되지 않은 순수한 Java 객체

---

스프링의 핵심 기능 3가지

1. IoC / DI (제어의 역전 / 의존성 주입)

EJB:    개발자가 직접 객체를 생성하고 관리
스프링: 스프링 컨테이너가 객체를 생성하고 관리해줌

2. AOP (관점 지향 프로그래밍)

EJB:    로그, 트랜잭션 코드가 비즈니스 로직에 뒤섞임
스프링: 공통 관심사(로그, 트랜잭션)를 비즈니스 로직과 분리

3. PSA (일관된 서비스 추상화)

EJB:    특정 DB, 특정 서버에 종속적
스프링: 어떤 DB, 어떤 환경에서도 동일한 방식으로 개발 가능

---

스프링 vs 스프링 부트

	스프링 (Spring)	스프링 부트 (Spring Boot)
출시	2004년	2014년
설정	개발자가 직접 설정	대부분 자동 설정
Tomcat(WAS)	별도 설치 필요	내장 Tomcat 포함
실행	war 파일 → 서버에 배포	jar 파일 → 단독 실행
의존성	버전 직접 관리	스타터가 버전 관리
시작 방법	직접 설정	Spring Initializr
관계	뿌리	스프링을 편하게 쓰는 도구

중요: 스프링 부트는 스프링을 대체하는 게 아닙니다.
스프링 부트는 스프링을 더 편하게 사용하기 위한 도구입니다.
내부적으로는 여전히 스프링이 동작하고 있습니다.

---

섹션 정리

개념	핵심 내용
EJB	스프링 이전의 Java 엔터프라이즈 기술. 복잡하고 무거웠음
로드 존슨	스프링의 창시자. 2002년 책에서 스프링의 원형을 공개
Spring	EJB의 겨울이 끝나고 찾아온 봄. Yann Caroff가 제안
POJO	프레임워크에 종속되지 않은 순수한 Java 객체
스프링 3대 핵심	IoC/DI, AOP, PSA
스프링 부트	스프링의 복잡한 설정을 자동화한 도구. 2014년 출시
스타터	검증된 의존성 묶음. 버전 충돌 걱정 없음
내장 Tomcat	jar 파일 하나로 서버 없이 실행 가능

---

[SECTION 07. 스프링의 핵심 — IoC 컨테이너와 DI 이해하기]

• IoC(Inversion of Control, 제어의 역전) = 객체의 생성과 관리를 개발자가 아닌 프레임워크(스프링)에게 맡기는 것

• DI(Dependency Injection, 의존성 주입) = 객체가 필요로 하는 다른 객체를 외부에서 만들어서 넣어주는 것

---

스프링 어노테이션 정리

어노테이션	용도	비고
@Component	일반 컴포넌트 등록	가장 기본
@Service	서비스 레이어 등록	@Component와 동일, 역할 명시용
@Repository	DB 접근 레이어 등록	@Component와 동일, 역할 명시용
@Controller	웹 컨트롤러 등록	@Component와 동일, 역할 명시용
@Autowired	의존성 자동 주입	생성자/필드/setter에 사용
@Configuration	설정 클래스 선언	@Bean 메서드를 포함하는 클래스
@ComponentScan	컴포넌트 자동 탐색 범위 지정	패키지 지정
@Bean	외부 라이브러리를 빈으로 등록	@Configuration 안에서 사용

@Service, @Repository, @Controller 는 모두 @Component 를 포함하고 있어요.
기능은 같지만 "이 클래스가 어떤 역할인지" 를 명확히 표현하기 위해 구분해서 씁니다.

---

섹션 정리

개념	핵심 내용
IoC	객체의 생성/관리 권한을 개발자 → 스프링으로 역전
DI	필요한 객체를 직접 생성하지 않고 외부에서 주입받음
스프링 컨테이너	빈을 생성하고 관리하는 스프링의 핵심
@Component 계열	스프링 컨테이너에 빈으로 등록하는 어노테이션
@Autowired	스프링이 자동으로 의존성을 주입하게 하는 어노테이션
생성자 주입	권장하는 DI 방식, final 사용 가능
@ComponentScan	지정한 패키지에서 @Component 계열을 자동 탐색

---

[SECTION 08. 인터페이스로 유연하게, 스프링 MVC]

@RequestParam vs @PathVariable 비교

	@RequestParam	@PathVariable
URL 형태	/search?keyword=스프링	/member/1
용도	검색, 필터, 페이징	특정 리소스 조회
필수 여부	선택적 (defaultValue 가능)	필수
REST API	덜 사용	자주 사용

---

섹션 정리

개념	핵심 내용
인터페이스 + DI	구현체를 바꿔도 Service 코드 변경 없음
Spring Initializr	스프링 부트 프로젝트를 웹에서 쉽게 생성
build.gradle	Maven pom.xml의 Gradle 버전, 더 간결
DispatcherServlet	스프링 MVC의 프론트 컨트롤러, 모든 요청의 입구
@Controller	스프링 MVC 컨트롤러 등록
@GetMapping	GET 요청 URL 매핑
@PostMapping	POST 요청 URL 매핑
@RequestMapping	공통 URL 접두사 지정
Model	컨트롤러 → 뷰로 데이터 전달
@RequestParam	쿼리 파라미터 (?key=value) 받기
@PathVariable	URL 경로 변수 (/member/{id}) 받기
타임리프	JSP를 대체하는 뷰 템플릿 엔진