MVC 패턴

세 친구의 완벽한 분업

식당에서 요리사가 주문도 받고 서빙과 계산까지 도맡아 하면 주방은 금세 엉망진창이 돼요. 그래서 주문받는 사람과 요리하는 사람, 음식을 담는 접시의 역할이 철저히 나뉘어 있죠. 소프트웨어도 마찬가지예요.

먼저 모델(Model)은 식당의 주방이자 식자재 창고예요. 사용자가 볼 실제 데이터와 비즈니스 규칙을 안전하게 보관하고 처리해요. 회원 정보나 게시글 내용, 포인트 계산 공식 같은 핵심 내용이 여기에 속해요.

다음으로 뷰(View)는 손님이 앉는 테이블과 예쁜 접시예요. 스마트폰이나 모니터 화면처럼 사용자가 눈으로 보고 누르는 모든 시각적 요소를 담당해요. 데이터가 어떻게 생겼는지 예쁘게 보여주는 일만 하죠.

마지막으로 컨트롤러(Controller)는 중간에서 부지런히 움직이는 웨이터예요. 사용자가 버튼을 누르면 그 주문(요청)을 받아서 모델에게 전달하고, 모델이 처리한 결과를 다시 뷰에게 넘겨 화면을 갱신해요.

왜 굳이 셋으로 쪼개서 만들까요?

화면 디자인을 완전히 새롭게 바꾸고 싶은 상황을 떠올려 보세요. 만약 데이터 처리 코드와 화면 디자인 코드가 한 파일에 뒤엉켜 있다면, 글자 색 하나 바꾸려다 결제 기능이 고장 나는 대참사가 생길 수 있어요.

MVC 패턴을 쓰면 화면 디자이너와 서버 개발자가 서로의 영역을 건드리지 않고 독립적으로 작업할 수 있어요. 화면 디자인을 아무리 뜯어고쳐도 데이터를 처리하는 핵심 비즈니스 로직은 안전하게 보존되거든요.

게다가 똑같은 회원 데이터(Model)를 가지고 모바일 앱 화면, 웹사이트 화면, 스마트워치 화면 등 다양한 형태의 뷰(View)를 손쉽게 연결할 수 있어요. 코드를 재사용하기가 훨씬 쉬워지고 버그를 찾는 시간도 획기적으로 줄어들어요.

조금 더 정확히 말하면

실제 개발 현장에서는 사용하는 프로그래밍 언어나 프레임워크에 따라 MVC의 구체적인 작동 방식이 조금씩 달라져요. 초기 데스크톱 프로그램에서는 뷰가 모델의 변화를 직접 감시하다가 화면을 스스로 고치기도 했어요.

하지만 웹 서비스 중심의 현대 환경에서는 대부분의 작업이 '사용자 요청 -> 컨트롤러 -> 모델 처리 -> 뷰 화면 갱신'이라는 명확한 단방향 흐름으로 이루어져요. 컨트롤러가 교통정리를 확실히 해줄 때 구조가 가장 단순해지기 때문이에요.

최근에는 MVC 패턴을 변형한 MVP나 MVVM 같은 발전된 설계 패턴들도 널리 쓰이고 있어요. 형태는 조금씩 다르지만 핵심 목표는 하나예요. 관심사의 분리(Separation of Concerns)를 통해 코드를 튼튼하고 깔끔하게 유지하는 것이랍니다.