2nd/10_Wiki/Topics/02_Architecture_Principles/관심사의 분리 (Separation of Concerns).md

---
id: P-REINFORCE-WIKI-D2716426
title: "관심사의 분리 (Separation of Concerns)"
category: "10_Wiki/💡 Topics/02_Architecture_Principles"
status: verified
canonical_id: ""
aliases: []
duplicate_of: ""
source_trust_level: A
confidence_score: 0.95
tags: ['Separation of Concerns']
raw_sources: ["Datacollector_MAC/out_wiki/관심사의 분리 (Separation of Concerns).md"]
last_reinforced: 2026-05-02
github_commit: ""
---

# [[관심사의 분리 (Separation of Concerns)]]

## 📌 Brief Summary
관심사의 분리(SoC)는 시스템을 겹치지 않는 뚜렷한 여러 섹션으로 나누어 소프트웨어를 설계하는 소프트웨어 엔지니어링의 핵심 원칙이다 [1]. 단일 컴포넌트가 너무 많은 관련 없는 작업을 수행하는 것을 방지하여 복잡성을 줄이고 시스템을 관리가능하게 만든다 [1]. 프레젠테이션 로직, 비즈니스 규칙, 데이터 접근 메커니즘을 분리함으로써 각 모듈의 독립적인 개발, 이해 및 테스트를 용이하게 하는 역할을 한다 [1]. 

## 📖 Core 실질 Content
* **원칙의 핵심 목적**: 시스템의 복잡성을 줄이는 것이 주된 목표이다 [1]. 하나의 모듈이나 컴포넌트가 자신이 맡은 특정한 '관심사(concern)'에만 집중하도록 격리함으로써, 코드가 부서지기 쉽고 관리 불가능해지는 것을 방지한다 [1].
* **주요 구현 및 아키텍처 패턴**:
  * **MVC (Model-View-Controller)**: 데이터와 비즈니스 로직을 관리하는 Model, 사용자 인터페이스를 다루는 View, 입력을 받아 조율하는 Controller로 애플리케이션의 관심사를 세 부분으로 분리한다 [2].
  * **계층형 아키텍처 (Layered Architecture)**: 프레젠테이션 계층, 비즈니스 로직 계층, 데이터 접근 계층 등 수평적인 층으로 관심사를 분리하며, 각 계층은 바로 아래 계층과만 통신하도록 제한한다 [2-4].
  * **마이크로서비스 아키텍처 (Microservices Architecture)**: 사용자 관리, 결제 처리 등 특정 비즈니스 기능을 중심으로 작고 독립적인 서비스들로 애플리케이션을 분할하여 매우 세밀한 수준에서 관심사를 분리한다 [2, 5].
* **코드베이스 내 실천 전략**:
  * **초기 책임 식별**: 시스템 설계 초기 단계에서 사용자 인증, 데이터 처리, UI 렌더링 등의 주요 책임을 명확히 정의하고, 이를 각기 다른 모듈에 매핑해야 한다 [6].
  * **명확한 인터페이스 (Clear Interfaces) 사용**: 서로 다른 컴포넌트 간의 통신을 위해 잘 문서화되고 안정적인 인터페이스를 정의하여, 하나의 관심사 내부 변경이 다른 관심사를 망가뜨리지 않도록 보호한다 [6].
  * **의존성 주입 (Dependency Injection, DI) 활용**: DI 프레임워크를 사용하여 컴포넌트 간 결합도를 낮추고 코어 로직의 변경 없이 구현체를 교체할 수 있도록 하여 유지보수성을 극대화한다 [6].
  * **순환 의존성 해결**: 프로젝트 폴더 조직 및 모듈화 단계에서 발생하는 순환 의존성(Cyclic dependencies) 문제는 관심사의 분리 원칙을 준수함으로써 캡슐화를 통해 근본적으로 해결할 수 있다 [7, 8].

## ⚖️ Trade-offs & Caveats
* **초기 설계의 복잡성**: 경계를 설계하기 위한 사전 설계(upfront boundary design) 과정이 필요하므로 구현 복잡성이 증가한다 [9].
* **과도한 추상화의 위험**: 잘못된 경계 설정이나 무리한 분리는 오히려 모듈 간의 통신을 복잡하게 만들어 시스템 파악을 더 어렵게 할 수 있다 [6]. 
* **코드 탐색의 파편화**: 관심사가 철저히 분리된 객체 지향 시스템이나 대규모 코드베이스에서는 기능 하나를 파악하기 위해 여러 파일과 계층을 이리저리 넘나들어야(jumping back and forth) 하는 인지적 피로도와 탐색 시간이 증가하는 단점이 발생할 수 있다 [10].

## 🔗 Knowledge Connections

### Related Concepts

#### [아키텍처/기반 기술]
- [[계층형 아키텍처 (Layered Architecture)]]
  - 연결 이유: 관심사를 수평적 계층(표현, 비즈니스 로직, 데이터 접근 등)으로 분리하여 각 계층의 역할을 엄격히 제한하는 가장 대표적인 아키텍처 패턴이기 때문이다 [2, 3].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 코드베이스를 읽을 때 코드가 어떤 계층에 속하는지를 파악함으로써 해당 코드의 책임과 통신 흐름(하향식 흐름 등)을 유추할 수 있다 [4, 11].
- [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
  - 연결 이유: 바운디드 컨텍스트(Bounded Context)를 통해 비즈니스 도메인을 기준으로 시스템의 경계를 명확히 분리하는 전략이 관심사 분리의 핵심과 연결되기 때문이다 [12, 13].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 비즈니스 용어로 명명된 모듈 구조(Ubiquitous Language)를 바탕으로 기술적 상세에 매몰되지 않고 코드베이스의 구조와 의도를 상위 수준에서 파악하는 방법을 배울 수 있다 [14-16].
- [[마이크로서비스 아키텍처 (Microservices Architecture)]]
  - 연결 이유: 관심사의 분리 원리를 단일 애플리케이션을 넘어 독립적 배포가 가능한 분산 시스템 단위로 확장한 구조이기 때문이다 [2, 5].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 시스템의 기능적 관심사가 네트워크 경계를 넘어 어떻게 통신하고 협력하는지, 인프라 수준에서의 분리와 결합도 문제를 이해할 수 있다 [17, 18].

#### [구현/설계 원칙]
- [[의존성 주입 (Dependency Injection)]]
  - 연결 이유: 분리된 관심사(모듈, 계층 등)들이 강하게 결합되지 않도록 느슨한 결합(Loose Coupling)을 제공하는 핵심 구현 기법이기 때문이다 [6, 11, 19].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 하위 모듈이 아닌 추상화(인터페이스)에 의존하게 하여 각 관심사가 독립적으로 테스트 가능하고 교체 가능하게 유지되는 원리를 배울 수 있다 [11, 19, 20].
- [[단일 책임 원칙 (Single Responsibility Principle, SRP)]]
  - 연결 이유: 객체 지향 설계(SOLID)에서 클래스나 모듈이 단 하나의 변경 이유(하나의 작업)만을 가져야 한다는 원칙으로, 코드 레벨에서의 관심사 분리이기 때문이다 [19].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 단일 파일이나 클래스의 복잡성을 제어하고, 코드베이스 내 각 컴포넌트의 명확한 경계와 응집도를 높이는 세부 설계 지식을 학습할 수 있다 [19].

### Deeper Research Questions
- 초기 설계 단계에서 시스템의 '관심사(Concern)'를 도출하고 모듈 경계를 짓기 위해 Event Storming 같은 워크샵을 어떻게 활용할 수 있는가?
- 관심사가 엄격하게 분리된 계층형 아키텍처 구조에서, 계층 간 데이터를 전달할 때 발생하는 보일러플레이트 코드와 변환 오버헤드를 어떤 방식으로 최소화하는가?
- 대규모 시스템의 코드베이스에서 기능(Feature) 기반으로 관심사를 나눌 때와 기술적 계층(Layer) 기반으로 나눌 때, 코드 유지보수성과 탐색 효율성 측면에서 어떤 차이가 있는가?
- 도메인 주도 설계(DDD)의 바운디드 컨텍스트와 마이크로서비스의 경계를 정의할 때, 두 관심사 분리 기법은 어떻게 상호 작용하며 차이점은 무엇인가?
- 기존의 레거시 모놀리식 시스템에 얽혀있는 순환 의존성(Cyclic Dependency)을 식별하고, 관심사 분리 원칙을 적용해 안전하게 리팩토링하는 단계적 프로세스는 무엇인가?

### Practical Application Contexts
- **Implementation:** 명확한 인터페이스를 설정하고 의존성 주입을 활용하여, 비즈니스 규칙을 다루는 코드와 데이터베이스 접근 코드를 서로 다른 모듈에 격리하여 작성한다 [4, 6, 11].
- **System Design:** 소프트웨어 설계 시 MVC 패턴이나 계층형, 클린 아키텍처 등을 채택하여, 각 구조가 담당할 '관심사'의 경계를 초기부터 명확히 수립해 결합도를 낮춘다 [2, 3, 21].
- **Operation / Maintenance:** 코드 변경이나 버그 발생 시(예: UI 레이아웃 깨짐, DB 저장 오류), 관심사가 분리되어 있으므로 전체 시스템을 뒤지지 않고 원인이 되는 특정 컴포넌트나 계층만을 집중적으로 검토하여 유지보수를 효율화한다 [1, 3, 7].
- **Learning Path:** 복잡한 대형 코드베이스를 새롭게 분석할 때, 아키텍처 상 분리된 관심사의 형태(계층형인지, 도메인 중심인지)를 먼저 파악한 후, 하향식 또는 상향식 탐색 기법을 조합하여 부분적으로 시스템을 정복해 나가는 학습 지표로 활용한다 [22, 23].
- **My Project Relevance:** 팀 프로젝트 개발 시 각 파일과 폴더를 책임(UI, 유틸리티, 서비스 로직 등)에 맞게 조직하고 설계 패턴을 적용하여, 추후 새로운 팀원이 합류하거나 본인이 코드를 재탐독할 때 논리적 탐색을 용이하게 만든다.

### Adjacent Topics
- [[SOLID 원칙]]
  - 확장 방향: 관심사의 분리를 클래스 및 객체 지향 프로그래밍 수준에서 더욱 구체화하는 5가지 설계 원칙(특히 단일 책임 원칙과 의존성 역전 원칙)을 통해 유연하고 유지보수하기 쉬운 코드 작성법으로 이해를 확장할 수 있다 [19, 24].

---
*Last updated: 2026-05-02*
## 🧪 검증 상태 (Validation)
- **정보 상태:** verified
- **출처 신뢰도:** A
- **검토 이유:** Datacollector에서 자동 추출된 위키 데이터의 초기 통합.

## 🧬 중복 검사 (Duplicate Check)
- **기존 유사 문서:** [[관심사의 분리 (Separation of Concerns).md]]
- **처리 방식:** UPDATE
- **처리 이유:** 기존 문서 내용 보강 및 v3.1 표준 적용