6.3 KiB
id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack
| id | title | category | status | canonical_id | aliases | duplicate_of | source_trust_level | confidence_score | tags | raw_sources | last_reinforced | github_commit | inferred_by | tech_stack | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| wiki-2026-0508-의존성-규칙-dependency-rule | 의존성 규칙 (Dependency Rule) | 10_Wiki/Topics | needs_review | self |
|
none | A | 0.9 |
|
2026-04-20 | [P-Reinforce] Continuous Worker - 의존성 규칙 (Dependency Rule) | Claude Opus 4.7 (auto-normalize 2026-05-08) |
|
의존성 규칙 (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 & Updates)
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: Design & Experience 분야의 자동 자산화 수행.
🔗 지식 연결 (Graph)
- Related Topics: 클린 아키텍처 (Clean Architecture), 의존성 역전 원칙 (Dependency Inversion Principle, DIP), 엔티티 (Entities), 유스케이스 (Use Cases)
- Projects/Contexts: 엔터프라이즈 소프트웨어 시스템 설계, 모듈화 및 아키텍처 경계 설정
- Contradictions/Notes: 의존성 규칙을 엄격하게 준수하기 위해 완벽한 아키텍처 경계(쌍방향 다형적 인터페이스, 분리된 입/출력 데이터 구조 등)를 만드는 것은 초기 설정 및 유지보수 비용이 상당히 큽니다 [11]. 따라서 모든 상황에 이 규칙을 엄격히 적용하기보다는, 프로젝트의 규모에 따라 전략 패턴이나 퍼사드(Facade) 패턴을 활용한 부분적 경계(Partial Boundary)를 두거나 실무적 타협을 하는 경우도 존재합니다 [11-13].
Last updated: 2026-04-18
🤖 LLM 활용 힌트 (How to Use This Knowledge)
언제 이 지식을 쓰는가:
- (TODO)
언제 쓰면 안 되는가:
- (TODO)
🧪 검증 상태 (Validation)
- 정보 상태: needs_review
- 출처 신뢰도: A
- 검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)
🧬 중복 검사 (Duplicate Check)
- 기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
- 처리 방식: UPDATE (자동 정규화)
- 처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
🕓 변경 이력 (Changelog)
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|---|---|---|---|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
💻 코드 패턴 (Code Patterns)
패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)
# TODO
🤔 의사결정 기준 (Decision Criteria)
선택 A를 써야 할 때:
- (TODO)
선택 B를 써야 할 때:
- (TODO)
기본값:
(TODO)
❌ 안티패턴 (Anti-Patterns)
- [안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)