Spring - DispatcherServlet

이전 장까지 MyBatis와 커넥션풀의 활용, 그리고 트랜잭션에 대해 상세히 알아보았습니다. 개인적으로 이 정도의 환경이라면 소, 중형 서비스 구축에는 문제없을 정도로 환상적인 제작환경이 구축됬다고 할 수 있겠네요. 또 실제로 많은 웹개발자들이 이런 포맷을 사용하고 있구요.

이제 우리가 해야 할 것은 누구나 탐낼만한 좋은 개발환경을 구축했으니 드문드문 처리해야할 애매한 문제들을 하나씩 알아나가보는 과정입니다. 그 중 오늘은 우리가 해결해야할 것은 바로 web.xml에 설정한 DispatcherServlet에 대해 알아가고 발생할 수 있는 문제점을 해결하는 것입니다.

스프링MVC는 DispatcherServlet 등장으로 정말 엄청나게 web.xml의 역할이 축소되었습니다. 예전같으면 서블릿을 URL로 활용하기 위해선 반드시 web.xml에 등록해야 했지만 이젠 DispatcherServlet이 해당 어플리케이션으로 들어오는 요청을 모두 핸들링해주니 말이죠.

물론 아직까지 web.xml의 역할은 중요합니다. <servlet>으로 DispatcherServlet을 등록해줘야 하는데다 이 객체의 URL 적용범위 또한 web.xml에다 설정해야 하구요. 향후 고급서비스를 위해 <filter>나 <listener>를 등록하는 역할 또한 web.xml의 기능으로 남아 있습니다.

대신 앞으로 web.xml에서 가장 주요하고 자주 쓰이는 기능인 <servlet>매핑은 이제 완벽하게 DispatcherServlet으로 넘어갔다고 생각합시다. 우리가 web.xml에 DispatcherServlet의 <url-pattern>을 '/'로 설정함과 동시에 이제 모든 요청은 DispatcherServlet의 영역이 된 셈입니다. 물론 DispatcherServlet을 web.xml에 등록해도 계속 서블릿을 web.xml에 매핑해쓸 수 있긴 합니다만 우리가 이런 옛방식을 버리고 DispatcherServlet을 이용해 웹개발을 한다면 앞으로 서블릿 파일을 만들 필요도 없어짐과 동시에 획기적이고 놀라운 @MVC의 혜택을 얻을 수 있습니다. @MVC에 대해서는 차후 설명하기로 하고 오늘은 DispatcherServlet의 역할에 대해 설명드리겠습니다.

먼저 DispatcherServlet을 이용한다는 것은 스프링에서 제공하는 @MVC를 이용하겠단 뜻입니다. @MVC는 그동안 추상적으로만알아오고 발전했던 MVC(Model, View, Controller) 설계영역을 아예 노골적으로 분할하여 사용자가 무조건 MVC로 어플리케이션을 설계하게끔 유도하는 방식인데요. (스프링이 전략패턴을 Dependency Injection이란 이름하에 유도하는 것과 마찬가지죠.) 이 말인즉 초보건 구루건 모두 @MVC를 이용해 어플리케이션을 개발한다면 99% MVC 설계의 원칙대로 웹어플리케이션이 제작할 수 있게 된다는 뜻입니다.

우리가 @MVC라는 이름 하에 DispatcherServlet 클래스를 web.xml에 등록하는 순간 스프링이 있기 전 힘겹게 배웠던 모델1, 모델2는 이제 완전한 추억거리가 되고 말 것입니다. @MVC는 설계자체를 모델1 방식으로 할 수 없게 만드는 데다 그동안 구현하기는 까다롭지만 활용성이 높다고 배웠던 모델2 방식을 모델1보다 쉽게 만들 수 있도록 환경을 조성해주기 때문입니다. 게다가 정확히 따지자면 @MVC는 모델 2방식의 설계도 아닙니다. 다만 우리가 @MVC로 코드를 작성하는 방식이 모델 2와 비슷해서 모델2 방식이라고 부르는 것 뿐이죠.

그렇다면 @MVC에서 DispatcherServlet가 담당하는 역할이 무엇인지 알아봅시다. 먼저 DispatcherServlet에 대해 간단히 정의해보자면 우리가 각각 분리하여 만든 Model 파트와 Controller파트 View파트를 조합하여 브라우저로 출력해주는 역할을 수행하는 클래스라 할 수 있겠네요.

간단하게 DispatcherServlet이 어떤 식으로 클라이언트의 요청을 처리하고 응답하는지 UML과 비슷한 방식으로 나타내 보았습니다. 아마 DispatcherServlet을 처음 접해본 분이시라면 모델2보다 복잡한 처리과정에 당황하실 수도 있겠네요. 하지만 위의 그림이 아무리 복잡해도 당황하실 필요는 없습니다. 어디까지나 저 처리과정의 대부분은 컨테이너가 대신 작업해주며 사용자가 직접 구현해야 될 분량은 얼마 되지 않으니까요. 먼저 위의 작업흐름을 풀어 자세히 설명하자면 다음과 같습니다.

① 클라이언트가 해당 어플리케이션에 접근하면 접근한 URL 요청을 DispatcherServlet이 가로챕니다. 이렇게 요청을 가로챌 수 있는 이유는 web.xml에 등록된 DispatcherServlet의 <url-pattern>이 '/'와 같이 해당 어플리케이션의 모든 URL로 등록되있기 때문입니다. 만약 특정 URL만 적용하고 싶다면 <url-pattern>의 내용을 바꿔주어 범위를 변경시키주면 됩니다.

② 가로챈 정보를 HandlerMapping에게 보내 해당 요청을 처리할 수 있는 Controller를 찾아냅니다. (스프링은 기본적으로 5가지의 핸들러 매핑을 제공합니다.) 이 부분은 스프링의 디폴트 전략에 의해 BeanNameUrlHandlerMapping과 DefaultAnnotationHandlerMapping이 기본으로 스프링MVC에 탑재되있기 때문에 특별한 경우가 아니라면 따로 설정할 필요가 없습니다.

③ 핸들러매핑이 해당 요청을 처리할 컨트롤러를 찾아냈다면 요청을 컨트롤러에 보내줍니다. 컨트롤러는 사용자가 직접 구현해주는 부분입니다. @MVC는 매우 다양한 코딩방식과 직관적이고 편리한 컨트롤러 작성방법을 제공하므로 이 부분에 대해서는 차후 심층적인 분석하여 자신에게 알맞는 전략을 선정해야 합니다.

④ 컨트롤러를 해당 요청을 처리한 후에 보통 컨트롤러는 요청을 응답받을 View의 이름을 리턴하게 됩니다. (물론 다른 핸들러 매핑 전략을 이용한다면 응답 과정이 다를 수도 있습니다.) 그 때 이 이름을 ViwResolver가 먼저 받아 해당하는 View가 존재하는지 검색합니다.

⑥ 해당 View가 있다면 처리결과를 View에 보낸 후 ⑦ 이 결과를 다시 DispatcherServier에 보낸 후 ⑧ DispatcherServlet은 최종 결과를 클라이언트에 전송합니다.

매우 복잡한 과정으로 처리되긴 하지만 이런 DispatcherServlet 전략에서 사용자가 직접 구현해야할 부분은 컨트롤러와 뷰 밖에 없습니다. 나머지 핸들러 매핑이나 리졸버는 대략적인 흐름만 알고 있다가 나중에 필요할 때 필요한 클래스를 컨텍스트에 등록시키기만 하면 그만입니다.

여기서 하나 문제가 발생했습니다. 디스패처 서블릿이 모든 요청을 컨트롤러에 넘겨주는 방식은 괜찮은데 모든 요청을 처리하다보니 이미지나 HTML 파일을 불러오는 요청마저 전부 컨트롤러로 넘겨버리는 것입니다. 게다가 JSP 안의 자바스크립트나 스타일시트 파일들도 전부 디스패처 서블릿이 요청을 가로채는 바람에 제대로 자원을 불러올 수도 없는 상황입니다. 도대체 어떻게 해야 할까요?

만약 이런 처리를 해주지 않는다면 위와 같은 에러가 로그에 기록될 것입니다. 디스패처 서블릿이 해당 요청을 처리할 컨트롤러를 찾지 못했다는 에러메시지죠. 이 문제를 해결하기 위한 방법이 몇가지 있습니다. 첫번째 방법은 아래와 같이 디스패처 서블릿이 처리할 URL과 자바와 관련없는 리소스들의 영역을 분리시키는 것입니다.

/apps - 클라이언트가 이 URL로 접근하면 앞으로 디스패처 서블릿이 담당

/resources - 이 URL은 디스패처 서블릿이 컨트롤할 수 없는 영역으로 분리

근데 이런 처리방식은 괜찮긴 하지만 상당히 코드가 지저분 해지는데다 form에서 모든 요청을 보낼 때 apps라는 URL을 붙여줘야 하기 때문에 직관적인 설계가 불가능해진다는 점이 있습니다. 두번째로는 진짜 말그대로 모든 요청을 컨트롤러에 등록하는 방법입니다. 허나 이런 방식은 정말 소규모 어플리케이션이 아니라면 절대로 해서는 안될 방법이겠죠.

스프링은 이런 모든 문제에 해결함과 동시에 굉장히 편리한 해결방법을 고안해 냈습니다. 그건은 바로 <mvc:resources />입니다. 만약 이클립스를 통해 저처럼 프로젝트를 Spring Template Project 생성하셨다면 servlet-context.xml에서 다음과 같은 코드를 발견하실 수 있으실 겁니다.

<resources mapping="/resources/-*" location="/resources/" />

이 전략은 다음과 같습니다. 먼저 디스패처 서블릿을 통해 들어온 요청을 처리하는데 만약 디스패처 서블릿이 해당 요청에 대한 컨트롤러가 찾을 수 없다면 2차적으로 위의 설정된 경로를 검색하여 해당 자원을 찾아내게 되는 것이죠. 저같은 경우는 기존의 resources폴더의 Depoloyment Assembly를 변경하여 아래와 같이 설정하는 것으로 문제를 해결했습니다.

만약 이런 비 어플리케이션 자원을 따로 분리하지 않고 어플리케이션 자원과 한데 섞어 작업하신다면 지금부터라도 이렇게 분리해서 작업하시길 권장해 드립니다. 먼저 이런 영역분리는 효율적인 리소스 관리와 확장을 돕기 때문입니다.

현대의 많은 대형 웹서비스들의 비 어플리케이션 자원 URL을 보시면 철저하게 static 성격의 외부 자원들을 분리시켜 사용하고 있습니다. 네이버같은 경우는 http://static.naver.net/란 URL을 통해 이런 자원들을 분리하였으며 페이스북은 http://static.ak.fbcdn.net/과 같은 URL로 분리시켰습니다. 이런 일례를 들어서라도 차후 확장을 위해 비어플리케이션 자원은 반드시 분리해야할 영역이라는 사실을 알려드리고 싶네요.

여기까지 DispatcherServlet에 대한 모든 설명이 끝났습니다. 다음 포스트부터는 슬슬 스프링 시큐리티에 대해 다뤄보려고 하는데 아직 아는 부분이 그렇게 많지 않은데다가 해결되지 않은 의문점이 다소 있어서 바로 포스팅하기는 조금 힘들 것 같네요 ㅠㅠ 문제가 해결되는 즉시 포스팅 하도록 하겠습니다.

출처 - http://springmvc.egloos.com/504151