커지는 프로젝트, 유지보수가 버거워진다면 전역 상태를 의심하자
전역 상태 관리는 React 같은 컴포넌트 기반 UI 라이브러리에서 prop drilling을 해결하는 매우 편리한 도구입니다. 하지만 프로젝트 규모가 커질수록 유지보수가 기하급수적으로 어려워지는 현상을 겪곤 하는데, 그 주요 원인 중 하나가 바로 무분별한 전역 상태 남용입니다.
특히 단방향 데이터 흐름의 원칙이 무너지면 컴포넌트 간의 의존성이 거미줄처럼 얽혀 코드 수정과 디버깅이 매우 까다로워집니다.
단방향 데이터 흐름이 유지보수의 핵심인 이유
React의 기본 철학은 단방향 데이터 흐름(Unidirectional Data Flow) 입니다. 데이터는 부모에서 자식으로 흐르고, 이벤트는 역방향으로 전달됩니다.
이 규칙이 지켜질 때 컴포넌트는 다음과 같은 이점을 갖습니다:
- 독립성 유지: 부모가 내려주는 props와 내부 상태만으로 동작하므로 컴포넌트의 재사용성과 테스트가 쉬워집니다.
- 예측 가능성: 데이터 변경의 원인과 결과(어디서 바뀌어 어디로 전달되는지)를 쉽게 추적할 수 있습니다.
하지만 전역 상태를 무분별하게 도입하면 이 단방향 흐름이 깨집니다. 어느 컴포넌트에서든 전역 상태를 직접 읽고 수정할 수 있게 되면서, 겉으로는 분리되어 보이는 수십 개의 컴포넌트가 실질적으로는 하나의 거대한 결합체처럼 묶여버립니다.
전역 상태 남용이 부르는 대표적인 문제들
- 데이터 흐름의 예측 불가능성: 한 화면의 상태를 변경했는데 전혀 상관없어 보이는 다른 화면이나 컴포넌트에서 사이드 이펙트가 발생합니다. 어디서 상태를 바꿨는지 추적하기 어려워 디버깅 시간이 급증합니다.
- 컴포넌트 간 결합도 증가: 전역 저장소의 특정 구조에 컴포넌트들이 강하게 결합되어, 독립적인 리팩토링이나 컴포넌트 재사용이 불가능해집니다.
- 신규 입사자의 온보딩 장벽: 전역 상태 안에 복잡한 도메인 비즈니스 로직까지 섞여 들어가면, 새 개발자가 시스템의 데이터 흐름을 파악하는 데 오랜 시간이 걸립니다.
전역 상태를 건강하게 다루는 원칙
- 비즈니스 로직과 UI 상태 분리: 전역 상태 저장소는 가능한 한 순수한 데이터 전달 통로로만 유지하고, 복잡한 비즈니스 계산이나 가공 로직은 커스텀 훅이나 도메인 함수로 분리합니다.
- 상태의 지역화(Local State First): 상태는 그것을 필요로 하는 가장 가까운 공통 부모 컴포넌트에 두는 것을 기본 원칙으로 삼습니다. 정말로 앱 전역에서 공유되어야 하는 데이터(인증 세션, 테마 등)만 전역 상태로 올립니다.
- 서버 상태와 클라이언트 상태 분리: React Query(TanStack Query), SWR 같은 서버 상태 관리 라이브러리를 적극 활용하여 캐싱, 동기화, 로딩 상태를 서버 데이터 계층에서 해결하고 클라이언트 전역 상태를 최소화합니다.
핵심 요약
전역 상태 라이브러리는 편리하지만 강력한 마법인 만큼 의존성을 높이는 독이 될 수도 있습니다.
단방향 데이터 흐름과 컴포넌트의 독립성을 최대한 지키면서, 꼭 필요한 곳에만 전역 상태를 절제하여 사용하는 것이 장기적으로 건강하고 유지보수하기 쉬운 코드베이스를 만드는 지름길입니다.