# 역할 분리 (Separation of Concerns)

## 1. 개요
**역할 분리(Separation of Concerns, SoC)**란 소프트웨어 설계에서 프로그램의 각 부분이 하나의 책임(Concern)만 가지도록 나누어 설계하는 원칙을 의미합니다. 복잡한 시스템을 서로 겹치지 않는 독립적인 섹션으로 분리함으로써, 각 부분이 자신의 역할에만 집중하게 하여 시스템의 전체적인 복잡도를 낮추는 것이 핵심입니다.

### 필요성
*   **유지보수성 향상:** 특정 기능의 수정이 필요할 때 해당 역할을 담당하는 모듈만 수정하면 되므로 영향 범위가 제한됩니다.
*   **확장성 확보:** 새로운 기능을 추가할 때 기존 코드를 대폭 수정하지 않고 새로운 모듈을 추가하거나 교체하기 용이합니다.
*   **테스트 용이성:** 각 모듈이 독립적인 역할을 수행하므로, 단위 테스트(Unit Test)를 통해 개별 기능의 정상 작동 여부를 명확히 검증할 수 있습니다.
*   **재사용성 증가:** 특정 역할로 분리된 모듈은 다른 프로젝트나 시스템에서도 쉽게 재사용될 수 있습니다.

## 2. 주요 원칙
역할 분리는 객체 지향 설계의 핵심 원칙인 **단일 책임 원칙(Single Responsibility Principle, SRP)**과 밀접한 관계가 있습니다.

*   **단일 책임 원칙(SRP):** "하나의 클래스는 하나의 변경 이유만을 가져야 한다"는 원칙으로, 역할 분리를 구현하는 구체적인 방법론입니다.
*   **응집도(Cohesion)와 결합도(Coupling):** 역할 분리를 통해 관련 있는 기능끼리 묶어 **응집도를 높이고**, 모듈 간의 의존성을 최소화하여 **결합도를 낮추는 것**을 목표로 합니다.

## 3. 구현 방법 및 사례

### 계층형 아키텍처 (Layered Architecture)
가장 대표적인 역할 분리 사례로, 애플리케이션을 논리적 계층으로 나누어 관리합니다.

| 계층 (Layer) | 역할 | 주요 책임 |
| :--- | :--- | :--- |
| **프레젠테이션 계층 (Presentation)** | 사용자 인터페이스 및 요청 처리 | UI 렌더링, 사용자 입력 수신, 응답 반환 |
| **비즈니스 계층 (Business/Service)** | 핵심 비즈니스 로직 수행 | 데이터 가공, 업무 규칙 적용, 트랜잭션 관리 |
| **데이터 계층 (Data/Persistence)** | 데이터 저장 및 조회 | DB 접근, 쿼리 실행, 데이터 매핑 |

### 코드 예시: 역할 분리 전과 후

**[분리 전] 모든 로직이 한 곳에 집중된 경우**
```javascript
// 사용자 등록 함수 하나가 모든 역할을 수행
async function registerUser(req, res) {
    const { username, password } = req.body;
    
    // 1. 유효성 검사 (Presentation 역할)
    if (!username || !password) {
        return res.status(400).send("입력값이 부족합니다.");
    }

    // 2. 비즈니스 로직 (Business 역할)
    const hashedPassword = await hashPassword(password);

    // 3. DB 저장 (Data 역할)
    const user = await db.query("INSERT INTO users VALUES (?, ?)", [username, hashedPassword]);
    
    res.status(201).send("등록 완료");
}
```

**[분리 후] 역할에 따라 계층을 나눈 경우**
```javascript
// 1. Presentation Layer: 요청 접수 및 응답 반환
async function registerUser(req, res) {
    try {
        const user = await UserService.createUser(req.body);
        res.status(201).send("등록 완료");
    } catch (e) {
        res.status(400).send(e.message);
    }
}

// 2. Business Layer: 비즈니스 규칙 처리
class UserService {
    static async createUser(userData) {
        if (!userData.username || !userData.password) throw new Error("입력값 부족");
        const hashedPassword = await hashPassword(userData.password);
        return await UserRepository.save(userData.username, hashedPassword);
    }
}

// 3. Data Layer: 데이터베이스 접근
class UserRepository {
    static async save(username, password) {
        return await db.query("INSERT INTO users VALUES (?, ?)", [username, password]);
    }
}
```

## 4. 기대 효과 및 주의점

### 기대 효과
*   **코드 가독성:** 각 파일이나 클래스가 수행하는 역할이 명확하여 코드를 이해하기 쉽습니다.
*   **협업 효율성:** 프론트엔드, 백엔드, DB 설계자가 각자의 영역(계층)에서 독립적으로 작업할 수 있습니다.
*   **유연한 교체:** 예를 들어, DB를 MySQL에서 MongoDB로 변경하더라도 데이터 계층만 수정하면 비즈니스 로직은 그대로 유지할 수 있습니다.

### 주의점
*   **과도한 분리(Over-engineering):** 단순한 기능임에도 불구하고 너무 많은 계층을 나누면 오히려 코드량이 늘어나고 흐름을 파악하기 어려워질 수 있습니다.
*   **복잡도 증가:** 모듈 간의 통신을 위한 인터페이스 설계 비용이 추가로 발생합니다.
*   **적절한 균형:** 시스템의 규모와 복잡도에 맞게 적절한 수준의 분리 지점을 찾는 것이 중요합니다.