feat: massive wikification of styling systems and SaaS architecture
Processed 100+ files including Design Systems, CSS Architectures, and Enterprise Frontend strategies.
This commit is contained in:
Antigravity Agent
@@ -1,18 +1,20 @@
|
||||
# [[Next.js App Router]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Next.js App Router는 Next.js 13 버전 이상부터 도입된 새로운 아키텍처로, 클라이언트 측 JavaScript 코드를 줄이기 위한 새로운 접근 방식을 제공합니다 [1]. 이 환경에서는 페이지와 레이아웃이 기본적으로 서버에서 렌더링되며 [2], 상호작용이 필요 없는 정적 컴포넌트의 경우 하이드레이션(Hydration) 과정 자체를 제거하여 성능을 최적화할 수 있습니다 [3].
|
||||
Next.js App Router는 향상된 레이아웃 중첩(nesting)과 관심사 분리(separation of concerns)를 가능하게 하는 Next.js의 라우팅 구조입니다 [1]. 브라우저가 아닌 서버에서 실행되어 HTML을 스트리밍하는 React Server Components(RSC)를 활용하며 [2], 대규모 프론트엔드 프로젝트의 유지보수성을 높이기 위해서는 App Router에 최적화된 폴더 아키텍처 설계와 RSC에 호환되는 CSS 스타일링 전략의 선택이 필수적입니다 [3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
- **기본 서버 컴포넌트(Default Server Components) 적용:** Next.js App Router를 사용하면 애플리케이션의 페이지(Pages)와 레이아웃(Layouts)이 기본적으로 React Server Components로 동작합니다 [2]. 이를 통해 해당 영역의 코드가 클라이언트 브라우저에서 실행되지 않게 되므로, 브라우저가 다운로드해야 하는 JavaScript 페이로드를 완전히 줄일 수 있습니다 [1, 3].
|
||||
- **단순화된 데이터 페칭:** App Router 환경에서는 비동기(async) 컴포넌트 내에서의 데이터 페칭(Data fetching) 기능이 별도의 추가 설정 없이 기본적으로(out of the box) 지원됩니다 [2].
|
||||
- **명시적인 클라이언트 컴포넌트 사용:** 버튼이나 폼과 같은 상호작용(Interactivity)이 필요한 부분은 파일 최상단에 `"use client"` 지시어를 선언하여 클라이언트 컴포넌트로 만들어야 합니다 [2]. App Router 환경에서 클라이언트 컴포넌트를 사용할 때는 하이드레이션 오버헤드를 줄이기 위해 코드 스플리팅(Code splitting), 트리 쉐이킹(Tree-shaking) 등을 통해 컴포넌트 번들 크기를 최소화하는 것이 필수적입니다 [4].
|
||||
- *참고: Next.js App Router의 디렉토리 구조, 중첩 라우팅 메커니즘 등 라우터 자체의 동작 원리에 대한 구체적인 세부 사항은 제공된 소스에 관련 정보가 부족합니다. 현재 소스는 주로 렌더링 및 하이드레이션 성능 관점에서의 App Router 활용에 집중되어 있습니다.*
|
||||
- **스타일링 호환성 및 RSC 문제 (The RSC Problem)**
|
||||
Next.js App Router는 서버에서 실행되는 React Server Components(RSC)를 근간으로 합니다 [2]. 이 때문에 React Context에 의존하여 런타임에 스타일을 생성하는 기존의 CSS-in-JS 라이브러리(예: styled-components, Emotion)는 App Router 환경과 근본적으로 호환되지 않습니다 [2, 3]. 따라서 2025년 기준 App Router를 사용하는 프로젝트에서는 런타임 오버헤드가 없는 **Tailwind CSS**, **CSS Modules**, 또는 빌드 타임에 정적 CSS를 생성하는 **vanilla-extract**(zero-runtime CSS-in-JS)를 사용하는 것이 적극적으로 권장됩니다 [5, 6].
|
||||
- **유지보수를 위한 확장 가능한 아키텍처 (Scalable Project Structure)**
|
||||
App Router를 도입할 때 흔히 발생하는 실수는 `app/` 디렉토리 내에 라우트와 함께 모든 컴포넌트, 훅(hooks), 비즈니스 로직을 혼재시키는 것입니다 [4]. 애플리케이션이 복잡해질수록 이러한 구조는 관리가 불가능해지므로, `app/` 폴더(`page.tsx`, `layout.tsx` 등)는 라우팅과 레이아웃을 처리하는 목적으로만 단순하게 유지해야 합니다 [7, 8].
|
||||
- **기능 주도 개발 (Feature-Driven Architecture) 적용**
|
||||
파일들을 단순히 유형별(components, hooks, utils 등)로 묶는 대신, 비즈니스 기능이나 도메인 단위로 그룹화하는 기능 주도 아키텍처(Feature-Based Architecture)를 적용해야 확장에 유리합니다 [1, 4, 7]. 실제 비즈니스 로직과 UI 컴포넌트는 `src/features/`와 같은 디렉토리로 분리하고 [8], 데이터 패칭(API)과 비즈니스 로직을 UI 프레젠테이션 파일과 철저히 분리함으로써 안전한 리팩토링과 협업을 가능하게 해야 합니다 [1, 8].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[React Server Components]], [[Client Components]], [[Hydration]]
|
||||
- **Projects/Contexts:** [[Next.js 13+]]
|
||||
- **Contradictions/Notes:** 제공된 소스는 App Router를 React Server Components 및 하이드레이션 최적화의 맥락에서만 설명하고 있으며, 파일 시스템 기반의 라우팅 구조나 캐싱 메커니즘 전반에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
- **Related Topics:** [[React Server Components]], [[CSS Modules]], [[Tailwind CSS]], [[Feature-Driven Architecture]]
|
||||
- **Projects/Contexts:** [[확장 가능한 프론트엔드 아키텍처 및 폴더 구조 설계]], [[대규모 앱의 유지보수를 위한 모던 CSS 도구 도입]]
|
||||
- **Contradictions/Notes:** 런타임 CSS-in-JS(예: styled-components)는 기존 Pages Router 기반의 프로젝트에서는 문제없이 작동하지만, App Router로 마이그레이션할 경우 서버 컴포넌트 구조와의 충돌로 인해 동작하지 않으므로 Tailwind CSS, CSS Modules 또는 vanilla-extract 등으로 마이그레이션을 계획해야 합니다 [6].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
*Last updated: 2026-04-26*
|
||||
Reference in New Issue
Block a user