의존성 주입(DI)과 @Service

의존성 주입(DI) 이란?

정의

의존성 주입은 객체 간의 의존 관계를 개발자가 직접 생성하지 않고,
스프링이 대신 주입해주는 설계 패턴입니다.

즉, 객체를 직접 new 하지 않고, 필요한 객체를 외부에서 주입받는 것입니다.

---

왜 필요한가?

전통적인 방식	문제점
UserService userService = new UserService();	클래스가 스스로 의존 대상을 만들기 때문에 결합도가 높고 테스트 어려움

DI를 사용하면 이렇게 바뀝니다:

@Service
public class UserService {
    private final UserRepository userRepository;

    // 생성자를 통해 주입 (Constructor Injection)
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

테스트 코드 작성, Mock 객체 주입, 확장성 등에서 유리합니다.

---

의존성 주입 방식 3가지

방식	특징	추천 여부
생성자 주입	생성자에서 주입 (불변성 유지)	가장 권장
필드 주입	@Autowired로 직접 주입	테스트 어려움, 비권장
세터 주입	@Autowired를 세터에 적용	선택적 의존성에만 적합

생성자 주입 예

@Service
public class MemberService {

    private final MemberRepository memberRepository;

    // 생성자 주입 (권장 방식)
    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

@RequiredArgsConstructor(롬복) 사용 시 자동 생성자 주입도 가능

---

@Service 애너테이션

역할

• 해당 클래스를 **비즈니스 로직 계층(Service Layer)**으로 스프링이 인식하게 해주는 애너테이션
• 자동으로 스프링 컨테이너에 Bean으로 등록

내부적으로는 @Component의 특수화 형태

즉, 다음과 같은 역할을 함:

@Component // 스프링 Bean 등록
public class MemberService {}

 

하지만 의미가 불분명하므로, 용도에 맞게 @Service, @Repository, @Controller 사용을 권장합니다.

---

스프링 컨테이너의 Bean 주입 과정

1. @Service, @Repository 등으로 Bean 등록
2. 필요한 곳에 생성자 or @Autowired로 주입
3. 스프링이 객체 간의 의존 관계를 자동 주입

---

예시 프로젝트 구조

com.example.demo
├── controller/
│   └── MemberController.java
├── service/
│   └── MemberService.java ← @Service
├── repository/
│   └── MemberRepository.java ← @Repository

MemberController

@RestController
@RequiredArgsConstructor
public class MemberController {
    private final MemberService memberService;
}

MemberService

@Service
@RequiredArgsConstructor
public class MemberService {
    private final MemberRepository memberRepository;
}

---

정리 요약

항목	설명
DI(의존성 주입)	객체의 의존성을 스프링이 주입해줌
@Service	비즈니스 계층을 명시하며 Bean 등록
추천 주입 방식	생성자 주입 (@RequiredArgsConstructor로 자동화)
장점	결합도 낮음, 테스트 용이, 코드 간결화, 유지보수성 ↑