모바일 앱에서 MVC와 PAC 패턴 적용 분석

초록

본 논문은 모바일 환경의 특수 요구사항—다중 플랫폼 지원과 멀티모달 입출력—에 비추어 MVC와 PAC 디자인 패턴의 적합성을 평가한다. 두 패턴이 UI와 비즈니스 로직을 분리하는 방식, 자동 UI 변환 가능성, 그리고 복합 입력·출력 시나리오에서의 한계를 비교 분석하고, 패턴 선택 가이드라인을 제시한다.

상세 요약

모바일 애플리케이션은 데스크톱에 비해 하드웨어 제약, 다양한 화면 크기, 터치·음성·제스처 등 다중 입력 채널, 그리고 제한된 배터리·네트워크 환경이라는 복합적인 제약을 동시에 만족해야 한다. 이러한 특성은 UI 계층을 어떻게 구조화하느냐에 따라 애플리케이션의 유지보수성, 확장성, 그리고 사용자 경험이 크게 달라진다. 논문은 먼저 MVC(Model‑View‑Controller)와 PAC(Presentation‑Abstraction‑Control)의 기본 구조를 정리한다. MVC는 View와 Controller가 서로 강하게 결합되는 경향이 있어, View가 다양한 디바이스 특성에 맞게 변형될 때 Controller 로직을 재사용하기 어렵다. 반면 PAC는 Presentation, Abstraction, Control이 삼각형 형태로 독립적이며, 각 계층이 서로 인터페이스를 통해 교환하므로 다중 모달 입력을 각각의 Presentation 모듈에 캡슐화하고, 공통 비즈니스 로직은 Abstraction에 집중시킬 수 있다.

핵심 인사이트는 다음과 같다. 첫째, 단일 화면·단일 입력 방식(예: 전통적인 터치 UI)에서는 MVC가 구현이 간단하고 프레임워크 지원이 풍부해 실용적이다. 둘째, 화면 해상도·비율이 크게 변동하거나, 음성·제스처·센서 입력이 동시에 요구되는 경우, PAC의 계층적 분리 덕분에 각 입력 모듈을 독립적으로 교체·추가할 수 있어 코드 복잡도가 낮아진다. 셋째, 자동 UI 변환(Responsive UI) 관점에서 MVC는 View 레이어에 플랫폼‑특화 로직이 집중돼 변환 비용이 증가하지만, PAC는 Presentation‑Abstraction 간의 명확한 계약을 통해 플랫폼‑별 Presentation 구현만 교체하면 된다. 넷째, 기존 모바일 프레임워크(iOS UIKit, Android Jetpack)에서는 MVC 기반 구조가 기본이지만, 최근 MVVM·MVI와 같은 변형이 등장하면서 PAC와 유사한 역할 분담을 시도하고 있다.

하지만 PAC도 무조건 최적은 아니다. Control 계층이 과도하게 복잡해지면 흐름 제어가 난해해지고, 작은 규모 앱에서는 오히려 과잉 설계가 된다. 또한, PAC를 지원하는 표준 라이브러리가 부족해 개발자가 직접 인터페이스 정의와 의존성 주입을 구현해야 하는 부담이 있다. 따라서 논문은 “앱 규모·입력 복합도·플랫폼 다양성”을 3차원 평가 매트릭스로 제시하고, 각 축에 따라 MVC와 PAC 중 어느 쪽이 더 효율적인지 판단하는 의사결정 트리를 제공한다.

결론적으로, 모바일 애플리케이션의 설계 패턴 선택은 단순히 “MVC가 널리 쓰인다”는 관념이 아니라, 멀티모달 요구와 자동 UI 변환 필요성, 그리고 팀의 기술 역량을 종합적으로 고려해야 함을 강조한다.