Spring · IoC와 의존성 주입

Spring의 핵심은 한 문장으로 줄일 수 있습니다 — "객체를 만들고 연결하는 일을 개발자가 아니라 Spring이 대신한다." 이것이 IoC(제어의 역전) 이고, 그 구체적인 방법이 DI(의존성 주입)^? 입니다. 이 페이지에서는 빈을 등록하고 주입받는 모든 방법을 차근차근 풀어봅니다.

1. IoC — 제어의 역전

보통 프로그램은 내가 필요한 객체를 직접 만듭니다. 예를 들어 서비스 안에서 new UserRepo() 라고 적어 리포지토리를 직접 생성하죠. IoC(Inversion of Control, 제어의 역전) 는 이 "객체를 만들고 서로 연결하는 권한"을 개발자에게서 빼앗아 Spring^? 컨테이너에게 넘기는 것입니다. 누가 객체를 만들지 그 제어권이 나 → 프레임워크로 뒤집혔다(역전) 고 해서 이런 이름이 붙었어요.

2. 빈과 컨테이너

Spring 컨테이너가 만들고 관리하는 객체를 빈(Bean) 이라고 부릅니다. 일반적인 객체와 다를 것은 없지만, "내가 new 로 만든 게 아니라 Spring이 만들어 보관 중인 객체"라는 점이 다릅니다. 이 빈들을 담아두고 필요할 때 꺼내주는 보관소가 컨테이너 입니다.

애플리케이션이 시작되면 컨테이너가 빈들을 전부 만들어 서로 연결(주입)한 뒤, 요청이 들어올 때마다 이미 준비된 빈을 꺼내 씁니다. 우리가 직접 객체를 조립할 필요가 없는 이유가 여기 있습니다.

3. 빈 등록 방법

어떤 객체를 빈으로 쓰고 싶으면 Spring에게 "이건 빈이야"라고 알려줘야 합니다. 크게 두 가지 길이 있습니다.

3-1. 스테레오타입 애너테이션 + 컴포넌트 스캔

클래스 위에 스테레오타입(stereotype, 역할 표시) 애너테이션 을 붙이면, Spring이 시작할 때 패키지를 훑어 (이것을 컴포넌트 스캔 이라 합니다) 표시된 클래스를 자동으로 빈으로 등록합니다. 아래 다섯 개는 사실 모두 @Component^? 의 특수한 형태입니다 — 동작은 같고 "이 클래스가 어느 층 소속인지" 의미만 다릅니다.

그럼 Spring은 어느 패키지를 훑을까요? @ComponentScan 이 그 시작 지점을 정합니다. 그런데 보통은 이걸 직접 쓸 일이 없습니다 — 앱 진입점에 붙은 @SpringBootApplication 안에 이미 @ComponentScan 이 포함되어 있어, 진입점 클래스가 있는 패키지와 그 하위 를 자동으로 스캔하기 때문입니다. 이 프로젝트라면 com.example.study 패키지 아래가 전부 스캔 대상입니다.

3-2. @Bean — 메서드 단위 등록

내가 만든 클래스가 아니라 외부 라이브러리 객체 처럼 애너테이션을 붙일 수 없는 경우, 또는 생성 과정을 직접 손봐야 하는 경우엔 @Configuration 클래스 안에 @Bean 메서드를 만듭니다. 메서드가 반환하는 객체가 빈으로 등록되고, 기본 빈 이름은 메서드 이름이 됩니다.

@Configuration
public class AppConfig {

  @Bean                                  // 반환 객체가 빈으로 등록됨
  public ObjectMapper objectMapper() {   // 빈 이름 = "objectMapper"
    ObjectMapper m = new ObjectMapper();
    m.registerModule(new JavaTimeModule());
    return m;
  }
}

정리하면 — 내 코드 클래스는 스테레오타입 애너테이션, 외부/조립이 필요한 객체는 @Bean 으로 등록합니다.

4. 의존성 주입 3가지 방법

빈이 다른 빈을 필요로 할 때, 그 필요한 객체(의존성)를 Spring이 넣어주는 것이 주입(injection) 입니다. 넣는 방법은 세 가지가 있습니다.

4-1. 생성자 주입 (권장)

생성자의 매개변수로 필요한 빈을 받습니다. 필드를 final 로 선언하면 한 번 주입된 뒤 바뀌지 않습니다(불변). 생성자가 하나뿐이면 @Autowired 를 붙이지 않아도 Spring이 알아서 주입합니다. 실무에서는 Lombok의 @RequiredArgsConstructor 가 final 필드용 생성자를 자동으로 만들어 주므로 코드가 깔끔합니다.

@Service
@RequiredArgsConstructor             // final 필드를 받는 생성자 자동 생성
public class UserService {
  private final UserRepo userRepo;   // Spring이 생성자로 주입

  // 생성자가 하나면 @Autowired 생략 가능
}

4-2. 세터 주입

세터(set 메서드)에 @Autowired 를 붙여 주입합니다. 있어도 되고 없어도 되는 선택적 의존성 에 어울립니다. 나중에 다시 넣어줄(재설정) 수 있다는 장점이 있지만, 객체가 만들어진 직후엔 그 의존성이 비어 있을 수 있다는 단점이 있습니다.

@Service
public class ReportService {
  private MailSender mailSender;     // 선택적 의존성

  @Autowired(required = false)       // 없어도 통과
  public void setMailSender(MailSender mailSender) {
    this.mailSender = mailSender;
  }
}

4-3. 필드 주입

필드 위에 바로 @Autowired 를 붙입니다. 가장 짧지만 권장하지 않습니다. final 로 만들 수 없고, 테스트할 때 직접 값을 넣기 어려우며, 의존성이 몇 개인지 한눈에 안 보여 클래스가 비대해지는 것을 가립니다.

@Service
public class OrderService {
  @Autowired                         // 필드 주입 — 짧지만 비권장
  private UserRepo userRepo;
}

5. 주입을 돕는 애너테이션

같은 타입의 빈이 여러 개라 Spring이 "어느 걸 넣어야 하지?" 헷갈릴 때 길잡이가 되는 애너테이션들입니다.

public interface PaymentGateway {}

@Component @Primary                          // 기본 후보
public class TossGateway implements PaymentGateway {}

@Component("kakao")
public class KakaoGateway implements PaymentGateway {}

@Service
@RequiredArgsConstructor
public class CheckoutService {
  private final PaymentGateway gateway;      // @Primary 덕에 TossGateway 주입

  // 특정 구현이 필요하면:
  // public CheckoutService(@Qualifier("kakao") PaymentGateway g) { ... }
}

6. 빈 스코프 — 빈은 몇 개나 만들어지나

스코프(scope) 는 "빈을 얼마나 만들어 얼마나 오래 쓸지"를 정합니다. 아무것도 지정하지 않으면 기본은 싱글톤 입니다 — 컨테이너 안에 딱 하나만 만들어 모두가 그 하나를 공유합니다.

@Component
@Scope("prototype")        // 주입할 때마다 새 객체
public class Cart {}

7. 빈 생명주기 콜백

빈은 "만들어진 직후"와 "사라지기 직전"에 할 일을 정해둘 수 있습니다 — 연결 풀 준비, 캐시 채우기, 리소스 정리 같은 것이죠. 방법은 세 가지이고, 표준 애너테이션 방식이 가장 권장됩니다.

@Component
public class CacheWarmer {

  @PostConstruct                 // jakarta.annotation.PostConstruct
  public void init() {
    // 주입이 모두 끝난 직후 1회 실행 — 캐시 미리 채우기 등
  }

  @PreDestroy                    // jakarta.annotation.PreDestroy
  public void cleanup() {
    // 앱 종료 직전 1회 실행 — 리소스 정리 등
  }
}

실행 순서는 초기화 때 @PostConstruct → afterPropertiesSet(), 소멸 때 @PreDestroy → destroy() 입니다.

8. 그 밖에 알아둘 것

9. 예제 — 레이어가 서로 주입되는 흐름

엔티티^? → 리포지토리^? → 서비스로 이어지는 전형적인 구성을, 전부 생성자 주입 으로 엮어 보겠습니다.

// (1) 엔티티 — DB 테이블과 매핑되는 객체 (빈 아님)
@Entity
public class User {
  @Id @GeneratedValue
  private Long id;
  private String name;
}

// (2) 리포지토리 — DB 접근 빈
public interface UserRepo extends JpaRepository<User, Long> {
  List<User> findByNameContaining(String keyword);
}

// (3) 서비스 — 비즈니스 로직 빈, 리포지토리를 주입받음
@Service
@RequiredArgsConstructor
public class UserService {
  private final UserRepo userRepo;          // 생성자로 주입

  @Transactional(readOnly = true)
  public List<User> search(String keyword) {
    return userRepo.findByNameContaining(keyword);
  }
}

객체 생성·연결의 주체

[개발자가 하던 일]                [Spring 컨테이너가 대신]
new UserRepo()          ──IoC──▶  UserRepo 빈 생성
new UserService(repo)             UserService 빈 생성
service.userRepo = repo           생성자로 repo 주입
                                  완성된 빈을 보관 → 필요할 때 제공

개발자는 new 를 한 번도 쓰지 않았습니다. 어떤 빈이 어떤 빈을 필요로 하는지(final UserRepo)만 선언하면, 컨테이너가 알아서 만들고 연결합니다. 이것이 IoC와 DI가 함께 만들어내는 결과입니다.

한눈에 — 애너테이션 카탈로그

다음 단계

• 이 빈들로 HTTP API를 만드는 방법 → Spring 웹 · REST
• 리포지토리·엔티티로 DB를 다루는 방법 → JPA
• 실제 코드로 배우는 백엔드 → be-01 Spring 기초