URL은 곧 상태입니다

"이 URL 을 남이 클릭했을 때 같은 상태를 봐야 하는가?" 하나로 결정한다. Yes 면 URL, No 면 useState/useReducer/localStorage.

결과적으로 필터·정렬·페이지·탭·날짜 범위는 URL 로, 모달 open/close·드롭다운·입력 중인 폼·스크롤 위치는 로컬 상태로 간다.

react-router-dom 과 Next.js 13+ 의 next/navigation 모두 useSearchParams 훅을 제공한다. 로컬 상태처럼 읽고 쓰되, setter 가 URL 을 바꾸면서 자동 리렌더를 유발한다.

import { useSearchParams } from 'react-router-dom';
// Next.js App Router: import { useSearchParams } from 'next/navigation';

function ProductList() {
  const [params, setParams] = useSearchParams();
  const color = params.get('color') ?? 'all';

  const onChange = (next: string) => {
    setParams((prev) => {
      const p = new URLSearchParams(prev);
      p.set('color', next);
      return p;
    });
  };
  // ...
}

타입 안전·zod 검증·배열 직렬화까지 원하면 nuqs 또는 TanStack Router 의 search 옵션을 쓴다. 기본 API 로도 충분하지만 프로젝트 규모가 커지면 라이브러리 도입 = 타입 계약 추가 로 이해하면 된다.

URL 업데이트 수단 선택은 브라우저 히스토리가 어떻게 쌓여야 하는가로 결정한다.

const update = debounce((q: string) => {
  const p = new URLSearchParams(location.search);
  q ? p.set('q', q) : p.delete('q');
  history.replaceState({}, '', `?${p.toString()}`);
}, 300);

검색어처럼 고빈도 업데이트는 debounce 300ms + replaceState 조합이 정석. popstate 이벤트로 뒤로/앞으로 감지 시 UI 를 URL 과 재동기화해야 한다(프레임워크 라우터는 대개 자동).

잘 설계된 URL 은 상태 컨테이너를 넘어 앱과 사용자 간 계약이 된다. 지켜야 할 규칙:

• 기본값은 URL 에서 생략: ?theme=light&page=1&sort=date → ? (기본값이면 쿼리 비움). 생략된 값은 읽는 쪽 params.get('theme') ?? 'light' 로 채운다.
• 의미 있는 이름: ?p=x7f2k&v=3 대신 ?color=silver&sort=price. 사람과 기계 모두 의도를 읽을 수 있어야 한다.
• 일관된 패턴 고수: 배열을 tags=a,b 로 쓸지 tags[]=a&tags[]=b 로 쓸지 프로젝트 내에서 하나로 고정.
• 민감 정보 금지: URL 은 브라우저 히스토리, 서버 로그, Referer 헤더, 분석 도구로 누출된다. 토큰/비밀번호는 절대 안 된다.
• Base64 JSON 주의: 상태가 너무 커서 인코딩해야 한다면 그건 URL 에 둘 상태가 아니라는 신호.

[감점 답변] "URL 이 좋다" 만 단언하거나 "라이브러리에서 그렇게 하더라" 수준. [좋은 답변] 공유 가능성/새로고침 지속성/뒤로가기 기대/민감도 4축으로 분류한다고 말한다. 필터·정렬·페이지처럼 링크로 공유 가능해야 할 상태는 URL, 모달 열림·드롭다운·입력 중인 폼처럼 세션 내 임시 상태는 useState. 추가로 URL 길이 제한, 고빈도 업데이트 시 replaceState + debounce 같은 트레이드오프까지 언급.

[감점 답변] "리렌더 문제" 로 뭉뚱그림. [좋은 답변] 원인은 setter 에 새 URLSearchParams 인스턴스를 통째로 전달하면서 이전 값을 복사하지 않은 것. 해결은 setParams(prev => { const p = new URLSearchParams(prev); p.set(key, value); return p; }) 로 이전 값을 보존한 뒤 부분 업데이트. 더 나아가 nuqs 같은 타입 안전 라이브러리로 key 별 독립 업데이트를 강제하는 설계도 소개.

[감점 답변] "길이 제한" 만 언급. [좋은 답변] 최소 4가지 축으로 답한다. 1) 민감 정보 누출 — 브라우저 히스토리/서버 로그/Referer 로 새므로 토큰·비번 금지. 2) URL 길이 제한(2~8KB) — base64 JSON 까지 가면 구조를 다시 봐야 함. 3) 히스토리 오염 — 타이핑마다 pushState 하면 뒤로가기가 부서짐. replaceState + debounce. 4) 불명확한 네이밍 — ?x=1&v=2 대신 자기 설명적 이름. 5) 기본값 노출 — 기본값은 생략해 URL 깨끗하게 유지.