docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,13 +1,13 @@
|
||||
---
|
||||
id: P-REINFORCE-AUTO-1BA61A
|
||||
category: "[[10_Wiki/💡 Topics/Programming & Language]]"
|
||||
category: "10_Wiki/💡 Topics/Programming & Language"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리(SoC)"
|
||||
---
|
||||
|
||||
# [[관심사의 분리(SoC)]]
|
||||
# [[관심사의 분리(SoC)|관심사의 분리(SoC)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 관심사의 분리(SoC, Separation of Concerns)는 소프트웨어 시스템을 각기 다른 기능이나 책임(관심사)에만 집중하는 작고 관리하기 쉬운 독립적인 모듈로 나누는 소프트웨어 엔지니어링의 핵심 설계 원칙이다 [1-5]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 처음 제안한 개념으로, 복잡성을 통제하고 코드의 모듈성, 가독성, 유지보수성, 확장성 및 재사용성을 크게 향상시키는 것을 목표로 한다 [3, 4, 6, 7]. 이 철학은 객체 지향 설계의 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP) 등 현대 아키텍처 패턴이 탄생하는 직접적인 근간이 되었다 [5, 8-10].
|
||||
@@ -32,13 +32,13 @@ github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리(SoC)"
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[단일 책임 원칙(SRP)]], [[응집도(Cohesion)와 결합도(Coupling)]], [[계층화 아키텍처(Layered Architecture)]], [[모델-뷰-컨트롤러(MVC)]], [[관점 지향 프로그래밍(AOP)]]
|
||||
- **Projects/Contexts:** [[넷플릭스 코스모스(Cosmos) 플랫폼]], [[스포티파이 스쿼드(Squad) 및 마이크로 프론트엔드]], [[화신산(Huoshen Mountain) 병원 모듈러 통합 건설(MiC)]]
|
||||
- **Related Topics:** [[단일 책임 원칙(SRP)|단일 책임 원칙(SRP)]], 응집도(Cohesion)와 결합도(Coupling), [[계층화 아키텍처 (Layered Architecture)|계층화 아키텍처(Layered Architecture)]], 모델-뷰-컨트롤러(MVC), [[관점 지향 프로그래밍(AOP)|관점 지향 프로그래밍(AOP)]]
|
||||
- **Projects/Contexts:** 넷플릭스 코스모스(Cosmos) 플랫폼, 스포티파이 스쿼드(Squad) 및 마이크로 프론트엔드, 화신산(Huoshen Mountain) 병원 모듈러 통합 건설(MiC)
|
||||
- **Contradictions/Notes:**
|
||||
* "SoC를 도입하면 유지보수와 모듈성이 향상된다"는 원칙이 일반적이나, "지나친 관심사 분리와 추상화는 간접 참조를 늘리고 런타임 성능 저하 및 코드 추적의 어려움을 유발하여 실무적 복잡성을 오히려 가중시킨다"는 경고와 상충하는 지점이 있다 [42-45].
|
||||
* 관심사의 선제적인 도출이 필수적이라는 견해가 있는 반면, 다른 실무자들은 초기에 관심사를 미리 예측해 분리하는 것은 불가능에 가까우며, 코드가 중복되어 나타날 때(Rule of Three) 사후적으로 리팩토링을 통해 분리하는 것(DRY 관점)이 현실적이라는 상반된 주장을 한다 [45, 46].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
- Raw Source: [[00_Raw/2026-04-20/관심사의 분리(SoC).md]]
|
||||
- Raw Source: 00_Raw/2026-04-20/관심사의 분리(SoC).md
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user