--- category: Architecture tags: [auto-wikified, technical-documentation, architecture] title: Dependency Injection description: "의존성 주입(Dependency Injection, DI)은 클래스가 필요로 하는 의존성(객체)을 직접 생성하지 않고 프레임워크나 외부 컨테이너를 통해 주입받도록 하는 소프트웨어 아키텍처 패턴이다 [1-3]." last_updated: 2026-05-04 --- # Dependency Injection ## 📌 Brief Summary 의존성 주입(Dependency Injection, DI)은 클래스가 필요로 하는 의존성(객체)을 직접 생성하지 않고 프레임워크나 외부 컨테이너를 통해 주입받도록 하는 소프트웨어 아키텍처 패턴이다 [1-3]. 이를 통해 시스템 컴포넌트 간의 강한 결합을 방지하고 유연성을 높일 수 있다 [1]. Spring Boot, NestJS, Vue 3 등 현대 프레임워크 전반에서 핵심 구조로 채택되어 코드의 테스트 가능성과 모듈성을 극대화하는 데 사용된다 [2-4]. ## 📖 Core Content * **설계 원칙과 테스트 가능성 확보**: DI는 의존성 역전 원칙(Dependency Inversion Principle)을 구현하는 구체적인 수단이다 [1]. 구체적인 구현체에 직접 의존하는 대신 생성자 등을 통해 필요한 의존성을 주입받도록 함으로써, 시스템의 결합도를 낮추고 유연성을 제공한다 [1, 3]. 특히 단위 테스트(Unit testing) 환경에서 비즈니스 로직을 변경하지 않고도 실제 서비스를 모의(Mock) 객체로 손쉽게 교체할 수 있는 강력한 이점을 제공한다 [2, 3]. * **Spring Boot의 IoC 컨테이너 기반 DI**: Spring Boot는 Java 어노테이션을 활용하는 제어의 역전(IoC) 컨테이너를 통해 DI를 구현한다 [5, 6]. 애플리케이션 시작 시 컨테이너가 어노테이션을 읽어 의존성 그래프를 구성하며, 수동 연결(Manual wiring) 없이 생성자를 통해 빈(Bean)을 자동으로 주입한다 [6, 7]. * **NestJS의 데코레이터 기반 DI**: Node.js 생태계의 NestJS는 Angular의 설계 철학을 도입하여 TypeScript 데코레이터 기반의 강력한 의존성 주입 컨테이너를 제공한다 [3, 5, 8]. 클래스의 생성자에 필요한 의존성(예: 데이터베이스 서비스, 캐시 서비스 등)을 선언하기만 하면 프레임워크가 알아서 이를 제공하여 코드의 응집도를 높인다 [2, 3]. * **Vue 3의 Provide/Inject를 통한 의존성 주입**: 프론트엔드 환경인 Vue 3에서는 Provide/Inject 시스템이 DI의 역할을 수행한다 [4]. 이 패턴을 통해 글로벌 로거, API 클라이언트, 상태 등 공유 서비스를 최상위 공급자에서 깊게 중첩된 하위 컴포넌트로 직접 "텔레포트"할 수 있으며, 이로 인해 중간 계층 컴포넌트들이 불필요한 데이터를 전달받는 'Prop Drilling' 현상을 방지한다 [4, 9]. ## ⚖️ Trade-offs & Caveats * **성능 오버헤드**: 의존성 주입 시스템과 이를 위한 데코레이터 처리는 런타임 성능에 약간의 오버헤드를 유발할 수 있다 [10]. 예를 들어, NestJS의 경우 DI 시스템의 추상화 계층으로 인해 순수 Express 프레임워크를 사용할 때보다 초당 요청 처리량(Throughput)이 약 10~15% 정도 감소할 수 있다 [10]. * **과도한 스캐폴딩과 구조적 복잡성**: DI 컨테이너와 모듈 시스템을 올바르게 구축하려면 많은 설정과 보일러플레이트 코드 작성이 요구된다 [11, 12]. 2~5명 규모의 소규모 팀이나 단순한 기능의 프로젝트에서는 이러한 구조적 제약이 실제 비즈니스 가치 창출보다 프레임워크 배선(Wiring) 작업에 더 많은 시간을 쏟게 하는 비용(기술 부채)으로 작용할 수 있다 [11]. * **프레임워크 우회 시 발생하는 안티 패턴**: DI를 지원하는 프레임워크 환경에서 개발자가 DI 컨테이너를 우회하여 직접 의존성을 인스턴스화(예: `new UsersService()`와 같이 객체를 수동 생성)하는 방식은 시스템의 이점을 파괴한다 [13]. 이와 같은 수동 의존성 연결은 아키텍처의 일관성을 해치고 테스트 가능성을 완전히 상실하게 만든다 [13]. --- *Last updated: 2026-05-03*