Single-page application vs. multiple-page application

이 포스트는 Single-page application vs. multiple-page application 를 한글로 번역한 글입니다.

Single-page application vs. multiple-page application

웹 어플리케이션이 이전 데스크탑 응용 프로그램을 대체하고 있다. 사용하기 좀 더 편리하고, 업데이트가 쉬우며, 단 한가지 기기에만 종속되지 않는다. 또한 사용자가 브라우저 기반 웹앱에서 모바일로 이미 자연스럽게 이동하고 있음에도 불구하고, 복잡하고 세련된 응용 프로그램에 대한 요구는 이미 커지고 있으며 계속 증가하고 있다. 만약 당신이 본인의 앱을 만든다는 생각을 가지고 있다면, 아마 웹앱을 위한 두가지 주요 디자인 패턴 : multi-page application (MPA) 와 single-page application (SPA) 에 대해 들어봤을것이다. 물론, 이 두가지 모델은 각각 장단점이 있다.

실제 앱에 아이디어를 적용하기 전에, 몇가지 중요한 질문에 답해야한다. 어떤 앱 모델이 더 나은지 결정 하려면 콘텐츠 우선 접근 방식(content-first approach)을 따라야한다. 이 방식은 콘텐츠를 다른 모든 것보다 우선적으로 생각하는것인데, 콘텐츠에 따라 사용자가 이용할지 안 할지를 결정하기 때문이다. 그리고 이것은 가장 중요한 질문을 제시한다 : 어떤 콘텐츠를 제공할 것인가? 어떤 콘텐츠가 가장 사용자들의 관심을 끌 것인가?

SPA 와 MPA 모두 많은 장단점들이 있다. 아래의 내용들로 이 두가지 디자인 패턴의 차이를 명확히 알고 어떤 앱이 당신의 아이디어에 더 맞을지 알게 되길 바란다. 그리고 실제 그 앱에 대한 아이디어를 실현해 보라.

Single-Page Application

단일 페이지 어플리케이션은 브라우저 내부에서 동작하는 앱이고 사용하는 동안 페이지 리로딩이 필요없다. 당신은 이런 종류의 앱을 매일 사용하고 있다. 예를 들어 G메일, 구글 맵스, 페이스북, 깃헙 등이 있다. SPA는 브라우저의 "자연스러운" 환경-페이지 리로딩과 별도의 대기 시간 없음-을 모방하기 위해 노력함으로써 뛰어난 UX를 제공한다. 당신이 방문한 곳은 Javascript를 사용하여 (의존성이 강한) 다른 모든 콘텐츠를 로드한 단지 하나의 웹 페이지이다.

SPA는 마크업과 데이터를 독립적으로 요청하고 브라우저에서 페이지를 바로 렌더링한다. AngularJS, Ember.js, Meteor.js, Knockout.js와 같은 진보된 JavaScript 프레임 워크 덕분에 이 작업을 수행할 수 있다. 단일 페이지 사이트는 컨텐츠가 사용자에게 간편하고 동작할 수 있는 상태로 제공되는 하나의 편리한 웹공간에 머물 수 있게 도와준다.

Single-Page Application 의 장점 :

• SPA는 대부분의 리소스(HTML+CSS+Scripts)가 앱의 생명주기 동안 딱 한 번만 로드되기 때문에 빠르다. 오직 데이터만 앞뒤로 전달된다.

• 개발이 간단하고 능률적이다. 페이지를 렌더링 하기 위해 서버에 코딩할 필요가 없다. 대게 서버의 이용없이 파일로 부터(file://URI) 개발을 시작할 수 있기 때문에 시작하기가 훨씬 쉽다.

• 크롬에서 디버그가 쉽다. 네트워크 작업을 모니터링하고 페이지 요소 및 이와 관련된 데이터를 조사 할 수 있기 때문.

• 개발자는 웹과 네이티브 모바일 앱의 동일한 벡엔드 코드를 재사용할 수 있기 때문에 모바일 웹을 만들기 더 쉽다.

• SPA는 어떤 로컬 저장소라도 효율적으로 캐시할 수 있다. 애플리케이션은 단 하나의 요청을 날리고, 모든 데이터를 저장하고, 이 데이터를 사용할 수 있으며 심지어 오프라인 상태일때도 동작한다. 

Single-Page Application 의 단점 :

• SPA에서 SEO(검색 엔진 최적화) 적용은 어렵고 까다로운 일이다. 콘텐츠는 AJAX (Asynchronous JavaScript and XML : 새로고침 없이 데이터 교환과 업데이트 해주는 방식)로 로드된다. 
  UPDATE 27.09.2017 : 이 댓글에서, Iris Shaffer가 서버 사이드에서 처리할 수 있다고 정확하게 짚어주었다. 실제로 이전보다 쉬워졌다.

• 클라이언트의 로드를 위해 무거운 프레임워크가 필요해지면서 다운로드가 느리다.

• Javascript를 사용할 수 있어야 한다. 만약 사용자가 자바스크립트를 브라우저에서 사용할 수 없도록 해두었다면, 어플리케이션이 제공될 수 없고 정확한 방식으로 동작하지 않을 수 있다. 
  UPDATE 27.09.2017: 이 댓글에서, Iris Shaffer는 isomorphic 렌더링 / 서버 사이드 렌더링을 사용하면 이미 서버에서 페이지를 렌더링 할 수 있다는 것을 알려주었다. 최초 렌더링이 서버에서 되고 캐시될 수 있을때, JS가 꺼져있어도 페이지를 불러오는데 문제 없다는 것이다. 이론적으로, 맞는 이야기다. 명백하게 서버 사이드에서 렌더링할 수 있다. 하지만 JS가 없다면 다른 기능들에 문제가 생길 수 있다. HTML & CSS로 많은 것을 할 수 있지만 경험상 자바스크립트 대신 이 방식을 사용하는 것은 좋지 않을 것이다.

• "고전적인" 웹과 비교해봤을때, SPA는 보안에 취약하다. Cross-Site Scripting(XSS)를 통해, 다른 사용자들로 하여금 공격자가 클라이언트측 스크립트를 주입할 수 있기 때문이다.

• 자바스크립트의 메모리 누수가 시스템을 느리게 만들 수 있다.

• 이 모델에서, 뒤로 가기와 앞으로 가기 버튼의 기능이 오작동 될 수 있다.
  UPDATE 27.09.2017: 현재 이것은 더이상 이슈가 아니다.

Multi-Page Application

MPA는 "고전적인" 방식으로 동작한다. 모든 변경사항, 예를 들어 데이터를 보여주거나 서버로 데이터를 제출하는 요청은 브라우저에서 서버로 부터 새로운 페이지를 렌더링 한다. 이런 어플리케이션들은 콘텐츠의 양과 많은 UI 계층 때문에 SPA보다 거대하다. 다행스럽게도, 더 이상 이것은 문제되지 않는다. AJAX 덕분에, 크고 복잡한 어플리케이션들이 서버와 브라우저 사이의 많은 데이터 전달을 걱정하지 않아도 된다. 이 해결책은 페이지의 특정 부분만 바꿀 수 있도록 발전했다. 반면 이것은 SPA보다 개발하기 더 복잡하고 어렵게 만들었다. 

Multiple-Page Application 의 장점 :

• 애플리케이션에서 어디로 갈지에 대한 시각적 인지도가 필요한 사용자에게 완벽한 접근 방식이다. 뚜렷하고 얕은 메뉴 탐색은 전통적인 방식의 MPA에 필수적인 부분이다.

• 쉽고 정확한 검색 최적화를 제공한다. 페이지당 하나의 키워드가 적용되기 때문에 다른 키워드들과의 순위을 매기는데 더 나은 기회를 제공한다. 

Multiple-page application 의 단점 :

• 프론트와 백엔드가 밀접하게 결합된다.

• 개발이 꽤 복잡해진다. 개발자는 클라이언트와 서버사이드에서 각각의 프레임워크를 사용해야한다. 이것은 개발과정을 길어지게 하는 결과를 낳는다.

SPA or MPA?

개발하기 전에, 목적을 고려해볼 필요가 있다. 다양한 카테고리가 필요하다면 (예로 온라인 쇼핑몰이나 다른 많은 콘텐츠를 제공하는것) MPA를 사용하라. 당신의 사이트가 단일 페이지 환경에 맞다고 확신한다면 그렇게 하라. 그리고 SPA를 만들고 싶지만 간신히 모든 정보를 한곳에 담을 수 있다면, 대신 하이브리드 사이트를 고려해보라. 이것은 여기서 언급되지 않은 또 다른 방식이다. 하이브리드 앱은 두가지 방식의 장점만 취하고 단점은 최소화 한것이다. 이것은 사실, URL 앵커를 조합해 브라우저 탐색 및 환경 설정 기능을 보다 많이 구현한 SPA이다.

많은 장점들로 인해, 앞으로 많은 사람들이 SPA를 사용하게 될것이다(하이브리드 앱 포함). 시장에 나와있는 많은 앱들이 이 모델로 이전하고 있다. 하지만, 일부 프로그램은 SPA에 적합하지 않기 때문에, MPA 모델은 여전히 활발하게 사용될 것이다. 

________

Originally published by Paweł Skólski at neoteric.eu/blog on December 1st, 2016.