앱 MVP Android 앱 용량: 번들·측정·축소 범위를 나누는 5가지 기준

앱 MVP Android 앱 용량: 번들·측정·축소 범위를 나누는 5가지 기준

Android MVP를 출시할 때 APK 또는 AAB 파일 하나의 크기만 보고 “앱이 가볍다”거나 “기능을 빼야 한다”고 판단하기 쉽습니다. 하지만 빌드 산출물 크기, Google Play가 특정 기기에 제공하는 다운로드, 사용자가 실제로 첫 설치에서 받는 구성, 이후 내려받는 기능은 같은 값이 아닐 수 있습니다. 숫자 하나를 줄이는 일이 곧 사용자 경험이나 출시 준비 완료를 뜻하지도 않습니다.

이 글은 Android MVP에서 앱 용량을 다룰 때 배포 형식, 측정 대상, 줄일 후보, 기능 분리, 출시 후보 검증을 한 체크박스로 섞지 않는 기준입니다. 특정 앱의 설치율, 성능, Google Play 심사 결과를 보장하지 않습니다.

1. 먼저 질문하기: 지금 보는 것은 AAB인가, 기기별 다운로드인가

Android App Bundle(AAB)은 앱의 컴파일된 코드와 리소스를 담아 Google Play에 올리는 게시 형식입니다. Android 공식 문서는 Google Play가 이 번들에서 기기 구성에 맞춘 APK를 만들어 제공하므로, 사용자는 실행에 필요한 코드와 리소스만 내려받는다고 설명합니다. 따라서 로컬에서 본 AAB 크기와 한 사용자가 내려받는 크기를 같은 의미로 쓰면 의사결정이 흐려질 수 있습니다.

특히 MVP에서는 “큰 파일”이라는 관찰만으로 기능 제거를 결정하기보다, 어느 기기·언어·화면 밀도·CPU 구성을 기준으로 말하는지부터 남기는 편이 좋습니다. Play 외 배포, 사내 테스트, 특정 기기 검증은 또 다른 산출물과 전달 경로를 가질 수 있습니다.

Android App Bundle 공식 안내는 번들이 APK 생성과 서명을 Google Play에 맡기는 게시 형식이라고 설명합니다. 이 특성을 이용해 파일 크기를 숨기려는 것이 아니라, 비교 대상을 정확히 고르는 것이 첫 단계입니다.

2. 두 번째 기준: ‘줄이기’ 전에 구성부터 측정하기

용량이 커졌다는 사실만으로는 무엇을 바꿔야 하는지 알 수 없습니다. Android Studio의 APK Analyzer는 APK 또는 Android App Bundle 안의 파일 절대·상대 크기, DEX와 Android 리소스 구성, 최종 파일을 확인하고 두 산출물을 나란히 비교할 수 있게 합니다. 즉, 이전 후보보다 커졌다는 관찰과 어떤 코드·리소스가 달라졌는지를 분리할 수 있습니다.

출시 후보마다 아래처럼 “측정 대상”을 기록하세요. 도구 화면의 숫자를 복사하는 것보다, 비교한 두 파일과 바뀐 항목이 무엇인지 남기는 편이 다음 릴리스에서 더 재현하기 쉽습니다.

1. 비교할 이전 배포 후보와 이번 후보를 정합니다.

2. APK Analyzer에서 DEX, 리소스, 네이티브 라이브러리, 자산 중 큰 항목을 관찰합니다.

3. 각 증가 항목이 첫 출시 핵심 흐름에 필요한지, 특정 조건에서만 필요한지 적습니다.

4. 줄이기 전후에 핵심 화면·입력·결제 등 해당 앱의 주요 흐름을 다시 확인할 조건을 정합니다.

APK Analyzer 문서에 따르면 이 도구는 APK/AAB의 구성 확인과 두 산출물 비교에 쓸 수 있습니다. 다만 분석 화면에서 큰 항목을 찾았다고 해서 삭제가 안전한 것은 아닙니다. 리소스가 어떤 화면·언어·기기 설정에서 참조되는지, 제거 뒤 어떤 경로를 다시 시험할지를 제품 범위와 함께 봐야 합니다.

앱 번들의 배포 범위와 기기별 제공 자체를 먼저 정리하고 싶다면 Android 앱 번들 배포 기준도 참고하세요. 이 글은 번들을 올리는 절차보다, MVP가 용량 문제를 어떤 관찰과 선택으로 다룰지에 초점을 둡니다.

3. 세 번째 기준: 사용하지 않는 것과 ‘드물게 쓰는 것’을 구분하기

Android의 앱 크기 축소 가이드는 코드에서 참조하지 않는 `res/` 리소스를 lint가 찾아낼 수 있다고 설명합니다. 또한 `shrinkResources`는 코드 축소를 켠 상태에서 사용하지 않는 리소스를 제거하는 흐름에 쓰입니다. 그러나 같은 문서는 lint가 `assets/` 폴더, 리플렉션으로 참조되는 자산, 연결한 라이브러리 파일을 모두 검사하지는 않는다고 분명히 안내합니다.

그래서 “미사용 경고”와 “삭제 승인”은 다른 기록이어야 합니다. 반사 호출, 서버에서 내려오는 이름, 동적 테마, 특정 언어·밀도 리소스처럼 정적 검사만으로 확인하기 어려운 경로가 있는지 먼저 확인하세요. 삭제 후보를 바로 기능 제외 목록으로 바꾸지 말고, 실제 참조 조건과 재검증 범위를 적는 것이 안전합니다.

후보: 사용하지 않는 것으로 보이는 이미지 리소스
관찰: 빌드 검사에서 경고가 보임
확인할 조건: 동적 이름 참조·특정 화면·언어·화면 밀도 사용 여부
결정: 제거 전 검증 / 유지 / 다른 형식으로 교체
재검증: 해당 화면과 배포 후보에서 실제 렌더링 확인

Android 앱 크기 축소 가이드는 리소스 수와 크기, 코드·네이티브 바이너리, 기기 구성별 제공을 별도 관점으로 설명합니다. 이 글의 목록은 특정 설정을 그대로 적용하라는 처방이 아니라, 제거 전에 무엇을 확인할지 정하는 범위 문서입니다.

MVP 기능 우선순위와 배포 후보의 품질 기준을 함께 정리해야 한다면, 유인어스가 실제 핵심 흐름과 출시 제약을 바탕으로 검토 범위를 구조화할 수 있습니다. MVP 범위 상담하기.

4. 네 번째 기준: 모든 기능을 첫 다운로드에 넣을지 따로 결정하기

Android App Bundle은 기기 구성에 맞춘 최적화 APK 제공을 지원합니다. Android 공식 문서는 첫 설치에 필요하지 않은 기능을 기능 모듈로 분리해 나중에 전달하는 방안도 소개하지만, 이 선택에는 구조 변경이 필요할 수 있으므로 먼저 다른 축소 방법을 검토하라고 안내합니다. 즉, 기능 모듈은 단순한 파일 줄이기 버튼이 아니라 사용자 흐름과 배포 구조를 바꾸는 선택입니다.

다음 질문은 제품·개발·QA가 함께 답할 수 있습니다.

• 첫 설치 뒤 인터넷이 불안정해도 이 기능이 바로 필요한가?

• 핵심 전환 또는 고객지원 경로가 해당 기능을 전제로 하는가?

• 기능을 나중에 받는 경우, 사용자가 무엇을 보고 어떤 다음 행동을 하는가?

• 설치 시점과 후속 전달 시점 각각에서 오류·취소·재시도 상태를 확인할 수 있는가?

• 기능 분리로 줄어든 초기 전달 범위와 추가 구현·검증 비용을 비교했는가?

여기서 “드물게 쓰인다”는 팀의 가정일 수 있습니다. 실제 사용 빈도와 사용자 여정이 확인되지 않았다면 가정으로 표시하고, 출시 뒤 관찰할 지표와 다음 판단 시점을 정하세요. 기능을 뒤로 미뤘다는 결정이 첫 사용 완료나 사용자 만족을 보장하지는 않습니다.

5. 다섯 번째 기준: 크기 감소와 출시 품질을 별도로 닫기

리소스·코드·자산을 줄여 산출물이 작아졌더라도 출시 검토가 끝난 것은 아닙니다. Android 문서는 앱 크기가 로드 시간, 메모리, 전력 사용에 영향을 줄 수 있다고 설명하지만, 한 번의 용량 변화만으로 어떤 사용자 결과가 생길지 단정할 수는 없습니다. 용량 측정, 핵심 흐름 QA, Google Play 배포 상태, 실제 사용자 수신은 서로 다른 확인입니다.

출시 후보는 아래 네 종류의 증거를 분리해 닫아 보세요.

출시 전 체크리스트

• 비교한 파일과 기기·배포 조건을 기록했는가

• AAB 크기와 기기별 다운로드를 같은 숫자로 해석하지 않았는가

• 큰 항목마다 첫 출시에서 필요한 이유 또는 검증 조건을 적었는가

• lint 경고·축소 설정의 범위를 동적 참조와 별도로 검토했는가

• 기능 모듈 검토를 사용자 흐름과 오류 상태까지 포함해 결정했는가

• 용량 변화 뒤 핵심 흐름 QA와 실제 배포 상태를 따로 확인했는가

앱 용량을 줄이는 일은 ‘파일을 작게 만드는 작업’이면서 동시에 ‘어떤 사용자가 언제 어떤 기능을 받아야 하는지 정하는 제품 결정’입니다. 둘 중 하나만 확인해서 출시 완료라고 판단하지 마세요.

자주 묻는 질문

AAB 파일이 작으면 모든 사용자의 다운로드도 작은가요?

그렇게 단정할 수 없습니다. AAB은 Google Play가 기기 구성에 맞춘 APK를 생성·제공하는 게시 형식입니다. 따라서 로컬 AAB 크기, 특정 기기의 다운로드 구성, 첫 설치 뒤 추가 전달은 구분해 확인하는 편이 좋습니다.

APK Analyzer에서 큰 리소스를 찾으면 바로 지워도 되나요?

바로 삭제하면 안 됩니다. APK Analyzer는 구성과 비교를 돕는 도구입니다. Android 공식 문서는 lint가 모든 자산·리플렉션 참조·라이브러리 파일을 검사하지는 않는다고 안내합니다. 실제 참조 조건과 제거 뒤 재검증할 화면을 먼저 정하세요.

shrinkResources만 켜면 앱 크기 검토가 끝나나요?

아닙니다. Android 공식 문서는 리소스 축소가 코드 축소와 연결된 흐름임을 설명합니다. 설정 적용 여부와 별개로, 어떤 리소스가 실제 사용자 경로에 필요한지, 축소 뒤 핵심 기능이 유지되는지를 별도로 검증해야 합니다.

기능을 나중에 내려받게 하면 MVP가 더 좋아지나요?

항상 그렇지는 않습니다. 첫 설치에 필요하지 않은 기능을 분리하는 선택은 초기 전달 범위를 줄일 수 있지만 구조 변경과 사용자 흐름·오류 처리 검토를 수반할 수 있습니다. 사용자가 그 기능을 언제 필요로 하는지와 대체 경로를 먼저 확인하세요.

Android MVP에서 첫 설치 범위, 기능 분리, 배포 전 검수 기준을 함께 정리하고 싶다면 유인어스에 MVP 범위 문의하기.