---
id: P-REINFORCE-AUTO-57A5BA
category: "10_Wiki/💡 Topics/Design & Experience"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency Rule)"
---

# [[의존성 규칙 (Dependency Rule)|의존성 규칙 (Dependency Rule)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> 의존성 규칙(Dependency Rule)은 클린 아키텍처(Clean Architecture)의 핵심 원칙으로, 모든 소스 코드 의존성이 반드시 고수준의 핵심 비즈니스 로직을 향해 '안쪽으로만' 향해야 한다는 원칙입니다 [1-3]. 이 규칙은 내부 계층(뇌)이 외부 계층(팔다리)의 존재에 대해 전혀 알지 못하도록 통제하여 시스템의 결합도를 낮추고 독립성을 극대화합니다 [2-4]. 결과적으로 비즈니스의 본질적인 규칙을 UI, 데이터베이스, 프레임워크 등 변동성이 높은 기술적 세부 사항으로부터 완벽하게 격리하고 보호하는 역할을 수행합니다 [1, 4, 5].

## 📖 구조화된 지식 (Synthesized Content)
*   **의존성의 방향 (Direction of Dependencies)**
    의존성 규칙에 따르면 소프트웨어의 소스 코드 의존성은 오직 안쪽, 즉 중앙의 핵심 비즈니스 로직(엔티티 및 유스케이스 등)으로만 향해야 합니다 [1, 3]. 이는 저수준의 모듈(외부의 프레임워크나 UI)이 고수준의 모듈(내부의 도메인)에 의존해야 하며, 고수준 모듈은 외부 기관에 결코 의존해서는 안 된다는 것을 의미합니다 [2].

*   **내부 계층의 완전한 격리 (Isolation of Inner Layers)**
    내부의 원에 속한 코드(뇌)는 외부의 원에 선언된 어떤 것(팔다리)에 대해서도 그 이름을 언급해서는 안 됩니다 [3]. 즉, 함수, 클래스, 변수 등 외부에 존재하는 모든 소프트웨어 요소의 존재를 내부 계층은 몰라야 합니다 [3]. 이를 통해 외부의 인프라스트럭처가 변경되더라도 핵심 비즈니스 규칙이 영향을 받지 않도록 보장합니다 [4, 6].

*   **데이터 형식의 독립성 (Data Format Independence)**
    외부 원에서 선언된 데이터 형식이나 특정 프레임워크가 생성한 데이터 구조를 내부 원에서 절대로 사용해서는 안 됩니다 [3]. 계층의 경계를 가로질러 데이터를 전달할 때는, 데이터베이스의 행(Row) 같은 외부 포맷이 아닌 내부의 원에서 사용하기 편리한 형태(간단한 데이터 전송 객체나 구조체)로 변환되어 전달되어야 합니다 [6, 7]. 

*   **경계 횡단과 의존성 역전 원칙 (Crossing Boundaries and DIP)**
    시스템의 제어 흐름이 의존성 규칙과 반대 방향으로 향해야 하는 경우(예를 들어, 내부의 유스케이스 계층이 외부의 프레젠터 계층을 호출해야 할 때), 이를 직접 호출하면 의존성 규칙을 위배하게 됩니다 [8]. 이 문제는 의존성 역전 원칙(DIP)과 동적 다형성을 활용하여 해결합니다 [8, 9]. 내부 계층에 인터페이스를 정의하고 외부 계층이 이를 구현하게 함으로써, 제어 흐름이 밖으로 향하더라도 소스 코드 의존성은 계속 안쪽을 유지할 수 있게 만듭니다 [8-10].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[클린 아키텍처 (Clean Architecture)|클린 아키텍처 (Clean Architecture)]], [[의존성 역전 원칙 (Dependency Inversion Principle, DIP)|의존성 역전 원칙 (Dependency Inversion Principle, DIP)]], [[엔티티 (Entities)|엔티티 (Entities)]], [[유스케이스 (Use Cases)|유스케이스 (Use Cases)]]
- **Projects/Contexts:** [[엔터프라이즈 소프트웨어 시스템 설계|엔터프라이즈 소프트웨어 시스템 설계]], [[모듈화 및 아키텍처 경계 설정|모듈화 및 아키텍처 경계 설정]]
- **Contradictions/Notes:** 의존성 규칙을 엄격하게 준수하기 위해 완벽한 아키텍처 경계(쌍방향 다형적 인터페이스, 분리된 입/출력 데이터 구조 등)를 만드는 것은 초기 설정 및 유지보수 비용이 상당히 큽니다 [11]. 따라서 모든 상황에 이 규칙을 엄격히 적용하기보다는, 프로젝트의 규모에 따라 전략 패턴이나 퍼사드(Facade) 패턴을 활용한 부분적 경계(Partial Boundary)를 두거나 실무적 타협을 하는 경우도 존재합니다 [11-13].

---
*Last updated: 2026-04-18*
- Raw Source: 00_Raw/2026-04-20/의존성 규칙 (Dependency Rule).md
---