무조건 쓰던 MVC 왜 쓸까?

목차

1. 내가 MVC를 쓰게된 이유

2. MVC가 처음으로 좋다고 느꼈을 때

3. mvc는 왜 필요할까

4. 향후 발전 방향

1. 내가 MVC를 쓰게 된 이유

처음에 웹 백엔드를 배울 때 처음 배운 것은 mcv 패턴이었습니다.

(출처 gemini)
이때 제가 느낀 생각은

"그냥 Controller에서 다 처리하면 안 되나?"

"간단한 조회 기능 하나 만드는데 파일 3~4개를 왔다 갔다 하려니 너무 번거롭고 비효율적으로 느껴졌다."
이었습니다.

하지만 일단 시키신 대로 하였으며 이후에 팀원들과 같이 프로젝트를 하면서 mvc 패턴의 편리함을 알게 됩니다.

2. MVC가 처음으로 좋다고 느꼈을 때

처음에 mvc 패턴을 배울 때 제가 들은 장점으로는

• 변경될 때 이것저것 수정할 필요가 없고
• 각각에게 역할을 분담하게 하여할 수 있다

이었는데요 처음에는 그렇게 와닿지 않았습니다.

하지만 막상 프로젝트를 들어가 보니 기획을 처음에 완벽하게 하지 못하고
기능 수정 및 추가를 하다 보니 db를 수정하거나, 기능을 추가하는 등 이런저런 변경사항이 생겼습니다

이전에 mvc 패턴을 배우기 전에 혼자서 할 때는 db를 수정하거나 특정 구간을 수정하면
어디서 문제가 생길지 몰라서 테스트를 많이 하는 경향이 존재했지만

mvc 패턴을 사용하다 보니 모든 곳을 수정할 필요 없이
특정 구간만 수정하면 된다는 것을 알게 된 후에는 코드의 수정이나 기능 추가가 빨라짐을 알게 되었습니다.


MyBatis 쿼리 문에서 따로 파라미터 수정이 필요한 케이스가 아니라면 MyBatis의 수정만 이루어지면 되기 때문에
빠르게 수정이 가능했습니다.

파일을 나눈 이유가 형식적으로 나눈 것이 아니라 서로에게 영향을 주지 않기 위한 격리 임을 깨닫는 순간이었습니다.

3. mvc는 왜 필요할까

그래서 mvc와 관련돼 소프트웨어 아키텍처는 무엇이고 왜 좋은지에 대해서 추가적으로 학습해 보았습니다.

아티택쳐는 크기에 따라 조금씩 나뉩니다.

시스템 아키택쳐(client-server, layered, MSA)
시스템을 어떻게 설계할지
서버와 클라이언트 연결 및 DB는 어떻게 둘지

애플리케이션 아키택쳐(MVC, MVVM)
애플리케이션 설계
프로그램 안에서 화면 및 데이터를 어떻게 주고받을지

구현 및 디자인 패턴 GOF(singleton, strategy)
코드를 실제적으로 어떻게 구현할지에 대한 방식

이 중에서는 저희는 애플리케이션 아키택쳐인 MVC를 사용했습니다.
특히 가장 흥미로웠던 것은 과거의 MVC와 현재의 MVC가 조금은 다르다는 점입니다.
이 중에서 애플리케이션 아키택쳐에 대해서 학습을 해보도록 하겠습니다

우선 종류로는 과거의 mvc, 현재의 mvc, mvvm, mvp
이부분에 대해서는 자세히 설명하면 현재 글이 너무 길어져서 이후에 따로 글로 정리 해보려고 합니다.

패턴	핵심 로직 담당	화면 갱신 방법	View-Model 관계	비고
과거 MVC	Controller	서버에서 HTML 전체 새로고침	강한 결합 (직접 연결)	JSP 시절
현재 MVC	Controller	클라이언트가 알아서 (JSON)	약한 결합 (연결 끊김)	Spring Boot 표준
MVP	Presenter	Presenter가 명령 (수동)	분리됨 (Interface)	안드로이드 초기
MVVM	ViewModel	데이터 바인딩 (자동)	분리됨 (관찰)	모던 프론트엔드

이를 통해서 왜 mvc를 사용하고 동시에 왜 mvc가 좋았는지를 이해할 수 있었습니다.

4. 향후 발전 방향

처음에는 생소하고 이해가 안 되었지만 이 아키텍처를 왜 학습 시켰는지 이제야 몸소 이해할 수 있었습니다.
앞으로 프로젝트에서도 mvc뿐만 아니라 다른 아키텍처도 적용 가능한지
혹은 더 적절하다면 이유가 무엇인지를 좀 더 능동적으로 선정하고 학습하며 성장하고 싶습니다.