hmk run dev

Next.js 14의 App Router 환경에서는 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR), 정적 생성(SSG), ISR 등 다양한 렌더링 방식을 상황에 맞게 조합할 수 있다. 특히 App Router는 서버 컴포넌트와 클라이언트 컴포넌트를 구분하고, 내장 fetch의 캐시 전략과 메타데이터 설정이 유연해지면서 SEO 대응 방식도 훨씬 정교해졌다. 그중 하나가 searchParams 기반 SSR이다. 기존의 다이나믹 라우트 방식과 달리, URL의 query string을 기반으로 서버에서 데이터를 받아 페이지를 렌더링하는 방식이다. 이 방식은 필터형 상품 페이지나 SKU 조합 페이지에서 매우 유용하다. 하지만 SEO 관점에서 보면 몇 가지 주의할 점이 있다. 렌더링 방식별 SEO..

Next.js는 다양한 렌더링 방식을 제공합니다. 정적 생성(SSG), 서버 사이드 렌더링(SSR), 클라이언트 사이드 렌더링(CSR), 그리고 점진적 정적 생성(ISR)까지 다양한 전략이 가능하죠. 버전이 14에 도달하면서 App Router가 정식화되었고, fetch() 내장, cache, revalidate, searchParams, server/client component 분리 등 보다 유연한 방식으로 구성할 수 있게 되었습니다.하지만 기능이 다양해진 만큼 "어떤 상황에서 어떤 렌더링 방식을 선택해야 하는지"는 더욱 고민되는 지점입니다. 특히 실무에서 많이 마주치는 SKU 기반 조합 페이지나, 필터형 검색 결과 페이지 등에서는 의사결정이 쉽지 않습니다.이번 글에서는 실제 사례를 중심으로, 어떤 ..

Next.js 프로젝트에서 백엔드 API와 통신할 때, 우리는 종종 브라우저 또는 서버(SSR/API 라우트 등)에서 외부 서버로 HTTP 요청을 보냅니다. 이때 성능 최적화를 고려한다면 "keep-alive" 설정을 살펴볼 필요가 있습니다. 브라우저에서 keep-alive는 어떻게 작동할까?서버 → 서버 요청에서는 왜 명시적으로 설정이 필요할까?실제로 어떻게 적용할 수 있을까? HTTP keep-alive란?기본적으로 HTTP 요청은 다음 흐름을 따릅니다:연결 열기 → 요청 보내기 → 응답 받기 → 연결 닫기이런 구조는 요청마다 새로운 TCP 연결을 만들고 끊는 비효율을 초래합니다. 특히, 서버 → 서버 간에 수백~수천 개의 API 호출이 일어난다면 이 비용은 무시할 수 없습니다.keep-alive는 ..