feat: Knowledge Gardening Milestone 400 (Batch #20)

00_Raw/Feature-Sliced Design.md

@@ -0,0 +1,34 @@
+# [[Feature-Sliced Design]]
+
+## 📌 Brief Summary
+Feature-Sliced Design(FSD)은 프론트엔드 애플리케이션(특히 React)을 위해 특별히 고안된 최신 아키텍처 방법론입니다 [1, 2]. 코드를 기술적인 파일 유형이 아닌 비즈니스 로직, 사용자의 여정, 책임(Scope and responsibility)을 기준으로 구성하여 프로젝트의 유지보수성과 확장성을 높이는 것을 목표로 합니다 [2, 3]. 컴포넌트 기반 개발, 도메인 주도 설계(DDD), 모듈형 시스템 아키텍처의 원칙을 결합하여 명확하고 강제할 수 있는 폴더 및 코드 구조를 제공합니다 [1, 4].
+
+## 📖 Core Content
+*   **핵심 계층 구조 (Layers, Slices, Segments):**
+    FSD는 프로젝트를 레이어(Layer), 슬라이스(Slice), 세그먼트(Segment) 개념으로 분할합니다 [5]. 가장 최상위 개념인 레이어는 다음과 같이 엄격하게 지정된 폴더 구조를 가집니다.
+    *   `app`: 애플리케이션 초기화 및 전역 설정 [3, 6]
+    *   `pages`: 라우트 수준의 화면 조합 [3, 6]
+    *   `widgets`: 기능(Feature)과 엔티티(Entity)를 조합한 재사용 가능한 대형 UI 블록 [3, 6]
+    *   `features`: 사용자의 상호작용 시나리오 및 비즈니스 워크플로우 [3, 6]
+    *   `entities`: 핵심 비즈니스 데이터 모델 [3, 6]
+    *   `shared`: 도메인에 종속되지 않은 재사용 가능한 유틸리티 및 UI 컴포넌트 [3, 6]
+
+*   **단방향 의존성 규칙 (Unidirectional Dependencies):**
+    FSD의 가장 중요한 규칙으로, 코드는 오직 동일한 레이어 또는 자신보다 하위 레이어의 코드만 가져올(import) 수 있습니다 [3, 7]. 상위 레이어가 하위 레이어에 의존하는 것은 허용되지만, 하위 레이어는 절대 상위 레이어에 의존할 수 없습니다 [3]. 이를 통해 숨겨진 순환 참조를 제거하고 아키텍처의 규율을 강제할 수 있습니다 [7, 8].
+
+*   **공개 API 규칙 (Public API Rule):**
+    각 슬라이스는 주로 `index.ts`를 통해 단일 진입점을 가져야 합니다 [9-11]. 외부 모듈은 오직 이 진입점에서 명시적으로 export된 요소에만 접근해야 하며, 내부 파일에 직접 접근할 수 없습니다 [9, 10]. 이는 캡슐화를 강화하고 명확한 인터페이스 계약을 생성하여 리팩토링 시 사이드 이펙트를 최소화합니다 [9, 11].
+
+*   **도입 이점 및 실무 적용:**
+    대규모 프로젝트가 성장함에 따라 기능 간의 의존성이 얽히는(Tangled dependencies) 문제를 해결해 줍니다 [12]. 코드를 독립적으로 수정 및 테스트할 수 있게 해 주며 [13], 공유 상태를 줄이고 렌더링 경계를 좁혀 성능 최적화에도 자연스럽게 기여합니다 [14]. ESLint 규칙 등을 통해 아키텍처 경계를 자동화하여 관리하는 것이 권장됩니다 [15, 16].
+
+*   **한계 및 주의사항:**
+    가장 큰 과제는 특정 기능이 정확히 어떤 "Feature" 경계에 속하는지 파악하는 것입니다 [17]. 인증(Auth)과 같은 교차 관심사는 한 번에 거대한 슬라이스로 만들기보다 '로그인', '가입', '비밀번호 재설정' 등 구체적이고 작은 기능 단위로 나누는 것이 좋습니다 [17-19]. 또한, 팀원 전체가 이 방법론을 완전히 이해하지 않으면 모듈 분류에 대한 의미론적 논쟁(Semantic overhead)이 길어지거나, 모든 코드가 `shared` 레이어로 쏟아지는 문제가 발생할 수 있습니다 [16].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Frontend Folder Structure]], [[Domain-Driven Design]], [[Component-Based Architecture]]
+- **Projects/Contexts:** [[대규모 React 애플리케이션 및 엔터프라이즈 시스템 확장성 관리]]
+- **Contradictions/Notes:** 소스 [1, 2]는 FSD가 대규모 프론트엔드 시스템에서 직관적이고 훌륭한 구조적 대안이라고 강조합니다. 반면, 소스 [16, 17]의 실제 개발자 논의에서는 특정 모듈이 기능(Feature)인지 위젯(Widget)인지 결정하는 과정이 종종 불필요한 의미론적 오버헤드를 유발하며, 팀의 학습 곡선이 높고 크로스 커팅 문제(Cross-cutting concerns)를 깔끔하게 분리하기 어렵다는 현실적인 비판을 제시합니다.
+
+---
+*Last updated: 2026-04-26*

00_Raw/SOLID Principles in React.md

@@ -0,0 +1,28 @@
+# [[SOLID Principles in React]]
+
+## 📌 Brief Summary
+SOLID 원칙은 단일 책임(SRP), 개방-폐쇄(OCP), 리스코프 치환(LSP), 인터페이스 분리(ISP), 의존성 역전(DIP)의 다섯 가지 설계 원칙을 의미하는 약어입니다 [1, 2]. 본래 객체 지향 프로그래밍(OOP)을 위해 고안되었지만, 함수형 프로그래밍이 주도하는 현대 React 생태계에서도 컴포넌트의 유지보수성, 가독성, 확장성을 높이는 데 필수적으로 적용됩니다 [2, 3]. 이 원칙은 주로 명확한 구조와 확장성이 요구되는 크고 복잡한 애플리케이션을 개발할 때 효과적으로 사용됩니다 [4].
+
+## 📖 Core 대Content
+*   **단일 책임 원칙 (SRP, Single Responsibility Principle)**
+    React 컴포넌트나 훅은 단 하나의 명확한 목적을 가져야 하며, 변경되어야 하는 이유도 단 하나여야 합니다 [5, 6]. 예를 들어, 300줄이 넘어가는 컴포넌트는 상태 관리, 데이터 페칭, 복잡한 JSX 렌더링 등 너무 많은 작업을 수행하고 있을 가능성이 높습니다 [5]. 이를 더 작고 한 가지 역할만 하는 컴포넌트나 커스텀 훅으로 분리하면 코드의 명확성과 테스트 가능성이 크게 향상됩니다 [2, 5].
+
+*   **개방-폐쇄 원칙 (OCP, Open/Closed Principle)**
+    소프트웨어 엔티티는 확장을 위해서는 열려 있어야 하지만 수정을 위해서는 닫혀 있어야 합니다 [2]. React에서는 기존 컴포넌트의 내부 코드를 직접 수정하는 대신, 컴포넌트 합성(composition), `children` prop, 또는 렌더 프롭스(render props)를 사용하여 새로운 기능을 유연하게 확장하는 방식으로 구현됩니다 [2, 6, 7].
+
+*   **리스코프 치환 원칙 (LSP, Liskov Substitution Principle)**
+    하위(자식) 타입의 객체가 상위(부모) 타입의 객체를 코드를 깨뜨리지 않고 완벽하게 대체할 수 있어야 한다는 원칙입니다 [2, 8]. React에서는 하위 컴포넌트가 기본 컴포넌트를 원활하게 대체할 수 있도록 설계해야 함을 의미합니다 [6].
+
+*   **인터페이스 분리 원칙 (ISP, Interface Segregation Principle)**
+    클라이언트는 자신이 사용하지 않는 인터페이스나 데이터에 의존해서는 안 됩니다 [2]. React에서는 컴포넌트가 자신이 사용하지 않는 불필요한 props를 받지 않아야 하며, 책임을 명확히 분리하여 전달해야 합니다 [6]. 예를 들어, 단지 `username` 문자열 하나만 필요한 하위 컴포넌트에 거대한 `user` 객체 전체를 전달하면 불필요한 결합이 발생하므로 특정 데이터만 넘겨주는 것이 바람직합니다 [2, 7].
+
+*   **의존성 역전 원칙 (DIP, Dependency Inversion Principle)**
+    구체적인 구현 클래스가 아닌 추상화나 인터페이스에 의존해야 한다는 원칙입니다 [2, 9]. React 애플리케이션에서는 컴포넌트가 다른 컴포넌트에 직접적으로 강하게 의존하게 만드는 대신, props를 통해 의존성을 주입(inject)하거나 Context API 같은 공통 추상화를 활용하여 의존성을 관리해야 합니다 [2, 6].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Clean Code]], [[DRY Principle]], [[KISS Principle]], [[YAGNI Principle]], [[Component Composition]], [[Custom Hooks]]
+- **Projects/Contexts:** [[Large-scale Application Architecture]], [[Refactoring Legacy React Codebases]]
+- **Contradictions/Notes:** 소스 간에 리스코프 치환 원칙(LSP)의 React 적용 가능성에 대한 작은 관점 차이가 있습니다. 한 소스는 서브 컴포넌트가 베이스 컴포넌트를 원활히 대체하는 방식으로 LSP를 적용할 수 있다고 설명하지만 [6], 다른 소스는 현대 React에서 클래스 상속을 거의 사용하지 않는 함수형 접근 방식을 취하기 때문에 이 원칙이 실제로 적용되는 경우는 드물다고 지적합니다 [2].
+
+---
+*Last updated: 2026-04-26*