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 API는 '상태 관리' 도구가 아니라 '의존성 주입' 도구입니다. 전역적으로 값을 공유하는 데는 좋지만, 빈번하게 바뀌는 데이터에는 쥐약이죠. 도구의 이름보다 그 도구가 해결하려는 '진짜 문제'를 보세요."

Q1. 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>;
}

📊 레벨별 답변 가이드 (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 방식이 실제 대규모 프로젝트 아키텍처에서 어떤 트레이드오프를 갖는지 분석합니다."

Q2. 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)

Q45. Props Drilling을 해결하기 위한 단계별 전략은 무엇인가요?

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

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

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

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

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

🐣 영철이의 복기 일기

오늘 'Context는 상태 관리가 아니다'라는 영호 님의 말씀에 머리를 한 대 맞은 기분이다. 그동안 나는 예쁜 상자에 쓰레기(?)를 가득 담아 페이지 전체에 뿌리고 있었다. Zustand로 스토어를 쪼개고 나니 코드는 간결해지고, 개발자 도구의 리렌더링 하이라이트가 잠잠해지는 걸 보니 마음이 평온해졌다.

💡 "상태 관리는 단순히 값을 저장하는 것이 아니라, 변화의 범위를 통제하는 예술이다."

내일은 클라이언트와 서버 사이의 가교, 'Data Fetching과 서버 상태'를 배울 차례다. 비동기 데이터는 또 어떤 복잡함으로 나를 괴롭힐지 기대된다! 📡💨