프론트엔드 개발에서 상태라는 개념이 궁금해진 이유?
최근 『리액트 훅을 활용한 마이크로 상태 관리』라는 책을 읽기 시작하면서, 문득 이런 질문이 떠올랐다.
“프론트엔드 개발에서 말하는
상태란 도대체 뭘까?”
이 질문에 대한 답을 직접 찾아보고, 스스로 정리해보고 싶어서 이 글을 쓰게 되었다.
프론트엔드 개발을 공부하다 보면 자주 듣게 되는 단어인 상태. 하지만 막상 설명하려고 하면 막막한 개념이다.
사실 이 글을 쓰는 지금도, 누군가 “상태가 뭐예요?”라고 묻는다면 선뜻 한 문장으로 대답하긴 어렵다.
그래서 이 기회에 다음과 같은 질문에 대해 정리해보려고 한다.
- 프론트엔드 개발에서 말하는 상태란 무엇일까?
- 왜 상태가 필요한 걸까?
- 상태 관리는 어떤 문제를 해결하기 위해 등장한 걸까?
상태란 무엇인가?
프론트엔드 개발에서 ‘상태(state)’란?
간단히 말하면 UI(User Interface, 사용자 인터페이스)의 모습과 동작을 결정하는 데이터이다. 상태는 애플리케이션에서 일어나는 모든 동작과 변화를 기반으로 UI를 업데이트하고, 사용자의 상호작용에 따라 변한다. 상태를 잘 관리하는 것이 애플리케이션의 효율성과 사용자 경험을 크게 향상시킬 수 있다.
상태의 예시
상태가 무엇인지 좀 더 구체적으로 이해하기 위해 몇 가지 예시를 들어보려 한다:
-
사용자 입력 값: 예를 들어, 사용자가 로그인 폼에 입력한 아이디나 비밀번호와 같은 값은 상태에 해당한다. 이 값은 사용자가 수정할 수 있으며, 상태는 그에 맞게 변경된다.
-
API에서 가져온 데이터: 외부 서비스나 서버에서 받아온 데이터는 상태로 관리된다. 예를 들어, 사용자의 프로필 정보나 게시글 목록 등은 외부 API로부터 받아오는 데이터이다.
-
UI 상태: UI 요소의 상태 역시 중요한 상태이다. 예를 들어, 모달 창이 열렸는지 닫혔는지, 버튼이 활성화되었는지 비활성화되었는지와 같은 정보도 상태로 관리된다. 이 정보에 따라 UI가 어떻게 보일지가 결정된다.
상태의 종류
프론트엔드에서 상태는 여러 종류로 나눌 수 있다. 각 상태 유형은 관리되는 범위나 용도가 다르기 때문에, 상황에 맞게 적절히 활용하는 것이 중요하다.
- 로컬 상태, Local State
- 특정 UI 컴포넌트 내부에서만 관리되는 상태
- 예시
- 입력 폼의 값
- 버튼 클릭 여부
- etc
- 전역 상태, Global State
- 여러 컴포넌트에서 공유되는 상태
- 예시
- 사용자 로그인 상태
- 테마(다크 모드) 설정
- etc
- 파생 상태, Derived State
- 다른 상태 값을 기반으로 계산되는 상태
- 예시
- 여러 입력 값을 합산하여 계산된 총액
- 검색어로 필터링된 목록
- etc
- 원격 상태, Remote State
- 외부 API에서 받아온 데이터
- 예시
- 서버에서 받아온 사용자 정보
- 게시글 목록
- 서버에서 받아온 좋아요한 게시글 목록
- etc
상태가 필요한 이유가 뭘까?
복잡하지 않았던 시절의 웹
예전의 웹은 지금처럼 복잡하지 않았다. 예를 들어, 네이버 뉴스 기사나 게시판처럼 단순히 글을 보여주고 끝나는 페이지가 많았다. 대부분 서버가 새 페이지를 통째로 만들어 보내주는 방식(SSR, Server Side Rendering)이었고, 때로는 미리 만들어진 정적 HTML 파일을 보내기도 했다.
당시 웹의 인터랙션은 대부분 "링크 클릭 → 페이지 이동" 수준이었다. 페이지가 바뀌기 전까지 화면이 변하지 않았기 때문에, 클라이언트에서 UI를 바꾸거나 사용자의 행동을 기억해야 할 필요가 거의 없었다. 다시 말해, 상태(state)라는 개념은 거의 필요하지 않았다.
복잡해진 프론트엔드
1️⃣ 정적인 웹에서 동적인 웹으로
단순히 HTML을 보여주는 게 아니라, 사용자 행동에 따라 UI가 실시간으로 반응해야 하는 시대가 왔다. 상품을 장바구니에 담거나, 실시간 알림을 받거나, 자동완성 검색어가 뜨는 것처럼 말이다. 이런 UI의 변화는 사용자 행동을 기억하고 화면에 반영할 수 있어야 한다.
2️⃣ 사용자와의 인터랙션 증가
이제는 클릭, 입력, 드래그 등 사용자의 모든 행동을 추적하고 UI에 반영해야 한다. 사용자가 어떤 버튼을 눌렀는지, 어떤 글을 입력했는지 등을 화면에 즉각 반영하려면 이를 저장하고 관리하는 상태가 필요하다.
3️⃣ SPA(Single Page Application)의 등장
2000년대 중후반부터 Gmail, Google Maps처럼 페이지 새로고침 없이 동작하는 웹 앱이 등장했고, 이 흐름은 SPA라는 개념으로 정리됐다. SPA는 한 페이지에서 여러 화면을 전환하고, 그때그때 필요한 데이터를 보여주기 위해서 상태 관리의 중요성을 강조했다.
4️⃣ 비동기 처리의 필요성
API 요청 후 데이터를 받아오는 동안 로딩 스피너를 보여주고, 오류가 발생하면 에러 메시지를 보여주는 등의 과정은 모두 상태의 변화로 표현되어야 한다. "로딩 중", "성공", "실패" 등의 상태를 구분해 화면에 반영해야 한다.
5️⃣ 컴포넌트 기반 UI
React, Vue, Angular 등은 UI를 작은 컴포넌트 단위로 쪼갠다. 이런 구조에서는 컴포넌트 간의 데이터 전달과 공유가 복잡해지고, 일관된 상태 관리가 필요하다.
6️⃣ 애플리케이션의 복잡도 증가
현대 웹은 하나의 기능도 여러 컴포넌트가 협력해서 동작한다. 이때 상태가 제대로 관리되지 않으면, 어디서 문제가 생겼는지 찾기 어렵고 사용자 경험도 나빠진다.
그래서 상태라는 개념이 등장했다
현대의 웹은 사용자의 모든 행동에 빠르게 반응하고, 실시간으로 데이터를 반영하는 방향으로 진화하고 있다. 그 과정에서 우리는 "지금 UI가 어떤 상태인지"를 기억하고 관리할 필요성을 절감하게 됐다.
바로 그때 등장한 개념이 상태(state)다.
이제 상태는 단순히 값 몇 개를 저장하는 게 아니라, 전체 UI의 흐름을 결정하는 중요한 요소가 되었다.
- 사용자의 입력을 반영하고
- 서버 응답을 기다리며
- 컴포넌트 간 데이터를 공유하고
- 화면 전환의 기준이 되는 것
이런 모든 것들이 상태로부터 시작되고 끝나기 때문에, 프론트엔드 개발에서 상태는 핵심 개념이 되었다.
상태 관리를 한다는 건 어떤 의미일까?
현대 웹 애플리케이션은 단순히 정보를 보여주는 것을 넘어서, 사용자와의 다양한 상호작용을 처리해야 하는 복잡한 구조를 갖게 되었다. 이때 사용자의 행동에 따라 UI가 적절하게 반응하려면, 애플리케이션 내부에 있는 ‘상태(state)’를 잘 관리하는 것이 매우 중요하다.
그렇다면 ‘상태 관리를 한다’는 건 어떤 의미일까?
상태 관리를 한다는 건, 애플리케이션에서 지금 어떤 상황(데이터)을 갖고 있는지를 기억하고, 그에 따라 UI를 업데이트하는 것을 의미한다.
예를 들어, 로그인 여부, 장바구니에 담긴 상품 수, 서버에서 받아온 데이터 등이 모두 상태이며, 이 상태에 따라 버튼이 활성화되거나 화면에 표시되는 내용이 달라진다.
그리고 이 상태들이 많아지고 복잡해질수록, 우리는 ‘상태 관리’라는 개념을 통해 데이터를 일관되게, 예측 가능하게, 구조적으로 다뤄야 할 필요가 생긴다.
상태 관리가 필요해진 이유
1️⃣ 컴포넌트 간의 데이터 전달 문제
React나 Vue 같은 프레임워크는 컴포넌트 기반으로 UI를 만든다. 하지만 컴포넌트가 많아지면 데이터를 props로 일일이 전달하는 것이 번거로워진다. 특히 중첩이 깊어질수록 데이터가 부모 컴포넌트에서 자식 컴포넌트(위에서 아래)로 계속 전달되면서 prop drilling 문제가 생긴다.
2️⃣ 데이터 일관성 유지의 어려움
여러 컴포넌트가 동일한 데이터를 공유할 때, 한 곳에서 데이터가 바뀌었는데 다른 곳은 아직 이전 데이터를 보여주는 문제가 생길 수 있다. 이건 사용자 입장에선 혼란스러운 경험이 된다.
3️⃣ 예측 가능한 흐름이 필요함
기능이 많아질수록 ‘누가, 언제, 어떤 이유로 상태를 바꿨는지’ 추적하기 어려워진다. 디버깅이 어려워지고, 테스트도 까다로워진다. 상태가 어떤 흐름으로 바뀌는지를 명확하게 만드는 것이 중요해졌다.
4️⃣ 구조적인 접근의 필요
애플리케이션의 기능이 늘어나고 복잡도가 증가하면, 단순한 useState()훅 만으로는 상태를 관리하기 힘들어졌다. 전역 상태, 원격 상태 등 다양한 상태를 체계적으로 관리할 수 있는 구조가 필요해졌다.
상태 관리가 중요한 이유?
1️⃣ UI 일관성 유지
프론트엔드에서 UI는 상태에 따라 달라진다. 로그인 여부, 알림 유무, 버튼 활성화 등 모두 상태에 따라 조건부 렌더링 된다. 상태가 잘못되면 UI도 이상하게 보인다.
2️⃣ 확장성과 유지보수성
기능이 늘어날수록 상태도 복잡해지고 많아진다. 이때 중앙에서 상태를 관리하거나, 적절한 위치에 분리하여 관리하면 코드가 깔끔하고 유지보수가 쉬워진다.
3️⃣ 사용자 경험 향상
사용자가 무언가를 클릭 했는데 화면 반응이 없다면? 상태가 UI에 제대로 반영되지 않는다. 정확한 상태 관리로 실시간 반응과 빠른 피드백을 줄 수 있다.
상태 관리를 도와주는 라이브러리(React 기준)
애플리케이션의 상태가 많아지고 복잡해지면서, 상태를 예측 가능하고 일관되게 관리하기 위해 여러 상태 관리 라이브러리들이 등장했다. 다양한 상황에서 효율적인 상태 관리를 가능하게 해준다.
1️⃣ 지역 상태 관리를 위한 라이브러리
- React Hooks(useState, useReducer) React의 내장 훅으로 간단한 지역 상태를 관리한다. 단, 컴포넌트 간 데이터 공유가 어렵다.
- Context API React에서 제공하는 기본 전역/지역 상태 공유 도구이다. 주로 React의 useState(), useReducer() 훅과 결합하여 쓰인다. 작은 규모의 애플리케이션에 적합하지만, 리렌더링 문제로 인해 대규모 애플리케이션에서는 성능 저하가 발생할 수 있다.
2️⃣ 전역 상태 관리를 위한 라이브러리
- Redux 상태를 중앙에서 관리하고, 상태 변경 흐름을 명확하게 만들어준다. 액션과 리듀서를 통해 상태를 업데이트하며, DevTools 같은 강력한 도구를 함께 제공한다.
- MobX 반응형 프로그래밍 기반의 라이브러리로, 적은 코드로 상태 관리를 할 수 있게 해준다. 관찰 가능한 상태가 변경되면 자동으로 관련 UI가 반응한다.
- Zustand React Hook 기반의 간단하고 직관적인 상태 관리 라이브러리이다. 필요한 상태만 관리할 수 있어, 작은 프로젝트나 빠른 구현에 적합하다.
3️⃣ 서버 상태 관리를 위한 라이브러리
- TanStack Query 서버에서 데이터를 가져오고, 캐싱하고, 갱신하는 복잡한 로직을 간단하게 만들어준다. 로딩, 에러, 성공 상태를 자동으로 관리하며 사용자 경험을 향상시킨다.
- SWR Vercel에서 만든 React 용 데이터 패칭 라이블리이다. ‘stale-while-revalidate’ 전략을 기반으로, 빠르게 캐시된 데이터를 보여주고 백그라운드에서 최신 데이터를 가져온다. 간단한 사용법으로 빠르게 서버 상태를 다룰 수 있게 해준다.
- Redux Toolkit Query (RTK Query) Redux 기반의 서버 상태 관리 도구이다. Redux와 연동되며 API 호출 로직을 추상화 해준다.
프론트엔드에서 상태를 한 줄로 말하자면?
글을 쓰면서 ‘상태’라는 개념을 한 줄로 말하자면 아래와 같이 말할 것 같다.
상태란? 사용자 상호작용과 실시간 데이터 반영이 중요해진 현대 웹에서 등장한 개념으로, UI의 현재 모습과 동작을 결정하는 핵심 데이터이다.
참고 자료
