싱글 페이지 애플리케이션
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
싱글 페이지 애플리케이션(SPA)은 웹 애플리케이션의 한 형태로, 초기 로딩 시 단일 HTML 페이지를 로드한 후, 사용자 인터랙션에 따라 필요한 부분만 동적으로 업데이트하여 사용자 경험을 향상시킨다. 2003년 초부터 개념이 논의되었으며, Ajax, 웹 소켓, 서버 전송 이벤트 등 다양한 기술을 활용하여 서버와 통신한다. SPA는 자바스크립트 프레임워크(AngularJS, React, Vue.js 등)나 WebAssembly 기반 프레임워크를 사용하여 개발할 수 있으며, 씬 서버 아키텍처, Thick stateful/stateless server architecture 등 서버 아키텍처에 따라 구현 방식이 달라진다. 하지만, 검색 엔진 최적화(SEO), 브라우저 히스토리 관리, 초기 로딩 속도 지연, 보안 문제, 분석 도구 연동 등 해결해야 할 과제도 존재한다.
더 읽어볼만한 페이지
| 싱글 페이지 애플리케이션 | |
|---|---|
| 개요 | |
| 유형 | 웹 애플리케이션 |
| 상호 작용 방식 | 웹 페이지 동적 재작성 |
| 특징 | |
| 장점 | 빠른 응답 속도 향상된 사용자 경험 서버 부하 감소 |
| 단점 | 초기 로딩 시간 증가 검색 엔진 최적화(SEO) 어려움 JavaScript 의존성 보안 문제 |
| 기술 요소 | |
| 주요 기술 | Ajax JavaScript HTML5 CSS3 |
| 프레임워크 및 라이브러리 | AngularJS React Vue.js Svelte |
| 역사 | |
| 개발 배경 | 웹 기술 발전 및 사용자 경험 향상 요구 |
| 초기 기술 | DHTML |
| 접근 방식 | |
| 라우팅 | 클라이언트 측 라우팅 해시 기반 라우팅 |
| 상태 관리 | 클라이언트 측 상태 관리 |
| 고려 사항 | |
| 성능 최적화 | 코드 분할 지연 로딩 캐싱 |
| SEO 최적화 | 서버 측 렌더링 (SSR) 프리렌더링 |
| 접근성 | 웹 접근성 준수 |
| 예시 | |
| 예시 애플리케이션 | Gmail Google 지도 |
| 기타 | |
| 같이 보기 | 리치 인터넷 애플리케이션(RIA) |
2. 역사
싱글 페이지 애플리케이션(SPA)이라는 용어의 기원은 명확하지 않으나, 이 개념은 적어도 2003년 초에 논의되었다.[33] 2002년 4월 스튜어트 모리스는 slashdotslash.com에서 자체 포함 웹사이트를 작성하였으며,[34] 같은 해에 루카스 비르도, 케빈 하크만, 마이클 피치, 에반 예가 미국 특허 8,136,109에 SPA 구현을 설명했다.[35] 초기에는 리치 웹 애플리케이션이라고 불리기도 했다.
SPA는 브라우저가 서버와 통신하면서도 단일 페이지를 유지할 수 있게 해주는 다양한 기술을 활용한다.
3. 기술적 접근
HTML 작성자는 HTML 문서의 서로 다른 섹션을 표시하거나 숨기기 위해 요소 ID를 활용할 수 있다. CSS를 사용하면, `:target` 가상 클래스 선택자를 통해 브라우저가 탐색한 페이지의 섹션만 표시하도록 할 수 있다.
페이지 전환 없이 서버와 통신하는 기술에는 다음과 같은 것들이 있다.
데이터 전송 방식은 서버가 원시 데이터(XML 또는 JSON)나 새로운 HTML을 반환하는 두 가지 방식이 있다.[1] 서버에서 HTML이 반환되는 경우, 클라이언트의 JavaScript는 DOM의 일부 영역을 업데이트한다.[1] 원시 데이터가 반환될 때는 클라이언트 측 JavaScript를 사용하여 XML/XSL(JSON의 경우 템플릿) 처리 후 원시 데이터를 HTML로 변환한 다음, DOM의 일부 영역을 업데이트한다.[1]
SPA는 서버 아키텍처에 따라 다음과 같이 나눌 수 있다.3. 1. 자바스크립트 프레임워크
AngularJS, Ember.js, ExtJS, Knockout.js, Meteor.js, React, Vue.js, Svelte와 같은 여러 자바스크립트 프레임워크 및 라이브러리들이 SPA 개발을 지원한다. 이러한 프레임워크들은 SPA의 원칙을 따르며, 개발자가 SPA를 효율적으로 만들 수 있도록 다양한 기능을 제공한다. 각 프레임워크는 모델-뷰-컨트롤러(MVC) 또는 모델-뷰-뷰모델(MVVM)과 같은 아키텍처 패턴을 기반으로 하며, 양방향 데이터 바인딩, 템플릿, 라우팅 등의 기능을 제공한다. ExtJS를 제외하고는 모두 무료이다.3. 2. WebAssembly 기반 프레임워크
다음 프레임워크는 WebAssembly를 활용하거나 WebAssembly를 핵심 기술 또는 지원 메커니즘으로 사용하여 싱글 페이지 애플리케이션(SPA)을 구축할 수 있다. 이러한 프레임워크는 고성능의 대화형 클라이언트 측 개발을 가능하게 하여 SPA 패러다임을 여러 언어와 생태계로 확장한다.3. 3. Ajax
Ajax는 자바스크립트의 XMLHttpRequest 또는 더 현대적인 `fetch()` (2017년 이후)를 사용하여 서버에 XML 또는 JSON 데이터를 비동기적으로 요청하는 기술이다.[1] Ajax를 사용하면 웹사이트는 자바스크립트 또는 jQuery와 같은 자바스크립트 라이브러리를 직접 사용하여 DOM을 조작하고 HTML 요소를 편집한다. Ajax는 과거에 브라우저마다 다른 동작을 보였던 Ajax 동작을 단순화된 구문으로 제공하고 정규화하는 jQuery와 같은 라이브러리에 의해 더욱 대중화되었다.
3. 4. 웹 소켓
웹 소켓은 HTML 명세의 일부인 양방향 실시간 클라이언트-서버 통신 기술이다. 실시간 통신의 경우 성능[9]과 단순성 측면에서 Ajax보다 우수하다.
3. 5. 서버 전송 이벤트 (SSE)
서버 전송 이벤트(SSE)는 서버가 브라우저 클라이언트로 데이터 전송을 시작할 수 있는 기술이다. 초기 연결이 설정되면 클라이언트가 닫을 때까지 이벤트 스트림이 열린 상태로 유지된다. SSE는 기존 HTTP를 통해 전송되며 자동 재연결, 이벤트 ID, 임의의 이벤트를 전송하는 기능 등 웹 소켓이 설계상 갖추지 못한 다양한 기능을 제공한다.[10]
3. 6. 브라우저 플러그인 (현재는 구식)
과거에는 실버라이트, 플래시, 자바 애플릿과 같은 브라우저 플러그인 기술을 사용하여 서버에 비동기 호출을 수행하기도 했다. 이러한 방식은 현재 구식으로 간주된다.
3. 7. 데이터 전송
서버에 대한 요청은 일반적으로 원시 데이터(XML 또는 JSON)나 새로운 HTML을 반환한다.[1] 서버에서 HTML이 반환되는 경우, 클라이언트의 JavaScript는 DOM의 일부 영역을 업데이트한다.[1] 원시 데이터가 반환될 때는 종종 클라이언트 측 JavaScript를 사용하여 XML / XSL(JSON의 경우 템플릿) 처리 후 원시 데이터를 HTML로 변환한 다음, DOM의 일부 영역을 업데이트한다.[1]
3. 8. 서버 아키텍처
SPA는 서버 아키텍처에 따라 씬 서버 아키텍처(Thin server architecture)와 씩 스테이트풀/스테이트리스 서버 아키텍처(Thick stateful/stateless server architecture)로 나눌 수 있다.
씬 서버 아키텍처(Thin server architecture)는 로직을 클라이언트 측에 두고 서버는 순수한 데이터 API 또는 웹 서비스 역할을 수행한다. 복잡성이 서버에서 클라이언트로 이동했다는 점에서 씬 서버 아키텍처라고 불리기도 하지만, 시스템 전체의 복잡성이 감소했는지는 논란이 있다.
씩 스테이트풀 서버 아키텍처(Thick stateful server architecture)는 서버가 클라이언트 상태를 메모리에 유지하며, 요청에 따라 HTML 및 JavaScript를 보내 클라이언트를 업데이트한다. 대부분의 로직과 HTML은 서버에서 실행 및 렌더링된다. 이 방법은 서버 메모리와 처리 능력을 더 필요로 하지만, 애플리케이션이 보통 서버에서 완전히 코딩되고, 서버의 데이터와 UI 상태가 사용자 지정 클라이언트/서버 통신 브리지 없이 동일한 메모리 공간에서 공유되므로 개발 모델이 단순화되는 장점이 있다.
씩 스테이트리스 서버 아키텍처(Thick stateless server architecture)는 클라이언트가 상태를 서버로 전송하고, 서버는 이를 기반으로 필요한 데이터나 코드를 생성하여 클라이언트에 반환한다. 이 방식은 더 많은 데이터를 서버로 전송해야 하며, 서버에서 클라이언트 페이지 상태를 부분적으로 또는 완전히 재구성하기 위해 요청당 더 많은 계산 리소스가 필요할 수 있다. 하지만 서버에 클라이언트별 페이지 데이터가 보관되지 않으므로 더 쉽게 확장할 수 있다. 따라서 Ajax 요청은 세션 데이터 공유 또는 서버 선호도 없이 서로 다른 서버 노드로 분산될 수 있다.
4. 로컬 실행
일부 싱글 페이지 애플리케이션은 파일 URI 방식을 사용하여 로컬 파일에서 실행될 수 있다. 이를 통해 사용자는 서버에 접속하지 않고도 SPA를 서버에서 다운로드하여 로컬 저장 장치에서 파일을 실행할 수 있다. 이러한 SPA가 데이터를 저장하고 업데이트하려는 경우, 브라우저 기반의 웹 스토리지를 사용해야 한다.[11] HTML에서 제공되는 발전을 통해 이점을 얻는다.[11]
5. SPA 모델의 과제
SPA는 브라우저가 원래 설계된 무상태 페이지 다시 그리기 모델에서 진화했기 때문에 몇 가지 새로운 과제가 발생했다.[12] 이러한 과제는 다음을 통해 대처할 수 있다.
5. 1. 검색 엔진 최적화 (SEO)
웹 검색 엔진의 크롤러에서 자바스크립트 실행이 일부 지원되지 않아, 검색 엔진 최적화(SEO)는 싱글 페이지 애플리케이션(SPA) 모델을 사용하는 웹사이트에 역사적으로 문제를 안겨주었다.[17][18]2009년부터 2015년까지 구글 웹마스터 중앙은 AJAX 페이지에 프래그먼트 식별자에서 느낌표를 사용하는 "AJAX 크롤링 방식"(#![19][20])을 제안했다. 이는 검색 엔진 크롤러가 관련 메타데이터를 추출할 수 있도록 SPA 사이트에서 특수 동작을 구현해야 하는 방식이었다. 그러나 이 방식은 여러 문제점이 지적되었고,[21] 2015년에 구글은 이 제안을 폐지했다.[22]
현재는 서버에서 첫 페이지 로드를 렌더링하고 클라이언트에서 후속 페이지 업데이트를 렌더링하는 방식을 사용할 수 있다. 또는 서버 측 렌더링, 정적 렌더링, 하이드레이션과 같은 방법을 통해 SEO 문제를 해결할 수 있다.[24]
SEO 호환성은 SPA에서 간단하지 않기 때문에, 검색 엔진 색인이 요구되거나 바람직한 상황에서는 일반적으로 SPA가 사용되지 않는다. 사용 사례로는 인증 시스템 뒤에 숨겨진 개인 데이터를 노출하는 애플리케이션이 있다.
5. 2. 브라우저 히스토리
단일 페이지 애플리케이션(SPA)은 "단일 페이지"이기 때문에 브라우저의 "뒤로" 및 "앞으로" 버튼을 사용한 페이지 기록 탐색 기능과 충돌한다. 사용자가 SPA 내에서 이전 화면 상태를 보기 위해 뒤로 가기 버튼을 눌렀을 때, 애플리케이션의 단일 페이지가 언로드되고 브라우저 기록의 이전 페이지가 표시되어 사용성에 문제가 생긴다.이러한 문제를 해결하기 위한 전통적인 방법은 브라우저 URL의 해시 프래그먼트 식별자를 현재 화면 상태에 따라 변경하는 것이었다. 이는 자바스크립트를 사용하여 구현할 수 있으며, 브라우저 내에서 URL 기록 이벤트를 생성한다. SPA가 URL 해시에 포함된 정보로부터 동일한 화면 상태를 복원할 수 있다면, 예상되는 뒤로 가기 버튼 동작이 유지된다.
HTML 사양은 이 문제를 더욱 해결하기 위해 실제 URL 및 브라우저 기록에 대한 프로그래밍 방식 접근을 제공하는 [http://www.w3.org/html/wg/drafts/html/master/browsers.html#dom-history-pushstate pushState]와 [http://www.w3.org/html/wg/drafts/html/master/browsers.html#dom-history-replacestate replaceState]를 도입했다.
5. 3. 분석 (Analytics)
구글 애널리틱스와 같은 분석 도구는 브라우저에서 새로운 페이지가 로드될 때 작동하는 방식에 크게 의존하지만, SPA는 페이지 로드 없이 콘텐츠가 변경되므로 이 방식이 적합하지 않다.[26]SPA에서는 첫 페이지 로드 후 모든 콘텐츠 변경이 애플리케이션 내부에서 처리되기 때문에, 분석 패키지를 업데이트하는 함수를 명시적으로 호출해야 한다. 이 함수를 호출하지 않으면 브라우저는 새로운 페이지 로드를 인식하지 못하고, 분석 도구는 사용자의 활동을 추적할 수 없다.[26]
HTML History API를 사용하면 SPA에 페이지 로드 이벤트를 추가하여 분석 도구와 통합할 수 있다. 하지만 이벤트를 정확하게 관리하고 누락이나 중복 없이 보고되도록 하는 것은 어려운 작업이다.[26]
일부 프레임워크는 주요 분석 제공 업체를 위한 무료 분석 통합 기능을 제공한다. 개발자는 이를 활용하여 애플리케이션에 분석 기능을 쉽게 통합할 수 있지만, 모든 것이 올바르게 작동하는지 확인해야 한다.[26]
5. 4. 보안
싱글 페이지 애플리케이션은 크로스-사이트 스크립팅(XSS)과 같은 전통적인 웹 페이지와 동일한 보안 위험에 노출될 뿐만 아니라, API를 통한 데이터 노출, 클라이언트 측 로직, 서버 측 보안의 클라이언트 측 시행 등과 같은 고유한 취약점도 가지고 있다.[27] 싱글 페이지 애플리케이션을 효과적으로 스캔하기 위해서는, DAST 도구 스캐너가 애플리케이션의 모든 영역을 검색하고, 애플리케이션이 원격 서버(예: API 요청)로 전송하는 모든 요청을 가로챌 수 있도록 신뢰할 수 있고 반복 가능한 방식으로 클라이언트 측 애플리케이션을 탐색할 수 있어야 한다.5. 5. 초기 로딩 속도 지연
싱글 페이지 애플리케이션(SPA)은 뷰를 렌더링하기 전에 프레임워크와 애플리케이션 코드를 로드해야 하기 때문에 서버 기반 애플리케이션보다 첫 페이지 로딩이 느려지는 경향이 있다. 서버 기반 애플리케이션의 경우 필요한 HTML만 가져오면 되므로 통신 시간이 짧다.[26]캐싱이나 지연 로드 모듈 등 SPA의 첫 로딩을 가속화하는 방법이 있다. 그러나 여전히 프레임워크와 애플리케이션 코드의 적어도 일부를 다운로드해야 하며, 많은 경우 브라우저에 무언가를 표시하기 위해 API를 통해 데이터를 가져와야 한다는 사실은 변하지 않는다. 이 성능과 대기 시간 문제는 "지금 지불할 것인가, 나중에 지불할 것인가"라는 트레이드 오프이며, 개발자가 결정해야 하는 것이다.[26]
6. 페이지 수명 주기
SPA는 초기 페이지 로드 시 완전히 로드되며, 요청 시 서버에서 로드된 새 페이지 조각으로 페이지 영역이 교체되거나 업데이트된다. 사용하지 않는 기능의 과도한 다운로드를 방지하기 위해 SPA는 종종 필요에 따라 페이지의 작은 조각이나 전체 화면 모듈과 같이 더 많은 기능을 점진적으로 다운로드한다.
이러한 방식으로 SPA의 "상태"와 기존 웹사이트의 "페이지" 사이에 유사성이 존재한다. 동일한 페이지 내의 "상태 탐색"이 페이지 탐색과 유사하기 때문에 이론적으로 모든 페이지 기반 웹사이트를 동일한 페이지에서 변경된 부분만 교체하는 단일 페이지로 변환할 수 있다.
웹의 SPA 방식은 단일 문서 인터페이스(SDI) 프레젠테이션 기술과 유사하며, 이는 네이티브 데스크톱 애플리케이션에서 널리 사용된다.
참조
[1]
서적
JavaScript - The Definitive Guide
https://books.google[...]
O'Reilly, Sebastopol, CA
2006
[2]
웹사이트
Inner-Browsing: Extending Web Browsing the Navigation Paradigm
http://devedge.netsc[...]
2003-05-16
[3]
웹사이트
Slashdotslash.com: A self contained website using DHTML
http://www.slashdots[...]
2012-07-06
[4]
웹사이트
US patent 8,136,109
https://patents.goog[...]
2002-04-12
[5]
웹사이트
Meteor Blaze
https://github.com/m[...]
2022-05-06
[6]
블로그
Introducing DDP
http://meteor.com/bl[...]
2012-03-21
[7]
웹사이트
Server Side Rendering for Meteor
https://meteorhacks.[...]
2015-01-31
[8]
뉴스
Single-page applications vs. multiple-page applications: pros, cons, pitfalls - BLAKIT - IT Solutions
https://blak-it.com/[...]
BLAKIT - IT Solutions
2017-10-17
[9]
웹사이트
Real-Time Monitoring using AJAX and WebSockets
http://www.computer.[...]
2016-06-01
[10]
웹사이트
Server-Sent Events
http://www.w3.org/TR[...]
W3C
2013-07-17
[11]
웹사이트
Unhosted web apps
https://unhosted.org[...]
[12]
웹사이트
The Single Page Interface Manifesto
http://itsnat.source[...]
2014-04-25
[13]
웹사이트
Derby
http://derbyjs.com/
2011-12-11
[14]
웹사이트
Sails.js
https://github.com/b[...]
2013-02-20
[15]
웹사이트
Tutorial: Single Page Interface Web Site With ItsNat
http://itsnat.source[...]
2011-01-13
[16]
문서
HTML5
[17]
웹사이트
What the user sees, what the crawler sees
https://developers.g[...]
2014-01-06
[18]
웹사이트
Making Ajax Applications Crawlable
https://developers.g[...]
2014-01-06
[19]
웹사이트
Proposal for making AJAX crawlable
http://googlewebmast[...]
Google
2011-07-13
[20]
웹사이트
(Specifications) Making AJAX Applications Crawlable
https://developers.g[...]
Google Inc.
2013-03-04
[21]
웹사이트
Hash URIs
http://www.w3.org/QA[...]
2011-07-13
[22]
뉴스
Deprecating our AJAX crawling scheme
https://webmasters.g[...]
2017-02-23
[23]
웹사이트
Implement dynamic rendering
https://developers.g[...]
2021-01-07
[24]
웹사이트
Dynamic rendering as a workaround
https://developers.g[...]
2024-07-02
[25]
웹사이트
Fix a single-page app for Google Search
https://codelabs.dev[...]
2021-12-15
[26]
서적
Getting MEAN with Mongo, Express, Angular, and Node
Manning Publications
2015
[27]
웹사이트
Single Page Applications (SPA)
https://appcheck-ng.[...]
[28]
서적
JavaScript - The Definitive Guide
O'Reilly, Sebastopol, CA
2006
[29]
웹사이트
AJAX クロールに関するスキームを廃止します
https://webmaster-ja[...]
2017-06-10
[30]
서적
Getting MEAN with Mongo, Express, Angular, and Node
Manning Publications
2015
[31]
서적
JavaScript - The Definitive Guide
O'Reilly, Sebastopol, CA
2006
[32]
웹인용
Fixing the Back Button: SPA Behavior using Location Hash
http://blog.falafel.[...]
2016-01-18
[33]
웹인용
Inner-Browsing: Extending Web Browsing the Navigation Paradigm
https://developer.mo[...]
2011-02-03
[34]
웹인용
Slashdotslash.com: A self contained website using DHTML
http://stu-rl.eu/sla[...]
2012-07-06
[35]
웹인용
US patent 8,136,109
https://www.google.c[...]
2002-04-12
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com