Navigation API - 더 나은 탐색 방식, 이제 Baseline Newly Available로 출시

10년이 넘는 시간 동안 우리는 Single Page Applications (SPAs)를 구축하기 위해 window.history에 의존해 왔으며, 동시에 그에 대해 불만을 가져왔습니다. 그 이유는 무엇일까요? 그것은 처음부터 SPAs를 위해 설계되지 않았기 때문입니다. 매끄러운 경험을 제공하기 위해, SPAs는 뒤로 가기 및 앞으로 가기 버튼을 지원하도록 브라우저의 히스토리에 수동으로 접근함으로써 표준 멀티 페이지 탐색 (multi-page navigation)을 모방해야만 했습니다.

History API가 이러한 고충 중 일부를 완화해주었지만, 모든 다양한 유형의 탐색 트리거 (navigation triggers)를 감지할 수 없다는 등의 자체적인 단점도 있었습니다. 다른 주목할 만한 제한 사항으로는 전체 히스토리 스택 (history stack)을 읽을 수 없거나, 현재 항목이 아닌 엔트리를 편집할 수 없다는 점 등이 있습니다. 또한 popstate 이벤트는 일관성 없게 동작하며, pushState 또는 replaceState가 프로그래밍 방식으로 호출될 때는 트리거되지 않습니다.

그 시대는 이제 끝납니다. Navigation API가 등장했으며, 2026년 초를 기점으로 모든 주요 브라우저에서 드디어 Baseline Newly available 상태가 됩니다.

병렬 비교

차이점을 설명하기 위해, 이 섹션에서는 기존에 클라이언트 사이드 라우팅 (client-side routing)을 처리하던 방식과 Navigation API를 통해 지원되는 새롭고 간소화된 접근 방식을 비교합니다.

기존 방식

// 1. 프로그래밍 방식으로 탐색하는 함수
function navigate(path) {
// 페이지 새로고침 없이 URL 업데이트
...

Navigation API의 작동 방식

// 1. 모든 탐색에 대한 하나의 중앙 리스너
// 이는 링크, 뒤로 가기/앞으로 가기 버튼, 그리고 프로그래밍 방식 호출을 모두 포착합니다
navigation.addEventListener('navigate', (event) => {
...

History API로 라우터 (router)를 구축하는 것은 마치 퍼즐을 맞추는 것처럼 느껴졌습니다. 왜냐하면 다음과 같은 작업들을 수행해야 했기 때문입니다:

• <a 태그에 대한 클릭을 전역적으로 리스닝 (Listen) 해야 함.
• 해당 클릭에 대해 preventDefault()를 호출해야 함.
• 수동으로 history.pushState()를 호출해야 함.
• 수동으로 DOM을 업데이트해야 함.
• 뒤로 가기/앞으로 가기 버튼을 처리하기 위해 popstate 이벤트를 별도로 리스닝해야 함.

만약 하나의 예외 케이스 (edge case)라도 처리하는 것을 잊었다면, 사용자는 실수로 잘못된 뷰 (view)에 도달할 수 있었으며, 이는 해당 방식의 취약성을 드러냈습니다.

Navigation API는 이 과정을 획기적으로 단순화합니다. 사용자가 링크를 클릭하거나, 폼 (form)을 제출하거나, 뒤로 가기 버튼을 누르거나, 혹은 코드에서 navigation.navigate()를 호출하는 등 모든 탐색 (navigation)에 대해 단일화되고 중앙 집중화된 NavigateEvent를 제공합니다.

event.intercept() 함수는 여러분을 대신해 많은 복잡한 작업을 처리합니다:

자동 URL 업데이트: pushState를 호출할 필요 없이 주소창과 히스토리 스택 (history stack)의 업데이트를 처리합니다.
자동 접근성 (accessibility): 포커스 관리 (탐색 후 포커스 복구)와 같은 접근성 기본 요소 (accessibility primitives)를 자동으로 처리합니다.
중앙 집중식 로직: 뒤로 가기 버튼과 클릭 이벤트를 정확히 동일한 함수에서 처리합니다.

추가적인 사용 사례

이 섹션에서는 Navigation API를 활용할 수 있는 더 많은 방법을 강조하기 위해 몇 가지 예시를 더 살펴봅니다.

예시: 폼 제출 처리하기

navigate 이벤트는 동일 문서 내의 모든 폼 제출을 자동으로 포착하며, 데이터에 접근할 수 있도록 NavigateEvent.formData 속성을 제공합니다.

이 예시는 표준 HTML 폼 제출을 포착하고, 페이지 새로고침을 방지하며, 데이터를 비동기적으로 처리합니다.

// 1. 하나의 중앙 리스너가 링크와 폼을 모두 처리합니다
navigation.addEventListener('navigate', (event) => {
// 이 블록에서는 폼 POST 제출만 처리합니다
...

예시: 비동기 스크롤 처리하기

Navigation API에서 event.scroll()은 탐색 중에 브라우저가 언제 스크롤 위치를 복구할지에 대해 수동 제어권을 부여합니다.

기본적으로 브라우저는 event.intercept()가 호출되는 즉시 스크롤 위치를 복구하려고 시도합니다. 하지만 현대적인 SPA (Single Page Application)에서는 콘텐츠가 아직 준비되지 않은 경우가 많습니다 (API 응답을 기다리고 있을 수 있습니다). 만약 콘텐츠가 렌더링되기 전에 브라우저가 스크롤을 수행하면, 잘못된 위치에 도달하거나 맨 위에 머물게 됩니다.

사용자가 긴 아이템 목록으로 돌아가기 위해 뒤로 가기 버튼을 클릭한다고 가정해 봅시다. 페이지가 끝까지 내려갈 수 있을 만큼 길어지기 전에 해당 아이템들을 먼저 가져와야(fetch) 할 것입니다.

navigation.addEventListener('navigate', (event) => {
if (!event.canIntercept) return;
event.intercept({
...

예시: 뷰 전환 (View Transitions) 활성화

Navigation API와 View Transitions API는 SPA(Single Page Application)에서 매끄러운 "앱 같은" 전환을 만들기 위해 함께 작동하도록 설계되었습니다.

탐색 이벤트(navigation event)를 가로챌(intercept) 때, DOM 업데이트를 document.startViewTransition()으로 감쌀 수 있습니다. 이는 브라우저에게 "이전" 상태의 스냅샷을 캡처하고, 필요한 DOM 변경을 수행한 다음, "새로운" 상태로 애니메이션을 실행하도록 지시합니다. 이를 통해 앱 같은 전환을 지원할 수 있습니다!

navigation.addEventListener('navigate', (event) => {
if (!event.canIntercept) return;
const url = new URL(event.destination.url);
...

요약

앞선 예시들에서 보았듯이, Navigation API는 많은 웹 개발자들에게 오랜 고충이었던 SPA 탐색의 깊은 구조적 문제들을 해결합니다. 이 API는 내장되어 있고 안전하며, 예외 케이스(edge cases)를 견고하게 처리합니다.

2026년 초 기준으로 Safari와 Firefox에서도 지원이 시작됨에 따라, Navigation API는 본격적인 사용(prime time)을 위한 준비를 마쳤습니다. 이는 우리가 항상 원했던 라우터(router)입니다. 단순하고, 강력하며, 현대적인 웹을 위해 구축되었습니다.