Update: Wikified 129 files from Datacollector_MAC/out_wiki (P-Reinforce v3.0)

10_Wiki/Topics/AI_and_ML/Next.js.md

@@ -1,11 +1,45 @@
 ---
-category: Unified
-tags: [auto-consolidated, technical-documentation]
-title: [[Next.js 기반 대규모 웹 애플리케이션|Next.js 기반 대규모 웹 애플리케이션]]
-last_updated: 2026-05-02
+category: AI_and_ML
+tags: [auto-wikified, technical-documentation, merged, ai_and_ml]
+title: Next.js
+description: "**Next."
+last_updated: 2026-05-04
 ---
 
-# [[Next.js 기반 대규모 웹 애플리케이션|Next.js 기반 대규모 웹 애플리케이션]]
+# Next.js
+
+
+## 📌 Brief Summary
+**Next.js**는 유연한 렌더링 전략(SSR, SSG 등), 내장 API 라우트 및 풀스택 기능을 지원하여 복잡한 애플리케이션의 성능과 확장성을 높여주는 React 기반의 메타 프레임워크입니다 [1, 2]. 특히, **App Router** 아키텍처를 통해 **React Server Components(RSC)**를 선도적으로 도입함으로써 클라이언트로 전송되는 자바스크립트 번들 크기를 줄이고, 데이터 페칭과 UI 렌더링 성능을 획기적으로 최적화하는 데 핵심적인 역할을 하고 있습니다 [3-5].
+
+## 📖 Core Content
+*   **서버 컴포넌트(RSC) 중심의 App Router 아키텍처:**
+    Next.js의 새로운 "app 디렉토리" 내에 있는 라우트와 컴포넌트들은 **기본적으로 서버 컴포넌트**로 동작합니다 [4]. 이는 서버에서만 비동기적으로 실행되어 데이터를 직접 가져오며, 그 결과물을 직렬화된 형태(RSC 페이로드)로 클라이언트에 전달하므로 **자바스크립트 번들 크기에 영향을 주지 않습니다** [6-9].
+*   **클라이언트 컴포넌트와의 경계 설정 및 혼합(Interleaving):**
+    사용자 상호작용(이벤트 핸들러)이나 브라우저 전용 API, 상태(`useState` 등)가 필요한 경우, 최상단에 `"use client"` 지시어를 선언하여 클라이언트 컴포넌트로 만듭니다 [4, 10]. Next.js에서는 클라이언트 컴포넌트 내부에 서버 컴포넌트를 직접 렌더링할 수는 없으나, 서버 컴포넌트를 `children`과 같은 **Prop(직렬화 가능한 속성) 형태로 전달**하여 자연스럽게 중첩(Interleaving)할 수 있습니다 [11, 12].
+*   **스트리밍(Streaming)과 Suspense 통합:**
+    긴 시간이 소요되는 데이터 로딩이 전체 페이지 렌더링을 차단하지 않도록, Next.js는 RSC를 `<Suspense>` 경계와 함께 사용하여 아웃 오브 오더(Out-of-order) 방식의 **스트리밍 렌더링**을 제공합니다 [3, 13]. 서버는 HTML 셸을 먼저 빠르게 보내고, 데이터가 준비되는 대로 나머지 RSC 페이로드를 클라이언트 측에 청크 단위로 스트리밍하여 즉각적인 로딩 UI(Fallback)에서 실제 콘텐츠로 전환합니다 [14-16].
+*   **서버 액션(Server Actions)을 통한 데이터 변이:**
+    `"use server"` 지시어로 정의되는 서버 액션을 사용하면, 클라이언트 컴포넌트의 버튼 클릭 등 이벤트 핸들러에서 직접 서버의 함수를 호출하여 데이터를 업데이트할 수 있습니다 [6, 17, 18]. 이는 클라이언트와 서버 간의 **단일 라운드트립**만으로 네트워크 요청, 데이터베이스 변경, 그리고 `revalidateTag`를 통한 최신 UI의 재검색 및 반영을 완료할 수 있게 해줍니다 [18].
+*   **React-Query 등 외부 라이브러리와의 결합:**
+    서버 액션 및 캐싱 전략만으로는 대응하기 까다로운 다중 폼 상태 관리 및 동적 라우팅 조건에서는 `@tanstack/react-query`의 `useSuspenseQuery` 등과 RSC를 조합하여 초기 데이터는 서버에서 가져오고 후속 인터랙션과 데이터 동기화는 클라이언트에서 효율적으로 관리하는 패턴이 유용하게 사용됩니다 [19-21].
+
+## ⚖️ Trade-offs & Caveats
+*   **서버 액션의 직렬화와 캐시 무효화(revalidateTag) 비용:**
+    서버 액션 내에서 `revalidateTag`를 호출할 경우, 변경된 일부 데이터만 로드되는 것이 아니라 **현재 페이지의 전체 RSC 트리가 다시 렌더링되고 모든 관련 데이터를 다시 요청**하는 비효율이 발생합니다 [22, 23]. 또한, 서버 액션은 직렬(Serial)로만 실행되어 한 번에 하나의 액션만 처리 가능하므로 네트워크 상태가 불량한 상황에서 연속된 호출 시 병목이 발생할 수 있습니다 [24].
+*   **공개 HTTP 엔드포인트로서의 보안 위험 (React2Shell):**
+    `"use server"` 지시어가 붙은 서버 액션은 내부 함수처럼 보이지만 실제로는 **전 세계 누구나 접근할 수 있는 공개 HTTP 엔드포인트**입니다 [25]. 일반적인 API 라우트와 동일한 수준의 입력값 검증과 권한 확인(Sanitization)을 거치지 않으면 **원격 코드 실행(RCE) 등 치명적인 보안 취약점**에 노출될 수 있습니다 [25-27]. 또한, 서버 컴포넌트에서 클라이언트로 넘기는 프로프에 필요 이상의 데이터를 넘기면 브라우저 네트워크 탭에 그대로 노출되므로 데이터 최소화가 필수적입니다 [28].
+*   **복잡도 증가와 에코시스템 종속성:**
+    클라이언트/서버 컴포넌트 간의 혼합과 중첩 사용은 애플리케이션의 **구조적 복잡성**을 크게 높입니다 [29]. 또한, 무분별하게 모든 곳에 `"use client"`를 붙이는 이른바 "Vibe Coding"의 함정에 빠지면 RSC의 혜택인 번들 최적화 효과는 사라지고 구조적 복잡성과 보안 표면만 늘어나게 됩니다 [30, 31]. 현재 RSC를 온전히 프로덕션에 지원하는 프레임워크가 사실상 Next.js(Vercel)에 종속되어 있으며, `emotion`과 같은 **CSS-in-JS 라이브러리와 호환성 문제**가 발생하는 등 기술 부채의 위험도 존재합니다 [32].
+*   **라우팅 동작 시의 불필요한 서버 요청 문제:**
+    클라이언트에서 URL 쿼리 문자열이 변경될 때(`router.push` 사용 시), Next.js는 변경 사항이 없는 RSC 페이지조차 새로 렌더링하도록 동작하여 불필요한 네트워크 대기 시간을 발생시킬 수 있으며, 이를 우회하기 위해 `window.history.pushState`를 사용할 경우 Suspense 전환과 매끄럽게 연동되지 않아 UI 경험이 저하되는 제약이 있습니다 [33, 34]. 
+
+---
+*Last updated: 2026-05-03*
+
+## 📚 Legacy Insights & Additional Context
+> [!NOTE]
+> Below is content merged from previous versions of this documentation.
 
 ## 📌 Brief Summary
 [[Next.js|Next.js]] 기반 대규모 웹 애플리케이션은 비즈니스 로직과 UI를 체계적으로 분리하는 기능 및 도메인 중심(Feature-Driven/Domain-Driven)의 모듈형 아키텍처를 채택하여 장기적인 유지보수성과 확장성을 확보하는 현대적인 웹 개발 방식입니다 [1, 2]. 특히 최근의 Next.js App Router 환경에서는 React Server Components(RSC)와의 호환성 문제로 인해 런타임 오버헤드가 있는 [[CSS-in-JS|CSS-in-JS]] 대신 Tailwind CSS, [[CSS Modules|CSS Modules]], 또는 zero-runtime 방식의 CSS-in-JS([[vanilla-extract|vanilla-extract]] 등)와 같은 정적 스타일링 전략을 선택하는 것이 필수적입니다 [3-5]. 이러한 구조와 스타일링 접근은 팀 간의 협업을 돕고 기술 부채를 최소화하여, 대규모 프로젝트에서도 "예쁘게"가 아닌 "유지보수 가능한" 시스템을 구축할 수 있게 합니다 [1, 5, 6].