MVC 패턴 in iOS

iOS에서 Model-View-Controller 사용하기

몇 주전 머무르는 곳 근처에서 iOS 디자인 패턴에 관한 meetup에 참석 했습니다. 말투가 참 재밌는 40대 백인 아저씨가 MVC-N에 관한 발표를했고 내용은 꽤나 흥미로웠습니다. 뜬금 없이 meetup에 참석했던 얘기를 꺼낸 이유는 iOS를 개발하는데 실제로 굉장히 다양한 architectural 패턴들이 존재한다는 점을 말하고 싶어서 입니다. 제가 들어본 패턴만해도 MVC, MVP, MVC-N, MVVM, VIPER 등등 그 이름을 기억하기도 쉽지 않습니다. 그러나 이 모든 architectural 패턴들은 “프로그램의 유지보수를 쉽게 그리고 단위 테스트를 할 수 있게” 라는 공통된 목표를 가집니다. 각각의 패턴들은 장단점이 있기에 어떤 패턴이 가장 좋다고 하기는 힘듭니다. 저는 architectural 패턴 중 가장 기본이 되는 MVC 패턴에 대해서 써보겠습니다. 참고로 최근 iOS architectural 패턴에 관한 좋은 글을 읽었는데 관심있으신 분은 읽어보시면 좋을것 같습니다.

MVC 패턴의 의미

MVC 패턴은 Model-View-Controller의 줄임말 입니다. 먼저 Model은 데이터에 관한 로직을 담는 부분입니다. 계산기 프로그램을 만든다고 가정하면 값들을 계산하고 저장하는 부분이라고 할 수 있습니다. 다음으로 View는 사용자에게 보여지는 화면을 가르킵니다. 계산기 프로그램이 있다면 계산된 값들이 보여지는 UI입니다. 마지막으로 Controller는 Model과 View간의 동작을 관리해줍니다. 계산기 프로그램으로 다시 예시를 들어보자면 사용자가 숫자를 입력함으로써 View에 변화를주면, Controller는 View로 입력된 값을 Model로 전달해주는 역할을 합니다. 또한 Model에서 값이 계산되면 그 값을 Controller는 View에 전달하여 계산된 값으로 화면을 갱신합니다. MVC패턴을 사용하면 프로그램을 구성하는 코드를 역할에따라 부분적으로 나눌 수 있게됩니다. 따라서 만약 프로그램의 UI를 바꾸고싶다면 다른 부분은 그냥 두고 View부분만 바꿔주면 되고 계산 로직을 바꾸고 싶다면 Model부분만 바꾸면 됩니다. 결과적으로 프로그램이 커져도 유지보수가 상대적으로 쉽습니다.

MVC in iOS

Apple은 iOS를 개발할 때 MVC를 권장합니다. MVC로 개발하기 쉽도록 만들어 놨으니 권장한다고 볼 수 있을 것 같습니다. 아래의 그림은 Stanford iOS 강의에 나온 iOS MVC 구조입니다.

그림에서 볼 수 있듯, Model과 View사이에는 중앙선이 그어져 있습니다. 즉 서로에게 independent 합니다. 따라서 View와 Model은 절대 서로에게 접근하면 안됩니다. 반면 Controller는 Model과 View에 접근하여 값을 전달하고 받아오는것이 역할이므로 Controller에서 Model로의 접근, Controller에서 View로의 접근 모두 가능합니다. 그렇다면 1. Model에서 Controller로의 접근 2. View에서 Controller로의 접근은 어떨까요? 먼저 1. Model -> Controller의 접근은 가능하지만 MVC 패턴에 어긋납니다. Model은 데이터의 값을 바꾸고 관리하는것만 해야합니다. 그렇다면 Model의 값이 바뀌었을 때 어떻게 Controller에게 값을 전달 할까요? iOS에서는 이때 Notification(또는 KVO)을 사용하여 해결합니다. Notification이란 Model의 값이 바뀌었을 때 Model이 Controller에게 바뀐 값을 직접 전달하는것이 아니라 Model은 자기의 값이 바뀌었다는 사실을 알리면(notification을 주면) Controller가 이를 듣고 Model에 접근합니다. 이렇게 하면 Model의 바뀐 값에 접근하는 로직을 Controller에 위치 시킬 수 있습니다. 다음으로 2. View -> Controller의 접근은 어떨까요? 위와 비슷하게 View는 화면을 갱신하는것이 역할이기 때문에 유저가 View에 값을 입력하거나 터치를 했을때 그 변화를 Controller에 직접 전달하면 안됩니다. iOS에서는 이럴 때 Delegate(또는 Data Source)을 사용하여 해결합니다. Delegate는 말그대로 위임한다는 뜻으로 유저가 화면에 값을 입력 할 때 혹은 터치나 드래그를 하여 event를 발생 시켰을 때, 프로그램에서 해야 할 일들을 Controller에게 위임합니다. 따라서 View의 변화에 대응하는 로직을 Controller에 위치 시킬 수 있습니다. 다소 말장난 같이 들리실 수 있겠지만 Notification, KVO, Delegate, Data Source라는 검색어로 구글링을 좀 해보시면 위와 같은 방법으로 “접근” 에 관한 코드를 Controller에 위치 시키는 것이 가능하다는 걸 알 수 있을겁니다.

마지막으로 iOS의 MVC 구조의 장단점에 대해서 간략하게 언급 하겠습니다. MVC는 역할분담을 고려한 구조를 빠르게 구현 할 수 있다는 장점이 있습니다. 즉 생산성이 매우 좋습니다. 그러나 iOS의 MVC는 Model-View-Controller의 분리가 완전하지 않아서 실제로는 View의 생명주기에 관한 코드가 Controller에 모두 위치하고 네트워크 통신에 관한 코드도 Controller에 위치하게 되기 때문에 Controller의 크기가 지나치게 커지는 경향이 있습니다. 이런 문제점을 극복하고자 MVC-N, MVP, MVVM 등등의 패턴들을 사용하기도 합니다. 그러나 iOS에 입문하시는 분들께는 더 나은 architectural 패턴을 찾는데 너무 많은 시간을 투자하지 말라고 조언드리고 싶습니다. architectural 패턴은 어디까지나 구조적인 패턴일뿐 더 나은 코드를 작성하기 위해서는 코드를 간결하고 가독성있게 작성하는것이 더 중요하다고 느낍니다. 저도 iOS를 시작한지 한달 반이 조금 넘었는데, 처음에 iOS 프로그래밍을 시작하면서 지나치게 architectural 패턴에 집착 했던거 같습니다. 아무튼 디자인 패턴은 정말 배워도 끝이 없는 것 같습니다. 기회가 되면 다른 패턴들에 대해서도 정리해 보도록 하겠습니다.