빈 팩토리와 애플리케이션 컨텍스트

Spring 빈은 컨테이너에 등록되어 관리되고 조회되는 객체입니다.

빈 정의를 바탕으로 컨테이너가 생성할 수도 있지만, @Bean 메서드나 공급자가 반환한 객체 또는 미리 만든 뒤 등록한 객체도 빈이 될 수 있습니다.

따라서 “빈”이라는 말만으로 Spring이 반드시 그 인스턴스를 직접 new로 만들었다고 단정하지 않습니다.

앞 문서의 BoardConfig는 board.member 역할 그래프를 @Bean으로 등록했습니다.

이번 문서는 그 그래프를 다시 설계하지 않고, 빈 접근의 기반인 BeanFactory와 애플리케이션 기능을 함께 제공하는 ApplicationContext의 계약을 구분합니다.

앞 장의 파일 배치와 Spring 컨테이너 전환을 마친 같은 학습 프로젝트에서 따라갑니다. 파일 제목의 board-core/는 프로젝트 루트를 뜻하므로 단일 Gradle 프로젝트에서는 그 아래 src/test/java에 테스트를 둡니다. 첫 장의 Java 25·Boot 4.1.1 의존성 기준과 JUnit·AssertJ를 유지하고, 이 절 때문에 다른 버전의 Spring context를 추가하지 않습니다.

먼저 BeanFactoryProbeTest를 작성해 프로젝트 루트에서 ./gradlew test --tests board.container.BeanFactoryProbeTest를 실행합니다. 이어 ApplicationContextProbeTest를 같은 위치에 추가하고 테스트 이름만 바꾸어 실행하세요. 두 테스트는 각자 작은 팩토리나 컨텍스트를 만들므로 웹 서버를 켤 필요가 없습니다.

아무 부트스트랩도 더하지 않은 BeanFactory

DefaultListableBeanFactory에 빈 정의를 직접 등록하면 구성 클래스나 컴포넌트 스캔 없이 정의·생성·조회만 관찰할 수 있습니다.

package board.container;

import static org.assertj.core.api.Assertions.assertThat;

import board.member.MemoryMemberRepository;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.support.BeanDefinitionBuilder;
import org.springframework.beans.factory.support.DefaultListableBeanFactory;

final class BeanFactoryProbeTest {
    @Test
    void 등록한_정의에서_기본_singleton을_조회한다() {
        var factory = new DefaultListableBeanFactory();
        var definition = BeanDefinitionBuilder
                .rootBeanDefinition(MemoryMemberRepository.class)
                .getBeanDefinition();
        factory.registerBeanDefinition(
                "memberRepository", definition);

        var byName = factory.getBean("memberRepository");
        var byType = factory.getBean(
                MemoryMemberRepository.class);

        assertThat(byName).isSameAs(byType);
        assertThat(factory.containsBeanDefinition(
                "memberRepository")).isTrue();
    }
}

이 예제에서 첫 getBean() 호출이 기본 singleton 인스턴스를 만들고, 같은 팩토리의 같은 정의를 다시 조회하면 같은 참조를 돌려줍니다.

그 관찰은 이 팩토리와 이 빈 정의에 한정됩니다. singleton 상태와 스코프의 일반 규칙은 뒤 문서에서 다룹니다.

plain DefaultListableBeanFactory는 빈 정의로 등록한 BeanPostProcessor나 BeanFactoryPostProcessor를 특별한 확장점으로 자동 탐지·활성화하지 않습니다.

애노테이션 주입, 구성 클래스 처리 같은 기능이 필요하면 관련 processor를 직접 등록·실행하거나 그 부트스트랩을 제공하는 컨텍스트를 사용해야 합니다.

ApplicationContext가 확장하는 계약

Spring 7의 ApplicationContext는 다음 여섯 인터페이스를 직접 확장합니다.

• ListableBeanFactory와 HierarchicalBeanFactory
• EnvironmentCapable
• MessageSource
• ApplicationEventPublisher
• ResourcePatternResolver

ListableBeanFactory와 HierarchicalBeanFactory는 각각 BeanFactory를 확장합니다.

그래서 ApplicationContext는 이름·타입 조회뿐 아니라 현재 팩토리의 빈 목록과 부모 팩토리 관계도 표현합니다.

ResourcePatternResolver는 ResourceLoader를 확장하므로 단일 리소스와 경로 패턴 조회 계약도 함께 얻습니다.

그림의 빈·리소스 경로에서 화살표 끝의 빈 삼각형은 extends로 얻는 상위 인터페이스를 가리킵니다. 아래쪽에 있다는 이유로 메서드가 그 순서대로 실행되는 것은 아닙니다. 환경·메시지·이벤트의 직접 확장 계약은 위 목록과 그림의 표에서 함께 확인합니다. Spring 7의 ApplicationContext API는 직접 확장과 간접 상속을 구분해서 보여 줍니다.

반면 refresh(), close(), isActive()처럼 구성과 수명을 제어하는 메서드는 클라이언트용 ApplicationContext가 아니라 ConfigurableApplicationContext에 있습니다.

시작·종료 코드는 구성 가능한 계약을 사용하고, 업무 객체는 컨테이너 수명 제어를 알지 않게 둡니다.

ApplicationContext extends
  EnvironmentCapable,
  ListableBeanFactory,
  HierarchicalBeanFactory,
  MessageSource,
  ApplicationEventPublisher,
  ResourcePatternResolver

AnnotationConfigApplicationContext의 부트스트랩

AnnotationConfigApplicationContext는 공통 애노테이션 processor 정의를 등록하고, refresh()에서 구성 클래스와 processor를 적용해 컨텍스트를 사용할 수 있게 만듭니다.

plain 팩토리에 @Configuration 클래스 정의 하나만 넣는 것과 같은 동작이라고 보면 안 됩니다.

다음 테스트는 환경과 이벤트를 같은 작은 컨텍스트에서 확인합니다.

package board.container;

import static org.assertj.core.api.Assertions.assertThat;

import java.util.ArrayList;
import java.util.List;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.event.EventListener;

final class ApplicationContextProbeTest {
    record MemberRegistered(long memberId) { }

    static final class RegistrationEvents {
        private final List<Long> observed = new ArrayList<>();

        @EventListener
        void on(MemberRegistered event) {
            observed.add(event.memberId());
        }

        List<Long> observed() {
            return List.copyOf(observed);
        }
    }

    @Configuration(proxyBeanMethods = false)
    static class EventConfig {
        @Bean
        RegistrationEvents registrationEvents() {
            return new RegistrationEvents();
        }
    }

    @Test
    void 환경과_이벤트를_같은_context에서_사용한다() {
        try (var context = new AnnotationConfigApplicationContext()) {
            context.getEnvironment().setActiveProfiles("memory");
            context.register(EventConfig.class);
            context.refresh();

            ApplicationEventPublisher publisher = context;
            publisher.publishEvent(new MemberRegistered(42L));

            assertThat(context.getEnvironment()
                    .matchesProfiles("memory")).isTrue();
            assertThat(context.getBean(RegistrationEvents.class)
                    .observed()).containsExactly(42L);
        }
    }
}

문자열 프로필 표현식은 deprecated acceptsProfiles(String...) 대신 matchesProfiles(String...)로 검사합니다.

이 테스트의 기본 이벤트 multicaster는 리스너를 발행 호출 스레드에서 동기 실행합니다.

별도 실행자를 구성하면 실행 방식이 달라질 수 있으므로 @EventListener 자체를 비동기 보장으로 해석하지 않습니다.

try 블록이 끝날 때 컨텍스트를 닫을 수 있는 이유도 구체 타입이 ConfigurableApplicationContext와 Closeable 계약을 구현하기 때문입니다.

확인 질문만큼만 컨텍스트 열기

테스트 도구는 “Spring을 쓰는가”가 아니라 무엇을 검증하는가에 맞춰 선택합니다.

@SpringBootTest의 기본 webEnvironment는 MOCK이며 실제 포트에서 요청을 기다리는 서버를 시작하지 않습니다.

실행 중인 서버가 검증 대상일 때만 RANDOM_PORT 또는 DEFINED_PORT를 선택합니다.

Tomcat, DataSource, SQL 초기화, MVC 구성 등이 항상 전부 시작된다고 말할 수 없습니다. 포함되는 구성은 애플리케이션, 의존성, 속성, 선택한 web environment에 달려 있습니다.

조회는 구성 경계에 두고 역할은 생성자로 전달

다음 파일은 서비스 로케이터가 의존성을 숨기는 완전한 비교용 반례이며 운영 소스에 추가하지 않습니다.

package board.member;

import java.util.Objects;
import org.springframework.context.ApplicationContext;

public final class ContainerLookupMemberRegistrationService {
    private final ApplicationContext context;

    public ContainerLookupMemberRegistrationService(
            ApplicationContext context
    ) {
        this.context = Objects.requireNonNull(
                context, "context must not be null");
    }

    public Member register(SignUpCommand command) {
        Objects.requireNonNull(command, "command must not be null");
        var members = context.getBean(MemberRepository.class);
        var passwordHasher = context.getBean(PasswordHasher.class);

        if (members.existsByEmail(command.email())) {
            throw new DuplicateEmailException(command.email());
        }
        String passwordHash = passwordHasher.hash(
                command.rawPassword());
        return members.save(Member.signUp(
                command.email(), command.name(), passwordHash));
    }
}

이 구조에서는 MemberRepository와 PasswordHasher가 생성자에 드러나지 않고, 호출 중에야 후보 없음·복수 후보 실패가 나타날 수 있습니다.

게시판의 실제 MemberRegistrationService처럼 두 역할을 생성자로 받으면 컨테이너는 구성 경계에서 객체를 완성하고 업무 호출은 평범한 Java 참조로 이어집니다.

시작 코드나 컨테이너 통합 테스트가 getBean()으로 완성된 진입 객체를 얻는 것과, 업무 객체가 실행 중 컨테이너를 조회하는 것은 다른 경계입니다.

이 문서의 경계

앞 문서 ch2-7이 @Bean 객체 그래프를 소유하고, 다음 ch3-2가 이름·타입 조회와 후보 집합을 다룹니다.

singleton 상태는 ch3-3, qualifier는 ch3-7, lifecycle callback은 ch3-8, scope는 ch3-9의 범위입니다.

이 문서에서는 그 규칙을 미리 일반화하지 않고 컨테이너 계약, 애노테이션 부트스트랩, 테스트 크기, 업무 코드의 주입 경계만 확정합니다.

연습 문제

작은 AnnotationConfigApplicationContext에서 classpath:schema.sql 한 파일을 getResource()로 읽고, classpath*:schema.sql 패턴을 getResources()로 조회하는 테스트를 작성하세요.

같은 호출을 BeanFactory 타입 변수만으로 표현할 수 없는 이유와, 컨텍스트를 닫는 코드는 왜 ConfigurableApplicationContext 계약에 속하는지도 인터페이스 관계로 설명합니다.

이 연습에서는 프로젝트의 src/test/resources/schema.sql에 다음 한 줄을 저장합니다. 이 파일은 리소스를 읽기 위한 표본이며 데이터베이스를 만들거나 SQL 초기화를 실행하지 않습니다. 같은 경로의 schema.sql을 의존성에서도 제공하는 환경이라면, 단일 조회가 이 표본을 선택하도록 먼저 테스트 클래스 경로를 확인하세요.

-- resource lookup exercise

예상 결과를 먼저 적어 보세요. 단일 조회에서 읽을 내용은 무엇이고, 패턴 조회는 반환 개수를 반드시 1로 단정할 수 있을까요?

package board.container;

import static org.assertj.core.api.Assertions.assertThat;

import java.nio.charset.StandardCharsets;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

final class ResourceLookupExerciseTest {
    @Test
    void 단일_리소스를_읽고_패턴_결과를_별도로_확인한다()
            throws Exception {
        try (var context = new AnnotationConfigApplicationContext()) {
            context.refresh();
            var single = context.getResource("classpath:schema.sql");
            assertThat(single.exists()).isTrue();

            try (var stream = single.getInputStream()) {
                var content = new String(
                        stream.readAllBytes(), StandardCharsets.UTF_8);
                assertThat(content.strip())
                        .isEqualTo("-- resource lookup exercise");
            }

            var matches = context.getResources("classpath*:schema.sql");
            assertThat(matches).isNotEmpty();
            for (var resource : matches) {
                assertThat(resource.exists()).isTrue();
                assertThat(resource.getFilename()).isEqualTo("schema.sql");
            }
        }
    }
}