라우팅을 꼭 웹서버에서 해야 할까?

요즘 여기저기 듣는게 많아서 이것저것 보다가 생각난 것을 주절주절 적어본다. 어깨너머로만 보고 혹은 대충 써보고 적은 것들도 많아서 내용의 정확성은 보장하지 않는다

최근 node.js + express + ejs + bootstrap을 이용해서 간단히 웹서버를 만들어 띄우는 것을 보면서 꽤 유용한 기술이구나...싶은 느낌을 받았다.

그런데 얼핏보면 깔끔해 보이는 이 구조도 사실상 php의 재탕에 불과하며..여전히 서버코드와 클라이언트 코드가 섞여서 유연성이 떨어지는 방향으로 발전하기 딱 좋게 생겼다.

게다가 서버나 클라이언트나 자바스크립트고 애초에 추구하는바도 서버측과 클라이언트측 코드 재사용이니 기본 구조만 본다면 jsp를 써서 서버나 클라이언트나 자바로 하겠다는것과 크게 달라보이질 않는다.

물론 UI 동적 구성을 jsp로는 할 수 없으니 node.js 묶음이 더 유연하긴 하겠지만... 서버-데이터구축 -> 서버-페이지 렌더링 -> 클라-동적UI 모두를 javascript로 처리하다보면 더 뒤죽박죽이 될것 아닌가 싶기도 하다.

그렇다면 좀 깔끔한 방법이 없을까?

이건 쉽게 시작할 수는 있어 보이지만 쉽게 변화시키기에는 적합해 보이지 않는다.

그러면서 든 생각이... 애초에 서버와 클라이언트가 이렇게 뒤죽박죽 된 것이 웹 개발이 성행하면서 부터 아닐까?..그러니까 JEE.. 뭐 나야 이바닥 초기맴버는 아니니 잘 모르겠다...

어쨌든 데이터 생성이 UI 렌더링에 영향을 받는게 이뻐보이진 않는다. 물론 서버에서 데이터를 줘야 페이지 렌더링을 하겠지만... 엮여도 너무 엮인 느낌이다.

게다가 how-to만 따라하며 던져지는 일만 하던 개발자라면... jsp 페이지(혹은 다른 view template) 안에서 수행되는 java 코드와 그 외 코드는 사실 몇만광년 떨어진 서버와 클라이언트라는 다른 공간에서 수행된다는 사실을 까먹게 될 것 같은 느낌도 든다.

사실 나도 M-V-C 구조가 구체적으로 머릿속에 잘 받아들여지지 않았고...(저 V는 서버에서 만드는 view와 크라이언트가 만드는 view를 섞어놓는 만행을 저질렀다.) service와 dao의 역할분담에 대한 명확한 판단은 아직도 잘 서지 않으며, 스프링에서도 당연히 서버코드에 속하는 Controller 영역이 고전적인 server-client 프로그래밍(네떡 게임, 터미널 모드, svn<->svn client, ..)에서는 당연히 client 영역이였다는 부분도 망각하고 있었다.

컨트롤러(http request와 java 코드의 경계에 있는)에서 주로 처리하는 일은 권한 체크, 파라메터 추출, 결과용 데이터 만들기, response body 만들기(주로 html 렌더링), 필요하면 또다른 웹서버 혹은 메일 발송등의 추가적인 통신 처리 등인데...

권한 체크야 어쩔 수 없다 쳐도, 요즘 권한체크는 컨트롤러에 도달하기 전에 인터셉터 형태로 처리되니 사실 컨트롤러가 할건 아니고,

파라메터 추출도 요즘 JEE 프레임워크들은 알아서 data model에 매핑해주니 딱히 컨트롤러가 할 일은 없고,

결과용 데이터 만들기는... 뭐 컨트롤러가 여전히 해야 할것 같고.. 그런데 db(혹은 다른 storage)를 뒤져서 데이터를 뽑는것 뿐만 아니라 이메일을 발송한다던가, 다른 웹서버에 요청을 전달한다던가 혹은 데이터를 가져온다던가, 핵연료봉을 들어 올린다던가, 혹은 이러한 작업들을 큐에 쌓던가...결국은 결과 데이터를 만들기 위해 수행하는 일련의 작업들이라고 보면 되지 않을까? 펙토리 메소드로 결과용 데이터를 만든다고 치면 이 모든건 펙토리 메소드에서 처리되도 이상할 것이 없는 작업들처럼 보이는데??

html 렌더링(혹은 xml, json 문자열 만들기)도 요즘은 컨트롤러가 data model만 던지면 연관된 view template에 엮어서 html로 만들던가 알아서 xml, json 등으로 변환해준다.

라우팅...그러니까 "이 처리가 성공하면 어느 페이지로 갈 것이다"에 대한 결정을 서버측에서 정해야 할까?

전에는 사용자의 이동을 제한하기 위해서... 그러니까 권한이 없는 페이지에 대해서는 동선을 제공하지 않기 위해서 서버측에서 처리해야 한다고 생각했었다.

그런데... 서버에서 보호해야 하는 것은 페이지 url이 아니라 거기에 담긴 데이터 아닐까?

다른말로 어떻게 해서든 악의적인 사용자가 그 url을 알게 되었을 때 그 url로 접근하면 데이터를 그냥 제공하는게 제대로 된 보안일까?

원천적으로 url을 보여주지 않는다는데 의의가 있을 수는 있지만... 어차피 오픈된 웹인 마당에 url 좀 숨겼다고 진정 보안에 도움이 될까?

결론은? 기존에 컨트롤러라고 생각했던 것은 결국 data model builder 혹은 factory method에 지나지 않게 되며 어떤 형태로든 결과는 data model 하나 던져주면 할일 다 하는거다.

어디서 많이 보던것 아닌가?

RESTful 모델이 그렇게 동작한다.

물론 hypertext 기반이어야 하고 정해진 method 규약을 따라야 하며, http response status를 통해 결과처리를 하는 등등 몇가지 추가사항들이 있지만... 어쨌든 url을 던지면 data가 던져진다... RESTful 틱하다.

요즘 ajax는 당빠가 된 client측의 javascript들이 워낙 좋아져서 페이지 이동 없이 리스트에서 상세보기로, 수정하기로 자유자제로 움직일 수 있다.

내 귀에 제일 유명한 jQuery로 대표되는 javascript 라이브러리? 프레임워크? 들은 서버에서 xml이든 json이든 던져주는 url 하나만 만들어주면 요거로 표도 만들고 그래프도 그리고 소팅도 하고 필터링도 하고 모양도 바꾸고 알아서 잘 한다.

물론 view를 손안대고 코 풀려면 Bootstrap이 요즘 내귀에는 대세이다.

일단 해상도에따라 레이아웃 대충 바꿔주고 메뉴 재구성해주는것만해도 땡큐다.

근데 하나가 비었다... 라우팅... 굳이 컨트롤러에서 할필요 없을것 같아 빼놓았는데 Bootstrap도 jQuery도 이걸 처리하기에는 부족하다.... 그래서 Backbone.js가 있다.

서버측은 Springframework의 RESTful 관련 기능을 최대한 활용해서 데이터 던져주는데만 집중하고,

클라측은 Backbone.js와 Bootstrap을 이용해서 와꾸를 짜고 이쁜게 필요하면 jQuery 투입.

어차피 서버가 던져주는 json/xml 데이터는 jQuery가 쓰기에도 Backbone.js가 쓰기에도 OK.

dwr 혹은 (버려진) Flex의 RemoteObject 같이 엽기적인 뒷구멍 솔루션을 쓰지 않아도 깔끔하게 동작한다.

요런 구성을 설명해주는 슬라이드가 있어서 이 긴 글을 적었다...이 새벽에... 아 졸려...

링크만 남기기 허전해서 주절주절 늘어놨는데... 내가 다시 이 글을 볼 일이 있을지 모르겠다...

어쩌다 다시 봤을 때... "뭔 헛소리?"하지 않을까 싶기도 하고..

아무튼 결론은 아래 링크를 보시라!!

http://www.slideshare.net/morman/integration-of-backbonejs-with-spring-31

Backbone.js를 포함한 client side MVC에 대해서는 아래 링크가 도움이 될 듯.

http://codefactory.kr/2011/12/22/getting-started-with-backbonejs-1-what-is-backbone/

하나 만들어 띄워보고 싶다....언젠가....근데 아마 안될꺼야...