[iOS] Coordinator (1) - 코디네이터란 무엇인가? 개념 이해하기

✔️ 이 글의 시리즈는 아래의 세 문서를 참고해 작성되었습니다.

• Coordinator Pattern

• How to use the coordinator pattern in iOS apps

• Advanced coordinators in iOS

✔️ 아래의 두 문서는 조악하게나마 번역을 해 두었으니 혹시 필요하신 분 참고하세요.

• How to use the coordinator pattern in iOS apps 해석 및 정리
• Advanced coordinators in iOS 해석 및 정리

✔️ 다음 편인 (2) - 코디네이터 구현하기 는 여기 에 있습니다.

✔️ 노션이 더 편하시다면 여기의 1,2편 통합본 를 확인해 주세요.

---

Coordinator (코디네이터)란?

Coordinator는 coordinate(조정하다)라는 동사의 의미를 담고 있습니다.

코디네이터는 뷰 컨트롤러들을 모으고 관리하는 역할을 하는 객체입니다.

코디네이터 패턴은 앱의 flow 관리를 쉽게 해 주고, massive view controller를 가볍게 해 주는 패턴입니다.

Coordinator를 왜 사용하는가?

iOS 개발자라면 여러 번 작성했을 코드를 먼저 살펴봅시다.

// HomeViewController.swift

func loginButtonTapped() {
        let vc = LoginViewController()
        vc.title = "Login"
    navigationController?.pushViewController(vc, animated: true)
}

홈 화면에서 로그인 버튼이 눌리면, 로그인 화면으로 전환하는 동작을 수행하는 간단한 코드입니다.

• 홈 뷰 컨트롤러가 로그인 뷰 컨트롤러를..
  • 생성하고(LoginViewController()),
  • 구성하고(vc.title = "Login"),
  • 표시하고(navigationController?.pushViewController(vc, animated: true)) 있습니다.

위 코드의 문제점

위와 같은 코드는 뷰 컨트롤러 간에 강한 결합을 형성한다는 문제가 있습니다.

• 뷰 컨트롤러 간의 연결을 하드코딩한다.
  • 어떤 뷰가 어떤 뷰 컨트롤러로부터 띄워진 것인지 일일이 찾아 보아야 합니다.
• 뷰 컨트롤러 재사용이 어렵다.
  • 같은 뷰 컨트롤러가 또 필요할 때 마다 위와 같은 생성, 구성, 표시 과정을 반복해야 합니다.
  • 코드 복사붙여넣기가 일어나기 쉬운 환경입니다.
• 하위 뷰 컨트롤러가 상위 뷰 컨트롤러에 접근 후 지시하고 있다.
  • 위 예시로 설명하자면, HomeViewController가 자신의 상위 뷰 컨트롤러인 navigationController에게 LoginViewController를 표시하라고(push)하고 있습니다.
  • 상위 뷰 컨트롤러가 하위 뷰 컨트롤러를 관리해야 하는데, 이와는 반대로 하위 뷰 컨트롤러가 상위 뷰 컨트롤러에 접근 및 지시해야만 하는 상황은 바람직하지 않다고 할 수 있습니다.

Coordinator 패턴은 이러한 문제를 해결하기 위해 탄생했습니다.

Coordinator의 장점

• 뷰 컨트롤러들의 연결을 끊는다.
  • 각각의 뷰 컨트롤러가 자신의 전후 흐름을 알지 못하게 한다.
• 앱의 흐름(flow)을 제어한다.
  • flow logic을 뷰 컨트롤러로부터 분리한다.
  • 코디네이터가 flow logic을 관리하며, 뷰는 코디네이터를 통해서만 소통한다.
  • 화면 순서가 바뀌더라도 코디네이터만 확인하면 되므로 수정이 용이하다.
• 뷰 컨트롤러가 ‘뷰와 모델 바인딩’이라는 목표에만 집중할 수 있게 해 준다.
• 뷰 컨트롤러 재사용이 용이하다.
  • 어떤 뷰가 여러 번 반복적으로 필요하면 여러 번 생성하는 대신 코디네이터의 동일 메서드를 반복 호출하면 된다.
  • 뷰 컨트롤러 생성 코드가 프로젝트 여기저기에 남발되는 것을 막을 수 있다.
• 앱의 동작이 투명해진다.
  • UIViewController는 viewDidLoad()와 같이 UIKit으로부터 호출될 때까지 기다리거나, 정해진 흐름을 따라야 한다.
  • 반면 코디네이터는 개발자가 완전히 제어할 수 있는 객체로, 관리가 상대적으로 쉽다.

Coordinator 의 구조와 동작

앱의 규모가 작은 경우 코디네이터 1개만으로도 뷰컨트롤러들을 관리할 수 있습니다.

앱의 규모가 커지면 부모 코디네이터와 자식 코디네이터로 역할을 분리할 수 있습니다.

✅ 이 글에서는 앱의 크기가 크다고 가정하고, 부모 코디네이터(AppCoordinator)와 자식 코디네이터를 모두 갖는 패턴을 설명합니다.

AppCoordinator (부모 코디네이터 / 상위 코디네이터)

부모 코디네이터. 코디네이터를 관리하는 코디네이터.

• 앱의 전체 흐름을 관리하는 상위 수준의 코디네이터이다.
  • 화면을 전환하는 메서드들을 가지고 있다.
• 자식 코디네이터를 생성하고 관리한다.
• 자식 코디네이터로부터 흐름 전환에 대한 요청을 받으면, 다른 곳으로 흐름을 이어 준다.

AppCoordinator? MainCoordinator?

• 상위 코디네이터를 MainCoordinator라고 하는 경우도 있습니다. 자식 코디네이터가 없는 경우 이렇게 이름을 붙이는 것 같습니다.
• 코디네이터 패턴을 만든 Khanlow의 블로그에서, 자식 코디네이터가 있는 경우에는 상위 코디네이터를 AppCoordinator라고 지칭하는 것 같습니다. 이 글에은 그러한 경우를 다루고 있으므로 AppCoordinator라고 표현하겠습니다.

Child Cooridnators (자식 코디네이터 / 하위 코디네이터)

• 자식 코디네이터들은 각각 다른 기능과 책임을 맡는다.
  • 앱의 기능을 작게 나누어 재사용이 쉬워진다.
• 자신이 담당한 뷰 컨트롤러를 생성하고 흐름을 관리한다.
  • 보통 자신이 담당한 뷰 컨트롤러의 이름을 따서 코디네이터 이름을 짓는 것 같습니다.
  • ex. HomeViewController ← HomeCoordinator가 관리
• 자신의 흐름이 끝났을 때, 부모 코디네이터에게 이를 알린다.

Coordinator 사용 전후 비교

도표로 간단히 그려보자면 코디네이터 사용 전과 후는 다음과 같이 비교할 수 있습니다.

홈 화면, 로그인 화면, 마이페이지 화면이 있는 간단한 앱을 생각해 봅시다.

코디네이터 사용 전

여러 개의 뷰 컨트롤러들 사이에 직접적인 연결이 존재하는 모습입니다.

• 로그인 화면에서 “홈”버튼을 눌렀을 때, 홈 화면을 띄워야 한다고 가정해 봅시다.
  • LoginViewController에서 홈 버튼을 눌렀을 때 함수가 호출되고,
  • 그 함수에서 HomeViewController를 생성 후 push해야 할 것입니다.
• 이번엔 마이페이지 화면에서도 “홈”버튼을 눌렀을 때, 홈 화면을 띄워야 한다고 가정해 봅시다.
  • MyPageViewController에서도 홈 버튼을 눌렀을 때 함수가 호출되고,
  • 그 함수에서 HomeViewController를 생성 후 push해야 할 것입니다.

이처럼 화면이 3개밖에 없는 간단한 상황인데도 HomeViewController를 생성하는 코드가 두 군데나 생기게 됩니다.

만약 다른 화면이 더 추가되고, 그 화면에서 홈 화면으로 돌아가야 할 때도 중복 코드가 계속해서 생기게 됩니다.

코디네이터 사용 후

코디네이터 패턴을 적용한 후의 모습입니다.

• 먼저 가장 큰 차이점은 “뷰 컨트롤러들 간의 연결” 이 없어진 것입니다.
  • 코디네이터가 없을 때는 자기들끼리 무분별하게 소통하던 뷰컨트롤러들이 이제 자신의 전용 코디네이터를 통해서만 소통하고 있습니다.
• 각 객체의 소통 대상과 방식이 정해져 있습니다.
  • 최상위 코디네이터(=부모 코디네이터)는 자식 코디네이터들을, 자식 코디네이터들은 뷰컨트롤러들을 관리합니다.
  • 뷰 컨트롤러는 자신의 코디네이터(자식 코디네이터)와 소통합니다.
    • 뷰 컨트롤러를 생성하려면 담당 코디네이터를 통해 생성해야만 하며, 코디네이터 이외의 지점에서 생성되어서는 안 됩니다.
  • 자식 코디네이터들은 부모 코디네이터의 지시를 받아 담당 뷰 컨트롤러를 관리합니다.

다음 편에서는 실제 코드와 함께 코디네이터 패턴을 구현해 봅니다.