[삼냥이즈 기술노트] MVC 패턴

삼냥이즈에서 NestJS 백엔드를 개발하면서 내가 아는 전통적인 방식의 MVC 패턴을 적용하기 어렵다는 생각이 들었다.

NestJS 서버는 현재 사실상 api 서버로 운영되고 있기 때문에 View라고 부를 만한 것이 Nest 어플리케이션 안에는 없다. 하지만 유니티 클라이언트를 View라고 생각하고 서비스 전체를 MVC 패턴으로 분리하고자 한다면 어려움에 부딪힌다. 기본적으로 MVC 패턴에선 View에서 Model이 전달한 데이터를 스스로 저장하고, 이를 처리하는 로직이 들어가선 안된다. 하지만 게임의 특성 상 응답 시간이 매우 중요하고, 따라서 클라이언트에서 자체적으로 관리하는 데이터를 먼저 띄워준 후, 이를 서버에서 검증하는 방식이 일반적이다. 이런 생각이 문득 들어 생각을 정리하기 위해 MVC 패턴에 대해 알아보았다.

 

MVC 패턴이란?

MVC(Model–View–Controller)는 소프트웨어 아키텍처 패턴 중 하나로, 애플리케이션의 관심사를 분리하기 위해 등장한 구조이다.

애플리케이션을 다음 세 가지 역할로 나누어 설계한다.

• Model
• View
• Controller

---

Model

Model은 애플리케이션의 핵심 데이터와 비즈니스 로직을 담당하는 부분이다.

주요 역할은 다음과 같다

• 서비스에서 사용하는 데이터 관리
• 비즈니스 로직 처리

Model은 View나 Controller에 대해 알고 있으면 안된다. Model은 순수하게 데이터와 비즈니스 로직만 담당해야 한다.

Model이 View에 대해 알고 있고, 이를 이용해 사용자에게 보여지는 화면을 직접 수정하면 안된다는 이야기

 

View

View는 사용자에게 데이터를 보여주는 UI역할을 담당한다.

주요 역할은 다음과 같다

• 사용자 인터페이스 구성
• UI 표시

View는 데이터를 Model과 마찬가지로 Model에서 전달한 데이터를 직접 저장하거나 처리해서는 안된다.

단순히 Model에서 Controller를 통해 전달 받은 데이터를 화면에 표시하는 역할만 해야 한다는 이야기

 

Controller

Controller는 Model과 View 사이의 중개자 역할을 한다.

주요 역할은 다음과 같다

• View를 통해 사용자의 요청을 받아 필요한 Model을 호출
• Model로부터 응답을 받아 결과를 View에 전달
• Controller는 사용자의 입력을 해석하고 시스템 동작을 조정하는 역할

Contoller는 View와 Model을 알고 있어야 한다. Controller는 중개해주는 역할.

이 경우에도 마찬가지로 요청을 해석해서 알맞은 Model을 호출하는 역할만 해야 하고 비즈니스 로직을 직접 처리하면 안된다

Controller가 데이터 관리와 비즈니스 로직을 처리하는 경우 Fat Controller가 되어 한 Controller가 지나치게 많은 역할을 담당하게 된다.

 

백엔드 프레임워크에서 MVC

실제 서버 개발에서는 Model을 더 세분화하는 경우가 많다.

NestJS나 Spring에서는 일반적으로 다음과 같은 구조가 사용된다

• Controller
• Service
• Entity
• Repository

이 경우 각 요소를 MVC 패턴과 대응시키면 아래와 같다.

• Controller - Controller
• Model - Service, Entity, Repository
• View - HTML, React, Unity와 같은 클라이언트

모델과 뷰를 분리했기 때문에 View는 Controller에서 정해준 규칙만 따라 요청을 보내면 Controller에서 요청을 분석해 알맞은 모델을 호출한다.

View는 비즈니스 로직을 알 필요가 없어지고 손쉽게 다양한 인터페이스에서 사용할 수 있는 백엔드를 만들 수 있다.

 

Express의 경우엔 아래와 같은 방식으로 코드를 많이 짠다

app.post("/users", async (req, res) => {
  const user = await db.users.insert(req.body);
  res.json(user);
});

 

이 경우엔 요청에 대해 분석하고, 비즈니스 로직을 실행하고, 데이터에 접근하는 로직이 한 함수 안에 들어 있다. 따라서 위와 같은 경우엔 MVC 패턴이 지켜진 경우는 아니다. Express는 아키텍쳐를 강제하지 않고 유저에게 많은 것을 위임한 프레임워크이기 때문인데 필요에 따라 Express에서도 MVC 구조를 만들 수 있다.

 

REST API 서버는 MVC인가?

API 서버의 경우 HTML 등으로 View를 만들지 않고 JSON 형식의 데이터를 반환하는 엔드포인트만 만드는 경우가 일반적이다.

따라서 전통적인 의미의 View가 어플리케이션 안에 없다.

 

하지만 View가 아예 없다고 보기도 애매한게 서버 어플리케이션만 놓고 보면 View가 없다고 볼 수 있지만, 전체 시스템 관점에선 클라이언트가 View의 역할을 한다고 볼 수도 있다.

 

따라서 관점에 따라 다르게 해석될 수는 있지만 REST API 서버는 전통적으로 완전한 MVC는 아니고 Controller와 Model의 책임 분리를 가져오는 등 MVC의 사고방식을 적절하게 변형해 적용한 구조라고 생각하는 것이 좋을 것 같다.

 

게임 어플리케이션은 MVC 패턴을 적용하기 어려운가?

일반적인 게임에선 클라이언트가 빠른 반응을 위해 먼저 업데이트 하고, 서버가 검증을 하는 방식이 일반적이다. 따라서 서버에서 전달한 데이터를 캐싱해야 하는 경우가 대부분이고, 이 때문에 게임 전체 구조를 MVC 패턴으로 만들긴 어렵단 생각이 들었다. 하지만 이것은 오해로 클라이언트 자체를 거대한 View 덩어리로 보면 안되고, 클라이언트 역시 내부 상태를 저장하는 Model, 사용자로부터 입력을 받고 알맞은 로직을 호출하고 데이터를 전달하는 Controller, 랜더링하는 View를 가진 또 하나의 MVC 구조라고 보는것이 적절하다. 이런 관점에서 생각한다면 게임 어플리케이션에서 MVC를 적용하는것이 어색하진 않다