MVC, 정말제대로알고계신가요?
저는 꽤 최근까지 MVC라고 하면 모든 개발자가 같은 개념을 떠올린다고 생각했습니다. 애시당초 디자인패턴이나 아키텍처를 배우는 이유가 다른 개발자, 특히 다른 도메인의 개발자들과의 의사소통을 도와주는 것이라고 생각 했으니까요. 하지만 어느 순간, 안드로이드 개발자분들이나 백앤드 개발자분들과 이야기하면서 뭔가 대화가 어긋나고 있다는 느낌을 종종 받았습니다. 그래서 다시 한 번 MVC 관련 문서들을 훑어보게 되었고, 그 동안 제가 MVC에 대해 오해했던 점들이 여러가지 있었음을 알게 되었습니다.
Apple MVC ≠ Original MVC
가장 중요한 오해는, 제가 애플의 MVC문서에서 배웠던 MVC는 오리지널 MVC가 아니라는 점이었습니다. 제가 MVC문서만 읽는데 그치지 않고, 그 문서의 말미에서 언급하는 Definitive Discussion 까지 모두 읽었더라면 미리 발견할 수 있었던 내용이었습니다.
애플은 해당문서에서, 자신들의 MVC패턴이 오리지널(스몰톡)MVC 를 참고하여 변형한 것이라고 말하고 있습니다. 아래는 공식문서에서 두 MVC를 비교하며 제시한 도표입니다.
이렇게 같은 MVC이지만, 각 컴포넌트 사이의 관계나 책임, 의사소통 방식은 상당히 다릅니다.
특히 Cocoa MVC와 MVP패턴을 비교해보면 재미있는 사실을 알 수 있습니다.
세세한 단어 선택은 조금씩 다르지만, 내용만 놓고 봤을 때 Cocoa MVC는 우리가 MVP라고 부르는 패턴과 거의 완전히 유사합니다. 유저가 뷰를 탭하는 것을 “user action”이라고 부르느냐 “user events”라고 부르느냐의 사소한 차이 정도지요. 그러니까 사실, “iOS에 MVP적용하기”를 하기 위해 별도의 튜토리얼을 읽거나 새로운 프레임워크를 들이거나 할 필요가 없는 것입니다. 우리는 원래부터 MVP를 하고 있었으니까요.
그렇다면 왜 애플은 그냥 자신들이 MVP를 쓴다고 말하지 않고 굳이 MVC를 쓴다고 말해서 사람들을 헷갈리게 하는 것일까요? 답은 의외로 간단합니다. 애플이 CocoaMVC를 정립할 당시에는 MVP가 상대적으로 새롭고 덜 알려져 있던 개념이었기 때문이었죠.
Android MVC ≠ Original MVC
이런 상황은 다른 프레임워크에서도 크게 다른 것 같지 않습니다. 안드로이드의 경우, MVC를 다루는 공식문서에서 다루지는 않지만, MVC를 소개하는 여러 안드로이드 관련 아티클들을 보면 서로 조금씩 다른 MVC를 얘기하고 있다는 것을 알 수 있습니다.
이 역시 세부 컴포넌트들의 역할은 조금씩 다르지만, 컴포넌트들간의 관계나 데이터의 흐름만 놓고 봤을 때는 MVP와 좀 더 유사합니다. 적어도 “전통적인” MVC와는 완전히 다르지요. 하지만 아마 많은 안드로이드 개발자분들이 안드로이드 MVC로 구글에서 검색했을 때 제일 최상단에 나오는 검색결과인 위 도표를 보고 MVC를 배웠을 것입니다. 이러니 안드로이드 개발자와 아이폰 개발자, 백앤드 개발자들이 서로 조금씩 다른 얘기를 하고 있을 수 밖에요.
맺으며
막연히 MVC라고 말하면 서로 이해할 것이라 생각했던 내용이, 생각만큼 표준화되어 있지도, 공유되고 있지도 않았습니다. 가장 기초적인 개념이라고 생각했던 MVC조차도 이러니, 다른 복잡한 디자인패턴이나 아키텍처 관련된 단어들은 더 심할 수도 있겠습니다.
개발자들간의 대화는 참 어렵습니다. 개발자들이 알아야 할 것은 너무나 많고, 서로가 조금씩 아는 분야가 다르기 때문입니다. 심지어는 같은 것을 알아도 조금씩 다르게 이해하고 있네요. 이런 상황에서, 조금이라도 더 원활한 소통을 위해서는 어떻게 해야 할까요? 정답은 없겠지만, 적어도 “우리가 대화하기 아주 어려운 상황에 있다”는 현실 인식은 필수일 것입니다. 이런 인식이 있으면 상대방이 내가 모르는 용어를 쓰거나, 내가 아는 용어도 내가 이해할 수 없는 용례로 사용할 때, 좀 더 부끄러움 없이 “저기… 제가 이해가 잘 안 가서 그러는데, 여기서 XXXX을 OOO한다는게 무슨 뜻인지 설명해 주실 수 있을까요?”와 같은 질문을 던질 수 있을테니까요.
