Files
2nd/10_Wiki/Topics/Programming & Language/관심사의 분리 (Separation of Concerns).md
T
Antigravity Agent f8b21af4be Wiki cleanup: error-doc removal, dedup merge, link normalization
10_Wiki/Topics 대규모 정리:
- 오류 캡처/미완성 stub 문서 227개 제거
- 교차폴더 중복 43클러스터 병합 (63파일 → redirect)
- 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건
- 카테고리 MOC 6개 신규 생성
- Graph 섹션 미해결 related-keyword 링크 10,058건 제거

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 23:52:15 +09:00

5.8 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-관심사의-분리-separation-of-concerns 관심사의 분리 (Separation of Concerns) 10_Wiki/Topics verified self
SoC
Separation of Concerns
관심사 분리
none A 0.9 applied
soc
modularity
design-principle
architecture
2026-05-10 pending
language framework
agnostic agnostic

관심사의 분리 (Separation of Concerns)

매 한 줄

"매 system 을 서로 겹치지 않는 concern 단위로 쪼개 각각이 독립 변경 가능하도록 한다". Dijkstra (1974) — 매 modularity 의 근본 원리. 매 layer / module / function / file 모든 scale 에 적용. 매 변경의 locality + 매 testability 를 동시에 얻는다.

매 핵심

매 SoC 의 본질

  • Concern: 매 system 이 처리하는 distinct topic (UI, persistence, billing, auth).
  • Separation: 매 concern 별로 코드/모듈/팀/배포 단위 분리.
  • Independent change: concern A 의 변경이 B 의 코드 수정 X.

매 적용 scale

  • Function: 매 single responsibility (SRP).
  • Module: 매 cohesion 높음 + coupling 낮음.
  • Layer: presentation / business / persistence (layered arch).
  • Service: bounded context / microservice.
  • Repository: monorepo path / multirepo.

매 응용

  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.

💻 패턴

Function-level: 매 1 함수 = 1 개념

// ❌ 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
}

// ✅ 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;
}

Module: 매 dependency direction

src/
├── domain/        ← 매 pure logic (no IO)
├── application/   ← 매 use cases (orchestration)
├── infrastructure/ ← DB, HTTP, queue
└── interface/     ← controller, CLI

MVC (web)

# model.py
class User: ...

# view.py (template)
def render_user(user): ...

# controller.py
def get_user(req):
    user = User.find(req.params["id"])
    return render_user(user)

CSS 분리 (concern: layout / theme / interaction)

/* 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); }

Hexagonal port-adapter

// 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

@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 (SRP) · Modularity
  • 응용: Layered Architecture · Hexagonal Architecture · Microservices
  • Adjacent: SOLID · Aspect-Oriented Programming (AOP)

🤖 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