앱 MVP Android Baseline Profile: 생성·포함·측정을 나누는 5가지 기준
Android MVP에서 화면이 처음 열릴 때 느리거나 이동·스크롤이 끊기는 문제를 만나면, Baseline Profile을 만들었다는 사실만으로 해결됐다고 기록하기 쉽습니다. 그러나 프로필 규칙을 만들기 위한 빌드, 실제 출시 빌드에 규칙을 포함하는 과정, 사용자가 설치한 결과, 성능 측정은 같은 단계가 아닙니다. 이 글은 Android MVP 팀이 이 네 상태와 다음 검증을 분리해 출시 범위를 정하는 방법을 설명합니다.
Android Developers는 Baseline Profile이 Android Runtime이 자주 쓰는 코드 경로를 사전 컴파일하도록 돕는 규칙 집합이라고 안내합니다(C001). 시작, 화면 이동, 스크롤 같은 공통 사용자 여정을 포함할 수 있으며, 프로필 생성용 빌드는 난독화·최적화를 끈 별도 변형이고 최종 출시 빌드는 난독화·최적화를 사용해야 한다고 구분합니다(C001). 따라서 ‘프로필 파일이 있다’와 ‘사용자 환경에서 개선이 확인됐다’는 서로 다른 문장입니다.
먼저 완료 상태를 네 줄로 나눕니다
Baseline Profile을 도입할 때는 아래 네 줄을 별도 체크하세요.
상태 | 확인할 질문 | 이 상태만으로 말할 수 없는 것 |
|---|---|---|
사용자 여정 선정 | 시작·이동·스크롤 등 어떤 흐름을 포함할지 정했는가 | 실제 앱의 성능 개선 |
규칙 생성 | 전용 테스트로 프로필 규칙을 생성했는가 | 출시 산출물 포함 여부 |
출시 산출물 확인 | release APK 또는 AAB에 해당 규칙이 포함됐는가 | 특정 기기에서의 체감 개선 |
측정 비교 | 같은 조건에서 프로필 사용·미사용 결과를 비교했는가 | 모든 사용자·기기의 같은 결과 |
이 표의 목적은 성능 수치를 만들어 내는 것이 아닙니다. 실패가 났을 때 원인을 ‘프로필이 안 됐다’로 뭉치지 않고, 어떤 단계의 증거가 빠졌는지 찾는 데 있습니다.
기준 1: 먼저 고객이 실제로 쓰는 여정을 고릅니다
프로필에는 모든 화면을 무작정 넣기보다, MVP의 핵심 흐름을 고르는 일이 먼저입니다. Android Developers는 앱 시작, 화면 간 이동, 콘텐츠 스크롤과 같은 공통 상호작용을 포함할 수 있다고 설명합니다(C001). 팀은 여기서 실제 제품의 첫 성공 행동을 한 문장으로 정의하면 좋습니다. 예를 들어 ‘앱을 열고 로그인 뒤 첫 목록을 확인한다’처럼 시작과 완료가 보이게 적습니다.
이 문장은 테스트 코드의 체크리스트이면서 제품 QA의 기준입니다. 개발자가 구현하기 편한 화면만 담으면, 프로필이 있더라도 사용자가 체감하는 느린 경로가 남을 수 있습니다. 반대로 아직 제공하지 않는 결제·추천·복잡한 편집 흐름을 미리 넣어 출시 준비가 끝난 것처럼 기록할 필요도 없습니다.
기준 2: 프로필 생성 빌드와 출시 빌드를 섞지 않습니다
공식 안내는 프로필을 캡처할 때는 규칙이 코드 서명과 정확히 맞도록 난독화·최적화를 사용하지 않는 별도 빌드 변형을 사용하고, 최종 release 빌드에서는 난독화·최적화를 사용하도록 구분합니다(C001). 이 차이를 모르고 하나의 APK만 점검하면, 규칙을 만든 성공과 출시 파일 적용 성공을 같은 결과로 오해할 수 있습니다.
작업 기록에는 ‘생성용 변형 이름’, ‘생성한 날짜와 커밋’, ‘실제 release 산출물 식별자’를 별도로 남기세요. 특정 버전 번호나 라이브러리 버전은 시간이 지나 바뀔 수 있으므로, 이 글의 예시를 고정 조건으로 복사하지 말고 Android 공식 문서와 현재 빌드 설정을 함께 확인해야 합니다.
MVP 출시 전 성능 근거와 QA 기록을 함께 점검하기
기준 3: 포함 확인과 성능 측정을 별도 QA로 둡니다
프로필 파일이 저장소에 있거나 생성 명령이 성공했다고 해서, 배포할 AAB·APK 안에 규칙이 들어갔다고 단정할 수는 없습니다. Android Developers는 생성된 규칙이 앱에 컴파일되어 패키지에 들어가고, 업로드 뒤 설치 시 Android Runtime이 해당 코드 경로를 컴파일하는 흐름을 설명합니다(C001). 팀의 확인도 소스 파일, release 산출물, 설치된 앱의 관찰을 분리해야 합니다.
성능을 측정할 때는 더 조심해야 합니다. Android Developers는 Macrobenchmark로 Baseline Profile을 켠 경우와 끈 경우를 비교할 것을 권하며, 에뮬레이터 측정은 호스트와 자원을 공유하므로 부정확할 수 있다고 안내합니다(C002). 즉, 측정 결과 하나를 모든 기기·모든 사용자의 성능 약속으로 바꾸지 말고, 기기·빌드·시나리오·측정 방식·반복 조건을 함께 남겨야 합니다.
기준 4: 첫 설치와 업데이트 뒤의 확인을 따로 둡니다
Baseline Profile은 새로운 설치와 앱 업데이트에서 중요한 코드 경로를 빠르게 준비하도록 돕지만, 배포 경로와 Android 버전에 따라 동작 조건이 다를 수 있습니다(C001). 예를 들어 Android Developers는 Google Play 밖의 배포 채널에서 설치 시 즉시 같은 이점을 보지 못하고 백그라운드 dexopt 뒤에야 반영될 수 있다고 설명합니다(C001). 이는 어떤 배포 경로가 나쁘다는 뜻이 아니라, QA 표에서 설치 경로를 숨기지 말아야 한다는 뜻입니다.
따라서 최소한 ‘새 설치’, ‘이전 버전에서 업데이트’, ‘내부 테스트 또는 실제 배포 경로’를 구분해 관찰하세요. 이 관찰은 프로필이 없을 때와 있을 때를 비교하는 실험 설계와도 연결됩니다. 결과가 다르면 코드 변경, 산출물 포함, 테스트 경로, 기기 상태 가운데 무엇이 달랐는지 되짚을 수 있습니다.
기준 5: 성능 수치보다 다음 결정 기준을 남깁니다
MVP에서는 모든 화면을 완벽하게 최적화하기보다, 어떤 사용자 여정의 지연을 먼저 다룰지 결정하는 일이 중요합니다. ‘빠르다’는 문구 대신 다음 표처럼 판단 기준을 남겨 보세요.
이번 릴리스의 핵심 사용자 여정은 무엇인가.
그 여정의 규칙을 어떤 생성용 빌드와 테스트로 만들었는가.
어떤 release 산출물에서 포함 여부를 확인했는가.
어떤 실기기·배포 경로·측정 조건에서 비교했는가.
다음 릴리스에서 유지·확대·재조사할 기준은 무엇인가.
이 기록은 성능 향상이나 앱스토어 평점, 유지율을 보장하지 않습니다. 대신 프로필 도입이라는 기술 작업을 제품의 핵심 흐름, 출시 산출물, 검증 증거와 연결합니다. R8 출시 산출물과 오류 해석의 경계를 점검해야 한다면 앱 MVP Android R8: 출시 빌드·매핑 파일·오류 해석을 나누는 기준도 참고할 수 있습니다.
자주 묻는 질문
Baseline Profile을 만들면 모든 성능 문제가 해결되나요?
아닙니다. Baseline Profile은 자주 쓰는 코드 경로의 사전 컴파일을 돕는 방법입니다. 어떤 사용자 여정을 포함했는지, 출시 산출물에 포함됐는지, 실제 조건에서 무엇을 비교했는지를 별도로 확인해야 합니다.
프로필 생성 성공 로그만 보면 되나요?
아닙니다. 생성용 빌드와 release 빌드는 목적이 다릅니다. 생성 규칙, release 산출물 포함, 설치·측정 관찰을 나눠 기록하세요.
에뮬레이터 측정 결과를 출시 성능으로 써도 되나요?
공식 문서는 에뮬레이터가 호스트와 자원을 공유해 부정확한 측정이 나올 수 있다고 안내합니다. 에뮬레이터 관찰은 환경과 한계를 표시하고, 중요한 판단은 적합한 실기기 조건에서 별도로 확인하세요.
이 글만으로 도입 여부를 확정할 수 있나요?
아닙니다. 이 글은 기록과 QA 범위를 정하는 도구입니다. 현재 Android Gradle Plugin, 배포 경로, 앱 구조와 Android 공식 문서를 함께 확인해 팀의 출시 기준을 정해야 합니다.
공식 출처
Android Developers: Baseline Profiles overview — 프로필의 역할, 생성·release 빌드 구분, 배포 경로 관련 안내 확인, 2026-09-21
Android Developers: Benchmark Baseline Profiles with Macrobenchmark library — 사용·미사용 비교와 에뮬레이터 측정 유의사항 확인, 2026-09-21
발행일: 2026-09-21 · 작성: 유인어스 앱 MVP 인사이트