Files

T

koriweb d8a80f6272 chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)

이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해
끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은
과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업.
도구: Datacollect/scripts/link_reconcile_apply.mjs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-08 12:24:15 +09:00

7.0 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, tech_stack

title

현대적_프론트엔드_아키텍처_및_상태_관리

📌 한 줄 통찰 (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 기반의 가벼운 인터랙션 위주 시스템.

이 지식을 적용할 때의 권장 절차:

아키텍처 선정: 프로젝트 규모에 따라 FSD 또는 도메인 기반 폴더 구조 채택.
상태 계층 정의: 서버 데이터와 클라이언트 UI 상태를 엄격히 분리 (TanStack Query vs Zustand).
공통 컴포넌트 구축: Shared 계층에 원자적 컴포넌트(Atomic Design) 구축.
기능 구현: Features 계층에서 비즈니스 로직을 구현하고 Widgets로 조립.
의존성 검사: 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

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

7.0 KiB Raw Blame History