앱 MVP Android R8: 출시 빌드·매핑 파일·오류 해석을 나누는 5가지 기준
Android 앱 MVP를 출시할 때 R8 설정은 용량을 줄이는 체크박스 하나로 끝나지 않습니다. 실제 출시 빌드에 어떤 최적화를 적용했는지, 그 빌드에서 나온 매핑 파일을 어디에 보관했는지, Play Console에서 읽는 오류가 어느 버전의 기록인지, 재현한 문제와 연결되는지까지는 서로 다른 일입니다. 이 글은 R8을 켜는 일과 출시 뒤 오류를 해석할 준비를 한 덩어리로 취급하지 않기 위한 기준을 정리합니다.
Android Developers는 R8이 사용되지 않는 코드·리소스를 제거하고 코드를 다시 작성하며, 클래스·필드·메서드 이름을 짧게 바꿀 수 있다고 설명합니다(C001, C002). Google Play Console Help는 난독화된 Java 스택 트레이스를 읽으려면 앱의 각 버전에 맞는 ReTrace 호환 매핑 파일이 필요하다고 안내합니다(C003, C004). 이 글은 특정 앱의 성능, 오류율, 스토어 심사 또는 안정성을 판단하지 않습니다.
먼저 분리할 것: R8 적용과 오류 해결은 같은 완료 신호가 아닙니다
R8은 앱에서 도달할 수 없는 코드와 라이브러리 의존성을 제거하고, 실행 효율을 위해 코드를 바꾸며, 이름을 축약할 수 있습니다(C001, C002). 따라서 출시 빌드가 생성됐다는 사실은 그 빌드의 실제 사용자 오류를 이해할 수 있다는 뜻이 아닙니다. 반대로 오류 화면에 스택 트레이스가 보인다고 해서 지금 보고 있는 호출명이 소스 코드의 원래 이름과 대응한다는 뜻도 아닙니다.
기획·개발 기록에는 최소한 `출시 후보 빌드`, `해당 빌드의 R8/규칙 상태`, `같은 버전의 매핑 파일`, `수집된 오류`, `재현·수정 확인`을 따로 적어 두세요. 이 다섯 항목 중 하나가 비어 있으면 다음 사람이 오류를 볼 때 추측이 늘어납니다. 특히 외주 인수인계나 담당자 교체가 있다면 파일 이름만 남기지 말고 어떤 versionCode·배포 산출물과 짝인지 확인할 수 있어야 합니다.
기준 1: 최적화는 개발용 화면이 아니라 실제 출시 후보에서 따로 확인합니다
Android Developers는 앱 최적화를 출시 빌드에 적용하고, 보통은 배포 전에 시험하는 최종 버전에 적용하라고 권장합니다(C005). 최적화는 빌드 시간을 늘리고 디버깅을 어렵게 만들 수 있기 때문에, 개발 중의 빠른 확인용 빌드와 출시 후보를 같은 조건으로 단정하지 않는 편이 좋습니다.
여기서 확인할 질문은 “R8을 썼는가”보다 구체적입니다. 이번 후보가 어떤 Gradle 설정과 규칙으로 만들어졌는지, 리플렉션·직렬화처럼 런타임에 찾아야 하는 코드에 필요한 keep rule을 검토했는지, 최적화된 후보에서 핵심 가입·결제·파일 선택 같은 흐름을 실제로 관찰했는지를 나누어 기록하세요. 규칙을 넓게 추가했다고 해서 특정 오류가 해결됐다고 말할 수는 없고, 문제와 동일한 조건에서 재확인하기 전에는 수정 완료로 적지 않는 편이 안전합니다.
우리 앱 MVP의 출시 후보·오류 기록·인수인계 흐름 점검하기
기준 2: 난독화와 매핑 파일은 한 버전의 짝으로 보관합니다
R8이 이름을 축약하면 스택 트레이스에서 원래 클래스와 메서드를 바로 읽기 어려울 수 있습니다(C002). Google Play Console은 Java 앱에서 ProGuard 또는 R8 형식의 ReTrace 호환 매핑 파일을 버전별로 사용해 충돌과 ANR을 해석한다고 설명합니다(C003, C004). 즉 `mapping.txt`라는 파일이 있다는 사실보다, 그것이 어느 출시 버전에서 생성됐는지가 핵심입니다.
팀의 보관 규칙에는 앱 식별자, versionCode 또는 버전명, 빌드 산출물 식별값, 생성 시점, 책임자, 저장 위치와 접근 권한을 함께 남겨 두는 것이 좋습니다. 파일을 외부에 공유할 때는 코드 구조 정보가 포함될 수 있다는 점을 고려해 공개 링크나 개인 메신저 전달을 기본값으로 두지 마세요. 이 글은 특정 보관 장소나 보안 수준을 지시하지 않으며, 조직의 접근 통제 기준은 별도로 확인해야 합니다.
기준 3: App Bundle과 APK, Java/Kotlin과 네이티브 파일을 섞지 않습니다
Google Play Console의 안내는 Java 계열 앱의 난독화 해석에 매핑 파일을, 네이티브 코드가 있는 앱의 심볼 해석에는 디버그 심볼 파일을 구분합니다(C003). Android App Bundle과 일정 버전 이상의 Android Gradle Plugin 조합에서는 Play가 번들에서 해독 파일을 자동으로 가져갈 수 있지만, APK 배포나 다른 빌드 경로에서는 별도 업로드 단계가 필요할 수 있습니다(C006).
그래서 릴리스 체크리스트에는 “매핑 파일 업로드됨” 한 줄보다 산출물 경로를 먼저 적는 편이 낫습니다. 예를 들어 이번 배포가 AAB인지 APK인지, Java/Kotlin 코드만 있는지 네이티브 라이브러리가 있는지, Play가 자동 수집한 항목인지 사람이 올린 항목인지, 각 항목을 읽어 본 콘솔 화면이 무엇인지 분리합니다. 다른 배포 채널에서 같은 빌드를 배포한다면 Play Console에 보이는 상태가 그 채널의 오류 해석까지 대신해 주는 것은 아닙니다.
기준 4: 파일을 올린 뒤에도 이전 오류가 풀렸다고 단정하지 않습니다
Google Play Console은 버전에 맞는 파일을 업로드한 뒤 발생한 충돌과 ANR부터 해독된다고 안내합니다(C007). 이미 과거에 수집된 오류나 다른 버전의 오류가 같은 방식으로 바뀐다고 추정하면 안 됩니다. 그래서 운영 회의에서 “매핑 파일 업로드 완료”와 “새로 들어온 오류를 읽을 수 있음”을 별도 상태로 두는 편이 좋습니다.
오류 하나를 검토할 때는 먼저 Play Console에서 버전·발생 시점·스택 트레이스 상태를 확인하고, 그 다음 해당 버전의 산출물·매핑 파일·재현 환경을 대조하세요. 오류 군집의 수가 줄거나 심각도가 바뀌었다는 관측도 원인을 곧바로 뜻하지는 않습니다. Google Play는 해독 파일이 있으면 여러 환경에서 동일한 오류를 묶어 볼 수 있어 표시 방식이 달라질 수 있다고 설명합니다(C008).
기준 5: 수정 확인은 매핑 파일 보관과 별도의 QA로 닫습니다
매핑 파일은 오류 이름을 해석하는 자료이지 수정 그 자체가 아닙니다. 수정 후보가 나오면 문제를 재현한 앱 버전과 기기·입력·네트워크 상태, 수정 뒤 다시 확인한 후보, 확인 결과를 한 기록으로 연결하세요. 재현할 수 없는 오류라면 “미재현”을 “수정됨”으로 바꾸지 말고, 관찰된 조건과 다음 확인 시점을 남겨 두는 편이 낫습니다.
실무에서는 다음 순서를 하나의 릴리스 기록으로 사용해 볼 수 있습니다.
출시 후보의 산출물 유형과 R8·keep rule 변경 여부를 기록합니다.
해당 버전의 매핑 파일 또는 네이티브 심볼 파일 경로와 접근 권한을 확인합니다.
Play Console에서 같은 버전의 파일 수집·업로드 상태를 읽어 봅니다.
새로 수집된 오류의 버전·시점·해독 상태를 산출물 기록과 대조합니다.
재현과 수정 QA 결과를 별도로 남기고, 관찰하지 않은 성능 변화는 결과로 쓰지 않습니다.
관련 글 앱 MVP 오류 보고: 재현 가능한 판단 기록으로 만드는 6가지은 오류를 재현 조건과 의사결정 기록으로 정리하는 방법을 다룹니다. 이번 글은 그보다 좁게 Android 출시 빌드에서 R8 설정, 버전별 매핑 자료, Play Console 해독 상태를 연결하는 준비에 초점을 둡니다.
출시 전 Android 빌드·매핑 파일·오류 대응 기록을 함께 정리하기
자주 묻는 질문
R8을 켜면 모든 오류를 바로 찾을 수 있나요?
아닙니다. R8은 최적화와 난독화를 수행할 수 있고, 난독화된 스택 트레이스를 읽으려면 같은 앱 버전에 맞는 매핑 자료와 실제 오류 기록이 필요합니다. 파일 보관, 콘솔 읽기, 재현과 수정 확인은 별도 단계로 관리하세요.
매핑 파일 하나를 계속 재사용해도 되나요?
버전별로 구분하는 편이 좋습니다. Google Play Console Help는 새 앱 버전마다 해독 또는 심볼 해석에 필요한 파일을 생성·업로드해야 한다고 안내합니다. 파일 이름만으로 판단하지 말고 출시 산출물과 연결되는 식별값을 함께 기록하세요.
Play Console에 파일을 올리면 이전 충돌도 해독되나요?
그렇게 단정할 수 없습니다. Google Play Console은 파일을 올린 뒤 발생한 해당 버전의 충돌·ANR부터 해독된다고 안내합니다. 이전에 수집된 오류와 이후 오류를 같은 상태로 묶지 마세요.
네이티브 코드가 있으면 mapping.txt만 확인하면 되나요?
아닙니다. Google Play Console의 안내는 Java 계열 난독화 해석용 매핑 파일과 네이티브 코드용 디버그 심볼 파일을 구분합니다. 앱의 실제 코드 구성과 빌드 산출물에 맞는 자료를 확인해야 합니다.
공식 출처
Android Developers: Enable app optimization with R8 — 2026-09-21 확인 Google Play Console Help: Deobfuscate or symbolicate crash stack traces — 2026-09-21 확인
발행일: 2026-09-21 · 작성: 유인어스 정책자금·정부지원사업 인사이트