App Router의 파일 기반 라우팅
App Router의 파일 규칙을 URL·레이아웃·데이터 흐름 설계 도구로 쓰는 방법과 복잡도 제어 패턴
규칙 암기가 아니라 “설계 도구”로 사용하는 법
App Router를 처음 접하면 대부분 이렇게 접근한다.
“어떤 파일이 어떤 라우트를 만든다”
이 접근은 빠르게 한계에 도달한다.
대규모 App Router 프로젝트에서 파일 기반 라우팅은 URL 매핑 규칙이 아니라, 애플리케이션 구조를 설계하는 도구다.
이 글의 목적은 하나다.
App Router의 라우팅을
‘기능 설명’이 아니라 ‘설계 흐름’으로 이해시키는 것
1. 기본 파일 규칙의 의미
“URL을 만든다”가 아니라 “UI 트리를 정의한다”
App Router의 핵심 전제는 다음 한 문장으로 요약된다.
라우트 = URL + 레이아웃 + 데이터 흐름
즉, 파일 하나는 단순히 페이지를 의미하지 않는다.
page.tsx→ 해당 세그먼트의 주 콘텐츠layout.tsx→ 하위 모든 라우트의 공통 UI 골격loading.tsx/error.tsx→ 상태 표현not-found.tsx→ 경계 정의
👉 App Router의 파일 규칙은
“이 URL에서 어떤 UI 트리가 구성되는가”를 선언한다.
2. 동적 라우트 설계 패턴
“파라미터 처리”가 아니라 “도메인 경계 표현”
❌ 잘못된 접근
[id]를 단순히 “숫자 치환”으로 이해- 모든 동적 라우트를 동일한 구조로 처리
이 방식은 도메인 복잡도가 올라가면 즉시 무너진다.
✅ 실무적인 동적 라우트 사고
동적 세그먼트는 보통 도메인 엔티티의 경계를 나타낸다.
예:
/products/[productId]/users/[userId]/settings/posts/[slug]
중요한 질문은 이것이다.
이 동적 라우트 아래에서
공유되는 레이아웃과 데이터는 무엇인가?
이 질문이 곧 디렉터리 구조를 결정한다.
3. route group / parallel / intercepting routes
“특수 기능”이 아니라 “복잡성 제어 수단”
이 세 가지는 문법이 아니라 설계 문제를 해결하기 위한 도구다.
3-1. Route Group ( )
목적: URL과 내부 구조를 분리
사용 목적
- URL에 드러나지 않는 내부 분리
- 레이아웃/역할 단위로 코드 정리
설계 관점
- “사용자는 몰라도 되는 경계”
- “팀 내부 구조를 드러내지 않기”
👉 Route Group은 조직도를 위한 도구다.
3-2. Parallel Routes @
목적: 한 URL에서 여러 UI 상태를 병렬로 관리
사용 목적
- 메인 콘텐츠 + 보조 패널
- 대시보드 구조
- 독립적으로 로딩되는 영역
설계 관점
- “이 화면은 하나의 페이지인가?”
- “여러 UI 흐름의 조합인가?”
👉 Parallel Route는 UI 합성 도구다.
3-3. Intercepting Routes
목적: 기존 흐름을 깨지 않고 UI를 끼워 넣기
사용 목적
- 모달
- 상세 보기 오버레이
- 리스트 → 상세 전환 UX 유지
설계 관점
- URL은 바뀌지만
- 사용자의 인지 흐름은 유지
👉 Intercepting Route는 UX 연속성 제어 도구다.
4. 디렉터리 구조 설계 예시 (실무 기준)
아래는 “콘텐츠 + 관리 영역”을 가진 서비스 예시다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
app/
├─ (public)/
│ ├─ layout.tsx
│ ├─ page.tsx # 홈
│ ├─ posts/
│ │ ├─ [slug]/
│ │ │ ├─ page.tsx # 게시글 상세
│ │ │ └─ loading.tsx
│ │ └─ page.tsx # 게시글 목록
│
├─ (dashboard)/
│ ├─ layout.tsx # 관리자 공통 레이아웃
│ ├─ page.tsx # 대시보드 홈
│ ├─ posts/
│ │ ├─ page.tsx
│ │ └─ @modal/
│ │ └─ edit/
│ │ └─ page.tsx # 모달 편집
│
└─ api/
└─ ...
이 구조의 설계 의도
- URL 구조 ≠ 내부 구조
- 공통 레이아웃은 명확히 격리
- 모달/보조 UI는 병렬·가로채기 라우트로 처리
- “페이지”가 아니라 “경험 단위”로 분리
핵심 정리: App Router 라우팅 사고 체크리스트
- 이 URL은 하나의 페이지인가, UI 트리인가?
- 공통 레이아웃은 어디까지 공유되어야 하는가?
- 이 동적 세그먼트는 단순 ID인가, 도메인 경계인가?
- 이 UI는 병렬로 존재해야 하는가?
- URL 변경이 UX 흐름을 깨면 안 되는가?
결론
App Router의 파일 기반 라우팅은
외워서 쓰는 규칙이 아니다.
- URL 설계
- UI 구조
- 데이터 경계
- UX 흐름
이 네 가지를 하나의 디렉터리 구조로 동시에 설계하게 만드는 도구다.
App Router를 잘 쓴다는 것은
라우트를 “만드는 것”이 아니라
복잡한 애플리케이션을 질서 있게 나누는 것이다.