[Android] 아키텍처의 시작, MVC 패턴과 안드로이드의 애매한 동거

개발 입문 시절, 여러분의 Activity는 어떤 모습이었나요? 아마 저처럼 뷰 레이아웃 설정부터 데이터 처리, 네트워크 통신까지 온갖 코드가 뒤섞인 '만능 클래스'였을지도 모릅니다. 하지만 앱이 커질수록 이런 방식은 유지보수의 재앙이 되곤 하죠.

 

오늘은 이런 혼돈을 막기 위한 첫 단추, MVC(Model-View-Controller) 아키텍처 패턴을 안드로이드 관점에서 정리해 보겠습니다.

---

MVC 패턴의 3대 요소

출처: 오픈듀토리얼스

 

MVC는 각 클래스에 명확한 '역할'을 부여해 관심사를 분리하는 전략입니다.

• Model: 데이터와 비즈니스 로직의 집합입니다. "데이터를 어떻게 처리할 것인가?"를 담당하죠
• View: 사용자에게 보여지는 UI 화면입니다. 모델의 데이터를 시각화해 보여줍니다.
• Controller: 사용자의 액션을 입력받아 모델에게 데이터 변경을 요청하는 '중개자'입니다.

 

안드로이드에서 MVC가 애매한 이유 (현실의 벽)

이론은 완벽하지만, 안드로이드에 적용하려고 하면 고개가 갸우뚱해집니다.

1. Activity의 정체성 혼란: MVC 이론상 View와 Controller는 분리되어야 합니다. 하지만 안드로이드에서 xml(View)와 Activitiy(Controller) 없이는 아무것도 할 수 없습니다. 사실상 Activity가 View와 Controller의 역할을 동시에 수행하게 되죠.
2. 강한 결합도: View(Activity)가 Model을 직접 알고 있는 구조이다 보니, 비즈니스 로직과 UI 코드가 끈적하게 엮이게 됩니다. 이는 "하나를 고치면 열 군데가 터지는" 유지보수의 어려움을 초래합니다.
3. 테스트의 어려움: UI와 로직이 섞여 있어, 로직만 따로 떼어내 테스트하기가 매우 까다롭습니다.

 

정리하며: MVC는 실패한 패턴인가?

결코 아닙니다! MVC는 '관심사 분리'라는 현대 아키텍처의 가장 중요한 철학을 제시한 기념비적인 패턴입니다.

 

안드로이드에서는 비록 MVC를 순수하게 구현하기 어렵지만, 이 고민들이 쌓여 이후에 등장할 MVP(Presenter)와 MVVM(ViewModel)의 밑거름이 되었습니다. 초기 디자인 패턴을 제대로 이해해야 왜 현대 안드로이드 개발에서 MVVM이 대세가 되었는지 그 이유를 명확히 알 수 있거든요,

 

 

참고

• 안드로이드 Architecture 패턴
• 안드로이드의 구조 - MVC, MVP, MVVM