가장 많이 언급되는 조언 앱 상태 관리(app state management) 가장 비효율적인 방법이기도 합니다. 하나의 글로벌 스토어만 정해서 모든 것을 다 집어넣는 방식이죠. 이 방식은 API 응답, 모달 가시성, 저장되지 않은 폼 입력값, 인증, 내비게이션 필터가 모두 동일한 라이프사이클을 가진 것처럼 취급합니다. 하지만 실제로는 그렇지 않습니다. Capacitor 또는 Electron 애플리케이션은 웹 레이어와 네이티브 또는 데스크톱 런타임 위에서 동작하므로, 상태를 다음과 같이 구분해야 합니다. 데이터의 출처, 유지 시간, 소유권, 그리고 네트워크나 프로세스가 종료될 때의 동작 방식에 따라.
모바일 런타임은 변동성이 크기 때문에 상태 관리가 필수적입니다. 앱은 화면 방향 전환이나 저메모리 상황 이후에 파괴되었다가 다시 생성될 수 있으며, Android는 인스턴스 상태 복구 및 다음과 같은 라이프사이클 콜백을 제공합니다. onSaveInstanceState() for that reason, as documented in a 신뢰할 수 있는 모바일 앱 상태 관리에 관한 UC Riverside의 연구에 따르면해당 연구에서는 다음을 조사했습니다. 966개의 앱과 4,808개의 액티비티를조사한 결과, 452개의 앱(46.8%)에서 비어 있지 않은 상태를 가진 액티비티가 최소 하나 이상 발견되었습니다., 반면 1,896개의 액티비티 전체적으로 비어 있지 않은 상태를 가졌습니다. 상태(State)는 UI가 동작한 뒤에 추가하는 선택적 추상화가 아니라, 런타임 계약의 일부입니다.
목차
- 글로벌 스토어 모델 재검토
- 크로스 플랫폼 앱을 위한 아키텍처 패턴
- 영속성과 오프라인 우선 동기화
- 성능 튜닝 및 테스트 전략
- Capacitor 및 Electron을 위한 플랫폼별 가이드
- 현대적인 하이브리드 아키텍처로의 마이그레이션
- 모범 사례와 피해야 할 일반적인 실수
글로벌 스토어 모델 재검토
Redux, Context, MobX를 비교하는 것은 잘못된 접근입니다. 스토어는 업데이트를 조율할 수는 있지만, 특정 값이 서버 데이터인지, 현재 화면의 상태인지, 폼 워크플로우인지, 혹은 주소창의 값인지 결정할 수는 없습니다. 모든 값을 하나의 글로벌 컨테이너에 넣으면 API 캐시가 중복되고, URL 파라미터가 만료되며, 관련 없는 화면까지 리렌더링되는 구독 문제가 발생합니다.
지속 가능한 설계를 위해서는 각 값에 소유자와 복구 정책을 할당해야 합니다:
- 서버 상태 데이터 페칭 및 캐싱 레이어에 속합니다. API 응답, 로딩 상태, 에러, 최신성, 무효화, 재시도는 모두 원격 리소스를 설명합니다. 서버가 최종 기준이므로 클라이언트는 별도의 영구적인 source of truth를 유지해서는 안 됩니다.
- 클라이언트 또는 UI 상태 해당 상태를 소유한 컴포넌트나 기능 근처에 둡니다. 모달 표시 여부, 선택된 탭, 펼쳐진 행, 테마 설정, 임시 상호작용 플래그는 보통 앱 전역에 영구 저장할 필요가 없습니다.
- 폼 상태 별도의 워크플로우를 따릅니다. 초안 입력, 유효성 검사 메시지, dirty 상태, 제출 진행 상황은 폼 내부를 이동해도 유지되어야 할 수 있지만, 자동으로 공유 비즈니스 상태가 되어서는 안 됩니다.
- URL 상태 라우터에 속합니다. 주소창의 검색어, 필터, 정렬 기준, 선택된 레코드, 페이지네이션은 다른 스토어에 복사하지 않고도 북마크, 공유, 복원, 검사할 수 있습니다.
단일 스토어가 아키텍처 부담을 만드는 이유
2024년 애플리케이션 상태 관리 심층 리뷰 웹과 모바일 애플리케이션 전반의 상태 관리를 살펴봅니다. 이 리뷰는 흩어진 UI 변수에서 명시적이고 라이프사이클을 고려한 아키텍처로의 실무적 전환을 반영합니다. Android가 instance-state bundle에서 ViewModel과 SavedStateHandle로 발전해 온 흐름도 같은 방향이지만, 모든 값이 하나의 공유 컨테이너에 속해야 한다는 뜻은 아닙니다.
글로벌 스토어는 여전히 명확한 역할이 필요합니다. 세션 식별 정보, 권한, 앱 수준의 설정, 연결 정책, 그리고 정교하게 설계된 기능 간 워크플로우는 공유된 소유권이 필요할 수 있습니다. 문제는 해당 스토어가 더 적합한 소유자가 있는 값들을 마구잡이로 담아두는 쓰레기통이 될 때 발생합니다.
실무 원칙: 서버, URL, 또는 현재 컴포넌트로부터 값을 다시 구성할 수 있다면, 특정 워크플로우에서 반드시 필요한 경우가 아닌 한 글로벌 상태에 포함하지 마세요.
이러한 경계 설정은 독립적으로 관리되는 모듈을 지원하기도 합니다. 제품을 배포 가능한 단위로 나누는 팀은 다음과 같은 소유권 원칙을 적용할 수 있습니다. 마이크로 프런트엔드 아키텍처를 활용하여 애플리케이션 전체에 하나의 거대한 의존성 그래프를 구축하는 대신 말이죠. Capacitor 또는 Electron 코드베이스에서는 하이브리드 모델이 더 효과적입니다. 원격 데이터는 캐시와 동기화 규칙을 사용하고, UI 값은 로컬에 유지하며, 지속적인 워크플로우 상태는 명시적인 영속성을 갖도록 합니다. 이렇게 분리하면 상태를 수정하려는 충돌을 방지할 수 있고, 새로고침, 프로세스 중단 또는 오프라인 상태 이후의 복구 로직을 훨씬 쉽게 설계할 수 있습니다.
크로스 플랫폼 앱을 위한 아키텍처 패턴
상태의 소유자가 정해지면 구현 방식은 훨씬 단순해집니다. 대부분의 클라이언트 측 상태는 다음 세 가지 패턴 중 하나에 해당합니다. 로컬 컴포넌트 상태, 작은 규모의 공유 스토어, 또는 이벤트 기반 통신 격리된 모듈 간의 통신입니다. 어느 패턴도 절대적으로 우월하지는 않습니다. 잘못된 선택은 보통 팀이 업데이트 빈도, 소유권, 복구 요구사항을 파악하기 전에 패턴부터 고를 때 발생합니다.
| 패턴 | 복잡도 | 메모리 사용량 | 최적의 사용 사례 |
|---|---|---|---|
| 컴포넌트 로컬 상태 | 낮음 | 낮음 | 화면별 토글, 초안, 디스클로저 패널, 임시 선택 |
| 중앙 집중식 경량 스토어 | 보통 | 보통 | 공유 세션 설정, 테마, 활성 워크스페이스, 기능 간 UI 조정 |
| 이벤트 버스 아키텍처 | 중간에서 높음 | 변수 | 느슨하게 결합된 모듈, 플러그인 알림, 네이티브 브릿지 이벤트, 격리된 기능 경계 |
로컬 상태가 기본이어야 합니다
컴포넌트 로컬 값은 의존성 경로가 짧습니다. 모달이 열리거나, 행이 확장되거나, 폼 필드가 변경될 때 해당 기능을 소유한 컴포넌트만 업데이트하면 되므로 애플리케이션 전체에 알릴 필요가 없습니다. 이는 의도치 않은 결합을 줄이고 유닛 테스트를 직관적으로 만듭니다. 또한 모바일 화면이 일시 중단되거나 데스크톱 창이 오래 열려 있을 때 메모리 점유를 제한합니다.
멀리 떨어진 여러 기능에서 동일한 값이 필요하거나 워크플로우가 라우트 경계를 넘나들 경우 로컬 상태 관리는 까다로워집니다. 이럴 때는 애플리케이션 전역 싱글톤에 배치하기보다 기능 단위의 스토어로 상태를 끌어올리는(lifting state) 것이 좋습니다. Zustand나 Pinia 같은 가벼운 스토어를 사용하면 모든 컴포넌트가 모든 변경 사항을 구독할 필요 없이, 특정 셀렉터와 명시적인 액션만 노출할 수 있습니다.
트레이드오프는 관리의 엄격함입니다. 가벼운 스토어는 만들기 쉽기 때문에 팀 내에 중복된 스토어가 많아지고 소유권이 불분명해질 수 있습니다. 소유자를 명확히 하고, mutation 메서드를 정의하며, 어떤 컴포넌트든 마음대로 수정할 수 있는 가변 객체를 노출하는 것은 피해야 합니다.
이벤트는 유용하지만 데이터베이스는 아닙니다
이벤트 버스는 “네이티브 공유 완료”, “윈도우 활성화”, “백그라운드 작업이 새 데이터를 수신함” 같은 알림에 적합합니다. 플러그인과 모듈이 서로를 직접 import하지 않고도 통신할 수 있게 도와줍니다. 하지만 이벤트는 일시적이므로 비즈니스 상태를 기록하는 유일한 수단으로는 부적절합니다. 일시 중단되었거나, 언로드되었거나, 늦게 등록된 구독자는 메시지를 놓칠 수 있습니다.
이벤트는 무언가 일어났음을 알리는 데 사용하고, 수신 모듈이 자신의 신뢰할 수 있는 스토어나 데이터 레이어를 조회하게 하세요. 네이티브와 웹 code가 각각 별도로 진화할 수 있으므로, 이벤트 이름은 구체적으로 유지하고 페이로드는 버전을 관리하세요.
더 넓은 아키텍처 맥락에서는, Bridge Global의 모바일 앱 개발 인사이트를 통해 공통 code와 플랫폼별 동작 사이의 균형을 맞추는 데 도움을 얻을 수 있습니다. 앱 상태에도 같은 경계가 적용됩니다. 안정적인 도메인 규칙은 공유하되, 라이프사이클 어댑터와 네이티브 통합 지점은 격리하세요. 실무적인 모바일 애플리케이션 아키텍처 가이드를 설계는 폴더 구조와 의존성 그래프에서 이러한 경계가 명확히 드러나야 합니다.
영속성과 오프라인 우선 동기화
인메모리 스토어는 영속 상태가 아닙니다. OS가 모바일 프로세스를 일시 중단하거나 종료할 수 있고, 데스크톱 사용자가 창을 닫을 수도 있으며, mutation이 처리되는 중에 네트워크가 끊길 수도 있습니다. 오프라인 우선 설계는 사용자가 반드시 복구할 수 있어야 하는 것이 무엇인지 정하는 것부터 시작해, 그 요구사항에 맞춰 스토리지와 동기화 규칙을 선택합니다.
영속적인 쓰기 경로 구축
사용자 경험과 원격 확인 과정을 분리하는 안정적인 흐름은 다음과 같습니다:
- 먼저 로컬에 기록하세요. 사용자 액션을 로컬 데이터베이스나 내구성이 있는 문서 저장소에 즉시 반영하여, 네트워크 대기 없이 인터페이스가 응답하도록 합니다.
- 변경 사항을 큐에 담으세요. 엔티티 식별자, 작업 유형, 페이로드, 생성 컨텍스트, 재시도 상태와 함께 작업을 저장합니다. 메모리에만 유지되는 큐는 프로세스가 종료되면 사라집니다.
- 정확한 상태를 렌더링하세요. 로컬 저장됨, 동기화 중, 동기화 완료, 실패 상태를 구분해야 합니다. 사용자는 변경 사항이 기기에 저장되었는지, 원격으로 확인되었는지 알아야 합니다.
- 조건이 맞을 때 동기화하세요. 리스너 재연결, 앱 포그라운드 이벤트, 예약된 백그라운드 작업이 재시도를 트리거할 수 있습니다. 중단된 요청이 다시 전송될 수 있으므로 sync worker는 멱등성을 유지해야 합니다.
- 충돌을 의도적으로 해결하세요. 서버 응답을 통해 로컬 작업이 수락, 거부, 병합되었는지 또는 사용자 검토가 필요한지 결정해야 합니다.
Native Build 기반 앱의 관계형 레코드와 트랜잭션 큐에는 SQLite가 실용적인 선택입니다. IndexedDB는 브라우저 중심 저장소나 Electron renderer code에 적합하지만, 팀에서 스키마 업그레이드와 트랜잭션 경계를 신중히 관리해야 합니다. 직렬화는 명시적으로 처리하세요. 컴포넌트 인스턴스, 클로저, Native 객체 참조가 아닌 도메인 데이터와 복구 메타데이터를 영구 저장해야 합니다.
충돌 정책은 제품 결정 사항입니다
Last-write-wins 방식은 간단하지만 정당한 수정 사항을 누락할 수 있습니다. 필드 단위 병합(Field-level merging)은 독립적인 필드들이 안전하게 결합될 수 있을 때 유용합니다. 재고 관리, 승인 프로세스, 금융 기록 또는 임상 워크플로우처럼 자동 병합 시 의미가 변할 수 있는 도메인 특화 규칙을 적용하는 것이 더 안전합니다. 일부 충돌은 동기화를 차단하고 사용자에게 선택을 요청해야 합니다.
동기화 레이어는 또한 다음을 분리해야 합니다. 읽기 조정(read reconciliation) 과 변이 재실행(mutation replay). 서버 데이터를 다시 가져오는(Refetching) 것만으로는 대기 중인 mutation이 성공했음을 증명할 수 없으며, mutation을 재실행한다고 해서 결과 레코드가 현재 서버 상태와 일치한다는 보장도 없습니다. 서버 버전이나 그에 상응하는 검증기를 기록하고, 구조화된 충돌 응답을 반환하며, 실패 원인을 설명할 수 있을 만큼 충분한 큐 히스토리를 유지하세요.
이 설계의 사용자 인터페이스 측면에서는, Vue, Angular 또는 React에서 오프라인 화면을 만드는 것이 유용한 인터페이스 설계 원칙을 제공합니다. 즉, 오프라인 모드는 콘솔에 숨겨진 예외 상황이 아니라, 눈에 보이는 애플리케이션 상태여야 합니다.
다음 영상은 오프라인 동작 및 동기화 구현 작업을 보완하는 데 도움이 됩니다:
성능 튜닝 및 테스트 전략
상태 관리 성능 문제는 단순히 느린 reducer 하나 때문에 발생하는 경우가 드뭅니다. 대규모 구독(subscription)으로 인해 관련 없는 컴포넌트가 렌더링되거나, 파생된 값(derived values)이 불필요하게 재계산되고, 거대한 객체 그래프가 계속 참조되거나, 동기화 작업이 UI 스레드에서 실행될 때 문제가 발생합니다. 어떤 라이브러리가 가장 빠른지 추측하기보다 업데이트 전파 과정을 직접 측정해 보세요.
대시보드를 사용한 2026년 벤치마크 결과, 100개의 연결된 컴포넌트와 10,000번의 반복 테스트에서 MobX의 성능은 다음과 같았습니다. 단순 변경 시 0.3ms, 중첩 변경 시 0.4ms, 파생 값 변경 시 0.6ms반면 Redux Toolkit은 0.8ms, 1.2ms, 1.5ms 를 기록했습니다. 동일한 벤치마크의 메모리 비교 결과, Zustand는 2.8 MB, Redux Toolkit은 4.2 MB 를 기록했습니다. 이는 특정 벤치마크 환경에서의 관찰 결과이며 모든 프로덕션 환경을 보장하는 것은 아니지만, 구독의 세밀함(granularity)과 업데이트 전략이 왜 중요한지 잘 보여줍니다. 자세한 내용은 React 상태 관리 비교 벤치마크를 확인하세요 테스트 컨텍스트용.
업데이트 경계 튜닝하기
Selector부터 시작하세요. 컴포넌트는 전체 세션 객체나 API 응답이 아니라 의미 있는 최소 슬라이스만 구독해야 합니다. 연산 비용이 큰 파생 데이터는 메모이제이션하되, 모든 원시 값까지 습관적으로 메모이제이션하지는 마세요. 메모이제이션은 유지 및 비교 비용도 늘리므로 적용 전후로 프로파일링하세요.
긴 목록은 가상화하고, 개별 엔티티를 업데이트할 때는 레코드를 정규화하세요. 작은 필드 변경 때문에 큰 루트 객체를 통째로 교체하지 마세요. Electron에서는 창이 모바일 화면보다 훨씬 오래 살아 있을 수 있으므로 긴 세션에서 렌더러 메모리를 지켜보세요. Capacitor에서는 입력이 몰릴 때 동기식 저장을 피하세요. 초안은 debounce하거나 의미 있는 체크포인트를 저장하되, 크래시가 나도 제품이 보존한다고 약속한 데이터를 잃지 않도록 하세요.
Springer와 연계된 연구에 따르면 상태 관리 방식을 바꾸면 프로그램 실행 시간이 평균 테스트 시나리오 전반에서 17% 감소했으며,이는 불필요한 동기화와 재계산을 줄이면 실질적인 런타임 이득을 얻을 수 있다는 점을 뒷받침합니다. 이 결과는 웹 애플리케이션 상태 관리 성능 연구에서나타나 있으며, 모든 스택에서 보장되는 개선으로 봐서는 안 됩니다.
값뿐 아니라 상태 전환도 테스트하세요
성공적인 요청 이후만 확인하는 상태 테스트는 isLoading 위험한 경로를 놓칩니다. 다음 시퀀스를 테스트하세요:
- Hydration: 저장된 데이터가 로드되고, 유효하지 않은 레코드는 거부되며, 기본값은 누락된 필드만 채웁니다.
- 중단: mutation 중에 요청이 취소되거나 앱이 백그라운드로 전환되는 경우입니다.
- Replay: 대기 중인 작업이 안전하게 재시도되며, 서버 사이드 이펙트가 중복 발생하지 않습니다.
- 충돌: 서버가 오래된 버전을 거부하면 UI에서 복구 가능한 해결 방법을 제공합니다.
- 격리: 로컬 UI 업데이트가 관련 없는 기능의 렌더링이나 mutation을 유발하지 않습니다.
네트워크 경계에서 Mock server-state 어댑터를 사용한 뒤, 전체 워크플로우에는 통합 테스트를 사용하세요. 개발 및 CI 환경에 instrumentation을 추가해 예상치 못한 구독자 수, 크기 제한 없는 큐, 기능이 언마운트된 뒤 발생하는 상태 전환을 감지하세요. 가장 가치 있는 테스트 픽스처는 또 하나의 독립적인 reducer assertion이 아니라, 현실적인 라이프사이클 시퀀스인 경우가 많습니다. 다음을 활용하세요: 앱 성능 최적화 가이드 이러한 측정값을 반복 가능한 릴리스 체크로 전환할 때.
Capacitor 및 Electron을 위한 플랫폼별 가이드
웹 애플리케이션은 JavaScript 프로세스가 모바일 앱보다 더 오래 유지된다고 가정할 수 있습니다. Capacitor와 Electron은 서로 다른 방식으로 이 가정을 없앱니다. Capacitor은 웹 레이어를 iOS나 Android가 관리하는 모바일 라이프사이클 안에 두는 반면, Electron은 독립적으로 나타났다 사라질 수 있는 창을 가진 데스크톱 프로세스 모델에 Chromium 렌더러를 연결합니다.
Capacitor에는 라이프사이클을 고려한 hydration이 필요합니다
백그라운드 전환은 프로세스가 다시 살아난다는 보장이 아니라 체크포인트를 만들 기회로 보세요. 앱 상태가 바뀌면 중요한 대기 중 mutation을 flush하고, 현재 동기화 커서를 기록하며, 계속 활성 상태로 둘 필요가 없는 리소스를 해제하세요. 포그라운드로 돌아오면 손실된 데이터를 rehydrate하고, 인증을 검증하고, 오래된 서버 데이터를 새로고침하고, 로컬 스토어가 준비된 뒤에만 구독을 다시 시작하세요.
JavaScript store가 네이티브 플러그인의 내부 구현을 직접 소유해서는 안 됩니다. 카메라 세션, 생체 인증 prompt, 푸시 등록, 파일 시스템 핸들, 백그라운드 작업은 각각 플랫폼별 라이프사이클 규칙을 따릅니다. 이를 네이티브 콜백을 도메인 이벤트나 명령으로 변환하는 어댑터로 감싸세요. 그러면 store는 앱이 일시 중단된 후 무효화되는 네이티브 객체를 보유하지 않고도 unavailable, requesting, active, failed, completed 같은 상태를 표현할 수 있습니다.
웹뷰 경계 때문에 직렬화도 중요합니다. Capacitor 브리지를 통해 plain data를 전달하고, 플러그인 응답을 검증하세요. 또한 live update 때문에 서로 다른 웹 번들이 설치된 네이티브 code와 상호작용하는 상황이 생길 수 있으므로 메시지에 버전을 붙이세요. Capacitor가 웹과 네이티브 code를 연결하는 방식 이 어댑터 방식이 왜 필요한지, 그 경계를 설명합니다.
Electron에는 프로세스 소유권이 필요합니다
Electron의 메인 프로세스는 권한이 필요한 작업과 지속적인 조율을 담당해야 하며, 렌더러는 뷰 전용 상태를 관리해야 합니다. 보안 설정 읽기, 파일 쓰기, 윈도우 조율 같은 작업에는 타입이 지정된 IPC 명령을 사용하세요. 모든 렌더러에 광범위한 파일 시스템 접근 권한을 노출하지 말고, 한 윈도우로 보낸 이벤트를 영구적인 애플리케이션 기록으로 취급해서도 안 됩니다.
멀티 윈도우 애플리케이션에는 명시적인 동기화 모델이 필요합니다. 메인 프로세스는 기준이 되는 업데이트를 배포할 수 있고, 각 렌더러는 로컬 표시 상태를 유지합니다. 두 윈도우가 같은 레코드를 편집한다면 단순한 브로드캐스트 이벤트가 아니라 버전 검사나 충돌 정책이 필요합니다. 닫힌 윈도우도 다시 열릴 때 상태를 재구성할 수 있어야 하므로, 메인 프로세스나 영속성 계층이 복구 가능한 데이터의 기준으로 남아 있어야 합니다.
Capacitor와 Electron은 도메인 모델, API 클라이언트, 큐 형식, 리듀서를 공유할 수 있습니다. 라이프사이클 code까지 반드시 공유할 필요는 없습니다. 가장 강력한 크로스 플랫폼 아키텍처는 공통 상태 어휘를 갖추고, 플랫폼별 지속성·브리지·복구 어댑터를 사용합니다.
현대적인 하이브리드 아키텍처로의 마이그레이션
레거시 글로벌 스토어에 재작성이 필요한 경우는 드뭅니다. 필요한 건 현황 파악과 안전한 추출 순서입니다. 각 기능이 한 번에 상태 클래스 하나씩 옮겨가고, 기존 스토어는 손대지 않은 화면에서 계속 쓸 수 있을 때 마이그레이션이 가장 잘 작동합니다.
기술이 아닌 소유권부터 시작하세요
기존 스토어를 위한 상태 카탈로그를 만드세요. 각 필드마다 소스, 사용처, 변경 경로, 영속성 요구 사항, 복구 동작을 기록합니다. 서버에서 파생된 상태인지, 라우트에서 파생된 상태인지, 폼이 소유한 상태인지, 기능 로컬 상태인지, 공유 상태인지 표시하세요. 이 작업을 하다 보면 하나의 API 뒤에 서로 관련 없는 여러 시스템이 숨겨져 있음을 자주 발견하게 됩니다.
서버 상태부터 옮기세요. 수동으로 미러링된 API 필드를 요청 상태, 무효화, 재시도, 재검증을 관리하는 전용 페칭 및 캐싱 레이어로 교체합니다. 모든 호출부를 한 번에 바꾸지 않고 기존 화면을 마이그레이션할 수 있도록 셀렉터를 일시적으로 호환되게 유지하세요. 새 소스가 통합 테스트를 통과한 뒤에만 중복된 서버 복사본을 삭제합니다.
다음으로 URL 상태를 라우터로 돌려주세요. 검색 필터와 선택된 리소스는 라우트 파라미터나 쿼리 상태를 통해 새로고침과 공유 후에도 유지되어야 합니다. URL 값을 스토어로 복사한 뒤 스토어 값을 다시 URL로 복사하는 동기화 이펙트를 제거하세요. 이런 루프는 레이스 컨디션을 만들고 브라우저 히스토리를 신뢰하기 어렵게 만듭니다.
기능 상태를 점진적으로 추출하기
모달 상태, 위저드 진행 상황, 로컬 선택 값을 가장 가까운 기능 경계로 옮기세요. 여러 컴포넌트에서 해당 값이 필요하면 인터페이스가 좁은 기능 스토어를 사용하세요. 남은 글로벌 스토어는 세션 정책, 테마, 권한, 명시적으로 공유된 워크플로우 같은 횡단 관심사에만 사용하세요.
전환기에는 호환성 레이어를 사용하세요. 새로운 소스에서 데이터를 읽으면서도 기존 셀렉터 형태를 노출할 수 있어, 플래그 뒤에서 기능을 마이그레이션할 수 있습니다. 각 추출을 독립적으로 릴리스하고, 에러 경로와 하이드레이션 동작을 모니터링하며, 새로운 소유권 모델이 안정화될 때까지 롤백 경로를 유지하세요.
Capacitor 및 Electron 팀의 경우, Capgo을 통해 서명된 JavaScript, CSS, 설정 및 에셋 번들을 타겟 채널로 전달할 수 있습니다. 여기에는 롤아웃 제어, 버전 히스토리, 디바이스 로그, 도입 및 실패 지표, 자동 롤백 보호 기능이 포함됩니다. 이를 통해 네이티브 변경 사항은 관련 플랫폼 릴리스 프로세스를 따르면서도, 상태 관리 리팩토링은 점진적으로 배포할 수 있습니다. 이는 마이그레이션을 제어하기 위한 운영상의 이점이지, 테스트나 호환성 계획을 생략해도 된다는 뜻이 아닙니다.
모범 사례와 피해야 할 일반적인 실수
리뷰 질문이 모호하면 상태 아키텍처는 실패합니다. 설계 리뷰와 Pull Request에서 다음 점검 항목을 활용하세요:
- code에서 소유자를 명시하세요: “어떤 모듈이 이 값을 변경할 수 있으며, API은 해당 경계를 어떻게 강제하는가?”라고 질문하세요. 단순히 두 컴포넌트가 동일한 필드를 필요로 한다는 이유만으로 추가된 스토어는 거절해야 합니다.
- 복구 컨트랙트를 정의하세요: 각 영속 값에 대해 새로고침, 앱 재시작, 로그아웃, 계정 전환 시 값이 유지되는지 초기화되는지 문서화하세요. 초안 인보이스는 재시작 후에도 유지될 수 있지만, 선택한 워크스페이스는 재검증이 필요할 수 있습니다.
- 동기화를 관찰 가능하게 만드세요: 요청 ID, 버전, 재시도 횟수 및 충돌 결과를 기록하세요. 사용자가 업데이트 누락을 보고하기 전에 반복적인 재시도나 충돌 실패에 대한 알림을 설정해야 합니다.
- 객체 구조가 아닌 명령어를 검토하세요: Mutation은 비즈니스 의도를 명시하고, 입력을 검증하며, 감사(audit)에 용이한 액션 이름을 노출해야 합니다. 이러한 검증을 우회하는 직접적인 쓰기 작업은 리뷰 대상입니다.
- 비정상적인 시퀀스를 테스트하세요: 네비게이션과 함께 발생하는 hydration 레이스 컨디션, 쓰기 중단 후 재시도, 중복 전달, 두 창에서의 오프라인 편집, 요청 대기 중 로그아웃 등의 테스트를 실행하세요.
- 삭제 경로를 확인하세요: 이전 selector, persistence adapter 또는 event listener가 여전히 기존 store에 쓰기를 수행한다면 마이그레이션이 완료되지 않은 것입니다. 두 소스가 동일한 필드를 업데이트할 때 실패하는 테스트를 추가하세요.
실무적인 PR 질문은 다음과 같습니다. “쓰기가 시작되었지만 확인(acknowledgement)되기 전에 이 프로세스가 사라지면 어떻게 되나요?” 답변에는 데이터 지속성, 재시도 권한, 중복 제거 및 사용자에게 보이는 실패 상태가 포함되어야 합니다.
Capgo를 사용하면 CapacitorJS 및 Electron 팀이 서명된 bundle, 롤아웃 제어, 디바이스 레벨 logs, 롤백 방지 기능을 갖춘 타겟 채널을 통해 JavaScript, CSS, 설정 및 에셋 업데이트를 배포할 수 있습니다. Capgo 상태 관리 리팩토링 및 복구 수정을 점진적으로 배포한 다음, lifecycle 및 동기화 테스트로 검증하세요.
