---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[관심사의 분리 (SoC)|관심사의 분리 (SoC]]
last_updated: 2026-05-02
---

# [[관심사의 분리 (SoC)|관심사의 분리 (SoC]]

## 📌 Brief Summary
> 관심사의 분리(SoC)는 시스템을 구성하는 요소를 서로 겹치지 않는 독립적인 모듈로 나누어, 각 부분이 특정 기능이나 목적(관심사)에만 집중하도록 설계하는 소프트웨어 공학의 핵심 원칙이다 [1, 2]. 1974년 에츠허르 데이크스트라가 제안한 이 개념은 복잡한 문제를 해결할 때 인간의 인지적 한계를 고려해 한 번에 하나의 측면에만 집중할 것을 강조한다 [3, 4]. 특히 아키텍처 관점에서 "뇌와 팔다리의 분리"라는 비유로 설명되며, 시스템의 본질인 핵심 비즈니스 로직(뇌)과 이를 외부에 연결하는 기술적 인프라(팔다리)를 격리하여 유지보수성과 재사용성을 극대화하는 것을 목표로 한다 [5, 6].

---

> 관심사의 분리(SoC, [[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])는 소프트웨어 시스템을 각기 다른 기능이나 책임(관심사)에만 집중하는 작고 관리하기 쉬운 독립적인 모듈로 나누는 소프트웨어 엔지니어링의 핵심 설계 원칙이다 [1-5]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 처음 제안한 개념으로, 복잡성을 통제하고 코드의 모듈성, 가독성, 유지보수성, 확장성 및 재사용성을 크게 향상시키는 것을 목표로 한다 [3, 4, 6, 7]. 이 철학은 객체 지향 설계의 단일 책임 원칙(SRP)과 인터페이스 분리 원칙(ISP) 등 현대 아키텍처 패턴이 탄생하는 직접적인 근간이 되었다 [5, 8-10].

## 📖 Core Content
* **철학적 기원과 인지적 해부:** 
관심사의 분리는 에츠허르 데이크스트라(Edsger W. Dijkstra)가 1974년에 발표한 에세이 "과학적 사고의 역할에 관하여"에서 기원하였다 [4, 7]. 그는 복잡한 시스템을 다룰 때 지적인 사고를 위해서는 한 측면에 깊이 집중하고 다른 측면을 일시적으로 무시하는 능력이 필수적이라고 역설했다 [4, 7]. 이러한 철학적 패러다임은 이후 객체 지향 설계의 단일 책임 원칙(SRP) 등으로 발전하였으며, 소프트웨어의 복잡성을 통제하기 위한 논리적 단위 격리의 기초가 되었다 [5].

* **"뇌와 팔다리의 분리" 비유:** 
아키텍처에서 관심사의 분리를 가장 직관적으로 나타내는 은유는 시스템의 고수준 정책과 저수준 세부 사항을 각각 뇌와 팔다리에 비유하여 엄격히 격리하는 것이다 [5, 6].
  * **뇌 (고수준 도메인 및 비즈니스 엔티티):** 시스템이 존재하는 근본적인 이유인 핵심 업무 규칙을 캡슐화한 '엔티티(Entity)'와 이들의 상호작용을 제어하는 '유스케이스(Use Case)'로 구성된다 [6, 8, 9]. 뇌에 해당하는 영역은 데이터베이스나 사용자 인터페이스(UI) 등 외부 환경의 영향을 받지 않는 가장 순수하고 독립적인 형태로 유지되어야 한다 [6, 10].
  * **팔다리 (저수준 세부 사항 및 플러그인):** 핵심 로직을 감싸고 외부 세계와 소통하는 웹 인터페이스, 데이터베이스, 서드파티 프레임워크 등을 의미한다 [6]. 이들 외부 시스템은 언제든 교체가 가능하도록 '플러그인'의 형태를 취해야 하며, 코드의 의존성 방향은 항상 저수준의 팔다리에서 고수준의 뇌를 향해야만 한다 [6, 11, 12].

* **공학적 구현 척도 (응집도와 결합도):** 
관심사의 분리가 올바르게 구현되었는지 판단하는 공학적 척도는 '높은 응집도(High Cohesion)'와 '낮은 결합도(Low Coupling)'이다 [13, 14]. 동일한 목적을 수행하는 밀접한 기능들은 한 모듈에 묶어 내부 결속력인 응집도를 극대화해야 한다 [13, 15, 16]. 반대로 모듈 간의 외부 상호작용은 인터페이스 사용이나 의존성 주입(DI) 등을 통해 최소화하여 낮은 결합도를 유지함으로써, 한 부품의 변경이나 고장이 전체 시스템으로 전파되는 것을 차단해야 한다 [13, 17-19].

* **다양한 분야로의 물리적/산업적 확장:** 
이러한 설계 원칙은 소프트웨어 코드를 넘어 다양한 기술 및 산업 분야에서도 근간이 된다.
  * **웹 표준:** 초창기 혼재되어 있던 웹 문서는 HTML(구조), CSS(표현), [[JavaScript|JavaScript]](동작)로 각각의 역할에 맞게 엄격히 분리되어 관심사 분리의 정수를 보여준다 [20, 21].
  * **로보틱스:** 로봇 시스템 또한 센서(입력 및 오감), 컨트롤러(알고리즘 및 뇌), 액추에이터(물리적 출력 및 근육)라는 명확히 분리된 하드웨어 및 소프트웨어 구성 요소들의 협업 구조로 작동한다 [22, 23].
  * **건설 산업 (MiC):** 건축물의 기능을 하위 시스템으로 분해해 공장에서 사전 제작한 후 현장에서 조립하는 '모듈러 통합 건설(MiC)' 역시 복잡한 건축 구조 관리를 단순화하는 물리적 차원의 SoC 적용 사례이다 [24].

---

*   **원칙의 기원과 진화:** 
    관심사의 분리라는 용어는 에츠허르 데이크스트라가 1974년 논문 "과학적 사고의 역할에 관하여"에서 '단일 트랙적이면서 동시에 멀티 트랙적인 사고방식'을 통해 복잡한 문제를 고립시켜 집중해야 한다고 주장하면서 등장했다 [11, 12]. 이후 1960~70년대의 구조적 프로그래밍부터 객체 지향 프로그래밍(OOP) 시대를 거쳐 MVC 패러다임, 마이크로서비스 아키텍처(MSA) 등 대규모 시스템을 설계하는 필수 원칙으로 진화해왔다 [8, 10, 13, 14].
*   **핵심 메커니즘 (응집도와 결합도):** 
    SoC를 성공적으로 구현했는지 판단하는 주요 척도는 높은 응집도(High Cohesion)와 낮은 결합도(Low/Loose Coupling)이다 [3, 15-17]. 응집도는 모듈 내부의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내며, 결합도는 모듈 간의 상호 의존성 정도를 뜻한다 [3, 18, 19]. 좋은 설계는 내부 결속력인 응집도를 극대화하고 외부 간섭에 해당하는 결합도를 최소화하는 최적화를 지향한다 [20, 21].
*   **적용 수준과 다양한 사례:**
    *   **함수 및 모듈 수준:** 각 함수나 모듈은 단일 작업에 집중하도록 분리되어야 한다. 이를 통해 코드가 스파게티처럼 얽히는 것을 방지하고 가독성과 테스트 가능성을 향상시킨다 [22-24].
    *   **소프트웨어 아키텍처 수준:** 핵심 비즈니스 로직(뇌)과 외부 인프라(팔다리)를 분리하는 것이 핵심이다 [25]. 웹 기반 시스템에서는 프레젠테이션 계층, 비즈니스 로직 계층, 데이터 액세스 계층으로 관심사를 분리하여 의존성이 단방향(주로 내부 핵심 도메인을 향해)으로 흐르도록 설계한다 [21, 26, 27].
    *   **웹 프론트엔드:** 전통적인 HTML(구조), CSS(표현), [[JavaScript|JavaScript]](동작)의 역할별 분리가 가장 직관적인 SoC 사례이다 [28-30]. 최근에는 프로젝트의 규모가 커짐에 따라 기능(Feature) 단위로 관심사를 묶어 관리하는 FSD([[Feature-Sliced Design|Feature-Sliced Design]]) 방식 등으로 진화하고 있다 [31, 32].
    *   **로보틱스 제어 시스템:** 로봇 또한 인지적 해부와 동일하게 외부 자극을 감지하는 센서(눈/귀), 의사결정을 내리는 컨트롤러(뇌), 물리적 운동을 수행하는 액추에이터(근육)로 하드웨어적 관심사를 명확히 분리하여 구동된다 [33, 34].
*   **주요 이점:** 
    시스템을 모듈화하면 특정 기능을 수정하거나 확장할 때 다른 코드에 미치는 부작용을 최소화할 수 있어 유지보수성이 크게 향상된다 [35-37]. 여러 명의 개발자가 각기 다른 모듈을 맡아 서로 방해받지 않고 병렬(동시) 개발을 수행할 수 있으며 [35, 38, 39], 비즈니스 로직을 데이터베이스나 UI 등 외부 시스템으로부터 격리시켜 독립적이고 신속한 단위 테스트 환경을 조성할 수 있다 [27, 40, 41].
*   **한계 및 실무적 고려사항:** 
    관심사를 맹목적이고 과도하게 분리(Over-engineering)하면 오히려 계층 간 통신 및 데이터 변환 오버헤드가 증가하여 시스템 성능을 떨어뜨릴 수 있다 [42, 43]. 층을 너무 얇게 나누거나 과도한 추상화를 도입할 경우, 실제 구현을 파악하기 위해 수많은 계층을 넘나들어야 하므로 개발자의 인지적 부하가 오히려 가중될 위험(인디렉션의 저주)이 존재한다 [42, 44, 45].

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 Knowledge Connections
- **Related Topics:** [[단일 책임 원칙 (SRP)|단일 책임 원칙 (SRP]], 응집도와 결합도, 클린 아키텍처 (Clean [[Architecture|Architecture]]
- **Projects/Contexts:** [[넷플릭스 코스모스 플랫폼 (Netflix Cosmos)|넷플릭스 코스모스 플랫폼 (Netflix Cosmos]], 스포티파이 자율적 분대 모델 (Spotify Squad), [[모듈러 통합 건설 (MiC)|모듈러 통합 건설 (MiC]]
- **Contradictions/Notes:** 관심사의 분리는 시스템의 가독성, 테스트 가능성, 재사용성을 비약적으로 향상시키지만 [25-27], 이를 맹목적으로 추구하여 과도하게 분리할 경우 함수 호출의 뎁스를 깊게 만들거나 간접 참조가 늘어나 오히려 인지적 부하와 성능 오버헤드(Overengineering)를 유발할 수 있다 [28-30]. 따라서 실무에서는 성급한 추상화를 피하고, 동일한 패턴이 세 번 반복될 때 비로소 분리를 고려하는 "[[Rule of Three|Rule of Three]]"와 같이 실용적인 임계점을 찾아 균형을 맞추어야 한다 [30].

---
*Last updated: 2026-04-18*

---

---

- **Related Topics:** [[단일 책임 원칙 (SRP)|단일 책임 원칙(SRP]], 응집도(Cohesion)와 결합도(Coupling), 계층화 아키텍처(Layered Architecture), 모델-뷰-컨트롤러(MVC), [[관점 지향 프로그래밍 (AOP)|관점 지향 프로그래밍(AOP]]
- **Projects/Contexts:** 넷플릭스 코스모스(Cosmos) 플랫폼, 스포티파이 스쿼드(Squad) 및 마이크로 프론트엔드, 화신산(Huoshen Mountain) 병원 모듈러 통합 건설(MiC)
- **Contradictions/Notes:** 
    * "SoC를 도입하면 유지보수와 모듈성이 향상된다"는 원칙이 일반적이나, "지나친 관심사 분리와 추상화는 간접 참조를 늘리고 런타임 성능 저하 및 코드 추적의 어려움을 유발하여 실무적 복잡성을 오히려 가중시킨다"는 경고와 상충하는 지점이 있다 [42-45].
    * 관심사의 선제적인 도출이 필수적이라는 견해가 있는 반면, 다른 실무자들은 초기에 관심사를 미리 예측해 분리하는 것은 불가능에 가까우며, 코드가 중복되어 나타날 때([[Rule of Three|Rule of Three]]) 사후적으로 리팩토링을 통해 분리하는 것(DRY 관점)이 현실적이라는 상반된 주장을 한다 [45, 46].

---
*Last updated: 2026-04-18*

---
