앱 MVP Android App Startup: 초기화·의존성·지연·측정을 나누는 5가지 기준

앱 MVP Android App Startup: 초기화·의존성·지연·측정을 나누는 5가지 기준

앱을 열자마자 분석 도구, 원격 설정, 데이터베이스, 작업 스케줄러를 모두 준비해야 한다는 요구는 흔합니다. 그러나 “시작할 때 실행된다”는 한 문장만으로는 어떤 준비가 첫 화면보다 앞서야 하는지, 서로 어떤 순서로 의존하는지, 실패했을 때 사용자가 무엇을 보게 되는지 판단할 수 없습니다.

Android의 App Startup은 시작 시 컴포넌트 초기화 순서를 명시할 수 있게 돕는 Jetpack 라이브러리입니다. 이 글은 Android MVP에서 초기화 항목을 무작정 늘리는 대신, 필수 초기화·의존성·지연 초기화·화면 준비·측정 결과를 분리해 결정하는 방법을 정리합니다. 특정 앱의 속도 개선이나 Play 품질 결과를 보장하지 않습니다.

1. 먼저 나눌 것: ‘앱이 실행됨’과 ‘사용자가 첫 화면을 봄’

앱 시작은 하나의 순간이 아닙니다. Android 공식 문서는 시작 상태를 콜드·웜·핫 시작으로 구분하며, 콜드 시작에서는 앱 프로세스와 Activity, UI가 새로 준비되고 첫 화면이 그려진 뒤 사용자가 앱을 사용할 수 있다고 설명합니다. 따라서 Application 단계에서 어떤 객체를 만들었다고 해서 사용자가 기능을 쓸 수 있게 된 것은 아닙니다.

측정도 두 개의 질문으로 분리하는 편이 안전합니다. TTID(time to initial display)는 첫 UI 프레임이 보이기까지의 시간이고, TTFD(time to full display)는 앱이 완전히 상호작용 가능해지기까지의 시간입니다. 첫 화면이 빨리 보이더라도 핵심 데이터나 버튼이 아직 준비되지 않았다면, MVP의 사용자 완료와 같은 신호로 취급하면 안 됩니다.

Android의 앱 시작 시간 문서는 시작 최적화에서 콜드 시작을 가정하라고 안내합니다. 다만 이 권고는 모든 항목을 첫 화면 전에 강제로 실행하라는 뜻이 아닙니다. MVP 팀은 첫 행동에 꼭 필요한 준비와, 화면이 보인 뒤에도 안전하게 진행할 수 있는 준비를 따로 적어야 합니다.

시작 경로를 실제 출시 빌드에서 비교하는 방법은 Android Baseline Profile 생성·포함·측정 기준도 함께 참고할 수 있습니다. 이 글은 프로필 생성 자체가 아니라, 어떤 초기화가 시작 경로에 남아야 하는지와 사용자 준비 상태를 어떻게 나눌지에 초점을 둡니다.

2. 두 번째 기준: 초기화 항목마다 ‘없으면 무엇이 멈추는가’를 한 줄로 쓰기

App Startup은 여러 컴포넌트의 시작 순서를 정리하는 도구이지, 모든 SDK를 자동 실행해야 한다는 규칙이 아닙니다. 항목별로 “이 항목이 아직 없을 때 첫 화면 또는 첫 행동이 실제로 막히는가?”를 먼저 답하세요. 예를 들어 로그인 상태를 읽지 않으면 첫 목적지를 정할 수 없는지, 오류 보고 도구는 첫 화면 이후에도 시작할 수 있는지, 작업 스케줄러 설정은 사용자의 즉시 행동과 어떤 관계인지 구분합니다.

아래 표는 제품 요구를 초기화 요구로 번역하는 예시입니다. 실제 항목과 오류 처리 방식은 각 앱의 기능과 구현에 맞춰 검증해야 합니다.

이렇게 쓰면 “초기화 실패”를 하나의 장애로 뭉뚱그리지 않게 됩니다. 반드시 준비되어야 하는 항목은 사용자에게 보이는 대기·오류·재시도 흐름을 함께 정의하고, 그렇지 않은 항목은 지연 가능한지와 실패가 사용자 행동을 막는지 따로 기록하세요.

3. 세 번째 기준: 의존성은 실행 순서가 아니라 제품 이유와 함께 선언하기

App Startup의 `Initializer`는 `create()`에서 컴포넌트를 초기화하고 `dependencies()`에서 선행 Initializer를 선언합니다. Android 공식 문서는 이 의존성 목록으로 시작 시 실행 순서를 제어할 수 있다고 설명합니다. 즉, A가 B의 결과 없이는 동작하지 않을 때만 A가 B에 의존한다고 적는 것이 자연스럽습니다.

의존성 선언을 ‘안전해 보이는 순서’로 계속 추가하면 시작 경로가 길어질 수 있습니다. MVP 기획과 코드 리뷰에서 다음 세 칸을 맞춰 보세요.

초기화 항목: 주문 초안 복원
필요 이유: 첫 화면의 이어쓰기 경로를 정해야 함
선행 항목: 로컬 계정 식별 상태
준비 실패 시: 빈 초안 화면 + 다시 시도
지연 가능 여부: 첫 진입 경로가 아니라면 가능

`dependencies()`에 들어간 항목은 단순한 기술 목록이 아니라, “이전 결과가 없으면 왜 다음 기능이 성립하지 않는가”라는 제품 가정입니다. 구현과 QA에서는 그 가정이 맞는지 확인하고, 가정이 깨졌을 때 사용자가 보는 화면과 로그를 별도 결과로 남기세요.

4. 네 번째 기준: 자동 초기화와 지연 초기화를 서로 다른 출시 결정으로 보기

App Startup은 매니페스트의 `InitializationProvider` 아래 메타데이터로 Initializer를 발견해 자동 실행할 수 있습니다. 한편 Android 공식 문서는 자동 초기화가 필요하지 않은 컴포넌트는 메타데이터를 제거한 뒤 `AppInitializer`로 수동 초기화하는 지연 초기화도 가능하다고 안내합니다. 자동 실행을 끄면 해당 컴포넌트의 의존성도 자동 초기화되지 않는다는 점은 특히 점검해야 합니다.

따라서 “첫 화면이 느리니 전부 지연하자”도, “초기화 라이브러리를 넣었으니 전부 자동 실행하자”도 결론이 아닙니다. 아래 네 가지를 각 항목에 적용하세요.

• 첫 화면의 경로 또는 안전성에 실제로 필요한가?

• 다른 Initializer의 결과가 반드시 선행돼야 하는가?

• 수동 실행 시점이 사용자 행동 뒤로 밀려도 되는가?

• 자동 실행을 끄면 함께 멈추는 의존성은 무엇인가?

Android App Startup 가이드에는 자동 발견, 의존성, 개별 또는 전체 자동 초기화 해제, 수동 초기화의 흐름이 정리돼 있습니다. 매니페스트 병합 결과와 실제 앱의 첫 진입 경로를 함께 검토해야, 라이브러리 의존성만 보고 실행 상태를 추정하지 않게 됩니다.

초기화 범위와 사용자가 보게 될 오류·복구 흐름을 MVP 설계로 정리해야 한다면, 유인어스는 기능 우선순위와 출시 제약을 기준으로 검토 범위를 함께 구조화할 수 있습니다. MVP 범위 상담하기.

5. 다섯 번째 기준: 코드 완료 대신 ‘시작 시나리오별 관찰’로 닫기

초기화 코드를 추가하고 빌드가 통과해도, 시작 품질 검토가 끝난 것은 아닙니다. Android 문서는 콜드·웜·핫 시작의 작업량이 다르다고 설명합니다. 한 번의 개발 기기 실행만으로 모든 시작 상태의 사용자 경험을 대표한다고 보기 어렵습니다.

출시 후보에서는 시나리오별로 관찰을 남기세요. 예를 들면 콜드 시작에서 첫 화면 표시와 핵심 행동 가능 시점, 웜 시작에서 복원된 상태, 네트워크 또는 초기화 실패 때의 대체 화면, 지연 항목이 준비되지 않은 동안의 사용자 행동을 분리합니다. Android는 TTFD 관련 정보를 위해 `reportFullyDrawn` 구현을 권장하지만, 이 호출 하나가 제품 준비를 보장하지는 않습니다. 팀이 정의한 ‘핵심 행동 가능’ 조건과 함께 봐야 합니다.

출시 전 체크리스트

• 초기화 후보마다 첫 화면 또는 첫 행동을 막는 이유를 썼는가

• TTID와 TTFD, 그리고 팀의 핵심 행동 가능 조건을 구분했는가

• `dependencies()`의 각 연결에 제품 이유를 남겼는가

• 자동 초기화 해제 시 함께 영향을 받는 의존성을 확인했는가

• 콜드·웜·핫 시작을 동일한 성공 신호로 섞지 않았는가

• 오류·재시도·지연 상태에서 사용자가 보는 다음 화면을 정했는가

App Startup은 초기화 순서를 정리하는 도구입니다. 어떤 준비가 사용자에게 꼭 필요한지, 어느 시점에 완료로 볼지는 제품이 별도로 결정해야 합니다.

자주 묻는 질문

App Startup을 쓰면 모든 SDK를 자동 초기화해야 하나요?

아닙니다. App Startup은 시작 시 컴포넌트 초기화와 의존 순서를 명시하는 방법입니다. 각 항목이 첫 화면 또는 첫 행동에 실제로 필요한지 먼저 판단하고, 지연 가능한 항목은 수동 초기화 가능성과 실패 시 사용자 영향을 별도로 검토하세요.

`dependencies()`에 넣은 Initializer는 어떤 의미인가요?

다음 Initializer가 동작하려면 선행 Initializer가 먼저 준비돼야 한다는 의존성입니다. 단지 실행 순서를 고정하려는 목적이 아니라, 선행 결과가 왜 필요한지와 실패 시의 제품 처리를 함께 기록하는 것이 좋습니다.

첫 화면이 빨리 보이면 시작 최적화가 끝난 건가요?

아닙니다. TTID는 첫 프레임이 표시되기까지의 시간이고, TTFD는 앱이 완전히 상호작용 가능해지기까지의 시간입니다. 화면 표시와 핵심 기능 준비, 백그라운드 항목 완료를 별도 신호로 확인해야 합니다.

이 글만으로 성능 점수나 Play 심사 결과를 알 수 있나요?

알 수 없습니다. 이 글은 MVP의 초기화 범위와 관찰 항목을 정리하는 기준입니다. 실제 성능·배포 품질은 앱 구현, 기기, 네트워크, Play Console의 최신 기준을 포함해 별도로 측정·검토해야 합니다.

Android MVP에서 ‘시작할 때 할 일’과 ‘사용자가 바로 할 수 있어야 할 일’을 구분하기 어렵다면, 현재 흐름을 기준으로 출시 범위를 정리해 보세요. 유인어스에 MVP 범위 문의하기.