이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
상태 관리 라이브러리 경험으로는 Zustand를 팀 프로젝트에서 써본 것이 있습니다. 여러 컴포넌트에서 같은 데이터를 공유해야 하는 상황이었는데, props로 계속 내려보내다 보니 컴포넌트 트리가 깊어질수록 코드가 복잡해지는 문제가 생겼습니다. Zustand를 도입하니 필요한 컴포넌트에서 바로 상태를 가져올 수 있어서 코드 구조가 훨씬 단순해졌습니다. 다만 처음 설정할 때 어떤 상태를 전역으로 관리하고 어떤 건 로컬에 두어야 하는지 기준을 잡는 게 어려웠습니다. 처음에는 거의 모든 상태를 전역으로 올렸다가 불필요하게 복잡해진 경험이 있었습니다. 이후로는 여러 컴포넌트에서 공유하거나 유지해야 할 상태만 전역으로 관리하는 기준을 만들었습니다. Zustand는 설정이 가볍고 사용법이 간단해서 소규모 프로젝트에 잘 맞는다고 느꼈습니다.
상태 관리 라이브러리 경험으로는 Redux를 수업 과제에서 써본 것이 있습니다. 처음에는 설정 코드가 많아서 진입 장벽이 높다고 느꼈습니다. action, reducer, store를 따로 만들어야 해서 간단한 기능 하나를 만들어도 파일이 여러 개가 생겼습니다. 하지만 프로젝트 규모가 커지면서 상태 변경이 어디서 일어나는지 추적이 명확해지는 장점을 느꼈습니다. Redux DevTools로 상태 변화 이력을 볼 수 있어서 버그 원인을 찾는 데 도움이 됐습니다. 한 번은 상태를 잘못 업데이트해서 화면이 예상과 다르게 동작했는데, DevTools로 어느 action에서 문제가 생겼는지 바로 확인할 수 있었습니다. Redux는 규모가 크거나 상태 변화가 복잡한 프로젝트에서 구조를 잡는 데 유리하다고 생각합니다. 소규모에서는 오히려 설정 비용이 더 클 수 있다는 것도 배웠습니다.
상태 관리 라이브러리를 처음 쓴 건 props drilling 문제를 직접 경험하고 나서였습니다. 컴포넌트가 3~4단계 이상 중첩되면서 데이터를 내려보내는 코드가 반복되고, 중간 컴포넌트는 그 데이터를 실제로 쓰지 않으면서 그냥 전달만 하는 구조가 됐습니다. 그때 Zustand를 도입해서 필요한 컴포넌트에서 바로 상태를 꺼내 쓰는 방식으로 바꿨고, 코드가 훨씬 간결해졌습니다. 처음엔 설정이 어렵게 느껴졌는데, 실제로 쓰고 나니 왜 이런 도구가 필요한지가 바로 이해됐습니다. 다만 전역 상태를 너무 많이 만들면 어디서 어떤 상태가 바뀌는지 파악하기 어려워지는 문제가 생긴다는 것도 경험했습니다. 지금은 공유가 필요한 상태만 전역으로, 나머지는 로컬로 관리하는 기준을 갖고 쓰고 있습니다. 도구보다 어떤 상태를 어디서 관리할지 판단이 더 중요하다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.