MediatorLiveData 제대로 쓰는 7가지 실전 팁

안드로이드 MVVM에서 MediatorLiveData 는 “여러 스트림을 하나로 묶는 허브”입니다. 소스 LiveData 들을 자유롭게 합치고, UI-State를 한곳에서 관리할 수 있죠. 그러나 잘못 쓰면 메모리 누수나 스파게티 ViewModel 로직을 만들기도 합니다. 여기, 실제 서비스 코드와 조회수 높은 한국 개발 블로그들을 참고해 뽑은 핵심 활용 팁 7가지를 정리했습니다.

---

1. addSource / removeSource는 ViewModel 안에만 두자
   MediatorLiveData 는 내부적으로 addSource() 로 등록된 스트림을 관찰하고 removeSource() 로 해제합니다. 이 로직은 ViewModel 레이어에서 끝내야 UI 컨트롤러(액티비티·프래그먼트)가 가벼워집니다.
2. 버튼 활성화·폼 검증 등에 ‘다중 LiveData 합성’ 활용
   예를 들어 이메일·비밀번호 LiveData 둘을 합쳐 회원가입 버튼의 enable 상태를 계산할 수 있습니다. 땅으니 블로그 예시처럼 네다섯 개의 스트림도 거뜬히 한 줄에 합칠 수 있어요.
3. 확장 함수로 보일러플레이트 줄이기
   “소스 추가 → 값 포워딩” 코드를 매번 쓰기 귀찮다면, 확장 함수로 래핑해 두세요. Medium 글의 샘플처럼 MediatorLiveData<T>.combine(...) 식으로 만들면 훨씬 읽기 좋습니다.
4. Kotlin Flow + asLiveData() 조합을 고려
   네트워크·Room 등 코루틴 기반 스트림이라면 먼저 Flow 로 결합하고, 최종 단계에서 asLiveData() 로 변환하면 로직 분리가 더 깔끔합니다.
5. distinctUntilChanged()로 불필요한 UI 리렌더 막기
   여러 소스를 합치다 보면 값이 동일해도 매번 옵저버가 호출되는 경우가 많습니다. switchMap · map 뒤에 distinctUntilChanged() 를 붙이면 불필요한 UI 업데이트를 방지할 수 있어요.
6. onActive() / onInactive() 훅으로 리소스 관리
   MediatorLiveData 자체가 활성화될 때만 내부 소스를 붙이고, 비활성화되면 떼도록 구현해 두면(예: API 폴링 중지) 배터리와 데이터 사용량을 아낄 수 있습니다.
7. 소스 제거를 잊지 말자—메모리 누수 방지
   일회성 결제 · 로그인 Flow 등 일시적인 로직이라면 작업이 끝난 즉시 removeSource() 나 value = null 처리로 참조를 끊어 주세요. 안 그러면 ViewModel이 살아 있는 한 콜백이 계속 쌓여서 메모리와 CPU를 잡아먹습니다.

---

마무리

MediatorLiveData 는 “작은 중재자(Mediator)” 같은 존재입니다. 스트림 수가 늘어도 UI 코드는 단순해지고, 테스트 대상도 ViewModel 한곳으로 모일 수 있죠. 위 7가지만 지키면 과도한 콜백 지옥이나 누수 걱정 없이 클린한 데이터 파이프라인을 구축할 수 있습니다.