[스프링 로드맵] B-2. DI/Bean 내부 - 빈 등록 방식과 라이프사이클

B-1에서 IoC / DI / Bean의 큰 그림을 잡았다면, 이제는 “그럼 빈은 어디서, 어떻게 등록되나?”를 정리할 차례다.

이 글은 애너테이션을 외우는 게 목적이 아니라,

• 빈을 자동으로 찾는 방식
• 직접 등록하는 방식
• 빈이 언제 만들어지고 언제 사라지는지

이 3가지를 개념 위주로 정리하는 게 목표다.

---

1. 빈 등록 방식은 딱 2가지

스프링에서 빈을 등록하는 방법은 생각보다 단순하다.

1. 컴포넌트 스캔 방식 (자동)
2. @Configuration + @Bean 방식 (수동)

이 둘만 이해하면, 나머지는 변형이다.

---

2. 컴포넌트 스캔 방식: 스프링이 알아서 찾아준다

2-1) 개념

컴포넌트 스캔이란, 특정 패키지 아래에서 ‘빈으로 쓸 만한 클래스’를 스프링이 자동으로 찾아 등록하는 것.

 

대표적인 애너테이션들:

• @Component
• @Service
• @Repository
• @Controller
• @RestController

이 애너테이션이 붙은 클래스는 스캔 대상이 된다.

 

2-2) 스캔은 언제, 어디서 시작되나?

Spring Boot에서는 보통

@SpringBootApplication
public class Application { }

이 클래스가 있는 패키지를 기준으로 하위 패키지 전체를 스캔한다.

 

예를 들어:

com.example.app
 ├─ Application
 ├─ controller
 ├─ service
 └─ repository

이 구조면, controller/service/repository 안의 컴포넌트들이 전부 스캔된다.

 

2-3) 왜 @Service, @Repository 같은 걸 나눠 쓰나?

기능적으로는 아래가 거의 같다.

@Component
@Service
@Repository

차이는 “의미를 드러내는 용도”에 가깝다.

• @Service → 비즈니스 로직
• @Repository → 저장소 계층
• @Controller → 웹 요청 처리

“이 클래스가 어떤 역할인지”를 코드에서 바로 읽히게 하기 위한 구분이라고 이해하면 된다.

---

3. @Configuration + @Bean: “내가 직접 등록한다”

3-1) 왜 수동 등록이 필요할까?

컴포넌트 스캔은 클래스에 애너테이션을 붙일 수 있을 때만 쓸 수 있다.

하지만 이런 경우도 있다.

• 외부 라이브러리 클래스
• 생성 과정이 복잡한 객체
• 조건에 따라 다른 객체를 등록하고 싶을 때

이럴 때 쓰는 게 수동 등록 방식이다.

 

3-2) 기본 형태

@Configuration
public class AppConfig {

  @Bean
  public Clock clock() {
    return Clock.systemDefaultZone();
  }
}

의미를 풀면:

• @Configuration
  -> “이 클래스는 빈 설정용 클래스다”
• @Bean
  -> “이 메서드의 반환값을 빈으로 등록해라”

이렇게 등록된 객체도 똑같이 Bean이고, DI 대상이 된다.

 

3-3) 컴포넌트 스캔 vs @Bean 감각 비교

구분	컴포넌트 스캔	@Bean
등록 주체	스프링이 자동	개발자가 직접
대상	내 클래스	외부/복잡한 객체
용도	일반적인 계층(Controller/Service 등)	설정/라이브러리/전략 객체

이 시리즈에서는:

• 기본 구조 → 컴포넌트 스캔
• 설정/특수 객체 → @Bean

이렇게 구분해서 이해하면 충분하다.

---

4. Bean Lifecycle: 빈은 언제 만들어지고 언제 사라질까?

라이프사이클을 깊게 파면 복잡해진다. 여기서는 흐름만 잡는다.

 

4-1) 빈 생성 흐름(단순화)

1. 스프링 컨테이너 시작
2. 빈 클래스 발견(스캔 or @Bean)
3. 객체 생성
4. 의존성 주입(DI)
5. 초기화 단계
6. 사용
7. 컨테이너 종료 시 정리

4-2) “초기화/종료”는 왜 존재하나?

어떤 객체는 생성만으로 끝나지 않는다.

• DB 커넥션 열기
• 파일/소켓 초기화
• 캐시 로딩

이런 작업은 생성 직후, 반대로 자원 해제는 종료 직전에 필요하다.

그래서 스프링은:

• “초기화 훅”
• “종료 훅”

을 제공한다.

이 글에서는 이름만 알아두면 된다.

• 초기화: @PostConstruct
• 종료: @PreDestroy

4-3) 지금 단계에서 기억할 것 3가지

1. 빈은 컨테이너 시작 시점에 만들어진다(기본 싱글톤)
2. DI는 생성 이후 자동으로 주입된다
3. 종료 시점에 정리할 수 있는 단계가 있다

구현까지는 다음 단계에서 다룬다.

---

5. 헷갈리기 쉬운 포인트 정리

“빈은 언제 new 되나?”

→ 스프링 컨테이너가 시작될 때(기본)

“컴포넌트 스캔이랑 @Bean 중 뭐가 더 좋나?”

→ 용도가 다르다. 자동 vs 수동.

“라이프사이클은 꼭 알아야 하나?”

→ 지금은 존재만 알면 된다.

왜 필요한지는 JPA/트랜잭션에서 자연스럽게 체감하게 된다.

---

6. 핵심 요약

• 빈 등록 방식은 자동(컴포넌트 스캔) / 수동(@Bean) 두 가지
• @Component 계열은 “스프링이 찾아서 등록”
• @Bean은 “개발자가 직접 만들어 등록”
• 빈은 생성 → 주입 → 사용 → 종료 흐름을 가진다
• 지금 단계에서는 개념 이해가 목적, 구현은 나중