Next.js App Router가 기본값이 된 지금, 프론트엔드 개발자들이 마주하는 진짜 문제는 '무엇을 쓸 것인가'가 아니라 '어디에 무엇을 두어야 하는가'의 경계 설정이다. 서버 컴포넌트와 클라이언트 컴포넌트가 같은 트리 안에 공존하는 이 환경에서, 상태관리 전략과 디버깅 방법론, 그리고 AI 에이전트가 코드베이스를 읽는 방식까지—설계 결정 하나하나가 이전보다 훨씬 직접적으로 성능과 유지보수성에 영향을 미친다.
기준 1: 상태는 '크기'가 아니라 '변경 빈도'로 나눠라
dev.to에 올라온 실전 사례 분석을 보면, App Router 환경에서 React Context가 문제가 되는 지점은 명확하다. Context는 값이 바뀌면 그것을 구독하는 모든 컴포넌트를 재렌더링한다. 사용자 세션과 알림 목록을 같은 Context에 묶어두면, 새 알림이 하나 도착할 때마다 사용자 이름을 보여주는 헤더까지 다시 그려진다. 규모가 작을 땐 무시할 수 있지만, 앱이 복잡해질수록 이 비용은 조용히 쌓인다.
Zustand가 이 문제를 해결하는 방식은 단순하다—셀렉터 기반 구독이다. useUserStore((state) => state.user) 처럼 필요한 조각만 구독하면, 알림 상태가 바뀌어도 Header는 재렌더링되지 않는다. 전환 비용도 낮다. 기존 Context의 값 형태를 그대로 store로 옮기고, useContext(MyContext)를 useMyStore(selector)로 교체하면 대부분의 마이그레이션이 완료된다. 체감상 한 시간 내외의 작업이다.
그렇다고 Context가 쓸모없다는 뜻은 아니다. 테마 설정처럼 앱 초기화 시점에 한 번 세팅되고 거의 바뀌지 않는 값, React Query나 React Router처럼 라이브러리가 직접 제공하는 Context 기반 API—이런 경우엔 Context가 더 자연스럽다. 판단 기준은 간단하다: useMemo나 useCallback을 Context 재렌더링을 막기 위해 추가하고 있다면, 그건 Zustand로 이동할 신호다.
App Router 맥락에서 중요한 건 서버-클라이언트 경계다. Zustand는 클라이언트 전용이다. 서버 컴포넌트에서 fetch한 초기 데이터는 props로 클라이언트 컴포넌트에 내려주고, UI 인터랙션 상태만 Zustand로 관리하는 패턴이 가장 깔끔하다. 서버 데이터는 props, 클라이언트 UI 상태는 store—이 분리선을 명확히 긋는 것이 App Router 시대 상태관리의 핵심이다.
기준 2: 디버깅은 '수정'이 아니라 '관찰'에서 시작한다
dev.to의 React 디버깅 가이드가 대화 형식을 빌려 전달하는 메시지는 사실 하나다—패닉 상태에서 코드를 바꾸는 것은 디버깅이 아니라 버그 추가다. '샷건 디버깅'이라 불리는 이 패턴, 즉 뭔가 바꾸면 고쳐질 것 같아서 빠르게 여러 곳을 수정하는 방식은 10분짜리 버그를 3시간짜리로 만드는 가장 확실한 방법이다.
대신 먼저 할 일은 재현 조건을 정밀하게 좁히는 것이다. '결제 화면이 이상해요'는 재현이 아니다. '주문 편집 후 목록으로 돌아오면 해당 주문의 금액이 새로고침 전까지 이전 값으로 표시된다'—이게 재현이다. 이 한 문장이 원인의 절반을 알려준다. 초기 로드 문제가 아니라 데이터 흐름 문제라는 것, 계산 로직이 아니라 상태 업데이트 전파 경로가 문제라는 것.
재현 조건이 확보되면, React DevTools의 Components 탭을 X선처럼 쓴다. 의심되는 컴포넌트를 클릭하면 현재 props와 state가 실시간으로 보인다. 'Mark Paid' 버튼을 누른 후 props 패널이 갱신되지 않는다면, 버그는 그 컴포넌트 안이 아니라 데이터를 내려주는 상위 레이어에 있다. 컴포넌트 자체는 무죄이고, 용의자는 캐시 또는 부모 컴포넌트로 좁혀진다. console.log 한 줄 없이 30초 안에 나오는 결론이다.
Profiler 탭은 한 단계 더 깊이 들어간다. '지금 이 상태'가 아니라 '시간에 따라 무슨 일이 일어났는가'를 플레임 그래프로 보여준다. 업데이트 후 특정 컴포넌트가 재렌더링되지 않았다면, DevTools는 그 이유를 직접 알려준다—'props did not change'. 이 한 마디가 원인을 컴포넌트 내부가 아니라 props를 전달하는 구조 문제로 확정짓는다. 관찰이 추측을 대체하는 순간이다.
기준 3: 코드베이스는 AI 에이전트도 읽는다
세 번째 기준은 아직 많은 팀이 놓치고 있는 부분이다. 우리가 짜는 코드와 문서를 이제는 사람만 읽지 않는다. Cursor 같은 AI 코딩 도구와 에이전트들이 프로젝트 구조와 문서를 컨텍스트로 소비한다. 여기서 llms.txt 제안이 등장한다.
llmstxt.org가 제안하는 이 컨벤션은 사이트나 프로젝트의 루트에 AI를 위한 간결한 진입점을 두는 것이다. robots.txt가 크롤러에게 규칙을 알려주듯, llms.txt는 AI 에이전트에게 이 프로젝트의 핵심 구조와 중요 링크를 효율적으로 전달한다. 불필요한 네비게이션 HTML, 푸터, 스타일 정보로 컨텍스트 윈도우를 낭비하는 대신, 에이전트가 실제로 필요한 정보만 압축해서 담는다.
아직 표준이 아니고 채택률도 고르지 않다. 하지만 Google이 2025년 Lighthouse의 새 Agentic Browsing 카테고리에 이 신호를 추가했다는 점, Cursor를 포함한 코딩 도구들이 라이브러리 문서 조회 시 이를 참조하기 시작했다는 점은 무시하기 어렵다. 중요한 건 llms.txt가 robots.txt나 sitemap.xml을 대체하는 게 아니라는 점이다—셋을 함께 쓸 때 에이전트가 프로젝트를 제대로 이해한다.
세 기준이 가리키는 하나의 방향
상태관리 경계 설정, 관찰 기반 디버깅, AI 에이전트 접근성—이 세 기준은 겉보기엔 별개 주제다. 그러나 공통적으로 가리키는 방향이 있다. '누가 이것을 읽고 실행하는가'에 대한 명확한 의식이다.
Zustand의 셀렉터 패턴은 컴포넌트가 자신에게 필요한 상태만 구독하게 한다. React DevTools 기반 디버깅은 가정 대신 실제 데이터 흐름을 관찰하게 한다. llms.txt는 AI 에이전트가 프로젝트 구조를 효율적으로 파악하게 한다. 세 가지 모두 '소비자의 관점에서 구조를 설계하는 것'의 다른 표현이다. App Router가 서버와 클라이언트의 경계를 명시적으로 요구하듯, 지금의 프론트엔드 설계는 코드를 실행하고 읽는 모든 주체—브라우저, 개발자, AI 에이전트—를 동시에 고려하는 방향으로 이동하고 있다.