의존성 주입(DI) 설정을 복사 붙여넣기하지 말고 이해하라
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
개발 툴
대상자
- 대상: Android 앱 개발자, 특히 Hilt/Dagger를 사용하는 중급 이상 개발자
- 난이도: 중간 (DI의 핵심 원리와 실무적 고려사항을 다룸)
핵심 요약
- 의존성 주입(DI)은 단순한 설정이 아니라
@Singleton,@Inject등의 스코프 이해와 컴포넌트 계층 구조를 바탕으로 한 설계가 필요함 - 과도한 주입은 클래스 결합도 증가, 테스트 어려움, 메모리 누수 등의 유지보수성 저하를 유발함
- DI의 진짜 이점(테스트 대체, SOLID 원칙 준수, 모듈화)을 얻으려면 Hilt/Koin 문서를 철저히 분석해야 함
섹션별 세부 요약
1. 스코프 오해의 위험성
@Singleton애노테이션은 Application 컴포넌트 또는 Activity의 생명주기와 결합되어야 함- 잘못된 스코프 설정은 메모리 누수 또는 네비게이션 오류를 유발할 수 있음
- 예:
@Singleton클래스가 Activity 생명주기와 맞지 않으면 불필요한 context 유지
2. 과도한 주입의 문제점
- 모든 클래스에
@Inject적용 시 의존성 결합도 증가, 의존성 숨김 발생 - 해결 방안:
- 생성자 주입은 핵심 의존성에 한해 사용
- 수동 DI는 작은 모듈 또는 테스트 케이스에 추천
3. DI의 진짜 이점 활용 방법
- 테스트 용이성: DI로 API/DB 의존성을 교체 가능
- SOLID 원칙 준수: 인터페이스 중심 설계 촉진
- 모듈화: 느슨한 결합 구조를 강제
- 필수 조건:
- 컴포넌트 계층 구조 이해
- 스코프 생명주기 관리
- Assisted Injection 활용
4. 수동 DI부터 시작하는 방법
- 예시:
```kotlin
class UserRepository(private val api: UserApi) { ... }
val api = Retrofit.Builder().build().create(UserApi::class.java)
val repo = UserRepository(api)
```
- 이 방식은 DI 프레임워크 내부 동작 원리를 이해하는 데 유리
5. 문서 중심의 학습 전략
- 블로그보다 공식 문서를 우선적으로 참조 (예: Hilt 공식 문서)
- 과거 템플릿 기반 설정은 오래된 실천을 반영할 수 있음
6. DI 프레임워크 사용 전략
- 핵심 의존성: 생성자 주입 사용
- 필요 시만
@Binds/@Provides사용 - 모든 화면에 @AndroidEntryPoint 사용은 피하고
ViewModel + Factory패턴 적용
7. DI 프레임워크 사용을 피해야 할 경우
- 작은 앱/프로토타입: 수동 DI로 중복 제거
- 분석/로깅 모듈: 정적 클래스로 충분
- 복잡한 로직: Factory 패턴으로 투명성 확보
결론
- DI 프레임워크(Hilt/Koin)는 원리 이해 후 사용해야 실무적 이점을 얻을 수 있음
- 수동 DI부터 시작하고, 공식 문서를 철저히 분석해야 함
- 과도한 DI는 오히려 유지보수성 저하를 유발하므로 전략적 사용이 필수적임