1. 서론
스프링 프레임워크는 주로 웹 애플리케이션을 대상으로 개발되며, 다수의 클라이언트 요청을 효율적으로 처리하기 위해 객체 인스턴스 관리에 많은 신경을 씁니다. 특히 싱글톤 패턴과 이를 응용한 싱글톤 컨테이너는 스프링이 애플리케이션 성능과 자원 효율성을 극대화할 수 있도록 돕는 중요한 개념입니다. 이번 포스팅에서는 순수 DI 컨테이너와 싱글톤 패턴의 구현, 그리고 스프링 컨테이너가 어떻게 싱글톤을 보장하는지에 대해 자세히 알아보겠습니다.
2. 웹 애플리케이션과 싱글톤의 필요성
대부분의 스프링 애플리케이션은 웹 기반이며, 고객의 요청이 동시에 몰리게 됩니다.
순수 DI 컨테이너(AppConfig와 같이)를 사용할 경우, 요청할 때마다 새로운 객체를 생성하게 되어 초당 수많은 객체가 생성되고 소멸되는 문제가 발생할 수 있습니다. 예를 들어, 아래 테스트 코드는 같은 요청임에도 불구하고 서로 다른 인스턴스가 생성되는 문제를 보여줍니다.
// 스프링 없는 순수한 DI 컨테이너 테스트
@Test
@DisplayName("스프링 없는 순수한 DI 컨테이너")
void pureContainer() {
AppConfig appConfig = new AppConfig();
// 매 호출마다 새로운 객체가 생성된다.
MemberService memberService1 = appConfig.memberService();
MemberService memberService2 = appConfig.memberService();
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
// 서로 다른 인스턴스임을 확인
assertThat(memberService1).isNotSameAs(memberService2);
}
Java
복사
요청 당 객체 생성을 줄이고, 단 하나의 인스턴스를 공유하면 메모리 낭비를 줄일 수 있으므로 싱글톤 방식이 매우 유용합니다.
3. 싱글톤 패턴의 기본 개념과 구현 방법
3.1. 싱글톤 패턴이란?
싱글톤 패턴은 클래스의 인스턴스가 오직 한 개만 생성되도록 보장하는 디자인 패턴입니다.
이를 위해 private 생성자와 static 영역에 미리 생성한 인스턴스를 사용하여 외부에서 임의로 객체를 생성하는 것을 막습니다.
3.2. 싱글톤 패턴 구현 예제
아래 코드는 싱글톤 패턴을 적용한 SingletonService 클래스의 예시입니다.
package hello.core.singleton;
public class SingletonService {
// 1. static 영역에 객체를 딱 1개만 생성해둔다.
private static final SingletonService instance = new SingletonService();
// 2. public 메서드를 통해서만 객체 인스턴스를 반환
public static SingletonService getInstance() {
return instance;
}
// 3. 생성자를 private으로 선언해 외부에서 new 키워드 사용을 막는다.
private SingletonService() {}
public void logic() {
System.out.println("싱글톤 객체 로직 호출");
}
}
Java
복사
위와 같이 구현하면, getInstance()를 통해 언제나 같은 인스턴스를 반환받을 수 있습니다.
3.3. 싱글톤 패턴 사용 테스트
@Test
@DisplayName("싱글톤 패턴을 적용한 객체 사용")
public void singletonServiceTest() {
// new SingletonService(); // 컴파일 오류: private 생성자 때문에 직접 생성 불가
SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();
System.out.println("singletonService1 = " + singletonService1);
System.out.println("singletonService2 = " + singletonService2);
// 두 객체의 참조값이 동일함을 확인
assertThat(singletonService1).isSameAs(singletonService2);
singletonService1.logic();
}
Java
복사
이처럼 싱글톤 패턴을 적용하면, 객체가 단 한 번만 생성되어 재사용되므로 자원 낭비를 방지할 수 있습니다.
3.4. 싱글톤 패턴의 한계와 문제점
싱글톤 패턴을 직접 구현할 때는 다음과 같은 문제점들이 발생할 수 있습니다.
•
코드 복잡성 증가: 싱글톤을 보장하기 위한 추가 코드가 필요하다.
•
의존관계 문제: 클라이언트가 구체 클래스에 의존하게 되어 DIP(의존관계 역전 원칙) 위반 가능성이 있음.
•
테스트 어려움: 전역 상태를 가지게 되어 단위 테스트 시 의존성 주입이나 모의 객체 사용이 어려워짐.
•
상태 관리 문제: 객체 내부에 상태를 가지면 여러 클라이언트 간의 데이터 공유로 인해 부작용이 발생할 수 있음.
5. 스프링 컨테이너와 싱글톤 관리
스프링은 싱글톤 컨테이너를 사용하여 별도의 싱글톤 패턴 구현 없이도 객체 인스턴스를 단 하나만 생성하고 공유합니다.
즉, 스프링 빈은 기본적으로 싱글톤 범위로 관리되며, 여러 요청이 들어오더라도 동일한 객체 인스턴스를 반환합니다.
5.1. 스프링 컨테이너 사용 예제
@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
// 스프링 컨테이너는 매번 같은 인스턴스를 반환한다.
MemberService memberService1 = ac.getBean("memberService", MemberService.class);
MemberService memberService2 = ac.getBean("memberService", MemberService.class);
System.out.println("memberService1 = " + memberService1);
System.out.println("memberService2 = " + memberService2);
// 두 객체의 참조값이 동일함을 확인
assertThat(memberService1).isSameAs(memberService2);
}
Java
복사
이처럼 스프링 컨테이너를 사용하면, 개발자가 직접 싱글톤 패턴 코드를 작성할 필요 없이 간편하게 싱글톤을 보장받을 수 있습니다.
6. 싱글톤 방식 사용 시 주의점: 무상태 설계
싱글톤 객체는 여러 클라이언트가 공유하기 때문에 상태를 유지(stateful) 하면 문제가 발생합니다.
예를 들어, 아래와 같이 상태를 가지는 StatefulService를 생각해봅니다.
6.1. 상태를 가지는 서비스 예제
package hello.core.singleton;
public class StatefulService {
private int price; // 상태를 유지하는 필드
public void order(String name, int price) {
System.out.println("name = " + name + ", price = " + price);
this.price = price; // 특정 클라이언트의 요청으로 값이 변경됨
}
public int getPrice() {
return price;
}
}
Java
복사
6.2. 문제 상황 테스트
@Test
void statefulServiceSingleton() {
ApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
StatefulService statefulService1 = ac.getBean("statefulService", StatefulService.class);
StatefulService statefulService2 = ac.getBean("statefulService", StatefulService.class);
// ThreadA: 사용자A가 10,000원 주문
statefulService1.order("userA", 10000);
// ThreadB: 사용자B가 20,000원 주문
statefulService2.order("userB", 20000);
// 사용자A가 주문 금액 조회 시, 기대와 달리 20,000원이 반환된다.
int price = statefulService1.getPrice();
System.out.println("price = " + price);
Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
}
Java
복사
위 테스트에서 두 클라이언트가 같은 인스턴스를 공유하기 때문에, 내부 상태가 변경되어 잘못된 값이 반환됩니다.
따라서 스프링 빈은 무상태(stateless)로 설계해야 하며, 공유 필드 대신 지역변수나 파라미터, ThreadLocal 등을 사용하는 것이 바람직합니다.
7. @Configuration과 싱글톤 보장 메커니즘
스프링에서는 @Configuration과 @Bean 애노테이션을 통해 설정 클래스를 작성할 때, CGLIB라는 바이트코드 조작 라이브러리를 활용하여 싱글톤을 보장합니다.
7.1. AppConfig 클래스의 예
아래 코드는 스프링 컨테이너가 싱글톤을 보장하는 AppConfig의 예시입니다.
@Configuration
public class AppConfig {
@Bean
public MemberService memberService() {
System.out.println("call AppConfig.memberService");
return new MemberServiceImpl(memberRepository());
}
@Bean
public OrderService orderService() {
System.out.println("call AppConfig.orderService");
return new OrderServiceImpl(memberRepository(), discountPolicy());
}
@Bean
public MemberRepository memberRepository() {
System.out.println("call AppConfig.memberRepository");
return new MemoryMemberRepository();
}
@Bean
public DiscountPolicy discountPolicy() {
return new RateDiscountPolicy();
}
}
Java
복사
여기서 주목할 점은 memberRepository() 메서드가 여러 번 호출되는 것처럼 보이지만, 실제로는 한 번만 실행되어 동일한 인스턴스가 반환된다는 사실입니다.
스프링은 CGLIB를 사용해 AppConfig 클래스를 상속받은 프록시 객체를 생성하고, 내부적으로 이미 생성된 스프링 빈이 있으면 재사용하는 방식으로 동작합니다.
7.2. @Configuration 없이 @Bean만 사용한 경우
만약 @Configuration 없이 @Bean만 적용하면, CGLIB에 의한 프록시 기능이 적용되지 않습니다.
그 결과, 메서드 호출 시마다 실제 객체 생성 로직이 실행되어 서로 다른 인스턴스가 생성될 수 있으므로 싱글톤이 깨지는 문제가 발생합니다.
팁: 스프링 설정 클래스에는 항상 @Configuration을 함께 사용하여 CGLIB의 싱글톤 보장 기능을 활용하는 것이 좋습니다.
8. 결론
이번 포스팅에서는 스프링의 싱글톤 패턴과 싱글톤 컨테이너의 동작 원리를 살펴보았습니다.
•
순수 DI 컨테이너에서는 매 요청마다 새로운 객체가 생성되어 메모리 낭비가 발생할 수 있으나,
•
싱글톤 패턴을 적용하면 단 하나의 인스턴스를 재사용할 수 있다.
•
스프링 컨테이너는 @Configuration과 CGLIB를 활용하여 자동으로 싱글톤을 보장하며, 개발자는 복잡한 싱글톤 구현 코드를 작성할 필요가 없다.
•
다만, 싱글톤 빈은 무상태로 설계해야 하며, 내부 상태 공유로 인한 부작용을 주의해야 합니다.
