Antigravity Agent
57 lines
4.1 KiB
Markdown
57 lines
4.1 KiB
Markdown
## 📌 Brief Summary
|
|
프론트엔드 시스템 디자인은 현대의 대규모 웹 애플리케이션을 확장 가능하고(Scalable), 유지보수가 용이하며(Maintainable), 고성능인(Performant) 시스템으로 구축하기 위한 아키텍처 설계론이다. UI 구현을 넘어 상태 관리, 모듈화, 빌드 최적화, 거버넌스 등을 통합적으로 엔지니어링하여 비즈니스 가치를 안정적으로 전달하는 것을 목표로 한다.
|
|
|
|
## 📖 Core Content
|
|
1. **아키텍처 패러다임: FSD (Feature-Sliced Design)**
|
|
- 비즈니스 도메인 중심의 계층화(App, Pages, Widgets, Features, Entities, Shared)를 통해 모듈의 독립성을 확보한다.
|
|
- 단방향 의존성 규칙과 Public API(`index.ts`)를 강제하여 기능 간의 암시적 결합을 방지하고 코드의 예측 가능성을 높인다.
|
|
2. **엔지니어링 원칙의 적용**
|
|
- **SOLID (특히 SRP)**: 컴포넌트의 책임을 단일화하고 비대한 컴포넌트에서 비즈니스 로직을 커스텀 훅으로 추출한다.
|
|
- **KISS & DRY**: 중복을 제거하되 과도한 추상화를 경계하여 코드의 단순성과 가독성을 유지한다.
|
|
3. **상태 관리 아키텍처**
|
|
- 상태의 수명과 성격에 따라 로컬, 전역(Zustand/Redux), 서버 캐시(TanStack Query)로 명확히 레이어를 분리한다.
|
|
- 성능 저하를 방지하기 위해 Context API의 리렌더링 한계를 이해하고 최적화된 상태 구독(Selector) 패턴을 적용한다.
|
|
4. **성능 엔지니어링**
|
|
- 번들 사이즈 최적화(Code Splitting)와 런타임 성능(Virtualization, Memoization)을 아키텍처 수준에서 고려하여 사용자 체감 성능을 극대화한다.
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **유연성 vs 규격화**: 엄격한 시스템 디자인은 협업과 유지보수에 유리하지만, 빠른 실험과 프로토타이핑이 필요한 초기 단계에서는 개발 속도를 저해할 수 있다.
|
|
- **도구의 종속성**: 특정 상태 관리나 빌드 도구에 기반한 디자인은 도구의 버전 업그레이드나 패러다임 변화 시 큰 전환 비용을 발생시킨다.
|
|
- **인지적 부하**: 아키텍처가 복잡해질수록 신규 팀원의 온보딩 비용이 증가하므로, 문서화와 자동화된 린트 규칙이 반드시 수반되어야 한다.
|
|
|
|
## 🔗 Knowledge Connections
|
|
### Related Concepts (Auto-Linked)
|
|
* [[Architecture]]
|
|
* [[Code Splitting]]
|
|
* [[Design_Systems]]
|
|
* [[Feature-Sliced_Design]]
|
|
* [[Frontend]]
|
|
* [[Index]]
|
|
* [[Management]]
|
|
* [[Observability]]
|
|
* [[Prop Drilling]]
|
|
* [[Redux]]
|
|
* [[Research]]
|
|
* [[State]]
|
|
|
|
### Related Concepts
|
|
- **Feature-Sliced Design**: 시스템 구조화의 핵심 방법론 (관계: 구조적 뼈대)
|
|
- **State Management Architecture**: 데이터 흐름의 계층화 (관계: 혈액 순환 체계)
|
|
- **Performance Engineering**: 시스템 효율성 극대화 (관계: 품질 지표)
|
|
|
|
### Deeper Research Questions
|
|
1. FSD 구조에서 계층 간 데이터 전달 시 'Prop Drilling'을 최소화하면서도 단방향 의존성을 지키는 전략은 무엇인가?
|
|
2. 서버 컴포넌트(RSC) 환경에서 시스템 디자인의 'Client State' 레이어는 어떻게 재설계되어야 하는가?
|
|
3. 아키텍처의 Public API 규칙을 위반하는 '심층 임포트(Deep Import)'를 정적 분석으로 완벽히 차단하는 방법은?
|
|
4. 상태 관리 라이브러리 간의 아키텍처적 트레이드오프를 결정하는 정량적 기준(팀 규모, 컴포넌트 수 등)은 존재하는가?
|
|
5. 시스템 디자인 단계에서 고려해야 할 '웹 접근성(A11y)'과 '국제화(i18n)' 레이어의 배치 전략은?
|
|
|
|
### Practical Application Contexts
|
|
- **신규 플랫폼 아키텍처 수립**: 제품 개발 초기 단계에서 확장 가능한 폴더 구조 및 기술 스택 레이어링 정의.
|
|
- **기술 부채 해소**: 스파게티 코드로 변한 대규모 리액트 앱을 기능별로 모듈화하여 시스템 안정성 회복.
|
|
|
|
### Adjacent Topics
|
|
- **Micro-Frontends Architecture**
|
|
- **Design Systems & Component Library Design**
|
|
- **Frontend Observability & Monitoring**
|