스프링 빈 스코프(Bean Scope)

프로토타입 스코프와 생명주기 콜백

프로토타입 빈은 컨테이너에 요청하는 순간 생성되고, 의존성 주입과 @PostConstruct 초기화까지 마친 뒤 클라이언트에게 넘겨진다. 그 이후 컨테이너는 이 인스턴스를 더 이상 추적하지 않는다. 따라서 @PreDestroy 같은 소멸 콜백이 호출되지 않으며, 자원 해제가 필요하면 사용하는 쪽이 직접 정리해야 한다.

@Component
@Scope("prototype")
public class ReportGenerator {

    @PostConstruct
    public void init() {
        // 요청마다 새 인스턴스에서 호출된다
    }

    @PreDestroy
    public void close() {
        // 프로토타입이므로 컨테이너가 호출해 주지 않는다
    }
}

스코프가 다른 빈을 섞을 때 생기는 문제

가장 자주 나오는 함정은 싱글턴 빈이 프로토타입 빈을 주입받는 경우다. 주입은 싱글턴이 생성되는 시점에 한 번만 일어나므로, 프로토타입 빈도 그 순간 만들어진 인스턴스 하나가 계속 재사용된다. 매번 새 인스턴스를 원한 의도와 어긋나는 것이다. 해결책은 사용 시점에 컨테이너에 조회를 위임하는 것이며, ObjectProvider가 대표적이다.

@Component
public class ReportService {

    private final ObjectProvider<ReportGenerator> generatorProvider;

    public ReportService(ObjectProvider<ReportGenerator> generatorProvider) {
        this.generatorProvider = generatorProvider;
    }

    public void generate() {
        ReportGenerator generator = generatorProvider.getObject(); // 호출 시점마다 새 인스턴스
        // ...
    }
}

request 같은 웹 스코프 빈을 싱글턴에 주입할 때는 프록시(Proxy) 방식을 쓴다. @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)로 선언하면 CGLIB 프록시가 대신 주입되고, 실제 메서드 호출 시점에 현재 요청에 해당하는 진짜 빈을 찾아 위임한다. 요청이 없는 시점에 웹 스코프 빈을 직접 주입하려 하면 컨텍스트 기동 자체가 실패하므로, 프록시나 ObjectProvider로 조회를 지연시키는 것이 핵심이다.

면접에서 이렇게 물어본다

• 스프링 빈의 기본 스코프는 무엇이고, 싱글턴 빈을 무상태로 설계해야 하는 이유를 설명해 보라.
• 스프링의 싱글턴 레지스트리와 디자인 패턴의 싱글턴 패턴은 무엇이 다른지 말해 보라.
• 프로토타입 빈은 왜 @PreDestroy가 호출되지 않는지 컨테이너의 관리 범위와 연결해 설명해 보라.
• 싱글턴 빈에 프로토타입 빈을 주입하면 어떤 문제가 생기고 어떻게 해결하는지 말해 보라.
• request 스코프 빈을 싱글턴 빈에서 사용할 때 프록시 모드가 필요한 이유를 설명해 보라.