Splash 화면을 앱 시작 상태 머신으로 설계하는 방법

인증·원격 설정·업데이트·오류 복구를 상태로 나눠 앱 시작 흐름을 예측 가능하게 만드는 방법을 정리합니다. 설정부터 시작하기 전에 ‘필수 초기화’을 분리해서 봐야 합니다. 로컬 설정 읽기처럼 다음 단계에 반드시 필요한 작업과 분석 SDK처럼 늦춰도 되는 작업을 분리해야 첫 화면이 불필요하게 지연되지 않습니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

Splash 화면을 앱 시작 상태 머신으로 설계하는 방법 핵심 판단 흐름 설명용 개념도

그림 1. Splash 화면을 앱 시작 상태 머신으로 설계하는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

설정 전에 정리할 문제

Splash는 예쁜 대기 화면보다 앱 시작 경계를 표현하는 도구입니다. ‘필수 초기화’에서 시작해 ‘명시적인 상태’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

상태 머신으로 옮기는 순서

1. 시작 시 실행되는 모든 작업과 의존 관계를 적습니다.
2. 사용자에게 다른 화면을 보여 줘야 하는 결과만 상태로 정의합니다.
3. 각 상태의 진입 조건과 허용 전이, 재시도 행동을 표로 만듭니다.
4. 딥링크 목적지는 Ready 이후에 한 번만 소비합니다.
5. 오프라인·서버 오류·설정 누락을 주입해 모든 종료 상태를 테스트합니다.

앱 시작을 상태로 나눠야 하는 이유

필수 초기화

로컬 설정 읽기처럼 다음 단계에 반드시 필요한 작업과 분석 SDK처럼 늦춰도 되는 작업을 분리해야 첫 화면이 불필요하게 지연되지 않습니다.

명시적인 상태

Booting, NeedsLogin, Ready, Maintenance, UpdateRequired, RecoverableError처럼 사용자가 볼 결과를 상태로 정의합니다.

전이 조건

여러 비동기 작업이 끝나는 순서가 아니라 필요한 조건이 충족됐는지로 다음 상태를 결정합니다.

오류 복구

네트워크 오류와 잘못된 로컬 데이터, 강제 업데이트를 같은 실패 화면으로 묶지 않습니다. 재시도 가능 여부와 안전한 대체 경로가 달라집니다.

최대 대기

스플래시를 무한히 유지하지 말고 작업별 시간 제한과 진단 ID를 둡니다. 사용자는 멈춤과 로딩을 구분할 수 있어야 합니다.

작업 전 확인표

확인 항목	질문
첫 기준: 필수 초기화	변경 전에 전제와 목적을 확인했는가?
분리 대상: 명시적인 상태	다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 여러 Promise 완료 순서에 따라 화면을 직접 바꾸기	본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구	정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

스플래시가 멈추는 전형적인 원인

• 여러 Promise 완료 순서에 따라 화면을 직접 바꾸기
• 선택 작업 하나의 실패로 전체 앱을 막기
• 오류를 기록하지 않고 로고 화면만 계속 보여 주기
• 딥링크와 기본 라우팅이 각각 시작 화면을 덮어쓰기

핵심만 다시 보면

Splash는 예쁜 대기 화면보다 앱 시작 경계를 표현하는 도구입니다. 초기화를 상태와 전이로 모델링하면 지연과 오류의 위치가 보이고, 딥링크와 로그인 같은 외부 조건도 예측 가능한 순서로 처리할 수 있습니다.

---

참고한 공식 문서

• React Native AppState

딥링크와 푸시 라우팅을 함께 테스트해야 하는 이유

앱 종료·백그라운드·인증 상태에 따라 달라지는 외부 진입 경로를 하나의 테스트 표로 검증하는 방법을 정리합니다. 여러 선택지를 한 번에 적용하기보다 ‘앱 생명주기’부터 확인합니다. 종료 상태의 initial URL과 실행 중 url 이벤트는 들어오는 경로가 다릅니다. 백그라운드 복귀까지 따로 확인해야 합니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

처음 확인할 경계

딥링크와 푸시는 입력 형식만 다를 뿐 외부에서 앱 상태를 바꾸는 같은 종류의 진입입니다. ‘앱 생명주기’에서 시작해 ‘인증 상태’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

각 기능을 따로 테스트할 때 놓치는 것

• 종료 상태에서만 발생하는 초기화 순서 문제
• 로그인 뒤 원래 목적지를 잃는 문제
• 푸시 탭과 URL 이벤트가 동시에 처리되는 문제
• 지원하지 않는 외부 URL을 내부 WebView로 여는 문제

딥링크와 푸시 라우팅을 함께 테스트해야 하는 이유 핵심 판단 흐름 설명용 개념도

그림 1. 딥링크와 푸시 라우팅을 함께 테스트해야 하는 이유의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

최소 시나리오 표를 만드는 순서

1. 딥링크와 푸시 payload를 동일한 RouteIntent로 변환합니다.
2. 앱 종료·백그라운드·포그라운드 상태를 행으로 둡니다.
3. 로그인·로그아웃·세션 만료를 열로 추가합니다.
4. 각 조합에서 최종 화면과 중간 안내, 이벤트 소비 여부를 기록합니다.
5. 지원하지 않는 링크와 중복 탭도 회귀 테스트에 포함합니다.

외부 진입 테스트의 네 가지 축

앱 생명주기

종료 상태의 initial URL과 실행 중 url 이벤트는 들어오는 경로가 다릅니다. 백그라운드 복귀까지 따로 확인해야 합니다.

인증 상태

로그아웃 사용자는 로그인 후 원래 목적지로 돌아가야 하고, 만료 세션은 복구 실패 시 안전한 화면으로 이동해야 합니다.

데이터 준비 상태

원격 설정과 프로필 Registry가 준비되기 전에 라우팅하면 없는 화면이나 잘못된 브랜드가 열릴 수 있습니다.

중복 이벤트

사용자가 알림을 두 번 누르거나 같은 URL 이벤트가 재전달돼도 화면이 중복 쌓이지 않게 이벤트 ID와 소비 상태를 관리합니다.

잘못된 입력

허용하지 않는 scheme, host, route, 파라미터는 거절하고 로그에 민감한 전체 토큰이나 개인정보를 남기지 않습니다.

실제 적용과 설명을 대조하기

확인 항목	질문
첫 기준: 앱 생명주기	변경 전에 전제와 목적을 확인했는가?
분리 대상: 인증 상태	다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 종료 상태에서만 발생하는 초기화 순서 문제	본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구	정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

적용 순서 요약

딥링크와 푸시는 입력 형식만 다를 뿐 외부에서 앱 상태를 바꾸는 같은 종류의 진입입니다. 생명주기, 인증, 초기화, 중복 입력을 한 테스트 표에서 다루면 릴리스 직전에 나타나는 라우팅 오류를 줄일 수 있습니다.

---

참고한 공식 문서

• React Native Linking
• React Native AppState

selectedProfiles로 빌드 대상을 제어할 때의 장단점

여러 브랜드 앱을 한 코드베이스에서 운영할 때 명시적 프로필 설정과 CI 검증을 함께 설계하는 방법을 설명합니다. 운영 단계에서 판단의 출발점은 ‘명시적인 빌드 범위’입니다. 이번 산출물에 포함될 제품을 설정으로 고정하면 의도치 않은 브랜드 리소스와 기능이 섞이는 일을 줄일 수 있습니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

selectedProfiles로 빌드 대상을 제어할 때의 장단점 핵심 판단 흐름 설명용 개념도

그림 1. selectedProfiles로 빌드 대상을 제어할 때의 장단점의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

selectedProfiles 방식의 이점과 비용

명시적인 빌드 범위

이번 산출물에 포함될 제품을 설정으로 고정하면 의도치 않은 브랜드 리소스와 기능이 섞이는 일을 줄일 수 있습니다.

번들 최적화 가능성

빌드 단계에서 제외가 실제 번들 제외로 이어지는지는 도구 체인에 따라 다릅니다. 런타임에서 메뉴만 숨긴 것을 번들 제거로 착각하지 않습니다.

설정 조합 증가

프로필 수가 늘수록 가능한 조합과 테스트 범위가 커집니다. 지원하는 조합을 제한하고 이름 있는 빌드 프리셋으로 관리하는 편이 안전합니다.

네이티브 설정 동기화

패키지명, 딥링크, 아이콘, Firebase 설정처럼 JavaScript 밖의 값도 선택된 프로필과 일치해야 합니다.

재현 가능한 산출물

커밋, 프리셋, 환경, 의존성 잠금 파일을 함께 기록해야 같은 앱을 다시 만들 수 있습니다.

도구보다 먼저 볼 기준

selectedProfiles는 빌드 의도를 명시하는 좋은 출발점이지만 그 자체가 완전한 제품 분리 기능은 아닙니다. ‘명시적인 빌드 범위’에서 시작해 ‘번들 최적화 가능성’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

CI에 연결하는 점검 순서

1. 지원할 프로필 조합을 프리셋 이름으로 정의합니다.
2. 각 프리셋에 필요한 리소스와 네이티브 설정 목록을 만듭니다.
3. 빌드 전 스키마 검증으로 누락·중복 프로필을 차단합니다.
4. 생성된 앱의 패키지명, 링크 스킴, 버전, 포함 기능을 자동 검사합니다.
5. 산출물 메타데이터에 프리셋과 커밋을 기록합니다.

변경 전 체크 포인트

확인 항목	질문
첫 기준: 명시적인 빌드 범위	변경 전에 전제와 목적을 확인했는가?
분리 대상: 번들 최적화 가능성	다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 존재하지 않는 프로필 이름을 조용히 무시하기	본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구	정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

설정 파일 하나에 기대면 생기는 문제

• 존재하지 않는 프로필 이름을 조용히 무시하기
• 런타임 숨김을 코드·리소스 제거로 오해하기
• 로컬 설정과 CI 환경 변수가 서로 다른 우선순위를 갖기
• 모든 조합을 지원한다고 선언하고 실제 테스트는 한 조합만 하기

결론

selectedProfiles는 빌드 의도를 명시하는 좋은 출발점이지만 그 자체가 완전한 제품 분리 기능은 아닙니다. 지원 프리셋, 스키마 검증, 네이티브 설정 검사와 산출물 기록이 함께 있어야 운영 가능한 방식이 됩니다.

---

참고한 공식 문서

• React Native 환경 설정

프로필별 권한 로직을 공통 레이어로 모으는 방법

화면마다 흩어진 권한 분기를 정책 레이어로 옮겨 변경 범위와 테스트 비용을 줄이는 설계 원칙을 정리합니다. 복잡한 기능 이름보다 먼저 확인할 것은 ‘주체’입니다. 로그인 사용자, 역할, 조직, 구독 상태처럼 권한 판단에 필요한 값을 작은 컨텍스트로 정리합니다. 화면이 저장소를 직접 조회하지 않게 합니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

판단의 출발점

공통 권한 레이어의 목적은 조건문을 한 파일로 옮기는 것이 아니라 정책 입력과 결정을 명확히 만드는 데 있습니다. ‘주체’에서 시작해 ‘대상’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

권한 정책 레이어에 모을 정보

주체

로그인 사용자, 역할, 조직, 구독 상태처럼 권한 판단에 필요한 값을 작은 컨텍스트로 정리합니다. 화면이 저장소를 직접 조회하지 않게 합니다.

대상

화면 이름보다 viewReport, editProfile처럼 기능 행위를 기준으로 권한을 정의하면 UI가 바뀌어도 정책을 재사용하기 쉽습니다.

환경

프로필, 지역, 점검 상태, 기능 플래그처럼 사용자 밖의 조건을 별도 입력으로 둡니다. 역할만으로 모든 예외를 표현하지 않습니다.

결정

허용 여부와 함께 이유 코드를 반환합니다. 로그인 필요, 기능 미제공, 권한 부족을 구분해야 안내 화면과 운영 로그가 정확해집니다.

기본 거부

알 수 없는 기능이나 누락된 컨텍스트를 임의로 허용하지 않습니다. 안전한 기본값을 쓰고 정상 경로에서 누락이 생기면 테스트가 실패하게 합니다.

프로필별 권한 로직을 공통 레이어로 모으는 방법 핵심 판단 흐름 설명용 개념도

그림 1. 프로필별 권한 로직을 공통 레이어로 모으는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

중앙화가 실패하는 경우

• 거대한 한 함수에 모든 제품 규칙을 넣기
• UI 표시 여부와 서버 권한을 같은 것으로 믿기
• 권한 실패를 일반 네트워크 오류로 처리하기
• 클라이언트 Guard만으로 민감한 API를 보호했다고 판단하기

화면 조건문을 정책으로 옮기는 순서

1. 화면별 조건문을 기능 행위와 상태 입력으로 분해합니다.
2. 중복 규칙을 하나의 정책 함수로 합칩니다.
3. 정책 결과에 이유 코드와 선택 가능한 대체 행동을 정의합니다.
4. 화면은 결과를 렌더링하고 정책 결정은 수정하지 않게 합니다.
5. 프로필·역할·상태의 경계값을 표 기반 테스트로 고정합니다.

운영 전 빠른 점검

확인 항목	질문
첫 기준: 주체	변경 전에 전제와 목적을 확인했는가?
분리 대상: 대상	다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 거대한 한 함수에 모든 제품 규칙을 넣기	본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구	정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

마무리

공통 권한 레이어의 목적은 조건문을 한 파일로 옮기는 것이 아니라 정책 입력과 결정을 명확히 만드는 데 있습니다. 클라이언트는 일관된 UX를 제공하고, 실제 데이터 권한은 서버에서도 같은 원칙으로 검증해야 합니다.

---

참고한 공식 문서

• React Native 보안 안내

Route Registry와 Route Guard를 분리해야 하는 이유

화면의 존재와 현재 접근 가능 여부를 분리해 멀티 프로필 앱의 라우팅 복잡도를 줄이는 방법을 설명합니다. 설정부터 시작하기 전에 ‘Registry는 화면의 존재를 답한다’을 분리해서 봐야 합니다. 라우트 이름, 화면 컴포넌트, 필요한 파라미터 형식과 소속 기능을 등록합니다. 현재 사용자가 들어갈 수 있는지는 여기서 판단하지 않습니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

Route Registry와 Route Guard를 분리해야 하는 이유 핵심 판단 흐름 설명용 개념도

그림 1. Route Registry와 Route Guard를 분리해야 하는 이유의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

설정 전에 정리할 문제

Route Registry와 Route Guard를 분리하면 화면 정의와 접근 정책의 변경 주기가 서로 영향을 덜 줍니다. ‘Registry는 화면의 존재를 답한다’에서 시작해 ‘Guard는 접근 가능성을 답한다’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

기존 라우팅을 분리하는 순서

1. 화면 등록 코드와 if 조건을 목록으로 나눕니다.
2. 모든 외부 입력을 내부 RouteIntent 형태로 정규화합니다.
3. Registry 조회 실패와 Guard 거절을 서로 다른 오류로 처리합니다.
4. 허용 결과에 목적지와 필요한 파라미터를 담습니다.
5. 종료·백그라운드·로그아웃 상태를 조합한 표 기반 테스트를 작성합니다.

Registry와 Guard가 답해야 하는 질문

Registry는 화면의 존재를 답한다

라우트 이름, 화면 컴포넌트, 필요한 파라미터 형식과 소속 기능을 등록합니다. 현재 사용자가 들어갈 수 있는지는 여기서 판단하지 않습니다.

Guard는 접근 가능성을 답한다

로그인, 역할, 프로필, 기능 플래그, 서비스 상태를 받아 허용·로그인 유도·차단 같은 결과를 돌려줍니다.

정규화 단계가 필요하다

딥링크와 푸시 payload를 내부 RouteIntent로 바꾸면 입력 형식이 달라도 같은 Guard와 네비게이션 로직을 사용할 수 있습니다.

거절 결과도 모델링한다

false 하나만 반환하면 사용자가 왜 이동하지 못했는지 알기 어렵습니다. 거절 이유와 대체 경로를 구조화하면 UI와 로그가 일관됩니다.

테스트 축이 분리된다

Registry 테스트는 누락·중복 라우트를, Guard 테스트는 상태 조합별 결정을 검증하므로 실패 원인을 좁히기 쉬워집니다.

작업 전 확인표

확인 항목	질문
첫 기준: Registry는 화면의 존재를 답한다	변경 전에 전제와 목적을 확인했는가?
분리 대상: Guard는 접근 가능성을 답한다	다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: Registry 내부에서 사용자 세션을 직접 읽기	본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구	정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

분리 후에도 다시 꼬이는 원인

• Registry 내부에서 사용자 세션을 직접 읽기
• Guard가 화면 컴포넌트를 직접 생성하기
• 라우트 이름을 여러 파일에서 중복 정의하기
• 거절 이유 없이 홈으로만 보내 문제를 숨기기

핵심만 다시 보면

Route Registry와 Route Guard를 분리하면 화면 정의와 접근 정책의 변경 주기가 서로 영향을 덜 줍니다. 외부 입력을 먼저 정규화하고 거절 이유까지 모델링하면 딥링크와 푸시 라우팅도 같은 규칙으로 검증할 수 있습니다.

---

참고한 공식 문서

• React Native Linking

React Native 멀티 프로필 앱 구조를 한 문서로 설계하는 방법

Profile Registry와 기능 플래그, 권한, 빌드 대상, 초기 라우팅을 하나의 구조로 연결해 설계하는 기준을 정리합니다. 이 주제를 이해할 때 첫 기준은 ‘Profile Registry’입니다. 프로필 ID와 표시 이름, 허용 기능, 시작 경로처럼 제품을 식별하는 최소 설정을 한곳에 둡니다. 화면 컴포넌트가 브랜드 이름을 직접 비교하지 않게 하는 것이 핵심입니다.

이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.

먼저 구분할 핵심

멀티 프로필 앱은 여러 조건문의 묶음이 아니라 제품 정의, 기능, 권한, 빌드, 라우팅을 연결한 구조입니다. ‘Profile Registry’에서 시작해 ‘기능 플래그’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.

React Native 멀티 프로필 앱 구조를 한 문서로 설계하는 방법 핵심 판단 흐름 설명용 개념도

그림 1. React Native 멀티 프로필 앱 구조를 한 문서로 설계하는 방법의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.

하나의 구조도로 연결해야 할 다섯 영역

Profile Registry

프로필 ID와 표시 이름, 허용 기능, 시작 경로처럼 제품을 식별하는 최소 설정을 한곳에 둡니다. 화면 컴포넌트가 브랜드 이름을 직접 비교하지 않게 하는 것이 핵심입니다.

기능 플래그

기능 제공 여부는 프로필 정의와 연결하되 화면 곳곳의 조건문으로 흩어지지 않게 합니다. 기본값과 알 수 없는 프로필의 처리도 명시해야 합니다.

권한 정책

기능이 존재하는지와 사용자가 지금 접근할 수 있는지는 다른 판단입니다. 역할, 로그인 상태, 지역 제한은 별도 정책 레이어가 결정합니다.

빌드 대상

한 번의 배포에 포함할 프로필 목록을 명시적 설정으로 관리합니다. 프로필 리소스와 네이티브 설정이 실제 빌드에 포함됐는지 CI에서 검사합니다.

초기 라우팅

딥링크와 푸시, 기본 시작 화면을 동일한 라우트 규칙으로 정규화합니다. 프로필을 먼저 확정한 뒤 접근 정책을 통과한 경로만 엽니다.

설계 문서를 만드는 순서

1. 현재 코드의 프로필 조건문과 브랜드별 리소스를 모두 찾습니다.
2. 공통 기능과 프로필별 기능, 사용자 권한 조건을 서로 다른 표로 분리합니다.
3. Registry를 단일 출처로 정하고 화면은 프로필 객체만 전달받게 합니다.
4. 빌드 설정과 런타임 설정 사이의 불일치를 실패 처리하는 검사를 만듭니다.
5. 프로필별 시작·딥링크·권한 거절 시나리오를 같은 테스트 표에 넣습니다.

멀티 프로필 구조를 약하게 만드는 패턴

• 화면마다 profileId 문자열을 직접 비교하기
• 빌드 제외와 런타임 숨김을 같은 기능으로 취급하기
• 공통 코드에 브랜드별 예외를 계속 추가하기
• 알 수 없는 프로필이 들어왔을 때 임의의 기본 프로필로 열기

적용 전 마지막 점검

확인 항목	질문
첫 기준: Profile Registry	변경 전에 전제와 목적을 확인했는가?
분리 대상: 기능 플래그	다른 책임과 섞이지 않게 경계를 정했는가?
피할 패턴: 화면마다 profileId 문자열을 직접 비교하기	본문에서 경고한 패턴이 남아 있지 않은가?
오류와 복구	정상 경로뿐 아니라 실패와 되돌리기도 확인했는가?

정리

멀티 프로필 앱은 여러 조건문의 묶음이 아니라 제품 정의, 기능, 권한, 빌드, 라우팅을 연결한 구조입니다. 각 책임을 분리한 뒤 Registry로 연결하면 새 프로필을 추가할 때 영향 범위를 예측할 수 있습니다.

---

참고한 공식 문서

• React Native Linking