reinforce:wikify - Batch 21: Design Patterns & SOLID (5 artifacts)

2026-05-02 22:22:25 +09:00
parent e560c05e77
commit 052ec10e24
5 changed files with 208 additions and 22 deletions
@@ -0,0 +1,46 @@
+---
+id: P-REINFORCE-WIKI-DEV-DRY
+title: "DRY 원칙과 지식의 단일 표현 (Don't Repeat Yourself)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["DRY", "Don't Repeat Yourself", "중복 제거", "단일 진실 공급원", "SSOT"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Design_Principles", "Clean_Code", "Refactoring", "Efficiency", "Technical_Debt"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[DRY 원칙과 지식의 단일 표현 (Don't Repeat Yourself)]]
+
+## 1. 개요
+DRY(Don't Repeat Yourself) 원칙은 "시스템 내의 모든 지식은 단일하고, 명확하며, 신뢰할 수 있는 표현을 가져야 한다"는 소프트웨어 개발의 핵심 원칙이다. 이는 단순히 코드의 텍스트가 겹치는 '구문적 중복'을 넘어, 비즈니스 규칙이나 데이터 모델링 등의 '지식의 중복'을 제거함으로써 시스템의 복잡성을 낮추고 변경 시의 일관성을 보장하는 것을 목표로 한다.
+
+## 2. 주요 실천 방안
+- **추상화 및 모듈화**: 반복되는 로직을 재사용 가능한 함수, 유틸리티 클래스, 혹은 공통 라이브러리로 추출하여 중앙에서 관리.
+- **상속과 합성**: 객체 지향 언어의 특징을 활용하여 공통 속성과 동작을 기본 클래스(Base Class)에 배치하거나, 작은 컴포넌트들을 조합하여 복잡한 기능 구현.
+- **중앙 집중식 구성 관리**: DB 연결 정보, API 엔드포인트 등 환경 설정 값을 코드 곳곳에 하드코딩하지 않고, 중앙 설정 파일이나 환경 변수를 통해 관리(SSOT: Single Source of Truth).
+- **자동화된 코드 생성**: 반복적이고 정형화된 보일러플레이트(Boilerplate) 코드는 수동 작성이 아닌 템플릿 엔진이나 코드 생성기를 활용하여 오타와 누락 방지.
+
+## 3. 엔지니어링 가치
+- **수정의 효율성**: 특정 비즈니스 규칙이 변경될 때, 중복이 제거된 시스템에서는 단 한 곳의 코드만 수정하면 되므로 변경 비용이 획기적으로 절감됨.
+- **데이터 무결성 및 일관성**: 동일한 로직이 여러 곳에 흩어져 있어 발생할 수 있는 '일부 누락' 현상을 방지하여, 시스템 전반의 동작 신뢰성 확보.
+- **가독성 향상**: 핵심 로직이 명확하게 정의된 지점(Single Point of Truth)에 집중되어 있어, 개발자가 시스템의 의도를 파악하는 속도 향상.
+
+## 4. 트레이드오프 및 주의사항
+- **성급한 추상화(Premature Abstraction)의 위험**: 아직 명확한 패턴이 발견되지 않은 상태에서 무리하게 중복을 제거하려다 오히려 코드 구조가 복잡해질 수 있음. '3의 법칙(Rule of Three)'을 고려할 것.
+- **우연한 중복(Accidental Duplication)**: 모양은 같지만 비즈니스적 의미가 다른 두 코드를 억지로 하나로 묶으면, 향후 두 로직이 서로 다른 방향으로 진화할 때 강결합으로 인한 유지보수 대란 발생 가능.
+- **가독성과의 충돌**: 지나친 추상화는 코드를 직접적으로 읽는 것을 방해할 수 있다. 때로는 약간의 중복이 과도한 추상화보다 더 명확하고 단순할 때가 있음.
+
+## 5. 지식 연결 (Related)
+- [[Separation_of_Concerns]]: 중복을 제거하기 위해 코드를 어떤 기준으로 나누어야 하는지에 대한 원칙.
+- [[SOLID_Principles]]: 중복 제거와 설계의 건전성을 동시에 확보하기 위한 5대 원칙.
+- [[Technical_Debt]]: DRY 원칙을 무시했을 때 발생하는 유지보수 비용의 총칭.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 시스템의 일관성을 유지하고 변경에 기민하게 대응하기 위한 지식 관리 및 중복 제거 표준 정립.
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-DEV-DIP
+title: "의존성 역전 원칙과 유연한 시스템 결합 (DIP)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["DIP", "의존성 역전 원칙", "Dependency Inversion Principle", "추상화 의존", "결합도 낮추기"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["SOLID", "Design_Principles", "Architecture", "Dependency_Injection", "Clean_Architecture"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[의존성 역전 원칙과 유연한 시스템 결합 (DIP)]]
+
+## 1. 개요
+의존성 역전 원칙(DIP, Dependency Inversion Principle)은 객체 지향 설계의 5대 원칙인 SOLID 중 하나로, "고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다"는 원칙이다. 이는 시스템의 핵심 비즈니스 로직(고수준)이 구체적인 구현 기술이나 외부 도구(저수준)의 변화에 휘둘리지 않도록 의존성의 방향을 역전시켜 시스템의 유연성과 유지보수성을 극대화한다.
+
+## 2. 핵심 메커니즘
+- **추상화에 의존**: 상위 계층이 하위 계층의 구체적인 클래스를 직접 참조하는 대신, 인터페이스나 추상 클래스를 통해 소통하도록 설계.
+- **의존성 주입 (DI) 활용**: 클래스 내부에서 의존 객체를 직접 생성하지 않고, 외부(컨테이너나 설정자)로부터 주입받음으로써 런타임에 구체적인 구현체 결합.
+- **포트와 어댑터 구조**: 클린 아키텍처나 헥사고날 아키텍처에서 내부 로직(포트)이 인터페이스를 정의하고, 외부 도구(어댑터)가 이를 구현하게 함으로써 의존성을 안쪽으로 향하게 통제.
+
+## 3. 엔지니어링 가치
+- **기술 스택 교체 용이성**: 데이터베이스, 메시지 브로커, 외부 API 라이브러리 등을 변경하더라도 핵심 비즈니스 로직은 수정할 필요가 없거나 최소화됨.
+- **테스트 용이성 (Testability)**: 실제 하위 모듈 대신 가짜 객체(Mock, Stub)를 인터페이스에 주입하여 비즈니스 로직을 격리된 환경에서 정밀하게 검증 가능.
+- **모듈의 독립적 진화**: 인터페이스라는 계약(Contract)이 유지되는 한, 상위 모듈과 하위 모듈은 서로의 내부 구현 변경에 영향을 받지 않고 독자적으로 발전 가능.
+
+## 4. 트레이드오프 및 주의사항
+- **설계 복잡성 증가**: 인터페이스를 정의하고 의존성을 주입하는 구조를 잡기 위해 초기 설계 비용과 코드량이 늘어날 수 있음.
+- **런타임 흐름 파악의 어려움**: 정적인 코드 독해만으로는 현재 어떤 구체적인 구현체가 주입되어 동작하는지 즉각적으로 알기 어려울 수 있음. 디버깅 및 IDE 도구 활용 필수.
+- **오버엔지니어링 경계**: 변경 가능성이 거의 없는 지점까지 무분별하게 인터페이스를 도입하는 것은 불필요한 추상화 오버헤드만 초래할 수 있음.
+
+## 5. 지식 연결 (Related)
+- [[SOLID_Principles]]: DIP가 속한 상위 설계 원칙 체계.
+- [[Clean_Architecture]]: DIP를 통해 도메인을 보호하는 표준 아키텍처 모델.
+- [[Design_Patterns]]: DIP를 구현하는 실전적인 기법들(Strategy, Factory 등).
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 소프트웨어의 결합도를 획기적으로 낮추고 변화에 강한 유연한 아키텍처를 구축하기 위한 객체 지향 설계의 핵심 원칙 정립.
@@ -0,0 +1,48 @@
+---
+id: P-REINFORCE-WIKI-DEV-DESIGN-PATTERNS
+title: "디자인 패턴과 객체 지향 설계 템플릿 (Design Patterns)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["디자인 패턴", "Design Patterns", "생성 패턴", "구조 패턴", "행위 패턴"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Design_Patterns", "OOP", "Refactoring", "Code_Quality", "Software_Design"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[디자인 패턴과 객체 지향 설계 템플릿 (Design Patterns)]]
+
+## 1. 개요
+디자인 패턴은 소프트웨어 설계 과정에서 반복적으로 발생하는 문제들에 대해 검증된 공통의 해결책이자 설계 템플릿이다. 이는 특정 코드를 그대로 복사하는 것이 아니라, 문제를 해결하기 위해 자신의 상황에 맞춰 커스터마이징할 수 있는 일반적인 청사진을 제공한다. 개발 팀 내에서는 디자인 패턴을 통해 복잡한 설계 의도를 단일 용어로 소통할 수 있는 강력한 '공통 언어'로 활용한다.
+
+## 2. 주요 분류 체계 (GoF 기반)
+- **생성 패턴 (Creational Patterns)**: 객체의 생성 메커니즘을 추상화하여 시스템을 유연하게 만드는 패턴.
+  - *예: 싱글톤(Singleton), 팩토리 메서드(Factory Method), 빌더(Builder), 추상 팩토리(Abstract Factory).*
+- **구조 패턴 (Structural Patterns)**: 클래스나 객체를 조합하여 더 큰 구조를 형성하고 결합도를 낮추는 패턴.
+  - *예: 어댑터(Adapter), 퍼사드(Facade), 데코레이터(Decorator), 프록시(Proxy), 컴포지트(Composite).*
+- **행위 패턴 (Behavioral Patterns)**: 객체 간의 책임 분산과 알고리즘의 통신 방식을 정의하는 패턴.
+  - *예: 옵저버(Observer), 전략(Strategy), 커맨드(Command), 상태(State), 템플릿 메서드(Template Method).*
+
+## 3. 엔지니어링 가치
+- **코드 독해 가속화**: 낯선 코드베이스에서 `Strategy`나 `Facade`와 같은 패턴 명칭을 발견하는 즉시 해당 클래스의 역할과 상호작용 방식을 추론할 수 있어 인지적 부하 급감.
+- **유지보수성 향상**: 결합도는 낮추고 응집도는 높이는 검증된 구조를 적용함으로써, 요구사항 변경 시 기존 코드의 수정을 최소화하고 안전하게 확장 가능.
+- **검증된 설계 자산**: 수십 년간 엔지니어링 커뮤니티에서 검증된 최적의 구조를 재사용함으로써 설계 오류와 시행착오를 대폭 줄임.
+
+## 4. 트레이드오프 및 주의사항
+- **오버엔지니어링의 위험**: 단순한 문제에 복잡한 패턴을 억지로 끼워 맞추는 행위는 오히려 코드의 가독성을 해치고 불필요한 추상화 계층만 늘릴 수 있음 (패턴 지상주의 경계).
+- **언어적 한계와 패턴의 소멸**: 현대적인 프로그래밍 언어들은 과거 디자인 패턴으로 해결하던 많은 문제를 언어 자체의 기능(함수형 프로그래밍, 일급 객체 등)으로 내재화하고 있어, 패턴의 필요성을 비판적으로 검토해야 함.
+- **코드 중복과 변질**: 패턴을 기계적으로 적용하다 보면 유사한 구조의 코드가 반복될 수 있으며, 시간이 흐름에 따라 초기 의도와 다르게 변질된 패턴은 기술적 부채가 됨.
+
+## 5. 지식 연결 (Related)
+- [[Architecture_Styles]]: 디자인 패턴이 적용되는 더 큰 규모의 시스템 구조.
+- [[SOLID_Principles]]: 디자인 패턴의 근간이 되는 객체 지향 설계의 5대 원칙.
+- [[Code_Smells]]: 패턴이 잘못 적용되었거나 해체가 필요한 징후들.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 소프트웨어의 미시적 구조를 체계화하고 팀 간의 설계 의사소통 효율을 극대화하기 위한 객체 지향 설계 표준 정립.
@@ -1,46 +1,47 @@
 ---
 id: P-REINFORCE-WIKI-DEV-SOLID
-title: "객체 지향 설계 5원칙 (SOLID Principles)"
+title: "SOLID 원칙과 객체 지향 설계의 건전성 (SOLID Principles)"
 category: "10_Wiki/💻 Topics_Dev"
 status: verified
 canonical_id: ""
-aliases: ["SOLID", "객체 지향 설계 원칙", "클린 코드 원칙"]
+aliases: ["SOLID", "SOLID 원칙", "객체 지향 설계 원칙", "객체 지향 5대 원칙", "로버트 마틴"]
 duplicate_of: ""
 source_trust_level: A
 confidence_score: 1.0
-tags: ["OOP", "SOLID", "Clean_Code", "Design_Principles", "Maintainability"]
+tags: ["SOLID", "OOP", "Design_Principles", "Clean_Code", "Refactoring"]
 raw_sources: ["Datacollector_Export_2026-05-02"]
 last_reinforced: 2026-05-02
 github_commit: ""
 ---

-# [[객체 지향 설계 5원칙 (SOLID Principles)]]
+# [[SOLID 원칙과 객체 지향 설계의 건전성 (SOLID Principles)]]

 ## 1. 개요
-SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더욱 유연하고 유지보수하기 좋게 만들기 위해 고안된 5가지 설계 원칙의 집합이다. 로버트 C. 마틴에 의해 체계화되었으며, 결합도를 낮추고 응집도를 높이는 견고한 코드베이스의 기초가 된다.
+SOLID 원칙은 객체 지향 프로그래밍과 설계(OOAD)에서 소프트웨어를 더 이해하기 쉽고, 유연하며, 유지보수하기 좋게 만들기 위해 고안된 5가지 설계 원칙의 집합이다. 로버트 C. 마틴이 정리한 이 원칙들은 구성 요소 간의 결합도를 낮추고 응집도를 높임으로써, 시스템의 일부분을 변경하더라도 다른 부분에 미치는 영향을 최소화하는 견고한 아키텍처의 토대를 제공한다.

-## 2. 5대 원칙 (Five Principles)
-1.  **SRP (Single Responsibility Principle, 단일 책임 원칙)**: 클래스는 단 하나의 변경 이유만 가져야 한다. (하나의 클래스는 하나의 역할만 수행)
-2.  **OCP (Open/Closed Principle, 개방-폐쇄 원칙)**: 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다. (기존 코드 변경 없이 기능 추가 가능해야 함)
-3.  **LSP (Liskov Substitution Principle, 리스코프 치환 원칙)**: 하위 타입은 언제나 자신의 상위 타입으로 교체될 수 있어야 한다.
-4.  **ISP (Interface Segregation Principle, 인터페이스 분리 원칙)**: 자신이 사용하지 않는 메서드에 의존하도록 강제해서는 안 된다. (구체적인 여러 인터페이스가 범용 하나보다 낫다)
-5.  **DIP (Dependency Inversion Principle, 의존성 역전 원칙)**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.
+## 2. 5대 핵심 원칙
+- **S (SRP: Single Responsibility Principle)**: 클래스는 단 하나의 변경 이유(책임)만 가져야 한다. 하나의 클래스가 너무 많은 역할을 수행하지 않도록 분리.
+- **O (OCP: Open/Closed Principle)**: 소프트웨어 요소는 확장에 대해서는 열려 있어야 하지만 수정에 대해서는 닫혀 있어야 한다. 기존 코드를 고치지 않고 기능을 추가할 수 있도록 설계(추상화 활용).
+- **L (LSP: Liskov Substitution Principle)**: 서브타입은 언제나 자신의 기반 타입(Base Type)으로 교체할 수 있어야 한다. 상속 구조에서 자식 클래스가 부모 클래스의 계약을 위반하지 않도록 보장.
+- **I (ISP: Interface Segregation Principle)**: 클라이언트는 자신이 사용하지 않는 메서드에 의존하도록 강제되어서는 안 된다. 범용 인터페이스 하나보다 구체적인 인터페이스 여러 개로 분리.
+- **D (DIP: Dependency Inversion Principle)**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다. 의존성 주입(DI)을 통해 구현 기술로부터 비즈니스 로직을 보호.

-## 3. 실전 적용 팁
- **SRP부터 시작**: 클래스의 역할을 분리하는 것만으로도 코드의 복잡성이 획기적으로 줄어든다.
- **인터페이스 우선 설계**: 구현체보다 인터페이스(Contract)를 먼저 정의하여 자연스럽게 OCP와 DIP를 준수하도록 유도한다.
- **점진적 리팩토링**: 레거시 코드를 한꺼번에 바꾸기보다 신규 기능 추가 시 해당 영역에 원칙을 적용하며 개선한다.
+## 3. 엔지니어링 가치
+- **변경에 유연한 구조**: 비즈니스 요구사항이 변할 때 코드의 대대적인 수정 없이도 안전하게 기능을 확장하거나 변경 가능.
+- **테스트 가능성 향상**: 결합도가 낮고 인터페이스 기반으로 설계되어 있어, 개별 모듈을 독립적으로 테스트하거나 모의 객체(Mock)로 대체하기 용이함.
+- **코드 가독성 및 재사용성**: 각 클래스의 역할이 명확하고(SRP) 모듈 간의 연결이 추상화되어 있어(DIP), 코드를 처음 접하는 개발자도 구조를 빠르게 이해하고 필요한 부분을 재사용 가능.

-## 4. 트레이드오프
- **장점**: 코드 재사용성 향상, 테스트 용이성, 변화에 유연한 대응.
- **단점**: 인터페이스 및 추상화 도입으로 인해 초기 설계 비용과 보일러플레이트 코드 증가.
+## 4. 트레이드오프 및 주의사항
+- **초기 설계 오버헤드**: 원칙을 지키기 위해 더 많은 인터페이스와 클래스를 정의해야 하므로, 초기 개발 속도가 다소 느려질 수 있음.
+- **과도한 추상화의 함정**: 모든 곳에 SOLID를 강박적으로 적용하면 코드가 파편화되어 오히려 전체적인 흐름을 파악하기 어려워질 수 있음(인지 부하 증가).
+- **점진적 적용의 미학**: 레거시 시스템을 단번에 SOLID로 바꾸려 하기보다, 새로운 기능을 추가하거나 버그를 수정할 때 해당 영역부터 점진적으로 개선하는 것이 현실적임.

 ## 5. 지식 연결 (Related)
- [[Clean_Architecture]]: SOLID 원칙이 대규모 시스템 레이어 분리에 적용된 결과물.
- [[Dependency_Injection]]: DIP를 실현하기 위한 핵심 기술적 수단.
- [[Design_Patterns]]: SOLID 원칙을 특정 문제 해결에 맞게 구체화한 검증된 패턴들.
+- [[Design_Patterns]]: SOLID 원칙을 실현하기 위한 구체적인 구현 템플릿들.
+- [[Clean_Architecture]]: SOLID 원칙이 시스템 전반의 레이어 분리에 적용된 사례.
+- [[Dependency_Inversion_Principle]]: SOLID 원칙 중 아키텍처적으로 가장 영향력이 큰 원칙.

 ## 🧪 검증 상태 (Validation)
 - **정보 상태**: 검증 완료 (Verified)
 - **출처 신뢰도**: A
- **검토 이유**: 소프트웨어 공학의 정수인 SOLID 원칙의 명확한 정의와 실천 방안 수록.
+- **검토 이유**: 객체 지향 시스템의 건전성을 평가하고 지속 가능한 코드베이스를 유지하기 위한 글로벌 설계 표준 정립.
@@ -0,0 +1,46 @@
+---
+id: P-REINFORCE-WIKI-DEV-SOC
+title: "관심사의 분리와 모듈형 시스템 설계 (SoC)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["SoC", "관심사의 분리", "Separation of Concerns", "모듈화", "계층 분리"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Design_Principles", "Architecture", "Modularity", "Complexity_Management", "Clean_Code"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[관심사의 분리와 모듈형 시스템 설계 (SoC)]]
+
+## 1. 개요
+관심사의 분리(SoC, Separation of Concerns)는 컴퓨터 프로그램을 서로 겹치지 않는 뚜렷한 섹션(관심사)으로 나누어 설계하는 소프트웨어 엔지니어링의 핵심 원칙이다. "Divide and Conquer(분할 정복)" 전략을 소프트웨어 아키텍처에 적용한 것으로, 하나의 컴포넌트가 너무 많은 무관한 책임을 지는 것을 방지하여 복잡성을 제어하고 시스템의 이해도를 높이는 데 기여한다.
+
+## 2. 주요 실천 방식 및 패턴
+- **계층형 아키텍처 (Layered Architecture)**: 프레젠테이션, 비즈니스 로직, 데이터 접근 계층 등 수평적으로 책임을 나누어 인접 계층하고만 소통.
+- **MVC (Model-View-Controller)**: 사용자 인터페이스(View), 비즈니스 데이터(Model), 흐름 제어(Controller)를 분리하여 UI 변경이 로직에 미치는 영향 최소화.
+- **마이크로서비스 (Microservices)**: 비즈니스 도메인 단위로 아예 물리적 프로세스를 분리하여 극단적인 수준의 SoC 구현.
+- **횡단 관심사 분리 (AOP)**: 로깅, 보안, 트랜잭션 등 여러 모듈에 공통적으로 나타나는 '횡단 관심사'를 비즈니스 로직과 분리하여 별도로 관리.
+
+## 3. 엔지니어링 가치
+- **복잡성 관리**: 거대한 시스템을 인간이 한 번에 인지할 수 있는 작은 단위로 조각내어 개발 및 유지보수 효율성 증대.
+- **코드 재사용성 및 교체 용이성**: 특정 관심사(예: 데이터베이스 접근)가 격리되어 있어, 다른 모듈의 수정 없이 해당 관심사를 담당하는 코드만 교체하거나 재사용 가능.
+- **병렬 개발 가속화**: 명확한 경계와 인터페이스가 정의되어 있으면, 여러 개발자가 서로의 코드 간섭 없이 서로 다른 계층을 동시에 개발 가능.
+
+## 4. 트레이드오프 및 주의사항
+- **인지 부하의 전이**: 너무 잘게 쪼개진 모듈은 전체적인 시스템의 동작 흐름을 한눈에 파악하기 어렵게 만들 수 있음(인지 부하가 파일 내부에서 파일 간 관계로 전이).
+- **설계 오버헤드**: 초기 단계에서 명확한 경계를 설정하기 위한 설계 노력이 많이 필요하며, 경계가 잘못 설정될 경우 계층 간의 데이터 전달 비용만 증가하는 '만능 계층' 문제 발생.
+- **강결합의 유혹**: 편의를 위해 다른 관심사의 코드를 한 곳에 섞기 시작하면 순식간에 '스파게티 코드'로 변질되므로, 지속적인 아키텍처 위반 검토 필요.
+
+## 5. 지식 연결 (Related)
+- [[SOLID_Principles]]: SoC를 객체 수준에서 구현한 단일 책임 원칙(SRP)을 포함하는 설계 체계.
+- [[Clean_Architecture]]: 관심사 분리를 극대화하여 도메인을 보호하는 설계 사상.
+- [[Modular_Programming]]: SoC를 실현하기 위한 구체적인 프로그래밍 패러다임.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 시스템의 복잡성을 관리 가능한 수준으로 제어하고, 각 모듈의 독립성과 재사용성을 확보하기 위한 근본적인 소프트웨어 설계 원칙 정립.