C-1: React Router 8 — 주소로 화면을 나눈다

안녕하세요, 홍순구 튜터입니다. 지난 시간에 우리는 인스타그램 클론의 비주얼을 마감했어요. 아이콘이 문자를 대신하고, 누르면 반응하고, 색과 크기가 기준을 넘습니다. 기능도 다 됩니다. 좋아요를 누르면 숫자가 오르고, 회원가입 폼은 검증까지 하고, 모달도 열려요.

그런데 우리 앱에는 아직 화면이 하나뿐입니다.

회원가입 폼과 피드가 같은 화면에 세로로 쌓여 있어요. 브라우저 주소창은 앱을 처음 연 뒤로 한 번도 바뀐 적이 없습니다. 친구에게 "우리 앱 회원가입 여기서 해" 하고 링크를 보낼 방법이 없어요. 보낼 주소가 하나뿐이니까요.

지난 과목에서는 이런 고민을 할 필요가 없었죠. HTML 파일을 여러 개 만들면 그만이었으니까요. index.html과 profile.html을 만들고 <a href="profile.html">로 이으면, 브라우저가 알아서 새 문서를 받아 와서 그려줬습니다. 파일이 곧 주소였어요.

React로 넘어오면서 그 구조가 사라졌습니다. 우리 앱의 HTML 파일은 index.html 하나뿐이고, 그 안에는 빈 <div id="root">만 있어요. 나머지는 전부 JavaScript가 그립니다. 문서가 하나인데 화면을 어떻게 나눌까요.

오늘 그 답을 만듭니다.

 오늘의 여정

 1. 화면이 하나뿐인 앱          지금 무엇이 안 되는지 직접 해본다
        ↓
 2. 세 모드와 우리의 선택        Declarative / Data / Framework
        ↓
 3. 라우터를 세운다              createBrowserRouter + RouterProvider
        ↓
 4. / 와 /signup 으로 가른다     App.tsx 를 헐어 두 화면으로
        ↓
 5. 머리를 한 곳으로             중첩 라우트와 Outlet
        ↓
 6. 눌러서 오가기                <a> 와 <Link> 의 진짜 차이
        ↓
 7. 지금 어디 있는지             NavLink 와 aria-current

💡 오늘 수업의 핵심 — "화면을 나누는 일은 주소를 나누는 일이다"

컴포넌트를 나누는 것과 화면을 나누는 것은 다릅니다. 우리는 이미 Feed와 SignUpForm을 따로 만들어 뒀지만, 둘은 여전히 한 화면에 함께 있어요. 화면이 갈리려면 주소가 갈려야 합니다.

🎯 학습 목표

• React Router 8의 Data Mode로 라우터를 세우고, 하나뿐이던 화면을 주소별로 나눌 수 있다
• <Link>가 <a>와 무엇이 다른지 설명하고, 그 차이를 개발자 도구에서 직접 확인할 수 있다
• 중첩 라우트와 <Outlet/>으로 주소가 바뀌어도 살아남는 공통 껍데기를 만들 수 있다

Step 1: "화면이 하나뿐인 앱"

코드를 고치기 전에, 지금 우리 앱이 무엇을 못 하는지부터 눈으로 봅시다. 개발 서버를 띄우고 브라우저를 여세요.

네 가지를 직접 해보세요

하나 — 주소창을 보세요. 페이지를 스크롤해서 회원가입 폼으로 갔다가 피드로 돌아와 보세요. 주소창이 바뀌나요? 안 바뀝니다. 앱을 처음 연 주소 그대로예요.

둘 — 회원가입 화면만 공유해 보세요. 친구에게 보낼 링크를 만들어 보려고 하면 막힙니다. 우리 앱에는 보낼 수 있는 주소가 하나뿐이라, 링크를 받은 친구는 항상 맨 위부터 보게 돼요.

셋 — 뒤로 가기를 눌러 보세요. 앱 안에서 이것저것 누르다가 뒤로 가기를 누르면 어디로 갈까요. 앱의 이전 화면이 아니라 앱을 열기 전에 보던 페이지로 나가버립니다. 브라우저 입장에서 우리 앱은 통째로 한 페이지거든요.

넷 — 새로고침을 눌러 보세요. 좋아요를 몇 개 눌러 두고 새로고침하면 전부 처음으로 돌아옵니다. 이건 오늘 고칠 문제가 아니에요. 뒤에 데이터와 상태를 다루는 시간에 다시 만나니 기억만 해두세요.

지난 과목에서는 이게 왜 문제가 아니었나

순수 HTML로 만들 때는 이 넷이 전부 공짜였습니다. 파일을 나누면 주소가 나뉘고, 주소가 나뉘면 나머지는 브라우저가 알아서 해줬어요.

 순수 HTML 시절                        지금 우리 React 앱

 index.html    →  /                    index.html  →  /
 signup.html   →  /signup                 └ <div id="root"></div>
 profile.html  →  /jaehoon                    └ JS 가 전부 그린다

 파일이 곧 주소                        파일은 하나, 주소도 하나
 브라우저가 문서를 새로 받아 그림      JS 가 안에서만 화면을 바꿈

React로 넘어오면서 얻은 것이 많았죠. 화면이 바뀌어도 문서를 새로 받지 않으니 빠르고, 상태가 유지되고, 화면 전환이 매끄럽지만, 그 대가로 주소라는 이름표를 잃었어요.

잃어버린 것을 정리하면

라우터는 이 셋을 되찾아 주는 도구입니다. 문서는 하나로 두면서, 주소는 여러 개인 것처럼 보이게 만들어요.

💡 한 줄 정리

지금 우리 앱은 화면이 하나라서 주소도 하나이고, 그래서 공유·뒤로 가기·직접 접근이 전부 막혀 있습니다.

Step 2: "세 모드와 우리의 선택"

React Router를 설치하기 전에 한 가지 정하고 가야 합니다. 이 라이브러리는 쓰는 방식이 세 가지예요. 문서에서도 이걸 모드(mode)라고 부릅니다.

세 가지 모드

 Declarative  주소를 컴포넌트에 이어주기만 한다
              <BrowserRouter> · <Routes> · <Route> · useNavigate
              ─ 가장 단순. 데이터는 각자 알아서.

 Data         주소 표를 React 바깥으로 꺼낸다
              createBrowserRouter · loader · action · useFetcher
              ─ 화면이 그려지기 전에 데이터를 부를 수 있다.

 Framework    Data 모드에 Vite 플러그인을 씌운다
              타입 안전한 href · 자동 코드 분할 · 서버 렌더링
              ─ 사실상 프레임워크. Next.js 와 같은 자리를 노린다.

Framework 모드는 원래 Remix라는 별도 프레임워크였는데, React Router 7에서 합쳐지면서 지금은 같은 패키지 안에 셋이 다 들어 있습니다.

공식 문서는 Framework를 권합니다. 우리는 Data를 고릅니다

솔직하게 말씀드릴게요. React Router 공식 문서에서 "무엇을 골라야 할지 모르겠으면" 항목에 적혀 있는 답은 Framework 모드입니다. 새로 시작하는 프로젝트라면 그쪽을 권하는데, 우리는 Data 모드로 갑니다. 이유가 둘 있어요.

첫째, 서버 렌더링은 다음 카테고리에서 제대로 다룹니다. Framework 모드의 큰 장점은 서버 렌더링과 자동 코드 분할인데, 우리는 그 주제를 Next.js로 깊게 배울 예정이에요. 여기서 어설프게 맛만 보면 두 번 배우는 셈이 됩니다.

둘째, 지금은 SPA를 SPA로 이해할 시간입니다. 프레임워크가 알아서 해주는 것을 먼저 만나면, 나중에 그게 무엇을 대신해 준 건지 모르게 돼요. 라우터가 주소를 어떻게 맡아보는지, 데이터를 언제 부르는지를 우리 손으로 한 번 조립해 두면, 다음에 프레임워크를 만났을 때 "아, 이걸 대신해 주는구나"가 됩니다.

정리하면 이렇습니다. Data 모드는 번들과 서버를 우리가 쥔 채로 라우팅의 이점만 가져오는 선택이에요.

⚠️ 검색하면 나오는 옛 자료 이야기

React Router를 검색하면 십중팔구 npm install react-router-dom으로 시작하는 글이 나옵니다. 이름이 비슷해서 그냥 따라 하기 쉬운데, 그 패키지는 지금 없습니다.

원래 React Router는 웹용과 네이티브용으로 패키지가 갈려 있었어요. 웹에서 쓰려면 -dom이 붙은 쪽을 깔아야 했죠. 버전 7에서 하나로 합쳐지면서 그 패키지는 껍데기만 남았고, 버전 8에서는 아예 없어졌습니다.

그러니 검색 결과에 그 이름이 보이면 "이 글은 버전 7 이전이구나" 하고 걸러내면 됩니다. 우리가 깔 것은 react-router 하나예요.

💡 한 줄 정리

React Router는 세 가지 방식으로 쓸 수 있고, 우리는 SPA 로서 번들과 서버를 직접 쥐기 위해 Data 모드를 고릅니다.

Step 3: "라우터를 세운다"

이제 설치합니다. 패키지는 하나예요.

npm install react-router

라우터를 만들고 앱을 감싼다

우리 앱의 시작점은 main.tsx입니다. 지금은 <App />을 그냥 그리고 있는데, 그 자리를 라우터가 대신하게 만들 거예요.

// apps/web-spa/src/main.tsx
import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';
import { createBrowserRouter } from 'react-router';
import { RouterProvider } from 'react-router/dom';
import { App } from './App';
import './styles/globals.css';

const rootElement = document.getElementById('root');

if (!rootElement) {
  throw new Error('#root 를 찾지 못했습니다');
}

// 라우터는 React 바깥에서 딱 한 번 만든다.
// 컴포넌트 안에서 만들면 다시 그려질 때마다 새 라우터가 생겨 주소 기록이 끊긴다.
const router = createBrowserRouter([{ path: '/', Component: App }]);

createRoot(rootElement).render(
  <StrictMode>
    <RouterProvider router={router} />
  </StrictMode>,
);

createBrowserRouter에 넘긴 것은 주소와 화면을 짝지은 배열입니다. 지금은 한 줄뿐이에요. "주소가 / 면 App을 그려라." 아직 화면이 하나라 나뉜 게 없지만, 라우터는 세워졌습니다.

RouterProvider는 그 라우터를 React 트리에 연결하는 컴포넌트예요. 이제부터 트리 안 어디서든 "지금 주소가 뭐냐"를 물어볼 수 있습니다.

⚠️ import가 두 갈래입니다

위 코드에서 눈여겨볼 것이 있어요. 두 줄이 서로 다른 곳에서 옵니다.

 createBrowserRouter  ←  'react-router'
 RouterProvider       ←  'react-router/dom'

처음 보면 오타처럼 보이지만, 일부러 그런 겁니다. 왜 그런지 보려면 react-router/dom이 내놓는 RouterProvider의 소스를 열어보면 됩니다. 하는 일이 한 줄뿐이에요.

// node_modules/react-router/dist/development/lib/dom-export/dom-router-provider.js
function RouterProvider$1(props) {
	return React$1.createElement(RouterProvider, {
		flushSync: ReactDOM.flushSync,
		...props
	});
}

이게 전부입니다. react-router 쪽의 RouterProvider를 그대로 가져와서 flushSync라는 함수 하나를 얹어 넘길 뿐이에요. flushSync는 react-dom이 주는 도구라 브라우저 밖에서는 쓸 수 없고, 그래서 브라우저 전용 통로인 /dom으로 갈라놓은 겁니다.

그런데 여기가 함정입니다. react-router에도 RouterProvider라는 이름이 있어서, 잘못 가져와도 아무 일이 안 일어납니다.

경고문이 라이브러리 안에 있긴 한데, flushSync를 실제로 쓰는 기능을 건드릴 때만 뜹니다. 우리가 오늘 배울 범위에서는 영영 안 보여요. 조용히 잘못된 채로 굴러가다가 나중에 화면 전환 효과를 넣을 때쯤 이상하게 동작하니, 이 두 줄은 외우기보다 왜 갈라졌는지를 기억해 두세요. 브라우저에서만 되는 것은 /dom 쪽입니다.

라우터를 컴포넌트 밖에 두는 이유

코드에서 createBrowserRouter는 createRoot보다 위, 즉 어떤 컴포넌트 안도 아닌 곳에서 불립니다. 이건 취향이 아니라 규칙이에요.

라우터는 "지금 어느 주소에 있고, 여기까지 어떻게 왔는지"를 기억하는 물건입니다. 컴포넌트 안에서 만들면 그 컴포넌트가 다시 그려질 때마다 기억을 잃은 새 라우터가 생겨요. 뒤로 가기가 망가지고, 화면 전환이 이상해집니다.

설치가 남긴 자국

라이브러리를 하나 들이면 앱이 얼마나 무거워지는지 재봅시다. 프로덕션 빌드 결과입니다.

CSS가 한 바이트도 안 늘었습니다. 당연한 결과예요. Tailwind는 우리 소스에 적힌 클래스 이름을 훑어서 CSS를 만드는데, 라우터는 클래스 이름을 하나도 안 내놓거든요. Shadcn 컴포넌트를 들여오던 시간에 "CSS는 그대로인데 JS만 십만 바이트 늘었다"를 봤죠. 같은 일이 여기서도 벌어집니다.

JS는 92KB 늘어 1.23배가 됐고, 빌드가 이런 경고를 내놓기 시작해요.

(!) Some chunks are larger than 500 kB after minification. Consider:

500KB 를 넘겼다는 뜻입니다. 지금 당장 문제가 되진 않지만, 이 경고는 나중에 필요한 화면의 코드만 나중에 받아오는 기법으로 해결하게 됩니다. 라우터가 그 기법의 출발점이에요. 화면이 주소로 갈려 있어야 "이 주소의 코드는 나중에"라고 말할 수 있으니까요.

💡 한 줄 정리

라우터는 React 바깥에서 한 번 만들어 RouterProvider로 앱을 감싸고, RouterProvider만 react-router/dom에서 가져옵니다.

Step 4: "/ 와 /signup으로 가른다"

라우터는 세웠지만 주소는 여전히 하나이니, 이제 진짜로 화면을 나눠 봅시다.

무엇을 어디로 나눌까

지금 App.tsx 안에는 두 덩어리가 세로로 쌓여 있어요. 회원가입 폼과 피드입니다. 이 둘을 각자 자기 주소를 가진 화면으로 떼어냅니다.

 App.tsx  ─┬─  회원가입 폼   →  /signup   SignUpPage
           └─  피드          →  /         HomePage

src/routes/라는 새 디렉토리를 만들고 그 안에 화면을 하나씩 둘게요. 앞으로 주소를 가진 것들은 전부 여기에 모입니다.

홈 화면

// apps/web-spa/src/routes/HomePage.tsx
export function HomePage() {
  const { posts, likedCount, toast, toggleLike, reachBottom, dismissToast } = useFeed(feedPosts);

  useScrollRestore(reachBottom);

  // ... 탭 제목과 알림 정리는 지난 시간 그대로 ...

  return (
    <main className="@container mx-auto max-w-[996px] py-4 sm:px-4">
      <header className="mb-4 flex items-baseline justify-between">
        <h1 className="mb-4 text-2xl font-bold">인스타그램</h1>
        <span className="text-sm text-faint">좋아요 누른 게시물 {likedCount}개</span>
        <ThemeToggle />
      </header>
      <Section title="피드">
        <Feed posts={posts} onToggleLike={toggleLike} />
      </Section>
      {toast !== null && <Toast message={toast.message} />}
    </main>
  );
}

App.tsx에 있던 것에서 회원가입 부분만 빠졌습니다. 나머지는 그대로예요.

회원가입 화면

// apps/web-spa/src/routes/SignUpPage.tsx
import { Section } from '../components/Section';
import { SignUpForm } from '../components/SignUpForm';
import { ThemeToggle } from '../components/ThemeToggle';

export function SignUpPage() {
  return (
    <main className="@container mx-auto max-w-[996px] py-4 sm:px-4">
      <header className="mb-4 flex items-baseline justify-between">
        <h1 className="mb-4 text-2xl font-bold">인스타그램</h1>
        <ThemeToggle />
      </header>
      <Section title="회원가입">
        <SignUpForm onSubmit={(values) => console.log('가입 요청', values.username)} />
      </Section>
    </main>
  );
}

주소 표를 따로 뺀다

주소가 둘이 되니 main.tsx 안에 배열을 그대로 두기가 답답해집니다. 표를 따로 빼요.

// apps/web-spa/src/routes/routes.ts
import type { RouteObject } from 'react-router';
import { HomePage } from './HomePage';
import { SignUpPage } from './SignUpPage';

// 주소와 화면을 짝지은 표. 라우터를 만드는 곳(main.tsx)과 떼어두면
// 어떤 주소가 있는지 이 파일 하나만 보면 된다.
export const routes: RouteObject[] = [
  { path: '/', Component: HomePage },
  { path: '/signup', Component: SignUpPage },
];

RouteObject는 라우터가 받아들이는 한 줄의 생김새예요. 타입을 달아두면 path를 pathname으로 잘못 적는 실수를 바로 잡아줍니다.

main.tsx는 이제 표를 받아 라우터만 만듭니다.

// apps/web-spa/src/main.tsx
import { routes } from './routes/routes';

const router = createBrowserRouter(routes);

App.tsx는 사라집니다

두 화면이 각자 자기 껍데기를 갖게 됐으니 App.tsx는 할 일이 없어졌어요. 지웁니다.

처음엔 좀 허전할 수 있는데, 이게 라우팅이 들어온 앱의 자연스러운 생김새입니다. 최상위에 "앱 전체"라는 컴포넌트가 있는 게 아니라, 주소마다 화면이 있고 라우터가 그중 하나를 고르는 구조예요.

확인해 봅시다

브라우저에서 주소를 직접 쳐보세요.

• localhost:5173/ → 피드가 뜹니다
• localhost:5173/signup → 회원가입 폼이 뜹니다

주소창에 주소를 치고 들어가는 것이 됩니다. 새로고침해도 그 화면이 그대로 있어요. Step 1에서 못 했던 것 중 하나가 해결됐습니다.

⚠️ 그런데 머리가 두 번 적혀 있습니다

두 파일을 다시 보세요. <main>도, <header>도, <h1>인스타그램</h1>도, <ThemeToggle />도 양쪽에 똑같이 들어가 있습니다.

지금은 화면이 둘이라 견딜 만하지만, 화면이 다섯 개가 되면 다섯 군데를 똑같이 고쳐야 해요. 제목 하나 바꾸는 데 다섯 파일을 열어야 합니다.

이건 다음 Step에서 바로 해결합니다.

💡 한 줄 정리

주소마다 화면 파일을 두고 표로 묶으면 화면이 갈리지만, 두 화면이 공통으로 쓰는 껍데기는 아직 중복으로 남습니다.

Step 5: "머리를 한 곳으로"

두 화면이 똑같이 들고 있는 껍데기를 하나로 합칩니다. React Router에는 이걸 위한 구조가 따로 있어요. 중첩 라우트입니다.

부모가 껍데기를 맡는다

발상은 이렇습니다. 주소 표를 평평한 목록이 아니라 나무 모양으로 만들어요. 부모가 공통 껍데기를 그리고, 자식이 그 안에 들어갑니다.

 /            Layout      main · header · 제목 · 화면 밝기
  │
  ├ (index)   HomePage    좋아요 개수 · 피드 · 알림
  └ signup    SignUpPage  회원가입 폼

 주소가 / 든 /signup 이든 Layout 은 늘 그려진다.
 갈리는 것은 그 안쪽 한 군데뿐이다.

껍데기를 만든다

// apps/web-spa/src/routes/Layout.tsx
import { Outlet } from 'react-router';
import { ThemeToggle } from '../components/ThemeToggle';

// 주소가 바뀌어도 이 바깥은 살아남는다.
// 갈리는 것은 Outlet 자리 하나뿐이다.
export function Layout() {
  return (
    <main className="@container mx-auto max-w-[996px] py-4 sm:px-4">
      <header className="mb-4 flex items-baseline justify-between">
        <h1 className="mb-4 text-2xl font-bold">인스타그램</h1>
        <ThemeToggle />
      </header>
      <Outlet />
    </main>
  );
}

핵심은 <Outlet />입니다. "여기에 자식 화면을 그려라"라고 표시해 두는 것이에요. children을 받아 그리는 것과 비슷한데, 무엇이 들어올지를 부모가 아니라 주소가 정한다는 점이 다릅니다.

표를 나무로 바꾼다

// apps/web-spa/src/routes/routes.ts
import type { RouteObject } from 'react-router';
import { Layout } from './Layout';
import { HomePage } from './HomePage';
import { SignUpPage } from './SignUpPage';

// 부모가 껍데기(Layout)를 맡고, 자식이 Outlet 자리에 들어간다.
// 자식 주소는 앞에 빗금을 안 붙인다 — 부모 주소에 이어 붙기 때문이다.
export const routes: RouteObject[] = [
  {
    path: '/',
    Component: Layout,
    children: [
      { index: true, Component: HomePage },
      { path: 'signup', Component: SignUpPage },
    ],
  },
];

두 가지를 짚고 갈게요.

index: true는 "부모 주소 그 자체"를 뜻합니다. 부모가 /를 맡고 있으니, 주소가 정확히 / 일 때 그려질 자식이 필요해요. 그게 index 라우트입니다. path를 안 적는 대신 index: true를 적어요.

자식의 path에는 빗금을 안 붙였습니다. 'signup' 이지 '/signup'이 아니에요. 부모 주소에 이어 붙는다는 뜻입니다.

그런데 여기서 한 가지 짚고 갈 게 있어요. 빗금을 붙여서 '/signup'이라고 적으면 어떻게 될까요. 아무 일도 안 일어납니다. 똑같이 동작해요.

이유는 라우터가 절대 경로 자식을 이렇게 판정하기 때문입니다.

 자식이 빗금으로 시작하면
   → 부모들의 주소를 전부 이어 붙인 것으로 시작해야 한다
   → 그렇지 않으면 에러

우리 부모는 /예요. 모든 절대 경로는 /로 시작하니 언제나 통과하므로, 우리 앱에서는 둘 중 무엇을 써도 같아요.

규칙이 실제로 무는 것은 부모 주소가 /가 아닐 때입니다. 부모가 /app인데 자식에 /other를 적으면 이런 에러가 납니다.

Absolute route path "/other" nested under path "/app" is not valid.
An absolute child route path must start with the combined path of all its parent routes.

그래도 자식에는 빗금을 안 붙이는 쪽을 권합니다. 부모 주소가 바뀌었을 때 자식을 안 고쳐도 되거든요. 빗금을 붙여두면 부모를 /account로 옮기는 순간 자식마다 전부 따라 고쳐야 하고, 안 고치면 위 에러가 납니다.

두 화면은 홀가분해집니다

껍데기를 부모에게 넘겼으니 자식은 자기 내용만 그리면 됩니다.

// apps/web-spa/src/routes/SignUpPage.tsx
import { Section } from '../components/Section';
import { SignUpForm } from '../components/SignUpForm';

export function SignUpPage() {
  return (
    <Section title="회원가입">
      <SignUpForm onSubmit={(values) => console.log('가입 요청', values.username)} />
    </Section>
  );
}

<main>도 <header>도 ThemeToggle도 전부 빠졌어요. 회원가입 화면은 이제 정말 회원가입만 담당합니다.

홈도 마찬가지인데, 하나 달라진 것이 있습니다. 좋아요 개수는 홈에만 있는 정보라 Layout으로 못 올려요. 머리말에서 빠져나와 피드 위로 내려왔습니다.

// apps/web-spa/src/routes/HomePage.tsx
  return (
    <>
      <p className="mb-4 text-sm text-faint">좋아요 누른 게시물 {likedCount}개</p>
      <Section title="피드">
        <Feed posts={posts} onToggleLike={toggleLike} />
      </Section>
      {toast !== null && <Toast message={toast.message} />}
    </>
  );

이건 사소해 보이지만 중요한 결정입니다. 공통 껍데기에는 공통인 것만 올릴 수 있어요. 특정 화면에만 있는 상태를 억지로 올리면, 그 상태를 안 쓰는 화면까지 그 상태를 알아야 하는 이상한 구조가 됩니다. 상태를 어디에 둘지는 곧 상태를 다루는 시간에 본격적으로 파고듭니다.

정말 살아남는지 확인해 봅시다

"주소가 바뀌어도 껍데기가 안 사라진다"는 말을 눈으로 확인하는 방법이 있어요. 개발자 도구를 열고 요소 탭에서 <header>를 찾은 다음, 메뉴를 눌러 다른 주소로 이동해 보세요.

React가 화면을 다시 그렸다면 그 <header>는 새로 만들어진 다른 요소여야 하는데, 실제로는 선택이 유지된 채 그대로 있어요. 같은 요소가 살아남은 겁니다.

이게 중첩 라우트의 실제 이득입니다. 껍데기 안에 스크롤 위치나 열려 있는 메뉴 같은 상태가 있어도, 주소가 바뀔 때 안 날아가요.

💡 한 줄 정리

부모 라우트가 <Outlet />으로 자리를 내주면 공통 껍데기는 한 번만 적히고, 주소가 바뀌어도 그 껍데기는 살아남습니다.

Step 6: "눌러서 오가기"

지금까지는 주소를 손으로 쳐서 화면을 옮겼으니, 이제 누를 수 있게 만들어요. 머리말에 메뉴를 답니다.

먼저 아는 방법으로 해봅시다

주소를 알고 있으니 링크를 만들면 되겠죠. 지난 과목에서 쓰던 방법 그대로요.

// apps/web-spa/src/routes/Layout.tsx (이렇게 해보면)
<nav aria-label="주요 메뉴" className="flex gap-3 text-sm">
  <a href="/">홈</a>
  <a href="/signup">회원가입</a>
</nav>

화면에는 잘 나옵니다. 눌러보면 화면도 잘 바뀌어요. 주소창도 바뀌고요. 겉으로는 아무 문제가 없습니다.

그런데 이건 우리가 원한 게 아닙니다.

무슨 일이 벌어지는지 재봅시다

개발자 도구의 네트워크 탭을 열고 기록을 지운 다음, 메뉴를 눌러 보세요. 그리고 두 방식을 나란히 비교합니다.

<a>를 눌렀을 때 수십 건이 다시 날아갑니다. 문서부터 시작해서 우리가 쓰는 모든 코드를 처음부터 다시 받아온 거예요.

이 숫자는 개발 서버 기준이고, 잴 때마다 조금씩 달라집니다. 개발 중에는 코드를 하나로 묶지 않고 파일 단위로 내주기 때문이에요. 실제 배포본에서는 문서와 묶인 JS, CSS 정도라 서너 건입니다. 중요한 것은 숫자가 아니라 0 이냐 아니냐입니다.

전역 값이 사라진 것이 더 결정적입니다. 콘솔에서 window.something = '살아있음'처럼 값을 하나 심어두고 눌러 보세요. <Link>로 옮기면 그 값이 그대로 있고, <a>로 옮기면 사라집니다. JavaScript 가 통째로 다시 시작됐다는 뜻이에요.

그 말은 우리가 들고 있던 것도 전부 날아갔다는 뜻입니다. 좋아요 기록도, 입력하던 폼 내용도, 다크모드로 갈아둔 표시도요.

<Link>로 바꿉니다

// apps/web-spa/src/routes/Layout.tsx
import { Link, Outlet } from 'react-router';
import { ThemeToggle } from '../components/ThemeToggle';

export function Layout() {
  return (
    <main className="@container mx-auto max-w-[996px] py-4 sm:px-4">
      <header className="mb-4 flex items-baseline justify-between">
        <h1 className="mb-4 text-2xl font-bold">인스타그램</h1>
        <nav aria-label="주요 메뉴" className="flex gap-3 text-sm">
          <Link to="/">홈</Link>
          <Link to="/signup">회원가입</Link>
        </nav>
        <ThemeToggle />
      </header>
      <Outlet />
    </main>
  );
}

href가 to로 바뀐 것 말고는 똑같아 보이죠. 하는 일은 완전히 다릅니다.

<Link>는 클릭을 가로채요. 브라우저가 원래 하려던 일(새 문서 받아오기)을 막고, 대신 주소창의 주소만 바꾼 다음 라우터에게 "주소 바뀌었어"라고 알립니다. 라우터는 표를 보고 <Outlet /> 안쪽만 갈아끼워요. 문서는 그대로입니다.

그런데 <Link>도 결국 <a>를 그립니다

개발자 도구에서 메뉴를 살펴보면 이렇게 나옵니다.

<a href="/signup" data-discover="true">회원가입</a>

<Link>라는 태그가 따로 있는 게 아니라, 진짜 앵커를 그리고 거기에 클릭 가로채기를 붙인 것이에요. data-discover는 라우터가 나중에 화면별로 코드를 나눠 받을 때 쓰려고 표시해 두는 것이라 지금은 신경 안 써도 됩니다.

이건 대충 만든 게 아니라 일부러 그렇게 만든 것입니다. href가 진짜로 있어야 되는 일들이 있거든요.

• 마우스 가운데 버튼으로 누르거나 Ctrl을 누른 채 클릭하면 새 탭에서 열립니다
• 우클릭해서 "링크 주소 복사"가 됩니다
• 마우스를 올리면 브라우저 왼쪽 아래에 갈 주소가 뜹니다
• 화면 낭독기가 "링크"라고 읽어줍니다

만약 <button onClick={...}>으로 만들었다면 이 넷이 전부 안 됐을 거예요. 버튼처럼 동작하되 링크로 남는 것, 그게 <Link>의 설계입니다.

💡 한 줄 정리

<Link>는 진짜 앵커를 그리되 클릭을 가로채서, 주소만 바꾸고 문서는 그대로 두고 화면 안쪽만 갈아끼웁니다.

Step 7: "지금 어디 있는지"

메뉴가 생겼는데 아쉬운 것이 하나 있어요. 지금 어느 화면에 있는지 메뉴만 봐서는 모릅니다. 두 링크가 똑같이 생겼거든요.

React Router에는 이걸 위한 링크가 따로 있습니다. NavLink예요.

켜진 것만 다르게 그린다

// apps/web-spa/src/routes/Layout.tsx
import { NavLink, Outlet } from 'react-router';
import { ThemeToggle } from '../components/ThemeToggle';

// NavLink 는 자기가 가리키는 주소에 와 있는지를 알려준다.
// 켜진 링크에는 aria-current="page" 도 알아서 붙는다.
function navLinkClass({ isActive }: { isActive: boolean }) {
  return isActive ? 'font-semibold text-ink' : 'text-faint';
}

export function Layout() {
  return (
    <main className="@container mx-auto max-w-[996px] py-4 sm:px-4">
      <header className="mb-4 flex items-baseline justify-between">
        <h1 className="mb-4 text-2xl font-bold">인스타그램</h1>
        <nav aria-label="주요 메뉴" className="flex gap-3 text-sm">
          <NavLink to="/" className={navLinkClass}>
            홈
          </NavLink>
          <NavLink to="/signup" className={navLinkClass}>
            회원가입
          </NavLink>
        </nav>
        <ThemeToggle />
      </header>
      <Outlet />
    </main>
  );
}

className에 문자열 대신 함수를 넘긴 것이 새롭죠. NavLink는 그 함수를 부르면서 "지금 네가 가리키는 주소에 와 있냐"를 isActive로 알려줍니다. 우리는 그 답을 보고 클래스를 정하면 되니, 홈에 있으면 홈이 진하고 회원가입에 있으면 회원가입이 진합니다.

낭독기에도 같은 사실이 전해집니다

개발자 도구에서 켜진 링크를 살펴보세요. 우리가 안 적은 속성이 붙어 있습니다.

<a aria-current="page" class="font-semibold text-ink" href="/signup" data-discover="true">회원가입</a>

aria-current="page"는 화면 낭독기에게 "이게 지금 페이지"라고 알려주는 표시예요. 눈으로 보는 사람은 글자가 진해진 것으로 알지만, 낭독기를 쓰는 사람에게는 굵기가 전해지지 않습니다. 이 속성이 그 몫을 합니다.

NavLink는 이걸 자동으로 붙여줘요. 우리가 신경 쓸 게 하나 줄어든 겁니다. 지난 시간에 좋아요 버튼의 눌림 상태를 직접 챙겨야 했던 것과 대조되죠. 도구가 챙겨주는 것과 우리가 챙겨야 하는 것을 구분해 두는 게 중요합니다.

⚠️ 검색하면 나오는 조언 하나를 재봤습니다

NavLink를 검색하면 거의 반드시 나오는 조언이 있어요.

루트 링크(to="/")에는 end를 붙여라. 안 그러면 모든 주소에서 켜진다.

end는 NavLink가 받는 옵션입니다. 그런데 이 조언이 지금도 맞는지 직접 재봤어요. 결과입니다.

to="/" 쪽 두 칸을 보세요. end를 붙이나 안 붙이나 결과가 똑같습니다. 위 조언은 이 버전에서 근거가 없어요.

왜 그런지는 라이브러리가 켜짐을 판정하는 규칙을 보면 알 수 있습니다. 규칙은 이렇습니다.

 켜진다 =  주소가 링크와 완전히 같다
        또는
           (end 가 아니고) 주소가 링크로 시작하는데
            그 바로 다음 글자가 '/' 이다

to="/"이고 지금 주소가 /signup인 경우를 넣어 봅시다. 링크는 /이고 그 길이는 1 이니, 확인할 글자는 /signup의 두 번째 글자예요. s입니다. /가 아니죠. 그래서 두 번째 갈래가 애초에 안 걸립니다.

그럼 end는 언제 쓰나요. 표의 마지막 줄이 답입니다. 자식을 거느린 주소에서 갈려요. /signup/done에 있을 때 /signup 링크를 켤지 말지가 그겁니다. 붙이면 "정확히 그 주소일 때만", 안 붙이면 "그 아래 어디에 있어도" 켜져요.

우리 앱에는 아직 자식을 거느린 주소가 없어서 end가 아무 일도 안 합니다. 그래서 안 붙였어요. 하는 일이 없는 옵션을 습관처럼 붙여두면, 나중에 그게 왜 있는지 아무도 모르게 됩니다.

이 이야기의 교훈은 end 자체가 아니에요. 널리 퍼진 조언도 버전이 바뀌면 근거를 잃는다는 것, 그리고 그걸 확인하는 방법은 직접 재보는 것뿐이라는 겁니다.

💡 한 줄 정리

NavLink는 isActive로 켜짐을 알려주고 aria-current까지 붙여주며, end는 자식을 거느린 주소에서만 의미가 있습니다.

마무리

오늘 한 일을 한 줄로 줄이면 이렇습니다. 하나뿐이던 화면에 주소라는 이름표를 붙였습니다.

시작할 때 우리 앱은 주소가 하나였어요. 지금은 /와 /signup이 있고, 각각 링크로 공유할 수 있고, 뒤로 가기가 앱 안에서 동작하고, 주소를 직접 쳐서 들어올 수 있습니다. 껍데기는 한 번만 적혀 있고요.

오늘 배운 핵심 세 가지

💡 하나 — 주소를 나누는 것과 컴포넌트를 나누는 것은 다릅니다. Feed와 SignUpForm은 진작에 따로 있었지만 화면은 하나였어요. 갈린 것은 오늘 주소 표를 만들면서부터입니다. 컴포넌트는 화면을 조립하는 단위이고, 주소는 화면을 부르는 이름이에요.

💡 둘 — 같은 이름이 둘일 수 있고, 틀려도 안 터질 수 있습니다. RouterProvider는 두 곳에서 가져올 수 있는데 잘못 골라도 타입 검사가 통과하고 화면도 잘 나옵니다. 조용히 잘못되는 것이 시끄럽게 터지는 것보다 위험해요. 어디서 오는 것인지 한 번은 확인하는 습관이 필요합니다.

💡 셋 — 널리 알려진 조언도 재봐야 합니다. 루트 링크에 end를 붙이라는 조언은 이 버전에서 아무 일도 안 했어요. 규칙을 직접 읽고 표를 만들어보고 나서야 end가 실제로 갈리는 곳을 알 수 있었습니다. 5분이면 확인할 수 있는 것을 안 하고 외우면, 이유를 모르는 코드가 쌓입니다.

시작할 때 남아 있던 것

지난 시간에 남겨둔 약속들이 어떻게 닫혔는지 봅시다.

다음 시간 예고

오늘 우리가 만든 주소는 둘 다 고정된 주소입니다. /와 /signup은 미리 정해져 있어요. 그런데 진짜 인스타그램의 주소는 이렇게 생겼습니다.

 /p/3021847265        게시물 하나
 /jaehoon             누군가의 프로필

게시물이 백만 개면 주소 표에 백만 줄을 적을 수는 없죠. 다음 시간에는 주소의 일부를 값으로 받는 법을 배웁니다.

그리고 더 큰 문제가 하나 남아 있어요. 오늘은 화면에 그릴 데이터가 이미 코드 안에 있었습니다. 그런데 /p/3021847265로 누가 주소를 치고 들어오면, 그 게시물 데이터는 누가 언제 불러올까요. 화면을 먼저 그리고 나서 부르면 빈 화면이 잠깐 보입니다. 다음 시간에는 화면이 그려지기 전에 데이터를 부르는 방법을 만듭니다.

지난 시간에 만든 모달 이야기도 아직 안 끝났어요. 열어두고 새로고침하면 사라지는 그 모달이요. 오늘은 주소를 나누는 데까지 왔으니, 다음 시간에 모달이 주소를 가져야 하는지를 그때 배운 것들로 답할 수 있게 됩니다.

과제

[구현] 세 번째 주소 만들기

/about 주소를 만들고 우리 앱을 소개하는 화면을 붙여 보세요.

• routes/AboutPage.tsx를 만들고 주소 표에 자식으로 추가합니다. 내용은 제목 하나와 문단 하나면 충분해요.
• 이 화면에 <main>이나 <header>를 넣어야 할까요? 넣지 말아야 할까요? 결정하고 이유를 한 줄로 적어 주세요.
• 머리말 메뉴에 /about 링크를 추가하세요.
• 주소 표에 자식으로 추가할 때 path를 어떻게 적었는지, 빗금을 붙였는지 안 붙였는지 적어 주세요. 붙여서도 한번 해보고 무슨 일이 생기는지 확인해 보세요.

[구현] 자식을 거느린 주소로 end 재현하기

Step 7의 표 마지막 줄을 직접 재현해 보세요.

• /signup 아래에 /signup/done이라는 자식 주소를 만듭니다. 가입이 끝났다는 화면이라고 생각하면 돼요.
• /signup/done으로 들어간 상태에서 머리말의 회원가입 링크가 켜지는지 확인하고 적어 주세요.
• 그다음 그 링크에 end를 붙이고 다시 확인해 주세요. 무엇이 달라졌나요.
• 둘 중 어느 쪽이 사용자에게 더 자연스러울까요? 정답이 하나가 아닙니다. 여러분의 판단과 이유를 적어 주세요.

[탐구] 재보고 숫자를 적기

각 항목의 결과를 한두 줄씩 적어 주세요. 확인이 끝나면 전부 되돌립니다.

• main.tsx에서 RouterProvider를 react-router에서 가져오도록 바꿔 보세요. 타입 검사와 화면과 콘솔 중 무엇이 문제를 알려주나요? 아무것도 안 알려준다면 그건 무엇을 뜻할까요.
• 라우터를 만드는 줄을 컴포넌트 안으로 옮겨 보세요. 어떤 동작이 망가지는지 직접 눌러가며 찾아 적어 주세요.
• 주소 표에서 index: true를 지우고 대신 path: ''로 바꿔 보세요. 동작이 같나요, 다른가요?
• 네트워크 탭을 열고 기록을 지운 다음 메뉴를 눌러 요청 수를 세어 주세요. 그다음 주소창에 같은 주소를 직접 치고 들어가 다시 세어 주세요. 두 숫자가 왜 다른지 적어 주세요.

생각해볼 주제

1. 주소는 누구를 위한 것일까요

오늘 우리는 주소를 나누면서 "링크로 공유할 수 있다", "뒤로 가기가 된다"를 이득으로 꼽았습니다. 전부 사용자를 위한 것이었죠.

그런데 주소는 개발자에게도 쓰입니다. 오류 보고에 주소가 찍히면 어느 화면에서 터졌는지 바로 알 수 있고, 방문 기록을 모으면 어느 화면을 많이 보는지 알 수 있어요.

그렇다면 화면을 나눌 때 기준이 무엇이어야 할까요. 사용자가 "여기 링크 보내줘"라고 말할 만한 단위일까요, 아니면 개발자가 구분해서 보고 싶은 단위일까요. 둘이 어긋나는 경우를 하나 떠올려 보고, 그때 무엇을 우선할지 생각해 보세요.

2. 도구가 챙겨주는 것을 어디까지 믿어야 할까요

NavLink는 aria-current를 알아서 붙여줬습니다. 편했죠. 그런데 지난 시간에 우리는 아이콘 꾸러미가 낭독기 처리를 챙겨준 반면, 움직임 꾸러미는 동작 줄이기를 전혀 안 본다는 것을 봤습니다.

같은 생태계의 도구인데 챙겨주는 범위가 제각각이에요. 그렇다면 새 라이브러리를 들일 때 "무엇을 안 챙겨주는지"를 어떻게 알아낼 수 있을까요.

문서를 읽는 것으로 충분할까요? 오늘 end 조언처럼 문서 바깥의 통설이 틀린 경우도 있었는데, 그럼 무엇을 근거로 삼아야 할지 생각해 보세요.

3. 상태를 어디에 둘지는 누가 정할까요

Step 5에서 좋아요 개수를 공통 껍데기로 못 올렸습니다. 홈에만 있는 정보였으니까요. 그래서 머리말에서 빠져나와 피드 위로 내려왔어요.

만약 디자이너가 "좋아요 개수는 모든 화면의 머리말에 있어야 한다" 고 요구하면 어떻게 될까요. 그 값은 홈이 들고 있는데 머리말은 Layout이 그립니다.

이럴 때 선택지가 몇 가지 떠오르나요. 각각의 대가는 무엇일까요. 화면 구조와 상태 구조가 어긋날 때 무엇을 먼저 바꿔야 할지 생각해 보세요.