모바일 개발에서의 Separation of Concerns — 정의, 원칙 및 적용

Separation of Concerns란

Separation of Concerns는 소프트웨어 시스템을 독립적인 부분으로 분해하여 각 부분이 하나의 작업을 해결하는 원칙입니다. concern(책임 영역)이라는 용어는 기능의 분리 가능한 모든 부분(화면 표시, 터치 처리, 데이터 검증, 네트워크 통신)을 나타냅니다. 이 원칙은 한 영역의 변경이 다른 영역의 변경을 필요로 하지 않도록 코드를 그룹화하도록 지시합니다.

모바일 개발에서 SoC는 여러 수준에서 나타납니다: 애플리케이션을 화면으로 분할하는 것부터 단일 클래스 내에서 코드를 구성하는 것까지. 네트워크에서 데이터를 로드하고 JSON을 파싱하며 UI를 렌더링하는 Activity나 ViewController는 Separation of Concerns를 위반합니다 — 이러한 코드는 유지보수, 테스트 및 확장이 어렵습니다. 대안은 각 책임을 별도의 컴포넌트로 추출하는 것입니다.

이 원칙은 추상화 개념과 밀접하게 관련되어 있습니다: 각 계층은 엄격하게 정의된 인터페이스를 제공하고 구현 세부 사항을 숨깁니다. 덕분에 개발자는 UI 로직을 다시 작성하지 않고도 네트워크 라이브러리나 데이터베이스를 교체할 수 있습니다. 이는 요구 사항과 기술이 시간이 지남에 따라 변하는 장기 프로젝트에서 특히 가치 있습니다.

원칙의 역사와 기원

Edsger Dijkstra는 1974년 논문 «On the Role of Scientific Thought»에서 Separation of Concerns의 개념을 처음으로 공식화했습니다. 그는 소프트웨어 시스템의 복잡성은 시스템을 분리하여 분석되는 부분으로 나누어 제어할 수 있다고 주장했습니다. 이 접근 방식은 코드가 계산, 입출력 및 사용자 인터페이스를 혼합했던 당시의 모놀리식 프로그램과 대조적이었습니다.

1980년대에는 이 개념이 구조적 프로그래밍 지지자들에 의해 발전되었고, 이후 객체 지향 접근 방식에 의해 발전되었습니다. Smalltalk 및 C++와 같은 언어는 SoC를 실용적인 도구로 만드는 캡슐화 및 모듈성 메커니즘을 제공했습니다. 현대 아키텍처 패턴 — MVC, MVP, MVVM 및 Clean Architecture — 은 Separation of Concerns 원칙의 직접적인 구현체입니다.

모바일 개발 세계에서 Apple은 iOS의 표준으로 MVC를 장려했으며, Model-View-Controller는 데이터, 표시 및 제어 로직을 분리합니다. Google은 Android를 위해 ViewModel 및 Repository를 기반으로 하는 아키텍처 가이드라인을 제안했습니다 — 각 컴포넌트는 고유한 제한된 작업을 해결합니다. SoC 없이 모바일 애플리케이션은 Massive View Controller — 수천 줄의 클래스 — 로 변하며, 변경 시 전체 기능이 손상될 위험이 있습니다.

모바일 아키텍처의 분리 수준

네 가지 주요 계층이 Separation of Concerns를 구현하는 일반적인 모바일 애플리케이션 아키텍처를 형성합니다. 각 계층은 자체 도메인만 담당하며 인터페이스를 통해 이웃과 상호 작용합니다.

UI 계층: View 및 ViewModel

View는 데이터 표시 및 사용자 이벤트 처리만을 담당합니다. iOS에서는 UIViewController 및 UIView, Android에서는 Fragment 또는 Activity입니다. ViewModel은 화면 상태와 데이터를 표시 가능한 형식으로 변환하는 로직을 포함합니다. 분리를 통해 UIKit을 SwiftUI로 교체하거나 Jetpack Compose로 화면을 다시 작성해도 비즈니스 로직에 영향을 미치지 않습니다.

ViewModel 테스트에는 에뮬레이터나 시뮬레이터 실행이 필요하지 않습니다 — 데이터 변환 및 사용자 작업에 대한 응답을 확인하는 단위 테스트로 충분합니다. 이는 Separation of Concerns의 직접적인 결과입니다: UI가 비즈니스 규칙과 혼합되지 않으며 각 컴포넌트가 분리되어 테스트됩니다.

비즈니스 로직 계층: Use Case 및 Interactor

Use Case(또는 Interactor)는 애플리케이션의 비즈니스 규칙(계산, 검증, 데이터 호출 오케스트레이션)을 포함합니다. 이 계층은 UI나 플랫폼 프레임워크의 존재를 알지 못합니다. Use Case는 Repository에서 데이터를 받아 로직을 적용하고 완성된 결과를 ViewModel에 반환합니다. 분리를 통해 하나의 Use Case를 여러 화면에서 재사용할 수 있습니다.

예를 들어, LoginUseCase는 이메일 유효성을 확인하고 인증을 위해 AuthRepository를 호출하며 결과를 반환합니다. 로그인 화면의 모양(SwiftUI, UIKit 또는 Compose)에 의존하지 않습니다. 비즈니스 규칙이 변경되면 UI나 데이터베이스를 건드리지 않고 하나의 Use Case만 수정하면 됩니다.

데이터 계층: Repository 및 DataSource

Repository는 데이터 소스(원격 API, 로컬 데이터베이스 또는 메모리 캐시)를 추상화합니다. ViewModel과 Use Case는 데이터가 어디서 오는지 알지 못합니다 — Repository가 네트워크에서 로드할지 캐시에서 로드할지 결정합니다. 이 분리는 비즈니스 로직이나 UI에 영향을 주지 않고 저장소 구현을 변경할 수 있게 합니다.

DataSource는 더 저수준의 분리입니다: NetworkDataSource는 HTTP 요청만 담당하고, LocalDataSource는 Room 또는 CoreData 작업을 담당합니다. Repository는 여러 DataSource에 대한 호출을 하나의 일관된 인터페이스로 결합합니다. 각 DataSource는 목 또는 가짜 서버를 사용하여 독립적으로 테스트됩니다.

DataSource 계층의 올바른 구현은 데이터베이스 스키마 변경이나 REST API를 GraphQL로 교체가 하나의 DataSource에만 영향을 미치고 Repository나 그 소비자에게는 영향을 미치지 않도록 보장합니다. 이는 인프라 수준에서의 Separation of Concerns의 직접적인 결과입니다: 각 기술적 관심사가 분리되고 계단식 변경 없이 교체 가능합니다.

디자인 패턴의 SoC

MVVM(Model-View-ViewModel)은 모바일 개발에서 가장 인기 있는 패턴으로, Separation of Concerns를 직접 구현합니다. Model은 데이터와 비즈니스 로직을 포함하고, View는 표시를 담당하며, ViewModel은 반응형 메커니즘을 통해 이들을 연결합니다. Flutter에서 BLoC는 이벤트, 상태 및 비즈니스 로직으로의 분리와 함께 유사한 역할을 수행합니다.

Robert Martin(Uncle Bob)의 Clean Architecture는 SoC를 최대한으로 끌어올립니다: 시스템은 독립적인 링(엔티티, 유스 케이스, 어댑터, 프레임워크)으로 나뉩니다. 내부 링(엔티티)은 외부 링(프레임워크)에 의존하지 않습니다. 이를 통해 애플리케이션의 핵심 로직을 다시 작성하지 않고 데이터베이스, UI 프레임워크 및 플랫폼까지 변경할 수 있습니다.

실제로 모바일 프로젝트가 완전한 Clean Architecture를 구현하는 경우는 드뭅니다 — 대부분의 애플리케이션에는 3계층 아키텍처로 충분합니다: UI, 도메인 및 데이터. 도메인 계층은 Use Case와 비즈니스 모델을 포함하며 Android SDK 또는 iOS SDK에서 완전히 분리됩니다. 이러한 분리는 20%의 노력으로 80%의 이점을 제공합니다.

// Data layer — 데이터 검색만 담당
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — 비즈니스 로직, API나 데이터베이스를 모름
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — 표시만 담당
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

위 코드는 순수한 분리를 보여줍니다: UserRepository는 API와만 작동하고, GetUserNameUseCase는 이름 형식 지정의 비즈니스 로직을 포함하며, UserViewModel은 UI 상태를 관리합니다. 각 클래스에는 변경 이유가 하나 있으며, 이것이 Separation of Concerns의 핵심입니다.

Separation of Concerns의 장점과 한계

SoC의 주요 장점은 유지보수성입니다. 독립적인 계층으로 분할된 코드는 분석하기 쉽습니다: 개발자는 오류가 발생한 계층만 보고 다른 계층에 주의를 빼앗기지 않습니다. 장기 프로젝트에서는 모놀리식 코드와 비교하여 버그 발견 및 수정 시간이 30~50% 감소합니다.

두 번째 중요한 장점은 테스트 용이성입니다. 비즈니스 로직이 UI와 프레임워크에서 분리되면 에뮬레이터 실행 없이 단위 테스트로 커버됩니다. 단위 테스트 커버리지가 높은 Android 및 iOS 프로젝트는 새 기능 추가 시 회귀가 현저히 적습니다.

주요 한계는 복잡성 증가입니다. 마이크로 계층과 추상화로의 과도한 세분화는 간단한 버튼을 추가하기 위해 개발자가 다섯 개의 파일을 편집해야 하는 상황을 초래합니다. Separation of Concerns 원칙은 합리적인 균형을 요구합니다: 실제로 독립적으로 변경되는 영역만 분리하십시오. 소규모 프로젝트의 경우 추가 추상화 없이 UI, 로직 및 데이터로의 기본 분리로 충분합니다.