web 스프링 프레임워크 다양한 구성

수많은 공공 프레임워크들이 스프링 기반으로 만들어져 있으며, 마찬가지로 대기업 SI도 스프링 프레임워크 기반으로 동작한다. 

1. 스프링 프레임워크 + JSP기반.

백엔드로직은 MVC라는단어를 귀에 못이 박히도록 듣기때문에, 스프링 프레임워크상에 Controller에서 요청을 분기하고, Model에서 실제 디비작업들을 진행한다. Service가 적당히 섞여서 들어가있다. 

지금까지의 예전 로직들은 프론트가 전혀 고려대상이 아니다. 모든 프론트 로직들은 JSP에 섞여있으며 운이 좋으면 CSS정도는 분리가 되어있다. 그렇지만 기본적인 자바스크립트, 제이쿼리및 시간관련 자바스크립트들과, 때때로 급해서 넣은듯한 스타일 속성값과 {}로 둘러쌓여있는 코드로 인해 뭔가 헝클어져 있다는 느낌은 지울수없다. 다만, 고치는데 있어서는 예전방식이 익숙한 사람은 너무나도 편하다. 

JSP는 때때로 WEB-INF에 들어가있는데, 이는 왜냐하면 서블릿으로만 접근가능하게 하며 직접 JSP파일을 호출하지 않도록 막기 위해서다. 서블릿으로 요청을 받아들이며 서블릿으로 페이지를 연결시킨다. 사용자는 아무리 노력해도 JSP파일을 직접 접근이 불가능하다. 서블릿으로도 접근이 안되는 경우는 서버에서 필터를 통해 사용자 세션등을 검사하고 있기 때문이다.

상당히 전형적인 프랙티스인듯한 검색결과가 나오기는 하는데, 아무래도 WEB에 관련된 설정이 들어가있어야 할것같은 곳에 JSP파일이 그대로 꽂아져 들어가 있는 형태는 좀 의문스럽긴하다.

2. 스프링 부트 + 관리화된 프론트(Angular / Bower / Gulp)

여기로 오면 REST API로만 작동하는 백엔드 서버와 사용자에게 보여지는 HTML 과 JS코드를 프론트엔드를 구분한다. 1번의 방식보다 훨씬 서로의 관심사에 대해 간섭을 하지 않는다.

1번의 경우 JSP라는 이도저도 아닌 놈이 백엔드의 로직을 그대로 보여주고 있다면, 스프링 부트를 이용한 벡엔드 로직은 REST API를 제공할뿐이다. 이 API는 목적 웹사이트를 만드는데 쓰일수도 있는데, 물론 아주 다른 웹사이트에다가 붙이는 것도 가능하다. 무조건 백엔드로직과의 통신방식은 주소를 호출하는 REST API로 되어있으며, 프론트는 전혀 관심대상이 아니다. 

프론트로 와보면, 제이쿼리가 등장한 이후, Vue Angular React등 상당히 핫한 자바스크립트가 계속 생겨왔다. 이런것들의 의존성을 관리해주는 바우어, 그리고 SCSS등을 컴파일하고 자바스크립트를 묶어주는 Gulp의 힘을 빌려서 잠깐의 시간동안 Build를 하게 하면 엄청 큰 파일이 있거나 혹은 로그를 죄다 출력하도록 설정하지 않은 경우에 한해 5초내로 웹페이지에 반영된다. 

다만, 완전히 분리된 스프링과 프론트 사이에는 동기화가 꼬일때가 있다. 아무리 browesify등을 이용해 바로바로 리프레시를 하거나 캐시를 날려도 스프링은 뭔가 한박자 늦어질때가 있다. 

직접 Gulp가 스프링 Target디렉터리에 가져다 꽂게 하는것도 하나의 편법이다. 

프론트단에서도 뭔가 지저분함을 참을수 없었는지, Angular는 로직을 처리하고, 뷰에서 실제 모델과 연동된 양방향 바인딩 데이터를 보여주고, REST와 상호작용또한 분리시킬수있다. 백엔드의 정갈함을 이어받은 프론트는 뭔가 굳이 여기까지 해야해 하는 생각과 함께, 유지보수의 용이성은 올라가기 마련이다. 다만, 숙련된 사람에 한하여.. 처음보면 일단 짜증나는건 마찬가지다. 

REST로 동작하는 백엔드는 추세라기도 말하기 민망할 정도로 상당히 오래전부터 대두되었었고 실제로 시장에서는 장고나 플라스크를 이용해서 파이썬과 붙여야 하는 프로젝트도 많이 존재하는것으로 보인다. 점점 OpenAPI가 많아지고, 프론트단의 복잡성과 유연성이 높아지기때문에 당연한 추세다.