06. 🧠 상태 관리 도구의 철학과 최적화 전략

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 23분 (핵심 요약: 11분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: Context API vs 라이브러리] → [질문 2: Flux 아키텍처] → [실전 변형 질문]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• Context API의 성능 한계와 전역 상태 라이브러리 도입 시점을 명확히 구분합니다.
• Zustand(Flux)와 Jotai(Atomic)의 패러다임 차이를 기술적으로 비교합니다.
• 불필요한 리렌더링을 방지하는 'Selector' 최적화 원리를 설명합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. Props Drilling

컴포넌트 트리 상단에서 하단으로 데이터를 전달하기 위해, 중간 컴포넌트들이 사용하지도 않는 Props를 단순히 전달만 하는 현상입니다. 코드의 가독성과 유지보수성을 크게 해칩니다.

2. Flux 아키텍처

데이터가 한 방향으로만 흐르도록 강제하는 디자인 패턴입니다. Action → Dispatcher → Store → View 순으로 데이터가 흐르며, 예측 가능한 상태 업데이트를 가능하게 합니다. (Redux, Zustand의 근간)

3. 원자적 상태 (Atomic State)

거대한 하나의 상점(Store) 대신, 작은 단위의 상태(Atom)들을 독립적으로 정의하고 조합하는 방식입니다. 필요한 컴포넌트만 해당 Atom을 구독하므로 리렌더링 최적화에 유리합니다. (Jotai, Recoil)

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

• 🐣 영철 (중반): "영호 님! '영수네 테마 설정' 하나 바꾸는데 전체 페이지가 다시 렌더링돼요. Context API만 쓰면 간단할 줄 알았는데, 어디까지 Context로 처리해야 할지 모르겠습니다."
• 🦁 영호 (리드): "영철 님, Context는 값을 깊은 트리로 전달하는 데 강하지만, 자주 바뀌는 값의 세밀한 구독까지 자동으로 해결해 주지는 않습니다. 도구의 이름보다 그 도구가 해결하려는 '변화 범위'를 먼저 보세요."

면접 질문 1. Context API와 전역 상태 관리 라이브러리(Zustand, Jotai 등)의 근본적인 차이는 무엇인가요?

🎯 출제 의도

Context API가 만능이 아님을 인지하고 있는지, 그리고 대규모 애플리케이션에서 발생하는 리렌더링 비용과 구독 최적화 전략을 이해하고 있는지 확인합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 모든 데이터를 하나의 거대한 Context에 몰아넣었습니다.

// 🐣 영철: "Context 하나만 있으면 어디서든 꺼내 쓸 수 있으니 편해요!"
const AppContext = createContext();
 
function AppProvider({ children }) {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  const [posts, setPosts] = useState([]); // ⚠️ 연관 없는 데이터들이 하나에 묶임
 
  return (
    <AppContext.Provider value={{ user, theme, posts }}>
      {children}
    </AppContext.Provider>
  );
}
 
// ⚠️ 버그: user 정보만 바뀌어도 posts를 사용하는 컴포넌트까지 모두 리렌더링됨

🦁 영호의 리뷰 포인트
"영철 님, Context는 값을 배달해 주는 '택배 기사'일 뿐이에요. 상자가 하나면, 안에 있는 물건 중 하나만 바뀌어도 상자 전체를 다시 배달해야 하죠. 라이브러리들은 이 '상자'를 잘게 쪼개거나, 필요한 물건만 쏙 골라내는 기능을 제공합니다."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 Zustand를 활용해 관심사별로 스토어를 분리하고 최적화하는 법을 보여줍니다.

// 🦁 영호: "관심사를 분리하고, 필요한 상태만 구독(Subscribe)하세요."
 
// Zustand: Flux 패턴 기반의 가벼운 스토어
const useThemeStore = create((set) => ({
  theme: 'light',
  toggleTheme: () => set((state) => ({ theme: state.theme === 'light' ? 'dark' : 'light' })),
}));
 
function ThemeButton() {
  // ✅ Selector를 사용하여 theme만 구독. 다른 상태가 바뀌어도 여기는 안전함!
  const theme = useThemeStore((state) => state.theme);
  const toggleTheme = useThemeStore((state) => state.toggleTheme);
 
  return <button onClick={toggleTheme}>{theme} 모드</button>;
}

Context도 작은 Provider로 나누고 value를 안정화하면 충분히 좋은 선택이 될 수 있습니다. 전역 상태 라이브러리는 "Context가 나쁘다"가 아니라 변경 빈도와 구독 단위가 더 세밀한 도구를 요구할 때 도입합니다.

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "Context API는 리액트 내장 기능이고, 라이브러리는 추가 설치가 필요합니다. Context는 데이터가 많아지면 성능이 떨어질 수 있습니다."
• Level 2 (Senior): "Context API는 '상태 전파'를 담당하며, 하위 컴포넌트의 리렌더링을 방지하려면 useMemo나 Context 쪼개기(Splitting)가 필요함을 설명합니다. 외부 상태 라이브러리는 '발행-구독(Pub-Sub)' 모델을 통해 리액트 밖에서 상태를 관리하며 최적화된 리렌더링을 제공함을 언급합니다."
• Level 3 (Specialist): "동시성 모드(Concurrent Mode)에서의 'Tearing' 문제를 해결하기 위해 라이브러리들이 useSyncExternalStore를 어떻게 활용하는지 설명합니다. 또한 Zustand의 가벼운 번들 사이즈와 Jotai의 Bottom-up 방식이 실제 대규모 프로젝트 아키텍처에서 어떤 트레이드오프를 갖는지 분석합니다."

면접 질문 2. Flux 아키텍처의 핵심 원리와, 왜 리액트 생태계에서 이 패턴이 주류가 되었는지 설명해 보세요.

🎯 출제 의도

데이터 흐름의 예측 가능성(Predictability)이 대규모 앱에서 왜 중요한지, 그리고 복잡한 상태 업데이트를 추적하기 위한 설계 능력을 확인합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 여러 컴포넌트에서 서로의 상태를 직접 수정하는 구조에 빠졌습니다.

// 🐣 영철: "A 컴포넌트에서 B 컴포넌트 함수를 직접 호출해서 상태를 바꿀게요!"
function ComponentA({ updateB }) {
  return <button onClick={() => updateB('새로운 값')}>B 바꾸기</button>;
}
 
// ⚠️ 결과: 데이터가 어디서 왜 바뀌었는지 추적하기 어려워짐

🦁 영호의 리뷰 포인트
"영철 님, 데이터가 여러 방향으로 바뀌면 앱이 커졌을 때 변경 원인을 찾기 어렵습니다. Flux는 '상태 변화는 정해진 경로를 따라 기록된다'는 규칙을 세워 디버깅 가능성을 높입니다."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 단방향 데이터 흐름의 정석을 설명합니다.

// 🦁 영호: "모든 변화는 'Action'이라는 기록을 남겨야 합니다."
 
// 1. Action: 어떤 변화가 일어날지 정의 (예: { type: 'ADD_POST' })
// 2. Dispatcher/Reducer: Action을 보고 어떻게 상태를 바꿀지 결정
// 3. Store: 유일한 진실의 원천 (Single Source of Truth)
// 4. View: Store의 변화를 감지하여 화면 갱신
 
// Zustand/Redux 패턴
const usePostStore = create((set) => ({
  posts: [],
  // 변화의 '이유'를 명확히 하는 액션 함수
  addPost: (newPost) => set((state) => ({ posts: [...state.posts, newPost] })),
}));

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "Flux는 데이터가 한 방향으로 흐르게 하는 패턴입니다. 예측하기 쉽다는 장점이 있습니다."
• Level 2 (Senior): "MVC 패턴의 복잡성을 해결하기 위해 등장했음을 설명합니다. 상태 업데이트 로직이 View와 분리되어 있어 테스트가 쉽고, 모든 상태 변화가 순수 함수(Reducer)와 액션 객체를 통해 일어나므로 디버깅이 용이함을 강조합니다."
• Level 3 (Specialist): "Flux 패턴의 단점인 '보일러플레이트' 문제를 Zustand가 어떻게 해결했는지(Redux 대비 단순화) 분석합니다. 또한 미들웨어(Middleware)를 통해 로깅, 영속성 저장(Persistence), 비동기 처리 등을 파이프라인 형태로 확장하는 고급 아키텍처 설계 경험을 제시합니다."

🔗 실전 변형 질문 (Related Variations)

면접 질문 45. Props Drilling을 해결하기 위한 단계별 전략은 무엇인가요?

• 🎯 출제 의도: 바로 전역 상태를 쓰기보다, 리액트답게 문제를 해결하는 합리적인 판단 능력을 확인합니다.
• 💡 핵심 원리 & 답변: 첫 번째는 **컴포넌트 합성(Component Composition)**입니다. Props를 받는 자식 대신, 자식을 children으로 넘겨 중간 컴포넌트가 존재를 모르게 만듭니다. 두 번째는 연관 있는 컴포넌트끼리 묶어 Context를 생성하는 지역적 Context 활용입니다. 전역 상태 라이브러리는 이 모든 방법으로도 해결이 안 될 만큼 '앱 전체'에서 공유가 필요할 때 최후의 수단으로 선택해야 코드의 결합도를 낮출 수 있습니다.

면접 질문 52. Zustand의 Selector를 사용할 때 객체를 직접 반환하면 발생하는 문제는 무엇인가요?

• 🎯 출제 의도: 리렌더링 조건인 '참조 동일성(Reference Identity)'을 깊이 이해하고 있는지 확인합니다.
• 💡 핵심 원리 & 답변: state => ({ a: state.a, b: state.b })처럼 매번 새로운 객체를 만들어서 반환하면, 실제 값이 같더라도 참조 주소가 계속 바뀌어 매번 리렌더링이 일어날 수 있습니다. 이를 방지하려면 개별 값을 원시 타입으로 따로 가져오거나, Zustand의 shallow 비교 또는 useShallow 같은 유틸리티로 객체 내부 값이 바뀔 때만 렌더링되게 설계해야 합니다.

면접 질문 60. 라이브러리를 쓰지 않고 리액트만으로 상태 관리 시스템을 구축한다면 어떤 구조를 제안하시겠습니까?

• 🎯 출제 의도: 도구에 의존하지 않는 순수 리액트 설계 역량을 확인합니다.
• 💡 핵심 원리 & 답변: useReducer와 useContext를 조합하여 'Mini Redux' 형태의 구조를 제안할 수 있습니다. Action과 Reducer로 로직을 정형화하고, 이를 Context를 통해 하위로 주입하는 방식입니다. 이때 성능 최적화를 위해 테마 전용 Context, 유저 정보 전용 Context 등으로 **Context를 세분화(Splitting)**하고, 필요시 컴포넌트를 React.memo로 감싸 불필요한 전파를 막는 설계가 핵심입니다.

📝 마무리 퀴즈

Q1. Context API를 상태 관리 도구처럼 남용하면 어떤 문제가 생기기 쉬운가요?

✅ 정답: Provider 값이 바뀔 때 넓은 하위 트리가 함께 다시 렌더링되어 변화 범위를 통제하기 어려워진다

💡 상세 해설:

• 원리 설명: Context는 값을 깊게 전달하는 도구이지, 세밀한 구독과 업데이트 최적화를 자동으로 제공하는 상태 관리 엔진이 아닙니다.
• 오답 피드백: "전역으로 공유된다"는 이유만으로 모든 상태를 Context에 넣으면 편해 보이지만, 렌더링 비용과 관심사 결합이 커집니다.
• 📌 핵심 기억법: 전역 접근성과 전역 업데이트는 다른 문제입니다.

Q2. Redux, Zustand, Jotai 같은 도구를 선택할 때 영호가 먼저 보라고 한 기준은 무엇인가요?

✅ 정답: 상태의 범위, 변경 빈도, 구독 단위, 팀의 디버깅/운영 요구가 도구의 철학과 맞는지 확인하는 것

💡 상세 해설:

• 원리 설명: 상태 관리 도구는 취향 문제가 아니라 변화 통제 방식입니다. Redux는 명시적 이벤트 흐름, Zustand는 간결한 store, Jotai는 atom 단위 조합에 강점이 있습니다.
• 오답 피드백: "요즘 많이 쓴다"는 도입 근거가 될 수 없습니다. 어떤 문제가 줄어드는지, 어떤 비용이 생기는지 말해야 합니다.
• 📌 핵심 기억법: 도구 선택은 인기 투표가 아니라 변화 범위 설계입니다.

Q3. 영철이의 테스트 타임: 영수네 알림 상태를 전역으로 올리기 전 확인해야 할 질문은 무엇인가요?

✅ 정답: 이 상태가 여러 화면에서 동시에 필요하고, 변경될 때 어떤 컴포넌트만 구독해야 하는지 확인한다

💡 상세 해설:

• 원리 설명: 전역 상태는 공유가 편해지는 대신 변경 영향도 커집니다. 구독 단위를 작게 만들 수 있는지, 서버 상태와 섞이지 않는지 먼저 봐야 합니다.
• 오답 피드백: props drilling이 한두 단계 있다는 이유만으로 전역 store를 만들면 구조가 더 커질 수 있습니다.
• 📌 핵심 기억법: 상태를 올리기 전에 영향 범위를 그립니다.

🐣 영철이의 퇴근 일기

오늘은 상태 관리 도구 이름을 많이 아는 것보다, 상태가 왜 바뀌고 어디까지 퍼져야 하는지 설명하는 게 더 중요하다는 걸 배웠다. 예전의 나는 Context에 넣으면 깔끔하다고 생각했는데, 사실은 변화 범위를 화면 전체로 넓히고 있었을지도 모른다.

💡 "상태 관리는 값을 보관하는 기술이 아니라, 변화가 퍼지는 범위를 설계하는 일이다."

다음 리뷰에서는 "이거 전역으로 빼죠"라고 말하기 전에, 어떤 컴포넌트가 구독해야 하고 어떤 컴포넌트는 몰라도 되는지 먼저 그려봐야겠다. 영철이 이제 도구보다 흐름을 먼저 묻는 쪽으로 조금 자라고 있다.