✅ 일반 Repository vs Hilt Repository 차이점
: 의존성 관리 방식과 테스트 용이성, 코드의 모듈화/유지보수성 측면에서 차이가 크다.
항목 일반 Repository Hilt Repository
📌객체 생성 직접 생성 (val repo = MyRepo()) Hilt가 알아서 생성하고 주입
📌의존성 관리 수동으로 관리하거나 싱글톤 직접 구현 자동 주입 + 생명주기 관리
테스트 용이성 목 객체 교체 어려움 @Inject로 교체 가능 (Mock 주입)
코드 가독성
/유지보수 복잡한 의존성 많아질수록 어려움 DI로 깔끔한 구조 가능
Scope 관리 직접 싱글톤 구현 또는 관리 필요 @Singleton, @ViewModelScoped 등으로 간단하게 설정
✅ 객체를 직접 생성하지 않아도 된다는 것의 의미
"내가 객체를 생성하는 코드를 안 써도 된다"
👉 의존성 주입(DI)의 핵심이야.
📌 일반 방식 (수동 생성)
val repo = MyRepository()-
개발자가 직접 new하거나 val repo = ...로 명시적 생성해야 해.
-
생성 시점과 위치를 내가 직접 제어함.
✅ Hilt 사용 시 (자동 주입)
@Inject lateinit var repo: MyRepository또는
class MyViewModel @Inject constructor(
private val repo: MyRepository
) : ViewModel()-
객체 생성은 내가 하지 않아도 됨
-
Hilt가 필요한 시점에 자동으로 생성해서 주입해줌
-
의존성 그래프를 구성해서 알아서 생성 순서, 생명주기 등을 관리함
✅ 내부 메모리에서 객체 생성은 여전히 이루어짐?
✅ 맞아! 내부적으로는 당연히 객체는 생성돼.
차이점은 "누가 생성하느냐"와 "언제, 어떻게 관리되느냐"야.
구분 | 일반 방식 | Hilt
객체 생성 | 내가 직접 생성 | Hilt가 자동으로 생성
메모리에 존재? | O | O
생명주기 관리 | 직접 해야 함 | Hilt가 관리 (예: @Singleton, @ViewModelScoped 등)
테스트 편의성 | 불편 | 매우 유리 (Mock 주입 가능)
🔍 비유하자면?
직접 객체 생성 = 라면 직접 끓여먹기
Hilt 사용 = 자동판매기에서 누르면 알아서 나옴
내가 직접 끓이든, 자판기에서 꺼내든 → 라면은 어차피 존재한다
차이는 노력과 관리 부담의 차이야 😄
