[G1-Sync] Manual knowledge update

2026-05-01 20:45:18 +09:00
parent e56d8c7cf9
commit 13f58a24de
40 changed files with 1577 additions and 23 deletions
@@ -0,0 +1,35 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARC-001
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, clean-architecture, design-patterns, mvc, separation-of-concerns, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Clean Architecture & Patterns]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "기술적 세부 사항(DB, Framework)으로부터 비즈니스 로직을 격리하여, 시스템의 수명을 연장하고 변화에 유연하게 대응하게 만드는 관심사 분리(Separation of Concerns)의 정점."
+
+## 📖 구조화된 지식 (Synthesized Content)
+아키텍처 패턴은 코드 리뷰 시 새로운 코드가 시스템의 전체적인 설계 방향과 일치하는지 평가하는 가장 고수준의 기준입니다.
+
+1.  **클린 아키텍처 (Clean Architecture)**:
+    *   **의존성 규칙**: 의존성은 항상 안쪽(도메인/엔티티)을 향해야 합니다. 외부의 프레임워크나 데이터베이스 변경이 핵심 비즈니스 로직에 영향을 주지 않도록 격리합니다.
+    *   **계층 분리**: 엔티티(Entity), 유즈케이스(Use Case), 인터페이스 어댑터, 프레임워크 및 드라이버 레이어로 구분하여 각각의 역할을 명확히 정의합니다.
+2.  **MVC (Model-View-Controller)**:
+    *   데이터(Model), 사용자 인터페이스(View), 로직(Controller)을 분리하여 각 컴포넌트의 독립적 개발과 테스트를 가능하게 합니다.
+3.  **코드 리뷰에서의 역할**:
+    *   리뷰어는 새로운 코드가 확립된 디자인 패턴과 정렬되는지, 계층 간의 신뢰 경계를 침범하지 않는지 비판적으로 검토합니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과도한 계층화 (Over-layering)**: 단순한 기능을 구현할 때도 모든 레이어를 엄격히 적용하면 코드 복잡도가 불필요하게 증가합니다. 프로젝트의 규모와 복잡도에 따라 아키텍처의 엄격함을 조절하는 실용적인 접근(Pragmatism)이 필요합니다.
+- **아키텍처 부패 (Architectural Decay)**: 시간이 흐름에 따라 편의를 위해 계층을 우회하는 코드가 쌓일 수 있습니다. 매 PR마다 아키텍처 무결성을 점검하여 부패를 조기에 차단해야 합니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: 아키텍처를 지탱하는 세부 설계 원칙.
+- [[Architecture Review]]: 아키텍처 일관성을 검증하는 프로세스.
+- [[Dependency Management (DI & DIP)]]: 계층 간 결합도를 낮추는 기술적 수단.
+- [[Single Responsibility Principle (SRP)]]: 컴포넌트 분리의 근거.
+- [[Abstraction & Over-engineering]]: 아키텍처 도입 시 경계해야 할 함정.
+---
@@ -0,0 +1,39 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-004
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, clean-architecture, layering, decoupling, domain-driven-design, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Clean Architecture]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "비즈니스 로직(Domain)을 중심에 두고 UI, DB, 프레임워크와 같은 외부 세부 사항을 주변부로 밀어내어, 외부 기술의 변화가 시스템의 핵심 논리에 영향을 주지 않도록 격리하는 계층화 아키텍처의 정수."
+
+## 📖 구조화된 지식 (Synthesized Content)
+클린 아키텍처는 소프트웨어의 생존 기간을 늘리고 기술 부채를 제어하기 위한 거시적 설계 패턴입니다.
+
+1.  **의존성 규칙 (The Dependency Rule)**:
+    *   모든 의존성은 안쪽(도메인/엔티티)을 향해야 합니다.
+    *   내부 계층은 외부 계층(DB, Web, UI)에 대해 아무것도 몰라야 하며, 인터페이스를 통해서만 소통합니다.
+2.  **계층화 구조**:
+    *   **Entities**: 핵심 비즈니스 규칙 및 데이터 모델.
+    *   **Use Cases**: 애플리케이션 고유의 비즈니스 규칙(흐름 제어).
+    *   **Interface Adapters**: 데이터 변환 레이어 (Controller, Presenter, Gateway).
+    *   **Frameworks & Drivers**: DB, 프레임워크, 외부 API 등 기술적 세부 사항.
+3.  **장점**:
+    *   프레임워크 독립성: UI나 DB 프레임워크를 교체해도 비즈니스 로직은 수정할 필요가 없습니다.
+    *   테스트 용이성: 외부 요소 없이 핵심 로직만 독립적으로 단위 테스트가 가능합니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **보일러플레이트의 증가**: 코드의 격리를 위해 다수의 인터페이스와 데이터 변환 객체(DTO)가 필요하게 되어 코드량이 늘어납니다. 프로젝트의 규모가 작을 때는 MVC보다 비효율적일 수 있습니다.
+- **학습 곡선**: 계층 간 경계를 엄격히 지키는 설계 철학을 팀 전체가 공유하고 준수하는 데 높은 수준의 컨센서스와 코드 리뷰 역량이 요구됩니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: 각 계층 내부 설계를 지탱하는 원칙들.
+- [[Domain-Driven Design (DDD)]]: 도메인 중심 설계 사상과의 시너지.
+- [[Dependency Inversion Principle (DIP)]]: 계층 간 통신을 가능하게 하는 핵심 기술.
+- [[Software Architecture Patterns]]: MVC, Hexagonal 아키텍처 등과의 비교.
+- [[Over-engineering]]: 패턴의 맹목적 적용 시 경계해야 할 부작용.
+---
@@ -0,0 +1,36 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-003
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, di, dependency-injection, decoupling, inversion-of-control, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Dependency Injection (DI)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "클래스 내부에서 직접 의존 객체를 생성하지 않고 외부에서 주입받음으로써, 객체 간의 결합을 끊어내고 테스트와 확장이 용이한 '유연한 부품'으로 만드는 제어 역전(IoC)의 실천적 기법."
+
+## 📖 구조화된 지식 (Synthesized Content)
+DI는 현대 소프트웨어 아키텍처에서 컴포넌트 간의 결합도를 낮추는 핵심 메커니즘입니다.
+
+1.  **제어의 역전 (IoC)**:
+    *   객체가 스스로 의존성을 생성(new)하는 권한을 포기하고, 외부(컨테이너)로부터 주입받습니다.
+    *   이를 통해 구현체(Concrete Implementation)가 아닌 추상화(Interface/Abstract Class)에 의존하게 됩니다.
+2.  **생명주기(Lifetime) 관리**:
+    *   주입되는 객체의 생존 범위(Transient, Scoped, Singleton)를 중앙에서 통제합니다.
+    *   잘못된 생명주기 설정은 메모리 누수나 의도치 않은 상태 공유를 초래할 수 있으므로 코드 리뷰의 필수 체크 항목입니다.
+3.  **프레임워크별 관례**:
+    *   Spring(Java)에서는 생성자 주입(Constructor Injection)을 권장하며, .NET에서는 빌트인 DI 컨테이너를 통한 인터페이스 바인딩을 기본으로 합니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **생명주기 오용 리스크**: Scoped 객체가 Singleton 객체에 주입되는 등 생명주기 불일치가 발생할 경우, 데이터가 의도보다 오래 유지되거나 런타임 에러가 발생할 수 있습니다.
+- **코드 추적성 저하**: 정적 코드만으로는 어떤 구현체가 주입될지 즉각 확인하기 어려울 수 있습니다. 이를 해결하기 위해 명확한 네이밍 컨벤션과 DI 바인딩 로그의 가시성 확보가 중요합니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: 의존성 역전 원칙(DIP)의 실현 방법.
+- [[Single Responsibility Principle (SRP)]]: 클래스의 책임을 생성과 실행으로 분리하는 관점.
+- [[Testability]]: Mock 객체 주입을 통한 단위 테스트 용이성 확보.
+- [[Constructor Injection]]: 가장 권장되는 DI 패턴.
+- [[Dependency Lifetimes]]: Transient, Scoped, Singleton의 이해.
+---
@@ -0,0 +1,36 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARC-002
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, dependency-management, dependency-injection, di, dependency-inversion-principle, dip, decoupling, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Dependency Management (DI & DIP)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "구체적인 구현이 아닌 추상화에 의존하게 하여 컴포넌트 간의 결합도를 낮추고, 코드 수정 없이 기능을 확장하거나 교체할 수 있는 유연한 시스템 구조의 핵심 기법."
+
+## 📖 구조화된 지식 (Synthesized Content)
+의존성 관리는 소프트웨어의 모듈성과 테스트 가능성을 결정짓는 가장 중요한 설계 요소입니다.
+
+1.  **[[Dependency Inversion Principle (DIP)]]**:
+    *   **고수준 모듈의 보호**: 고수준 모듈(비즈니스 로직)은 저수준 모듈(데이터베이스, 외부 API)의 구체적인 구현에 의존해서는 안 됩니다. 둘 다 추상화(인터페이스)에 의존해야 합니다.
+    *   **의존성 방향의 역전**: 전통적인 계층 구조에서의 의존성 방향을 뒤집어, 구현체가 인터페이스를 따르게 함으로써 핵심 로직을 외부 변화로부터 보호합니다.
+2.  **[[Dependency Injection (DI)]]**:
+    *   **객체 생성이 아닌 주입**: 클래스 내부에서 의존 객체를 직접 생성(New)하지 않고, 외부(생성자, 메서드 등)에서 주입받습니다.
+    *   **유연한 교체**: 인터페이스를 통해 종속성을 주입받으므로, 실제 구현체를 환경(Staging, Production)이나 테스트 목적(Mocking)에 따라 쉽게 교체할 수 있습니다.
+3.  **코드 리뷰에서의 역할**:
+    *   리뷰어는 코드가 하드코딩된 종속성을 가지고 있는지, 인터페이스를 통해 결합도가 적절히 분리(Decoupled)되었는지 검증합니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **추상화의 비용**: 모든 관계에 DI/DIP를 적용하면 코드 가독성이 떨어지고 추적하기 어려워질 수 있습니다. '과잉 엔지니어링(Over-engineering)'을 경계하며, 변화가 잦거나 테스트가 필수적인 영역을 중심으로 적용하는 실용성이 필요합니다.
+- **의존성 그래프의 복잡성**: 주입되는 객체가 많아지면 객체 생성 로직이나 DI 컨테이너 설정이 복잡해집니다. 생성자 주입(Constructor Injection)을 권장하고 클래스의 책임을 작게 유지하여 주입되는 의존성 수를 제한해야 합니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: DIP가 포함된 설계 원칙 그룹.
+- [[Clean Architecture & Patterns]]: DIP를 통해 도메인 로직을 보호하는 상위 아키텍처.
+- [[Testing Strategy]]: DI가 가능하게 하는 테스트 용이성.
+- [[Single Responsibility Principle (SRP)]]: 의존성이 많아지는 것을 방지하는 근거.
+- [[Over-engineering]]: 무분별한 추상화의 위험.
+---
@@ -0,0 +1,37 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-005
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, design-pattern, mvc, decoupling, ui-architecture, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[MVC (Model-View-Controller)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "데이터(Model), 사용자 인터페이스(View), 로직 제어(Controller)를 분리하여 시스템의 관심사를 격리함으로써, UI의 변화가 데이터 구조에 영향을 주지 않도록 설계하는 고전적이고 강력한 관심사 분리(SoC) 패턴."
+
+## 📖 구조화된 지식 (Synthesized Content)
+MVC는 애플리케이션의 구조적 무결성을 유지하기 위한 가장 널리 알려진 디자인 패턴입니다.
+
+1.  **구성 요소의 역할**:
+    *   **Model**: 애플리케이션의 데이터와 비즈니스 로직을 담당합니다. 데이터베이스와의 상호작용 및 상태 변화를 관리합니다.
+    *   **View**: 사용자에게 정보를 표시하는 인터페이스 레이어입니다. 모델의 데이터를 시각적으로 표현하며 로직은 포함하지 않습니다.
+    *   **Controller**: 사용자의 입력을 받아 모델을 업데이트하거나 뷰를 선택하는 제어 흐름을 담당합니다. 모델과 뷰 사이의 중재자 역할을 수행합니다.
+2.  **관심사 분리 (Separation of Concerns)**:
+    *   각 구성 요소가 독립적으로 개발 및 테스트될 수 있도록 격리합니다.
+    *   코드 리뷰 시, 뷰에 비즈니스 로직이 포함되어 있거나 모델이 UI 요소를 직접 참조하는지 등을 검토하여 패턴의 무결성을 확인합니다.
+3.  **시스템 확장성**:
+    *   일관된 구조를 유지함으로써 장기적인 유지보수 비용을 낮추고, 새로운 기능을 추가할 때 시스템 전체의 복잡성을 제어합니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **비대한 컨트롤러 (Fat Controller)**: 로직이 컨트롤러에 집중되어 코드가 비대해지는 현상이 자주 발생합니다. 이를 방지하기 위해 서비스 레이어(Service Layer)를 추가로 도입하여 비즈니스 로직을 모델이나 서비스로 분산시키는 전략이 필요합니다.
+- **현대적 변형**: 웹 프레임워크의 발전에 따라 MVP, MVVM 등 다양한 변형 패턴이 등장하였으나, 관심사 분리라는 핵심 철학은 MVC에서 계승되었습니다.
+
+## 🔗 지식 연결 (Graph)
+- [[Design Patterns]]: 아키텍처 패턴의 범주.
+- [[Clean Architecture]]: MVC를 보다 고도화한 계층화 구조.
+- [[SOLID Principles]]: 각 계층의 단일 책임을 정의하는 원칙.
+- [[Separation of Concerns (SoC)]]: 패턴의 근본적인 설계 철학.
+- [[Code Health]]: 일관된 패턴 준수가 가져오는 시스템의 건강성.
+---
@@ -0,0 +1,33 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-001
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, ooad, solid-principles, maintainability, code-review, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[SOLID Principles]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "소프트웨어의 유지보수성과 확장성을 보장하기 위한 5가지 핵심 설계 기둥: 인지적 부하를 낮추고, 변화에 유연하며, 결합도가 낮은 강건한 시스템을 구축하기 위한 객체지향 설계의 표준 지침."
+
+## 📖 구조화된 지식 (Synthesized Content)
+SOLID 원칙은 코드 리뷰와 시스템 설계의 무결성을 평가하는 핵심 기준입니다.
+
+1.  **[[Single Responsibility Principle (SRP)]]**: 클래스나 함수는 단 하나의 변경 이유만을 가져야 합니다. 모듈화를 통해 가독성과 테스트 용이성을 극대화합니다.
+2.  **Open-Closed Principle (OCP)**: 확장에는 열려 있고 수정에는 닫혀 있어야 합니다. 기존 코드를 건드리지 않고 새로운 기능을 추가할 수 있는 구조를 지향합니다.
+3.  **Liskov Substitution Principle (LSP)**: 하위 타입은 언제나 상위 타입으로 교체 가능해야 합니다. 상속 구조에서의 행동 일관성을 보장합니다.
+4.  **Interface Segregation Principle (ISP)**: 클라이언트가 사용하지 않는 메서드에 의존하도록 강요해서는 안 됩니다. 거대한 인터페이스보다 구체적이고 작은 인터페이스 여러 개가 낫습니다.
+5.  **[[Dependency Inversion Principle (DIP)]]**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 합니다. 구체적인 구현이 아닌 추상화에 의존하여 결합도를 낮춥니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **추상화의 비용**: 확장성을 위해 인터페이스와 추상화를 과도하게 도입할 경우, 코드의 직관성이 떨어지고 오버엔지니어링(Over-engineering)으로 이어질 수 있습니다. 현재의 요구사항과 미래의 유연성 사이의 실용적 타협(Trade-off)이 필수적입니다.
+- **실행 흐름 파악의 어려움**: DI(의존성 주입)를 극한으로 활용할 경우 런타임에 의존성이 결정되므로, 코드 정적 분석만으로는 전체 실행 흐름을 파악하기 어려워질 수 있습니다. 이를 보완하기 위한 명확한 문서화와 추적 로직이 필요합니다.
+
+## 🔗 지식 연결 (Graph)
+- [[Single Responsibility Principle (SRP)]]: 첫 번째 원칙의 심화.
+- [[Dependency Injection (DI)]]: DIP를 실현하는 구체적 기법.
+- [[Clean Architecture]]: SOLID를 애플리케이션 전체로 확장한 구조.
+- [[Abstraction & Over-engineering]]: 설계 시 경계해야 할 트레이드오프.
+- [[Test-Driven Development (TDD)]]: 테스트하기 좋은 코드를 만드는 원칙으로서의 연결.
+---
@@ -0,0 +1,36 @@
+---
+id: P-REINFORCE-AUTO-WIKI-ARCH-002
+category: "10_Wiki/💡 Topics/02_Architecture_Principles"
+confidence_score: 0.95
+tags: [architecture, srp, cohesion, refactoring, code-review, p-reinforce]
+last_reinforced: 2026-05-01
+---
+
+# [[Single Responsibility Principle (SRP)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> "하나의 모듈은 오직 하나의 변경 이유(Reason to change)만을 가져야 한다: 코드의 응집도를 높이고 복잡성을 분산하여, 버그 수정과 기능 확장이 다른 영역에 미치는 부작용을 최소화하는 설계의 기초."
+
+## 📖 구조화된 지식 (Synthesized Content)
+SRP는 객체 지향 설계의 첫 번째 단추이자 가장 보편적인 리뷰 기준입니다.
+
+1.  **단일 책임의 기준**:
+    *   클래스나 함수가 수행하는 '일(Task)'이 아니라, 그 코드를 관리하고 요구사항을 변경하는 '주체(Actor)'가 누구인가에 집중합니다.
+    *   비즈니스 로직, 데이터베이스 접근, UI 렌더링 등이 하나의 파일에 섞여 있다면 이는 명백한 SRP 위반입니다.
+2.  **코드 리뷰의 핵심 필터**:
+    *   리뷰어는 거대한 함수나 클래스를 발견했을 때 이를 논리적 단위로 쪼개도록 권고합니다.
+    *   모듈이 작아질수록 테스트 코드를 작성하기 쉬워지며, 특정 기능만 떼어내어 재사용하기 용이해집니다.
+3.  **결합도와 응집도**:
+    *   책임이 명확히 분리된 코드는 낮은 결합도(Low Coupling)와 높은 응집도(High Cohesion)를 가지게 되어, 전체 시스템의 유지보수 비용을 낮춥니다.
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과도한 파편화**: SRP를 극단적으로 적용할 경우 클래스와 파일 수가 기하급수적으로 증가하여 전체 시스템의 가독성을 해칠 수 있습니다. '논리적 연관성'이 높은 코드들은 적절한 수준에서 함께 유지하는 실용적 균형이 필요합니다.
+- **아키텍처적 부채**: 초기 설계 시 SRP를 무시하면 시간이 흐를수록 '신(God) 객체'가 탄생하며, 이는 리팩토링 비용을 기하급수적으로 증가시키는 주요 원인이 됩니다.
+
+## 🔗 지식 연결 (Graph)
+- [[SOLID Principles]]: 5대 원칙의 시작점.
+- [[Testability]]: 테스트하기 좋은 코드를 만드는 직접적 원인.
+- [[Refactoring]]: SRP 위반 시 리뷰어가 내리는 핵심 처방.
+- [[Clean Architecture]]: 책임을 계층별로 격리하는 거시적 구조.
+- [[Code Readability]]: 단순해진 코드가 가져오는 가독성 향상.
+---