인턴 생활 중 새로운 프로젝트에 들어가게 되면서 기획에 많은 변화가 생기고, 그에 따라 존재하는 레거시 코드가 비교적 적기도 하여 코드들의 개선 사항과 구현되지 않은 부분에 대해 정리해봤어요.
정리한 내용들 중에는 다음과 같이 전역 상태 관리에 내용도 포함되어 있어요.
- Modal 타입은 전역에서 관리하는 게 어떤지 ?
-> 페이지에서 관리하기보다 바깥쪽에서 하위 컴포넌트로 Modal 타입(submit, done)을 공유하기 때문에 전역으로 관리하면 좋을 듯
- Modal 타입보다 Modal의 열림/닫힘 상태를 전역에서 관리해도 좋을 듯- pageIndex도 전역에서 관리하는 게 어떤지 ?
-> 여러 컴포넌트들에서 현재 pageIndex를 저장하고 있음
-> prop으로 넘겨주는 것보다 전역으로 관리하면 props drilling을 피할 수 있을 듯
이런 저런 개선 사항들을 정리해보다 문득 공유하는 상태를 가지고 있으면 무조건 전역 상태를 써야 하는 거 아닌가 ? 라는 생각을 하고 있음을 깨달았고,
전역 상태를 관리하는 기준을 확실히 하는 것이 후에 의견을 전달할 때 더 도움이 될 것 같다고 생각하여 ‘어떤 경우에 전역 상태 관리를 사용하는가?’에 정리해보고자 해요.
이전에도 이런 고민을 한 적이 있는데, 그 당시 도달했던 나름의 결론은 이런 것들이었고, 위의 개선 사항들도 이에 기반한 제안들이에요.
- 컴포넌트 props drilling의 depth가 3 이상일 때 고려하기
- 페이지의 최상단에서 하위 컴포넌트에 뿌려주는 상태일 때 고려하기 (ex. 유저 id, dark/light mode)
더 구체적이고 명확한 기준에 대한 의견이 궁금해서 찾아보던 도중 관련된 주제에 대해 토론하는 글을 발견했어요.
해당 discussion에서도 질문자 분께서 전역 상태를 사용하는 명확한 기준을 고민하시는 것 같았고, 여러 주니어, 시니어 개발자 분들께서 너무 유의미한 인사이트를 많이 공유해주셔서 이를 바탕으로 저의 의견도 구체화 해보고자 해요.
Context API는 전역 상태 관리 도구가 아니다
전역 상태 관리를 위해 Context API를 도입했다. 라는 말은 맞지 않다고 해요.
그 이유는 Context API는 네이밍 컨벤션에서도 알 수 있듯이, 상태 관리 도구라기보다 의존성 주입(DI) 도구에 가깝다고 해요.
chat gpt에게 의존성 주입의 뜻을 검색하면 다음과 같이 알려주고 있어요.
간단하게 JS에서는 props를 내려주는 것이 대표적인 의존성 주입에 해당한다고 볼 수 있어요.
Context API를 의존성 주입 도구라고 바라보니, 이제 Context API를 언제 사용해야 할지 그 범위를 좀 더 축소 해볼 수 있어보여요.
- Modal
- Modal은 독립적으로 동작하는 컴포넌트 (의존성 X)
- 따라서 Modal의 제어가 필요한 컴포넌트의 상단에 Provider를 써서 해당 컴포넌트를 관리할 수 있다 !
- dark/light mode
- 마찬가지로 독립적으로 동작하는 컴포넌트이기 때문에 의존성이 없다.
- 최상단에 Provider를 써서 전체적인 페이지의 테마를 관리할 수 있다.
- Page Index
- 페이지 인덱스에 따라 렌더링 되어야 하는 content가 달라짐 (의존성 O)
- 따라서 Context API를 써야 한다면 쓰이는 페이지의 상단에 쓸 수는 있겠지만, Props drilling의 depth가 많이 깊지 않은 이상 굳이 쓸 필요가 없어보임.
props drilling + α ?
props drilling의 발생만으로 전역상태를 사용해야 할까 ?
여기까지 읽으셨다면 이 질문에 대한 답이 ‘아니요’ 일 거라고 생각해요.
그렇다면 props drilling + α 가 있어야 전역 상태 도입을 고려할텐데, 이 α는 어떤 것들이 있을까요 ?
보통 Context 코드를 작성할 때는 ThemeContext, ModalContext처럼 어떤 Context인지 나타내는 키워드가 함께 들어가는 경우가 많아요. 이처럼 Context API를 사용할 때는 해당 Context를 사용하는 컴포넌트들이 공통된 키워드를 공유하고 있어야 자연스럽다고 생각해요.
또한 앞서 이야기했듯이, Context API는 상태 관리 도구라기보다 의존성 주입 도구에 가까워요.
그래서 Context를 분리했을 때, 그 Context에 담긴 책임도 함께 분리될 수 있는 경우에 사용하는 것이 적절하다고 생각해요.
즉, 하나의 독립된 맥락과 역할을 가진 경우에만 Context로 분리하는 게 좋아요.
전역 상태 관리 도구
개인적으로, Context API를 도입하는 진입 장벽은 낮으나, 전역 상태 관리 도구를 도입하는 것에 있어서는 더 신중해지는 편입니다. 실제로 제가 참여했던 프로젝트 중 하나는, 전역 상태 도구를 하나도 사용하지 않고 완성한 사례도 있어요.
그만큼 전역 상태 도구는 상황에 따라 도입 여부를 분명히 판단해야 하는 도구라고 생각해요.
제가 신중하게 접근하는 이유는 다음과 같아요.
외부 라이브러리
- Context API는 React에 내장된 기능이지만, Zustand, Recoil, Jotai 등 전역 상태 도구들은 모두 외부 라이브러리이기 때문에 도입의 명확한 이유가 있어야 한다고 생각해요.
- 그래서 새로운 상태를 전역으로 관리하고 싶을 때도
“이건 꼭 전역이어야 하나 ?”
“Context API만으로 충분하지 않을까 ?”
와 같은 질문을 스스로에게 던지게 되고,
그 과정에서 전역 도구 없이도 충분히 구현이 가능한 경우가 많다는 걸 경험했어요.
그렇다면 전역 상태 관리 도구는 언제 사용하는 게 좋을까요 ?
저는 이 문제에 대해 정해진 정답은 없다고 생각해요.
이전에 언급한 전역 상태 관리 도구를 도입하지 않은 프로젝트도 있었던 반면에, Zustand를 도입하여 전역 상태를 관리했던 프로젝트도 있었어요.
이런 경험들을 생각해보았을 때, 프로젝트의 FE 팀원들 마다 선호하는 방식이 각자 다르고, 프로젝트 마다 전역 상태 관리 도구를 도입했을 때 더욱 효율적으로 상태들을 관리할 수 있는 프로젝트가 존재한다고 생각해요.
전역 상태 관리 도구의 도입 여부는 '필요성'과 '맥락'을 기반으로 팀 내에서 합의되는 기준을 세우는 것이 중요하다고 생각해요.
상태가 자주 변경되고 여러 컴포넌트에서 동시에 사용되거나, 페이지 전환 이후에도 상태가 유지되어야 하는 경우에는 전역 상태 관리 도구가 유용하게 작동할 수 있어요. 반대로 단순히 props 전달이 불편하다는 이유로 전역 도구를 도입하면 오히려 코드의 복잡도만 높아질 수 있어요.
결국 중요한 건
"전역 상태가 정말 필요한 상태인가?",
"Context만으로는 해결이 어려운 구조인가?”
와 같이 판단할 수 있는 기준을 팀이 함께 공유하고, 프로젝트 성격에 맞게 선택하는 유연한 태도를 갖는 것이라고 생각해요.
