<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waylog Blog · Next.js</title>
    <link>https://waylog.pages.dev/category/next-js</link>
    <description>Waylog Blog의 Next.js 카테고리에 속한 글 모음</description>
    <language>ko-KR</language>
    <lastBuildDate>Thu, 21 May 2026 13:50:29 GMT</lastBuildDate>
    <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
    <generator>Next.js</generator>
    <atom:link href="https://waylog.pages.dev/category/next-js/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Next.js Middleware 완전 해부: Edge Runtime 제약·실행 타이밍·프로덕션 패턴 실전 가이드</title>
      <link>https://waylog.pages.dev/posts/nextjs-middleware-edge-runtime-internals</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/nextjs-middleware-edge-runtime-internals</guid>
      <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
      <category>Next.js</category>
      <description>요청이 라우트에 닿기 전에 통제권을 갖는다는 것의 의미 우리 프론트엔드 개발자들이 Next.js 기반 서비스를 프로덕션에서 운영하다 보면 반드시 직면하는 문제들이 있습니다. 인증되지 않은 사용자가 /dashboard에 직접 URL을 입력해 접근하는 순간, 일본에서 접속한 사용자에게 한국어 랜딩 페이지를 노출하는 상황, A/B 실험 코호트를 클라이언트 JavaScript 실행 이후에 분기하면서 레이아웃 시프트가 발생하는 경우. 이 문제들의 공통점은 &quot;요청이 라우트에 닿기 전에 처리했다면 훨씬 깔끔했</description>
    </item>
    <item>
      <title>Next.js Server Actions와 useOptimistic으로 낙관적 UI 구현하기: 폼·뮤테이션·롤백 실전 패턴</title>
      <link>https://waylog.pages.dev/posts/nextjs-server-actions-optimistic-ui-mutation</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/nextjs-server-actions-optimistic-ui-mutation</guid>
      <pubDate>Fri, 20 Mar 2026 00:00:00 GMT</pubDate>
      <category>Next.js</category>
      <description>네트워크 응답을 기다리는 동안, 사용자는 이미 다음 행동으로 넘어간다 우리 프론트엔드 개발자들은 폼 제출 버튼을 누른 후 스피너가 돌아가는 화면을 얼마나 오래 봐왔습니까. 사용자 입장에서는 이미 의도가 확실한 행동을 했는데 UI가 먼저 반응하지 않는 것이 오히려 어색합니다. 낙관적 UI(Optimistic UI)는 이 문제를 다른 방향으로 풉니다. 서버 응답이 오기 전에 요청이 성공했다고 가정하고 UI를 먼저 업데이트한 뒤, 실제로 실패하면 이전 상태로 롤백하는 패턴입니다. Next.js 13 A</description>
    </item>
    <item>
      <title>Next.js PPR(Partial Prerendering) 실전 아키텍처: 정적 셸과 동적 스트림을 한 라우트에서 다루는 설계 전략</title>
      <link>https://waylog.pages.dev/posts/nextjs-ppr-partial-prerendering-static-dynamic-architecture</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/nextjs-ppr-partial-prerendering-static-dynamic-architecture</guid>
      <pubDate>Mon, 08 Dec 2025 00:00:00 GMT</pubDate>
      <category>Next.js</category>
      <description>ISR이 해결하지 못한 빈틈, 그리고 PPR이 채우는 방식 상품 상세 페이지는 전형적인 딜레마의 현장입니다. 상품명, 설명 문구, 카테고리 브레드크럼은 수일 동안 바뀌지 않습니다. SEO 점수를 극대화하려면 이 콘텐츠를 CDN에서 즉시 내려주는 것이 맞습니다. 그러나 같은 페이지에는 실시간 재고 수량, 로그인한 사용자 전용 할인 배너, 방금 달린 리뷰가 공존합니다. ISR(Incremental Static Regeneration)로 이 페이지를 처리하면, 재검증 주기가 60초라도 그 60초 동안 </description>
    </item>
    <item>
      <title>Next.js 14 App Router 도입기: 변화와 적응</title>
      <link>https://waylog.pages.dev/posts/1</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/1</guid>
      <pubDate>Tue, 25 Mar 2025 00:00:00 GMT</pubDate>
      <category>Next.js</category>
      <description>\n\nNext.js 14가 출시되면서 프론트엔드 생태계, 특히 React 기반의 웹 개발 환경은 거대한 지각 변동을 맞이했습니다. App Router의 안정화는 단순한 기능 추가를 넘어, 우리가 웹 애플리케이션을 설계하고 구축하는 방식 자체를 재정의했습니다. 본 포스트에서는 실무 프로젝트를 Pages Router에서 App Router로 마이그레이션하며 겪은 구체적인 경험, 그 과정에서 마주한 난관들, 그리고 이를 통해 얻은 확실한 기술적 이점들을 약 3,000자 분량으로 상세히 회고해보고자 합</description>
    </item>
  </channel>
</rss>
