2.5 KiB
2.5 KiB
id, category, confidence_score, tags, last_reinforced
| id | category | confidence_score | tags | last_reinforced | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| ARCH-LAYERED-001 | 10_Wiki/💡 Topics/AI | 1.0 |
|
2026-04-26 |
Layered Architecture in Frontend (프런트엔드 계층형 아키텍처)
📌 한 줄 통찰 (The Karpathy Summary)
"기술적 역할(Components, Hooks, Services)에 따라 영토를 나누는 방식은 초기에 직관적이나, 프로젝트가 비대해질수록 하나의 기능을 수정하기 위해 전 대륙을 횡단해야 하는 비효율을 초래한다" — 소규모 앱의 정석이자 대규모 앱의 병목이 되는 전통적 아키텍처.
📖 구조화된 지식 (Synthesized Content)
- 추출된 패턴: "Technical Role-Based Partitioning" — 애플리케이션을 데이터(Model), 비즈니스 로직(Controller/Services), 프레젠테이션(View)과 같은 기술적 관심사에 따라 수평적으로 계층화하는 패턴.
- 구조적 특징:
- Type-Based Folder Structure:
components/,hooks/,services/,store/와 같이 파일의 유형별로 폴더를 구성. - Top-Down Dependency: 상위 계층(UI)이 하위 계층(Services/Data)에 의존하는 구조.
- Type-Based Folder Structure:
- 장단점:
- 장점: 초기 설정이 매우 직관적이며, 소규모 프로토타입 개발 시 빠른 속도 보장.
- 단점: 기능(Feature)이 비대해질수록 관련 코드들이 프로젝트 전체에 파편화되어 인지적 부하(Cognitive Load)가 급격히 상승함.
- 의의: 전통적인 백엔드 설계 철학을 프런트엔드에 이식한 형태로, 현대의 기능 중심(Feature-Based) 아키텍처로 진화하기 위한 징검다리 역할을 함.
⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- 과거 데이터와의 충돌: 과거에는 MVC/MVVM 기반의 계층 분리가 최선책이었으나, 현대 정책은 컴포넌트 중심의 '기능 기반 설계(FSD) 정책'을 대규모 앱의 표준으로 선호함.
- 정책 변화: Antigravity 프로젝트는 단순 CRUD 중심의 소규모 페이지에만 계층형 구조를 허용하며, 복잡한 비즈니스 로직이 포함된 도메인은 반드시 기능별 모듈화(Feature-Sliced Design) 정책을 따르도록 함.