Facebook: MVC Does Not Scale, Use Flux Instead

Facebook이 “MVC는 스케일하지 않는다"라는 결론을 내렸습니다. 확장에 어울리지 않고, 거대한 시스템에는 더더욱 맞지 않는다는 이야기입니다.

이유는 이렇습니다. 새로운 기능을 추가할 때마다 시스템의 복잡도가 기하급수적으로 늘어납니다. 그래서 프로그래머가 “기존 기능에 영향을 주지는 않을까?” 하는 걱정을 하게 되고, 결국 기능을 더하는 일 자체가 두려워집니다. MVC는 작은 앱에는 잘 맞지만, 모델과 뷰의 수가 많아지면 사정이 달라집니다.

모델과 뷰 사이의 데이터 흐름이 양방향으로 일어나기 때문에 복잡도가 폭발적으로 증가하고, 이해하기도 디버깅하기도 어려워집니다. 그래서 Facebook은 MVC와 결별했다고 합니다.

대안의 목적은 “좀 더 예측 가능하도록 코드를 구조화하는 것"입니다. Facebook은 Flux와 React로 이 목적을 달성했다고 밝힙니다. Flux는 데이터 흐름이 단방향인 시스템 아키텍처이고, React는 “predictable"하고 “declarative"한 웹 유저 인터페이스를 빠르게 만들기 위한 JavaScript framework입니다.

구조를 좀 더 들여다보면 이렇습니다. Store는 앱의 모든 데이터를 저장합니다. MVC의 Model과 다른 점은 하나의 객체 인스턴스가 아니라 여러 객체의 상태를 관리한다는 점입니다. Dispatcher는 Controller의 역할을 합니다. Action이 시작될 때 어떻게 Store가 업데이트되어야 하는지를 결정하는, 모든 데이터를 관리하는 중앙 허브입니다. Store의 콜백이 등록되는 장소라고 이해하면 됩니다. Store가 변경되면 View도 변경됩니다. 데이터는 단방향으로만 흐르고, Store와 View는 서로 직접 영향을 줄 수 없습니다. 중요한 점은 데이터 계층이 자기가 영향을 미치는 view를 업데이트 완료한 다음에야 다른 작업을 진행한다는 것입니다.

샘플로 Flux TodoMVC Tutorial을 따라가면 과정을 좀 더 자세히 살펴볼 수 있습니다.

논란

위 글이 올라간 뒤로 Reddit에는 수많은 논쟁이 벌어졌습니다. 재미있게 본 코멘트들을 옮겨 둡니다.

Facebook이 MVC를 잘못 이해하고 있다는 의견이 있습니다. 정통 MVC는 이런 모양인데, Facebook은 아마도 여러 모델을 컨트롤하는 데 하나의 컨트롤러를 쓰려고 시도했을 거라는 추측입니다.

이것이 MVC에 새 이름을 붙인 것일 뿐이라는 의견도 있습니다. MVC를 조금만 변형해서 이벤트 기반 형태로 만든 것이라는 분석입니다. Store가 자신과 호출 순서의 의존성을 콜백 형태로 Dispatcher에 등록하고, Dispatcher는 호출 순서를 보장하면서 작업을 처리하는 역할을 합니다. 결국 Controller의 역할을 Dispatcher와 Store가 나누어 맡게 된 형태로 볼 수 있다는 이야기입니다.