<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waylog Blog · React</title>
    <link>https://waylog.pages.dev/category/react</link>
    <description>Waylog Blog의 React 카테고리에 속한 글 모음</description>
    <language>ko-KR</language>
    <lastBuildDate>Thu, 21 May 2026 13:50:29 GMT</lastBuildDate>
    <pubDate>Fri, 20 Feb 2026 00:00:00 GMT</pubDate>
    <generator>Next.js</generator>
    <atom:link href="https://waylog.pages.dev/category/react/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>React Error Boundary와 Suspense 실전 패턴: 에러·로딩 상태를 선언적으로 다루는 컴포넌트 설계</title>
      <link>https://waylog.pages.dev/posts/react-error-boundary-suspense-fallback-patterns</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/react-error-boundary-suspense-fallback-patterns</guid>
      <pubDate>Fri, 20 Feb 2026 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>에러는 피하는 것이 아니라 설계하는 것이다 React 애플리케이션을 운영하다 보면 반드시 마주치는 순간이 있습니다. 서드파티 API가 갑자기 응답을 거부하고, 예상치 못한 형태의 데이터가 렌더 함수 안으로 흘러들어 오고, 네트워크가 불안정한 모바일 환경에서 Suspense로 감싼 컴포넌트가 영영 해소되지 않는 상황입니다. 우리 팀이 MAU 30만 규모의 여행 예약 플랫폼을 운영하면서 가장 뼈아프게 배운 것은 바로 이것이었습니다. 에러는 try/catch로 모두 잡아낼 수 있다는 낙관, 그리고 로딩</description>
    </item>
    <item>
      <title>React useTransition과 Concurrent 렌더링 실전: Suspense, Deferring, Scheduler 우선순위를 코드로 이해하기</title>
      <link>https://waylog.pages.dev/posts/react-use-transition-concurrent-rendering-patterns</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/react-use-transition-concurrent-rendering-patterns</guid>
      <pubDate>Wed, 31 Dec 2025 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>메인 스레드가 막히는 순간, UI는 사용자를 배신한다 React 애플리케이션에서 &quot;왜 필터를 클릭했는데 선택이 늦게 반영되지?&quot;라는 질문을 받아본 적이 있을 것입니다. 우리 팀은 수십만 건의 거래 내역을 보여주는 어드민 대시보드를 운영하면서 정확히 이 문제를 마주했습니다. 날짜 범위 피커를 선택할 때마다 선택 UI 자체가 200ms 이상 굳어버렸고, 사용자들은 자신의 클릭이 먹혔는지조차 알 수 없었습니다. React 18 이전 세계에서 해결책은 제한적이었습니다. debounce로 무거운 계산을 늦</description>
    </item>
    <item>
      <title>React 서버 컴포넌트(RSC) 시대의 상태 관리와 성능 최적화 대전망</title>
      <link>https://waylog.pages.dev/posts/react-server-components-guide</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/react-server-components-guide</guid>
      <pubDate>Wed, 16 Apr 2025 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>React 서버 컴포넌트(RSC) 시대의 상태 관리와 성능 최적화 대전망 프론트엔드 생태계는 늘 격변의 중심에 서 있습니다. 그 중에서도 React 18과 Next.js App Router가 불러온 React Server Components (RSC)의 도입은, 그동안 클라이언트 단에 쏠려 있던 렌더링과 상태 관리의 무게중심을 서버 쪽으로 강력하게 되돌려 놓은 패러다임 시프트입니다. RSC가 보편화된 시대에 프론트엔드 개발자들은 어떻게 상태(State)를 관리하고 애플리케이션의 성능을 최적화해야 </description>
    </item>
    <item>
      <title>Zustand: Redux의 독재를 끝낼 가벼운 영웅</title>
      <link>https://waylog.pages.dev/posts/3</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/3</guid>
      <pubDate>Wed, 12 Mar 2025 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>\n\nReact 생태계에서 &quot;상태 관리(State Management)&quot;는 언제나 뜨거운 감자였습니다. 오랫동안 Redux가 사실상의 표준(De facto standard)으로 군림했지만, 과도한 보일러플레이트 코드와 복잡한 설정은 개발자들을 지치게 만들었습니다. Context API, Recoil, Jotai, MobX 등 수많은 도전자들이 나타났지만, 최근 가장 가파른 성장세를 보이며 개발자들의 마음을 사로잡은 라이브러리가 있습니다. 바로 Zustand입니다. 독일어로 &quot;상태&quot;를 뜻하는 이 </description>
    </item>
    <item>
      <title>Next.js 15 미리보기: 서버 컴포넌트의 진화와 하이드레이션</title>
      <link>https://waylog.pages.dev/posts/54</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/54</guid>
      <pubDate>Sun, 02 Feb 2025 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>웹 개발의 표준을 이끌어가고 있는 Next.js가 또 한 번의 도약을 준비하고 있습니다. Next.js 15(가칭)에서 기대되는 변화들은 단순히 성능을 조금 올리는 수준이 아니라, 우리가 생각하는 &quot;서버 사이드 렌더링&quot;의 개념을 한 단계 더 확장시킬 것입니다. 특히 React 19의 정식 릴리즈와 맞물려 더욱 강력해질 서버 액션(Server Actions)과 부분적 사전 렌더링(Partial Prerendering, PPR)에 대해 심층 분석해 봅니다. 1. 컴파일러의 혁신: Turbopack의 </description>
    </item>
    <item>
      <title>React Server Components(RSC) 아키텍처 깊게 파헤치기: Next.js App Router의 내부 동작 원리와 네트워크 성능 최적화</title>
      <link>https://waylog.pages.dev/posts/react-server-components-architecture</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/react-server-components-architecture</guid>
      <pubDate>Sun, 03 Nov 2024 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>React Server Components(RSC) 아키텍처: 단순한 기능 추가를 넘어서는 웹 렌더링의 패러다임 시프트 2024년 이후 프론트엔드 개발 생태계에서 가장 뜨거운 감자는 단연 React Server Components(RSC)와 Next.js App Router입니다. 우리는 그동안 브라우저(클라이언트)에서 모든 것을 처리하던 Single Page Application(SPA)의 시대에 익숙해져 있었습니다. 하지만 RSC는 이 관성을 완전히 뒤집어 놓았습니다. 많은 개발자가 RSC를 </description>
    </item>
    <item>
      <title>2026년 모던 React 상태 관리 생태계 완벽 분석: Redux를 넘어 Zustand, Jotai, Recoil까지</title>
      <link>https://waylog.pages.dev/posts/modern-react-state-management</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/modern-react-state-management</guid>
      <pubDate>Mon, 28 Oct 2024 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>모던 React 상태 관리: Redux의 시대를 넘어선 새로운 패러다임 React 개발에서 &quot;상태 관리(State Management)&quot;는 영원한 화두입니다. 2015년 Dan Abramov가 Redux를 세상에 내놓은 이후, 프론트엔드 생태계는 사실상 Redux의 독주 체제였습니다. Flux 아키텍처에 기반한 단방향 데이터 흐름, 예측 가능한 상태 변화, 그리고 강력한 DevTools는 대규모 애플리케이션의 복잡성을 길들이는 데 혁명적인 역할을 했습니다. 하지만 2024년을 넘어 2026년 현재</description>
    </item>
    <item>
      <title>React 서버 상태 관리 실전: Query Cache, Mutation, Invalidation으로 화면 데이터 일관성 지키기</title>
      <link>https://waylog.pages.dev/posts/react-query-server-state-cache-invalidation</link>
      <guid isPermaLink="true">https://waylog.pages.dev/posts/react-query-server-state-cache-invalidation</guid>
      <pubDate>Mon, 16 Sep 2024 00:00:00 GMT</pubDate>
      <category>React</category>
      <description>서버 상태는 클라이언트 상태와 다르다 React 애플리케이션에서 상태 관리를 이야기하면 전역 store부터 떠올리기 쉽습니다. 하지만 화면에 보이는 데이터 중 상당수는 클라이언트가 소유한 상태가 아닙니다. 사용자 목록, 주문 상태, 알림 개수, 결제 내역은 서버가 진짜 소스입니다. 클라이언트는 그 시점의 스냅샷을 잠시 들고 있을 뿐입니다. 서버 상태를 일반 전역 store에 넣으면 곧 문제가 생깁니다. 언제 다시 가져와야 하는지, 여러 화면에서 같은 요청을 중복으로 보내지 않는지, mutation</description>
    </item>
  </channel>
</rss>
