T
TechInsights
목록으로
BackEnd•2025. 12. 23.

코드 품질 개선 기법 27편: 티끌이 모여 태산이 되듯 의존성도 쌓이면

라인
라인 Engineering Team
코드 품질 개선 기법 27편: 티끌이 모여 태산이 되듯 의존성도 쌓이면

핵심요약

원문 보기

의존성 주입(DI)의 목적을 명확히 하고, 상태가 없는 단순 클래스나 유틸리티 함수에는 불필요한 주입을 최소화해야 코드 복잡도를 줄일 수 있다는 점을 설명합니다. 목적 없는 DI는 오히려 암묵적 의존성 증가와 값 연관성 파괴를 초래할 수 있음을 지적합니다.

코드 품질 개선: 불필요한 의존성 주입 최소화

핵심 요약

  • 의존성 주입(Dependency Injection)은 특정 목적(범위/라이프사이클 관리, 의존성 역전, 구현 전환 등)을 위해 사용해야 하며, 목적 없는 주입은 오히려 코드의 복잡성을 증가시키고 유지보수를 어렵게 함.
  • 유틸리티 함수나 상태 없는(stateless) 단순 클래스는 의존성 주입 없이 직접 호출하거나 인스턴스화하는 것이 효율적.

문제 사례 분석

  • LatestNewsSnippetUseCase 클래스에서 modelFactory, stringTruncator, timeFormatter를 생성자로 주입받는 경우.
  • modelFactory는 NewsSnippet 생성자 참조로 대체 가능하며, stringTruncator와 timeFormatter는 상태가 없다면 싱글톤 객체 또는 일반 private 속성으로 관리하는 것이 불필요한 주입을 줄임.

불필요한 의존성 주입의 문제점

  • 불필요하고 암묵적인 의존성: 생성자나 인터페이스를 통해 주입된 의존성의 호출자를 추적하기 어려워짐.
  • 호출자의 책임 증가: 연쇄적인 의존성 해결로 메인 클래스에 복잡도가 집중될 수 있음 (DI 컨테이너 등으로 완화 가능).
  • 값의 연관성 파괴: Locale과 같이 여러 곳에서 사용될 것으로 기대되는 공통 값이 실제로는 다른 값이 전달될 수 있으며, 이를 검증하기 어려워짐.

개선 방안

  • 의존성을 주입할 때는 반드시 그 목적을 명확히 하고, 꼭 필요한 경우에만 적용.
  • 상태가 없거나 참조 투명한(referentially transparent) 함수/클래스는 직접 호출하거나 인스턴스화하여 불필요한 의존성 발생 방지.

결론

  • 의존성 주입은 코드의 유연성과 테스트 용이성을 높이는 강력한 패턴이지만, 남용될 경우 오히려 복잡도를 야기.
  • 코드의 요구사항과 목적을 명확히 파악하여 최적의 의존성 관리 방식을 선택하는 것이 중요.
#BackEnd#Architecture
라인
라인

라인 Engineering Team

기술 인사이트를 전달하는 공식 채널

You might also like

View all
토스 피플 : 새로운 길을 만들 땐 내 선택을 믿는다

토스 피플 : 새로운 길을 만들 땐 내 선택을 믿는다

"이 버튼 왜 안 눌려요?" 물류 현장의 목소리로 PDA 시스템 완성하기

"이 버튼 왜 안 눌려요?" 물류 현장의 목소리로 PDA 시스템 완성하기