이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 API 데이터를 전역 상태에 저장해서 관리하다 보니 데이터가 오래돼도 업데이트가 안 되는 문제가 발생했습니다. 직접 refetch 타이밍을 관리하다 보니 코드도 복잡해졌습니다.
React-Query를 도입했습니다. 서버 데이터는 React-Query가 캐싱과 재요청을 관리하고, 클라이언트 상태만 별도로 관리하는 방식으로 분리했습니다. 처음에는 캐시 키 설계를 잘못해서 서로 다른 데이터가 같은 키를 사용하는 버그가 발생했는데, 키 구조를 계층적으로 관리하는 방식으로 수정했습니다.
이후로 데이터 신선도 관련 이슈가 없어지고 로딩 상태 관리 코드도 줄어들었습니다. 서버 상태와 클라이언트 상태를 구분하는 것이 상태 관리의 핵심이라는 것을 그 경험에서 배웠습니다. 그 경험이 상태를 종류별로 다르게 다루는 시각을 만들어주었습니다.
팀 프로젝트에서 여러 컴포넌트가 공유해야 하는 필터 상태를 props로 계속 내려보내다 보니 중간 컴포넌트들이 필요도 없는 props를 받아야 하는 상황이 됐어요.
Recoil을 처음 써봤는데, atom으로 상태를 정의하고 필요한 컴포넌트에서 직접 읽고 쓰는 방식이 props 드릴링 문제를 해결해줬어요. 처음엔 atom을 너무 많이 만들어서 어디서 어떤 상태를 쓰는지 추적이 안 되는 문제가 생겼는데, atom 파일을 기능 단위로 묶어서 관리하니 해결됐습니다.
전역 상태가 편리하지만 무분별하게 쓰면 오히려 흐름이 불분명해진다는 걸 그 경험에서 배웠어요. 어떤 상태를 전역으로 올릴지 기준을 정하는 게 중요하다는 것도요. 그 경험이 상태 관리 도구 선택에 대한 기준을 만들어줬어요.
새 프로젝트를 시작할 때 팀원들이 Redux, Recoil, React-Query를 각자 선호해서 어떤 것을 쓸지 의견이 갈렸어요. 각자 써봤던 것을 주장하는 상황이었습니다.
어떤 상태를 어떻게 쓰는지 먼저 정리하고 도구를 고르자는 방식을 제안했어요. 서버 데이터가 많고 클라이언트 상태는 단순하다는 걸 확인하고 나서 React-Query와 간단한 Context 조합으로 결론 냈습니다. 복잡한 상태 관리 라이브러리 없이도 충분하다는 판단이었어요.
도구 선택이 '어떤 게 유명한가'보다 '지금 내 프로젝트의 상태가 어떻게 생겼는가'에서 시작해야 한다는 걸 그 경험에서 배웠어요. 오버엔지니어링이 단순한 문제를 복잡하게 만든다는 것도요. 그 경험이 도구를 맥락 안에서 선택하는 습관을 만들어줬어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.