2025.12.09Spring

💉 Spring으로 알아보는 의존성 주입(DI)

프레임워크를 사용하다 보면 자연스럽게 쓰게 되지만 막상 DI가 무엇인지 명확히 설명하기 애매한 경우도 많다. 이번 글에서는 DI가 무엇인지, 왜 쓰는지, 그리고 실제 코드에서는 어떻게 사용되는지 알아보자.

DI(Dependency Injection)란?

필요한 객체를 내가 직접 new 하지 않고 외부에서 넣어 주도록 만드는 것을 의미한다.

예를 들어 A 클래스에서 B 클래스를 필요로 할 때 A 클래스 내부에서 new 키워드를 사용하여 직접 생성하는 대신 프레임워크(스프링, NestJS 등)의 컨테이너가 B 클래스를 A에 주입해 주는 방식이다.

의존성(Dependency)을 외부에서 주입(Injection) 한다는 의미

*DI를 사용하는 이유

그냥 객체 내부에서 new 해서 사용하면 되는 것 아닌가?라는 생각이 들 수도 있지만 DI를 사용했을 때의 장점들이 있다.

1. 테스트가 쉬워진다 (Mock 주입)

먼저 DI가 없는 코드를 보면

java

// DI를 사용하지 않고 직접 생성
public class PostService {
  
  private final PostRepository postRepository = new PostRepository();
  
  public Post getPost(Long id) {
    return postRepository.findById(id);
  }
}

이런 경우 테스트할 때 몇 가지 문제가 존재하는 데 예를 들어 PostRepository가 DB에 직접 붙는 구현체라면 단위 테스트마다 실제 DB를 필요로 하여 Mock(가짜 객체)로 변경하기가 어렵다.

따라서 DI를 적용하면 아래와 같다.

java

// DI 적용
public class PostService {
  
  private final PostRepository postRepository;
  
  public PostService(PostRepository postRepository) {
    this.postRepository = postRepository; // 외부에서 주입
  }
  
  public Post getPost(Long id) {
    return postRepository.findById(id);
  }
}

이제 테스트 시에는 아래와 같이 Mock 객체를 주입할 수 있다.

java

PostRepository mockRepo = mock(PostRepository.class);
PostService postService = new PostService(mockRepo);

실제 DB를 붙이지 않고도 Mock 객체를 주입해서 PostService를 순수하게 테스트할 수 있다.

2. 결합도를 낮추어 유지 보수가 쉬워진다

DI의 핵심은 추상 타입(인터페이스)에 의존하라는 원칙과 잘 맞는다. 예를 들어 새 댓글이 달리면 글 작성자에게 알림을 보내는 기능을 만든다고 생각해 보자. 처음에는 이메일만 보내면 된다고 생각해서 아래와 같이 인터페이스를 정의할 수 있다.

java

// 알림 인터페이스
public interface BlogNotifier {
  void notifyNewComment(Long postId, String commentAuthor, String commentContent);
}

// 이메일 알림 구현체
public class EmailBlogNotifier implements BlogNotifier {
  
  @Override
  public void notifyNewComment(
    Long postId, String commentAuthor, String, commentContent
  ) {
    // 이메일 전송 로직
  }
}

그런데 블로그를 운영하던 도중 요구사항이 바뀌어 슬랙으로 알림을 보내야 하는 경우라면 아래와 같이 슬랙 알림 구현체를 만들면 된다.

java

// 슬랙 알림 구현체
public class SlackBlogNotifier implements BlogNotifier {
  
  @Override
  public void notifyNewComment(
    Long postId, String commentAuthor, String commentContent
  ) {
    // 슬랙 알림 전송 로직    
  }
}

여기서 중요한 포인트는 CommentService 코드는 변경하지 않고 단지 DI 설정에서 어떤 구현체를 주입할지만 결정하면 된다는 점이다. 예를 들어 스프링이라면 다음과 같이 설정할 수 있다.

java

@Configuration
public class BlogConfig {
  
  @Bean
  public BlogNotifier blogNotifier() {
    // 상황에 맞는 구현체를 선택
    // return new EmailBlogNotifier();
    return new SlackBlogNotifier();
    // 필요한 경우 Email + Slack을 묶은 Composite 구현체를 만드는것도 가능
  }
  
  @Bean
  public CommentService commentService(BlogNotifier blogNotifier) {
    return new CommentService(blogNotifier);
  }
}

이렇게 하면 CommentService는 오직 BlogNotifier 인터페이스만 의존한다. 실제로 이메일을 보낼지 슬랙을 보낼지는 컨테이너 설정에서 결정하여 나중에 WebPush, 카카오톡 알림 등을 추가하고 싶어도 새로운 구현체를 만들고 DI 설정만 바꾸면 되기 때문에 유지 보수와 확장이 훨씬 쉬워진다.

DI와 IoC(Inversion of Control)

DI가 나오면 항상 따라오는 단어가 하나 더 있다. 바로 IoC(Inversion of Control) 제어의 역전이다. 기존 전통적인 방식에서는 누가 어떤 객체를 new 할지, 누가 누구를 호출할지 전부 내 코드가 직접 제어한다.

java

public class Main {
  public static void main(String[] args) {
    PostRepository repo = new PostRepository();
    PostService service = new PostService(repo);
    
    Post post = service.getPost(1L);
  }
}

위 코드에서는 직접 객체 생성 순서와 의존성을 모두 제어하고 있다. 그러나 스프링, NestJS 같은 프레임워크를 사용하면 객체를 언제 만들지, 어떤 순서로 만들지, 어떤 객체에 어떤 의존성을 주입할지 같은 이런 제어권을 프레임워크의 IoC 컨테이너가 가져간다.

우리는 그저 이 클래스가 서비스인지 레포지토리인지 혹은 주입받아 사용할지 등의 여부만 어노테이션을 통해 표시해 주면 된다.

java

@Repository
public class PostRepository {
  // 레포지토리 코드
}

@Service
public class PostService {
  
  private final PostRepository postRepository;
  
  @Autowired
  public PostService(PostRepository postRepository) {
    this.postRepository = postRepository;
  }
}

직접 new 하지 않고 컨테이너가 객체를 만들고 주입한다. 즉 제어(Control)가 우리 코드에서 프레임워크로 역전(Inversion) 되었다. 이것을 IoC라고 하며 그 구체적인 방법 중 하나가 DI이다.

DI의 주입 방법

DI에는 보통 세 가지 방식이 있다.

생성자 주입(Constructor Injection)
필드 주입(Field Injection)
세터 주입(Setter Injection)

요즘은 생성자 주입이 가장 권장되는 방식이다.

*생성자 주입

java

@Service
public class PostService {
  
  private final PostRepository postRepository;
  
  public PostService(PostRepository postRepository) {
    this.postRepository = postRepository;
  }
}

final 필드를 사용할 수 있어 불변성을 지킬 수 있으며 테스트 코드에서 생성자만 호출하면 되기 때문에 테스트도 용이하다. (Lombok 사용 시 @RequiredArgsConstructor로도 가능)

*필드 주입

java

@Service
public class PostService {
  
  @Autowired
  private PostRepository postRepository;
}

코드가 굉장히 간단해지지만 필드가 final이 될 수 없고 테스트 시 Mock 주입이 불편하여 요즘은 지양하는 방식으로 취급된다. (DI 컨테이너 없이 순수 자바 코드로 생성하기도 어렵다)

*세터 주입

java

@Service
public class PostService {
  
  private PostRepository postRepository;
  
  @Autowired
  public void setPostRepository(PostRepository postRepository) {
    this.postRepository = postRepository;
  }
}

선택적인 의존성이나 런타임에 구현체가 바뀔 수 있는 경우에 사용되기도 하지만 일반적인 서비스/레포지토리 구조에서는 생성자 주입이 더 깔끔하다.

2025.12.09Spring

💉 Spring으로 알아보는 의존성 주입(DI)

DI(Dependency Injection)란?

*DI를 사용하는 이유

그냥 객체 내부에서 new 해서 사용하면 되는 것 아닌가?라는 생각이 들 수도 있지만 DI를 사용했을 때의 장점들이 있다.

1. 테스트가 쉬워진다 (Mock 주입)

먼저 DI가 없는 코드를 보면

java

// DI를 사용하지 않고 직접 생성
public class PostService {
  
  private final PostRepository postRepository = new PostRepository();
  
  public Post getPost(Long id) {
    return postRepository.findById(id);
  }
}

java

// DI 적용
public class PostService {
  
  private final PostRepository postRepository;
  
  public PostService(PostRepository postRepository) {
    this.postRepository = postRepository; // 외부에서 주입
  }
  
  public Post getPost(Long id) {
    return postRepository.findById(id);
  }
}

이제 테스트 시에는 아래와 같이 Mock 객체를 주입할 수 있다.

java

PostRepository mockRepo = mock(PostRepository.class);
PostService postService = new PostService(mockRepo);

실제 DB를 붙이지 않고도 Mock 객체를 주입해서 PostService를 순수하게 테스트할 수 있다.

2. 결합도를 낮추어 유지 보수가 쉬워진다

java

// 알림 인터페이스
public interface BlogNotifier {
  void notifyNewComment(Long postId, String commentAuthor, String commentContent);
}

// 이메일 알림 구현체
public class EmailBlogNotifier implements BlogNotifier {
  
  @Override
  public void notifyNewComment(
    Long postId, String commentAuthor, String, commentContent
  ) {
    // 이메일 전송 로직
  }
}

그런데 블로그를 운영하던 도중 요구사항이 바뀌어 슬랙으로 알림을 보내야 하는 경우라면 아래와 같이 슬랙 알림 구현체를 만들면 된다.

java

// 슬랙 알림 구현체
public class SlackBlogNotifier implements BlogNotifier {
  
  @Override
  public void notifyNewComment(
    Long postId, String commentAuthor, String commentContent
  ) {
    // 슬랙 알림 전송 로직    
  }
}

java

@Configuration
public class BlogConfig {
  
  @Bean
  public BlogNotifier blogNotifier() {
    // 상황에 맞는 구현체를 선택
    // return new EmailBlogNotifier();
    return new SlackBlogNotifier();
    // 필요한 경우 Email + Slack을 묶은 Composite 구현체를 만드는것도 가능
  }
  
  @Bean
  public CommentService commentService(BlogNotifier blogNotifier) {
    return new CommentService(blogNotifier);
  }
}

DI와 IoC(Inversion of Control)

java

public class Main {
  public static void main(String[] args) {
    PostRepository repo = new PostRepository();
    PostService service = new PostService(repo);
    
    Post post = service.getPost(1L);
  }
}

java

@Repository
public class PostRepository {
  // 레포지토리 코드
}

@Service
public class PostService {
  
  private final PostRepository postRepository;
  
  @Autowired
  public PostService(PostRepository postRepository) {
    this.postRepository = postRepository;
  }
}

DI의 주입 방법

DI에는 보통 세 가지 방식이 있다.

생성자 주입(Constructor Injection)
필드 주입(Field Injection)
세터 주입(Setter Injection)

요즘은 생성자 주입이 가장 권장되는 방식이다.

*생성자 주입

java

@Service
public class PostService {
  
  private final PostRepository postRepository;
  
  public PostService(PostRepository postRepository) {
    this.postRepository = postRepository;
  }
}

java

@Service
public class PostService {
  
  @Autowired
  private PostRepository postRepository;
}

java

@Service
public class PostService {
  
  private PostRepository postRepository;
  
  @Autowired
  public void setPostRepository(PostRepository postRepository) {
    this.postRepository = postRepository;
  }
}