[G1-Sync] Manual knowledge update

10_Wiki/Topics/Design & Experience/의존성 규칙 (Dependency Rule).md

@@ -1,5 +1,5 @@
 ---
-id: P-REINFORCE-AUTO-57A5BA
+id: [[P-Reinforce]]-AUTO-57A5BA
 category: "10_Wiki/💡 Topics/Design & Experience"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -10,7 +10,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency R
 # [[의존성 규칙 (Dependency Rule)]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 의존성 규칙(Dependency Rule)은 클린 아키텍처(Clean Architecture)의 핵심 원칙으로, 모든 소스 코드 의존성이 반드시 고수준의 핵심 비즈니스 로직을 향해 '안쪽으로만' 향해야 한다는 원칙입니다 [1-3]. 이 규칙은 내부 계층(뇌)이 외부 계층(팔다리)의 존재에 대해 전혀 알지 못하도록 통제하여 시스템의 결합도를 낮추고 독립성을 극대화합니다 [2-4]. 결과적으로 비즈니스의 본질적인 규칙을 UI, 데이터베이스, 프레임워크 등 변동성이 높은 기술적 세부 사항으로부터 완벽하게 격리하고 보호하는 역할을 수행합니다 [1, 4, 5].
+> 의존성 규칙(Dependency Rule)은 클린 아키텍처(Clean [[Architecture]])의 핵심 원칙으로, 모든 소스 코드 의존성이 반드시 고수준의 핵심 비즈니스 로직을 향해 '안쪽으로만' 향해야 한다는 원칙입니다 [1-3]. 이 규칙은 내부 계층(뇌)이 외부 계층(팔다리)의 존재에 대해 전혀 알지 못하도록 통제하여 시스템의 결합도를 낮추고 독립성을 극대화합니다 [2-4]. 결과적으로 비즈니스의 본질적인 규칙을 UI, 데이터베이스, 프레임워크 등 변동성이 높은 기술적 세부 사항으로부터 완벽하게 격리하고 보호하는 역할을 수행합니다 [1, 4, 5].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **의존성의 방향 (Direction of Dependencies)**
@@ -22,7 +22,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency R
 *   **데이터 형식의 독립성 (Data Format Independence)**
     외부 원에서 선언된 데이터 형식이나 특정 프레임워크가 생성한 데이터 구조를 내부 원에서 절대로 사용해서는 안 됩니다 [3]. 계층의 경계를 가로질러 데이터를 전달할 때는, 데이터베이스의 행(Row) 같은 외부 포맷이 아닌 내부의 원에서 사용하기 편리한 형태(간단한 데이터 전송 객체나 구조체)로 변환되어 전달되어야 합니다 [6, 7]. 
 
-*   **경계 횡단과 의존성 역전 원칙 (Crossing Boundaries and DIP)**
+*   **경계 횡단과 의존성 역전 원칙 (Crossing [[Boundaries]] and DIP)**
     시스템의 제어 흐름이 의존성 규칙과 반대 방향으로 향해야 하는 경우(예를 들어, 내부의 유스케이스 계층이 외부의 프레젠터 계층을 호출해야 할 때), 이를 직접 호출하면 의존성 규칙을 위배하게 됩니다 [8]. 이 문제는 의존성 역전 원칙(DIP)과 동적 다형성을 활용하여 해결합니다 [8, 9]. 내부 계층에 인터페이스를 정의하고 외부 계층이 이를 구현하게 함으로써, 제어 흐름이 밖으로 향하더라도 소스 코드 의존성은 계속 안쪽을 유지할 수 있게 만듭니다 [8-10].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
@@ -30,7 +30,7 @@ github_commit: "[P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency R
 - **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[클린 아키텍처 (Clean Architecture)]], 의존성 역전 원칙 (Dependency Inversion Principle, DIP), [[엔티티 (Entities)]], [[유스케이스 (Use Cases)]]
+- **Related Topics:** [[클린 아키텍처 (Clean Architecture)]], 의존성 역전 원칙 (Dependency [[Inversion]] Principle, DIP), [[엔티티 (Entities)]], [[유스케이스 (Use Cases)]]
 - **Projects/Contexts:** [[엔터프라이즈 소프트웨어 시스템 설계]], [[모듈화 및 아키텍처 경계 설정]]
 - **Contradictions/Notes:** 의존성 규칙을 엄격하게 준수하기 위해 완벽한 아키텍처 경계(쌍방향 다형적 인터페이스, 분리된 입/출력 데이터 구조 등)를 만드는 것은 초기 설정 및 유지보수 비용이 상당히 큽니다 [11]. 따라서 모든 상황에 이 규칙을 엄격히 적용하기보다는, 프로젝트의 규모에 따라 전략 패턴이나 퍼사드(Facade) 패턴을 활용한 부분적 경계(Partial Boundary)를 두거나 실무적 타협을 하는 경우도 존재합니다 [11-13].