chore: Delete processed raw file (Layered Arch)

00_Raw/Layered Architecture.md

@@ -1,25 +0,0 @@
-# [[Layered Architecture]]
-
-## 📌 Brief Summary
-Layered Architecture(계층형 아키텍처)는 데이터, 로직, 프레젠테이션과 같은 기술적인 역할(Technical Role)에 따라 관심사를 분리하는 전통적인 소프트웨어 아키텍처 방식입니다 [1]. React 프로젝트에서는 주로 `components`, `hooks`, `services`, `store`와 같이 파일 유형별로 폴더를 구성하는 형태로 적용됩니다 [1, 2]. 이 구조는 초기 프로젝트 설정이 직관적이고 소규모 애플리케이션에는 적합하지만, 애플리케이션이 커질수록 단일 기능(Feature)이 여러 계층에 흩어지게 되어 코드 유지보수 및 확장성이 크게 떨어지는 단점이 있습니다 [1-3].
-
-## 📖 Core Content
-* **기술적 역할에 기반한 분리 (Separation by Technical Role):** 
-  Layered Architecture는 MVC(Model-View-Controller), MVP(Model-View-Presenter), MVVM 등의 패턴처럼 애플리케이션을 데이터, 비즈니스 로직, 프레젠테이션 계층으로 나눕니다 [1, 4]. 프론트엔드 프로젝트에서는 주로 모든 컴포넌트를 하나의 폴더에, 모든 훅(Hooks)을 다른 폴더에, 스타일을 또 다른 폴더에 모아두는 방식(Type-Based Organization)으로 나타납니다 [1, 2].
-* **초기 직관성과 소규모 앱에 대한 적합성:**
-  이 구조는 기술적인 명확성을 최적화하므로, 개발 초기의 작은 프로토타입이나 중소규모 애플리케이션(Small to medium applications)에서는 시작하기 쉽고 직관적인 장점이 있습니다 [1-3].
-* **확장성 및 유지보수의 한계:**
-  프로젝트의 규모가 확장됨에 따라 여러 가지 구조적 결함이 발생합니다.
-  * 단일 기능(Logical feature)에 관련된 파일들이 프로젝트 디렉토리 전체에 파편화되어 분산됩니다 [1, 2].
-  * 비즈니스 로직이 쪼개져 있어, 하나의 기능을 리팩터링하거나 수정할 때 관련이 없는 수많은 폴더와 파일들을 탐색하고 수정해야 하므로 개발자의 인지 부하(Cognitive load)가 증가합니다 [1, 2].
-  * 기존 백엔드 중심적인 구조를 프론트엔드에 강제하는 경향이 있어, React와 같이 모던한 컴포넌트 기반 라이브러리의 본질과 완벽하게 부합하지 않습니다 [4].
-* **현대적 대안으로의 전환:** 
-  이러한 확장성(Scalability) 문제를 해결하기 위해, 2025년 프론트엔드 생태계에서는 기술적 파일 유형이 아닌 비즈니스 기능 자체를 중심으로 코드를 그룹화하는 기능 기반 폴더 구조(Feature-Based Organization) 또는 Feature-Sliced Design(FSD) 패러다임으로 전환하고 있습니다 [5, 6].
-
-## 🔗 Knowledge Connections
-- **Related Topics:** [[MVC/MVP/MVVM]], [[Feature-Sliced Design]], [[Feature-Based Organization]], [[React Folder Structure]]
-- **Projects/Contexts:** [[대규모 React 애플리케이션 아키텍처 설계]], [[프론트엔드 폴더 구조 리팩터링 및 확장성 확보]]
-- **Contradictions/Notes:** Layered Architecture는 초기 도입 시 기술적인 명확성을 제공하여 유용해 보일 수 있지만, React와 같은 컴포넌트 기반 UI 개발에서는 장기적인 기능 확장성(Feature scalability)을 저해하므로 Feature-Sliced Design 같은 현대적인 기능 중심 아키텍처가 더 나은 대안으로 평가받고 있습니다 [4, 7].
-
----
-*Last updated: 2026-04-26*

10_Wiki/Topics/AI/Layered-Architecture-in-Frontend.md

@@ -0,0 +1,30 @@
+---
+id: ARCH-LAYERED-001
+category: "[[10_Wiki/💡 Topics/AI]]"
+confidence_score: 1.0
+tags: [architecture, layered-architecture, mvc, mvvm, separation-of-concerns, react, scalability]
+last_reinforced: 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)에 의존하는 구조.
+- **장단점:**
+    - **장점:** 초기 설정이 매우 직관적이며, 소규모 프로토타입 개발 시 빠른 속도 보장.
+    - **단점:** 기능(Feature)이 비대해질수록 관련 코드들이 프로젝트 전체에 파편화되어 인지적 부하(Cognitive Load)가 급격히 상승함.
+- **의의:** 전통적인 백엔드 설계 철학을 프런트엔드에 이식한 형태로, 현대의 기능 중심(Feature-Based) 아키텍처로 진화하기 위한 징검다리 역할을 함.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 과거에는 MVC/MVVM 기반의 계층 분리가 최선책이었으나, 현대 정책은 컴포넌트 중심의 '기능 기반 설계(FSD) 정책'을 대규모 앱의 표준으로 선호함.
+- **정책 변화:** Antigravity 프로젝트는 단순 CRUD 중심의 소규모 페이지에만 계층형 구조를 허용하며, 복잡한 비즈니스 로직이 포함된 도메인은 반드시 기능별 모듈화(Feature-Sliced Design) 정책을 따르도록 함.
+
+## 🔗 지식 연결 (Graph)
+- [[Feature-Sliced-Design-FSD]], [[Modern-React-Application-Architecture-Patterns]], [[Frontend-Architecture-and-Folder-Structure]], [[Clean-Architecture-Implementation]]
+- **Raw Source:** [[00_Raw/Layered Architecture.md]]