스프링 빈(Bean)의 생명주기 과정
한 줄 답변
스프링 빈은 '객체 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸 전 콜백 -> 종료'의 생명주기를 가집니다. 주로 @PostConstruct를 통해 초기화 작업을 수행합니다.
핵심 개념 정리
스프링 컨테이너(IoC 컨테이너)는 애플리케이션 컴포넌트인 빈(Bean)의 생명주기를 전적으로 관리합니다. 자바의 일반적인 객체가 단순하게 'new' 키워드로 인스턴스화되고 가비지 컬렉터에 의해 소멸되는 것과 달리, 스프링 빈은 컨테이너의 런타임 환경 내에서 체계적인 단계를 거쳐 준비되고 폐기됩니다.
가장 기본적인 스프링 싱글톤 빈의 생명주기는 '객체 생성 → 의존관계 주입 → 초기화 콜백 → 사용 → 소멸 전 콜백 → 스프링 종료'의 흐름을 따릅니다. 여기서 핵심은 객체 생성 단계와 의존관계 주입 단계가 분리되어 있다는 점입니다. 스프링은 먼저 빈 객체를 생성(인스턴스화)한 뒤, 설정 메타데이터를 바탕으로 연관된 의존성을 주입(DI)합니다.
의존관계 주입이 완료된 이후에야 비로소 객체는 필요한 준비를 마치고 실제 비즈니스 로직을 수행할 수 있습니다. 따라서 스프링은 의존관계 주입이 완료되면 '초기화 콜백'을 호출하여 개발자가 데이터베이스 커넥션 풀 구축, 외부 API 네트워크 연결 등 무거운 초기화 작업을 안전하게 수행할 수 있도록 지원하며, 애플리케이션 종료 직전에는 '소멸 전 콜백'을 호출해 자원을 우아하게(Graceful) 반환하도록 돕습니다.
비교 정리
| 항목 | @PostConstruct / @PreDestroy | @Bean(initMethod, destroyMethod) |
|---|---|---|
| 적용 방식 | 초기화/소멸 메서드에 직접 애노테이션 부여 | 설정 클래스에서 빈 등록 시 메서드 이름 지정 |
| 스프링 종속성 | JSR-250 자바 표준 (스프링 외의 컨테이너에서도 동작) | 스프링 프레임워크 전용 기능 |
| 외부 라이브러리 적용 | 코드를 수정할 수 없는 외부 라이브러리에는 적용 불가 | 외부 라이브러리 빈에도 자유롭게 적용 가능 |
| 실무 권장도 | 개발자가 직접 컨트롤하는 코드에 대해 가장 권장됨 | 외부 라이브러리 연동 시에 주로 사용됨 |
면접에서 이렇게 답하세요
단순히 생명주기 순서를 기계적으로 나열하기보다는, '왜 객체 생성과 초기화를 분리해야 하는가(관심사의 분리 및 단일 책임 원칙)'에 초점을 맞춰 답변하세요. 생성자는 메모리를 할당하고 필수적인 데이터만 받는 데 집중하고, DB 커넥션 등 무거운 작업은 의존관계 주입 이후 콜백을 통해 별도로 분리하여 초기화하는 것이 유지보수와 테스트에 유리하다는 점을 어필하면 훨씬 깊이 있는 개발자로 평가받습니다.
자주 묻는 추가 질문
Q. 생성자 주입을 사용할 때도 객체 생성과 의존관계 주입이 분리되나요?
아닙니다. 생성자 주입의 경우 빈 객체를 생성할 때 필수 파라미터로 의존성을 전달해야 하므로 객체 생성과 의존관계 주입이 동시에 일어납니다.
Q. 프로토타입(Prototype) 스코프 빈의 생명주기는 어떻게 다른가요?
스프링 컨테이너는 프로토타입 빈의 생성, 의존관계 주입, 초기화까지만 관여하고 클라이언트에게 반환한 후 관리하지 않습니다. 따라서 소멸 콜백이 호출되지 않습니다.
Q. InitializingBean과 DisposableBean 인터페이스는 왜 요즘 안 쓰나요?
스프링 전용 인터페이스라 코드가 스프링에 강하게 결합되며, 메서드 이름을 변경할 수 없다는 단점 때문에 최근에는 @PostConstruct 애노테이션을 주로 사용합니다.
커뮤니티 하이라이트
“실무에서는 99% @PostConstruct와 @PreDestroy를 사용합니다. 외부 라이브러리 빈 등록 시에만 @Bean 속성을 쓴다고 명확히 나누어 답변하면 좋습니다.”
“면접에서 생성자 주입과의 생명주기 차이점을 묻는 꼬리 질문이 자주 들어옵니다. 생성자 주입은 '예외적으로 동시에 일어난다'는 점을 꼭 기억하세요!”
42명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.