[inflearn] 스프링 핵심 원리 - 기본편 review

✅ 강의 소개

초급자를 위해 준비한 [웹 개발, 백엔드] 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다.

 

✅ 강의별 후기

[ 객체 지향 설계와 스프링 ]

스프링이 만들어진 역사와 스프링의 생태계, 프레임워크에 대해 학습.
좋은 객체 지향 어플리케이션을 개발하기 위한 개념들을 이해 및 복습
- 추상화, 캡슐화, 상속, 다형성
- 다형성의 본질 (유연한 변경)
- 객체를 설계할 때, 역할과 구현을 명확히 분리.
- SOLID 원칙
SRP(변경에 따른 파급효과 최소화)
OCP(확장에는 열려있고 변경에는 닫혀있음)
LSP(프로그램의 정확성, 다형성의 인터페이스 규약)
ISP(여러개의 인터페이스)
DIP(추상화에 의존)

---

[ 스프링 핵심 원리 이해 ]

기본적인 환경 설정을 진행.
요구사항에 따라 회원과 주문, 할인 도메인을 설계, 개발하고 테스트.
각 도메인별 협력 관계와 다이어그램에 대해 이해.
역할과 구현을 분리하며 SOLID 원칙을 준수하며 리팩토링.

- 비즈니스 요구사항을 바탕으로 도메인을 설계하고 개발, 테스트하는 방법들을 배울 수 있었다. 특히, 요구사항이 변할 것을 고려해서 DIP 원칙을 지키며 할인 정책(DiscountPolicy)을 설계했다.

- 역할과 구현을 분리, 다형성을 활용하여 인터페이스와 구현 객체를 분리.

- 클래스의 의존 관계를 구체(구현)클래스가 아닌 추상(인터페이스)에만 집중해서 OCP원칙 준수.

- 관심사를 분리하기 위한 AppConfig를 통해 어플리케이션의 사용 영역과 구성 영역을 구분

- 마지막으로 스프링을 적용하여 IoC와 DI, 컨테이너에 대해 학습했다.

---

[ 스프링 컨테이너와 스프링 빈 ]

스프링 컨테이너를 생성하고 스프링이 제어하는 빈들에 대한 이해
스프링 빈을 조회할 때, 동일한 타입을 조회하거나 상속 관계에 따라 조회
ApplicationContext와 BeanFactory, BeanDefinition을 기반으로 스프링 빈 조회

---

[ 싱글톤 컨테이너 ]

웹 어플리케이션 특징에 맞는 싱글톤 패턴에 대한 이해
싱글톤 컨테이너와 주의점
@Configuration과 싱글톤, 바이트코드 조작

- 싱글톤 패턴을 직접 코드로 구현해보고, 이에 대한 단점들을 싱글톤 기반의 스프링 컨테이너를 활용하여 해결했다.

- 싱글톤 객체의 상태를 유지하기 위해 무상태로 설계해야 한다.

- @Configuration으로 설정한 클래스는 스프링이 CGLIB이라는 바이트 코드 조작 라이브러리를 사용해서 임시로 빈 등록하여 싱글톤을 보장한다.

- 단순히 @Bean만 사용하면 스프링 빈으로 등록하지만, 싱글톤을 보장하지 않는다.

---

[ 컴포넌트 스캔 ]

컴포넌트 스캔과 의존관계 자동 주입에 대한 이해
@ComponentScan으로 스프링 빈 등록 및 @Autowired로 빈 조회
컴포넌트 스캔의 기본 대상들
컴포넌트 스캔의 기본적인 탐색 위치와 필터
중복으로 등록되는 빈

- @SpringBootApplication 설정 안에 @ComponentScan이 있고, 스프링의 부가 기능을 담당하는 어노테이션도의 설정에도 @Component가 있어서 자동으로 스프링 빈에 등록되는 점을 알게 됐다.

@Component, @Controller, @Service, @Repository, @Configuration

- 또한, 자동 빈 등록과 수동 빈 등록으로 인해 중복된 이름을 가진 빈이 등록될 경우, 기존에는 수동 빈 등록이 우선권을 가졌지만, 이제는 오류가 발생하여 사전에 버그를 방지한다는 점을 알았다.

---

[ 의존관계 자동 주입 ]

다양한 의존관계 주입 방법과 각각의 특징에 대한 이해.
lombok을 이용한 방법과 @Autowired 적용 우선순위를 정하는 @Primary, @Qualifier
실무에서 자동/수동으로 빈을 등록하는 올바른 운영 기준

- 의존관계를 주입하는 4가지 방법(생성자/수정자/필드/일반 메서드)에 대해 이해했고, 불변과 누락, final 키워드 사용을 위해 생성자 주입을 적극 활용하기.

- 필수 값이 아닌 경우에는 수정자 주입 방식을 Optional로 부여.

- lombok(@RequiredArgsConstructor)을 통해 final로 선언된 변수들에 대해 생성자를 만들어주며, 생성자가 1개만 있으면 자동으로 의존관계가 주입된다.

- 조회되는 빈 타입이 2개 이상일 경우, 어노테이션을 통해 해결할 수 있다.

@Autowired: 타입 매칭을 시도하고, 필드명, 파라미터명으로 매칭

@Qualifier: @Qualifier끼리 매칭

@Primary: 최우선 매칭

- 조회한 빈이 모두 필요할 경우, List, Map을 활용해서 전략 패턴을 구현한다.

- 실무에서 자동/수동으로 빈을 등록하는 올바른 운영 기준

업무 로직 빈: 웹을 지원하는 로직은 숫자가 많고 다양하여 자동 빈 등록을 적극 사용한다. 하지만, 다형성을 적극 활용하는 비즈니스 로직은 수동 빈 등록을 고민해본다.

기술 지원 빈: 보통 어플리케이션 전반에 걸쳐서 활용되므로 기술 지원 로직에서 문제가 발생할 경우, 원인을 파악하기 어렵다. 이를 위해 수동 빈 등록을 하여 문제 원인을 명확하게 드러내는데 사용한다. 

---

[ 빈 생명주기 콜백 ]

빈이 등록되고, 초기화, 소멸되는 생명주기에 대한 이해.
인터페이스와 어노테이션 기반으로 빈의 생성, 소멸 시점을 관리.
스프링 컨테이너 생성 > 스프링 빈 생성 > 의존관계 주입 > 초기화 콜백 > 사용 > 소멸전 콜백 > 스프링 종료

- 스프링 빈은 객체을 생성하고, 의존관계 주입이 다 끝난 시점에서 준비가 완료된다. 이처럼 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 알게됐다. (객체의 생성과 초기화를 분리)

인터페이스: InitializingBean, DisposableBean > 스프링 전용 인터페이스, 초기화/소멸 메서드명 변경 불가, 외부 라이브러리에 적용 불가

설정 정보: 초기화 메서드, 종료 메서드 지정 > @Bean(initMethod = "init", destroyMethod = "close"), 외부 라이브러리에 적용 가능

어노테이션: @PostConstruct, @PreDestroy > 가장 권장하는 방법, 대신 외부 라이브러리에 적용 불가

---

[ 빈 스코프 ]

빈 스코프에 따라 빈 생명주기에 대한 이해.
프로토타입 스코프 활용과 문제점 및 해결방법을 학습.
웹 스코프와 Provider, 프록시 활용.

- 싱글톤 스코프의 빈은 요청에 대해 항상 같은 인스턴스를 반환하지만, 프로토타입 스코프 빈은 항상 새로운 인스턴스를 생성한다. 대신, 스프링 컨테이너가 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다. 그래서 @PreDestory같은 소멸 메서드가 호출되지 않는다.

- 싱글톤 빈이 의존관계가 주입을 통해 프로토타입 빈을 주입받게되면 의도와 다르게 동작한다. 이를 해결하기 위해 ObjectProvider 또는 자바에서 제공하는 Provider를 활용하여 스프링 컨테이너에서 직접 필요한 의존관계를 찾는다. (Lookup, DL)

- 웹 환경에서만 동작하며, HTTP request 하나가 들어오고 나갈 때까지 유지되는 스코프는 request scope라고 한다.

- 스프링 어플리케이션을 실행하는 시점에 request 스코프 빈은 생성되지 않는다. 이를 위해 Provider를 활용하거나 프록시 방식을 사용한다.(proxyMode = ScopeProxyMode.TARGET_CLASS)

- 프록시 방식은 CGLIB라는 라이브러리로 가짜 프록시 객체를 만들어 임시로 빈에 등록하며, 요청이 오면 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다.

---

 

✅ review

 실무에서 스프링 부트를 기반으로 개발하는 경우, 가끔 어노테이션과 의존관계 주입 등을 당연하게 생각해 왔다. 이런 점들을 명확히 알고, 고민하며 개발하고자 해당 강의를 수강했다.

 기존에 알고 있던 개념들을 더욱 명확하게 이해할 수 있었고, 배웠던 것들을 실무에서 어떻게 적용할지 고민하며 개발하게 됐다. 이미 JPA가 아닌 Mybatis를 사용하고, 객체 지향 원칙에 벗어나는 레거시 코드가 많아 어렵겠지만, 새로 개발하는 내용들은 최대한 스프링답게 개발하고자 한다.