Spring

[hyunjungkimm]

스프링부트

• Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 되고, 손 쉬운 빌드 구성을 위한 starter 종속성을 제공하고, 스프링과 외부 라이브러리를 자동 구성하여 버전 관리를 손쉽게 할 수 있어 스프링을 편리하게 사용할 수 있도록 지원한다.
• 간결한 설정, 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성

스프링의 핵심

• 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
• 스프링은 자바 언어(특징 : 객체 지향 언어) 기반의 프레임워크 = 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크

객체 지향

특징

1. 추상화

2. 캡슐화

3. 상속

4. 다형성

역할과 구현을 분리

• 운전자 - 자동차
• 역할과 구현을 구분하면 세상이 단순해지고, 유연해지며 변경이 편리해진다.
• 확장 가능한 설계
• 인터페이스를 안정적으로 잘 설계하는 것이 중요
• 장점
• 1. 클라이언트는 인터페이스(대상의 역할)만 알면 된다.
• 2. 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
• 3. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
• 4. 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

     자바 - 역할과 구현을 분리

• 자바 언어의 다형성을 활용
• 1. 역할 = 인터페이스
• 2. 구현 = 인터페이스를 구현한 클래스, 구현 객체
• 객체를 설계할 때 역할과 구현을 명확히 분리
• 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기
• 오버라이딩(재정의)된 메서드가 실행 = 다형성으로 인터페이스를 구현한 객체(인스턴스)를 실행 시점에 유연하게 변경 가능
• 다형성의 본질 = 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

  객체의 협력이라는 관계

• 혼자 있는 객체는 없다.
• 수 많은 클라이언트(요청)와 객체 서버(응답)는 서로 협력 관계를 가진다.

  한계

• 역할(인터페이스)자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다. -> 인터페이스를 안정적으로 잘 설계하는 것이 중요

객체 지향 프로그래밍

• 객체 지향 프로그래밍은 여러 개의 독립된 단위 = "객체"들의 모임
• 객체는 메시지를 주고 받고, 데이터를 처리할 수 있음 = 협력
• 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이(=컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법)하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용됨

스프링과 객체 지향

• 스프링의 IoC(제어의 역전), DI(의존관계 주입)은 다형성을 활용에서 역할과 구현을 편리하게 변경할 수 있게 해준다.

좋은 객체 지향 설계의 5가지 원칙 (SOLID)

SRP : 단일 책임 원칙(Single responsibility principle)

• 한 클래스는 하나의 책임만 가져야 한다. = 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

  OCP : 개방-폐쇄 원칙(Open/closed principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 문제점 : MemberService 클라이언트가 구현 클래스를 직접 선택하여 구현 객체를 변경하려면 코드를 변경해야한다. (다형성 o / OCP x)

  LSP : 리스코프 치환 원칙(Liskov substitution principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 함.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것.

  ISP : 인터페이스 분리 원칙(Interface segregation principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 인터페이스가 명확해지고, 대체 가능성이 높아짐.

  DIP : 의존관계 역전 원칙(Dependency inversion principle)

• 추상화에 의존해야지, 구체화에 의존하면 안된다. = 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
• 문제점 : MemberService 클라이언트가 구현 클래스를 직접 선택하여 인터페이스에 의존하지만, 구현 클래스에도 의존한다. (다형성 o / DIP x)

  결론

• 다형성만으로는 OCP, DIP를 지킬 수 없어서 쉽게 부품을 갈아 끼우듯이 개발할 수 없어서 뭔가가 더 필요하다. (=spring)

Spring DI

• Dependency Injection : 의존관계, 의존성 주입
• DI 컨테이너를 제공하여 자바 객체들을 컨테이너에 넣어놓고 연결, 주입 기능
• 다형성 + OCP/DIP를 가능하게 지원
• 클라이언트 코드의 변경없이 기능 확장

[hyunjungkimm]

관심사의 분리

문제점

1. DIP 위반 - 추상화에만 의존해야하는데 구체화에도 의존하고 있다.

2. OCP 위반 - 현재의 코드는 기능을 확장하려고 변경하면, 클라이언트 코드에 영향을 준다.

orderServiceImpl 코드를 변경해야 한다.

문제 해결 방법 - 관심사의 분리

객체의 생성과 연결하는 역할(구성영역 - AppConfig)과 실행하는 역할(사용영역)의 명확한 분리

• 변경 사항이 있어도 사용영역의 코드는 변경되지 않고 구성영역의 코드만 변경된다. OCP - 개방-폐쇄 원칙
• 기존에는 클라이언트가 의존하는 서버 구현 객체를 직접 생성하고, 실행하여 다양한 책임을 가졌지만, 관심사의 분리를 통해 클라이언트 객체는 자신의 역할을 실행하는 것만 집중, 권한이 줄어들었다.(책임이 명확해짐) SRP - 단일 책임 원칙

의존관계를 외부에서 주입해주는 것 같다고 해서 DI(Dependency Injection) - 의존관계 주입, 의존성 주입. DIP - 의존 관계 역전 원칙

제어의 역전 (IoC, Inversion Of Control)

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것

프레임워크 vs 라이브러리

• 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 제어의 역전 o, 프레임워크 o (JUnit)
• 내가 작성한 코드를 직접 제어의 흐름을 담당한다면 그건 프레임워크가 아니라 라이브러리

의존관계 주입(DI, Dependency Injection)

• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것
• 객체 인스턴스를 생성하고 , 그 참조값을 전달해서 연결한다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.

IoC 컨테이너, DI 컨테이너

• 객체를 생성하고 관리하면서 의존관계를 연결해주는 것 (AppConfig 같은 역할)
• @Configuration : 설정(구성)정보로 사용
• @Bean : 어노테이션이 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 등록된 객체를 스프링 빈이라고 한다.
• ApplicationContext : 스프링 컨테이너

[hyunjungkimm]

스프링 컨테이너

• BeanFactory, ApplicationContext = 스프링 컨테이너
• ApplicationContext는 BeanFactory 기능을 모두 상속 받아서 제공 + 부가 기능
  • BeanFactory : 스프링 빈을 관리하고 조회하는 스프링 컨테이너 최상위 인터페이스
• AnnotationConfigApplicationContext는 구현체
• 다양한 형식 지원 (자바코드, xml) - 스프링의 유연한 설계

스프링 컨테이너 생성 과정

1. 스프링 컨테이너 생성

2. 스프링 빈 등록

• @Bean 등록된 클래스 정보를 스프링 빈에 등록
• 빈 이름은 항상 다른 이름을 부여해야 함

3. 스프링 빈 의존관계 설정

• 스프링 컨테이너는 설정 정보를 참고해서 의존 관계를 주입(DI)

스프링 빈 설정 정보 - BeanDefinition

• BeanDefinition에만 의존(추상화)
• @Bean 각각 하나씩 메타 정보가 생성된다.
• 스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.

[hyunjungkimm]

싱글톤 컨테이너

싱글톤 패턴

생성 이유

• 순수한 DI 컨테이너는 요청마다 객체를 새로 생성해서 메모리 낭비가 심함
• 해당 객체가 딱 1개만 생성되고 공유하도록 설계된 싱글톤 패턴이 생김

  싱글톤 패턴

• 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴
• private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막아서 객체 인스턴스를 2개 이상 생성하지 못함

싱글톤 컨테이너 = 스프링 컨테이너

• 객체 인스턴스를 싱글톤으로 관리한다.
  • 요청이 올 때마다 객체를 생성하는 것이 아니라, 이미 만들어진 객체를 공유해서 효율적으로 재사용
• 스프링 빈은 항상 무상태로 설계
  • 여러 클라이언트가 하나의 같은 객체 인스턴스를 공유하기 때문
  • 가급적 읽기만 가능해야 하고 값을 변경할 수 있는 필드가 있어서는 안됨
  • 필드 대신에 자바에서 공유되지 않는, 지연변수, 파라미터, ThreadLocal 등을 사용할 것
  • 공유 필드 조심

@Configuration

• 스프링 컨테이너 = 싱글톤 레지스트리 = 스프링 빈이 싱글톤이 되도록 보장
• 스프링은 클래스의 바이트 코드를 조작하는 라이브러리(CGLIB) 사용하여 AppConfig 클래스를 상속받은 임의의 다른 클래스를 만들고, 그 다른 클래스를 스프링 빈으로 등록함
  • 
  • 임의 클래스가 싱글톤이 보장되도록 해줌
  • @Bean이 붙은 메서드마다 이미 스프링 빈이 존재하면 존재하는 빈을 반환하고, 스프링 빈이 없으면 생성해서 스프링 빈으로 등록하고 반환하는 코드가 동적으로 만들어짐
  • @Configuration 없이 @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않으므로 스프링 설정정보는 @Configuration을 사용하자

[hyunjungkimm]

컴포넌트 스캔

@ComponentScan

스프링은 설정 정보가 없어도 자동으로 스프링 빈을 등록

• @Bean으로 등록해줄 필요가 없음
• @Component 어노테이션 붙은 모든 클래스를 스캔해서 스프링 빈으로 등록
• 탐색 위치 : 지정하지 않으면 default로 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 됨.
  • basePackage : 탐색할 패키지의 시작 위치를 지정함. 이 패키지를 포함해서 하위 패키지를 모두 검색함
  • 권장 : 패키지 위치를 지정하지 않고, 설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것
    • 스프링 부트의 대표 시작 정보인 @SpringBootApplication를 이 프로젝트 시작 루트 위치에 두는 것이 관례 (설정 안에 @ComponentScan이 들어 있음)

컴포넌트 스캔 기본 대상

• @Component : 컴포넌트 스캔에서 사용
• @Controller : 스프링 MVC 컨트롤러에서 사용
• @Service : 스프링 비즈니스 로직에서 사용
• @Repository : 스프링 데이터 접근 계층에서 사용
• @Configuration : 스프링 설정 정보에서 사용

필터

• includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다.
• excludeFilters: 컴포넌트 스캔에서 제외할 대상을 지정한다.

중복등록과 충돌

• 자동 빈 등록 vs 자동 빈 등록 : ConflictingBeanDefinitionException예외 발생 (스프링 오류)
• 수동 빈 등록 vs 자동 빈 등록 : 수동 빈 등록이 우선권을 가졌었는데 최근에는 오류가 나도록 바뀜
• 
  • 두 개의 빈이 발견됨
  • @Primary 사용하여 하나의 빈을 기본 빈으로 지정 , @Qualifier 사용해서 주입할 빈을 명확히 지정

@Autowired : 자동 의존관계 주입

• 생성자에 여러 의존관계도 한 번에 주입 가능
• 생서자에 @Autowired를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.

[hyunjungkimm]

의존관계 주입

• 스프링 라이프 사이클
  • spring container 생성 -> bean 등록 -> 의존관계 주입

    1. 생성자 주입

• 생성자를 통해서 의존 관계를 주입 받는 방법
• 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다.
• 불변, 필수 의존관계 사용
• 스프링 빈에서는 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입됨.
• 생성자 주입은 스프링 라이프 사이클에서 bean 등록시 일어남

생성자 주입을 권장하는 이유

1. 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.
2. 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있어서 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아준다.
   • 수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출되므로, 필드에 final 사용할 수 없다. 오직 생성자 주입 방식만 final 키워드를 사용할 수 있음

@RequiredArgsConstructor

• 롬복 라이브러리 제공 기능
• final이 붙은 필드를 모아서 생성자를 자동으로 만들어줌

2. 수정자 주입(setter 주입)

• setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존 관계를 주입하는 방법
• 선택, 변경 가능성이 있는 의존관계에 사용
• 생성자 주입은 스프링 라이프 사이클에서 의존관계 주입때 일어남
• @Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생한다.(required 옵션의 기본값이 true) 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 지정하면 된다.

  3. 필드 주입

• 필드에 바로 주입하는 방법
• 권장 x (안티패턴)
  • 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있다. (또 setter를 만들어야 함 - 애플리케이션 실제 코드와 관계없는 테스트 코드가 생김)
  • DI프레임워크가 없으면 아무것도 할 수 없다.
  • 사용하지 말자!
• 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용

  4. 일반 메서드 주입

• 한 번에 여러 필드를 주입받을 수 있지만 일반적으로 잘 사용하지 않음

조회 대상 2개일 때 해결 방법

1. @Autowired 필드 명 매칭

1. 타입 매칭 2. 타입 매칭의 결과가 2개 이상일 때 필드명, 파라미터 명으로 빈 이름 매칭
   • 먼저 타입 매칭을 시도 하고 그 결과에 여러 빈이 있을 때 추가로 동작하는 기능임

2. @Qualifier

• @Qualifier끼리 매칭 -> 빈 이름 매칭 -> 못찾으면 NoSuchBeanDefinitionException 예외 발생
• 추가 구분자를 붙여주는 방법으로 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아님
• @Primary보다 우선권이 높음

3. @Primary 사용

• 우선순위를 정하는 방법
• @Autowired시에 여러 빈이 매칭되면 @Primary가 우선권을 가진다.

실무에서 자동, 수동 운영

편리한 자동 기능을 기본으로 사용하자

직접 등록하는 기술 지원 객체는 수동 등록

애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있음

• 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등이 모두 업무 로직임. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경됨.
• 기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용됨. 데이터 연결이나, 공통 로그 처리처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들

  다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

[hyunjungkimm]

빈 생명주기 콜백

객체의 초기화, 종료 작업

• 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화, 종료 작업이 필요함

스프링 빈의 라이프사이클

• 객체 생성 -> 의존관계 주입
  • 생성자 주입은 예외

스프링 빈의 이벤트 라이프사이클 (싱글톤)

• 스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 컨테이너 종료
  • 초기화 콜백 : 빈이 생성되고, 빈이 의존관계 주입이 완료된 후 호출
  • 소멸전 콜백 : 빈이 소멸되기 직전에 호출
• 객체의 생성과 초기화를 분리하자.
  • 단일 책임 원칙 : 생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가지고, 초기화는 생성된 값들을 활용해서 외부 커넥션을 연결하는 등 무거운 동작을 수행한다.

스프링 - 빈 생명주기 콜백 3가지 방법

1. 인터페이스 (InitializingBean, DisposableBean)

• InitializingBean : afterPropertiesSet() 메서드로 초기화 지원
• DisposableBean : destory() 메서드로 소멸을 지원함
• 거의 사용하지 않음
  • 스프링 전용 인터페이스에 의존
  • 초기화, 소멸 메서드의 이름을 변경할 수 없음
  • 내가 코드를 고칠 수 없는 외부 라이브러리에 적용 불가능

    2. 설정 정보에 초기화 메서드, 종료 메서드 지정

• 메서드 이름을 자유롭게 줄 수 있고, 스프링 빈이 스프링 코드에 의존하지 않음
• 코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메서드를 적용할 수 있음
• 종료 메서드 추론
  • @Bean의 destroyMethod의 기본값이 (inferred)(추론)으로 등록되어 있어 close, shutdown 라는 이름의 메서드를 자동으로 호출해준다.
  • 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작함

    3. @PostConstruct, @PreDestory애노테이션 지원

• 가장 권장함
• 스프링에 종속적인 기술이 아니라 자바 표준이라서 스프링이 아닌 다른 컨테이너에서도 잘 동작함
• 단점 : 외부 라이브러리에는 적용하지 못함

[hyunjungkimm]

빈 스코프

빈이 존재할 수 있는 범위

스프링 스코프

1. 싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프

• 싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환함
• 싱글톤 빈은 스프링 컨테이너 생성 시점에 초기화 메서드가 실행됨

2. 프로토타입 : 빈의 생성과 의존관계 주입, 초기화까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프

• 프로토타입 스코프의 빈을 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환함
• 프로토 타입 빈을 관리할 책임은 프로토타입 빈을 받은 클라이언트에 있다.
  • @PreDestory 같은 종료 메서드 호출되지 않음, 클라이언트가 직접 호출해야함.
• 프로토 타입 스코프 빈은 스프링 컨테이너에서 빈을 조회할 때 생성되고, 초기화 메서드도 실행됨
• 프로토 타입 빈을 주입 받으면 주입 받는 시점에 각각 새로운 프로토 타입 빈이 생성된다. (사용시 생성 x)

프로토 타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

• 프로토 타입 스코프를 사용하는 것은 새로 요청받을때마다 새로 생성하는 것인데, 싱글톤 빈과 함께 사용하면 처음 주입받을때만 생성된다.
  • 스프링은 일반적으로 싱글톤 빈을 사용하므로 싱글톤 빈이 프로토타입 빈을 사용하게 된다.
  • 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되는 것이 문제

프로토 타입 스코프 - 싱글톤 빈과 함께 사용시 문제 해결법 = Provider

• 스프링 컨테이너에 요청

  • 싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청하는 것임
  • 
  • DL(Dependency Lookup) : 의존관계를 외부에서 주입(DI)받는게 아니라 직접 필요한 의존관계를 찾는 것을 의존관계 조회(탐색)이라 한다.
  • 스프링 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트가 어려워짐.

• ObjectProvider

  • 스프링이 제공하는 기능 : 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공하는 것
  • 과거 ObjectFactory + 여러 편의 기능을 추가한 것
  • ObjectProvider의 getObject()를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환함

• JSR-330 Provider

  • provider.get()을 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인
  • provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.(DL)

3. 웹 관련 스코프

웹 환경에서만 동작하고, 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출됨.

• request : 웹(HTTP) 요청이 들어오고 나갈때 까지 유지되는 스코프
  • 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리됨
  • 웹과 관련된 부분은 컨트롤러까지만 사용해야 한다. 서비스 계층은 웹 기술에 종속되지 않고, 가급적 순수하게 유지하는 것이 유지보수 관점에서 좋다.
  • 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 아직 생성되지 않음, 이 빈은 실제 고객의 요청이 와야 생성할 수 있음(=진짜 객체 조회를 꼭 필요한 시점까지 지연시켜야함)
    1. ObjectProvider 사용
       • ObjectProvider 덕분에 ObjectProvider.getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있음
       • 스프링 컨테이너에 요청을 지연하여 빈을 나중에 생성함
       • 같은 HTTP 요청이면 ObjectProvider.getObject() 여러번 호출해도 같은 스프링 빈이 반환됨 (요청이 섞여도 구분 가능함)
    2. 프록시 방식
       • @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
       • 가짜 프록시 클래스를 만들어 두고 HTTP request 와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해둘 수 있음
       • 위의 설정을 하면 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서 MyLogger를 상속받은 가짜 프록시 객체를 생성함. 의존관계 주입도 가짜 프록시 객체가 주입됨
       • 가짜 프록시 객체는 요청이 오면 그때 내부에서 진짜 빈을 요청하는 위임 로직이 들어있음
       • 가짜 프록시 객체는 request scope와 상관없는 가짜이고, 내부에 단순한 위임로직만 있고, 싱글톤처럼 동작함.
• session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프
• application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프
• websocket : 웹 소켓과 동일한 생명주기를 가지는 스코프