211. MVP (Model-View-Presenter) / MVVM (Model-View-ViewModel) - MVC 패턴 한계 극복 안드로이드 iOS 프론트엔드 아키텍처 데이터 바인딩 옵저버 패턴

핵심 인사이트: (210번 MVC 연계) MVC 패턴으로 웹사이트를 짜니 너무 행복했다. 근데 모바일 스마트폰 앱(안드로이드/iOS) 시대가 오면서 재앙이 터졌다. 폰 앱은 화면(View)이 수백 개고 버튼 클릭도 미친 듯이 많다. 멍청한 View가 지 혼자 화면을 못 그리니까, 지휘자인 Controller가 View 100개의 버튼 색깔, 텍스트 크기를 일일이 다 챙겨주느라 코드가 10만 줄로 뚱뚱해져서(Massive Controller) 과로사로 터져버렸다! "야! Controller 지휘자가 너무 불쌍하잖아! Controller를 해고하고 1:1 과외 교사(Presenter)를 붙여주거나(MVP), 아예 뷰(View) 뒤에 거대한 '자동 동기화 복사 거울(ViewModel)'을 달아! 그럼 데이터(Model)가 바뀌면 지휘자가 명령 안 해도 거울(ViewModel)이 자동으로 화면(View)을 실시간으로 착착 바꿔주잖아(데이터 바인딩)!!" 프론트엔드 모바일 시대를 지배한 진화형 뼈대, MVP와 MVVM이다.

Ⅰ. MVC의 치명적 한계 (Massive Controller)

• View와 Model의 더러운 유착: 210번 MVC에서 Controller가 중간에 껴있긴 하지만, 결국 View가 화면을 예쁘게 칠하려면 Model(데이터)을 슬쩍 쳐다보고 값을 빼와야 합니다. 완벽한 격리가 실패합니다.
• Controller의 과로사: 앱이 복잡해질수록 Controller 하나에 수백 개의 View와 Model 통제 로직이 몰빵되어 코드가 괴물처럼 비대해집니다.

Ⅱ. MVP (Model - View - Presenter) - "1:1 밀착 과외 교사" 🌟

안드로이드 초창기를 지배한 패턴입니다. C(Controller)를 P(Presenter)로 바꿨습니다.

• 핵심 목표: "View와 Model은 평생 서로의 얼굴을 1초도 보면 안 된다! 완벽한 남남으로 찢어놔!"
• 작동 원리:
  • View(화면) 1개당 무조건 **Presenter(프레젠터)**라는 1:1 전담 과외 교사를 배정합니다.
  • 화면에 로그인 버튼이 눌립니다. View는 생각 없이 옆에 있는 Presenter 멱살을 잡습니다. "형! 눌렸어!"
  • Presenter가 뒤로 가서 Model(DB)한테 아이디 비번을 확인받고 다시 View로 돌아와서 일일이 떠먹여 줍니다. "야 뷰야, 화면 빨간색으로 칠해! 에러 메시지 띄워!"
• 장단점: View와 Model이 완벽히 100% 분리되어 테스트하기 미치도록 좋습니다. 하지만, View 하나를 만들 때마다 무조건 Presenter 코드를 1:1 쌍으로 1만 줄씩 새로 짜줘야 하는 노가다(코드 중복)가 끔찍하게 터집니다.

Ⅲ. MVVM (Model - View - ViewModel) - "마법의 쌍둥이 거울" 🌟 대세 🌟

MVP의 노가다에 빡친 마이크로소프트와 안드로이드 진영이 내놓은 궁극의 완성본. 현재 프론트엔드(React, Vue, iOS)의 지배자입니다.

• 개념: Presenter라는 꼰대 과외 교사를 죽여버리고, View 뒤에 'ViewModel(뷰 모델)'이라는 마법의 투명 거울 창고를 세워두는 패턴입니다.
• 핵심 마법: 데이터 바인딩 (Data Binding) 🌟 기출 단골 🌟
  • 뷰(View)의 텍스트 박스와, 뷰 모델(ViewModel) 안의 변수를 보이지 않는 마법의 끈(옵저버 패턴, 양방향 바인딩)으로 꽁꽁 묶어(Binding) 버립니다.
  • 기적의 결과: 지휘자가 "화면 고쳐!"라고 1줄의 코드도 짤 필요가 없습니다. 그냥 서버에서 데이터가 날아와서 뷰 모델(ViewModel)의 데이터가 딱 바뀌는 찰나의 순간! 마법의 끈으로 묶여있는 폰 화면(View)의 글씨가 0.001초 만에 스스로 지 혼자서 착! 하고 바뀌어버립니다. (반응형 프로그래밍의 기초)
• 효과: 화면 업데이트를 위한 귀찮은 제어 코드(UI Update Logic) 수만 줄이 지구상에서 완전히 소멸하여 프론트엔드 개발자의 퇴근 시간이 6시간 앞당겨집니다.

Ⅳ. 3대 패턴 비교 (누가 지휘를 하는가?)

📢 섹션 요약 비유: 복잡한 스마트폰 앱 화면을 그리는 전쟁에서 MVC 패턴은 **'오케스트라 1명의 지휘자(Controller)'**입니다. 1명이 100명의 악기 연주자(View)에게 일일이 손가락을 짚어가며 "너 지금 이거 쳐! 넌 저거 쳐!" 지시하려니 지휘자가 과로사로 피를 토합니다(Massive Controller). 이를 개선한 MVP 패턴은 100명의 연주자 뒤에 아예 **'1:1 전담 과외 선생님 100명(Presenter)'**을 붙인 것입니다. 선생님이 1:1로 악보(Model)를 받아서 연주자의 손가락을 잡아끌며 떠먹여 주니(완벽한 분리) 절대 안 틀리지만, 선생님 인건비(코드 작성 노가다)가 파산 수준입니다. 최종 완성형인 MVVM 패턴은 선생님을 다 자르고, 연주자들의 눈앞에 **'마법의 홀로그램 악보대(ViewModel + 데이터 바인딩)'**를 세워둔 기적입니다. 작곡가(Model)가 멀리서 악보를 쓱 고치면, 그 즉시 모든 연주자 눈앞의 홀로그램 악보가 실시간으로 저절로 스르륵 바뀝니다. 누가 지시(제어 코드)할 필요 없이 연주자(View)는 그냥 눈앞의 악보(바인딩 된 데이터)만 보고 연주하면 끝나는, 모바일 프론트엔드 UI 업데이트의 궁극적 자동화 아키텍처입니다.