docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links
This commit is contained in:
Antigravity Agent
@@ -1,20 +1,20 @@
|
||||
---
|
||||
id: [[P-Reinforce]]-AUTO-FE2B8D
|
||||
id: [[P-Reinforce|P-Reinforce]]-AUTO-FE2B8D
|
||||
category: "10_Wiki/💡 Topics/Programming & Language"
|
||||
confidence_score: 0.90
|
||||
tags: [auto-reinforced]
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 ([[Separation of Concerns]])"
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 ([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])"
|
||||
---
|
||||
|
||||
# [[관심사의 분리 (Separation of Concerns)]]
|
||||
# [[관심사의 분리 (Separation of Concerns)|관심사의 분리 (Separation of Concerns]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 관심사의 분리(SoC)는 소프트웨어 설계에서 프로그램의 각 부분이 서로 다른 고유한 기능이나 특정 관심사에만 집중하도록 시스템을 논리적 단위로 나누는 근본적인 원칙입니다 [1-3]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 인간의 지적 한계로 인한 복잡성을 통제하기 위해 제안한 개념으로, 시스템을 관리하기 쉬운 조각으로 분해하여 모듈성, 유지보수성, 재사용성 및 확장성을 극대화하는 것을 목표로 합니다 [1, 3-6]. 시스템의 핵심 비즈니스 로직과 기술적 세부 사항을 명확히 격리함으로써, 변화에 유연하게 대응하고 진화할 수 있는 견고한 아키텍처를 구축하는 데 필수적인 철학입니다 [7-9].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**기원과 철학적 패러다임**
|
||||
* 관심사 분리의 기원은 에츠허르 데이크스트라가 1974년 발표한 에세이 "과학적 사고의 역할에 관하여"로 거슬러 올라갑니다 [3]. 그는 복잡한 문제를 해결할 때 인간의 정신이 압도당하지 않도록 특정 측면에 주의를 집중하고 다른 측면을 분리해서 사고하는 것이 지적 사고의 핵심이라고 강조했습니다 [3, 6]. 이 원칙은 후대 학자들에 의해 소프트웨어 모듈성([[Modularity]])을 확보하는 일차적인 방법으로 정립되었으며, 객체 지향 설계의 SOLID 원칙(특히 단일 책임 원칙과 인터페이스 분리 원칙)의 모태가 되었습니다 [3, 7].
|
||||
* 관심사 분리의 기원은 에츠허르 데이크스트라가 1974년 발표한 에세이 "과학적 사고의 역할에 관하여"로 거슬러 올라갑니다 [3]. 그는 복잡한 문제를 해결할 때 인간의 정신이 압도당하지 않도록 특정 측면에 주의를 집중하고 다른 측면을 분리해서 사고하는 것이 지적 사고의 핵심이라고 강조했습니다 [3, 6]. 이 원칙은 후대 학자들에 의해 소프트웨어 모듈성([[Modularity|Modularity]])을 확보하는 일차적인 방법으로 정립되었으며, 객체 지향 설계의 SOLID 원칙(특히 단일 책임 원칙과 인터페이스 분리 원칙)의 모태가 되었습니다 [3, 7].
|
||||
|
||||
**"뇌와 팔다리의 분리" 은유 (핵심 구조)**
|
||||
* 관심사 분리를 가장 직관적으로 설명하는 비유는 시스템을 '뇌(Brain)'와 '팔다리(Limbs)'로 구분하는 것입니다 [7].
|
||||
@@ -35,9 +35,9 @@ github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 ([[Separat
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[응집도와 결합도 (Cohesion and Coupling)]], [[클린 아키텍처 (Clean [[Architecture]])]], [[단일 책임 원칙 (Single Responsibility Principle)]], [[의존성 규칙 (Dependency Rule)]]
|
||||
- **Projects/Contexts:** 넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform), [[스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro [[Frontend]]s)]], 화신산 병원 모듈러 통합 건설 (Huoshenshan Hospital Modular Construction)
|
||||
- **Contradictions/Notes:** 관심사의 분리는 시스템의 복잡성을 낮추지만, 맹목적으로 추구하여 과도하게 분리할 경우 함수 호출의 깊이 증가, 네트워크 지연, 데이터 변환 오버헤드 등 성능 저하를 초래할 수 있습니다 [30]. 또한 지나친 추상화는 개발자를 미궁에 빠뜨려 가독성을 저하시키는 '오버엔지니어링'의 부작용을 낳을 수 있으므로, 유사 코드가 최소 3번 이상 중복될 때 추상화를 고려하는 "[[Rule of Three]]"를 참고하여 실무적인 분리의 임계점을 찾아야 합니다 [31, 32].
|
||||
- **Related Topics:** [[응집도와 결합도 (Cohesion and Coupling)|응집도와 결합도 (Cohesion and Coupling]], 클린 아키텍처 (Clean Architecture), [[단일 책임 원칙 (Single Responsibility Principle)|단일 책임 원칙 (Single Responsibility Principle]], [[의존성 규칙 (Dependency Rule)|의존성 규칙 (Dependency Rule]]
|
||||
- **Projects/Contexts:** 넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform), [[스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends)|스포티파이 자율적 분대 모델 및 마이크로 프론트엔드 (Spotify Squads and Micro Frontends]], 화신산 병원 모듈러 통합 건설 (Huoshenshan Hospital Modular Construction)
|
||||
- **Contradictions/Notes:** 관심사의 분리는 시스템의 복잡성을 낮추지만, 맹목적으로 추구하여 과도하게 분리할 경우 함수 호출의 깊이 증가, 네트워크 지연, 데이터 변환 오버헤드 등 성능 저하를 초래할 수 있습니다 [30]. 또한 지나친 추상화는 개발자를 미궁에 빠뜨려 가독성을 저하시키는 '오버엔지니어링'의 부작용을 낳을 수 있으므로, 유사 코드가 최소 3번 이상 중복될 때 추상화를 고려하는 "[[Rule of Three|Rule of Three]]"를 참고하여 실무적인 분리의 임계점을 찾아야 합니다 [31, 32].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-18*
|
||||
|
||||
Reference in New Issue
Block a user