🎣 05. 실무 100% 활용법: 커스텀 훅과 안티패턴

🎯 이 섹션을 읽고 나면:

• 스토어 훅(useStore)을 컴포넌트에서 직접 호출하지 않고 커스텀 훅으로 캡슐화(Encapsulation)하는 이유를 알 수 있다.
• 상태(State) 구독 없이 액션(Action) 함수만 추출하여 불필요한 리렌더링을 완전히 차단하는 패턴을 적용할 수 있다.
• useEffect를 사용해 React 컴포넌트의 상태나 Props를 Zustand에 강제 동기화하려는 행위가 왜 최악의 안티패턴인지 이해한다.

📋 목차

• 🤔 왜 알아야 하는가
• 🏗️ 1. 스토어 캡슐화: 커스텀 훅 (Custom Hooks)
  • ❌ 인라인 셀렉터 남용
  • ✅ 커스텀 훅으로 은닉 (Encapsulation)
• 💎 2. 파생 상태(Derived State) 로직 감추기
• 🚀 3. 구독 끊기: Action 전용 Hook
• ☠️ 4. 최악의 안티패턴: useEffect로 동기화하기
  • ❌ 영철이의 폭발하는 타이머
• 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 6분

🗺️ 이 문서의 흐름
인라인 셀렉터의 문제점 → 커스텀 훅으로 추상화 → 파생 로직 은닉 → 액션 분리 → useEffect 동기화 안티패턴 경고

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "리드 님! Zustand 정말 편해요. 요즘엔 제가 컴포넌트 짤 때마다 무조건 파일 맨 위에 const user = useAppStore(state => state.user.profile) 이렇게 셀렉터를 짜넣고 시작해요. 근데 유저 스토어 구조가 한 번 바뀌니까 한 50개 파일 찾아다니면서 셀렉터를 다 수정해야 하는데, 이거 맞나요?"
• 🦁 영호 ( 리드 ): "영철 님, Zustand가 보일러플레이트가 없다고 해서 추상화(Abstraction) 까지 생략하라는 뜻은 아닙니다. 컴포넌트가 스토어의 내부 깊은 구조(Depth)를 너무 훤히 알고 있으면 결합도가 높아집니다. 글로벌 스토어를 커스텀 훅으로 예쁘게 포장하는 실무 테크닉을 알려드릴게요."

🤔 왜 알아야 하는가

Zustand 문서를 열면 가장 먼저 나오는 코드는 const bears = useStore((state) => state.bears) 입니다. 이처럼 컴포넌트가 직접 스토어 전체 상태 트리에 접근하여 원하는 조각을 떼어오는(Selecting) 방식은 빠르고 직관적입니다.

하지만 실무 환경에서 프로덕트 규모가 커지면 문제점들이 속출합니다.

1. 중복과 파편화: 수많은 컴포넌트에서 동일한 Selector 콜백이 복사-붙여넣기 됩니다.
2. 리팩토링 지옥: 스토어 내부 구조를 한 번 변경(state.user -> state.auth.user)하면, 해당 스토어를 사용하는 수십 개의 파일에서 전부 에러가 터집니다.
3. 렌더링 지뢰밭: 액션(함수) 하나만 필요한데 스토어 껍데기를 잘못 구독하여 무한 리렌더링이 납니다 (이전 렌더링 최적화 챕터 참고).

잘 짜인 아키텍처는 "어떤 라이브러리를 쓰는지"를 컴포넌트가 모르게 합니다. Zustand 스토어를 커스텀 훅(Custom Hook) 이라는 외투로 입혀서 제공해야 합니다.

🏗️ 1. 스토어 캡슐화: 커스텀 훅 (Custom Hooks)

영철이가 짜놓은 기존 코드를 보겠습니다.

❌ 인라인 셀렉터 남용

// components/UserProfile.tsx
import { useAuthStore } from '@/store/authStore';
 
export function UserProfile() {
  // 🚨 영철: "컴포넌트마다 스토어 안쪽을 직접 다 뒤져서 꺼내와야지!"
  const userName = useAuthStore(state => state.user.profile.name);
  const avatar = useAuthStore(state => state.user.profile.avatarUrl);
  // ...
}

✅ 커스텀 훅으로 은닉 (Encapsulation)

스토어를 정의한 파일(authStore.ts) 맨 단에, 컴포넌트들이 가져다 쓸 수 있는 작은 커스텀 훅들을 미리 정의해서 export 합니다.

// store/authStore.ts
import { create } from 'zustand';
 
const useAuthStore = create(...)
 
// 🦁 영호: "컴포넌트한테는 스토어 쌩얼(useAuthStore)을 보여주지 마세요. 예쁘게 포장해서 내보냅니다."
export const useUserName = () => useAuthStore(state => state.user.profile.name);
export const useUserAvatar = () => useAuthStore(state => state.user.profile.avatarUrl);
export const useIsLoggedIn = () => useAuthStore(state => !!state.accessToken);

이제 컴포넌트의 코드가 압도적으로 우아해집니다.

// components/UserProfile.tsx
import { useUserName, useUserAvatar, useIsLoggedIn } from '@/store/authStore';
 
export function UserProfile() {
  const isLoggedIn = useIsLoggedIn();
  const name = useUserName();
  const avatar = useUserAvatar();
  
  // 💡 컴포넌트는 이게 Zustand에서 오는지, Context에서 오는지 알 필요도 없습니다!
}

유지보수의 마법: 훗날 스토어 구조가 바뀌면 컴포넌트는 단 한 줄도 수정할 필요가 없습니다. 오직 authStore.ts 파일 내부에 선언된 커스텀 훅의 Selector 리턴값만 수정해주면 앱 전체에 방어선이 쳐집니다.

💎 2. 파생 상태(Derived State) 로직 감추기

장바구니 총액이나 필터링된 게시글처럼 계산이 필요한 값(파생 상태)을 가져올 때도 커스텀 훅이 빛을 발합니다.

// ❌ 컴포넌트 단에서 연산 (무거운 훅)
function CartSummary() {
  const items = useCartStore(state => state.items);
  const total = items.reduce((sum, i) => sum + i.price, 0); // 렌더링마다 계산
}
 
// ✅ 스토어 단에서 Selector로 연산 은닉
export const useCartTotal = () => useCartStore(state => 
  state.items.reduce((sum, item) => sum + item.price, 0)
);
 
function CartSummaryPro() {
  // 🦁 영호: "컴포넌트는 뷰(View)만 그립니다. 계산식은 스토어로 밀어 넣으세요."
  const total = useCartTotal(); 
}

🚀 3. 구독 끊기: Action 전용 Hook

가장 빈번하게 일어나는 렌더링 최적화 실패 사례입니다. 그저 버튼을 누를 때 작동할 '메서드(함수)' 하나만 필요한데 무심결에 스토어를 호출하는 경우입니다.

// ❌ 영철이의 무한 렌더버튼
function LogoutButton() {
  // 🚨 Zustand의 모든 상태 중 하나라도 바뀌면 이 로그아웃 버튼 컴포넌트가 재렌더링됨
  const { logout } = useAuthStore(); 
  return <button onClick={logout}>로그아웃</button>
}

함수도 역시 Selector로 하나씩 짚어와야 하지만, 액션이 많아지면 반복 노가다가 됩니다. 이때 5년 차들은 Actions 객체를 묶어서 빼냅니다.

// store/authStore.ts
const useAuthStore = create((set) => ({
  user: null,
  // 💡 상태(State)와 액션(Action) 함수 객체를 내부적으로 뎁스를 나눠 분리합니다
  actions: {
    login: () => set(...),
    logout: () => set(...),
  }
}));
 
// Action만 쏙 빼가는 전용 훅
export const useAuthActions = () => useAuthStore(state => state.actions);

// components/LogoutButton.tsx
import { useAuthActions } from '@/store/authStore';
 
function LogoutButtonPro() {
  // ✅ 완벽 차단! 상태값이 천 번 변해도 이 버튼은 초기 1회만 렌더링되고 끝납니다.
  const { logout } = useAuthActions(); 
  return <button onClick={logout}>로그아웃</button>
}

☠️ 4. 최악의 안티패턴: useEffect로 동기화하기

Zustand 커뮤니티에서 가장 경고하는 치명적인 안티패턴입니다. 부모 컴포넌트에서 받은 props나 로컬 useState 값을 Zustand 글로벌 스토어에 쑤셔 넣기 위해 useEffect를 남용하는 행위입니다.

❌ 영철이의 폭발하는 타이머

// 🐣 영철: "게시글 ID Props를 받았으니 Zustand 스토어에 넣어둬야 다른 애들도 이 ID를 알지!"
function PostDetail({ postId }: { postId: string }) {
  const setPostId = useAppStore(state => state.setPostId);
 
  // 🚨 최악의 안티패턴
  useEffect(() => {
    setPostId(postId); // 렌더링 -> Effect 발생 -> 상태 변경 -> 재렌더링 무한 루프 위험!
  }, [postId, setPostId]);
 
  return <div>...</div>
}

이 코드는 다음과 같은 문제를 낳습니다.

1. React의 데이터 단방향 흐름(Top-Down)을 정면으로 위배합니다.
2. 컴포넌트 렌더링이 완료된 직후(Effect) 전역 상태가 바뀌기 때문에 불필요한 연쇄 리렌더링 폭풍(Waterfall)을 일으킵니다.
3. 이 컴포넌트가 언마운트(Unmount) 될 때 스토어의 postId를 누가 청소할 건가요? 쓰레기 데이터가 남습니다.

🦁 영호의 지옥 탈출 솔루션:
"Props로 내려온 데이터는 그냥 Props로 쓰거나, 하위 트리에서만 공유해야 한다면 거창한 Zustand 대신 React Context API를 만들어 내려주세요. 정 전역 스토어를 찌르고 싶다면 렌더링 중(useEffect)이 아닌 이벤트 핸들러(버튼 클릭, 페이지 이동 액션 내부) 에서 스토어를 업데이트해야 합니다."

📝 마무리 퀴즈

Q1. Zustand 스토어를 프로젝트 내 컴포넌트에서 가져다 쓸 때 가장 권장되는 추상화 패턴은 무엇인가요?

• A) 모든 컴포넌트에서 useStore를 통째로 임포트하여 인라인 콜백으로 상태를 꺼내 쓴다.
• B) 스토어 정의 파일 하단에 전용 커스텀 훅(useUser, useAuthActions)을 만들어 그것만 export 한다.
• C) Context API로 한 번 더 감싸서 내려 보낸다.
• D) 전역 객체인 Window에 스토어를 마운트하여 직접 참조한다.

✅ 정답: B

💡 상세 해설:

• 원리 설명: 스토어 훅을 은닉(Encapsulation)하여 커스텀 훅으로 배포하면, 컴포넌트는 전역 상태의 내부 뎁스와 구조에 의존하지 않게 됩니다. 스토어 형태가 변경되더라도 커스텀 훅 단 1곳만 수정하면 되기 때문에 유지보수성이 극대화됩니다.
• 오답 피드백: "영철 님, 매번 컴포넌트에서 보따리(스토어)를 직접 풀어서 헤집어 놓지 마세요. 필요한 것만 건네주는 직원(커스텀 훅)을 고용합시다."
• 📌 핵심 기억법: 🦁 영호: "스토어는 숨기고, 커스텀 훅으로만 소통하라."

Q2. 함수(Action) 하나만 컴포넌트에서 호출하려고 스토어를 참조했을 때 불필요하게 리렌더링이 자주 발생한다면, 가장 의심해야 하는 패턴은 무엇인가요?

• A) useStore(state => state) 처럼 스토어 전체를 반환받아 비구조화 할당(Destructuring)으로 함수를 꺼냈다.
• B) 버튼 클릭 이벤트 내부에서 get() 함수를 사용했다.
• C) 컴포넌트에 React.memo를 씌우지 않았다.
• D) useStore(state => state.logout) 과 같이 함수 하나만 찍어서 가져왔다.

✅ 정답: A

💡 상세 해설:

• 원리 설명: const { logout } = useStore() 처럼 스토어를 통째로 구독해버리면, 스토어 내부의 count나 user 등 어떤 상태가 바뀌어도 객체 참조가 변경된 것으로 간주되어 컴포넌트 전체가 다시 그려집니다. 성능 측면에서 최악의 안티패턴 중 하나입니다.
• 오답 피드백: "영철 님, 구조 분해 할당 편하다고 막 쓰면 리렌더링 폭탄 맞습니다. 필요한 타겟물만 조준경으로 정확하게 찍으세요!"
• 📌 핵심 기억법: 🦁 영호: "함수 하나 쓰려다 스토어 전체를 구독하는 것은 배가 고프다고 식료품 창고째 짊어지는 꼴입니다."

Q3. 🏋️‍♂️ 영철의 테스트 타임 (Q&A)

영철이가 여러 컴포넌트에서 useAppStore(state => state.theme === 'dark') 를 복붙해서 쓰고 있었습니다. 리뷰에서 이를 커스텀 훅으로 빼라는 지시를 받았는데, 어차피 한 줄짜리 코드인데 굳이 빼야 할까요?

✅ 정답: 네, 반드시 빼야 합니다. export const useIsDarkMode = () => useAppStore(state => state.theme === 'dark'); 처럼 모듈화해야 합니다.

💡 상세 해설:

• 원리 설명: 지금 당장은 한 줄이지만, 추후에 다크모드 판별 로직이 state.theme === 'dark' || state.systemTheme === 'dark' 처럼 복잡해지면 파일 100개를 일일이 수정해야 합니다. 커스텀 훅은 변경에 대한 유일무이한 단일 지점(Single Point of Truth)을 만들어 방어벽을 형성합니다.
• 오답 피드백: "영철 님, 복붙(Copy&Paste)은 죄악입니다! 손가락이 조금 편하자고 미래의 내 목을 조르지 마세요!"
• 📌 핵심 기억법: 🦁 영호: "컴포넌트는 스토어의 이름을 몰라야 한다. 오직 커스텀 훅이라는 웨이터를 통해서만 주문하라."

🐣 영철이의 퇴근 일기

오늘은 '동작은 하는' 코드가 왜 '구린' 코드인지 뼈저리게 느꼈다. 나름 상태관리 툴 쓴다고 여기저기 스토어를 호출해댔는데, 그게 결국 스파게티 코드 변종일 뿐이었다는 리드 님의 팩폭에 할 말이 없었다. 컴포넌트 상단에 const { isDark, userName, logout } = useAuthStore() 라고 예쁘게 훅으로 뽑아 쓰고 나니 코드가 갑자기 시니어의 향기를 풍기기 시작했다. 그리고 useEffect 안에 set함수 넣었다가 앱 무한루프 나서 컴퓨터 터질 뻔했던 트라우마도 이참에 고쳐야겠다. Zustand... 알면 알수록 깐깐하지만 진짜 매력 있는 녀석이다.

💡 "전역 스토어는 속이 훤히 보이는 어항이 아니다. 예쁜 포장지(Custom Hook)로 감싸고 액션과 상태를 분리해 컴포넌트에 배달하자."