[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,104 +2,176 @@
|
||||
id: wiki-2026-0508-관심사의-분리-separation-of-concerns
|
||||
title: 관심사의 분리 (Separation of Concerns)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-FE2B8D]
|
||||
aliases: [SoC, Separation of Concerns, 관심사 분리]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [soc, modularity, design-principle, architecture]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 관심사의 분리 ([[Separation of Concerns]])"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: agnostic
|
||||
framework: agnostic
|
||||
---
|
||||
|
||||
# [[관심사의 분리 (Separation of Concerns)]]
|
||||
# 관심사의 분리 (Separation of Concerns)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 관심사의 분리(SoC)는 소프트웨어 설계에서 프로그램의 각 부분이 서로 다른 고유한 기능이나 특정 관심사에만 집중하도록 시스템을 논리적 단위로 나누는 근본적인 원칙입니다 [1-3]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 인간의 지적 한계로 인한 복잡성을 통제하기 위해 제안한 개념으로, 시스템을 관리하기 쉬운 조각으로 분해하여 모듈성, 유지보수성, 재사용성 및 확장성을 극대화하는 것을 목표로 합니다 [1, 3-6]. 시스템의 핵심 비즈니스 로직과 기술적 세부 사항을 명확히 격리함으로써, 변화에 유연하게 대응하고 진화할 수 있는 견고한 아키텍처를 구축하는 데 필수적인 철학입니다 [7-9].
|
||||
## 매 한 줄
|
||||
> **"매 system 을 서로 겹치지 않는 concern 단위로 쪼개 각각이 독립 변경 가능하도록 한다"**. Dijkstra (1974) — 매 modularity 의 근본 원리. 매 layer / module / function / file 모든 scale 에 적용. 매 변경의 locality + 매 testability 를 동시에 얻는다.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**기원과 철학적 패러다임**
|
||||
* 관심사 분리의 기원은 에츠허르 데이크스트라가 1974년 발표한 에세이 "과학적 사고의 역할에 관하여"로 거슬러 올라갑니다 [3]. 그는 복잡한 문제를 해결할 때 인간의 정신이 압도당하지 않도록 특정 측면에 주의를 집중하고 다른 측면을 분리해서 사고하는 것이 지적 사고의 핵심이라고 강조했습니다 [3, 6]. 이 원칙은 후대 학자들에 의해 소프트웨어 모듈성([[Modularity]])을 확보하는 일차적인 방법으로 정립되었으며, 객체 지향 설계의 SOLID 원칙(특히 단일 책임 원칙과 인터페이스 분리 원칙)의 모태가 되었습니다 [3, 7].
|
||||
## 매 핵심
|
||||
|
||||
**"뇌와 팔다리의 분리" 은유 (핵심 구조)**
|
||||
* 관심사 분리를 가장 직관적으로 설명하는 비유는 시스템을 '뇌(Brain)'와 '팔다리(Limbs)'로 구분하는 것입니다 [7].
|
||||
* **뇌 (Core/Brain):** 아키텍처의 심장부로, 시스템이 존재하는 근본 이유인 고수준의 '비즈니스 엔티티'와 '유스케이스'를 포함합니다 [10-12]. 이 영역은 외부 시스템(데이터베이스, UI, 프레임워크 등)의 영향을 받지 않는 순수한 상태로 보존되어야 하며 가장 높은 재사용성과 독립성을 지녀야 합니다 [12, 13].
|
||||
* **팔다리 (Peripheral/Limbs):** 핵심 로직을 감싸고 외부 세계와 물리적으로 소통하는 저수준의 세부 사항입니다. SQL 쿼리, REST API, HTML/CSS 웹 인터페이스, 서드파티 라이브러리 등이 포함되며, 핵심 로직을 변경하지 않고 언제든 교체 가능한 '플러그인' 형태로 존재해야 합니다 [12, 13].
|
||||
* **신경계 (Wiring):** 뇌와 팔다리 사이의 상호작용을 중재하는 인터페이스나 DTO 등의 소통 경로로, 의존성 역전을 통해 느슨한 결합을 유지합니다 [14, 15].
|
||||
### 매 SoC 의 본질
|
||||
- **Concern**: 매 system 이 처리하는 distinct topic (UI, persistence, billing, auth).
|
||||
- **Separation**: 매 concern 별로 코드/모듈/팀/배포 단위 분리.
|
||||
- **Independent change**: concern A 의 변경이 B 의 코드 수정 X.
|
||||
|
||||
**구현을 위한 공학적 척도: 응집도와 결합도**
|
||||
* **높은 응집도 (High Cohesion):** 모듈 내부의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타냅니다. 기능적 응집도가 높은 코드는 가독성이 좋고 단위 테스트가 쉬우며 수정 시 영향 범위가 한정됩니다 [2, 16-18].
|
||||
* **낮은 결합도 (Low Coupling):** 한 모듈이 시스템의 다른 부분에 의존하는 정도를 최소화하는 것을 의미합니다. 구체적인 구현이 아닌 인터페이스를 참조하거나 의존성 주입(DI)을 통해 모듈 간의 독립성을 보장하여 예상치 못한 부작용을 방지합니다 [2, 19-21].
|
||||
### 매 적용 scale
|
||||
- **Function**: 매 single responsibility (SRP).
|
||||
- **Module**: 매 cohesion 높음 + coupling 낮음.
|
||||
- **Layer**: presentation / business / persistence (layered arch).
|
||||
- **Service**: bounded context / microservice.
|
||||
- **Repository**: monorepo path / multirepo.
|
||||
|
||||
**아키텍처 및 산업 적용 사례**
|
||||
* **소프트웨어 아키텍처:** 프레젠테이션, 비즈니스 로직, 데이터 액세스 계층으로 나누는 3계층 구조와 도메인 주도 설계(DDD)의 바운디드 컨텍스트, 클린 아키텍처 등이 대표적인 관심사 분리의 구현체입니다 [8, 22-24]. 이때 소스 코드 의존성은 항상 외부(저수준)에서 내부(고수준 정책)를 향해야 한다는 '의존성 규칙'이 적용됩니다 [25].
|
||||
* **다양한 산업의 관심사 분리:** HTML(구조), CSS(표현), JS(동작)의 웹 표준 기술 [26, 27], 로보틱스 제어 시스템에서의 센서(입력), 컨트롤러(뇌), 액추에이터(근육) 분리 [28], 건축 산업에서의 모듈러 통합 건설(MiC) [29] 등 물리적, 시스템적 복잡성을 다루는 광범위한 영역에 적용됩니다.
|
||||
### 매 응용
|
||||
1. MVC / MVP / MVVM.
|
||||
2. Clean / Hexagonal Architecture (port-adapter 분리).
|
||||
3. Aspect-Oriented Programming (cross-cutting 분리).
|
||||
4. Microservice (bounded context 분리).
|
||||
5. CSS-in-JS vs separate stylesheet — 매 variant.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** 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].
|
||||
### Function-level: 매 1 함수 = 1 개념
|
||||
```typescript
|
||||
// ❌ Mixed
|
||||
function processOrder(input: any) {
|
||||
if (!input.email) throw new Error("invalid"); // validation
|
||||
const tax = input.amount * 0.1; // tax calc
|
||||
db.execute("INSERT INTO orders ..."); // persistence
|
||||
smtp.send(input.email, "Confirmed"); // notification
|
||||
}
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
// ✅ Separated
|
||||
function validate(input: OrderInput): Order { /* ... */ return order; }
|
||||
function computeTax(order: Order): Money { /* ... */ }
|
||||
async function persist(order: Order, tax: Money): Promise<OrderId> { /* ... */ }
|
||||
async function notify(order: Order): Promise<void> { /* ... */ }
|
||||
async function processOrder(input: OrderInput) {
|
||||
const order = validate(input);
|
||||
const tax = computeTax(order);
|
||||
const id = await persist(order, tax);
|
||||
await notify(order);
|
||||
return id;
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Module: 매 dependency direction
|
||||
```
|
||||
src/
|
||||
├── domain/ ← 매 pure logic (no IO)
|
||||
├── application/ ← 매 use cases (orchestration)
|
||||
├── infrastructure/ ← DB, HTTP, queue
|
||||
└── interface/ ← controller, CLI
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### MVC (web)
|
||||
```python
|
||||
# model.py
|
||||
class User: ...
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
# view.py (template)
|
||||
def render_user(user): ...
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
# controller.py
|
||||
def get_user(req):
|
||||
user = User.find(req.params["id"])
|
||||
return render_user(user)
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### CSS 분리 (concern: layout / theme / interaction)
|
||||
```css
|
||||
/* layout.css */
|
||||
.container { display: grid; grid-template-columns: 240px 1fr; }
|
||||
/* theme.css */
|
||||
:root { --bg: #fff; --fg: #111; }
|
||||
.dark { --bg: #111; --fg: #eee; }
|
||||
/* interaction.css */
|
||||
.btn:hover { transform: translateY(-1px); }
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Hexagonal port-adapter
|
||||
```typescript
|
||||
// domain port (concern: business)
|
||||
export interface OrderRepo {
|
||||
save(o: Order): Promise<void>;
|
||||
findById(id: OrderId): Promise<Order | null>;
|
||||
}
|
||||
|
||||
// adapter (concern: infra)
|
||||
export class PostgresOrderRepo implements OrderRepo { /* SQL */ }
|
||||
export class InMemoryOrderRepo implements OrderRepo { /* test */ }
|
||||
```
|
||||
|
||||
### AOP (cross-cutting) — Spring
|
||||
```java
|
||||
@Aspect @Component
|
||||
class TxAspect {
|
||||
@Around("@annotation(Transactional)")
|
||||
Object inTx(ProceedingJoinPoint pjp) throws Throwable {
|
||||
var tx = txManager.begin();
|
||||
try { var r = pjp.proceed(); tx.commit(); return r; }
|
||||
catch (Throwable t) { tx.rollback(); throw t; }
|
||||
}
|
||||
}
|
||||
// 매 business code 에서 tx 코드 누설 X
|
||||
```
|
||||
|
||||
### Bounded context (microservice 단위)
|
||||
```
|
||||
billing-service/ ← 매 invoice, charge
|
||||
inventory-service/ ← 매 stock
|
||||
shipping-service/ ← 매 carrier integration
|
||||
# 매 각자 DB, 각자 deploy, 각자 schema
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 small script | function-level SRP 만 |
|
||||
| 매 medium app | layered + module 단위 |
|
||||
| 매 complex domain | hexagonal + bounded context |
|
||||
| 매 large org | microservice + team boundary |
|
||||
| 매 cross-cutting (log, tx, auth) | AOP / middleware / interceptor |
|
||||
|
||||
**기본값**: 매 layered + DI + interface boundary. 매 over-fragmentation (매 1 함수 1 파일) 의 X.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Software Design Principles]]
|
||||
- 변형: [[Single Responsibility Principle]] · [[Modularity]] · [[High Cohesion / Low Coupling]]
|
||||
- 응용: [[Layered Architecture]] · [[Hexagonal Architecture]] · [[Microservices]]
|
||||
- Adjacent: [[SOLID]] · [[Design by Contract]] · [[Aspect-Oriented Programming]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: refactor proposal, code smell detection (mixed concerns), boundary 설정.
|
||||
**언제 X**: 매 throwaway script — overhead 만.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **God Module / God File**: 매 모든 concern 의 mix.
|
||||
- **Shotgun Surgery**: 매 1 변경이 매 N 파일 수정 — 매 concern 의 분산 잘못.
|
||||
- **Premature decomposition**: 매 unclear boundary 의 microservice 분할 — 매 distributed monolith.
|
||||
- **Leaky abstraction**: 매 infra 의 domain 누수 (e.g. ORM annotation 의 domain entity 노출).
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Dijkstra "On the role of scientific thought" 1974, Parnas "On the Criteria To Be Used in Decomposing Systems into Modules" 1972).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — SoC 본질 + scale + MVC + hexagonal + AOP |
|
||||
|
||||
Reference in New Issue
Block a user