Antigravity Agent
75 lines
11 KiB
Markdown
75 lines
11 KiB
Markdown
# [[Frontend Scalable Architecture]]
|
|
|
|
## 📌 Brief Summary
|
|
프론트엔드 확장 가능 아키텍처(Frontend Scalable Architecture)는 비즈니스 로직과 UI 컴포넌트의 결합을 방지하고 애플리케이션의 성장을 안전하게 도모하는 구조적 방법론이다 [1]. 단순한 렌더링 속도 최적화를 넘어 상태 소유권 명확화, 명시적 의존성 관리, 기능(Feature) 중심의 모듈화를 통해 예측 가능한 코드베이스의 확장을 목표로 한다 [1, 2]. 현대적인 아키텍처는 Feature-Sliced Design(FSD)과 같은 계층적 모델을 도입하여 팀 간 협업 효율을 높이고 장기적인 유지보수성을 극대화한다 [3].
|
|
|
|
## 📖 Core Content
|
|
- **기능(Feature) 기반 조직과 FSD (Feature-Sliced Design):**
|
|
과거의 기술 파일 타입(컴포넌트, 훅, 스타일 등) 기준 폴더 구조는 애플리케이션이 커질수록 탐색과 유지보수를 어렵게 만든다 [4, 5]. 2025년 기준 표준은 비즈니스 기능(도메인)을 중심으로 코드를 구성하는 것이다 [6]. 특히 FSD는 앱을 7개의 계층(`shared`, `entities`, `features`, `widgets`, `pages`, `app`)으로 나누어 상위 계층이 하위 계층에만 의존하게 하는 **단방향 의존성**을 강제한다 [7]. 또한 `index.ts`를 유일한 진입점으로 사용하는 Public API 규칙을 통해 내부 로직을 캡슐화한다 [8, 9].
|
|
|
|
- **SOLID 및 클린 코드 원칙의 적용:**
|
|
React 컴포넌트 개발 시 단일 책임 원칙(SRP)을 적용하여 역할이 많은 대형 컴포넌트(예: 300줄 이상)를 작고 집중된 형태의 컴포넌트로 분리한다 [10]. 개방-폐쇄 원칙(OCP)은 `children`이나 `render props`를 통한 합성으로 구현하며, 인터페이스 분리 원칙(ISP)을 통해 사용하지 않는 거대한 Props 객체 전달을 방지하여 결합도를 낮춘다 [11]. 또한 DRY(중복 방지) 원칙과 KISS(단순성 유지) 원칙 간의 균형을 잡아 과도한 추상화를 방지한다 [12].
|
|
|
|
- **파편화 및 전문화된 상태 관리:**
|
|
거대한 단일 스토어 방식에서 벗어나 상태 특성에 맞는 도구를 분리하여 선택한다. 로컬 상태는 `useState`를, 애플리케이션 전역 상태는 렌더링 최적화를 위해 Context API 대신 `Zustand`나 `Jotai`를 활용하며, 서버 상태(캐시, 네트워크 동기화)는 `TanStack Query`를 사용하여 API 네트워크 계층과 UI를 분리한다 [13-16].
|
|
|
|
- **빌드 타임 성능 및 번들링 최적화:**
|
|
Vite를 사용하여 개발 중에는 네이티브 ES 모듈을 제공해 즉각적인 반영을 얻고, 프로덕션에서는 Rollup을 통한 `manualChunks` 설정과 `React.lazy`를 활용해 경로(Route) 수준의 코드 스플리팅을 적용한다 [17-20]. 특히 2025년에 안정화된 React Compiler는 불필요한 리렌더링 방지를 위한 메모이제이션을 빌드 타임에 자동으로 처리해주어 수동 최적화(`useMemo`, `useCallback`)로 인한 코드 복잡도를 획기적으로 줄여준다 [18, 21, 22].
|
|
|
|
- **안정성 및 오류 복구 인프라:**
|
|
애플리케이션의 일부가 실패하더라도 전체가 멈추지 않도록 React Error Boundaries를 불안정한 UI 섹션에 전략적으로 배치한다 [23, 24]. 프로덕션 단계에서는 Sentry, LogRocket 같은 도구를 결합하여 메모리 누수, 분리된 DOM 노드 파악, 세션 리플레이를 통한 에러 모니터링 체계를 구축한다 [25-27].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **상태 관리 도구의 선택 (Context vs Zustand vs Redux):** Context API는 기본 내장 도구라는 장점이 있으나, 상태 값의 일부만 변경되어도 해당 컨텍스트를 구독하는 모든 컴포넌트가 리렌더링되는 치명적인 성능 저하를 유발한다 [28, 29]. 반면 Zustand는 선택자(Selector) 패턴으로 이 문제를 해결하고 구조가 가볍지만, 너무 유연하여 팀 내 규칙이 부재할 경우 전역 상태와 비동기 로직이 중구난방이 되는 부작용(Store Soup)을 낳을 수 있다 [30-32]. Redux는 엄격한 패턴을 제공하여 대규모 팀에 안정적이나, 과도한 보일러플레이트로 초기 개발과 MVP 구현 속도를 크게 늦춘다 [33, 34].
|
|
- **성능 최적화의 함정:** `React.memo`나 `useCallback`을 무분별하게 사용하면 메모이제이션을 판단하는 얕은 비교 처리에 비용이 더 발생해 오히려 성능을 악화시킬 수 있다 [35, 36].
|
|
- **FSD 아키텍처의 오버헤드:** Feature-Sliced Design은 명확한 캡슐화와 분리 구조를 제공하지만, 특정 모듈이 'feature'인지 'widget'인지 경계를 구분하기 모호한 상황 등 시맨틱 결정을 위한 커뮤니케이션 오버헤드가 발생하며, 새로운 팀원에게는 가파른 학습 곡선으로 작용한다 [37, 38].
|
|
- **마이크로 프론트엔드(Micro-Frontends):** 조직적인 확장성을 해결하고 독립적인 배포를 가능하게 하지만, 런타임 통합의 복잡성, 성능 오버헤드 증가, 파편화된 개발자 경험을 초래하므로 기본 아키텍처라기보다는 최후의 수단으로 간주해야 한다 [3].
|
|
|
|
## 🔗 Knowledge Connections
|
|
|
|
### Related Concepts
|
|
|
|
#### [아키텍처 및 방법론]
|
|
- [[Feature-Sliced Design]]
|
|
- 연결 이유: 대규모 프론트엔드 앱의 구조를 기술 계층이 아닌 비즈니스 도메인(기능) 중심으로 나누고, 엄격한 계층 구조를 제공하는 핵심 아키텍처이기 때문 [3, 7].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 폴더 구조화, 캡슐화를 위한 Public API 제어 전략, 단방향 의존성을 통한 결합도 감소 원리 [7, 8].
|
|
- [[SOLID Principles in React]]
|
|
- 연결 이유: 확장성 있는 컴포넌트와 훅 설계를 위한 근본적인 소프트웨어 엔지니어링 가이드라인이기 때문 [9].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: SRP(단일 책임 원칙)와 ISP(인터페이스 분리 원칙)를 활용해 결합도는 낮추고 응집도는 높은 컴포넌트를 분리해내는 실무적 기법 [10, 11].
|
|
|
|
#### [상태 관리 및 성능 최적화 도구]
|
|
- [[Zustand]]
|
|
- 연결 이유: Context API의 '리렌더링 폭포' 한계를 극복하고 Redux의 복잡성을 피하면서 전역 상태를 효과적으로 스케일링하는 대안이기 때문 [29, 32].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Selector 패턴이 컴포넌트의 특정 상태 구독을 제어하여 어떻게 렌더링 최적화를 달성하는지에 대한 메커니즘 [32].
|
|
- [[React Compiler]]
|
|
- 연결 이유: 2025년 기준 개발자가 수동으로 수행하던 메모이제이션(`useMemo`, `useCallback` 등) 작업을 빌드 타임에 자동화하여 코드 복잡도를 획기적으로 낮춰주는 도구이기 때문 [21, 22].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 개별 JSX 요소의 세밀한 메모이제이션 작동 방식과 서드파티 라이브러리에 대응하기 위한 최적화 제약 조건 [39, 40].
|
|
- [[React Error Boundaries]]
|
|
- 연결 이유: 확장 가능한 대규모 애플리케이션에서 특정 하위 모듈이나 컴포넌트의 런타임 오류가 전체 애플리케이션의 크래시로 이어지는 것을 막는 핵심 안정화 장치이기 때문 [23, 24].
|
|
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 에러의 선언적 격리와 Fallback UI 제공을 통해 프로덕션 환경의 UX와 회복력을 강화하는 방식 [41, 42].
|
|
|
|
### Deeper Research Questions
|
|
|
|
- Feature-Sliced Design(FSD)에서 Cross-cutting concern(교차 관심사)을 완벽히 격리하는 것이 현실적으로 어려운 이유는 무엇이며, 이를 상위 계층에서 어떻게 컴포지션(Composition)으로 해결해야 하는가?
|
|
- React Compiler가 빌드 타임에 메모이제이션을 자동화함에도 불구하고, 서드파티 라이브러리(예: TanStack Query 등)가 반환하는 불안정한 참조(Unstable References)가 있을 때 왜 여전히 수동 메모이제이션이 필요한가?
|
|
- Context API가 유발하는 '리렌더링 폭포 현상'을 우회하기 위해 설계된 Zustand의 Selector 패턴은 내부적으로 어떻게 필요한 상태 변화만 감지하고 컴포넌트를 업데이트하는가?
|
|
- Vite 환경에서 `manualChunks`와 `React.lazy`를 결합하여 거대한 번들(Large Chunks)을 분리해 낼 때, 이러한 전략이 Core Web Vitals(특히 LCP 및 INP)에 미치는 실제 브라우저 동작 메커니즘은 어떠한가?
|
|
- 대규모 애플리케이션에서 마이크로 프론트엔드(Micro-Frontends) 도입 시 발생하는 런타임 통합의 성능 오버헤드는 FSD와 같은 모놀리식 모듈형 아키텍처와 비교하여 어떠한 한계를 가지는가?
|
|
|
|
### Practical Application Contexts
|
|
|
|
- **Implementation:** 코드를 구현할 때 비즈니스 도메인 단위로 폴더를 생성(Feature 폴더)하며, 300줄이 넘어가는 컴포넌트는 단일 책임 원칙(SRP)에 따라 작은 UI 요소와 커스텀 훅으로 분리하여 작성한다 [6, 10, 43].
|
|
- **System Design:** 모듈 간 결합도를 최소화하기 위해 하위 계층(예: shared, entities)에서 상위 계층(예: features, pages)을 참조하지 못하도록 ESLint 규칙으로 단방향 의존성을 강제하고, 각 폴더의 접근 창구를 `index.ts`로 캡슐화(Public API 규칙)하여 아키텍처를 설계한다 [7, 8, 44].
|
|
- **Operation / Maintenance:** 프로덕션 환경에서 Sentry를 통해 Error Boundary가 잡지 못한 에러를 모니터링하고, 크롬 DevTools의 메모리 스냅샷이나 LogRocket과 같은 디버깅 툴로 이벤트 리스너 미해제에 따른 Detached DOM 메모리 누수를 지속적으로 추적 및 유지보수한다 [25-27].
|
|
- **Learning Path:** React 코어 원리와 상태 관리의 한계(Context API 병목 현상) 인지 → 확장성을 고려한 아키텍처 원칙(FSD, SOLID) 학습 → 도메인 분리 도구 적용(Zustand, TanStack Query) → 성능 및 번들링 최적화(React Compiler, Vite 코드 스플리팅) 순서로 학습 로드맵을 구성한다 [45].
|
|
- **My Project Relevance:** 소스에 관련 정보가 부족합니다.
|
|
|
|
### Adjacent Topics
|
|
|
|
- [[Core Web Vitals]]
|
|
- 확장 방향: 프론트엔드 아키텍처에서의 코드 스플리팅과 리소스 지연 로딩 최적화 기법이 실제 사용자 체감 속도(LCP, INP, CLS 등)에 미치는 영향을 측정하고 데이터 기반으로 모니터링하는 전략으로 확장 [17, 46].
|
|
- [[Git Branching Workflow]]
|
|
- 확장 방향: 엄격하게 구조화된 대형 코드베이스를 여러 팀원과 함께 충돌 없이 개발하기 위한 깃 브랜칭 전략(GitHub Flow 적용 여부), Conventional Commits 작성법 및 CI/CD 품질 검증 파이프라인으로 확장 [47, 48].
|
|
|
|
---
|
|
*Last updated: 2026-04-30* |