김영한의 스프링 핵심 원리(기본편) - 총 정리

1) OOP 핵심 개념

다형성

• 상속, 오버라이딩, 오버로딩
• 인터페이스(역할) / 구현체(구현) 분리 → 변경/확장 용이, 코드 재사용

OCP

• 확장에는 열려있고 변경에는 닫혀있음
• 기능 추가는 쉽게, 코어 로직 수정은 최소화/없게

DIP

• 구현체가 아니라 추상체(인터페이스)에 의존
• 결과적으로 OCP 만족에 유리

다형성은 지키지만 OCP를 못 지키는 케이스

• 인터페이스는 쓰지만 “구현체 선택/교체”가 코어 로직에 하드코딩됨
• 해결: 구현체 결정은 외부(AppConfig 등)로 빼고 주입(Injection)으로 처리

IoC

• 객체 생성/흐름 제어를 개발자가 아니라 프레임워크(컨테이너)가 담당
• 구현체 교체 지점은 코어 로직이 아니라 설정(AppConfig 등)에서 관리

DI

• 컴파일 타임에는 추상체만 의존(정적으로는 결합 낮음)
• 런타임에 실제 구현체를 생성해서 주입

---

2) 싱글톤

싱글톤 패턴 장점

• 인스턴스 1개만 생성 → 메모리/생성 비용 절감
• 전역 공유 → 상태/설정/캐시 일관성 유지 쉬움

싱글톤 패턴 단점

• 전역 상태 → 결합도 증가, 테스트 어려움(대체/격리 어려움)
• 멀티스레드 환경에서 동기화/초기화 순서 이슈 위험

싱글톤 패턴/컨테이너 주의점

• 여러 스레드에서 공유될 수 있으므로 stateless로 설계해야 함

@Configuration 과 싱글톤

• @Configuration 없으면 @Bean이 여러 번 new 될 수 있음
• @Configuration 있으면 CGLIB 바이트코드 조작으로 빈을 싱글톤으로 보장

---

3) 의존성 주입 방식

필드 주입 단점

• 외부에서 변경/주입이 어려움 → 테스트 제약(스프링 컨텍스트 의존)

생성자 주입을 쓰는 이유

• 주입은 1회로 고정(변경 불가 전제)
• final 가능 → 누락 시 컴파일 단계에서 잡힘

---

4) 빈 등록 전략

자동 빈 등록이 좋은 케이스

• 컨트롤러/서비스/레포지토리 같은 업무 로직 빈
• 패턴이 유사하고 흐름이 명확 → 문제 추적 쉬움

수동 빈 등록이 좋은 케이스

• AOP, DB, 로깅 등 기술 지원 빈
• 전역 영향 범위 큼 → 위치/구성 파악을 위해 명시적으로 관리하는 게 유리

---

5) 스프링 빈 라이프사이클

라이프사이클 흐름

• 컨테이너 생성 → 빈 생성 → 의존관계 주입 → 초기화 콜백 → 소멸 전 콜백 → 종료

초기화 콜백 활용 예

• 캐시 워밍업
• 커넥션 풀 선생성 등

---

6) 스프링 빈 스코프

싱글톤(Singleton)

• 기본 스코프
• 컨테이너 시작~종료까지 유지

프로토타입(Prototype)

• 생성 + 의존관계 주입까지만 컨테이너 관여, 이후 관리 X
• 상태가 꼭 필요하면 “필요할 때 생성해서 쓰고 버리는” 용도로 고려

웹 스코프(Web)

• request: 요청 시작~끝까지
• session: 세션 생성~종료까지
• application: 서블릿 컨텍스트 범위(웹에서만)
  • 사실상 전역 공유 성격으로 싱글톤과 유사 (웹 환경에서 의미 있음)

 

---

 

 

1) OOP

문제

1. 다형성의 핵심 목적을 한 문장으로 설명하라.
2. 오버라이딩과 오버로딩의 차이를 말하라.
3. OCP의 정의를 쓰고 핵심 의미를 한 줄로 설명하라.
4. DIP의 핵심 문장을 짧게 쓰라.
5. DIP가 OCP에 유리한 이유를 한 줄로 말하라.
6. “다형성은 지키지만 OCP는 깨지는” 대표 상황을 적어라.
7. 위 상황을 해결하는 스프링식 접근을 한 줄로 말하라.
8. IoC의 정의를 간단히 말하라.
9. DI를 “정적/런타임” 관점으로 구분해 설명하라.

답

1. 역할(인터페이스)과 구현(구현체)을 분리해 구현 교체/확장을 쉽게 만드는 것.
2. 오버라이딩은 상위 메서드 재정의, 오버로딩은 같은 이름을 파라미터로 구분해 여러 개 정의.
3. 확장에는 열려 있고 변경에는 닫혀 있어야 한다 / 기능 추가는 가능하지만 코어 로직 수정은 최소화.
4. 구현체가 아닌 추상체(인터페이스)에 의존한다.
5. 추상체 의존이면 구현 교체로 확장이 가능해 코어 로직 변경이 줄어든다.
6. 인터페이스는 쓰지만 구현체 선택/교체 로직이 코어 로직에 하드코딩된 경우.
7. 구현체 결정은 AppConfig 같은 외부로 빼고 DI로 주입한다.
8. 객체 생성 및 흐름 제어를 개발자가 아니라 프레임워크(컨테이너)가 담당하는 것.
9. 정적으로는 추상체에만 의존하고, 런타임에 실제 구현체를 생성해 주입한다.

---

2) 싱글톤

문제

1. 싱글톤 패턴의 장점 2가지를 쓰라.
2. 싱글톤 패턴의 단점 2가지를 쓰라.
3. 싱글톤 컨테이너에서 빈 설계 시 주의점 1가지를 쓰라.
4. @Configuration이 싱글톤 보장과 연결되는 이유를 한 줄로 말하라.
5. @Configuration이 없을 때 생길 수 있는 문제를 한 줄로 말하라.

답

1. 인스턴스 1개로 메모리/생성 비용 절감, 전역 공유로 상태/설정/캐시 일관성 유지 용이.
2. 전역 상태로 결합도 증가·테스트 어려움, 멀티스레드 동기화/초기화 이슈 위험.
3. 여러 스레드가 공유하므로 stateless로 설계해야 한다.
4. CGLIB 바이트코드 조작으로 @Bean이 여러 번 new 되지 않게 보장한다.
5. @Bean 메서드 호출 시 동일 객체가 여러 번 new 될 수 있다.

---

3) 의존성 주입 방식

문제

1. 필드 주입의 단점 1가지를 쓰라.
2. 생성자 주입을 권장하는 이유 2가지를 쓰라.

답

1. 외부에서 변경/주입이 어려워 테스트가 스프링 컨텍스트에 의존하기 쉽다.
2. 주입이 1회로 고정되고, final로 선언 가능해 누락 시 컴파일 에러로 잡힌다.

---

4) 빈 등록 전략

문제

1. 자동 빈 등록이 적합한 빈 유형을 예시 3개로 쓰라.
2. 수동 빈 등록이 적합한 빈 유형을 예시 3개로 쓰라.
3. 기술 지원 빈을 수동 등록하면 좋은 이유를 한 줄로 말하라.

답

1. Controller, Service, Repository(업무 로직 빈).
2. AOP, DB, 로깅(기술 지원/인프라 빈).
3. 전역 영향이 커서 구성/위치를 명시적으로 관리하는 게 추적과 유지보수에 유리하다.

---

5) 스프링 빈 라이프사이클

문제

1. 스프링 빈 라이프사이클 흐름을 순서대로 쓰라.
2. 초기화 콜백에서 할 수 있는 작업 2가지를 쓰라.

답

1. 컨테이너 생성 → 빈 생성 → 의존관계 주입 → 초기화 콜백 → 소멸 전 콜백 → 종료.
2. 캐시 워밍업, 커넥션 풀 사전 생성 등.

---

6) 스프링 빈 스코프

문제

1. 싱글톤 스코프의 범위를 말하라.
2. 프로토타입 스코프에서 컨테이너가 관리하는 범위를 말하라.
3. 프로토타입 스코프를 고려할 수 있는 대표 상황을 한 줄로 쓰라.
4. 웹 스코프 3가지를 쓰고 각각의 범위를 한 줄씩 설명하라.
5. application 스코프가 싱글톤과 유사해 보이는 이유를 한 줄로 말하라.

답

1. 스프링 컨테이너 시작부터 종료까지 유지.
2. 생성과 의존관계 주입까지만 관여하고 이후 생명주기 관리는 하지 않는다.
3. 상태가 필요한 객체를 필요 시점에 생성해 쓰고 버리고 싶을 때.
4. request: 요청 시작~종료 / session: 세션 생성~종료 / application: 서블릿 컨텍스트 범위.
5. 웹 애플리케이션 전역(서블릿 컨텍스트)으로 공유되는 전역 범위 성격이라서.