diff --git a/10_Wiki/Topics_Dev/Bounded_Context.md b/10_Wiki/Topics_Dev/Bounded_Context.md
new file mode 100644
index 00000000..0aa63ab2
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Bounded_Context.md
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-DEV-BOUNDED-CONTEXT
+title: "바운디드 컨텍스트와 도메인 모델 경계 (Bounded Context)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["Bounded Context", "바운디드 컨텍스트", "도메인 경계", "서브도메인", "언어의 경계"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["DDD", "Architecture", "Modularity", "Ubiquitous_Language", "System_Design"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[바운디드 컨텍스트와 도메인 모델 경계 (Bounded Context)]]
+
+## 1. 개요
+바운디드 컨텍스트(Bounded Context)는 도메인 주도 설계(DDD)의 핵심 개념으로, 거대하고 복잡한 비즈니스 도메인을 논리적으로 일관된 작은 하위 시스템으로 분할하는 설계 패턴이다. 각 컨텍스트는 고유한 모델과 유비쿼터스 언어(Ubiquitous Language)가 통용되는 명확한 경계(Boundary)를 가지며, 이를 통해 시스템 내의 용어 충돌을 방지하고 모듈 간의 자율성을 극대화한다.
+
+## 2. 핵심 메커니즘 및 특징
+- **언어의 경계**: 동일한 단어라도 컨텍스트에 따라 의미가 달라질 수 있다. 예를 들어, '상품'이라는 단어는 주문 컨텍스트에서는 '판매 대상'이지만, 배송 컨텍스트에서는 '무게와 부피를 가진 화물'로 해석된다. Bounded Context는 이러한 의미적 경계를 명확히 긋는다.
+- **모델의 일관성**: 하나의 컨텍스트 내부에서는 모델이 모순 없이 일관되게 동작해야 한다. 경계 밖의 모델과는 느슨하게 결합하며, 필요한 데이터는 컨텍스트 매핑(Context Mapping)을 통해 교환한다.
+- **팀과 코드의 독립성**: Bounded Context는 팀 단위의 조직 구조와도 밀접하게 연관되며(Conway's Law), 각 컨텍스트별로 최적화된 기술 스택과 독립적인 배포 파이프라인을 가질 수 있는 기술적 토대가 된다.
+
+## 3. 엔지니어링 가치
+- **복잡성 제어**: 시스템 전체를 한꺼번에 이해하려 하지 않고, 특정 비즈니스 목적을 가진 컨텍스트 단위로 쪼개어 인지 부하를 획기적으로 줄임.
+- **마이크로서비스 분할 표준**: 모놀리식 시스템을 마이크로서비스로 전환할 때, 기술적인 계층이 아닌 비즈니스 가치 중심의 서비스 경계를 설정하는 가장 강력한 기준 제공.
+- **결함 격리 및 유연성**: 한 컨텍스트 내부의 모델 변경이 다른 컨텍스트에 영향을 미치지 않도록 방어막(Anti-Corruption Layer 등)을 형성하여 시스템의 지속적인 진화 지원.
+
+## 4. 트레이드오프 및 주의사항
+- **설계 난이도 및 분석 비용**: 비즈니스 도메인에 대한 깊은 이해와 도메인 전문가와의 밀접한 협업이 필수적이며, 경계를 잘못 설정할 경우 컨텍스트 간 데이터 중복과 통신 오버헤드만 증가할 위험이 있음.
+- **통합의 복잡성**: 분리된 컨텍스트 간에 일관성을 유지하기 위해 이벤트 기반 통신이나 공유 커널(Shared Kernel) 등의 정교한 통합 전략 필요.
+- **오버엔지니어링 경계**: 단순한 도메인에서도 무리하게 컨텍스트를 쪼개는 것은 불필요한 추상화 오버헤드와 운영 비용만 발생시킬 수 있으므로 주의.
+
+## 5. 지식 연결 (Related)
+- [[Domain_Driven_Design]]: Bounded Context가 속한 상위 설계 방법론.
+- [[Microservices_Architecture]]: Bounded Context가 물리적으로 구현된 아키텍처 스타일.
+- [[Ubiquitous_Language]]: 각 컨텍스트 내부에서 사용하는 공통 언어 체계.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 대규모 시스템의 비즈니스 복잡성을 관리 가능한 단위로 분해하고, 기술 중심이 아닌 도메인 중심의 견고한 아키텍처를 구축하기 위한 설계 표준 정립.
diff --git a/10_Wiki/Topics_Dev/Dependency_Injection.md b/10_Wiki/Topics_Dev/Dependency_Injection.md
new file mode 100644
index 00000000..ce35a65d
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Dependency_Injection.md
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-DEV-DI
+title: "의존성 주입과 유연한 객체 조립 (Dependency Injection)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["DI", "의존성 주입", "Dependency Injection", "객체 조립", "제어의 역전"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Design_Patterns", "Dependency_Injection", "Clean_Architecture", "SOLID", "Testability"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[의존성 주입과 유연한 객체 조립 (Dependency Injection)]]
+
+## 1. 개요
+의존성 주입(DI, Dependency Injection)은 객체가 자신이 사용할 의존 객체를 내부에서 직접 생성(New)하지 않고, 외부(컨테이너 혹은 설정자)로부터 주입받는 설계 패턴이다. 이는 객체 간의 결합도를 낮추고 제어의 역전(IoC)을 실현하는 구체적인 수단으로, 변경에 유연하고 테스트가 용이한 고도화된 소프트웨어 구조를 구축하는 핵심 기법이다.
+
+## 2. 주입 방식의 분류
+- **생성자 주입 (Constructor Injection)**: 객체 생성 시점에 의존성을 필수로 전달받음. 객체의 불변성을 보장하고 누락된 의존성을 컴파일 타임에 확인 가능하여 가장 권장되는 방식.
+- **수정자 주입 (Setter Injection)**: 선택적인 의존성이 있거나 런타임에 의존성을 변경해야 할 경우 사용. 객체 생성 후 언제든 주입 가능하나, 주입되지 않은 상태로 사용될 위험 존재.
+- **인터페이스 주입 (Interface Injection)**: 의존성을 주입받는 메서드를 포함한 인터페이스를 구현하여 주입. 자바 등의 언어에서는 잘 사용되지 않음.
+
+## 3. 엔지니어링 가치
+- **결합도 완화 및 유연성 확보**: 클래스가 구체적인 구현체(Concrete Class)가 아닌 인터페이스에 의존하게 되므로, 코드 수정 없이도 설정만으로 다른 구현체(예: MySQL -> MongoDB)로 교체 가능.
+- **테스트 용이성 (Mocking)**: 실제 데이터베이스나 네트워크 서비스 대신 가짜 객체(Mock/Stub)를 주입하여, 환경에 구애받지 않고 핵심 비즈니스 로직을 독립적으로 정밀 테스트 가능.
+- **보일러플레이트 코드 감소**: DI 컨테이너(Spring, NestJS, Inversify 등)가 객체의 생명주기와 의존 관계 조립을 자동화해 주므로, 개발자는 핵심 로직 구현에만 집중 가능.
+
+## 4. 트레이드오프 및 주의사항
+- **가독성의 양면성**: 코드 수준에서 의존 관계가 명시적으로 드러나지 않고 컨테이너 설정에 숨겨져 있어, 시스템의 전체적인 실행 흐름(Runtime Flow)을 파악하기 위해 추가적인 학습과 도구 활용이 필요함.
+- **초기 학습 곡선**: DI 컨테이너의 동작 원리와 설정 방식을 숙지해야 하며, 잘못된 설정으로 인한 런타임 에러(Circular Dependency 등)를 디버깅하는 데 숙련도 요구.
+- **오버헤드**: 미미한 수준이지만 리플렉션(Reflection) 기반의 DI 프레임워크는 초기 구동 시 성능 저하가 있을 수 있음. 성능이 극도로 중요한 환경에서는 수동 주입이나 컴파일 타임 DI 고려 필요.
+
+## 5. 지식 연결 (Related)
+- [[Dependency_Inversion_Principle]]: DI의 상위 설계 원칙.
+- [[Clean_Architecture]]: DI를 통해 도메인 로직을 외부 환경으로부터 격리하는 아키텍처 모델.
+- [[Inversion_of_Control]]: DI를 포함하는 더 포괄적인 소프트웨어 설계 개념.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 객체 간의 결합을 끊고 시스템의 조립성과 테스트 가능성을 극대화하기 위한 현대 소프트웨어 개발의 필수 구현 표준 정립.
diff --git a/10_Wiki/Topics_Dev/Object_Oriented_Programming.md b/10_Wiki/Topics_Dev/Object_Oriented_Programming.md
new file mode 100644
index 00000000..6187fbf3
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Object_Oriented_Programming.md
@@ -0,0 +1,46 @@
+---
+id: P-REINFORCE-WIKI-DEV-OOP
+title: "객체 지향 프로그래밍과 고도화된 설계 패러다임 (OOP)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["OOP", "객체 지향 프로그래밍", "Object-Oriented Programming", "상속", "캡슐화"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["OOP", "Design_Principles", "Software_Engineering", "Modeling", "Clean_Code"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[객체 지향 프로그래밍과 고도화된 설계 패러다임 (OOP)]]
+
+## 1. 개요
+객체 지향 프로그래밍(OOP)은 데이터와 이를 처리하는 논리를 하나의 단위인 '객체(Object)'로 묶고, 객체 간의 협력을 통해 복잡한 소프트웨어를 구성하는 프로그래밍 패러다임이다. 단순히 데이터를 구조화하는 것을 넘어, 현실 세계의 개념을 코드로 전이시키고 변화에 유연하게 대응할 수 있는 시스템을 구축하기 위한 캡슐화, 상속, 다형성, 추상화의 4대 핵심 원칙을 기반으로 한다.
+
+## 2. 4대 핵심 원칙
+- **캡슐화 (Encapsulation)**: 데이터와 메서드를 하나로 묶고 외부 접근을 제한(정보 은닉)하여 객체의 내부 구현 변경이 외부에 영향을 주지 않도록 보호.
+- **상속 (Inheritance)**: 기존 클래스의 속성과 기능을 물려받아 재사용하고 확장. 코드 중복을 줄이고 계층 구조 형성.
+- **다형성 (Polymorphism)**: 동일한 인터페이스나 상위 클래스에 대해 서로 다른 구현체(객체)가 각자의 방식으로 동작하게 함으로써 유연한 교체 가능성 확보.
+- **추상화 (Abstraction)**: 복잡한 내부 로직은 숨기고 핵심적인 개념이나 인터페이스만 노출하여 사용자가 최소한의 지식으로 객체를 활용할 수 있게 함.
+
+## 3. 엔지니어링 가치
+- **모델링의 직관성**: 비즈니스 도메인의 개념을 클래스와 객체로 직접 매핑하여 설계자와 개발자 간의 의사소통 간극 해소.
+- **코드 재사용 및 유지보수성**: 상속과 합성을 통해 검증된 코드를 재사용하고, 특정 객체의 책임만 수정함으로써 시스템 전반의 안정성 유지.
+- **대규모 시스템의 복잡성 제어**: 시스템을 독립적인 객체들의 집합으로 분할함으로써 개발자가 한 번에 인지해야 하는 코드의 범위를 국소화.
+
+## 4. 트레이드오프 및 주의사항
+- **깊은 상속 계층의 위험**: 과도한 상속은 부모 클래스의 변경이 수많은 자식 클래스에 예측 불가능한 영향을 미치는 '취약한 기반 클래스' 문제 초래. 상속보다는 합성(Composition) 권장.
+- **인지 부하의 증가**: 수천 개의 클래스로 구성된 대규모 OOP 시스템은 객체 간의 호출 관계와 의존성 지도를 파악하기 위한 IDE 도구와 높은 숙련도 요구.
+- **성능 오버헤드**: 객체 생성과 메서드 호출 과정에서 발생하는 간접 참조 오버헤드가 있을 수 있으나, 현대의 하드웨어와 런타임 최적화(JIT 등)를 통해 대부분의 경우 무시 가능한 수준임.
+
+## 5. 지식 연결 (Related)
+- [[SOLID_Principles]]: OOP 설계를 건전하게 유지하기 위한 5대 가이드라인.
+- [[Design_Patterns]]: OOP에서 반복적으로 발생하는 설계 문제에 대한 검증된 해결책.
+- [[Clean_Code]]: 가독성 높고 의도가 명확한 OOP 코드를 작성하기 위한 실천법.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 현대 소프트웨어 개발의 주류 패러다임인 OOP의 핵심 원리를 정립하고, 대규모 시스템의 지속 가능한 설계를 위한 기반 지식 통합.
diff --git a/10_Wiki/Topics_Dev/Ports_and_Adapters.md b/10_Wiki/Topics_Dev/Ports_and_Adapters.md
new file mode 100644
index 00000000..5e1da840
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Ports_and_Adapters.md
@@ -0,0 +1,47 @@
+---
+id: P-REINFORCE-WIKI-DEV-PORTS-ADAPTERS
+title: "포트와 어댑터 아키텍처 및 인터페이스 설계 (Ports and Adapters)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["포트와 어댑터", "Ports and Adapters", "헥사고날 아키텍처", "Hexagonal Architecture", "어댑터 패턴"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Architecture", "Hexagonal", "Clean_Architecture", "Interface_Design", "DIP"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[포트와 어댑터 아키텍처 및 인터페이스 설계 (Ports and Adapters)]]
+
+## 1. 개요
+포트와 어댑터(Ports and Adapters) 아키텍처는 헥사고날 아키텍처(Hexagonal Architecture)로도 알려져 있으며, 애플리케이션의 핵심 비즈니스 로직을 외부 환경(UI, 데이터베이스, 외부 API 등)으로부터 완벽하게 격리하기 위한 설계 패턴이다. 내부 비즈니스 로직은 외부 세계와 소통하기 위한 규격인 '포트(인터페이스)'만 정의하고, 실제 외부 기술과의 연동은 이 포트를 구현한 '어댑터(구현체)'가 담당하게 함으로써 기술 변화에 무관한 견고한 도메인 중심 설계를 지향한다.
+
+## 2. 핵심 구성 요소
+- **포트 (Ports)**: 애플리케이션 핵심 계층에 정의된 인터페이스. 외부에서 내부로 들어오는 진입점(Primary/Inbound Port)과 내부에서 외부 인프라를 호출하는 규격(Secondary/Outbound Port)으로 나뉜다.
+- **어댑터 (Adapters)**: 포트를 통해 애플리케이션과 외부 기술을 연결하는 구체적인 구현체.
+  - **드라이빙 어댑터 (Driving Adapters)**: 사용자의 요청을 받아 포트를 호출 (예: REST Controller, CLI).
+  - **드리븐 어댑터 (Driven Adapters)**: 애플리케이션의 요청을 받아 외부 시스템과 통신 (예: DB Repository, Mail Client).
+- **의존성 규칙**: 모든 의존성은 외부에서 내부(도메인)로 향해야 한다. 도메인은 어댑터의 존재를 몰라야 하며, 오직 포트에 정의된 추상화된 규격에만 의존한다.
+
+## 3. 엔지니어링 가치
+- **기술 스택의 독립성**: 데이터베이스를 RDBMS에서 NoSQL로 바꾸거나, Web 프레임워크를 교체하더라도 애플리케이션의 핵심 비즈니스 로직은 전혀 수정할 필요가 없음.
+- **테스트 용이성 (Testability)**: 외부 인프라(어댑터) 없이도 포트에 모의 객체(Mock)를 연결하여 도메인 로직만 독립적으로 완벽하게 검증 가능.
+- **비즈니스 중심 설계**: 기술적인 제약 조건에 얽매이지 않고 비즈니스 요구사항과 유즈케이스 자체에 집중하여 시스템의 핵심 가치 구현 가능.
+
+## 4. 트레이드오프 및 주의사항
+- **구현 복잡도 증가**: 단순한 CRUD 애플리케이션에서도 인터페이스와 어댑터를 분리해야 하므로 초기 개발 공수와 코드량이 늘어날 수 있음.
+- **간접 참조 오버헤드**: 추상화 계층이 늘어남에 따라 코드를 직접 읽고 흐름을 파악하는 데 더 많은 인지 노력이 필요하며, IDE의 도움 없이 런타임 구현체를 찾기 어려울 수 있음.
+- **과도한 엔지니어링 경계**: 변화가 거의 확실하지 않은 영역까지 무리하게 포트/어댑터로 감싸는 것은 생산성을 저하시키는 오버엔지니어링이 될 수 있으므로 적절한 수준의 판단 요구됨.
+
+## 5. 지식 연결 (Related)
+- [[Clean_Architecture]]: 포트와 어댑터 개념을 구체화한 상위 아키텍처 프레임워크.
+- [[Dependency_Inversion_Principle]]: 포트와 어댑터를 가능하게 하는 핵심 설계 원칙.
+- [[Design_Patterns]]: 어댑터를 구현하는 실전적인 기법.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 비즈니스 로직을 기술적 환경으로부터 격리하여 시스템의 지속 가능성과 기술 변화 대응력을 극대화하기 위한 아키텍처 표준 정립.
diff --git a/10_Wiki/Topics_Dev/Single_Responsibility_Principle.md b/10_Wiki/Topics_Dev/Single_Responsibility_Principle.md
new file mode 100644
index 00000000..c88300d6
--- /dev/null
+++ b/10_Wiki/Topics_Dev/Single_Responsibility_Principle.md
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-DEV-SRP
+title: "단일 책임 원칙과 높은 응집도 (SRP)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["SRP", "단일 책임 원칙", "Single Responsibility Principle", "응집도", "책임 분리"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["SOLID", "Design_Principles", "Clean_Code", "Refactoring", "Modularity"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[단일 책임 원칙과 높은 응집도 (SRP)]]
+
+## 1. 개요
+단일 책임 원칙(SRP, Single Responsibility Principle)은 "하나의 클래스는 단 하나의 책임만을 가져야 하며, 클래스가 변경되어야 하는 이유는 오직 하나뿐이어야 한다"는 설계 원칙이다. 이는 객체 지향 설계의 핵심인 응집도(Cohesion)를 극대화하고 결합도(Coupling)를 낮추어, 소프트웨어를 더 이해하기 쉽고 변경에 강하며 테스트 가능한 구조로 만드는 기초 토대가 된다.
+
+## 2. 핵심 개념 및 판단 기준
+- **변경의 이유 (Reason to Change)**: 책임이란 곧 '변경의 근거'를 의미한다. 만약 기획 부서의 요구사항 변경과 데이터베이스 관리자의 구조 변경이 동시에 한 클래스의 수정을 유발한다면, 그 클래스는 두 가지 책임을 가진 것이다.
+- **응집도 (Cohesion)**: 클래스 내부의 메서드와 데이터들이 얼마나 밀접하게 관련되어 있는지의 척도. SRP를 준수할수록 응집도는 자연스럽게 높아진다.
+- **관심사의 분리**: 비즈니스 로직, 데이터 영속성, UI 렌더링, 입력 검증 등 서로 다른 도메인 관심사를 명확히 구분하여 개별 클래스나 모듈로 격리.
+
+## 3. 엔지니어링 가치
+- **유지보수 안정성**: 특정 기능을 수정할 때 해당 책임만을 전담하는 클래스만 고치면 되므로, 예상치 못한 사이드 이펙트(Side Effect)가 시스템 전반으로 퍼지는 위험 차단.
+- **코드 가독성 및 명확성**: 클래스의 이름과 구현 코드가 하나의 목적만을 지향하므로, 코드를 처음 읽는 개발자가 시스템의 의도를 신속하고 정확하게 파악 가능.
+- **재사용성 및 테스트 용이성**: 작고 명확한 책임을 가진 클래스는 다른 컨텍스트에서 재사용하기 쉽고, 모의 객체(Mock)를 활용한 단위 테스트 작성이 매우 간편함.
+
+## 4. 트레이드오프 및 주의사항
+- **클래스 폭발 (Class Explosion)**: 원칙을 너무 잘게 적용하면 시스템에 수많은 클래스가 생성되어 전체적인 오케스트레이션(흐름)을 파악하기 위한 인지적 비용이 증가할 수 있음. 적절한 수준의 추상화와 그룹화 필요.
+- **파편화된 로직**: 하나의 비즈니스 프로세스가 너무 많은 클래스에 흩어져 있으면 오히려 가독성을 해칠 수 있다. '변경의 이유'가 같은 로직은 하나로 묶는 균형 감각이 요구됨.
+- **점진적 리팩토링**: 거대한 레거시 클래스를 한 번에 분해하기보다는, 새로운 요구사항이 발생하거나 버그를 수정할 때마다 책임의 경계를 확인하며 점진적으로 분리할 것.
+
+## 5. 지식 연결 (Related)
+- [[SOLID_Principles]]: SRP를 포함한 객체 지향 설계의 5대 원칙.
+- [[Separation_of_Concerns]]: 시스템 전체 수준에서의 관심사 분리 철학.
+- [[Clean_Code]]: 명확한 책임을 가진 코드를 작성하기 위한 실무 기법.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 소프트웨어 모듈의 근본적인 단위인 클래스의 책임을 명확히 정의함으로써, 시스템의 유지보수성과 확장성을 보장하는 가장 강력한 설계 도구 정립.