
서론
SPA에서 상태 관리를 이야기하면 React의 useState, Context, Zustand 같은 도구를 먼저 떠올리기 쉽습니다.
이러한 도구를 보다 정확히 이해하기 위해서는 왜 이러한 개념이 등장했는지, 도구를 사용하기 전에는 어떻게 구현해야 했는지 등을 알아야 한다고 생각합니다.
이를 위해 이번 글에서는 MPA와 SPA를 비교하고, 상태 관리의 책임이 어떻게 이동되었는지, 왜 SPA에서 클라이언트 상태 관리가 필요해졌는지 정리해보겠습니다.
단순한 요구사항
단순한 요구사항에서는 화면 전체가 새로 그려지는 방식도 크게 문제가 되지 않았습니다.
예를 들어, 게시글 목록처럼 페이지마다 보여줄 내용이 명확히 나뉘어 있는 화면을 생각해보겠습니다.
1페이지에는 1번부터 4번까지의 글이 있고, 2페이지에는 5번부터 8번까지의 글이 있는 단순한 구조입니다.

이런 경우 1페이지에서 2페이지로 이동할 때 화면 전체가 새로 그려져도 사용자는 이를 자연스럽게 받아들일 수 있습니다.
다음 페이지로 이동한다는 것은 새로운 화면을 다시 불러오는 일로 인식되었기 때문입니다.
물론 이 과정에서 잠깐의 깜빡임이 발생할 수는 있지만, 페이지마다 보여줄 내용이 명확히 나뉘어 있고 화면 전환의 목적도 분명하기 때문에 특별히 어색한 경험으로 느껴지지는 않았습니다.
MPA
단순한 요구사항을 수행하는 데에는 MPA(Multi-Page Application)가 적절합니다.
MPA란 여러 페이지로 구성된 애플리케이션을 의미합니다.
클라이언트가 화면에 맞는 URL로 요청하면, 서버에서 URL에 맞는 데이터를 구해 html을 만들어 응답하는 방식으로 동작합니다.
그러므로 구조가 단순하고, 흐름이 명확하다는 장점이 있습니다.

브라우저(클라이언트)가 위와 같이 게시글 목록을 요청합니다.
그러면 서버는 게시글 목록 조회 템플릿인 articles.html을 활용해, 동적 데이터만 갈아끼워 전달합니다.
브라우저는 전달받은 articles.html로 화면 전체를 변경해 사용자에게 보여줍니다.

게시글 상세 조회 또한 동일하게 동작합니다.
1번 게시글을 요청하면, 게시글 상세 조회 템플릿인 article-{number}.html을 활용해, 동적 데이터만 갈아끼워 전달합니다.
브라우저는 전달받은 articles-1.html로 화면을 변경해 사용자에게 보여줍니다.

2번 게시글을 요청하면 서버는 동일하게 템플릿을 사용해 article-2.html을 전달하고, 브라우저는 전달받은 html을 새롭게 보여줍니다.
MPA에서의 상태 관리
MPA에서 브라우저는 필요한 HTML 문서를 서버에 요청하고, 서버는 요청에 맞는 데이터를 채워 HTML을 만들어 내려줍니다.
브라우저는 서버가 내려준 HTML을 화면에 표시하고, 다른 페이지로 이동하면 다시 새로운 HTML을 요청합니다.
즉 MPA에서는 화면을 구성하는 주요 데이터 처리와 HTML 생성이 서버에서 이루어집니다.
이처럼 서버에서 HTML을 만들어 내려주는 방식을 SSR(Server-Side Rendering)이라고 합니다.
복잡한 요구사항
이전처럼 단순한 요구사항이 아니라, 무한 스크롤, 실시간 검색, 좋아요, 댓글 작성, 장바구니 추가 등등과 같이 복잡한 요구사항이 주어졌다고 가정하겠습니다.
이 경우 사용자는 작은 동작 하나를 할 때마다 페이지 전체가 다시 바뀌는 것보다, 필요한 부분만 빠르게 바뀌는 화면을 기대하게 됩니다.
MPA 적용 시
예를 들어, 무한 스크롤로 여러 이미지를 조회한다고 가정해봅시다.
한 페이지 당 이미지는 8장이 들어갑니다.

처음 요청은 아무 문제없이 동작합니다.

문제는 두 번째 페이지부터 발생합니다.
무한 스크롤이니, 기존 이미지 8장에 더해 2페이지에 해당하는 추가 이미지 8장을 붙여야 합니다.
하지만 브라우저가 그려야 하는 html은 서버가 필요한 부분을 완전히 채워서 전달하고, 브라우저는 단순히 갈아 끼워야 합니다.
그래서 다음과 같이 화면이 깜빡거리고, 버벅거립니다.

SPA
MPA에서 화면이 깜빡이는 이유는 페이지를 이동할 때마다 서버에서 완성된 HTML을 새로 받아오고, 브라우저가 화면 전체를 다시 로드하기 때문이었습니다.
그렇다면 매번 HTML 전체를 새로 받는 대신, 필요한 데이터만 받아서 브라우저에서 화면을 바꾸면 어떨까요?
이런 흐름에서 등장한 방식이 바로 SPA(Single-Page Appliation)입니다.
SPA 적용 시
그럼 위에서 언급한 복잡한 요구사항을 처리하기 위해 SPA를 사용해보겠습니다.

서버는 이제 데이터까지 완전히 준비된 html을 전달하지 않고, 데이터만 전달합니다.
그리고 브라우저가 서버에게 받은 데이터를 토대로 images.html의 일부 요소만 변경합니다.
이를 통해 html 전체를 갈아치우는 것이 아닌, 일부분만 변경하게 됩니다.

2페이지 또한 동일합니다.
서버에는 2페이지에 해당하는 이미지 8개를 전달받고, 마지막 이미지에 8개의 이미지를 이어 붙이는 식으로 동작합니다.

실제 동작시키면 위와 같이 동작합니다.
html 전체를 갈아치우지 않기 때문에 깜빡거리지 않고, 일부 요소만 변경하므로 버벅거리지 않습니다.
SPA에서의 상태 관리
SPA를 도입해 좀 더 빠르고 안정적인, 사용자 친화적인 화면을 제공할 수 있게 되었습니다.
서버에서 필요한 데이터를 가져와서 일부 요소만 변경하므로 속도가 빨라졌기 때문입니다.
하지만 이로 인해 서버에서 관리해주던 데이터를 브라우저가 관리해야 합니다.
대표적으로 관리해야 할 상태는 다음과 같습니다.
- URL 상태
- 서버 데이터 상태
- UI(컴포넌트) 상태
- 앱 전역 상태
이러한 상태는 각각의 성격에 따라 다르게 관리되어야 합니다.
어떤 값은 한 컴포넌트 안에서만 필요하고, 어떤 값은 URL과 맞춰져야 하며, 어떤 값은 여러 화면이 함께 바라봐야 합니다.
어떤 값은 바뀌는 즉시 화면에 반영되어야 하지만, 어떤 값은 화면 전체가 아니라 특정 영역만 다시 그려야 합니다.
그래서 SPA에서는 상태를 어디에 둘지, 상태가 바뀌었을 때 어느 화면까지 반영할지를 계속 판단해야 합니다.
MPA, SPA 상태 관리 비교
위에서 언급한, SPA에서 관리해야 하는 상태를 기준으로 비교한 표는 다음과 같습니다.
| 상태 종류 | MPA에서의 관리 방식 | SPA에서의 관리 방식 |
|---|---|---|
| URL 상태 | MPA에서는 URL이 각 화면을 가리키기 때문에, URL이 바뀌면 새로운 화면으로 전환됩니다. | 화면 전체를 다시 받지 않고 일부만 바꾸기 때문에, URL도 클라이언트가 현재 화면에 맞게 따로 맞춰줘야 합니다. |
| 서버 데이터 상태 | 브라우저가 원하는 화면을 요청하면, 그 화면에 필요한 데이터까지 서버가 함께 채워서 내려줍니다. | 브라우저가 화면은 유지한 채 필요한 데이터만 따로 요청하고, 받은 데이터를 직접 화면에 반영해야 합니다. |
| UI 상태 | 화면을 이동하면 이전 화면에서 열어둔 탭, 모달, 입력 상태는 자연스럽게 사라집니다. | 화면이 계속 살아 있으므로 탭, 모달, 입력값, 로딩 상태를 유지할지 초기화할지 직접 관리해야 합니다. |
| 앱 전역 상태 | 화면을 요청할 때마다 서버가 여러 화면에 필요한 공통 상태를 함께 채워서 내려줍니다. | 화면이 일부만 바뀌어도 헤더, 사이드바처럼 여러 영역이 같은 값을 함께 사용해야 하므로 브라우저가 공통 상태를 관리해야 합니다. |
MPA에서는 브라우저가 상황에 따라 필요한 화면을 서버에게 요청하고, 서버는 필요한 데이터를 가져와 html을 만들어줬습니다.
서버가 어떤 문맥에서 어떤 데이터를 사용해야 하는지 알고 있기 때문에 브라우저의 부담은 거의 없던 상황이었습니다.
SPA에서는 브라우저가 상황에 따라 필요한 데이터를 서버에게 요청하고, 서버는 요청에 맞는 데이터를 반환해줍니다.
서버는 브라우저가 어떤 문맥을 가졌는지는 신경쓰지 않고 요청받은 데이터를 전달할 뿐입니다.
브라우저가 현재 자신의 문맥에 따라 전달받은 데이터를 활용해야 하므로, MPA에 비해 브라우저의 부담이 커졌습니다.
마무리
이번 글에서 MPA와 SPA, 그리고 상태 관리에 대해 정리했습니다.
다음 글에서는
SPA에서는 상태를 어디에 둘지, 상태가 바뀌었을 때 어느 화면까지 반영할지를 계속 판단해야 합니다.
이 부분을 직접 체감해보기 위해, 바닐라 자바스크립트로 상태 관리를 하는 방법에 대해 정리하겠습니다.
'프론트엔드' 카테고리의 다른 글
| 바닐라 자바스크립트로 보는 클라이언트 상태 관리의 흐름과 한계 (0) | 2026.06.14 |
|---|