[CS] Coordinator 패턴은 왜 사용하는 것일까?

 

 

✏️ Coordinator 패턴

Coordinator 패턴은 ViewController에서 수행하던 화면 전환에 대한 로직을 Coordinator를 통해 분리한다는 컨셉을 가지고 있다. 

 

나는 개발하다가 ViewController에서 navigate를 할 때 이때껏 큰 불편함을 느끼지 못했었는데, 프로젝트 규모가 6개월을 넘어갈 정도로 커지게 되면서 화면 전환 로직을 더 이상 ViewController가 가지고 있는 게 맞는지, 화면이동 간의 중복코드가 너무 많아지는 문제점들이 있어서 Coordinator 패턴에 대한 관심을 가지게 되었다.

 

 

navigation 하는 코드 그거 얼마나 된다고 추가적인 학습 비용을 감수하더라도 coordaintor 패턴을 써야 하는지 의문이 들 수 있다. 

(나 조차 그랬으니 . .)

 

그래서 이런 의문점들을 풀어보고자 포스팅을 작성해보려고 한다!

(제가 공부하기 위해 작성한 것이므로 틀린 정보가 있다면 알려주세요!)

 

 

도대체 왜 사용하는 것일까?

 

UIKit 기준으로 모든 ViewController에서 화면 전환이 이루어진다.

 

 

기존 코드의 문제점

TableView가 있는 화면인 경우 didSelectRowAt 안에서 특정 셀을 클릭했을 때 A -> B로 넘어가는 로직이 작성되고, 또 다른 뷰에서도 계속 비슷한 형식으로 ViewController안에 화면 전환 로직이 작성될 텐데 앱의 규모가 커져서 관리해야 하는 화면 갯수가 많아지게 되거나 하나의 뷰 컨트롤러 안에서 여러 가지 뷰를 제어해야 하는 상황이라면 뷰컨트롤러는 UI를 그리는 역할뿐만 아니라 어떤 뷰를 보여줄지 관리까지 해야 하는 역할을 담당하게 된다.

 

극단적인 예시를 들어보자면 VC안에 있는 tableView에서 로그인 유무에 따라 다른 뷰를 보여주고자 하면 VC안에서 아래와 같이 분기처리를 해야 하는 로직이 담겨있을 수 있다.

func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {

    if AuthManager.shared.isLoggedIn {
        let detailVC = DetailViewController()
        navigationController?.pushViewController(detailVC, animated: true)
    } else {
        let loginVC = LoginViewController()
        navigationController?.pushViewController(loginVC, animated: true)
    }
}

 

MVVM 패턴을 사용해서 viewModel이 분기처리를 하는 방식으로 해결해 볼 수 있지만, 해당 방법의 한계점은 결국 뷰모델이 로그인여부를 확인해서 뷰에 output을 주게 되면 뷰컨트롤러에서 이동을 시키는 건 동일하다.

if isLoggedIn {
    let detailVC = DetailViewController()
    navigationController?.pushViewController(detailVC, animated: true)
} else {
    let loginVC = LoginViewController()
    navigationController?.pushViewController(loginVC, animated: true)
}

 

반면 Coordinator를 사용하게 된다면 뷰모델에서 로그인 여부 로직을 확인 후, VC에서는 어떤 뷰로 이동할 건지는 관심 없고 coordinator에게 신호만 전달해 주면 각 화면의 Coordaintor가 계층적으로 뷰의 이동을 관리할 수 있기 때문에 View Controller는 뷰를 그리고, Model 혹은 ViewModel과 상호작용 하여 어떤 뷰를 표시해 줄지를 결정하도록 SRP (단일 책임 원칙)을 가질 수 있게 된다.

 

 

즉 VC에서 navigation으로 이동해 주는 방식은 navigation 로직이 VC마다 존재하기 때문에 분산되어 있는 반면 Coordinator를 사용하면 AppCoordinator에서 내려주는 구조이기 때문에 Coordaintor가 하나의 전체 흐름을 관리하는 중앙집중 방식으로 진행된다는 차이점이 있다.

 

따라서 ViewController는 navigation을 직접 수행하지 않고, 이벤트만 전달하며 실제 화면 전환(push/present)은 Coordinator가 담당한다.

 

 

 

 

SceneDelegate에서 B화면으로 진입하는 과정까지를 그림으로 그려보았을 때 차이점을 더 확실하게 알 수 있었다.

VC에서 navigation을 처리하는 과정

 

B ViewController로 가기까지의 과정을 보면 B ViewController로 이동해야 한다는 사실을 A ViewController에서 결정하고 있다.

 

따라서 기존 방식의 문제점은 B화면의 흐름 로직이 A화면에서 다루고 있으니 둘 사이의 결합도가 매우 강하다는 것을 확인할 수 있다.

 

Coordinator를 사용해서 처리하는 과정

반면 Coordinator 패턴을 사용하면 도메인별로 A화면의 Coordinator와 B화면 전환에 대한 Coordinator가 각각 생기기 때문에 B 화면에 대한 결정권은 A Coordinator에게 생긴다.

 

따라서 A ViewController는 이동한다는 신호만 트리거 시켜주면 되기 때문에 다음 VC가 어딘지 신경 쓰지 않아도 되고 이를 통해 뷰 간의 결합도를 낮출 수 있다!

 

수정할 때도 용이한데, 갑자기 기획이 변경돼서 A ViewController에서 C  ViewController로 이동해야 하는 경우 A ViewController 로직을 수정하는 게 아닌 A Coordinator 부분을 수정하면 되기 때문에 각 계층 간의 역할과 책임도 분리되게 된다는 장점이 있다.

 

한마디로 정리하자면 Coordinator 패턴은 navigation 코드를 분리하는 것뿐만 아니라 앱의 화면 흐름(Flow)을 ViewController 밖에서 통제함으로써 ViewController 간 결합도를 낮추고, 흐름 변경을 유연하게 만들 수 있기 때문에 사용하는 것이다!

---

참고

GitHub - kudoleh/iOS-Clean-Architecture-MVVM: Template iOS app using Clean Architecture and MVVM. Includes DIContainer, FlowCoor

 

Clean Architecture and MVVM on iOS

https://zeddios.medium.com/coordinator-pattern-bf4a1bc46930