김영한 스프링 핵심 원리 - 기본편 복기

 

약 3주 정도 전에 본 거 같은데 도움이 너무 되었지만 점점 기억에서 없어져 가는 거 같아 다시 복기 할 겸 강의 후기를 작성해보려고 한다.

 

이번 강의 한 줄 평: 기존 코드를 변경하지 않고 유연한 코드 변경을 하게 해주는 스프링. 꼈다 끼웠다.

1. 객체 지향 설계와 스프링

 

우선 첫 번째 색션에서는 어떻게 스프링이 탄생하게 되었는지에 대한 이야기를 해준다.

 

기본 복잡하고 사용하기 어렵고 비싼 서버를 사용하다가 진절머리난 로드 존슨이라는 분이 스프링을 만들어내게 된 서사를 들었다.

 

힘든 겨울이 지내고 나온 것이라고 하여 스프링(spring)이라고 하였나? 재밌다.

 

기존에는 책으로 출발하였는데 이게 오픈소스 프로젝트가 되고 점점 커져 스프링이 되었다고 한다.

 

옛날 이야기 듣듯이 들었다.

 

이후 스프링 개념 정의. 스프링과 스프링 부트의 차이점을 설명해주고

 

객체 지향의 특징을 여러 비유, 자동차라는 인터페이스와 테슬라, 아반떼와 같은 구현체들로 비유하며 설명해주었다. 현실 세계에 있는 객체 지향 구현법? 이랑 비유를 들어줘서 잘 와닿았다. 공연 무대. 로미오 역할이 인터페이스, 연기하는 사람이 구현.

 

이렇게 역할과 구현으로 구분하는 개념을 잘 확립할 수 있었다.

 

결국 스프링이 구현체가 변경되더라도 이 구현체와 연결되어 있는 다른 코드를 변경하지 않고 깔끔하고 쉽게 다형성을 관리해주는 단순 라이브러리가 아니라 Ioc(Inversion of Control)까지하는 프레임워크라는 것이다.

 

어떠한 제한 상황, 변화된 상황이 오더라도 깔끔하고 유연하게 대처할 수 있도록 하는 것인 듯하다.

 

2. 스프링 핵심 원리 이해1 - 예제 만들기

이 색션에서는 함께 순수 자바 코드를 한땀씩 짜보며 스프링이 없던 시절 결국 다다를 DIP 원칙과 OCP 원칙 준수의 불가능함을 보여주고 스프링의 필요성을 몸소 느끼게 해준다.

 

역할과 구현을 각각 구현하고 단일 책임의 원칙(SRP)을 잘 준수하며 코드 작성을 진행을 하지만 결국에는 구현체를 바꿔야할 시에 직접 코드를 수정해야하는 OCP 원칙 위배와, 결국 구현체에 의존하고 있는 DIP 원칙 위배를 보여준다.

 

3. 스프링 핵심 원리 이해2 - 객체 지향 원리 적용

 

AppConfig라는 공연 기획자를 만들었다.

 

기존에는 배우가 다른 배우까지 섭외를 해야했지만 이제 배우(구현체)를 섭외하는 사람들 따로 배정하여 각 배우들은 자신의 연기에만 집중할 수 있도록 한 것이다.

 

변경이 필요한 코드를 AppConfig로 따로 빼두어 같이 관리하여 이 파일을 제외하고는 OCP를 만족할 수 있도록 하였다.

 

지금은 순수 자바로 구현하여서 구현체 변경시 AppConfig를 변경해야하지만 스프링 프레임워크 사용시 Ioc를 통해서 스프링이 자동으로 사용하는 구현체를 스프링 컨테이너에 빈으로 등록하여 OCP를 만족하며 코드를 작성할 수 있도록 해준다.

 

4. 스프링 컨테이너와 스프링 빈

 

이 색션에서는 공연 관리자(AppConfig), 스프링 컨테이너가 스프링 빈(배우)들을 어떻게 관리하고 있는지 내부 구조를 설명해주고 있다.

 

여긴 잘 기억 안 남 ㅎ

 

5. 싱글톤 컨테이너

이 색션에서는 스프링의 기본 빈 등록 방식인 싱글톤 패턴 설명으로 스프링 빈을 싱글톤 패턴으로 관리하여 하나의 객체를 사용하여 요청들에 효율적으로 응답하는 방법을 보여준다.

 

그러나 하나의 객체를 공유하는 만큼 Stateless는 지켜야함을 말해준다.

 

6. 컴포넌트 스캔

 

이 색션에서는 컴포넌트 스캔을 통해서 스프링 빈을 스프링 컨테이너에 자동 등록하는 법을 알아보았다 기존에는 AppConfig에서 수동으로 코드를 작성하여 등록해야했지만 @Component 어노테이션을 통해 자동화에 다다랐다.

 

또한 이를 @Autowired 어노테이션을 통해 스프링 컨테이너에 있는 스프링 빈 의존 관계 자동 주입을 하는 법도 알아보았다.

 

7. 의존 관계 자동 주입

 

이번 챕터에서는 다양한 의존 관계 주입 방법이 있지만 어떤 상황에 어떤 것이 가장 좋은 방법이 될지 알아보았다.

 

기본적으로는 스프링에 너무 의존하지 않고 불변성(final 사용)을 지키는 생성자 주입이 정석적이고 좋은 방법이라고 생각하면 될 듯하다.

 

필드 주입도 비슷하게 쓸 수 있을 것 같지만 스프링에서는 빈 생성 단계와 의존 관계 주입 단계가 나눠져 있기 때문에 final 속성을 달지 못해 불변성을 확보할 수 없다.

 

참고로 생성자 주입을 하게 되면 빈 생성 단계에서 의존 관계 주입이 발생한다.

 

8. 빈 생명주기 콜백

이 색션에서는 

 

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존 관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

 

이 스프링 생명 주기에서 초기화 콜백, 소멸전 콜백에 대해 다루고 있다.

 

기본적으로 객체에 대한 초기화를 생성자에서 다 해서 생성자에게 무리를 주지 말고(생성자 주입을 하지 말라는 건 아님, 모든 걸 생성자에서 하지 말라는 말) 초기화 작업 같은 건 초기화 콜백에서 하라는 말이다.

 

또한 소멸전 콜백도 사용해 스프링 빈이 적절히 잘 종료될 수 있도록 해야한다.

 

9. 빈 스코프

 

마지막 색션에서는 스프링 컨테이너의 기본 싱글톤 패턴의 빈 관리말고 다른 빈 스코프에 대해서 알아본다.

 

싱글톤 패턴은 시작 후 끝나기 전까지 쭉, 프로토타입은 요청시에만 잠시 나타나는 일회성 빈, 그리고 웹 스코프는 요청이 들어올 때 잠시 생성되는 빈인데 서버 시작 시 해당 요청(고객)을 받을 담당원 빈 같은 것이다. 그래서 요청을 처리할 담당원을 연결해줄 프록시가 필요하다 <- HTTP 요청이 들어오면 담당원 연결해줄 수 있도록 대기해야함.

 

또한 싱글톤 패턴과 함께 프로토타입을 쓸 때의 주의점. 즉 싱글톤 빈이 프로토타입 빈을 주입 받게 되면 프로토타입처럼 일회성으로 계속 객체를 생성해야하지만, 싱글톤 패턴에 주입되어 계속 유지되는 현상이 있는데 이를 해결하는 Provider를 알아보았다. 이는 미리 프로토타입 빈을 싱글톤에 주입시켜 놓는 것이 아니라 필요할 때마다 컨테이너에서 가져와 생성하도록 해주는 대리인 역할이다.

 

강의 중 인텔리제이 단축키 꿀팁

커멘드 + X: 해당 줄 제거

커멘드 + D: 해당 줄 복사

커멘드 + 쉬프트 + 엔터: 문장 마무리

옵션 + 엔터: 뭐 안 된다 싶으면 이거

옵션 + 커멘드 + v: 함수에서 나온 값 받을 변수 생성

커멘드 + E: 이전 파일

 

 

출처: https://www.inflearn.com/course/스프링-핵심-원리-기본편/dashboard?cid=325969