3.0 KiB
3.0 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | |||
|---|---|---|---|---|---|---|---|
| Architecture |
|
Constructor Injection | Constructor Injection(생성자 주입)은 클래스의 생성자를 통해 객체가 필요로 하는 의존성을 명시적으로 선언하고 프레임워크로부터 해당 객체를 제공받는 의존성 주입(DI) 방식입니다 [1-3]. | 2026-05-04 |
Constructor Injection
📌 Brief Summary
Constructor Injection(생성자 주입)은 클래스의 생성자를 통해 객체가 필요로 하는 의존성을 명시적으로 선언하고 프레임워크로부터 해당 객체를 제공받는 의존성 주입(DI) 방식입니다 [1-3]. 모던 Spring Boot와 NestJS 같은 최신 엔터프라이즈 프레임워크에서 가장 선호되고 권장되는 접근법입니다 [1, 2]. 이 방식을 사용하면 수동으로 객체를 생성하거나 연결할 필요 없이, 프레임워크가 의존성을 자동으로 감지하고 인스턴스화하여 주입합니다 [2, 3].
📖 Core Content
- 프레임워크의 자동 의존성 해결: Spring Boot와 NestJS와 같은 프레임워크에서는 클래스 생성자에 필요한 의존성을 선언하기만 하면 됩니다 [1, 2]. 프레임워크의 제어 역전(IoC) 혹은 DI 컨테이너가 생성자를 감지하여 알맞은 빈(Bean)이나 프로바이더를 자동으로 주입하므로, 팩토리 메서드나 수동 배선(manual wiring) 코드를 생략할 수 있습니다 [2].
- 결합도 완화와 구조적 명확성: 의존성을 내부에서 직접 인스턴스화하거나 하드 코딩하여 임포트하는 대신, 생성자를 통해 외부에서 주입받는 방식을 취합니다 [1]. 이러한 접근은 컴포넌트 간의 강한 결합도를 낮추고 시스템을 더 유연하게 만듭니다 [1, 3].
- 테스트 가능성(Testability) 극대화: 생성자 주입의 가장 큰 기술적 이점은 단위 테스트의 용이성입니다 [1, 3]. 테스트 과정에서 비즈니스 로직을 전혀 변경하지 않고도, 생성자의 인자를 통해 실제 서비스 대신 모의 객체(Mock)를 손쉽게 교체하여 주입할 수 있어 독립적이고 격리된 테스트 환경을 구축하기 매우 수월해집니다 [1].
⚖️ Trade-offs & Caveats
- 기반 클래스(Base Class) 상속 시의 관리 부담: 상속을 활용해 기반 클래스에 공통 로직을 구성할 때 의존성이 개입되면, 이를 상속받는 모든 하위 구현체의 생성자에 해당 의존성을 전달하도록 코드를 작성해야 하는 제약과 부담이 발생합니다 [4].
- 의존성 변경에 따른 연쇄 수정 비용: 위의 상속 구조 등에서 새로운 의존성이 추가되는 설계 변경이 발생할 경우, 기반 클래스를 상속받는 모든 하위 클래스의 생성자 서명(Signature)을 일일이 찾아 수정해야 하는 유지보수 상의 비용과 번거로움이 발생할 수 있습니다 [4].
Last updated: 2026-05-03