SPA(Single Page Application)

팀 버너스 리 옹이 웹을 만든 이후 웹 기술은 많은 변화를 거쳐왔다. 내가 처음 웹을 접한것이 중학생 시절이던 1998~9년경 당시 유행하던 불법 게임 및 음악파일 다운로드 사이트들을 통해서였으니 나름 꽤 초기부터 접하고 있었던 것 같다. 당시만 해도 동적 DHTML이 신기술이니 브라우저가 익스플로러보다는 넷스케이프가 좋니 하던 시절이었으니 말이다. 그 시절에 브라우저 전쟁의 산물인 자바스크립트가 지금처럼 퍼지게 될 줄은 상상도 못했다. 당시에 자바스크립트는 브라우저 위에서만 실행되었고 브라우저 성능도 초기버전들이라 좋지 않았다. 그러던 것이 익스플로러 6, 7, 8 버전을 거치고 파이어폭스, 구글 크롬이 등장하면서 현재에 이르고 있다.

자바스크립트의 역사에 있어 가장 중요한 브라우저는 구글 크롬이라고 생각한다. 구글 크롬에 탑재된 V8 엔진은 스크립트 코드의 실행 속도를 혁신적으로 향상시켰다. 크롬 출시 초기 스크립트의 실행 속도를 다른 브라우저들과 비교해 봤을 때 개인적인 느낌으로는 타 브라우저에서는 10초 걸리는 코드가 크롬은 1초 걸리는 정도의 차이를 느낄 정도였으니 말이다. 이 V8 엔진 덕에 현재의 Nodejs 프로젝트도 나오게 되었고 지금 말하려고 하는 SPA도 가능했다라고 한다면 좀 비약일려나...

1. 기존 방식과 차이점
기존의 웹 구현 방식은 각 페이지 마다 한번의 요청이 필요했다. HTML 코드는 모두 서버에서 계산되어 브라우제어 텍스트로 전달되며 브라우저는 전달받은 html 텍스트를 토대로 화면을 렌더링하여 보여주면 역할은 끝이었다. 물론 2005년 즈음에 소개된 Ajax기술을 통해 SPA가 아니더라도 한 페이지에서 서버에 여러번의 요청을 할 수 있었지만 말이다. SPA는 방금 언급한 Ajax를 좀 더 적극적으로 사용한다. 기존에는 Ajax를 사용하지 않거나 페이지의 일부를 조작하기 위해서 사용했다면 SPA에 와서는 아예 페이지 전체를 구성하기 위해 자바스크립트와 Ajax를 사용한다. 페이지 요청은 최초 페이지가 로딩될 때 한번 뿐이며 표시해야할 데이터는 물론 데이터를 표시하기 위한 태그, 페이지 이동까지도 자바스크립트로 구현한다.

이 방식의 장점은 우선 사이트의 전체 트래픽이 감소한다. 기존방식은 페이지 이동시 마다 갱신하지 않아도 되는 부분까지 서버에서 다시 전달받아야 하지만 SPA구현에서는 변경되는 부분에 대한 코드만 받으면 되기 때문이다.

두번째로 구현과 변경이 편하다. SPA 방식으로 사이트를 구현하게 되면 사이트 구현 코드가 전체적으로 서버쪽 코드와 브라우저쪽 코드로 분리가 되기 때문에 인원이 많으면 각각의 역할을 분리하여 구현하면 된다. 또 자연스럽게 데이터와 뷰가 분리가 되는 효과가 있기 때문에 화면 구성이 변경될 때도 상대적으로 쉽게 대응이 가능하다.

이런 장점에 반대급부로 단점도 존재한다. 내가 생각하는 단점은 다음과 같다.

우선 검색엔진에 등록이 되지 않는다. SPA 내의 각 페이지는 스크립트의 실행 결과이지 별도의 독립된 URL이 없기 때문에 검색엔진에 의해 인덱싱이 되더라도 해당 페이지로 바로 접근할 방법이 없다. SPA를 구현한 프레임워크들은 fragment나 route를 통해 각 페이지에 독립적인 url을 제공할 방법이 있다. 하지만 이것은 선택사항일 뿐더러 route를 구현했다 하더라도 검색엔진에서 지원하지 않으면 소용이 없다. 구글은 페이지 내의 스크립트 코드까지 실행시켜 페이지를 인덱싱하는데 국내 검색엔진은 그렇게 하지 않는다고 한다. (불확실한 부분입니다. 자세한 내용을 아시는 분은 알려주세요.)

둘째로 다국어 구현이 애매하다. 브라우저에서 실행되는 스크립트로 사이트를 구현하기 때문에 일반적인 서버사이드 스크립트들(ASP.net, JSP, php...)에서 제공하는 다국어 변환 기술을 적용하기가 애매하다. 스크립트 단에서 다국어를 따로 구현할 수도 있는데 이렇게 되면 서버쪽 다국어, 스크립트쪽 다국어로 나뉘게 되어 중복해서 관리해야 하는 부담이 있다. 아예 템플릿을 내려줄 때 서버쪽에서 다국어를 적용시켜 전달할 수 도 있을듯 한데 아무래도 귀찮지 싶다.

2. 구현 프레임워크
SPA를 구현할 수 있게 지원하는 프레임워크들은 많이 나와있다. Knockout이라던가 회사 프로젝트에서 사용했던 Backbone과 Marionette, 한창 대세인 구글의 Angularjs 등등. 그밖에도 일일이 열거하지 힘들 정도로 많은 프레임워크들이 있는것으로 알고 있지만 가장 많이 언급되는건 위에 나열한 정도지 않나 싶다.
3. 그래서?
SPA는 서버를 데이터 저장소 처럼 사용하는 느낌이 있다. 요 몇년 새 RESTFUL한 API 구현 방식이 소개가 되고 유행을 타면서 서버는 그냥 브라우저에 데이터를 제공하는 Database 같은 역할??? 각설하고 위에 언급한 장단점 외에 더 많은 장단점이 있을거고 항상 어떤 솔루션이나 방법론이 모든 경우에서 정답이 될 수 없다는것은 다들 경험을 통해 알고 있으리라 생각된다. 프로젝트에 SPA를 적용할 지 안할지는 상황에 맞게 요구사항에 맞게 결정해야 할 문제다. 지난 몇년간 프로젝트는 항상 긴급하게 요구사항도 결정나지 않은 채로 일단 시작하고 보는 식으로 진행이 됐었고 예상하겠지만 프로젝트가 끝날 때 까지 일단위 심지어는 시간단위로 요구사항이 변경되었다. 이런 환경에서 일을 진행시키기 위해 의도치는 않았지만 Backbone.Marionette를 사용하기로 결정했던 것은 정말 잘 한 일이었던 것 같다. (하지만 어딜 가든 Angularjs 할줄 아는 사람만 찾는 것은 함정. Backbone.Marionette는 정말 없다. 다른 프레임워크 다 마찬가지겠지만.) 이후 포스트는 Angularjs에 대해 공부한 것에 대해 포스트 할 거 같다. 덤으로 생각이 난다면 Marionette와 의 비교도 곁들여서...