왜 MVC 패턴을 사용하고 있나요?
여러분들은 MVC 패턴을 왜 사용하나요? 웹 개발을 꿈꾸고 있는 분들은 MVC 패턴을 한번이라도 들어봤을 것이고 실제로 적용시켜 본 경험이 있는 사람도 많을 것입니다.
저 또한 MVC 패턴을 적용하여 프로젝트를 진행했던 경험이 있습니다.
그러면 여러분들은 `다른 패턴도 많을 건데 MVC 패턴을 사용하는 이유는 무엇인가요? 다들 MVC패턴에 열광하는 이유가 뭐죠?` 라는 질문에 답할 수 있으신가요?
네이버 부스트캠프를 진행하던 도중 저는 Spring Boot로 프로젝트를 진행해왔던 터라, node.js를 사용하여 백엔드 코드를 작성할 때에도 당연히 MVC 패턴을 적용하여 디렉토리 구조를 만들었습니다. 그런데 팀원 중 한분이 node.js에서의 장점이 있을건데 Spring Boot에서 사용하는 MVC 패턴을 굳이 적용할 이유가 있나? 라는 생각에 큰 도움을 주지 못했습니다.
"그냥 써오던 거니까", "알아보기 편하니까" 등의 생각밖에 떠오르지 않아서 쉽게 말을 꺼내지 못했습니다. 우리는 어떤 패턴이든 기술이든 도구든 사용할 때, 무작정 사용하지 말고 "why? 왜?" 라는 생각을 가장 먼저 떠올리고 그 근거를 바탕으로 선택해야 한다고 생각합니다.
그래서 저는 MVC 패턴을 사용하게 된 근본적인 이유를 찾기 위하여 MVC 패턴의 역사를 먼저 찾아봤습니다. 여기서는 MVC 패턴이 무엇인지에 대해서는 설명하지 않을 것입니다. MVC 패턴이 궁금하신 분은 아래에 제가 첨부한 링크를 참고하시면 됩니다.
제 글을 읽으신 분들이 MVC 패턴을 왜 사용하는지, 수많은 프로젝트에 MVC 패턴을 적용하는 이유가 무엇인지에 대한 궁금증이 해소되었으면 좋겠습니다.
1979 년, MVC 패턴의 시작..
MVC 패턴의 시작은 1979년, 제록스 팔로 알토 연구센터라는 곳의 연구원인 트리그베 릭스카우드(Trygve ReensKaug) 였습니다. 이때는 Smalltalk 라는 프로그래밍 언어로 개발을 진행중이었습니다.
여기서 릭스카우드가 개발중인 애플리케이션이 점점 복잡해지면서 인터페이스와 비즈니스 로직을 분리해야 할 필요성을 느끼고 MVC 라는 개념을 도입했습니다.
여기서 우리는 MVC 패턴을 사용하는 한 가지 이유에 대해서 알 수 있습니다. 바로 인터페이스와 비즈니스 로직의 분리 입니다.
초기의 MVC 모델 (JSP 모델 1)
초기의 MVC 패턴에는 View와 Controller가 한 공간에서 작성되었습니다.
이렇게 개발하면 어떤 문제가 발생할까요? 혼자 개발하는 것이라면 상관없겠지만, 협업을 하는 과정이라면 프론트와 백의 작업이 한 공간에서 이루어지는 것이기 때문에 한 파일에서 두명이 작업하는 상황이 발생하여 충돌이 날 수 있습니다.
JSP 모델 2
이제 우리가 알고 있는 Controller와 View가 분리된 MVC 패턴이 완성되었습니다.
하지만 View 와 Model이 서로 분리되지 못한 모습을 볼 수 있습니다.
Cocoa MVC
이제 우리가 흔히 알고 있고 적용하고 있는 MVC 패턴의 모습이 나옵니다. Cocoa MVC는 애플에서 발표하였고, 1979년에 만들어진 MVC패턴과는 매우 다른 모습입니다. 현대는 5 Layer라는 조금 더 세분화한 계층을 사용하고 있습니다.
MVC 패턴이 발전하는 과정을 살펴보면 한 가지 공통점이 있습니다. 바로 각자의 역할을 명확히 구분한다는 것입니다.
MVC 패턴이 탄생했던 이유도 인터페이스와 비즈니스 로직의 분리, 그리고 그 다음에는 View와 Controller의 분리, 그리고 다음에는 View와 Model의 분리였습니다.
그럼 여기서 다시 `MVC 패턴을 사용하는 이유가 무엇인가요?`에 대한 궁금증은 해소 되었을 것이라고 생각합니다.
각자 맡은 역할만 하자.
부동산을 통해 집을 구한다고 생각해봅시다. 중개사 한분과 집주인, 그리고 집을 구하는 사람이 있습니다. 중개사는 집주인과 집을 구하는 사람 사이의 중개 역할만 잘 수행하면 되는 것이고, 집주인은 집을 파는데에만 집중하면 되는 것이고, 집을 구하는 사람은 어떤 조건에 들어갈지 등 집을 구하는데에만 집중하면 되는것입니다.
그러면 MVC 패턴을 사용하는 본질적인 이유에 대해서는 알았습니다. 그럼 각자 맡은 역할만 해서 따라오는 장점은 무엇일까요?
- 코드의 복잡성 감소
- 유지보수성과 확장성 증가
- 테스트 용이성
- 넓은 생태계
제가 생각하는 장점은 크게 위와 같습니다.
우선 각 파일은 자기가 맡은 역할만 수행하면 되기 때문에 코드의 복잡성이 당연히 감소할 것입니다.
또한, 비즈니스 로직에 문제가 생겨 수정하거나 새로운 비즈니스 로직을 추가하고 싶을 경우 Model만 건드리면 쉽게 해결이 가능하기 때문에 유지보수성과 확장성이 증가합니다.
그리고 코드가 따로 분리 되어있으니, 테스트 해보고 싶은 부분만 골라서 테스트를 해볼 수 있습니다. 사용자 입력처리를 테스트 해보고 싶으면 Controller를 테스트하면 되고, 비즈니스 로직을 테스트하고 싶으면 Model을 테스트하면 됩니다.
마지막으로 MVC 패턴은 매우 많이 사용하는 개발자들 덕분에 커뮤니티가 굉장히 넓습니다. 개발 도중 필요한 래퍼런스를 쉽게 찾을 수 있고, 문제가 발생했을 경우에도 관련 자료를 쉽게 찾을 수 있습니다.
저는 이글을 작성하면서 MVC패턴의 역사에 대해 처음 알게 되었습니다. 생각보다 오랜 역사가 있다는 것을 알게 되었고, MVC 패턴을 사용하게 된 이유를 알게되었습니다.
이상으로 MVC 패턴에 대한 이야기를 마치겠습니다. 다음은 생성형 AI나 트랜잭션에 대한 이야기를 나눠볼려고 합니다.
참고 자료
'CS' 카테고리의 다른 글
MySQL 인덱스 완벽 가이드: 성능 최적화의 핵심 (1) | 2024.11.17 |
---|---|
[OAuth] 회사 방문증으로 이해하는 인증 원리 (1) | 2024.11.13 |
트랜잭션과 격리 수준 완벽 가이드 (0) | 2024.11.12 |
쿠키와 세션 (0) | 2024.09.03 |
댓글