---
category: Architecture
tags: [auto-wikified, technical-documentation, architecture]
title: Separation of Concerns
description: "Separation of Concerns(관심사의 분리)는 모듈, 파일, 클래스가 단 하나의 변경 이유만 가지도록 설계하는 소프트웨어 아키텍처의 핵심 원칙입니다 [1]."
last_updated: 2026-05-04
---

# Separation of Concerns

## 📌 Brief Summary
Separation of Concerns(관심사의 분리)는 모듈, 파일, 클래스가 단 하나의 변경 이유만 가지도록 설계하는 소프트웨어 아키텍처의 핵심 원칙입니다 [1]. 이 원칙은 핵심 비즈니스 로직을 UI, 데이터베이스, 횡단 관심사(Cross-cutting concerns) 등 다른 기술적 세부사항으로부터 완벽히 고립시킴으로써 시스템의 유지보수성과 확장성을 보장합니다 [2, 3]. 현대의 프론트엔드 및 백엔드 프레임워크들은 각자의 고유한 패턴을 통해 이 원칙을 실무에 적용하고 있으며, 비즈니스 로직이 뷰(View) 등 다른 계층으로 누출될 경우 기술 부채가 빠르게 누적되게 됩니다 [3-5].

## 📖 Core Content
*   **프론트엔드 UI와 비즈니스 로직의 분리:**
    *   **React:** 렌더 프로프(Render Props) 패턴이나 컨테이너/프레젠테이션(Container and Presentational) 패턴을 적용하여 데이터 페칭 등 '동작 논리'를 UI 렌더링과 물리적으로 분리합니다 [6-8]. 이 패턴들은 컴포넌트의 행동 로직은 캡슐화하되, UI 표현은 이를 사용하는 측에 위임함으로써 깔끔한 관심사 분리를 달성합니다 [6].
    *   **Vue 3:** Composition API를 활용하여 관련된 상태와 로직을 하나의 블록(Composable)으로 그룹화함으로써 논리적 관심사를 분리합니다 [5]. 이를 통해 비즈니스 로직을 추출하고, 컴포넌트 자체는 순수한 뷰 레이어 기능에 집중하도록 만듭니다 [5].
    *   **Flutter:** 대규모 프로젝트의 경우 BLoC(Business Logic Component) 패턴과 같은 스트림 기반의 이벤트 중심 상태 관리 방식을 사용하여 비즈니스 로직과 UI 사이의 엄격한 관심사 분리를 강제합니다 [9].

*   **백엔드 아키텍처 수준의 관심사 분리:**
    *   **Django의 레이어 분리:** 모델(Models)은 오직 데이터의 형태와 저장만을, 뷰(Views)는 HTTP 요청/응답만을, 서비스(Services)는 비즈니스 로직만을 담당하도록 분리하는 것이 실전 권장 사항입니다 [1]. 
    *   **클린 / 헥사고날 아키텍처:** 핵심 도메인 규칙이 애플리케이션의 여타 부분과 섞이지 않도록 모듈화를 통해 고립시킵니다 [2, 3]. 또한 로깅, 인증, 예외 처리 등 전체 계층을 관통하는 횡단 관심사(Cross-Cutting Concerns)는 비즈니스 로직에 결합되지 않고 미들웨어, AOP, 인터셉터와 같은 인프라스트럭처 계층에서 중앙 집중식으로 분리하여 처리합니다 [2, 10-12].

## ⚖️ Trade-offs & Caveats
관심사의 분리를 실무 시스템에 구현하기 위해 고도화된 아키텍처 및 디자인 패턴을 도입할 때 다음과 같은 제약 및 반대 급부가 따를 수 있습니다:

*   **디버깅 및 코드 추적의 어려움:** AOP(관점 지향 프로그래밍)나 인터셉터 도구를 통해 횡단 관심사를 너무 '마법처럼(magical)' 분리할 경우, 코드가 어디서 어떻게 실행되는지 명시적으로 보이지 않게 됩니다 [12, 13]. 이는 새로운 개발자의 온보딩을 어렵게 만들고 예상치 못한 곳에서 에러가 발생할 때 디버깅 난이도를 상승시킵니다 [12, 13]. 
*   **복잡성과 보일러플레이트 코드 증가:** 로직과 프레젠테이션을 명확히 나누는 컨테이너 패턴이나 서비스 레이어 등을 강제하면 불가피하게 생성해야 할 파일 개수와 보일러플레이트 코드가 증가합니다 [14, 15].
*   **오버엔지니어링 위험:** 지나치게 복잡한 분리 패턴이나 의존성 계층(예: 헥사고날 아키텍처의 포트와 어댑터)은 소규모 프로젝트나 1인 개발 환경에서는 오히려 프레임워크 자체의 기능 구축에 과도한 자원을 쓰게 만들어 개발 생산성을 크게 저하시키는 결과를 초래할 수 있습니다 [16-18]. 프론트엔드 환경에서도 렌더 프로프 패턴을 무분별하게 사용할 경우 깊게 중첩된 JSX 래퍼가 생성되는 '래퍼 지옥(Wrapper Hell)' 현상을 유발합니다 [19, 20].

---
*Last updated: 2026-05-03*