AppConfig와 스프링 빈 질문

애송이

작성한 질문수 3

0

안녕하세요, 인프런 AI 인턴입니다.

애송이님, AppConfig를 사용하는 핵심 이유는 객체 생성과 의존관계 설정의 책임을 한곳에서 분리하기 위해서입니다.

스프링 빈으로 등록하면 스프링이 객체를 생성하고 필요한 의존성을 주입해 주지만, 어떤 구현체를 사용할지에 대한 구체적인 의존관계 설정은 여전히 필요합니다.

예를 들어 다음과 같이 서비스가 인터페이스에 의존한다고 가정해 보겠습니다.

public class MemberServiceImpl implements MemberService {
    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

MemberServiceImpl은 MemberRepository 인터페이스에만 의존하므로, MemoryMemberRepository를 사용할지 다른 구현체를 사용할지는 외부에서 결정해야 합니다. 이 역할을 AppConfig가 담당합니다.

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

이렇게 하면 MemberServiceImpl은 구체적인 구현체를 직접 알 필요가 없고, 구현체를 변경할 때 AppConfig만 수정하면 됩니다.

반면 컴포넌트 스캔과 @Autowired를 사용하는 방식은 스프링이 빈을 자동으로 찾아 주입해 주는 편리한 방식입니다. 하지만 같은 인터페이스의 구현체가 여러 개라면 어떤 빈을 주입할지 @Primary, @Qualifier 등의 추가 설정이 필요할 수 있습니다.

즉, 두 방식의 차이는 다음과 같습니다.

• AppConfig 방식: 객체 생성과 구현체 선택을 개발자가 명시적으로 관리
  
• 컴포넌트 스캔 방식: 스프링이 빈을 자동으로 검색하고 주입
  
• AppConfig의 장점: 구현체 변경, 의존관계 파악, 테스트용 객체 구성 등이 명확함
  
• 자동 주입의 장점: 반복적인 설정 코드가 줄어들고 편리함
  

실무에서는 기본적으로 컴포넌트 스캔과 자동 주입을 많이 사용하지만, 애플리케이션의 주요 의존관계를 명확히 드러내거나 구현체를 선택해야 하는 경우에는 @Configuration과 @Bean을 활용할 수 있습니다.

관련된 기존 답변을 함께 참고해 주세요.

AppConfig와 생성자 관련 질문드립니다

해당 답변에서도 AppConfig는 의존관계 설정의 책임을 맡고, 서비스 구현체는 인터페이스에 의존하도록 분리하는 이유를 설명하고 있습니다. MemberServiceImpl과 OrderServiceImpl의 생성자는 AppConfig 내부에서 호출되며, 이를 통해 구체적인 구현체를 외부에서 주입할 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.