그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

의존성 주입이 뭔가요

실무4/5
설계4/5
인간3/5
기초3/5

면접관의 질문 의도

DI를 '스프링이 알아서 해주는 것'으로만 외운 사람과, 왜 생성 책임을 떼어내야 하는지·필수와 선택 의존성을 어떻게 가르는지까지 답하는 사람을 구분하려는 질문이다. 답에 따라 생성자 주입 강제 이유나 순환 참조 처리로 깊이를 캐물을 수 있다.

큐레이션 답변

학습 자료

의존성 주입(DI)은 객체가 필요한 협력자를 자기가 직접 new하지 않고, 외부 조립자가 만들어서 넣어주는 방식이다. 핵심은 생성 책임과 사용 책임의 분리다. 이렇게 분리해두면 구현을 바꿔 끼우거나 테스트 더블을 넣기 쉬워지고, 객체는 자기 일에만 집중한다. 필수 의존성은 생성자 주입으로 강제해 누락 가능성을 컴파일 시점에 잘라낸다.

좋은 답변 구조

  1. 01의존성과 DI를 '생성 책임 분리'라는 핵심 동작 원리로 먼저 정의한다
  2. 02객체가 직접 new할 때 생기는 결합도·테스트 비용 문제를 짚는다
  3. 03생성자·세터·메서드 주입의 차이와 각자가 답하는 문제를 정리한다
  4. 04필수 의존성은 생성자 주입으로 강제한다는 결론과 근거를 단정한다

자주 실수하는 포인트

DI를 '스프링 어노테이션 사용법'으로만 설명하고 생성 책임 분리라는 원리를 빠뜨린다
필수 의존성을 세터/필드 주입으로 처리해 누락 시점을 런타임까지 미룬다
DI와 IoC를 같은 말로 섞어 쓰면서 둘의 포함 관계를 구분하지 못한다
주입 방식 선택을 '취향'이라 답하고 테스트성·불변성 같은 근거를 대지 못한다

실무 맥락

  • 외부 시스템·DB 접근 객체를 모킹해 단위 테스트를 빠르게 돌려야 하는 서비스 계층
  • 결제·메시지 발송처럼 같은 인터페이스에 여러 구현체를 환경별로 갈아 끼우는 모듈
  • 스프링 빈 스코프와 생명주기를 명시적으로 설계해야 하는 멀티 모듈 백엔드

본인 경험에 녹이는 힌트

new로 직접 만들던 서비스를 생성자 주입으로 바꿔서 테스트 작성이 갑자기 쉬워졌던 경험이 있다면 DI가 결합도에 어떤 영향을 주는지 설명할 수 있다

필드/세터 주입을 쓰다가 NPE나 누락 의존성을 만났던 경험이 있다면 왜 필수 의존성을 생성자로 강제해야 하는지 근거로 댈 수 있다

결제 모듈처럼 구현체를 환경별로 교체해 본 경험이 있다면 인터페이스에 의존하고 조립을 외부로 미루는 가치를 자기 말로 풀 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1IoC와 DI의 관계는 어떻게 정리하나요
Q2생성자 주입이 세터 주입보다 안전한 이유는 무엇인가요
Q3생성자 주입으로 풀리지 않는 순환 참조는 어떻게 처리하나요
Q4DI 컨테이너 없이 순수 자바로 DI를 적용할 때 어떤 비용이 드나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문