전역 상태를 사용하는 기준이 있으신가요?

[Kimbangg]

현재 프로젝트는 props를 직접 주입하는 방식으로 상태를 전달하고 있으며, 전역 상태는 도입하지 않았어요. 컴포넌트 계층 구조는 다음과 같아요:

A Component
|-- AA Component
|    |-- AAA Component
|-- AB Component
|    |-- ABA Component
|         |--- ABAA Component

문제 상황:

• AA나 AB는 단순히 state 전달의 매개체 역할만 하고 있어요.
• 상태를 사용하는 컴포넌트는 계층 구조의 하위(예: AAA, ABAA)에 위치하고, 중간 컴포넌트는 상태와 관련된 로직이 없어요.

고민 지점:

• 어느 정도 계층이 깊어지면 전역 상태를 도입하는 게 좋을까요?
  • AAA 정도의 깊이에서 전역 상태를 고려할지, 아니면 더 깊은 ABAA 수준에서 전역 상태를 고려할지 기준을 잡기 어렵네요.

[jhlee0409]

저의 경우에는 도입을 고민하는 포인트가 크게 3가지 있는데요.

1. props로 내려주어야하는 depth가 얼마나 깊은가 -> ABAA 수준에서 도입을 고려
2. 같은 레벨의 특정 상태를 공유하는 컴포넌트들이 얼마나 있는가 -> depth 상관없이 공유하는 컴포넌트가 하나라도 존재하면 도입 고려
3. 파생 값이 존재하느냐 + 파생 값을 공유하는 컴포넌트가 있느냐 (2번과 맞물리는 지점) -> 도입!

위 세 가지가 모두 충족한다면 도입을 하는 편이에요.

장점으로는 아래와 같아요

1. 관리에 측면에서 유리하다. 사용하고 있는 컴포넌트까지 내려가서 확인해야하는 경우가 적어진다
2. 비교적 쉬운 렌더링 최적화 (selector 함수를 통하여...)
3. 디버깅이 쉽다? 해당 모듈을 사용하는 쪽에서는 순수하게 가공되지 않는 값만 전달하고 모든 계산은 상태 공유 모듈이 담당한다면 해당 모듈만 확인하면 된다.

코멘트를 달면서도 한번 더 생각을 해보게 되네요
명쾌한 답변은 아니지만요 ㅎㅎ..
좋은 질문 감사드립니다!

[taehee-sp]

일단 상태의 종류가 다양하기 때문에, 프롭 내리기가 귀찮다는 모호한 기준만으로 모든 걸 전역 상태 vs 지역 상태로 나누면 위험하다고 생각합니다. 전역 상태와 지역 상태는 생명주기도 다르고 용도도 다르기 때문이죠. 무엇보다 전역 상태라고 프롭 내리기를 하지 않고 필요한 곳에 바로 꽂아 넣는 게 항상 좋은 것도 아닙니다. vue나 svelte에서도 비슷한 고민을 하겠지만 일단 react를 기준으로 이야기를 해보겠습니다.

간단하게만 분리해보자면 이런 식으로 나눌 수 있을 거에요.

1. 서버가 진실의 원천이고 동기화되는 상태.
2. 브라우저나 쿠키 등에 저장되는 설정이나 인증 세션/토큰 등의 상태
3. 주로 url에 저장되는 특정 페이지나 히스토리 같은 라우팅 상태
4. 사용자가 입력하는 폼의 상태
5. 그 외 클라이언트에서 유지되는 상태들

1. 서버가 진실의 원천이고 동기화되는 상태

대부분 전역 상태일 수 밖에 없습니다. 보통 서버 상태가 컴포넌트마다 다르지는 않고요. 컴포넌트마다 다른 상태를 구독하더라도, 어쨌든 데이터의 원천은 외부에 있으니까요. 탠스택 쿼리 문서에 잘 나와 있습니다

그래서 보통 tanstack query나 swr 등을 이용해서 on-demand로 가져오고 캐시를 최신화하거나, loader 등을 이용해서 페이지 단위로 페칭하거나, server component 등을 이용해서 주입할 수도 있을 거에요.

하지만 loader 같은 경우가 아니더라도, 특정 컴포넌트가 특정 서버 리소스에 바로 의존하게 하면, 다양한 용도로 사용하기 어려워집니다. 예를 들어 hook을 사용하면 client component가 되기 쉬운데, 서버에서 렌더해야 하는 경우에는 사용하기 어려워요. 스토리북이나 테스트 등의 환경에서 tanstack-query나 fetch를 모킹하는 건 그거 props로 데이터를 넘기는 것보다 훨씬 어렵습니다. relay 같은 솔루션으로 각 컴포넌트의 data 의존성을 명확하게 하고 보장해준다고 해도, 이건 또 (백엔드를 포함한) 팀이 GraphQL과 relay를 쓰고 이해해야한다는 의존성이 강하게 따라 붙습니다.

그런 이유로 저는 서버와 동기화되는 tanstack-query 등의 상태라고 해도 보통 props로 내리는 걸 두려워하지 않는 편입니다.

2. 브라우저에 저장되는 상태

이 친구들도 그 특성상 전역 상태일 수 밖에 없습니다. 브라우저의 로컬스토리지나 쿠키 등도 앱 외부에 있기 때문입니다. (마치 백엔드 웹 애플리케이션 서버에게 os의 다른 프로세스나 파일 시스템, DB가 외부이듯이요)

하지만 위에서 말한 것처럼 스토리북과 테스트, 서버 사이드 렌더링 등의 환경을 생각하면... 이러한 데이터 소스도 컴포넌트 외부에서 주입해주는 게 나은 경우가 많았습니다. (서버와 로컬 스토리지를 공유할 수는 없잖아요?) 그리고 브라우저에 있는 상태는, 이런저런 요구사항을 따라서 서버로 옮겨가는 경우도 많으니까요. (설정을 여러 기기 간에 동기화한다거나요) 보통 자주 바뀌지 않으니 Context 로 내려주는 정도는 가능하다고 생각합니다. 보통 페이지 최상단에서 가져와서 컴포넌트로 내리게 됩니다.

3. 라우팅 상태

history, path variable, search params, hash 같은 값들도 그 특성상 전역 상태인 경우가 많습니다. 다만 위의 1,2 와 달리 특정 페이지로 이동하기만 하면 쉽게 재현하고 복원할 수 있다는 장점이 있습니다. 앱 외부에서 우리 앱의 특정 부분으로 보내는데 사용하기도 해서... route에 상태를 집어넣고, 순수하게 페이지가 결정되게 하면 여러모로 유리합니다. 다만 지역 상태와 이런 routing 상태를 상호동기화하기는 보통 어렵기 때문에, 라우팅 상태를 진실의 원천으로 삼으면 좋습니다.

그래서 라우팅 상태는 보통 일시적이고, 생명주기가 짧습니다. 1번이나 2번처럼 영속되는 상태는 페이지를 이탈하거나 할 때 지워줘야 하는 등의 어려움이 있는데요. 라우팅 상태는 페이지만 이탈하면 사라지기 때문에 편하죠. 하지만 필터나 정렬 등이 다시 돌아왔을 때 유지되기를 바란다거나 하면... 결국 1번이나 2번으로 영속도 같이 해주고 동기화도 해줘야 해서 번거로워지기 쉽습니다.

하지만 여전히 라우팅 상태도 직접 꽂아넣는 게 보통 좋은 생각은 아닙니다. storybook이나 test 환경은 보통 iframe 등 안에서 history를 이미 사용하고 있는 경우가 많습니다. router에 의존하게 되면 이런 환경을 재현하기 어려워서, in memory router나 next-router-mock 같은 걸 직접 만들어야 하는 번거로움이 커집니다. 게다가 다양한 페이지에서 재사용 하는 컴포넌트에서는 특히 안 좋은 선택입니다. 페이지마다 같은 상태의 이름이 다를 수도 있고요. router는 서버에서는 보통 request나 전용 함수로, 클라이언트에서는 hook 을 이용해서 주입하는데. 당연하게도 hook을 사용하면 ssr/ssg 는 포기해야 하는 거죠.

1,2 에서도 반복되는 이야기지만 SSR에 더해 서버 컴포넌트가 나오면서 과거 presentation 컴포넌트 패턴을 다시 살려내라는 것인가 좀 불만스러운 부분이 있습니다.

4. 폼의 상태

지역 상태의 표본입니다. 리덕스 베스트 프랙티스에서는 대부분의 경우 폼 상태를 전역 상태 라이브러리에 넣지 말라고 분명하게 이야기합니다.

폼 상태는 보통 그 페이지를 이탈하면 사라집니다. 임시 저장 등의 기능이 있더라도 이는 일시적으로 저장하고 복원하는 거지 보통 실시간으로 동기화되진 않습니다. 폼 상태의 초기값으로 123 등의 상태가 필요하다면 보통 initial 값으로 주입하기 마련입니다.

그럼에도 폼 상태를 전역 상태로 집어넣기를 바란다면, 보통 react의 특수한 성능 문제나, 필드가 많아지면서 props를 올리기 내리기가 부담스러워진 게 아닐까 싶습니다. 하지만 다시 반복하듯이, props 내리기와 전역 상태는 별개의 문제입니다.

이 문제는 ContextAPI로는 전혀 해결되지가 않습니다. 폼 전체의 상태가 상위에 있게 되면, 사용자가 한 글자를 칠 때마다 폼 전체가 리렌더 되는데요. 이는 상당 수의 리액트 앱이 느리고 버벅이게 만드는 성능 문제의 주범입니다.

보통 react-hook-form이나 final-form, formik 등의 폼 라이브러리를 사용하면 지역 상태로 폼 상태를 만들게 됩니다. 그러면 폼 단위에서 provider로 아래의 field 컴포넌트들에 폼의 store를 내려줄 수 있습니다. form의 store는 보통 내부는 가변이지만, 이 store 자체의 참조는 변하지 않기 때문에 폼 전체의 리렌더를 일으키지 않습니다. 각 Field 컴포넌트는 자신이 관심을 가지는 필드의 상태만 선택해서 구독합니다. 이러면 prop 내리기의 고통 없이 복잡한 폼도 쉽게 만들 수 있게 되는 경우가 많습니다. 그러면 각 필드는 독립되어 응집도를 가지고 처리할 수 있습니다. (예시 : https://github.com/twinstae/coaching-sospeso/blob/main/src/components/SospesoApplyingForm.tsx)

이러한 방식의 문제는 당연하게도 여러 필드의 상태가 엮인 경우는 어떻게 하냐는 것인데. 보통 여러 필드가 엮어져 있더라도 모든 폼의 상태를 필요로 하는 건 아니기 때문에 큰 문제는 없었습니다.

5. 그 외에 클라이언트의 상태

여기에는 보통 특정한 컴포넌트의 캡슐화 가능한 상태들이 들어갑니다. 예를 들자면 모달이 열리고 닫힌다거나 (overlay-kit을 사용할 것 같은), collapsible한 아코디언 등이 열리고 닫힌다거나, 캐로셀이 알아서 넘어간다거나, hover나 focus, scroll 되는 상태 같은 것들 말이죠. 이런 상태들은 보통 생명주기가 매우 매우 짧고, 영속될 필요가 아마 없습니다. (스크롤 복원 등의 상황이 아니라면?) 메모리 안에서 태어나 메모리 안에서 사라지는 경우가 많습니다. 그래서 uncontrol 즉 통제하지 않고 그냥 컴포넌트 안에서 알아서 내버려 두게 하면 편합니다.

하지만 이런 상태를 1,2,3 등으로 외부에서 통제(control)하고 싶은 경우가 자주 생깁니다. 기억나는 사례로는 특정 url로 들어오면 특정 list item으로 가서 아코디언을 열어달라거나. 상세 페이지에 들어갔다 돌아오면 scroll을 복원해달라는 식의 요구사항이었습니다. 이런 경우에는 상태 영속이 필요하기 때문에 1,2,3 등으로 가야하는 거죠.

그런 경우에는 폼과 비슷하게, 이런 상태를 초기값으로 외부에서 설정할 수 있게 하고, 그 후로는 단방향으로 업데이트 되게하면 좋습니다. 아니면 한 상태에서 다른 상태가 파생되게 하고, CSS로 선언적으로 처리하거나, 외부 헤드리스 컴포넌트 라이브러리 등을 활용하면 쉽게 풀리는 경우가 매우 많았습니다.

props 내리기에 대하여

이러나 저러나 props을 내리는 건 여러모로 고민이 되는 문제입니다. 자식 컴포넌트에 필요한 의존성을 부모에서 알아야 한다는 건 좀 번거롭지만, 어떤 의존성이 있는지 명확히 숨겨지지 않고 보이는 건 장점입니다. 당연히 타입 체크도 되지요. 마치 Option이나 Result 같은 모나드 타입이 숨겨진 부수효과를 명확히 드러내듯이요. poor man's DI 라는 말이 있는데요. 생성자나 매개변수로 넘기는 건 직관적이고 단순한 의존성 주입 방법이기도 합니다. 서버와 클라이언트 모두에서 쉽게 사용할 수 있고요. storybook이나 test 환경도 쉽게 지원할 수 있습니다.

그럼에도 한 컴포넌트에 의존성 props를 5개 6개씩 넘기거나, 3단계 4단계 씩 내리거나, 복잡한 의존성 그래프를 만들게 되면... provider나 전역 상태를 직접 꽂고 싶은 유혹이 커질 것입니다. 저라면 의존성을 props로 주입 받는 컴포넌트를 만들고, 바로 윗 단계의 적절한 단위에서 주입하는 식으로 타협하기도 합니다만. 보통은 캡슐화만 잘해도 그런 고통은 많이 사라졌습니다. (애초에 하나의 개발자가 5, 6개 계층을 모두 가로질러 작업하는 게 문제는 아닐까요? 디자인 시스템이나 공용 컴포넌트로 처리할 문제를 애플리케이션 개발을 하면서 고민하진 않을까요?)

마지막으로 다시 정리하지만, props 내리기의 고통은 전역 상태보다는 의존성 주입 방식의 고민에 가깝다고 생각합니다. ContextAPI가 있으니 전역 상태 라이브러리가 필요가 없다는 식의 오개념이 자꾸만 퍼지는데요. ContextAPI 는 상태 관리 도구가 아니라 의존성 주입 도구로 보는 게 맞고, 의존성 주입 도구들의 네이밍 컨벤션을 따르고 있습니다.

리덕스나 jotai 등도 프로바이더를 쓴다고 하지만, 대부분 store를 동적으로 주입하기 위한 용도일 뿐입니다. Jotai는 그래서 global store를 가지고 providerless 모드로 쓸 수 있고요. 애초에 앱의 핵심 기능을 ContextAPI 처럼 특정 프레임워크의 한정된 기능에 종속시킨다면... Context 를 서버에서 쓸 수 있게 되기 전까지는 서버에서 주입할 방법이 없다거나 하는 이슈를 계속 겪게 될 겁니다. (Context가 만능인 줄 알고 살다가 server component를 만나고 엉엉 울었다)

어떤 경우에는 build 툴의 resolve alias를 사용하는 것도 좋을 것이고요. overlay-kit 처럼 기존에 번거롭게 만들던 isOpen 같은 전역 상태를 깔끔하게 캡슐화해주는 선언적인 라이브러리를 만드는 것도 도움이 될 것입니다. prefetch나 suspense, error boundary 등을 이용해서 loading 등의 상태를 제거하고, 앱 위로 올려버릴 수도 있고요.

다만 이는 상태를 어디에 둘 것인가의 고민과는 다르게 생각해봐야 할 것입니다.

(의존성 주입에 대해 썻던 글을 첨부합니다 https://tech.wonderwall.kr/articles/functionaldependencymanagement/ )

[ohprettyhak]

좋은 글 감사합니다. 1. 서버가 진실의 원천이고 동기화되는 상태 부분에서 탠스택 쿼리 링크가 구글 밋으로 넘어가는데 한 번 확인해주시면 감사하겠습니다 :)

[taehee-sp]

좋은 글 감사합니다. 1. 서버가 진실의 원천이고 동기화되는 상태 부분에서 탠스택 쿼리 링크가 구글 밋으로 넘어가는데 한 번 확인해주시면 감사하겠습니다 :)

아하 그렇네요. 고쳐두었습니다.

[Johnyworld]

ContextAPI 는 상태 관리 도구가 아니라 의존성 주입 도구로 보는 게 맞고

너무 공감됩니다. 단지 props drilling 을 피하기 위해서 Context 를 사용하는 경우도 많은데, Context 는 "맥락" 을 담아야 하고 맥락에 맞는 데이터와 메서드를 가지고 있어야 한다고 생각합니다.
그리고 반드시 같은 맥락의 다른 파일들과 "응집" 되어있어야 하구요

[saengmotmi]

ContextAPI 는 상태 관리 도구가 아니라 의존성 주입 도구로 보는 게 맞고

너무 공감됩니다. 단지 props drilling 을 피하기 위해서 Context 를 사용하는 경우도 많은데, Context 는 "맥락" 을 담아야 하고 맥락에 맞는 데이터와 메서드를 가지고 있어야 한다고 생각합니다.

그리고 반드시 같은 맥락의 다른 파일들과 "응집" 되어있어야 하구요

@Johnyworld 덧붙여주신 부분도 되게 좋네요. 생각해보면 서버 API 작성하는 context 개념(미들웨어 등)이나 클로저의 렉시컬 스코프 같은 개념과 꽤나 친연성이 있는 명명인데 useContext랑 이 개념들을 명시적으로 연결지어 생각해보지 못했네요. 감사합니다 :)

[taehee-sp]

ContextAPI 는 상태 관리 도구가 아니라 의존성 주입 도구로 보는 게 맞고

너무 공감됩니다. 단지 props drilling 을 피하기 위해서 Context 를 사용하는 경우도 많은데, Context 는 "맥락" 을 담아야 하고 맥락에 맞는 데이터와 메서드를 가지고 있어야 한다고 생각합니다.

그리고 반드시 같은 맥락의 다른 파일들과 "응집" 되어있어야 하구요

@Johnyworld 덧붙여주신 부분도 되게 좋네요. 생각해보면 서버 API 작성하는 context 개념(미들웨어나 AsyncLocalStorage 등)나 클로저의 렉시컬 스코프 같은 개념과 꽤나 친연성이 있는 명명인데 useContext랑 이 개념들을 명시적으로 연결지어 생각해보지 못했네요. 감사합니다 :)

그렇죠. Provider 나 Context 가 보통 의존성 주입의 네이밍 컨벤션이라. 백엔드나 기존 객체지향 생태계나 함수형 쪽 DI 대안들을 잘 숙고해보면 유용한 대안들이 많이 있습니다. 저는 의존성 주입 방법 13가지 같은 글을 언젠가 쓰려는 계획도...

[jungpaeng]

depth를 기준으로 전역 상태를 사용할지 여부를 결정하면 안 될 것 같습니다.
또한, 저는 대부분의 서비스에서 전역 상태를 저장하기 위한 목적으로 전역 상태 관리 라이브러리(redux, jotai, zustand 등)를 사용하지 않아도 된다고 생각해요.

저는 react에서 전역 상태 관리 라이브러리 전성 시대가 열린 것이 과거 리액트의 행적과 큰 연관이 있다고 생각이 드는데요.

redux 전성시대

과거 훅도 없고 SPA라는 개념도 낯설던 시절, 리액트라는 작은 라이브러리로만 서비스의 모든 상태를 관리하는 것은 부담으로 다가왔어요.
서버에서 내려주는 수많은 데이터들과 내가 서버로 보내야 할 값들, 그리고 폼에서 다루고 있는 값, 유저 정보와 같이 대부분의 서비스에서 참조할 것 같은 값 등..

심지어 state에만 저장해두면 그 컴포넌트를 벗어날 때 상태가 초기화돼서 다시 불러와야 해요. 그래서 그당시 많은 사용자들이 선택한 게 "저 값들을 redux의 단일 스토어에 저장하고 당장 필요할 때 필요한 부분만 작게 쪼개서 가져오자." 라고 생각해요.

당시에는 정말 다른 방법이 없었거든요. useSyncExternalStore과 같은 훅도 없고 ContextAPI도 없어서 다른 페이지와 공유하는 값을 만드는 것도 번거로웠고 항상 골칫거리였는데 다소 복잡해보이긴 하지만 redux만 깐다면 이 모든 문제를 대신 해결해준다니! 정말 마법같은 물건이었죠.

그래서 서버에서 내려주는 데이터들도 리스트와 같은 경우 더 효율적으로 관리하기 위해 normalize해서 redux에 저장하고 그것을 클라이언트에서 사용하고 이런 형태로 사용이 됐어요. 그러나 그 때에도 많은 사용자들이 너무 보일러플레이트가 많다고 불만을 표했었죠.

ContextAPI의 등장

그리고 ContextAPI가 나왔어요. 이 때, 많은 사용자들이 "ContextAPI로 redux를 대체할 수 있느냐?" 하면서 많은 관심을 표했어요.
그렇지만 ContextAPI는 단순히 상태를 전달하는 통로 역할만 할 뿐이었고, 당시 ContextAPI에 대한 연구는 많이 진행되지 않았으며 리액트의 리렌더링에 대한 오해도 많이 쌓여있는 상태였어요.

"리액트 리렌더링이 자주 일어날 수록 페이지가 늘어나니까 모든 컴포넌트에 memo를 씌우자"와 같은 주장도 꽤 있었던 것으로 기억해요.

그래서 ContextAPI는 상태를 보다 더 멀리 전달할 수 있음에도 "redux를 대체할 수는 없음"이라고 많은 사용자들이 결정내리고 redux를 유지했죠.

물론, ContextAPI를 어떻게든 써볼 수 있을까? observedBits를 이용해서 계산식을 넣으면 실제 값이 변경된 컴포넌트만 다시 업데이트가 되는데? 이거 selector 불필요한 거 아님? 이런 의견도 꽤 있었어요.

이후 얘기지만, dai-shi 아저씨가 ContextAPI를 이용해서 꽤 많은 실험을 했고, 꽤 긴 시간이 있지만 그 이후에 탄생한 게 jotai, zustand, valtio 등이에요.

값을 전달해주는 통로 + 상태를 selector 기반(redux), atomic 기반(recoil), subscribe(mobx) 기반으로 다루는 개념을 접목시켜서 라이브러리를 만드셨죠.

ReactQuery도 등장

redux 사용이 많아지면서 사용자마다 모두 다른 보일러 플레이트를 작성하고, 사용하는 미들웨어도 모두 다르고 꽤 많은 혼란이 있었다고 생각해요.

그래서 "당신에게 redux는 꼭 필요하지 않을 수 있습니다" 등과 같은 글고 많이 나왔죠. 그러던 중, ReactQuery가 나오게 됐어요. redux 사용자들에게는 정말 단비같았죠.

redux에 때려넣고 있던 데이터들 중 심지어 효율적으로 다루겠다고 normalizing까지 해서 서버 데이터를 저장했던 그 힘든 과정을 ReactQuery가 모두 대신 해주겠다고 하니까요.

한 번 호출한 API의 데이터를 알아서 캐싱하고 같은 API를 짧은 시간 내에 호출했을 때 캐싱 데이터를 이용하는 등, 귀찮은 작업들을 꽤 많이 가져가서 redux에 남아있는 데이터는 많이 남지 않게 되었어요.

지금 생각해보면?

과거 시점이 아닌 지금 시점에서 생각해보면, 데이터를 전역에 저장하기 위해서 redux, jotai, zustand 등과 같은 전역 상태 도구를 꼭 써야할까? 생각하면 전 아닐 것 같아요.

물론, selector 패턴이 필요해서 redux나 zustand를, atomic store pattern이 필요해서 jotai를 선택할 수는 있다고 생각해요. 하지만, 이것이 주 목적이어야 하지, 전역으로 상태를 저장하는 것이 주 목적이면 안 될 것 같아요.

서버에서 내려주는 많은 데이터는 ReactQuery를 통해 캐싱하는 방향으로 발전해왔고, 남아있는 데이터를 봤을 때 별로 많지 않을 것 같아요.

또한, 각 영역을 지정해서 상태를 관리하고 ContextAPI와 useReducer를 적절히 활용해서 상태를 관리하도록 하면 전역 상태 관리 라이브러리들이 제공해주는 편리한 상태 관리 기능도 많이 대체할 수 있다고 생각해요.

props drilling이 싫어요

리액트 문서에서는 props drilling에 대한 해결 방법으로 전역 상태 관리 라이브러리 사용을 제시하는 게 아닌, ContextAPI 사용을 제시하고 있어요.

실제로 ContextAPI는 props drilling을 피하는 효과적인 수단이에요. 앞서 언급한 대로 리액트 리렌더링으로 인해서 꺼려질 수 있지만, 저는 리렌더링은 문제가 되지 않는다고 생각해요.

• https://kentcdodds.com/blog/fix-the-slow-render-before-you-fix-the-re-render
• https://x.com/asidorenko_/status/1596468945321865216?s=46&t=aLO5O-zBL9EKV7jifx-o5g

리렌더링은 문제가 되지 않는다는 의견이 많고, 리액트에서 렌더 단계에 진입했다고 돔이 다시 리렌더링되는 건 절대 아니거든요.

제가 선호하는 스택

저는 대부분 상태를 관리할 때, useReducer와 ContextAPI를 사용해요.

또한, 정말 복잡한 상태를 관리해야 할 때는 useReducer를 대체하는 형태로 xstate를 사용하며, 필요하다면 ContextAPI를 사용하고 있어요.

[injunchoi98]

좋은 댓글 감사합니다. 앞서 다른분들이 말씀하신 것처럼 context api는 상태관리자가 아닌 DI툴로 prop drilling을 피하게 해줍니다. 다만 말씀하신대로 context api는 상태를 저장하거나 읽고 업데이트하지 않기에, 상태관리를 할 수 없고 이에 따라 상태관리를 위해선 usereducer와 context api를 조합하여 사용할 수 있습니다. 그러나 vdom의 depth가 깊어지면 리렌더링 성능에 문제가 생길 수 있고 이를 해결하기 위해 useMemo나 react.memo를 사용하다보면 redux 열화판을 만들고 있단 사실을 깨닫게 될겁니다. 그때 전역 상태관리 라이브러리 도입을 고민하면 된다고 생각합니다.

[jungpaeng]

그러나 vdom의 depth가 깊어지면 리렌더링 성능에 문제가 생길 수 있고 이를 해결하기 위해 useMemo나 react.memo를 사용하다보면 redux 열화판을 만들고 있단 사실을 깨닫게 될겁니다.

저는 이런 경우에도 도입을 할 필요가 없다고 생각하는 입장입니다.

대부분의 경우, React의 재조정 단계는 매우 빠르고 컴포넌트 수가 많아진다고 하더라도 재조정만으로는 성능에 크게 영향을 주지 않았습니다. 실제로 꽤 복잡한 UI 에디터 서비스를 만들 때에도 전역 상태 관리 라이브러리 없이 ContextAPI만을 이용해서 props drilling을 해결했고, 성능에 문제가 생기지 않았습니다.

컴포넌트가 많아질수록 그리고 깊어질수록 ContextAPI를 썼을 때 성능 저하가 일어난다면 그것은 단순히 컴포넌트의 수가 많기 때문이 아니라 리렌더링이 일어나면서 컴포넌트에 존재하는 무거운 로직을 여러 번 다시 실행하기 때문이라고 생각합니다.

그리고 가장 좋은 해결법은 그 로직 자체의 개선이지, 단순히 리렌더링 횟수를 줄이는 것은 그 문제를 덮어두는 것으로 생각되어서 리렌더링 횟수를 줄이기 위해서 전역 상태 관리 라이브러리를 사용하는 것을 선호하지는 않습니다.

또한, useReducer + ContextAPI를 사용하는 것은 Redux의 열화판을 만들 수 있다는 점에 대해서 어떤 의도로 그렇게 말씀해주신 것인지는 이해가 갑니다.

useReducer 자체가 들고 있는 로직이 복잡한 경우라면, 이 로직을 Redux로 이동해도 동일하게 복잡해지기 때문에 Redux가 좋은 해결책으로 생각되지는 않습니다.

저는 이러한 경우에는 xstate + ContextAPI를 조합해서 상태 머신을 만들어 전체 흐름을 관리하는 방법을 이용하고 있습니다.

[injunchoi98]

로직 자체의 개선이 필요하다는 점에 공감합니다. useCallback이나 useMemo 같은 memoization 기법에도 비용이 존재하며, React 공식 문서에서도 실행 시간이 100ms를 넘어서면 memoization을 고려해보라고 권장하고 있습니다. 하지만 로직 개선보다는 memoization이 더 쉬운 해결책이기 때문에, 이를 남용하면 말씀하신 대로 문제를 덮어두는 방식이 될 수도 있습니다.

Hot path를 찾아내고 prototype method를 활용하는 등 로직 자체의 개선도 중요하지만, 컴포넌트의 depth가 깊어지면 Context API를 사용하는 것은 재렌더링 비용을 증가시킬 수 밖에 없습니다. 왜냐하면 React는 부모 컴포넌트가 재렌더링되면 자식 컴포넌트들도 모두 재렌더링되기 때문입니다. 이는 Svelte 블로그의 “Virtual DOM is pure overhead” 글에서도 지적된 부분입니다.

물론 lazy initialization을 활용하거나, 자식 컴포넌트의 선언을 부모 컴포넌트 바깥으로 이동하는 Composite Pattern을 적용할 수도 있습니다. 하지만 부모로부터 prop을 받아야 하는 경우, 이러한 최적화 기법을 적용하기 어렵고, 특히 참조형 변수를 prop으로 받는 경우에는 더욱 그렇습니다.

따라서 Context API를 사용할 경우 prop이 변경되지 않았음에도 부모 컴포넌트가 렌더링되었기 때문에 자식 컴포넌트들도 불필요하게 재렌더링됩니다. 저도 렌더링 자체를 나쁘다고 생각하지 않습니다. UI 변경을 계산하는 필수적인 과정이기 때문입니다. 하지만 불필요한 리렌더링을 줄여 성능을 최적화할 수 있다면, 이는 충분히 고려해야 할 문제라고 생각합니다.

Virtual DOM의 depth가 얕다면 memoization을 통해 최적화하더라도 그 개선 결과가 ns~μs 단위일 것이므로 큰 의미가 없을 수도 있습니다. 하지만 depth가 깊어질수록 memoization의 필요성이 커지고, 일일히 memoization을 적용하기 보단 전역 상태 관리 라이브러리를 활용해 구독 중인 값이 변경된 컴포넌트들만 리렌더링하도록 만드는 것이 더 효과적이라 생각합니다.

결국 저는 reducer + Context API의 대체제로 Redux를 도입한다면, 로직 관리보다는 Context API의 provider보다 hierarchy가 낮은 자식 컴포넌트들이 모두 재렌더링되는 성능 문제를 해결하기 위해 선택할 것 같습니다.

[jungpaeng]

자세히 의견을 남겨주셔서 감사합니다. 잘 읽어보았습니다.

하지만 depth가 깊어질수록 memoization의 필요성이 커지고, 일일히 memoization을 적용하기 보단 전역 상태 관리 라이브러리를 활용해 구독 중인 값이 변경된 컴포넌트들만 리렌더링하도록 만드는 것이 더 효과적이라 생각합니다.

실제 돔에서의 리렌더링은 많은 자원을 잡아먹기 때문에 실제로 느린 것이 맞고 컴포넌트 구조가 깊어질 수록 더욱 느려지기 때문에 피해야 하는 것이 맞습니다만, VDOM에서는 그렇게 많은 자원을 잡아먹지 않기 때문에 복잡한 서비스와 컴포넌트를 만들 때에도 이를 메모이징을 직접 사용해가면서까지 피해야 할 필요성을 크게 느끼지 못했습니다.

앞서 댓글에서 언급했지만, UI 에디터를 만들 때 Resizable, Draggable 등과 같이 사용자의 인터렉션에 반응하는 컴포넌트를 만들어서 화면에 n개의 컴포넌트를 배치하고 각 컴포넌트의 좌표, 크기 등의 값을 서비스 최상단 ContextAPI에 저장하는 방식의 서비스를 만들 때에도 useCallback, useMemo 그리고 memo 등과 같은 메모이징 유틸을 사용하지 않았음에도 저사양 기기에서 문제가 발생하지 않았습니다.

돌이켜보면 React는 children prop이 이전과 동일하면 memo()를 사용하지 않더라도 자식을 다시 렌더링하지 않기 때문에 메모이징과 같은 효과를 낼 수 있어서 컴포넌트의 뎁스가 깊어지더라도 크게 문제가 되지 않았을 거라고 생각됩니다.

공유주신 "Virtual DOM is pure overhead" 글에서 리액트는 diffing 단계를 거치기 때문에 비용이 공짜가 아니라고 말하고 있으며, 매번 렌더링될 때마다 컴포넌트에 들어있는 실행문이 다시 실행되기 때문에 불필요한 연산이 이뤄진다고 말하고 있습니다.
정리해보면 이를 VDOM의 한계라고 말하고 있으며, 스벨트는 런타임에서 재조정을 통해 업데이트할 돔을 결정하는 VDOM과 달리 빌드 단계에서 이를 알 수 있으니 더욱 빠르다고 말하고 있습니다.

https://news.ycombinator.com/item?id=34612162

위 글에서 리액트 팀이었던 "peterhunt"가 언급한 내용을 보면, 리액트를 오픈 소스로 공개하기 전에 모바일 검색, 데스크톱 광고 관리 등과 같은 실제 애플리케이션에서 성능을 광범위하게 측정했고, VirtualDOM의 diff 오버헤드가 실제로 사용자 경험에 의미 있게 영향을 주는 경우는 매우 드물다고 말하고 있습니다. 또한, 눈에 띄는 상황에서는 이를 우회할 수 있는 방법(메모이징 관련 유틸들)이 있습니다.

위 댓글에서 언급된 엣지 케이스처럼 렌더링에 의해 무거운 연산이 계속 실행되는 탓에 속도 문제가 발생하고 해당 로직을 더이상 최적화하기 어려운 상황이 발생했다면 말씀주신 것처럼 메모이징을 피하기 어려운 상황이 왔다고 생각됩니다.

이러한 상황에서 어쩔 수 없이 모두 직접 관련된 컴포넌트 / 함수 / 변수 등에 메모이징을 걸어서 무거운 연산이 재실행되지 않도록 조치해야 하지만, 이것 또한 리액트 컴파일러가 공개된 만큼 빠르게 개선될 수 있을 거라고 기대하고 있습니다.

그래서 저는 성능을 최적화하기 위해서 전역 상태 관리 라이브러리를 추가하지 않을 것입니다.

---

위에서 ContextAPI를 사용하더라도 크게 느리지 않아서 전역 상태를 사용하지 않는다 라고 말했지만 이렇게 생각을 하게 된 배경 또한 있는데요, 저 또한 리액트를 얼마 사용하지 않고 ContextAPI도 없어서 redux 외에는 상태를 공유할만한 대안이 없을 때에는 값 공유, 성능 개선 등 다양한 이유로 redux를 사용해왔습니다.

또한, ContextAPI가 나온 이후에도 특정 페이지의 redux를 ContextAPI로 교체했을 때 속도가 많이 느려지는 것을 체감하고 ContextAPI의 observedBits를 조작하는 과정을 거치다가 복잡도가 너무 높아져서 다시 전역 상태 관리 라이브러리로 이동했던 경험도 있습니다.

그렇게 redux, mobx, recoil, jotai, zustand 등 많은 전역 상태 라이브러리를 사용해왔는데, 이렇게 전역 상태 관리 라이브러리가 추가될 때 공통적으로 느꼈던 문제가 팀원마다 무엇을 전역 상태로 분리할 것인지에 대한 의견이 모두 다르다는 것이었습니다.

props drilling을 피하기 위해서 ContextAPI를 사용하기 싫으니까 전역 상태로 대체하자는 의견, 페이지 이동 등 라우팅이 달라지지만 값을 유지해야 하는 경우에만 사용하자는 의견, 성능에 영향을 줄 수 있는 값들을 모두 전역 상태로 관리하자는 의견, 또 폼과 같은 데이터를 관리할 때 스텝이 들어가면 번거로워지니까 모든 데이터를 애초에 전역 상태로 관리하자는 의견 등

다양한 의견들이 모이고 바쁜 일정 사이에서 이를 조율하지 못하니 전역 상태 스토어는 점점 많은 값들을 담게 되었고 값이 리액트의 외부에 저장되고 많은 컴포넌트에서 값을 조작할 수 있는 만큼 디버깅 또한 점점 어려워지는 것을 경험했습니다.

가장 많은 버그가 발생했던 것이 n개의 컴포넌트에서 동시에 전역 상태의 값을 조작해서 저장된 값이 의도하지 않은 값이 되거나, 특정 단계에서 초기화가 필요한 값이 전역 상태로 저장된 경우 초기화가 진행되지 않아서 엉뚱한 값이 보여지는 경우 등이 생각납니다.

제가 전역 상태를 기피하는 것은 위와 같은 경험을 가진 상태에서 React에 점차 익숙해지니 "전역 상태를 사용하지 않고 ContextAPI만을 사용하더라도 퍼포먼스에 큰 영향이 없네?" 라는 생각을 갖게 되어서인 것도 큰 것 같습니다. 이러한 과정을 거치지 않았으면 저도 상태가 많아져서 성능을 개선해야 할 때 이전처럼 전역 상태를 추가하는 것을 계속 고려했을 것 같습니다.

결국 작업하는 환경에 따라서 상태를 어떻게 조작할지에 대한 의견이 모두 달라질 수 있을 것 같은데요, 이런 생각을 갖고 있구나 정도로 봐주시면 좋을 것 같습니다.

[injunchoi98]

좋은 댓글 계속 달아주셔서 감사합니다.
말씀주신것처럼 '어떤것을 전역상태인로 관리할 것긴가'라는 원래 토론 주제와 그에 대해 고민하신 부분은 사실 저도 아직 명확한 답을 내리진 못하는 것 같습니다.
어떤 맥락에서 전역 상태 라이브러리를 지양하게 되신지 더 이해가 잘 되는 것 같습니다.
저도 고민하신 부분과 토론주제에 대해 좀 더 고민하고 경험하여 더 좋은 코드를 짤 수 있도록 노력할 것 같습니다.
앞으로도 토론탭에서 자주 뵐 수 있기를 기대하겠습니다. 감사합니다!

[milooy]

🤖 토론 요약 봇

@Kimbangg 님, 멋진 토론을 열어주어서 감사합니다.
토론에 참여해주신 모든 분들 덕에 의미 있는 토론이 일어났어요.
그 중 가장 도움이 되었던 댓글이 있다면 Mark as answer 를 누르고 본 토론을 close해주세요!
완료된 토론은 디스커션 혹은 FF 문서 내 링크에서 계속 볼 수 있습니다.

---

📌 전역 상태를 사용하는 기준에 대한 토론 요약

🏷️ 핵심 질문

• 현재 프로젝트에서 props를 통해 상태를 전달하고 있으며, 전역 상태는 사용하지 않음.
• 하지만 계층이 깊어지면서(A → AA → AAA → ABAA...)
  "언제 전역 상태를 도입하는 것이 좋을까?" 라는 고민이 생김.

---

🚀 전역 상태를 도입할 때 고려해야 할 3가지 주요 기준

(@jhlee0409의 답변)

1. props로 내려주는 깊이가 너무 깊은가?
   • 일반적으로 ABAA 수준 이상에서 전역 상태 고려 가능.
2. 같은 레벨에서 특정 상태를 공유하는 컴포넌트가 많은가?
   • 깊이와 상관없이 공유하는 컴포넌트가 하나라도 있다면 도입 고려.
3. 파생 값이 존재하는가 + 파생 값을 공유하는 컴포넌트가 있는가?
   • 파생 상태를 공유해야 한다면 전역 상태가 유리.

🏆 전역 상태의 장점

• 관리가 쉬워짐 → 어디서 상태를 확인해야 하는지 명확해짐.
• 렌더링 최적화 가능 → selector 함수 등을 활용하여 불필요한 렌더링 방지.
• 디버깅이 용이 → 상태가 한 곳에서 관리되면 추적이 쉬움.

---

🎯 전역 vs 지역 상태를 구분하는 기준

(@taehee-sp의 답변)
전역 상태를 무조건 도입하기보다는 상태의 성격을 먼저 파악해야 함.

1️⃣ 전역 상태가 적합한 경우

• 서버 상태: 서버에서 동기화되는 데이터 → TanStack Query, SWR 등 활용
• 브라우저 저장 상태: 로컬스토리지, 쿠키, 인증 토큰 등
• 라우팅 상태: URL에서 관리되는 정보 (history, search params 등)

2️⃣ 지역 상태가 적합한 경우

• 폼 상태: react-hook-form 등으로 관리하는 것이 일반적
• UI 상태: 모달 열림 여부, hover 상태 등
• 단순한 컴포넌트 내부 상태: 굳이 전역으로 관리할 필요 없음

3️⃣ 혼합해서 관리할 수도 있음

• 특정 상태는 라우팅 상태와 동기화할 수도 있음 (예: 필터 상태)
• 특정 UI 상태는 초기값만 외부에서 주입받고 내부적으로 관리하는 것도 가능

⚠️ 전역 상태가 항상 정답은 아니다!

• 전역 상태를 사용하면 유지보수가 어려워질 수 있음.
• 스토리북, 테스트 환경, SSR에서 전역 상태가 걸림돌이 될 수도 있음.
• props 내리기와 전역 상태 관리는 별개 문제
  → props가 귀찮다고 전역 상태를 무조건 도입하지 말 것.

---

🛠 ContextAPI는 상태 관리 도구가 아니다!

(@Johnyworld, @injunchoi98의 답변)

• ContextAPI는 상태 관리 도구가 아니라 "의존성 주입(DI) 도구"
• "props drilling을 피하려고 Context를 사용한다" → ❌ 잘못된 접근
• ContextAPI를 이용한 상태 공유는 리렌더링 이슈를 초래할 수 있음.
• useReducer와 함께 사용하면 관리가 가능하지만, 과하게 사용하면 결국 Redux의 열화판을 만들게 됨.
• 전역 상태 도입은 정말 필요할 때만 고려하는 것이 좋음.

---

🔥 Redux vs React Query vs ContextAPI vs Zustand/Jotai

(@jungpaeng의 답변)

• 과거에는 Redux가 거의 필수였지만, 현재는 React Query + ContextAPI만으로도 충분한 경우가 많음.
• 서버 데이터를 Redux에 저장하고 관리하던 패턴 → React Query 등장 이후 많이 사라짐.
• ContextAPI와 useReducer를 잘 활용하면 전역 상태 관리 라이브러리가 없어도 되는 경우가 많음.
• 전역 상태 관리 라이브러리는 "전역 상태를 저장하는 것"이 아니라, "특정 패턴을 제공하는 것"이 핵심.
  • Redux, Zustand → selector 기반 패턴
  • Jotai, Recoil → atomic store 패턴

💡 Redux 같은 라이브러리가 필요한 경우?

• 대규모 애플리케이션에서 복잡한 상태를 관리해야 할 때
• 다양한 컴포넌트 간 상태 공유가 많을 때
• 상태의 변경이 많고 디버깅이 중요한 경우

---

✅ 결론: 전역 상태 도입, 이렇게 판단하자!

1. 단순히 props 내리기가 귀찮아서 전역 상태를 도입하는 것은 ❌
2. 상태의 성격을 먼저 파악하자! (서버 상태 vs 브라우저 상태 vs UI 상태)
3. 전역 상태를 도입하는 주요 기준
   • 깊은 props drilling → ContextAPI (but, 리렌더링 고려)
   • 다수의 컴포넌트가 공유 → Zustand, Jotai
   • 서버 데이터 → React Query
   • 전역적인 복잡한 상태 관리 → Redux

🎯 "전역 상태 관리 라이브러리를 꼭 써야 할까?"
→ 대부분의 경우 아니다. ContextAPI + useReducer만으로도 충분한 경우가 많다! 🚀

[RyuWoong]

여러페이지를 거쳐야해서 전역상태를 사용해야할 것 같다면, useFunnel을 고려해볼 수도 있겠죠?

[milooy]

ㅋㅋ 맞아요! useFunnel도 일종의 제한된 전역상태를 제공하죠