개발자로 살다 보면 MVC, MVVM 같은 용어를 한 번쯤은 들어본다. 이제 막 개발을 시작한 세대는 Flux, Redux 같은 게 더 익숙할지도 모르겠다.
설계에 관심이 많다. 회사에서 JavaScript를 이용해서 UI 개발을 주로 하다 보니, 자연스레 MVC를 관심사에 담았다.
Model, View, Controller가 있고 저마다의 역할을 나눠 갖는다. MVC로 설계하면 관심사를 잘 분리할 수 있고 재사용성이 좋아져, 유지보수 비용이 줄어든다.
그렇다는데 왜 내 코드는 조금도 나아지지 않는 걸까. 작은 스핀박스 컴포넌트 정도야 쉽게 만들 수 있었지만, 이 녀석은 MVC 없이도 충분히 예쁠 수 있다. 문제는 더 큰 녀석이다. 코드가 조금만 복잡해지면 내가 아는 MVC는 아무런 힘을 쓰지 못했다.
Controller는 너무 쉽게 Super Object가 되었고, Model과 View는 N:N의 관계를 맺으며 새로운 우주를 창조했다. 비즈니스 논리로 뒤섞인 View는 테스트하기 어려웠다. Model, View, Controller로 나누면 유지보수하기 쉬워진다며?
의심이 싹을 틔운다. 내가 뭘 잘못 알고 있는 게 아닐까?
어떤 녀석의 정체를 알고 싶을 때면 나는 그 녀석이 태어난 맥락을 살펴보곤 한다. MVC가 태어난 배경을 뒤져보았다. 흥미로운 사실 세 가지를 알았다.
설계 패턴(Archictecture Pattern)은 소프트웨어를 설계할 때, 반복해서 발생하는 문제에 대한 보편적으로 재사용할 수 있는 해법을 의미한다. 설계 패턴은 소프트웨어 디자인 패턴과 유사하지만 범위가 더 넓다. https://en.wikipedia.org/wiki/Architectural_pattern
설계 패턴인 MVC는 여러 개의 디자인 패턴으로 이루어진 하부 구조를 가질 수 있다.
설계 패턴은 시스템의 근간을 이루는 큰 구조를 정의한다. 이에 반해 디자인 패턴은 구조 안에서 반복하여 나타나는 문제에 대한 저수준의 해법이다.
회사로 비유하자면 설계 패턴이 조직의 성격과 관계를 정의한 조직도라면, 디자인 패턴은 실무진들이 일을 하는 방식을 구체적으로 정의한 업무 매뉴얼인 셈이다. 설계 패턴인 MVC는 여러 개의 디자인 패턴으로 이루어질 수 있다.
GoF의 디자인 패턴에서 MVC를 언급했기 때문일까? MVC를 디자인 패턴으로 이해하는 사람이 많지만, 정작 책에서 저자는 MVC를 디자인 패턴이 아닌 몇 개의 디자인 패턴으로 엮인 클래스의 집합으로 소개한다.
다른 맥락에 MVC를 적용하려면 다른 해석을 적용해야 한다. 이 과정에서 다양한 변종이 생겼다. Application Model, MVP, MVVM, Flux. 이외에도 다양한 유사 설계 패턴과 구현체가 존재한다.
MVC를 접하는 저마다의 상황에서 각자의 시선으로 MVC를 해석하고, 이런 해석이 온라인으로 퍼져나갔다. 맥락을 모르고 해법을 받아들이고, 그것이 재생산되어 퍼지면서, 오해가 만들어진다. 그러다 보니 같은 MVC를 놓고 이야기를 해도 서로 다른 관점을 그릴 때가 많다.
맥락을 이해하고 나니 차이가 보이기 시작했다. 그래서 MVC의 역사를 정리하기로 했다. 우리가 아는 MVC는 MVC가 걸어온 길의 어디쯤에 있는지를 이해하면 대화가 조금은 수월해지지 않을까.
내용이 너무 방대해서 궁금했던 내용을 위주로 정리를 했지만 그래도 길다. 죄다 설명하자니 더 길어지고, 줄이자니 설명이 불충분할까 걱정이다. 내가 이해한 게 맞는지 여전히 불안하고, 지식 사이의 공백이 못내 두렵지만 용기를 내어보기로 했다.
아는 한에서 최대한 정리를 하되 쉽게 설명하는 건 내 능력 밖이라는 사실을 인정하기로 했다. 그럼에도 글이 너무 길어지면 곤란하니 총 세 편으로 나눠서 쓸 생각이다.