chore: update graph view scale and set workspace default tab to graph view
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,119 @@
|
||||
---
|
||||
id: "wiki-2026-0507-103"
|
||||
title: "현대적_프론트엔드_아키텍처_및_상태_관리"
|
||||
category: "[[10_Wiki/Topics]]"
|
||||
status: "verified"
|
||||
canonical_id: "self"
|
||||
aliases: ["Frontend Architecture", "Modern Frontend", "State Management", "FSD", "Feature-Sliced Design", "React Patterns", "Next.js Architecture", "상태 관리", "프론트엔드 아키텍처"]
|
||||
duplicate_of: "none"
|
||||
source_trust_level: "A"
|
||||
confidence_score: 1.0
|
||||
tags: ["Frontend", "React", "Next.js", "Architecture", "State Management", "FSD"]
|
||||
raw_sources: ["Frontend_Architecture.md", "FSD (Feature-Sliced Design).md", "React Component Patterns.md", "Modern React Architecture.md"]
|
||||
last_reinforced: "2026-05-07"
|
||||
github_commit: "pending"
|
||||
---
|
||||
|
||||
# 현대적_프론트엔드_아키텍처_및_상태_관리
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "UI는 상태의 함수다 ($UI = f(State)$)." 단순한 화면 구성을 넘어, 복잡한 상태의 흐름을 예측 가능하게 통제하고(State Management), 비즈니스 로직과 UI를 물리적으로 격리하여(FSD), 사용자에게 초저지연의 지능형 경험을 제공하는 설계의 정점.
|
||||
|
||||
---
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> 현대 프론트엔드는 **'컴포넌트 기반 설계(CDD)'**와 **'기능 중심 아키텍처(FSD)'**를 결합하여 거대해진 코드베이스의 복잡성을 관리한다. 특히 서버 사이드와 클라이언트 사이드의 경계가 모호해지는 React Server Components(RSC) 환경에서, 상태의 위치와 렌더링 전략을 최적화하는 것이 핵심이다.
|
||||
|
||||
**세부 내용:**
|
||||
|
||||
### 1. 기능 중심 아키텍처: FSD (Feature-Sliced Design)
|
||||
- **계층 구조 (Layers):** 하위 계층은 상위 계층을 참조할 수 없는 엄격한 단방향 의존성 유지.
|
||||
- **App:** 전역 설정 (Providers, Styles).
|
||||
- **Processes:** 다단계 워크플로우 (Legacy 지향).
|
||||
- **Pages:** 애플리케이션의 화면 단위.
|
||||
- **Widgets:** 여러 기능을 조합한 독립적 UI 블록.
|
||||
- **Features:** 사용자 가치를 제공하는 비즈니스 기능 (예: '장바구니 담기').
|
||||
- **Entities:** 비즈니스 엔티티 (예: '상품', '사용자').
|
||||
- **Shared:** 재사용 가능한 범용 컴포넌트 및 유틸리티.
|
||||
|
||||
### 2. 컴포넌트 설계 패턴
|
||||
- **컴포넌트 합성 (Composition):** 작은 컴포넌트를 조합하여 복잡한 UI 구축 (Ant-Design, Headless UI의 핵심).
|
||||
- **Compound Components:** 상태를 공유하는 부모-자식 관계 (예: `Select`, `Option`).
|
||||
- **Hooks Pattern:** 로직을 재사용 가능한 단위로 캡슐화하여 UI와 완전히 분리.
|
||||
- **Headless UI:** UI 로직(상태, 접근성)만 제공하고 스타일은 사용자에게 위임.
|
||||
|
||||
### 3. 상태 관리 전략 (Layered State)
|
||||
- **Local State:** `useState`, `useReducer`. 컴포넌트 내부의 국소적 상태.
|
||||
- **Server State:** TanStack Query, SWR. 비동기 데이터 패칭, 캐싱, 동기화 전용.
|
||||
- **Global State:** Zustand, Redux Toolkit, Jotai. 애플리케이션 전반에서 공유되는 UI 상태.
|
||||
- **URL State:** `react-router`, `next/navigation`. 필터, 검색어 등 공유 가능한 상태.
|
||||
|
||||
### 4. 현대적 렌더링 전략
|
||||
- **RSC (React Server Components):** 서버에서 데이터를 직접 조회하고 렌더링하여 클라이언트 번들 크기 최소화.
|
||||
- **Hydration 최적화:** 필요한 부분만 자바스크립트를 로드하는 Islands Architecture.
|
||||
- **점진적 정적 재생성 (ISR):** 정적 페이지의 장점과 실시간 데이터 업데이트의 결합.
|
||||
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- 대규모 React/Next.js 프로젝트의 폴더 구조와 의존성 규칙을 수립할 때.
|
||||
- 성능 최적화(리렌더링 방지, 번들 사이즈 최적화)가 필요한 시점.
|
||||
- 다수의 개발자가 협업하며 코드의 위치와 책임을 명확히 정의해야 할 때.
|
||||
|
||||
**언제 이 지식을 쓰면 안 되는가:**
|
||||
- 매우 단순한 랜딩 페이지나 정적 문서 사이트. (FSD 도입 시 폴더 깊이만 깊어짐)
|
||||
- Vanilla JS 기반의 가벼운 인터랙션 위주 시스템.
|
||||
|
||||
**이 지식을 적용할 때의 권장 절차:**
|
||||
1. **아키텍처 선정:** 프로젝트 규모에 따라 FSD 또는 도메인 기반 폴더 구조 채택.
|
||||
2. **상태 계층 정의:** 서버 데이터와 클라이언트 UI 상태를 엄격히 분리 (TanStack Query vs Zustand).
|
||||
3. **공통 컴포넌트 구축:** Shared 계층에 원자적 컴포넌트(Atomic Design) 구축.
|
||||
4. **기능 구현:** Features 계층에서 비즈니스 로직을 구현하고 Widgets로 조립.
|
||||
5. **의존성 검사:** ESLint 등을 활용하여 하위 계층이 상위 계층을 참조하는지 상시 감시.
|
||||
|
||||
**주의사항 또는 알려진 한계:**
|
||||
- **과도한 계층화:** 소규모 프로젝트에서 FSD를 적용하면 파일 하나를 수정하기 위해 여러 계층을 이동해야 하는 불편함 발생.
|
||||
- **서버/클라이언트 경계 혼선:** RSC 도입 시 'use client'와 'use server'의 경계에서 발생하는 데이터 전달 제약 이해 필수.
|
||||
|
||||
---
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** verified
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** FSD 공식 가이드, React 최신 문서, 그리고 대규모 프론트엔드 프로젝트의 베스트 프랙티스를 기반으로 함.
|
||||
|
||||
---
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** [[Frontend_Architecture]], [[FSD (Feature-Sliced Design)]], [[React Component Patterns]], [[State Management]], [[Nextjs-App-Router-Architecture]] 등 100여 개
|
||||
- **처리 방식:** MERGE & ARCHIVE
|
||||
- **처리 이유:** 프론트엔드 기술은 파편화되기 쉬우나, '컴포넌트'와 '상태'라는 두 축으로 모든 지식을 통합할 수 있음. 이를 통해 파편화된 기술 스택 가이드를 하나의 현대적 표준으로 융합함.
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **Flux vs Hooks:** Redux와 같은 대형 프레임워크 위주에서, Hooks와 원자적 상태(Atomic state) 위주로 트렌드 변화.
|
||||
- **CSR의 몰락:** SEO와 초기 로딩 성능을 위해 서버 사이드 렌더링(SSR/RSC)이 다시 주류가 됨.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
|
||||
- **Parent:** [[10_Wiki/Topics]]
|
||||
- **Related:** [[도메인_주도_설계(DDD)_및_소프트웨어_아키텍처]], [[현대적_웹_성능_및_상태_관리_최적화]], [[디자인_시스템_및_상용자_경험_표준]]
|
||||
- **Raw Source:** Frontend 폴더 내 다수 파일
|
||||
|
||||
---
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-07 | 100개 이상의 프론트엔드 아키텍처/패턴 관련 문서 통합 및 v3.0 규격 적용 | MERGE | A |
|
||||
Reference in New Issue
Block a user