• Coordinator 패턴
• Coordinator 패턴이란?
• 인스턴스 직접 생성 문제
• 재사용성 문제
• Coordinator 사용하기
• AppCoordinator
• 그 외 Coordinator
• 마치며
• 참고 문서

MusicSpot은 각 화면을 Feature 단위의 패키지로 별도로 개발하고 있습니다.

1. 증분 빌드가 가능해진다.
2. 각 Feature마다 별도의 데모 앱을 만들 수 있게 된다.

첫 번째 장점의 경우 사실은 저희가 체감하지는 못하고 있습니다.

대규모 앱에 어울리는 구조인만큼, 앱의 규모가 아주 작은 저희 프로젝트에서는 느끼기 힘든 장점입니다.

두 번째 장점이 저희가 생각하는 현재 환경에서 취할 수 있는 이점이라고 보고 있습니다.

그런데, 이런 장점들에 따라 단점도 당연하게 함께 따라오게 되었습니다.

최종적인 앱 타겟 프로젝트가 각 Feature 패키지들을 의존하고 이들을 연결시켜주어야 한다는 점인데요..

그렇기 때문에 화면들을 관리하고 그 사이에서 화면 전환을 담당하는 로직을 별도로 구현할 수 밖에 없었습니다.

Coordinator 패턴

Coordinator 패턴이란?

Coordinator 패턴을 선택하게 된 것은 반강제적이였습니다.

때문에 이 패턴이 왜 등장했고, 왜 필요했던 건지 고민해보지 않았었는데요.. 이것부터 알아봐야 제대로 사용할 수 있을 것 같습니다.

// ViewController.swift
let vc = SearchViewController()
self.navigationController?.pushViewController(vc, animated: true)

iOS에서 일반적으로 이루어지는 화면 전환 로직입니다.

ViewController 인스턴스를 "생성" 하고 있을지 없을지 모르는 NavigationController에게 push 해달라고 요청합니다.

이 때 발생하는 문제점들은 아래와 같습니다.

1. Navigation Stack에 추가할 ViewController를 알고 있어야하고, 심지어 직접 인스턴스를 생성한다.
2. 해당 로직을 모든 화면에서 각기 따로 구현해준 뒤 사용해야 한다. 즉, 재사용되기 어렵다.

인스턴스 직접 생성 문제

기본적인 방식대로 AViewController에서 BViewController로 화면 전환을 하려면 A가 B를 알고 있어야 합니다.

그 말은, A가 B에 강하게 의존하고 있다는 것과 동일한 의미입니다.

그런데 이 프로젝트가 저희 프로젝트처럼 모듈 구조를 사용하고 있다면요?

혹은 MVVM 구조를 적용했는데, BViewController에 주입해야 할 인스턴스가 있다면요?

let serviceA = ServiceA()
let serviceB = ServiceB()
let viewModel = BViewModel(
  serviceA: serviceA,
  serviceB: serviceB
)

let vc = BViewController(
  viewModel: viewModel,
  isCompleted: true
)

View와 관련된 로직만을 담고 싶었던 ViewController가 결국에는 비즈니스 로직에 대한 정보를 알아야 하게됩니다.

UseCase와 Repository를 사용했던 것과 같이 이 생성과 화면 전환에 대한 로직을 다른 레이어에 "위임" 할 수 있다면 정말 좋겠죠?

AViewController가 BViewController에 대해 몰라도 되니 독립적으로 동작할 수 있게 되고, UI와 관련된 로직만을 처리하도록 책임을 분리할 수 있을테니까요.

재사용성 문제

여기 AViewController와 BViewController가 정확히 같은 로직을 통해 CViewController를 생성하고 push하고 있습니다.

지금은 단순히 두 개의 뷰컨만 나열했지만, 각기 다른 상황에서도 같은 형태의 화면 전환 로직이 필요한 경우가 참 많습니다.

인스타그램의 경우를 보더라도 게시물, 스토리, 팔로잉, 검색 등 아주 다양한 경로를 통해 어떤 유저의 프로필 화면으로 진입할 수 있죠.

그런데 이렇게 중복되는 동작을 담당하는 하나의 계층을 만든다면 재사용성에 아주 도움이 되겠죠?

그러기 위해서는 현재 A, B 등 다양한 뷰컨에서 가지고 있던 화면 전환 로직의 책임을 다른 하나의 계층에 "위임" 해줘야 합니다.

화면 전환의 책임을 각각의 ViewController 들에서 Navigator (가칭) 계층으로 옮김으로써 어떤 ViewController가 요청했는지는 상관없이 공통된 로직을 사용할 수 있게되는 것이죠.

이 두 문제는 별도로 생각할 수 있지만 하나의 공통점을 갖고 있습니다.

바로 "위임" 이라는 키워드로 해결할 수 있다는 것입니다.

그리고 iOS 개발에서 이 위임이라는 키워드는 Delegate 패턴이라는 아주 보편적인 방식으로 해결할 수 있습니다.

물론 이 책임을 위임하는 방법에는 아주 많은 방법들이 있겠지만, 그 중 가장 자료가 많은 방법이 바로 Coordinator 패턴인 것입니다.

명칭은 Coordinator이지만 어디까지나 "패턴"이기 때문에 정형화 된 형태는 있겠지만 같은 목적과 수단으로 문제를 해결한다면 모두 Coordinator 패턴이라고 볼 수 있겠네요.

그러니까 Coordinator 패턴은 화면 전환에 특화된 Delegate 방식 중 하나라고 볼 수 있겠네요.

Coordinator 사용하기

이제 Coordinator 패턴이 Delegate 패턴 중 하나라는 느낌을 유념해가며 사용하는 방법을 살펴보겠습니다.

Coordinator 패턴을 처음 이해할 때는 각 ViewController마다 하나의 Coordinator를 사용한다고 이해하면 편합니다.

당연하게도 매번 그렇지는 않습니다. 반복되는 화면 전환의 흐름이 있다면, 이를 Flow라는 단위로 정의하고 Coordinator를 사용할 수도 있습니다.

예를 들어 HomeViewController에서 SearchViewController로의 전환이 필요한 경우를 생각해보겠습니다.

1. HomeViewController의 Coordinator인 HomeCoordinator의 화면 전환을 함수를 호출합니다.
2. HomeCoordinator는 SearchViewController에 대한 책임이 있는 SearchCoordinator를 생성합니다.
3. SearchCoordinator에게 SearchViewController 인스턴스 생성과 push 로직의 실행을 요청합니다.
4. SearchCoordinator가 SearchViewController를 생성하고 Navigation Stack에 push합니다.

기본적인 흐름은 여기에서 크게 벗어나지 않습니다.

ViewController는 자신을 생성한(관리하는) Coordinator에게 화면 전환을 요청합니다.

그러면 해당 Coordinator는 다른 Coordinator를 start() 시키거나 Flow 흐름에 따라 ViewController를 Navigation Stack에 추가합니다.

protocol Coordinator: AnyObject {
  var navigationController: UINavigationController { get set }
  var childCoordinators: [Coordinator] { get set }
  var finishDelegate: CoordinatorFinishDelegate? { get set }
  func start()
  func finish()
}

그리고 위 예시가 이 흐름에 따라 필요한 가장 기본적인 형태의 Protocol입니다.

AppCoordinator

Coordinator 패턴은 childCoordinators 배열로 하위 Coordinator를 관리하는 일종의 트리 구조를 가지고 있습니다.

그 말은 곧, 최상단의 뿌리가 하나 있어야한다는 의미입니다.

이 뿌리가 바로 AppCoordinator입니다.

이 AppCoordinator를 사용하는 방법을 살펴보며 대략적인 Coordinator의 사용법을 알아봅시다.

var window: UIWindow?
var appCoordinator: AppCoordinator?

func scene(_ scene: UIScene,
		   willConnectTo _: UISceneSession,
		   options _: UIScene.ConnectionOptions) {
  guard let windowScene = (scene as? UIWindowScene) else { return }
  let window = UIWindow(windowScene: windowScene)
  defer { self.window = window }

  let navigationController = UINavigationController()
  self.appCoordinator = AppCoordinator(navigationController: navigationController)

  window.rootViewController = navigationController
  window.makeKeyAndVisible()

  self.appCoordinator?.start() // ✅
}

이렇게 UINavigationController를 하나 만들어 Coordinator에 전달해주는 식으로 인스턴스를 생성해 사용합니다.

그리고 Coordinator의 start() 함수를 호출해주는 것으로 담당하는 ViewController를 생성하고 이동하는 로직을 수행하게 됩니다.

그 외 Coordinator

// HomeCoordinator.swift
func startSearch() {
  let searchCoordinator = SearchCoordinator(navigationController: self.navigationController)
  searchCoordinator.finishDelegate = self // 1️⃣
  self.childCoordinators.append(searchCoordinator) // 2️⃣
  searchCoordinator.start() // 3️⃣
}

다른 Coordinator를 생성하고 start() 해주는 과정은 위 과정에서 크게 벗어나지 않습니다.

1️⃣ 생성된 Coordinator의 상위 Coordinator가 본인임을 알리기 위해 Delegate 패턴을 사용합니다. 이후에 finish()를 위해 사용됩니다.

2️⃣ 생성된 Coordinator를 상위 Coordinator에서 참조함으로써 ARC가 자동으로 메모리에서 해제시키지 않도록 유지해줍니다.

3️⃣ 생성된 Coordinator의 start 로직을 실행합니다.

반대로 finish() 해주는 과정은 CoordinatorFinishDelegate를 사용합니다.

extension Coordinator {
  func finish() {
    self.childCoordinators.removeAll() // 1️⃣
    self.finishDelegate?.shouldFinish(childCoordinator: self) // 2️⃣
  }
}

1️⃣ 하위 Coordinator들을 메모리에서 해제시켜주기 위해 childCoordinators 배열을 비워줍니다.

2️⃣ 상위 Coordinator에게 Delegate 패턴을 사용해 종료 요청을 합니다.

마치며

이렇게 반강제(?)로 Coordinator에 대해서 다시 한 번 생각해보는 시간을 가졌습니다.

무엇보다 중요한 것은 "Coordinator 패턴은 화면 전환 로직의 책임 분리를 위한 Delegate 패턴의 일종이다." 라는 사실인 것 같습니다.

또한, 말 그대로 패턴일 뿐이기 때문에 정답 또한 없는 개념입니다.

이 포스트에서는 Delegate 패턴을 사용해 finish에 대한 로직을 처리해줬는데, RxSwift나 Combine과 같은 다른 솔루션을 사용할 수도 있습니다.

멘토링 시간에 Coordinator 패턴의 단점 또한 명확하기 때문에 고민이 필요하다고 해주셨는데, 이 단점을 아직 체감하지 못했습니다.

직접 다시 섬세하게 사용해보며 느낄 수 있었으면 좋겠네요 😊

참고 문서

RxFlow

ZeddiOS - Coordinator Pattern

화면 전환을 해결해 준 Coordinator 패턴

메이트러너: 코디네이터 패턴 적용기