📌 Zustand에서 Selector는 꼭 써야 할까요?

Zustand, Recoil, Redux 등 상태 관리 라이브러리를 사용하다 보면 "selector" 라는 개념을 자주 접하게 됩니다.

처음에는 “굳이 이걸 왜 써야 하지?” 싶은 생각이 들 수 있지만, 실제 프로젝트가 커질수록 selector의 필요성과 효율성을 체감하게 됩니다.

이 글에서는 프론트엔드 개발자의 입장에서 Selector가 무엇인지, 왜 사용하는지, 그리고 Zustand에서 실제로 어떻게 활용할 수 있는지까지 자세히 정리해보았습니다.

---

✅ Selector란 무엇인가요?

Selector는 상태에서 원하는 값을 선택하거나, 가공해서 반환하는 함수입니다.

단순히 상태를 그대로 가져오는 것이 아니라,

• 특정 조건으로 필터링을 하거나
• 복수의 상태를 조합하여 새로운 정보를 만들거나
• 포맷팅 또는 변환된 상태값을 제공하는 역할 을 수행합니다.
  

💡 React의 useMemo와 개념적으로 유사하지만, store 내부에서 정의되며 전역적으로 재사용할 수 있다는 점에서 차별화됩니다.

🤔 “셀렉터는 Recoil 전용 아니야?”

➡️ 아니요. 셀렉터(selector) 는 Recoil의 전용 기능이 아니라
“상태 파생값(derived state)”을 계산하는 일반적인 개념이에요.

용어	의미
Selector (일반 용어)	상태에서 특정 값을 추출하거나 가공해 리턴하는 함수 (리액트 상태 관리 공통 개념)
Recoil Selector	selector() 함수로 등록하는 내장 API
Zustand Selector	내장 API는 없고, 직접 함수로 정의해서 사용
Redux Selector	createSelector (reselect 라이브러리)로 구현하는 메모이제이션 함수

즉, Recoil이 셀렉터라는 개념을 공식 API로 채택했을 뿐,

이 개념은 상태 관리에서 널리 쓰이는 일반적인 개념이에요.

---

🔍 Zustand에서는 어떻게 쓰는데?

Zustand에서는 아래처럼 함수로 직접 셀렉터를 정의합니다.

getSelectedDepartment: () => {
  const { selectedDeptId, departments } = get();
  return departments.find(d => d.deptId === selectedDeptId) || null;

그리고 아래처럼 컴포넌트에서 사용할 수 있어요:

const selected = useGroupStore.getState().getSelectedDepartment();

이런 걸 Recoil에서는 selector()로 등록해서 사용하는 것뿐이에요.

---

📦 즉, 셀렉터는 “Recoil만의 기능”이 아니라…

• Recoil은 "selector"를 공식 기능으로 이름 붙였고
• Redux는 createSelector라는 함수로 외부 라이브러리에서 제공하고
• Zustand는 자유롭게 “우리가 직접 셀렉터처럼 함수 정의”해서 써요

---

🤔 Selector를 사용하는 이유

1. 중복 로직 제거

아래와 같이 부서 정보를 찾는 로직이 여러 컴포넌트에서 반복되는 경우가 많습니다:

const dept = departments.find(d => d.deptId === selectedDeptId)

→ 이러한 코드를 store 내부의 selector 함수로 추출해두면 재사용성이 높아집니다:

getSelectedDepartment: () => {
  const { selectedDeptId, departments } = get();
  return departments.find(dept => dept.deptId === selectedDeptId) || null;
}

---

2. 상태 구조 변경에 유연합니다

예를 들어 상태 구조가 바뀌어 departments가 organization.departments로 변경된다면,
컴포넌트마다 전부 수정을 해야 하지만,

→ selector를 사용하면 selector 하나만 고치면 모든 컴포넌트가 자연스럽게 반영됩니다.

---

3. 컴포넌트는 표현(UI)에만 집중할 수 있습니다

const leaderName = useGroupStore.getState().getLeaderName(5)

위처럼 컴포넌트는 "어떻게 데이터를 가져올지"가 아니라,

"어떤 데이터를 표현할지"에만 집중할 수 있게 되어 UI/로직 분리(SoC) 가 잘 이루어집니다.

---

4. 안정적인 코드 작성 (null-safe)

조건문 없이 무심코 아래와 같은 코드를 작성하면:

const leader = departmentMembers[deptId].find(m => m.position === 1);

→ 에러 발생 가능성 (Cannot read properties of undefined)이 높아집니다.

하지만 selector 내부에서 예외 처리를 해두면 컴포넌트에서는 안심하고 사용할 수 있습니다.

---

🧠 Selector 실제 코드 예시 (Zustand 기준)

// store 내부에 정의
getSelectedDepartment: () => {
  const { selectedDeptId, departments } = get();
  return departments.find(dept => dept.deptId === selectedDeptId) || null;
},

getLeaderName: (deptId: number) => {
  const members = get().departmentMembers[deptId] || [];
  const leader = members.find(member => member.position === 1);
  return leader?.userNm || '';
}

컴포넌트에서는 다음과 같이 간단하게 사용합니다:

const selectedDept = useGroupStore.getState().getSelectedDepartment();
const leaderName = useGroupStore.getState().getLeaderName(selectedDept?.deptId || 0);

---

📍 Selector는 언제부터 도입하는 것이 좋을까요?

• 특정 상태에 대해 계산된 값을 여러 곳에서 반복 사용하고 있다면
• 상태 구조가 중첩되거나 복잡해질 가능성이 있다면
• 유지보수 및 리팩토링 효율을 고려해야 한다면

➡️ 이럴 경우, selector를 미리 정의해두는 것이 코드 품질과 개발 속도 모두에 도움이 됩니다.

---

🛠️ 팁: 셀렉터는 store 외부로 따로 빼도 좋습니다

// store/group/selectors.ts
export const getSelectedDepartment = (state: GroupState) => {
  return state.departments.find(d => d.deptId === state.selectedDeptId) || null;
};

컴포넌트에서는 아래처럼 사용할 수 있습니다:

const dept = getSelectedDepartment(useGroupStore.getState());

---

✅ 마무리하며

Selector는 초반에는 없어도 코드를 작성하는 데 문제가 없어 보일 수 있습니다.

하지만 코드가 점점 커지고 상태가 복잡해질수록 selector를 사용하지 않으면

• 로직이 중복되고
• 컴포넌트가 무거워지고
• 상태 변경에 따른 버그 발생 위험이 높아집니다.

Zustand와 같은 경량 상태 관리 도구에서도,

상태를 “어떻게 가공해서 쓸지까지 설계하는 것이 진짜 상태 관리의 핵심입니다.