카테고리 없음

[TIL] 스프링 MVC 패턴, 동작 원리

2nyong 2023. 4. 17. 01:50

- 스프링 MVC 패턴의 등장

Java 공부를 이제 막 시작하고 있지만, 벌써 패턴이라는 단어가 익숙하게 들린다. 싱글톤 패턴이나 빌더 패턴 등등이 있는데.. 지금은 이런 패턴들에 대해 알고 있다라기 보다는 들어봤다라는 말이다.(하하.. 앞으로 공부를 이어나가며 관련 내용도 정리해보겠다!)
 
Java를 모르던 시절 어깨너머로 무슨무슨 패턴이라는 말을 들었을 때는 마치 'Java 코드의 실행은 main 메서드에서부터'와 같이 Java를 사용하기 위해 정해진 규칙 쯤으로 생각했었다. 지금은 패턴이라는게 코드의 유지보수에 대한 편리함을 제공하기 위해 탄생한 개념이라는 것을 알고 있다.
 
처음으로 머릿말을 길게 적어봤는데, 지금 정리할 내용도 '패턴'에 대한 이야기라서 그렇다. MVC 패턴은 Model, View, Controller의 앞 글자를 딴 패턴으로, 이 패턴 역시 코드의 유지보수에 대한 편리함을 위해 탄생했다.
 
과거에는 JSP(Java Server Page)라는 것을 사용해 웹페이지를 만들었다고 한다. Spring과 마찬가지로 Java를 사용한 웹페이지 구현 프로젝트인데, Spring과의 차이점은 Java/html/javascript 가 모두 혼합되어 있는 코드를 사용해 개발을 해왔다는 점이다. 다양한 언어로 작성된 책이 있을 수는 있지만, 그 책의 페이지마다 다양한 언어로 쓰여있다는건 꽤나 어질어질한 일이다.
 
이렇게 작성한 코드는 유지보수에 불리할 뿐더러, 프론트, 백, 디자인 등 각각의 영역에서 협업하는 개발자들 모두를 고통스럽게 만든다. 이러한 문제를 해결하기 위해 협업하는 개발자들의 관심사에 따라 코드를 분리하자는 아이디어를 기반으로 View에는 html/css/javascript를 담아 프론트엔드 개발자가 집중하도록 하고, Model과 Controller에는 Java를 담아 백엔드개발자가 집중할 수 있도록 분리하였다.

 

여기서 View는 말 그대로 사용자 인터페이스(화면)을 담당하고, Model은 데이터(저장, 불러오기 등)와 비즈니스 로직을 담당하며, Controller는 View와 Model 간의 상호작용을 조정하고 제어한다.

 

- 스프링 MVC 패턴의 동작 원리

  1. Client → DispatcherServlet
    - Client가 요청(Request)을 하면 가장 앞 단에서 DispatcherServlet이 요청을 받는다.

  2. DispatcherServlet → Handler mapping
    - Handler mapping에게 부터 클라이언트가 요청한 URL과 일치하는 API path와 Controller 함수를 요청한다.
    - Handler mapping은 API path와 매칭된 Controller 함수를 찾아 DispatcherServlet에게 반환한다.

  3. DispatcherServlet → Controller
    - Client 요청에 대한 처리를 적절한 Controller 함수에게 전달한다.

  4. Controller → DispatcherServlet
    - Controller가 Client에게 받은 API 요청을 처리한다.
    - Model and logical view name으로 부터 받은 'Model' 정보와 'View' 정보를 DispatcherServlet에게 전달한다.

  5. DispatcherServlet → ViewResolver
    - 전달받은 View 정보를 ViewResolver에게 넘겨준다.
    - ViewResolver는 View 정보와 일치하는 html 파일을 찾고, View에 Model 정보를 적용해 반환한다.

  6. DispatcherServlet → View
    - ViewResolver에게 받은 페이지를 View에게 전달한다.

  7. View → Client
    - View를 Client에게 응답(Response)로 전달한다.

MVC 패턴을 학습하며 과거 연구원으로 일하던 시절에 작성했던 코드들이 문득 떠올랐다. 날씨 예측 프로그램의 성능 향상(예측도 향상이 아니라 빨리 돌아가게 만들기)을 목적으로 관심사 분리되어 작성된 코드를 사용자의 선택에 따라 모두 자동으로 결합시켜 주는 서브 프로그램을 작성한 적이 있었다. 
 
아마 '패턴'이라는 개념을 알고 있었다면 그 프로그램의 소스 코드를 그렇게 작성하지는 않았을 것이다.. 현재 누가 그것을 관리하는지는 알 수 없지만 죄송한 마음이다. 종종 이런 마음이 들면 그 당시에는 완전한 절차지향적 프로그래밍이어서 어쩔 수 없었던 거라고 스스로 위로하곤 하지만, 좋은 코드에 대한 이해가 부족했던것이 사실일 것이다. (아직 무엇이 좋은 코드인지도 잘 모르지만, 그것이 좋은 코드가 아니었다는 것만은 알고 있기 때문이다)
 
프레임워크와 프로그래밍 언어에 대한 학습을 통해 유지보수의 편의성과 가독성을 모두 겸비한 '좋은 코드'를 작성하기 위해 노력할 것이다. 미래의 내가 다시 이 글을 보러 온다면 좀 귀여워할지도 모르겠다.