Ajax 웹 애플리케이션의 MVC 패턴

 

전통적인 웹 애플리케이션의 MVC 패턴

 

MVC는 Model-View-Control의 약자이다. 사용자에게 프레젠테이션을 제공하는 View, 비즈니스 로직을 처리하는 Model, View와 Model을 제어하는 Control로 분리하여 웹 애플리케이션을 개발하는 형태이다. 이는 MVC 기능을 하나의 웹 애플리케이션에 작성함에 따른 소스의 복잡성과 유지보수의 어려움을 피하기 위한 것이며, 비즈니스 로직을 모델 중심으로 접근하여 효율성을 최대화하려는 의도이다.

 

                 [그림 5] 전통적인 웹 애플리케이션의 MVC 패턴 구조

 

[그림 5]는 JSP/Java 환경에서의 MVC 패턴 구조이다. 시스템 환경에 따라 EJB 컨테이너를 사용하지 않을 수도 있으며, 서블릿이 직접 데이터베이스 서버 또는 애플리케이션 서버와 연결되어 있을 수도 있다. 또한, 데이터베이스 서버와 애플리케이션 서버를 통합하여 하나로 사용할 수 있다. 반드시 상기와 같은 흐름으로 처리해야 하는 것은 아니며 전반적인 흐름이다.

 

여기서 필자가 강조하려는 것은 JSP 역할이다. MVC 패턴으로 나뉘어도 JSP에서 제외되는 것은 Control과 Model 부분이다. MVC 패턴으로 분리한다고 하더라도 실질적인 분리라고 보기에는 어려움이 있다. 특히 Model 부분은 정형화된 형태의 시스템 개발에서는 당연히 분리해야 한다.

 

이렇게 분리를 하더라도 JSP에는 HTML도 있고 자바스크립트도 있으며 JSP 자체 기술도 포함되어 있다. 그런데, HTML은 브라우저 본연의 기능이며 자바스크립트 또한 JSP에 포함될 이유가 없다. 지금까지 어쩔 수 없이 포함되었지만, 분리할 수 있다면 그 방법이 더욱 좋을 것이다. 하나의 JSP에 HTML도 포함하고 자바스크립트도 포함하게 되므로 확장성에 걸림돌이 된다. 또한, XML과 같은 데이터를 처리함에 있어서도 한계가 있다.

 

Ajax MVC 패턴은 이런 모습이 아니다. 확장자 *.JSP에 HTML과 자바스크립트가 포함된 형태가 아니라, HTML은 자체의 확장자인 *.HTML로 별도로 분리하여 작성하고, CSS도 자체의 확장자인 *.CSS로 분리하여 작성한다. 또한, 자바스크립트도 자체의 확장자인 *.JS로 분리하여 작성한 후, 이 모든 것을 Ajax라는 이름 아래 통합하는 모습이다.

 

이렇게 Ajax 요소기술을 분리하여 작성해야 하는 가장 큰 이유는 지면 관계로 자세하게 설명할 수 없지만, 역동적인 유저 인터페이스를 제공할 수 있기 때문이다. Ajax 요소기술 중에 DOM 기술이 있다. DOM 기술은 자바스크립트와 연계하여 HTML 엘리먼트를 생성할 수 있고, CSS를 편집할 수 있으며, 이를 통해 Dynamic한 유저 인터페이스를 제공할 수 있다. 하나로 통합하여 작성하면 Dynamic한 유저 인터페이스를 제공하는데 한계가 있다.

 

Ajax 웹 애플리케이션의 MVC 패턴

 

Ajax 웹 애플리케이션은 의도적으로 MVC 패턴을 구현하지 않더라도 자연스럽게 MVC 패턴으로 구현된다. 아니, MVC 패턴 형태가 되지 않으면 Ajax 웹 애플리케이션을 구현할 수 없다고 해도 과언이 아니다. 다음 [그림 6]은 Ajax 웹 애플리케이션의 MVC 패턴 구조이다.

              [그림 6] Ajax 웹 애플리케이션의 MVC 패턴 구조

 

위의 [그림 6]과 [그림 5] ‘전통적인 웹 애플리케이션의 MVC 패턴 구조’의 EJB 컨테이너, 데이터베이스 서버, 애플리케이션 서버는 두 패턴이 같은 형태를 나타내고 있다. 즉, Model을 담당하는 부분은 전통적인 패턴과 Ajax 패턴이 동일하다. 또한, 웹 컨테이너의 서블릿도 바뀐 것이 없으므로 웹 서버 Control을 담당하는 패턴도 동일하다.

 

하지만, JSP/HTML과 클라이언트 부분은 많이 다르다. Ajax 엔진이 클라이언트에 포함되어 있으며 자바스크립트가 Ajax 엔진에 포함되어 있다. 또한, JSP에 포함되어 있던 HTML이 브라우저에 포함되어 있다. JSP에 포함되어 있던 HTML은 원래 브라우저가 담당해야 할 것이므로 브라우저에 돌려 주었으며, 자바스크립트는 브라우저에 포함되어 있는 기술이며 클라이언트에서 실행하게 되므로 클라이언트가 담당하게 한 것이다. 즉, 각 기술이 실행되는 본래의 자리로 돌아간 것이다.

 

웹 페이지(브라우저)에서 데이터 입력이 발생하면 Ajax 엔진이 이를 인식하고, 데이터 입력이 완료되면 Ajax 엔진이 이를 받아 서블릿에 보내준다. 서블릿은 이를 받아 데이터베이스에 저장하거나 다른 애플리케이션을 호출하여 비즈니스 로직을 처리한 후, 그 결과를 Ajax 엔진에게 돌려준다. Ajax 엔진은 서버로부터 받은 데이터를 편집(HTML+CSS+데이터)하여 브라우저에게 보내주면, 브라우저가 이를 해석하여 웹 페이지에 출력하는 흐름이다.

 

 

ASP/JSP는 어디로?

 

이렇게 HTML과 자바스크립트가 제자리로 가고 나니 JSP에는 남는 것이 없다. ASP도 이런 모습에서 벗어날 수 없다. 그렇다면 ASP/JSP가 존재해야 할 이유에 대해 생각해 볼 필요가 있다. 브라우저와 서버간의 통신을 담당하는 기능이 ASP/JSP에 포함되어 있었으나, XMLHttpRequest를 사용해서 비동기 또는 동기 통신 방법으로 클라이언트와 서버가 데이터를 송수신할 수 있다. 그렇다면 ASP/JSP안에 HTML, CSS, 자바스크립트를 작성해야 할 이유가 없다.

 

또한, ASP/JSP는 동기 방법으로 처리해야 하므로 사용자의 데이터 입력에 따라 즉시에 유저 인터페이스를 제공할 수 없다. 이런 가운데, 두 마리 토끼를 잡기 위해 ASP/JSP안에 Ajax를 적용하려는 움직임이 있지만, 이는 본질적으로 기능이 다른 것을 맞추는 모습이 된다. 즉, 이것도 아니고 저것도 아닌 모습이 될 수도 있다. 그 동안 사용했던 언어에 대한 애착심이 남겠지만, 현실적이고 논리적인 모습을 갖춘 기술이 있고, ASP/JSP안에서 메인 역할을 했던 HTML, CSS, 자바스크립트를 그대로 사용할 수 있으므로 분리하여 정리를 하면 된다.

 

이렇게 하는 것이 쉽지는 않다. 그렇다고 언제까지 계속하여 문제점을 안고 갈 수는 없다. 지금은 사용자가 Ajax에 대해 모르고 있어 요구를 하지 않겠지만, 웹 서핑 등을 통해 Ajax 모습을 보고 느끼게 된다면 틀림없이 Ajax 형태로 개발을 요구하게 될 것이다. 왜냐하면 사용자 자신이 편하게 웹 애플리케이션을 사용할 수 있기 때문이다. 한마디로 Ajax는 피할 수 없는 대세이다.

 

ASP/JSP는 세계 표준이 아니라 특정 업체의 기준이다. 이것을 다른 의미로 해석하면 특정 업체에 의해 기준이 바뀔 수도 있다는 의미가 되며, 개발자 또한 바뀐 모습을 따라 가야 한다. 이러한 모습은 이제 개발자에게 허용할 수 없는 사항이 되었다. 서버용 애플리케이션은 그 나름대로 특징이 있으므로 어쩔 수 없다고 하더라도 웹 애플리케이션만큼은 세계 표준 기술을 적용하여 개발해야 한다.

 

그렇다고 일방적으로 ASP/JSP를 사용하지 말자는 것은 아니다. 객체지향 방법에 의해 정형적인 형태의 서버용 애플리케이션을 개발하기 위해서는 시간과 인원이 필요하다. 품질과 기능을 차제로 한다는 전제조건이 있다면 단기간에 개발할 수 있는 장점이 있다. SQL 정도를 포함하는 것이라면 그 나름대로 장점이 있을 것이지만, 근본적인 접근 방법은 아니다.

 

ASP/JSP를 사용한다고 하더라도 브라우저 창에 입력하는 확장자가 *.asp, *.jsp가 아니라 *.html이 되어야 하며, 서버용 애플리케이션으로 사용해야 한다. 즉, XMLHttpRequest 객체의 URL에 지정하는 서버용 애플리케이션의 확장자가 *.asp, *.jsp가 된다. 그러나 이것이 근본적인 접근 방법이 아니라는 것을 이해할 필요가 있다.