라이브러리 의존성을 줄이는 방향으로 개발해보기
Android 개발을 하다 보면, 우리는 수많은 외부 라이브러리를 프로젝트에 도입합니다.
Retrofit, Glide, Dagger, Timber, RxJava, Firebase, Coil, OkHttp 등은 아마 대부분의 개발자에게 익숙할 것입니다.
이들은 생산성을 높이고 반복되는 코드를 줄여주지만, 동시에 복잡도와 의존성 문제라는 그림자를 남깁니다.
이번 글에서는 왜 라이브러리 의존성을 줄이는 것이 중요한지, 실제로 어떻게 줄여볼 수 있을지, 어디까지 줄이는 것이 합리적인지를 Android 개발자의 관점에서 살펴보려 합니다.
🔍 왜 의존성을 줄이려는가?
외부 라이브러리는 강력한 도구지만, 다음과 같은 단점도 함께 가져옵니다:
- 버전 충돌
의존성 간 버전이 충돌하면 빌드 오류나 런타임 에러가 발생합니다. 특히 Gradle에서 트랜지티브 의존성(간접 참조)의 충돌은 해결이 쉽지 않습니다. - 보안 리스크
외부 코드에 취약점이 존재할 수 있으며, 우리 앱이 직접 그 영향을 받을 수 있습니다. 특히 유지되지 않는 라이브러리는 큰 위험입니다. - APK 크기 증가
종종 작은 기능을 위해 대형 라이브러리를 도입하는 경우가 있습니다. 이는 사용자 입장에서 앱 설치 용량을 키우는 요인이 됩니다. - 빌드 속도 저하
많은 라이브러리는 Annotation Processor를 사용하는데, 이로 인해 빌드 시간이 크게 늘어날 수 있습니다. - 기술 부채화
특정 라이브러리에 너무 의존한 구조는 향후 교체가 어려운 "기술 부채"가 되기 쉽습니다.
🛠 줄일 수 있는 곳부터 줄여보자
실제로 Android 앱 개발에서 라이브러리를 대체할 수 있는 부분은 꽤 많습니다.
1. Retrofit 대신 HttpURLConnection / Ktor Client / Fuel
Retrofit은 매우 편리하지만, 간단한 네트워크 호출에는 과합니다.
작은 앱이나 단일 API 요청이라면 Kotlin의 HttpURLConnection이나 Ktor client, Fuel 같은 경량 라이브러리로 대체 가능하고, 때로는 아예 직접 wrapper를 만들어 사용하는 것도 가능합니다.
예: Retrofit 없이 네트워크 요청
val url = URL("https://example.com/data")
val connection = url.openConnection() as HttpURLConnection
connection.requestMethod = "GET"
val result = connection.inputStream.bufferedReader().readText()
2. Glide / Coil 없이 Bitmap 처리
이미지 라이브러리는 편리하지만, 내부적으로 많은 메모리를 소비합니다.
간단한 앱에서는 ImageView.setImageBitmap()이나 BitmapFactory.decodeStream()으로 충분한 경우도 많습니다.
3. Timber 없이 Log로 일관성 있게
Timber는 유용하지만, 로그 관리를 위해 굳이 별도 의존성을 추가하지 않아도 됩니다.
Kotlin의 object Logger를 만들어 Log.d(), Log.e()를 래핑하면 비슷한 결과를 얻을 수 있습니다.
object Logger {
fun d(tag: String, msg: String) {
if (BuildConfig.DEBUG) Log.d(tag, msg)
}
}
4. DI 프레임워크 없이 수동 주입
Dagger나 Hilt는 대형 프로젝트에서 유용하지만, 작은 앱에서는 오히려 구조가 복잡해질 수 있습니다.
단순한 서비스 객체라면 수동 생성 및 주입으로도 충분히 관리 가능합니다.
class Repository(private val api: MyApi)
val api = MyApi()
val repository = Repository(api) // 수동 DI
🧭 현실적인 접근법: "줄일 수 있는 것부터 줄이자"
모든 라이브러리를 제거하자는 이야기는 아닙니다.
오히려 필요한 것만 가져오고, 나머지는 스스로 구현하거나 최소한으로 대체하자는 뜻에 가깝습니다.
아래와 같은 전략이 효과적입니다:
- 도입 전 질문하기: “직접 구현이 가능할까?”, “기본 SDK로 충분한가?”
- 유지 관리 상태 확인: GitHub Star 수보다 최근 커밋 날짜를 보자.
- 경량 대안 탐색: 대형 라이브러리 대신 모듈화된 경량 버전 고려
- 팀 코드 스타일과 통일성 고려
✅ 외부에 기대지 않아야, 내 코드의 생존력이 높아진다
라이브러리는 도구이지 필수 요소는 아닙니다.
개발자가 그 도구 없이도 기본적인 구조와 기능을 구현할 수 있어야 유지보수성과 확장성이 확보됩니다.
오히려 라이브러리를 "제거해보면서 더 많이 배우게 되는 경우도 많다"는 것을 경험해 본 개발자들도 많을 것입니다.
“기능 구현은 라이브러리 없이도 가능해야 한다.”
이 말은 궁극적으로 개발자가 더 높은 수준의 자율성과 판단력을 갖추는 데 도움이 됩니다.
더 간결하고 가벼운 Android 앱을 만들고 싶으신가요?
그렇다면 지금 사용하는 라이브러리 목록을 한 번 정리해보세요.
당신의 앱은 생각보다 더 가볍고, 더 빠르게 작동할 수 있습니다.