268
한 권으로 끝내는 Node & Express
델의 변형이지만, 뷰 모델 하나에 모델 여러 개가 결합될 수도 있고, 여러 모델의 부분합이나
단일 모델의 일부가 될 수도 있습니다. 언뜻 보기에는 불필요하게 복잡해 보일 수도 있지만 필
자는 여기서 대단히 가치 있는 개념을 발견했습니다. 그건 바로 모델을 ‘보호’한다는 겁니다. 순
수한
MVC
에서는 모델을 변형하거나, 뷰에만 필요한 것을 추가해 모델을 더럽히고 싶어질 때
가 있고, 심지어 그런 일이 필요하기까지 합니다. 뷰 모델에는 ‘외부’가 있습니다. 표현에만 필
요한 뷰가 있어야 한다면 뷰 모델에서 하면 됩니다.
어떤 패턴이든 마찬가지지만,
MVC
를 따를 때도 얼마나 충실히 지킬지 결정해야 합니다. 원칙
에 너무 충실하면 최신 기술을 ‘올바른’ 방식으로 구현하기 위해 영웅적인 노력이 필요할 겁니
다. 반면 너무 방만하면 유지보수 문제가 생기고 기술적인 부채를 지게 됩니다. 필자는 충실한
쪽을 선호하는 편입니다. 다행히
MVC
와 뷰 모델은 자연스럽게 따라야 하는 부분이 있고, 이
패턴으로 적응하기 어려운 상황은 극히 드뭅니다.
17.1.
모델
필자는 모델이 무엇보다도 중요한 요소라고 생각합니다. 모델이 견고하고 잘 디자인되어 있으
면 표현 계층을 만들거나 추가하기는 매우 쉽습니다. 하지만 다른 길로 가기는 어렵습니다. 모
델은 프로젝트의 기반입니다.
표현 계층이나 상호작용 코드로 모델을 어지럽히지 않는 게 정말 중요합니다. 어지럽히는 게
쉽거나 편리한 해결책으로 보이더라도, 결국 두통거리