처음 Spring 작업을 시작했을 때 가장 흥미로웠던 개념 중 하나는 빈 범위(Bean Scope)라는 아이디어였습니다. Spring은 Spring 컨테이너 내에서 생성된 Bean의 라이프사이클을 결정하는 다양한 Bean 범위를 제공합니다. 가장 일반적으로 사용되는 두 가지 범위는 Singleton과 Prototype입니다. 이러한 범위를 이해하는 것은 효율적이고 효과적인 Spring 애플리케이션을 설계하는 데 중요하므로 이에 대해 제가 배운 내용을 안내해 드리겠습니다.

Spring Bean 범위 이해

Spring에서 빈은 Spring IoC(Inversion of Control) 컨테이너에 의해 인스턴스화, 조립 및 관리되는 객체입니다. 빈 범위는 빈 인스턴스가 생성되는 방법과 시기, 지속 기간 등 빈의 수명주기를 나타냅니다.

Spring은 여러 빈 범위를 제공하지만 내가 집중할 두 가지는 다음과 같습니다.

• 싱글톤 범위
• 프로토타입 범위

각 범위에는 특정 사용 사례가 있으며 올바른 사용 사례를 선택하면 애플리케이션의 동작과 성능에 큰 영향을 미칠 수 있습니다.

싱글톤 범위

싱글톤 범위는 Spring의 기본 범위이며 내가 가장 자주 사용하는 범위입니다. Singleton 범위로 Bean을 정의하면 Spring 컨테이너가 해당 Bean의 인스턴스를 하나만 생성하고 이 단일 인스턴스가 전체 애플리케이션 컨텍스트에서 공유된다는 의미입니다.

작동 방식

빈을 싱글톤으로 선언하면 Spring은 애플리케이션 컨텍스트가 시작되는 동안이나 처음 참조될 때 처음 요청될 때 빈 인스턴스를 생성합니다. 그 이후에는 이 Bean에 대한 모든 후속 요청이 동일한 인스턴스를 반환합니다.

다음은 간단한 예입니다.

@Configuration
public class AppConfig {
    @Bean
    public MyService myService() {
        return new MyService();
    }
}

이 예에서 myService()는 Singleton Bean입니다. Spring 컨텍스트에서 MyService 빈을 요청할 때마다 동일한 인스턴스를 얻게 됩니다.

싱글톤 빈의 사용 사례

Singleton 범위는 클라이언트별 정보를 보유하지 않는 Stateless Bean에 이상적이라는 것을 알았습니다. 예는 다음과 같습니다:

• 서비스 클래스: 일반적으로 이러한 클래스에는 별도의 인스턴스 없이 애플리케이션 전체에서 공유할 수 있는 비즈니스 로직이 포함되어 있습니다.
• DAO 클래스: 일반적으로 데이터베이스와 상호 작용하고 클라이언트별 상태를 유지하지 않으므로 단일 인스턴스로 충분합니다.

이점 및 고려 사항

Singleton Bean의 주요 이점은 메모리 효율성입니다. 단일 인스턴스를 재사용하면 애플리케이션이 더 적은 메모리를 소비하고 객체 생성 및 삭제에 따른 오버헤드가 최소화됩니다. 그러나 상태를 유지하는 싱글톤 빈에는 주의하는 것이 중요합니다. Singleton Bean이 실수로 상태(예: 인스턴스 변수)를 보유하는 경우 이 상태는 여러 클라이언트에서 공유되어 잠재적인 데이터 불일치가 발생할 수 있습니다.

프로토타입 범위

Singleton과 달리 Prototype 범위는 Spring 컨테이너에서 Bean이 요청될 때마다 새 Bean 인스턴스를 생성합니다. 이에 대해 알게 되었을 때 Prototype Bean은 사용할 때마다 새로운 인스턴스가 필요한 시나리오에 유용하다는 것이 분명해졌습니다.

작동 방식

Prototype 범위로 Bean이 정의되면 Spring은 Bean이 요청될 때마다 새 인스턴스를 반환합니다. Prototype Bean을 정의하는 방법은 다음과 같습니다.

@Configuration
public class AppConfig {
    @Bean
    @Scope("prototype")
    public MyService myService() {
        return new MyService();
    }
}

이 예에서는 Spring 컨텍스트에서 MyService 빈을 요청할 때마다 Spring이 MyService의 새 인스턴스를 생성합니다.

프로토타입 빈의 사용 사례

프로토타입 빈은 일종의 클라이언트별 상태를 유지하거나 사용할 때마다 고유한 구성이 필요한 상태 저장 빈을 처리할 때 특히 유용합니다. 일반적인 사용 사례는 다음과 같습니다.

• 명령 객체: 각 명령이 별도로 실행되고 자체 상태를 유지하는 명령과 같은 패턴을 구현하는 경우 프로토타입 빈이 올바른 선택입니다.
• 세션 또는 요청 범위 Bean: 웹 애플리케이션에서 사용자 세션 또는 요청과 관련된 Bean을 프로토타입으로 정의하여 각 사용자 또는 요청에 대해 새 인스턴스가 생성되도록 할 수 있습니다.

이점 및 고려 사항

Prototype Bean 사용의 주요 이점은 새 인스턴스를 생성할 때 제공되는 유연성입니다. 이는 상태가 있는 개체를 처리할 때 특히 유용합니다. 그러나 성능과 리소스 사용량 측면에서는 상충 관계가 있습니다. 매번 새로운 인스턴스가 생성되므로 메모리 소비가 늘어나고 가비지 수집 빈도가 높아질 수 있습니다. 게다가 싱글톤 빈과 달리 Spring은 생성 이후 프로토타입 빈의 수명주기를 관리하지 않기 때문에 이러한 빈의 파괴와 정리를 수동으로 처리해야 합니다.

싱글톤 대 프로토타입: 올바른 범위 선택

Spring 애플리케이션을 디자인할 때 직면하게 되는 주요 결정 중 하나는 싱글톤 범위와 프로토타입 범위 중에서 선택하는 것입니다. 제가 고려하는 요소를 요약하면 다음과 같습니다.

• 상태성: 빈이 상태 비저장인 경우 일반적으로 싱글톤이 최선의 선택입니다. Stateful Bean의 경우 Prototype이 더 적합합니다.
• 리소스 관리: 싱글톤 빈은 하나의 인스턴스만 유지되므로 메모리 효율성이 더 높습니다. 프로토타입 빈은 더 많은 유연성을 제공하면서도 더 많은 리소스를 소비합니다.
• 라이프사이클 관리: 싱글톤 빈은 라이프사이클 전반에 걸쳐 Spring 컨테이너에 의해 관리됩니다. 반면에 Prototype Bean의 전체 수명주기를 관리해야 합니다.

실제 사례

각 범위를 언제 사용해야 하는지 명확히 하는 데 도움이 될 수 있는 실제 시나리오를 제공하겠습니다. 온라인 쇼핑 애플리케이션을 구축한다고 가정해 보겠습니다.

• 쇼핑 카트 서비스: 이 서비스는 일반적으로 상태 비저장이며 싱글톤 Bean에 적합한 후보입니다. 매번 새 인스턴스를 만들 필요가 없으며 동일한 서비스가 여러 요청을 처리할 수 있습니다.
• 주문 처리: 반면에 고객의 주문을 나타내는 Order 개체는 해당 주문과 관련된 세부 정보를 보유하는 상태 저장 개체입니다. 따라서 각 주문이 Order 클래스의 별도 인스턴스에 의해 처리되도록 Prototype Bean이어야 합니다.

혼합 스코프: 주의 사항

제가 힘들게 배운 한 가지는 싱글톤 빈과 프로토타입 빈을 혼합하면 예상치 못한 문제가 발생할 수 있다는 것입니다. 예를 들어, Prototype 범위의 Bean을 Singleton Bean에 주입하면 Singleton Bean이 항상 Prototype Bean의 동일한 인스턴스를 사용하게 될 수 있습니다. 이를 방지하기 위해 나는 일반적으로 Provider를 삽입하거나 @Lookup 주석을 사용하여 필요할 때마다 Prototype Bean의 새 인스턴스가 생성되도록 합니다.

@Service
public class SingletonService {

    @Autowired
    private Provider myPrototypeServiceProvider;

    public void usePrototypeService() {
        MyPrototypeService prototypeService = myPrototypeServiceProvider.get();
        prototypeService.execute();
    }
}

이 예에서 myPrototypeServiceProvider.get()은 Singleton Bean 내에서 호출될 때마다 MyPrototypeService의 새 인스턴스가 생성되도록 보장합니다.

안녕히 가세요 !

Spring의 싱글톤 및 프로토타입 Bean 범위의 미묘한 차이를 이해하는 것은 개발자로서의 여정에서 매우 중요했습니다. 두 범위 모두 사용 사례에 따라 뚜렷한 이점을 제공하며 올바른 범위를 선택하면 애플리케이션의 성능과 디자인에 큰 영향을 미칠 수 있습니다.

내 경험에 따르면 Singleton은 효율성과 단순성으로 인해 대부분의 Bean에 적합한 범위인 반면 Prototype은 매번 새로운 인스턴스가 필요한 특별한 경우를 위해 예약되어 있습니다. 내 빈의 상태 유지와 애플리케이션 내에서 사용되는 방식을 신중하게 고려함으로써 더 좋고 유지 관리하기 쉬운 Spring 애플리케이션으로 이어지는 정보에 입각한 결정을 내릴 수 있습니다.