공개 라우트 화이트리스트

인증 게이트가 있는 앱에서 어떤 경로는 비인증 사용자도 봐야 하는가 를 결정하는 자리가 있습니다. 이 자리에 공개 경로 화이트리스트 가 보통 자리잡습니다. 그리고 신규 도메인 도입 시 이 자리를 같이 갱신 하지 않으면 사용자가 정보성 페이지에 진입할 때 로그인 화면으로 튕깁니다.

1. 사고 시나리오

상황	사용자 경험	진짜 원인
비인증 사용자가 /약국 진입 → /login?returnUrl=/약국 redirect	"왜 정보 보는데 로그인하라지?"	publicRoute 화이트리스트에 /약국 누락
검색엔진 크롤러가 정보성 페이지를 못 색인	SEO 점수 하락	동일 원인 — 크롤러도 비인증
신규 도메인 PR 머지 후 해당 도메인 진입점 누락	사용자 발견 → 사후 패치	publicRoute 동기화 의무 누락

2. 흔한 매처 형태

비인증 사용자도 볼 수 있어야 하는 경로는 두 종류로 나뉩니다.

• 정확한 경로: /, /login, /signup, /help
• prefix 매처: /약국, /약국/서울/12345 (도메인 전체)

prefix 매처는 startsWith 패턴 하나로 도메인 전체 를 한 자리에 등록할 수 있어 가장 견고합니다.

function isPublicRoute(pathname: string): boolean {
  if (pathname === "/" ) return true;
  if (pathname.startsWith("/login")) return true;
  if (pathname.startsWith("/signup")) return true;
  // 정보성 도메인 ↓
  if (pathname.startsWith("/약국")) return true;
  if (pathname.startsWith("/가격비교")) return true;
  if (pathname.startsWith("/요양")) return true;
  // ...
  return false;
}

타입 정의 (string union) 보다 함수 가 좋은 이유 — startsWith 같은 동적 매칭이 가능.

3. 신규 도메인 도입 동기화 7자리

대시보드 위젯 통일성 의 7 자리 동기화 중 #7 자리.

신규 도메인 PR 체크리스트
├─ 라우트 등록 (app/x/page.tsx)
├─ 대시보드 위젯
├─ 사이드바
├─ 푸터 링크
├─ i18n ko/en
├─ 검색 카테고리
└─ 공개 라우트 화이트리스트  ← 이 자리

이 자리 하나가 빠지면 비인증 사용자가 도메인에 도달조차 못함 — 가장 큰 사용자 영향에 비해 가장 쉽게 누락되는 항목.

4. 적용 전 / 적용 후

측면	화이트리스트 누락	화이트리스트 정합
비인증 사용자 진입	login 강제 리다이렉트	정보성 페이지 정상 렌더
검색 크롤러 색인	색인 실패	색인 가능
신규 도메인 도입 후 사용자 발견	"왜 안 보여?" 직접 보고	매끄러운 도입
SEO	점수 하락	영향 없음
회귀 검증	사후 사용자 보고	PR 체크리스트로 사전

5. 자신의 프로젝트에 적용하려면

• 인증 게이트 (middleware · ClientLayout · server guard) 자리에 isPublicRoute() 함수 단일 SSOT 만들기.
• 신규 도메인 PR 템플릿에 "publicRoute 등록" 체크박스 추가.
• prefix 매처 (startsWith) 패턴을 기본으로 — 도메인 하위 모든 경로 자동 포함.
• 정보성 페이지 / 인증 필요 페이지를 코드 주석 으로 분리해 검토 가능하게.
• e2e 회귀 — 비인증 fetch 시 정보성 도메인은 200, 인증 도메인은 308 인지 카운트 검증.

비인증 사용자 한 사람이 페이지를 못 보면 — 그 한 사람이 검색 엔진일 수도 있습니다. 화이트리스트는 작은 자리지만 공개의 폭 을 결정하는 자리입니다.