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*