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

메이트 러너 앱 개발 과정을 공유하는 포스트입니다!

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️

여기서 저희 프로젝트를 더 자세히 볼 수 있어요!

 

그럼 시작하겠습니다!

계획에 없던 코디네이터 패턴이 등장한 이유

저희 팀은 기획단계와 개발 초기에는 코디네이터 패턴을 전혀 고려하지 않았습니다. 왜냐하면 이미 클린 아키텍처와 완전히 새로운 지식인 RxSwift를 프로젝트에 도입하려고 하면서 많은 에너지를 소비했고, 꼭 필요하지 않다면 사용하지 않아도 된다는 생각이 있었기 때문입니다. 

 

하지만 이런 생각은 홈 탭의 기능들을 구현하면서 완전히 달라지게 되었습니다.

이 화면들은 함께 달리는 모드에서 사용자가 달리기를 시작하기까지 거쳐야 하는 화면입니다. 많게는 총 5개의 뷰 컨트롤러를 거치면서 달리기에 대한 설정을 해주어야 합니다. 

 

그 이후에 달리기가 시작되면 아래에 보이는 것처럼 각 모드에 따라 각각 다른 운동화면과 결과 화면을 보여주어야 하기 때문에 총 6개의 뷰 컨트롤러가 홈 탭에 또 포함됩니다.

따라서 우리 앱에서는 홈 탭에 총 11개의 다른 뷰 컨트롤러들이 상황에 맞게 전환되어야 합니다. 이런 상황에서 뷰 컨트롤러에 게 직접 화면 전환을 시키게 되면 다음과 같은 코드를 11개의 뷰 컨트롤러에 모두 작성해주어야 합니다.

 

class ViewController {
	buttonDidTap() {
	    let next = NextViewController()
        next.viewModel = ViewModel(
        	usecase: UseCase()
        	repository: Repository()
        )
    	self.navigationViewController.pushViewController(next)
    }
}

 

이렇게 되면 같은 목적의 화면들을 수정하기 위해서 매번 각 뷰 컨트롤러 파일을 열어 관리해주어야 하고, 만약 유즈 케이스나 내부 서비스의 타입이 동일하다면 동일한 코드가 여러 번 반복됩니다. 

 

이런 불편함을 해결하고, 동시에 뷰 컨트롤러로부터 의존성 주입이라는 추가적인 역할을 분리해내기 위해 코디네이터 패턴을 적용하게 되었습니다.

코디네이터 설계하기

코디네이터를 설계하기 위해서는 먼저 우리가 어떤 단위로 화면들을 코디네이터로 묶어야 할지 고민하는 과정이 필요했습니다.

 

메이트 러너 앱은 사용자가 앱에 접속하면 로그인이 되었는지 여부에 따라 홈 화면으로 이동하거나, 로그인 화면으로 이동합니다. 그리고 홈 화면은 4개의 탭으로 이루어진 탭 바 컨트롤러가 가장 기본 뷰 컨트롤러가 되죠.

 

https://github.com/boostcampwm-2021/iOS06-MateRunner/pull/63

앱, 탭바 코디네이터 구현 by jeonyeohun · Pull Request #63 · boostcampwm-2021/iOS06-MateRunner

프로젝트 깃헙에 처음으로 코디네이터를 도입하고 올렸던 PR의 기록이 남아있는데요..

이게 뭐지..? ㅋㅋㅋㅋㅋ 제 피알을 본 팀원들이 이걸 어떻게 이해했는지 모르겠네요...

 

아무튼 처음 의도는 최상위에 AppCoordinator를 두고 탭 바를 모두 관리하는 TabBarCoordinator를 만들고 그 아래에 트리 형태로 각 탭에 대한 자녀 코디네이터를 두는 방식입니다.

 

실제 구현은 여러 깃헙 레포를 래퍼런스로 삼아 아래와 같이 코디네이터 프로토콜을 정의했습니다.

 

 

finishDelegate는 이 코디네이터가 작업을 모두 마쳤을 때, 즉 이 코디네이터를 통해 관리하고자 하는 뷰 컨트롤러가 더 이상 없을 때 다른 코디네이터에서 다른 연쇄적인 작업을 수행하도록 하기 위해 만든 델레게이트입니다. 예를 들어서 로그인이 모두 끝나면 탭 바로 이동해야하기 때문에 제일 최상위 코디네이터인 AppCoordinator와 LoginCoordinator를 델레게이트로 연결해두면 AppCoordinator는 LoginCoordinator가 종료됐을 때 탭 바에 대한 코디네이터를 시작하도록 정의할 수 있습니다.

 

navigationController는 이 코디네이터에서 사용할 내비게이션 컨트롤러를 의미합니다. 이 코디네이터에서 처리하는 모든 뷰 컨트롤러는 이 내비게이션 컨트롤러로 삽입됩니다.

 

childCoordinators는 Coordinator 인스턴스의 배열로 이 코디네이터의 하위에 들어갈 코디네이터들의 목록을 의미합니다. AppCoordinator의 childCoordinators는 [LoginCoordinator, TabBarCoordinator]가 되겠죠.

 

type프로퍼티는 나중에 특정한 코디네이터를 찾을 때 키 값의 역할로 사용이 되고, start, finsh 메서드는 코디네이터가 처음 시작할 때와 종료될 때의 동작을 정의합니다.

 

이제 홈 탭에서 화면이 전환되고 의존성이 주입되는 것은 이런 식으로 진행됩니다.

꽤 그럴듯하죠? 뷰 컨트롤러는 처음 의도했던 대로 뷰를 그리는 일만 하고 의존성 주입과 화면의 전환은 이제 코디네이터의 역할이 되었습니다.

 

잠깐, 코디네이터는 그럼 뷰컨에 있어야 돼? 뷰 모델에 있어야 돼?

저희 팀은 두 가지 이유 때문에 코디네이터를 뷰 모델에 위치하도록 했습니다.

 

뷰 모델이 화면에서 발생하는 이벤트를 몰라도 괜찮은가?
이게 맞는 생각인지 확신은 없지만 저희는 뷰 모델에는 화면에서 발생하는 모든 이벤트가 전달되어야 한다는 생각으로 구현을 진행했습니다.

 

뷰 모델로 구조를 나누는 이유가 뷰에서 일어나는 일을 테스트할 수 있게 하기 위해서라고 생각하는데 단위 테스트나 시나리오 테스트를 진행할 때 화면 전환이 어떤 경우에서 트리거 되는지 테스트하려면 이벤트가 무조건 뷰 모델에는 한번 가야 하고 뷰 모델에서 코디네이터를 호출해야 한다고 생각했습니다.

 

그렇지 않으면 간단한 예로, 버튼이 눌렸을 때 다른 화면으로 전환이 되는지를 테스트할 수 없고, 뷰 모델에 이벤트를 보낸 뒤에 다시 뷰 컨트롤러에서 코디네이터를 호출하기에는 뷰 모델에서는 아무 일도 하지 않은 채로 뷰 컨트롤러에 함수만 호출하게 되는 격이라는 생각이 들었습니다

 

뷰컨에서 유즈 케이스 데이터에 접근해도 되는 거야?

RunningSetting을 유즈케이스에 둔다면, 뷰 컨트롤러에서 코디네이터를 호출할 때 뷰 모델 -> 유즈 케이스까지 들어가서 값을 가지고 나와야 하는데 두 번에 거쳐 뷰 컨트롤러가 유즈 케이스를 간접적으로라도 접근하는 것이 좋게 느껴지지는 않았습니다.

 

화면 흐름 관리

코디네이터를 사용하면서 얻은 다른 큰 이점이 또 있었습니다. 하위 코디네이터를 통해 실제로는 개별적인 뷰 컨트롤러들을 동일한 목적의 흐름으로 논리적인 단위로 분리할 수 있다는 점입니다. 

 

다시 이 그림으로 돌아가면, 사용자가 달리기 정보를 설정하는 SettingViewController들과 달리기 하는 도중, 그리고 달리기의 결과를 표시하는 RunningViewController 두 흐름으로 나눌 수 있습니다. 하지만 지금은 HomeCoordinator 한 코디네이터가 모든 논리 흐름을 담당하고 있습니다. 

 

위에서 코디네이터를 트리구조로 설계했다고 말씀드렸는데요, 바로 이때를 위해서입니다!

짠!

 

HomeCoordinator를 부모 코디네이터로 두고, 달리기 설정 흐름을 관리하는 SettingCoordinator와 달리기 화면과 결과 화면 흐름을 관리하는 RunningCoordinator로 분리하면 화면 전환의 논리적 흐름을 저희가 원하는 대로 나누고 관리할 수 있게 됩니다.

 

실제로 두 코디네이터의 프로토콜은 다음과 같습니다.

프로토콜만 봐도 이 코디네이터가 어떤 화면들을 처리하게 되는지 바로 알 수 있죠!

 

화면 간 데이터 전달

이제 코디네이터에 대한 전반적은 설계는 마무리가 되었는데요, 한 가지 더 고민할 거리가 있었습니다.

이렇게 달리기 정보를 설정하는 화면들을 전환할 때마다 설정된 데이터 인스턴스를 다음 뷰 컨트롤러에게 넘겨주어야 했습니다.

저희는 이렇게 설정 정보를 모델링하고 모델 불변성을 지키기 위해 새로운 설정 정보가 업데이트될 때마다 이전 값과 새로운 값이 합쳐진 새 인스턴스를 생성하도록 했습니다.

 

결국 이 데이터가 화면을 넘길 때마다 계속 이동해야 하고, 특히 SettingCoordinator에서 RunningCoordinator로 데이터를 넘겨주는 것 역시도 필요했습니다.

 

RuinningSetting 데이터를 다음 뷰 컨트롤러에 넘기는 것은 코디네이터가 화면 전환의 중간다리 역할을 하기 때문에 코디네이터에게 다음 뷰 컨트롤러로의 전환을 요청하면서 데이터를 함께 전달하는 것으로 쉽게 해결할 수 있었습니다.

 

문제는 SettingCoordinator -> RunningCoordinator의 데이터 이동인데요, 이 문제는 Delegate로 부모 코디네이터와 자식 코디네이터를 연결하는 것으로 또 쉽게 해결이 가능했습니다.

이렇게 모든 설정 정보가 세팅되고 마지막에 3초 카운트 다운 화면까지 종료되면, 코디네이터는 설정이 모두 끝났다는 delegate 메서드를 호출하고, 이 메서드를 실제로 구현하고 있는 HomeCoordinator는 delegate 메서드 호출과 함께 전달된 RunningSetting 데이터를 다음 전환 흐름인 RunningCoordinator에 전달합니다.

 

RunningCoordinator는 전달받은 달리기 설정 정보를 보고 각 모드에 맞는 운동 중 화면으로 뷰 컨트롤러를 전환시킵니다.

실전형 알고리즘 - 코디네이터 트리 탐색하기

마지막으로 자신의 자식 코디네이터가 아닌 다른 코디네이터의 인스턴스를 찾아내는 방법에 대해 소개하고 마치겠습니다.

아까 코디네이터 프로토콜에서 소개하지 않고 넘어갔던 findCoordinator라는 메서드가 있었는데요, 각 코디네이터가 가지는 type 프로퍼티를 이용해 자손 코디네이터를 찾아낼 수 있습니다.

각 코디네이터 객체가 가지고 있는 childCoordinators에 있는 코디네이터들을 순회하면서 그 타입이 지금 찾고자 하는 타입과 일치하면 곧바로 해당 코디네이터를 반환하는 알고리즘입니다.

 

알고리즘 문제를 풀면서 많이 짜 봤던 BFS를 그대로 적용해보았는데요, swift에서는 O(1)로 첫 번째 배열 요소를 꺼내는 것을 보장하는 연산이 없지만 (제가 모르는 것이라면 알려주세요!), 코디네이터가 많지 않기 때문에 큰 오버헤드는 아닐 것이라고 생각해서 그대로 사용했습니다.

 

PS 할 때만 사용했던 알고리즘을 실제로 적용해보니 느낌이 새로웠습니다..!

 

마무리

이렇게해서 저희 팀이 프로젝트에 코디네이터 패턴을 적용한 과정을 고유해보았습니다. 코디네이터 패턴도 아키텍처도 아직 미숙한 개발자들이 진행한 프로젝트이기 때문에 부족한 점이 있다면 알려주시면 더 공부할 거리가 생길 것 같습니다 :)

 

저희 프로젝트는 여기서 확인하실 수 있습니다!

GitHub - boostcampwm-2021/iOS06-MateRunner: 함께 달리는 즐거움, Mate Runner 🏃🏻‍♂️🏃🏻‍♀️