[G1-Sync] Manual knowledge update

10_Wiki/Topics/Programming & Language/느슨한 결합 (Loose Coupling).md

@@ -1,5 +1,5 @@
 ---
-id: P-REINFORCE-AUTO-50EE48
+id: [[P-Reinforce]]-AUTO-50EE48
 category: "10_Wiki/💡 Topics/Programming & Language"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -19,20 +19,20 @@ github_commit: "[P-Reinforce] Continuous Worker - 느슨한 결합 (Loose Coupli
 * **주요 이점**
   * **유지보수 및 변경의 용이성**: 컴포넌트가 독립적이므로 요구사항 변화에 맞춰 특정 기능만 수정하면 되어 유지관리 비용과 기술적 부채가 감소합니다 [6, 10, 12].
   * **재사용성(Reusability) 증가**: 외부 의존성이 적기 때문에 잘 격리된 모듈은 다른 프로젝트나 환경에서도 쉽게 분리하여 재사용될 수 있습니다 [2, 6, 13].
-  * **테스트 용이성(Testability)**: 시스템 전체를 구동할 필요 없이, 실제 의존성 대신 가짜 객체(Mock)나 더미 데이터를 주입하여 개별 모듈을 독립적으로 단위 테스트할 수 있습니다 [6, 14-16].
+  * **테스트 용이성(Te[[Stability]])**: 시스템 전체를 구동할 필요 없이, 실제 의존성 대신 가짜 객체(Mock)나 더미 데이터를 주입하여 개별 모듈을 독립적으로 단위 테스트할 수 있습니다 [6, 14-16].
   * **병렬 개발 지원**: 여러 개발자나 팀이 서로의 작업에 간섭하지 않고 명확한 경계 내에서 독자적인 컴포넌트를 개발 및 배포할 수 있도록 돕습니다 [14, 17].
 
 * **느슨한 결합을 달성하기 위한 전략**
   * **인터페이스 및 추상화**: 구체적인 구현에 직접 의존하지 않고 명확한 인터페이스(계약)를 정의하여 상호작용함으로써 구현 세부 사항을 캡슐화합니다 [2, 12, 18, 19].
   * **의존성 주입(Dependency Injection, DI)**: 의존성 역전 원칙(DIP)을 활용하여 내부 모듈이 필요한 객체를 직접 생성하지 않고 외부로부터 주입받게 함으로써 컴포넌트 간 결합을 끊어냅니다 [2, 11, 18, 19].
-  * **이벤트 기반 아키텍처(Event-Driven Architecture)**: 컴포넌트 간 직접적인 API 호출을 피하고, 메시지 브로커나 이벤트를 통해 비동기적, 간접적으로 통신하게 만들어 시스템을 분리합니다 [2, 19, 20].
+  * **이벤트 기반 아키텍처(Event-Driven [[Architecture]])**: 컴포넌트 간 직접적인 API 호출을 피하고, 메시지 브로커나 이벤트를 통해 비동기적, 간접적으로 통신하게 만들어 시스템을 분리합니다 [2, 19, 20].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[관심사의 분리 (Separation of Concerns)]], [[응집도 (Cohesion)]], [[의존성 주입 (Dependency Injection)]], [[이벤트 기반 아키텍처 (Event-Driven Architecture)]], [[단일 책임 원칙 (SRP)]]
+- **Related Topics:** [[관심사의 분리 ([[Separation of Concerns]])]], [[응집도 (Cohesion)]], [[의존성 주입 (Dependency Injection)]], [[이벤트 기반 아키텍처 (Event-Driven Architecture)]], [[단일 책임 원칙 (SRP)]]
 - **Projects/Contexts:** [[마이크로서비스 아키텍처 (Microservices Architecture)]], [[클린 아키텍처 (Clean Architecture)]], [[계층화 아키텍처 (Layered Architecture)]]
 - **Contradictions/Notes:** 단순히 시스템을 마이크로서비스로 나눈다고 해서 결합이 완벽히 분리되는 것은 아니며, 네트워크상의 공유 자원이나 공통 데이터 구조에 의해 간접적으로 강하게 결합되는 '결합 분리의 오류'가 발생할 수 있습니다 [21]. 또한, 과도하게 세분화된 분리는 오히려 성능 오버헤드, 네트워크 통신 비용 증가 및 코드 추적의 복잡성을 초래할 수 있으므로 상황에 맞는 적절한 균형이 필요합니다 [22, 23].