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