---
id: wiki-2026-0508-frontend-architecture
title: Frontend Architecture
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [uncategorized]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

## 📌 한 줄 통찰 (The Karpathy Summary)
프론트엔드 아키텍처는 현대 웹 애플리케이션의 복잡성을 관리하고 지속 가능한 유지보수성과 확장성을 확보하기 위한 구조적 설계 기반이다. 단순한 UI 렌더링을 넘어 비즈니스 로직과 UI의 분리, 엄격한 의존성 관리, 그리고 기능(Feature) 기반의 모듈화를 통해 견고한 소프트웨어 시스템을 구축하는 것을 목표로 한다.

## 📖 구조화된 지식 (Synthesized Content)
1. **기능 기반 설계 및 FSD (Feature-Sliced Design)**
   - 기술적 타입(컴포넌트, 훅 등)이 아닌 비즈니스 기능(도메인) 중심으로 코드를 구성하여 응집도를 높인다.
   - FSD 아키텍처를 통해 계층(Layer) 간 단방향 의존성을 강제하고, 모듈 간의 순환 참조와 아키텍처 붕괴를 원천적으로 방지한다.
2. **소프트웨어 공학 원칙의 적용**
   - **SOLID**: 단일 책임 원칙(SRP)으로 컴포넌트를 세분화하고, 컴포넌트 합성(Composition)으로 개방-폐쇄 원칙(OCP)을 준수한다.
   - **KISS, DRY, YAGNI**: 코드를 단순하게 유지하고 불필요한 추상화와 오버엔지니어링을 경계하여 실용적인 코드베이스를 유지한다.
3. **계층화된 상태 관리**
   - 상태의 성격에 따라 로컬(React State), 글로벌 앱 상태(Zustand), 서버 캐시 상태(TanStack Query)로 레이어를 분리하여 리렌더링 성능과 데이터 동기화 효율을 최적화한다.
4. **성능 및 회복성 설계**
   - Vite 기반의 코드 스플리팅과 지연 로딩을 통해 번들 크기를 최적화하고, Error Boundary를 배치하여 특정 모듈의 오류가 시스템 전체로 전파되는 것을 차단한다.

## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
- **설계 오버헤드**: 엄격한 아키텍처(FSD 등) 도입 시 초기 폴더 구성과 계층 분리에 따른 인지적 부하 및 파일 수 증가가 발생할 수 있다.
- **추상화의 양날의 검**: DRY 원칙을 무리하게 적용하여 지나치게 추상화된 공통 로직은 오히려 코드 독해를 방해하고 변경에 취약하게 만들 수 있다(KISS 원칙과의 충돌).
- **기술 부채의 점진적 해결**: 기존의 모놀리식 구조에서 기능 기반 아키텍처로 전환할 때, 과도한 빅뱅 방식의 리팩토링보다는 점진적 마이그레이션 전략이 권장된다.

## 🔗 지식 연결 (Graph)
### Related Concepts
- **Feature-Sliced Design**: 프론트엔드 모듈화의 최신 표준 방법론 (관계: 핵심 아키텍처 모델)
- **State Management**: 데이터 흐름의 중앙 통제 및 최적화 (관계: 데이터 레이어 설계)
- **SOLID Principles**: 객체 지향 및 컴포넌트 설계의 근간 (관계: 코드 품질 기준)

### Deeper Research Questions
1. FSD의 'Widgets' 계층과 'Features' 계층 사이의 책임 분배를 결정하는 가장 명확한 기준은 무엇인가?
2. 마이크로 프론트엔드 전환 시, 중앙 집중식 상태 관리 라이브러리와 서비스별 격리된 상태 관리 중 어떤 것이 유리한가?
3. 컴포넌트 합성(Composition) 패턴이 개방-폐쇄 원칙(OCP)을 프론트엔드 환경에서 어떻게 물리적으로 구현하는가?
4. 서버 사이드 데이터(RSC) 비중이 늘어날 때, 클라이언트 아키텍처의 상태 관리 레이어는 어떻게 간소화되어야 하는가?
5. 아키텍처의 단방향 의존성 규칙을 정적 분석 도구(ESLint plugin-import 등)를 통해 자동화하여 강제하는 방안은?

### Practical Application Contexts
- **대규모 앱 리팩토링**: 흩어져 있는 비즈니스 로직을 기능별 폴더로 캡슐화하여 유지보수성 확보.
- **신규 프로젝트 설계**: 초기 아키텍처 수립 단계에서 상태 레이어와 오류 처리 전략 정의.

### Adjacent Topics
- **Micro-Frontends**
- **Server Components (RSC)**
- **Test-Driven Development (TDD) in Frontend**

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

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

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

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