200MB 모듈을 팀 단위로 해결하기: 당근 숏폼팀의 On-demand Dynamic Feature Module 도입
Summary
"200MB 모듈이 0MB로?" 당근 숏폼팀의 기막힌 다이어트 비결, On-demand DFM
전 세계 2,000만 사용자에게 민폐 끼치지 않고 화려한 편집 기능을 넣는 법
당근 숏폼팀이 대규모 멀티 모듈 환경에서 비디오 편집 기능의 고용량 문제를 어떻게 해결했는지 상세히 다룹니다. 단순히 기술을 적용하는 것을 넘어, Hilt 의존성 주입 이슈부터 네이티브 라이브러리(STL) 충돌까지 실무에서 마주친 험난한 고비들을 돌파한 생생한 엔지니어링 기록입니다.
- 01초기 200MB에서 40MB로, 다시 DFM으로 90% 추가 절감한 용량 최적화 여정
- 02Hilt 어노테이션 프로세서의 한계를 EntryPoint 패턴으로 극복한 사례
- 03SplitCompat을 이용한 동적 모듈 클래스 로더 패치 전략 공유
- 04네이티브 라이브러리 로딩 시 발생하는 UnsatisfiedLinkError 해결 노하우
- 05'완벽한 분리'보다 '안정적인 운영'을 택한 실용적인 아키텍처 의사결정
RECOMMENDATION
앱의 특정 기능이 전체 용량의 큰 비중을 차지하거나, 특정 국가/그룹에게만 선별적으로 기능을 제공해야 하는 안드로이드 엔지니어에게 이 글은 완벽한 가이드가 될 것입니다.
The Problem
당근 숏폼 서비스인 '당근 스토리'에 비디오 편집 기능을 추가하면서 모듈 용량이 200MB까지 비대해졌으며, 리소스를 CDN으로 전환한 후에도 40MB의 용량이 남아 글로벌 사용자에게 큰 부담이 되었습니다. 영상 편집은 일부 사용자만 사용하는 기능임에도 모든 사용자가 이를 설치해야 하는 비효율성을 해결해야 했습니다.
The Solution
Android의 On-demand Dynamic Feature Module(DFM)을 도입하여 사용자가 편집 기능을 요청할 때만 모듈을 다운로드하도록 설계했으며, 기술적 복잡도를 낮추기 위해 기능 코드는 base 모듈에 유지하고 대용량의 SO 파일(네이티브 라이브러리)만 DFM으로 분리하는 전략을 취했습니다.
The Result
결과적으로 편집 기능 관련 용량을 90% 이상 절감하여 글로벌 서비스에 미치는 영향을 최소화했으며, 기능을 코드와 분리함으로써 DFM 로딩 실패 시에도 앱의 안정성을 확보하고 개발 편의성을 높였습니다.
Trade-off
코드는 base에 있고 라이브러리 파일은 DFM에 존재하는 비대칭 구조로 인해 구조가 생소해질 수 있으며, 런타임에 모듈 설치 여부 확인 및 SO 파일 로딩 흐름을 개발자가 직접 명시적으로 관리해야 하는 운영상의 복잡도가 존재합니다.
Key Concepts
More from 당근
View all posts from 당근
혼자 시작해 전국 오픈까지, 당근 레슨/과외 빌딩 로그
MarketplaceProduct Market FitFunnel Optimization2주 전
디자인시스템 팀은 디자인시스템만 잘 만들면 될까
Design SystemAI in DesignUX Patterns1개월 전당근 200+개 DB 를 옮기는 ELT 플랫폼, DT Platform 을 만든 이야기
ELTApache SparkApache Airflow1개월 전
누구나 찾아볼 수 있는 중고거래 서버 LLM 릴리즈 노트 도입기
LLMGitHub ActionsNotion2개월 전How We Protect Karrot’s Internal PyPI Proxy from Supply Chain Attacks
PyPIAWS CodeArtifactSecurity Cooldown2개월 전
