MVC, MVVM, MVP 등 다양한 아키텍처 패턴 소개 및 구현

소프트웨어 개발에서 아키텍처 패턴은 코드를 효율적으로 구조화하고 유지보수성을 향상시키는 중요한 요소입니다. 모바일 앱 개발에서도 각 패턴은 데이터 흐름과 의존성 관리에 큰 영향을 미치며, 규모와 복잡성에 따라 적합한 패턴을 선택하는 것이 필수적입니다. 이번 글에서는 대표적인 아키텍처 패턴인 MVC (Model-View-Controller), MVP (Model-View-Presenter), MVVM (Model-View-ViewModel) 패턴에 대해 소개하고, 각각의 특징과 구현 방법을 설명하겠습니다.

Table of Contents

1. MVC (Model-View-Controller) 패턴

MVC는 가장 전통적이고 많이 사용되는 아키텍처 패턴입니다. 애플리케이션을 모델(Model), 뷰(View), **컨트롤러(Controller)**로 나누어 책임을 분리하는 방식입니다.

모델(Model): 애플리케이션의 핵심 데이터와 비즈니스 로직을 처리합니다. 모델은 데이터를 관리하고, 이를 사용하여 동작을 수행합니다.
뷰(View): 사용자 인터페이스(UI)를 나타내며, 모델의 데이터를 화면에 보여줍니다. 사용자가 보는 화면입니다.
컨트롤러(Controller): 사용자 입력을 처리하고, 모델과 뷰 사이에서 중재 역할을 합니다. 컨트롤러는 사용자의 요청을 받아 모델을 업데이트하고, 그에 따라 뷰를 갱신합니다.

1.1 MVC의 장점과 단점

장점:

명확한 역할 분담으로 코드가 구조적으로 나뉘어 이해하기 쉽습니다.
뷰와 모델 간의 의존성이 낮아 재사용성이 높습니다.

단점:

모바일 애플리케이션에서 컨트롤러가 과부하될 수 있습니다.
복잡한 애플리케이션에서는 컨트롤러가 너무 많은 역할을 담당하게 되어 코드가 복잡해집니다.

1.2 MVC 구현 예제

swift코드 복사// Model
class UserModel {
    var name: String?
    var age: Int?
}

// Controller
class UserController {
    let userModel = UserModel()
    
    func updateUserName(newName: String) {
        userModel.name = newName
    }
}

// View
class UserViewController: UIViewController {
    let userController = UserController()

    override func viewDidLoad() {
        super.viewDidLoad()
        // View에서 Controller를 통해 Model에 접근
        userController.updateUserName(newName: "John")
    }
}

2. MVP (Model-View-Presenter) 패턴

MVP는 MVC의 변형으로, **프레젠터(Presenter)**가 컨트롤러의 역할을 대신하여 뷰와 모델을 분리하는 데 더 집중합니다. 프레젠터는 뷰에서 받은 사용자 입력을 처리하고, 모델과 상호작용한 결과를 다시 뷰에 전달합니다.

모델(Model): 데이터와 비즈니스 로직을 처리하는 역할은 변함이 없습니다.
뷰(View): UI를 담당하며, 프레젠터로부터 데이터를 받아 화면에 표시합니다.
프레젠터(Presenter): 뷰의 입력을 받아 모델에 전달하고, 모델에서 처리된 데이터를 다시 뷰로 보내는 역할을 합니다. 뷰와 모델 간의 직접적인 의존성을 없애는 것이 특징입니다.

2.1 MVP의 장점과 단점

장점:

뷰와 모델 간의 결합도가 매우 낮아 테스트가 용이합니다.
뷰와 모델이 독립적으로 동작하여 유지보수에 유리합니다.

단점:

프레젠터가 모든 비즈니스 로직을 처리하게 되면, 복잡한 애플리케이션에서는 프레젠터가 과도하게 커질 수 있습니다.

2.2 MVP 구현 예제

kotlin코드 복사// Model
class UserModel {
    var name: String? = null
}

// View Interface
interface UserView {
    fun showUserName(name: String)
}

// Presenter
class UserPresenter(val view: UserView) {
    val userModel = UserModel()

    fun updateUserName(newName: String) {
        userModel.name = newName
        view.showUserName(newName)
    }
}

// View Implementation
class UserActivity : AppCompatActivity(), UserView {
    private lateinit var presenter: UserPresenter

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        presenter = UserPresenter(this)
    }

    override fun showUserName(name: String) {
        // 화면에 이름 표시
    }
}

3. MVVM (Model-View-ViewModel) 패턴

MVVM 패턴은 안드로이드와 같은 데이터 바인딩 기능을 사용하는 프레임워크에서 주로 사용됩니다. **뷰모델(ViewModel)**이 프레젠터의 역할을 대신하며, 뷰와 모델 사이의 데이터 바인딩을 통해 뷰와 모델의 의존성을 최소화합니다.

모델(Model): 비즈니스 로직과 데이터 처리를 담당합니다.
뷰(View): 사용자 인터페이스를 표현하며, 뷰모델을 통해 데이터와 상호작용합니다.
뷰모델(ViewModel): 뷰에 필요한 데이터를 준비하고, 뷰의 상태를 관리하는 역할을 합니다. 뷰모델은 뷰와는 완전히 독립적이며, 데이터 바인딩을 통해 뷰에 데이터를 전달할 수 있습니다.

3.1 MVVM의 장점과 단점

장점:

데이터 바인딩을 통해 뷰와 모델 간의 결합도를 낮출 수 있습니다.
코드가 더 모듈화되고 재사용성이 높아집니다.

단점:

데이터 바인딩을 설정하고 유지보수하는 것이 복잡할 수 있습니다.
작은 규모의 프로젝트에서는 오버엔지니어링이 될 수 있습니다.

3.2 MVVM 구현 예제

kotlin코드 복사// ViewModel
class UserViewModel : ViewModel() {
    val userName: LiveData<String> = MutableLiveData()

    fun updateUserName(newName: String) {
        (userName as MutableLiveData).value = newName
    }
}

// Activity (View)
class UserActivity : AppCompatActivity() {
    private lateinit var viewModel: UserViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        viewModel = ViewModelProvider(this).get(UserViewModel::class.java)

        viewModel.userName.observe(this, Observer { name ->
            // 화면에 이름 업데이트
        })
    }
}

4. 아키텍처 패턴의 선택 기준

앱의 규모와 요구사항에 따라 적합한 아키텍처 패턴을 선택하는 것이 중요합니다. MVC는 작은 규모의 애플리케이션에 적합하며, MVP는 테스트 가능성을 강조하는 중간 규모의 앱에 유리합니다. MVVM은 대규모 애플리케이션에서 데이터 바인딩을 통한 효율적인 상태 관리를 필요로 할 때 적합합니다.

5. 결론

각 아키텍처 패턴은 역할과 목적이 명확하게 나뉘어 있으며, 애플리케이션의 요구 사항에 따라 적절히 선택하여 사용해야 합니다. MVC, MVP, MVVM 모두 장단점이 있으며, 팀의 기술 스택과 프로젝트 특성에 맞는 패턴을 선택하는 것이 중요합니다.