화면의 존재와 현재 접근 가능 여부를 분리해 멀티 프로필 앱의 라우팅 복잡도를 줄이는 방법을 설명합니다. 설정부터 시작하기 전에 ‘Registry는 화면의 존재를 답한다’을 분리해서 봐야 합니다. 라우트 이름, 화면 컴포넌트, 필요한 파라미터 형식과 소속 기능을 등록합니다. 현재 사용자가 들어갈 수 있는지는 여기서 판단하지 않습니다.
이 글의 범위
실제 경험이나 측정 결과를 가정하지 않고, 공식 문서로 확인 가능한 개념과 적용 순서를 일반 가이드로 설명합니다. 제품 버전과 서비스 정책은 바뀔 수 있으므로 적용 전 연결된 공식 문서를 다시 확인하세요.
Route Registry와 Route Guard를 분리해야 하는 이유 핵심 판단 흐름 설명용 개념도
그림 1. Route Registry와 Route Guard를 분리해야 하는 이유의 핵심 판단 순서를 정리한 설명용 개념도입니다. 실제 서비스 화면, 운영 로그 또는 측정 결과가 아닙니다.
설정 전에 정리할 문제
Route Registry와 Route Guard를 분리하면 화면 정의와 접근 정책의 변경 주기가 서로 영향을 덜 줍니다. ‘Registry는 화면의 존재를 답한다’에서 시작해 ‘Guard는 접근 가능성을 답한다’와의 경계를 정하면 구현할 범위와 실패했을 때 확인할 지점을 구분하기 쉬워집니다.
기존 라우팅을 분리하는 순서
- 화면 등록 코드와 if 조건을 목록으로 나눕니다.
- 모든 외부 입력을 내부 RouteIntent 형태로 정규화합니다.
- Registry 조회 실패와 Guard 거절을 서로 다른 오류로 처리합니다.
- 허용 결과에 목적지와 필요한 파라미터를 담습니다.
- 종료·백그라운드·로그아웃 상태를 조합한 표 기반 테스트를 작성합니다.
Registry와 Guard가 답해야 하는 질문
Registry는 화면의 존재를 답한다
라우트 이름, 화면 컴포넌트, 필요한 파라미터 형식과 소속 기능을 등록합니다. 현재 사용자가 들어갈 수 있는지는 여기서 판단하지 않습니다.
Guard는 접근 가능성을 답한다
로그인, 역할, 프로필, 기능 플래그, 서비스 상태를 받아 허용·로그인 유도·차단 같은 결과를 돌려줍니다.
정규화 단계가 필요하다
딥링크와 푸시 payload를 내부 RouteIntent로 바꾸면 입력 형식이 달라도 같은 Guard와 네비게이션 로직을 사용할 수 있습니다.
거절 결과도 모델링한다
false 하나만 반환하면 사용자가 왜 이동하지 못했는지 알기 어렵습니다. 거절 이유와 대체 경로를 구조화하면 UI와 로그가 일관됩니다.
테스트 축이 분리된다
Registry 테스트는 누락·중복 라우트를, Guard 테스트는 상태 조합별 결정을 검증하므로 실패 원인을 좁히기 쉬워집니다.
작업 전 확인표
| 확인 항목 | 질문 |
|---|---|
| 첫 기준: Registry는 화면의 존재를 답한다 | 변경 전에 전제와 목적을 확인했는가? |
| 분리 대상: Guard는 접근 가능성을 답한다 | 다른 책임과 섞이지 않게 경계를 정했는가? |
| 피할 패턴: Registry 내부에서 사용자 세션을 직접 읽기 | 본문에서 경고한 패턴이 남아 있지 않은가? |
| 오류와 복구 | 정상 경로뿐 아니라 실패와 되돌리기도 확인했는가? |
분리 후에도 다시 꼬이는 원인
- Registry 내부에서 사용자 세션을 직접 읽기
- Guard가 화면 컴포넌트를 직접 생성하기
- 라우트 이름을 여러 파일에서 중복 정의하기
- 거절 이유 없이 홈으로만 보내 문제를 숨기기
핵심만 다시 보면
Route Registry와 Route Guard를 분리하면 화면 정의와 접근 정책의 변경 주기가 서로 영향을 덜 줍니다. 외부 입력을 먼저 정규화하고 거절 이유까지 모델링하면 딥링크와 푸시 라우팅도 같은 규칙으로 검증할 수 있습니다.
