2nd/01_Archive/2026-04-20/관심사의 분리 (Separation of Concerns, SoC).md

관심사의 분리 (Separation of Concerns, SoC)

📌 Brief Summary

관심사의 분리(SoC)는 복잡한 소프트웨어 시스템을 더 작고 관리하기 쉬운 부분으로 나누어, 각 모듈이 단일한 관심사(기능이나 책임)만을 다루도록 설계하는 소프트웨어 공학의 근본적인 원칙이다 [1-3]. 1974년 에츠허르 데이크스트라(Edsger W. Dijkstra)가 처음 제안한 이 개념은 한 번에 모든 측면을 다루는 대신 특정 측면에 집중하여 복잡성을 통제하는 것을 목표로 한다 [4-6]. 이 원칙을 통해 시스템의 모듈성, 유지보수성, 재사용성 및 테스트 가능성을 획기적으로 향상시킬 수 있다 [1, 7, 8].

📖 Core Content

• 주요 개념 및 메커니즘

  • 모듈화(Modularity): 프로그램을 기능별로 독립된 모듈로 분할하여, 각 모듈이 특정 역할만 수행하도록 구성한다 [7, 9].
  • 응집도(Cohesion): 모듈 내의 요소들이 하나의 명확한 목적을 위해 얼마나 밀접하게 관련되어 있는지를 나타내며, SoC는 기능적 응집도를 높여 코드 가독성과 유지보수성을 극대화하는 것을 지향한다 [9-11].
  • 결합도(Coupling): 모듈 간의 상호 의존성을 의미하며, 느슨한 결합(Low Coupling)을 통해 한 모듈의 변경이 다른 모듈에 미치는 영향을 최소화한다 [7, 10, 12, 13].

• 적용 및 구현 사례

  • 웹 개발(HTML/CSS/JS): HTML은 구조, CSS는 표현(스타일), JavaScript는 동작을 담당하도록 기술과 역할을 엄격히 분리하여 개발의 복잡성을 관리한다 [14-16].
  • 계층화 아키텍처(Layered Architecture): 시스템을 프레젠테이션 계층(UI), 비즈니스 로직 계층, 데이터 액세스 계층 등으로 나누어 각 층의 책임을 분리하며, MVC(Model-View-Controller) 패턴이 대표적이다 [17-20].
  • 마이크로서비스(Microservices): 애플리케이션을 특정 비즈니스 기능(도메인)을 처리하는 작고 독립적인 서비스 단위로 분해하여 각 팀이 자율적으로 개발, 배포할 수 있게 한다 [17, 21, 22].
  • 로보틱스 제어 시스템: 소프트웨어를 넘어 하드웨어 측면에서도 센서(입력 및 인지), 컨트롤러(두뇌 및 의사결정), 액추에이터(출력 및 물리적 동작)로 역할을 명확히 분리하여 복잡한 시스템의 제어를 구현한다 [23, 24].

• 장점 및 한계

  • 장점: 코드의 명확성이 향상되고, 기능을 수정할 때 영향을 받는 코드가 국소화되어 시스템의 확장과 유지보수가 용이해진다 [25-28]. 또한, 각 부분이 격리되어 있어 다수의 엔지니어가 병렬로 개발하기 좋고 단위 테스트가 훨씬 수월해진다 [25, 26, 28].
  • 한계(오버헤드): 완벽한 분리를 맹목적으로 추구하면 불필요한 레이어와 인디렉션(Indirection)이 추가되어 오히려 코드 추적과 디버깅을 어렵게 만들 수 있다 [29, 30]. 또한 분산 환경에서는 계층 간 데이터 변환 및 통신 오버헤드에 따른 성능 저하가 발생할 수 있다 [31]. 이를 방지하기 위해 코드 중복이 세 번 이상 발견될 때 비로소 추상화와 분리를 고려하는 "Rule of Three"와 같은 실무적 지침이 권장된다 [30, 32, 33].

🔗 Knowledge Connections

• Related Topics: 단일 책임 원칙 (Single Responsibility Principle, SRP), 응집도 (Cohesion), 결합도 (Coupling), 계층화 아키텍처 (Layered Architecture), 마이크로서비스 아키텍처 (Microservices Architecture)
• Projects/Contexts: 넷플릭스 코스모스 플랫폼 (Netflix Cosmos Platform) (마이크로서비스, 워크플로우, 서버리스 함수로 논리적 계층을 엄격히 분리하여 병목 현상을 해결한 사례 [34-36]), 스포티파이 마이크로 프론트엔드 (Spotify Micro Frontends) (스쿼드 조직 모델과 프론트엔드의 관심사를 분리하여 독립적 개발과 배포를 가능하게 한 사례 [22]).
• Contradictions/Notes: 관심사의 분리는 훌륭한 설계 지침이지만, 개발 초기 단계부터 모든 것을 선제적으로 추측하여 분리하려 하면 '오버엔지니어링'이나 '성급한 추상화(Premature Abstraction)'가 발생할 수 있다. 이는 인지적 부하를 줄이려는 SoC의 본래 목적과 정반대의 결과를 낳을 수 있으므로, 실제 중복과 복잡성이 확인되는 임계점에서 점진적으로 분리를 수행해야 한다는 실무자들의 지적이 있다 [29, 30, 33, 37].

---

Last updated: 2026-04-18