인증·원격 설정·업데이트·오류 복구를 상태로 나눠 앱 시작 흐름을 예측 가능하게 만드는 방법을 정리합니다. 설정부터 시작하기 전에 ‘필수 초기화’을 분리해서 봐야 합니다. 로컬 설정 읽기처럼 다음 단계에 반드시 필요한 작업과 분석 SDK처럼 늦춰도 되는 작업을 분리해야 첫 화면이 불필요하게 지연되지 않습니다.
이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.
 |
| Splash 화면을 앱 시작 상태 머신으로 설계하는 방법 핵심 판단 흐름 설명용 개념도 |
그림 1. Splash 화면을 앱 시작 상태 머신으로 설계하는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.
설정 전에 정리할 문제
Splash는 예쁜 대기 화면보다 앱 시작 경계를 표현하는 도구입니다. ‘필수 초기화’에서 시작해 ‘명시적인 상태’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.
상태 머신으로 옮기는 순서
- 시작 시 실행되는 모든 작업과 의존 관계를 적습니다.
- 사용자에게 다른 화면을 보여 줘야 하는 결과만 상태로 정의합니다.
- 각 상태의 진입 조건과 허용 전이, 재시도 행동을 표로 만듭니다.
- 딥링크 목적지는 Ready 이후에 한 번만 소비합니다.
- 오프라인·서버 오류·설정 누락을 주입해 모든 종료 상태를 테스트합니다.
앱 시작을 상태로 나눠야 하는 이유
필수 초기화
로컬 설정 읽기처럼 다음 단계에 반드시 필요한 작업과 분석 SDK처럼 늦춰도 되는 작업을 분리해야 첫 화면이 불필요하게 지연되지 않습니다.
명시적인 상태
Booting, NeedsLogin, Ready, Maintenance, UpdateRequired, RecoverableError처럼 사용자가 볼 결과를 상태로 정의합니다.
전이 조건
여러 비동기 작업이 끝나는 순서가 아니라 필요한 조건이 충족됐는지로 다음 상태를 결정합니다.
오류 복구
네트워크 오류와 잘못된 로컬 데이터, 강제 업데이트를 같은 실패 화면으로 묶지 않습니다. 재시도 가능 여부와 안전한 대체 경로가 달라집니다.
최대 대기
스플래시를 무한히 유지하지 말고 작업별 시간 제한과 진단 ID를 둡니다. 사용자는 멈춤과 로딩을 구분할 수 있어야 합니다.
작업 전 확인표
| 확인 항목 | 질문 |
|---|---|
| 첫 기준: 필수 초기화 | 변경 전에 전제와 목적을 확인했는가? |
| 분리 대상: 명시적인 상태 | 다른 책임과 섞이지 않게 경계를 정했는가? |
| 피할 패턴: 여러 Promise 완료 순서에 따라 화면을 직접 바꾸기 | 본문에서 경고한 패턴이 남아 있지 않은가? |
| 오류와 복구 | 정상 경로뿐 아니라 실패와 되돌리기도 확인했는가? |
스플래시가 멈추는 전형적인 원인
- 여러 Promise 완료 순서에 따라 화면을 직접 바꾸기
- 선택 작업 하나의 실패로 전체 앱을 막기
- 오류를 기록하지 않고 로고 화면만 계속 보여 주기
- 딥링크와 기본 라우팅이 각각 시작 화면을 덮어쓰기
핵심만 다시 보면
Splash는 예쁜 대기 화면보다 앱 시작 경계를 표현하는 도구입니다. 초기화를 상태와 전이로 모델링하면 지연과 오류의 위치가 보이고, 딥링크와 로그인 같은 외부 조건도 예측 가능한 순서로 처리할 수 있습니다.
