[스프링 핵심 원리] 빈 스코프

스프링 핵심 원리의 강의 내용을 정리한 포스팅입니다.

---

빈 스코프란?

말 그대로 빈이 존재할 수 있는 범위를 뜻한다.

 

지금까지는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어 스프링 컨테이너가 종료될 때까지 유지된다고 학습하였는데, 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다.

 

스프링은 다음과 같이 다양한 스코프를 지원한다.

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

2. 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존 관계 주입, 초기화까지만 관여하고 그 이상 관리하지 않는 짧은 범위의 스코프이다.

3. 웹 관련 스코프

3-1 request: 웹 요청이 들어오고 나갈 때까지 유지되는 스코프이다.

3-2 session: 웹 세션이 생성되고 종료될 때까지 유지되는 스코프이다.

3-3 application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.

 

빈 스코프는 컴포넌트 스캔 자동 등록과 수동 등록 두 가지 방법으로 지정할 수 있는데, 자동 등록의 방법은 다음과 같다.

@Scope("prototype")
@Component
public class HelloBean {}

 

프로토타입 스코프

프로토타입 스코프의 빈은 싱글톤 스코프와 다르게 스프링 컨테이너에 조회할 경우, 스프링 컨테이너는 항상 새로운 인스턴스를 생성해 반환한다.

 

과정

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.

2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존 관계를 주입한다.

3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.

4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

 

스프링 컨테이너는 프로토타입 빈을 생성/의존 관계 주입/초기화까지만 처리하기 때문에, 프로토타입 빈을 관리할 책임은 해당 빈을 받은 클라이언트에게 있다. 따라서 @PreDestroy와 같은 종료 메서드가 호출되지 않으며 클라이언트가 직접 호출해야 한다.

 

그런데 프로토타입 스코프의 빈을 싱글톤 빈과 함께 사용했을 때 문제가 될 수 있는 상황이 존재한다.
스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다. 그런데 싱글톤 빈은 생성 시점에만 의존 관계 주입을 받기 때문에, 프로토타입 빈이 새로 생성되기는 하지만 싱글톤 빈과 함께 계속 유지가 된다.

 

예를 들어 싱글톤 빈인 clientBean이 있고 해당 빈이 가지고 있는 프로토타입 빈을 가지고 있다고 가정해 보자.
클라이언트는 프로토타입 빈을 이용하기 위해 clientBean을 스프링 컨테이너에 요청해서 받을 것이다.

이때 clientBean은 싱글톤 빈이므로 항상 같은 객체가 반환되는데, 해당 빈이 가지고 있는 프로토타입 빈 역시 clientBean이 생성되어 의존 관계를 주입하는 시점에 생성된 상태이므로 클라이언트가 요청을 할 때마다 새로 생성되지 않는다.

하지만 프로토타입 빈의 특성을 고려해 보았을 때, 주입 시점에만 새로 생성하는 것이 아닌 사용할 때마다 새로 생성해서 사용하는 것을 원할 것이다. 이 문제를 해결할 수 있는 방법은 크게 세 가지가 있다.

 

1. 스프링 컨테이너에 요청
싱글톤 빈이 프로토타입을 사용할 때마다 스프링 컨테이너에 새로 요청하는 것으로, 가장 간단한 방법이기도 하다.
이렇게 의존 관계를 외부에서 주입받는 것이 아닌, 직접 필요한 의존 관계를 찾는 것을 DL(Dependency Lookup)이라고 한다.
그런데 의존 관계를 찾기 위해서는 스프링의 애플리케이션 컨텍스트 전체를 주입받아야 하고, 이는 스프링 컨테이너에 종속적인 코드가 됨과 동시에 단위 테스트도 어려워짐을 의미한다.

 

2. ObjectFactory, ObjectProvider
지정한 빈을 컨테이너에서 대신 찾아주는 DL 기능을 제공하는 것이 바로 ObjectProvider이다. ObjectProvider는 ObjectFactory를 상속받아 스트림 처리와 같은 편의 기능을 추가해 만들어진 것이다.

ObjectProvider에는 getObject()라는 메서드가 존재하는데, 해당 메서드를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다. 스프링이 제공하는 기능을 사용하지만 기능이 단순하므로, 단위테스트를 만들거나 mock 코드를 만들기에 한결 수월해진다.
ObjectProvider는 DL정도의 기능만 제공하기 때문에 단순하고, 별도의 라이브러리가 필요 없다는 장점이 있다.

 

3. JSR-330 Provider
해당 방법은 javax.inject.Provider라는 JSR-330 자바 표준을 사용하는 방법이다. Provider 역시 get()이라는 메서드가 존재하는데, 내부에서 스프링 컨테이너를 통해 해당 빈을 찾아 반환한다.
별도의 라이브러리가 필요하다는 단점이 존재하지만, 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다는 장점이 있다.

 

그렇다면 스프링이 제공하는 ObjectProvider를 사용할 것인지, 아니면 자바 표준인 JSR-330 Provider를 사용할 것인지 고민이 될 수 있는데 ObjectProvider는 DL을 위한 편의 기능을 많이 제공해 주고 스프링 외에 별도의 의존 관계 추가가 필요 없기 때문에 편리하다.
코드를 스프링이 아닌 다른 컨테이너에서 사용할 일이 없을 경우, ObjectProvider를 사용하면 될 것이다.

 

참고로 ObjectProvider와 JSR-330 Provider는 프로토타입뿐만 아니라 DL이 필요한 경우 언제든지 사용할 수 있다.

 

웹 스코프

웹 스코프는 웹 환경에서만 동작하며, 프로토타입과 다르게 스프링이 해당 스코프의 종료 시점까지 관리한다. 따라서 종료 메서드가 호출된다. 웹 스코프 중 request 스코프는 HTTP 요청이 왔을 때 로그를 구분하기 위한 목적으로 사용하기에 적합한데, 다음은 해당 기능을 구현한 코드이다.

@Component
@Scope(value = "request")
public class MyLogger {
    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " + message);
    }

    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }

    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id = " + id);
    }
}

로그를 출력하기 위한 logic()메서드가 구현되어 있는데, 해당 코드에는 문제점이 존재한다.
스프링 애플리케이션을 실행하는 시점에 싱글톤 빈인 LogDemoService는 생성해서 주입이 가능하지만, request 스코프 빈인 MyLogger는 실제 요청이 오지 않았기 때문에 아직 생성될 수가 없는 것이다. 이 문제를 해결하기 위한 방법으로 크게 두 가지가 있는데, 스코프와 Provider를 이용하는 방법과 스코프와 프록시를 이용하는 방법이 있다.

 

스코프와 Provider

해당 방법은 앞서 등장한 Provider를 사용하는 것이다.

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final ObjectProvider<MyLogger> myLoggerProvider;

    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("service id = " + id);
    }
}

ObjectProvider덕분에 getObject()를 호출하는 시점까지 request scope 빈의 생성을 지연할 수 있다. getObject()를 호출하는 시점에는 HTTP 요청이 진행 중이므로 request scope 빈의 생성이 정상적으로 이루어진다.
getObject()를 컨트롤러와 서비스에서 각각 호출해도, 같은 HTTP 요청이면 같은 스프링 빈이 반환되기 때문에 같은 요청끼리 식별이 가능하다.

 

스코프와 프록시

프록시 방식을 사용해도 문제를 해결할 수 있다.

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

@Service
@RequiredArgsConstructor
public class LogDemoService {
    private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id = " + id);
    }
}

앞선 코드에 proxyMode = ScopedProxyMode.TARGET_CLASS를 추가해 주었고, 서비스의 코드도 원래 작성했던 대로 돌아갔다. Scope의 적용 대상이 클래스면 TARGET_CLASS, 인터페이스면 INTERFACES를 입력하면 된다. 이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고, HTTP 요청이 있는지 여부와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

 

proxyMode = ScopedProxyMode.TARGET_CLASS를 설정함으로써, 스프링 컨테이너가 CGLIB라는 바이트코드 조작 라이브러리를 이용해 개발자가 작성한 클래스를 상속받는 가짜 프록시 객체를 생성한다. 서비스 클래스에 있는 MyLogger의 클래스를 조회해 보면 순수한 클래스가 아님을 알 수 있다. 따라서 스프링 컨테이너에 등록되는 myLogger는 가짜 프록시 객체이고, 의존 관계 주입 역시 가짜 프록시 객체로 이루어지는 것이다.

 

가짜 프록시 객체에는 요청이 오면 그제야 내부에서 진짜 빈을 요청하는 위임 로직이 들어있다. 여기서 핵심 아이디어는 가짜 객체를 세워둠으로써 진짜 객체 조회를 반드시 필요한 시점까지 미뤄두는 것이다. 그리고 해당 아이디어를 애노테이션 설정 변경만으로 구현할 수 있다. 이때 프록시는 웹 스코프가 아니더라도 사용할 수 있다.

 

이러한 방법을 이용해 마치 싱글톤을 사용하는 것처럼 구현이 가능하지만, 실제로는 다르게 동작하기 때문에 주의해서 사용해야 하며 이렇게 특별한 scope는 유지보수를 위해 꼭 필요한 곳에 최소화하여 사용하는 것이 좋다.