bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
185c293b127d4c47048269045c8231b4ffddebb3
2nd/10_Wiki/Topics/현대적_프론트엔드_아키텍처_및_상태_관리.md
T

6.9 KiB
Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit
wiki-2026-0507-103 현대적_프론트엔드_아키텍처_및_상태_관리 10_Wiki/Topics verified self
Frontend Architecture
Modern Frontend
State Management
FSD
Feature-Sliced Design
React Patterns
Next.js Architecture
상태 관리
프론트엔드 아키텍처
none A 1.0
Frontend
React
Next.js
Architecture
State Management
FSD
Frontend_Architecture.md
FSD (Feature-Sliced Design).md
React Component Patterns.md
Modern React Architecture.md
2026-05-07 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)

⚠️ 모순 및 업데이트 (Contradictions & Updates)

  • Flux vs Hooks: Redux와 같은 대형 프레임워크 위주에서, Hooks와 원자적 상태(Atomic state) 위주로 트렌드 변화.
  • CSR의 몰락: SEO와 초기 로딩 성능을 위해 서버 사이드 렌더링(SSR/RSC)이 다시 주류가 됨.

🔗 지식 연결 (Graph)

🕓 변경 이력 (Changelog)

날짜 변경 내용 처리 방식 신뢰도
2026-05-07 100개 이상의 프론트엔드 아키텍처/패턴 관련 문서 통합 및 v3.0 규격 적용 MERGE A
Reference in New Issue View Git Blame Copy Permalink