05. 🪝 리액트 훅과 관심사 분리 설계

📌 이 면접 항목의 목표

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

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: 로직 분리 기준] → [질문 2: useSyncExternalStore] → [실전 변형 질문]

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

• 뷰(View)와 비즈니스 로직을 분리하는 명확한 기준을 세울 수 있습니다.
• useSyncExternalStore를 사용해 외부 상태를 안전하게 구독하는 법을 이해합니다.
• HOC와 커스텀 훅 패턴의 적재적소 활용법을 논리적으로 비교합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. 관심사 분리 (Separation of Concerns, SoC)

하나의 컴포넌트나 함수가 하나의 목적에만 집중하도록 만드는 설계 원칙입니다. 리액트에서는 주로 UI를 담당하는 뷰와 데이터를 처리하는 로직을 분리하는 데 집중합니다.

2. 테어링 (Tearing)

동시성 렌더링 환경에서 화면의 여러 부분이 서로 다른 시점의 상태를 보여주는 시각적 불일치 현상입니다. 렌더링 도중 외부 상태(Store 등)가 바뀌어 발생합니다.

3. 고차 컴포넌트 (Higher-Order Component, HOC)

컴포넌트를 인자로 받아 새로운 기능을 추가한 컴포넌트를 반환하는 패턴입니다. 훅이 등장하기 전 로직 재사용의 핵심이었으며, 현재는 로깅이나 권한 체크 등 UI를 감싸는 로직에 주로 쓰입니다.

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

• 🐣 영철 ( 신입 ): "영호 님! '영수네 대시보드' 컴포넌트가 500줄이 넘어가서 도저히 못 고치겠어요. 안에 API 호출, 정렬 로직, 필터 로직이 다 섞여 있어서 하나 바꾸면 다 터져요! 😭"
• 🦁 영호 ( 리드 ): "영철 님, 그게 바로 '스파게티 컴포넌트'의 전형입니다. 컴포넌트는 UI만 그려야 해요. 계산기 엔진이랑 껍데기를 분리하지 않으면 평생 유지보수의 늪에서 못 나올 겁니다. 자, 커스텀 훅으로 '뇌'를 추출해 봅시다."

Q1. 관심사의 분리를 위해 비즈니스 로직을 커스텀 훅으로 추출할 때, 뷰(View)와 로직을 분리하는 기준은 무엇인가요?

🎯 출제 의도

코드를 단순히 옮기는 행위를 넘어, 컴포넌트의 책임을 어떻게 정의하는지 그리고 재사용성과 테스트 용이성을 고려한 설계 철학이 있는지 확인합니다.

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

영철이는 컴포넌트 안에 모든 것을 다 때려 박았습니다.

// 🐣 영철: "찾아보기 편하게 한 파일에 다 모아놨어요!"
function UserDashboard() {
  const [data, setData] = useState([]);
  
  useEffect(() => {
    // ⚠️ API 호출 로직 직접 노출
    fetch('/api/users').then(res => res.json()).then(setData);
  }, []);
 
  // ⚠️ 복잡한 필터/정렬 로직 직접 노출
  const sortedData = [...data].sort((a, b) => b.score - a.score);
  const activeUsers = sortedData.filter(u => u.isActive);
 
  return (
    <div>
      {activeUsers.map(user => <UserItem key={user.id} {...user} />)}
    </div>
  );
}

🦁 영호의 팩폭 조언
"영철 님, 이렇게 짜면 '데이터 필터링 로직'만 따로 테스트하고 싶을 때 컴포넌트 전체를 렌더링해야 해요. 컴포넌트는 데이터를 받아서 그림을 그리는 것에만 집중해야 합니다. 나머지는 다 훅으로 유배 보내세요."

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

영호 리드는 비즈니스 로직을 useUserBoard라는 커스텀 훅으로 분리합니다.

// 🦁 영호: "컴포넌트는 UI 명세서여야 합니다. 상세 로직은 훅이라는 하청업체에 맡기세요."
 
// 🧠 Business Logic Hook
function useUserBoard() {
  const [users, setUsers] = useState([]);
  // ... fetch users로직
  
  const processUsers = (data) => {
    return data
      .sort((a, b) => b.score - a.score)
      .filter(u => u.isActive);
  };
 
  return { users: processUsers(users) };
}
 
// 🖼️ View Component
function UserDashboard() {
  const { users } = useUserBoard(); // 🪄 마법처럼 데이터만 쏙!
 
  return (
    <div>
      {users.map(user => <UserItem key={user.id} {...user} />)}
    </div>
  );
}

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

• Level 1 (Junior): "재사용하고 싶은 로직이 생기면 커스텀 훅으로 만듭니다. 컴포넌트 코드가 너무 길어질 때도 분리합니다."
• Level 2 (Senior): "데이터 페칭, 상태 관리, 복잡한 연산 등 '도메인 로직'과 'UI 렌더링'을 분리하는 기준을 설명합니다. 이를 통해 UI 변경 없이 로직만 독립적으로 단위 테스트(Unit Test)를 가능하게 함을 강조합니다."
• Level 3 (Specialist): "'Headless Component' 패턴이나 'Hook 기반 아키텍처'를 언급합니다. UI 프리젠테이션과 상태 관리 엔진을 완전히 격리하여, 웹뿐만 아니라 앱(React Native) 등 다른 플랫폼에서도 동일한 비즈니스 로직 훅을 공유할 수 있는 확장성 있는 구조를 제안합니다."

Q2. useSyncExternalStore 훅이 도입된 배경과, 테어링(Tearing) 현상을 방지하는 원리는 무엇인가요?

🎯 출제 의도

React 18 동시성 모드에서 발생할 수 있는 미묘한 시각적 버그를 이해하고, 외부 라이브러리(Redux, Zustand 등)가 리액트 스케줄러와 어떻게 협업하는지 깊이 있게 아는지 확인합니다.

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

영철이는 window.innerWidth를 전역 상태처럼 쓰기 위해 단순한 useEffect를 썼다가 레이아웃이 찢어지는 현상을 발견했습니다.

// 🐣 영철: "그냥 useEffect로 값 감시하면 되는 거 아닌가요?"
function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);
  
  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);
    return () => window.removeEventListener('resize', handleResize);
  }, []);
 
  return width; // ⚠️ 동시성 모드에서 여러 컴포넌트가 서로 다른 width를 읽을 위험(Tearing) 있음
}

🦁 영호의 팩폭 조언
"영철 님, 리액트 18의 동시성 렌더링은 도중에 멈출 수 있어요. 렌더링 1단계에서 A 컴포넌트가 width를 읽고, 그 사이에 리사이즈가 발생한 뒤 2단계에서 B 컴포넌트가 읽으면 화면이 짝짝이가 됩니다. 이걸 막으라고 만든 게 useSyncExternalStore입니다."

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

영호 리드가 안전한 외부 상태 구독 방식을 제안합니다.

// 🦁 영호: "외부 상태는 리액트의 렌더링 속도와 맞지 않을 수 있습니다. 강제로 동기화하세요."
 
const widthStore = {
  subscribe: (cb) => {
    window.addEventListener('resize', cb);
    return () => window.removeEventListener('resize', cb);
  },
  getSnapshot: () => window.innerWidth,
};
 
function useWindowWidth() {
  // ✅ 리액트에게 '이 값은 외부에서 오니까 렌더링 중에 바뀌면 중단해!'라고 알려줌
  return useSyncExternalStore(
    widthStore.subscribe,
    widthStore.getSnapshot
  );
}

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

• Level 1 (Junior): "외부 상태(Redux 등)를 리액트와 연결해 주는 훅입니다. 값이 바뀌면 리렌더링해 줍니다."
• Level 2 (Senior): "동시성 렌더링은 작업을 쪼개어 처리하는데, 그 사이 외부 상태가 변하면 시각적 불일치(Tearing)가 발생함을 설명합니다. useSyncExternalStore는 읽기 작업의 일관성을 보장하기 위해 도입되었음을 언급합니다."
• Level 3 (Specialist): "이 훅이 원자적(Atomic) 업데이트를 어떻게 보장하는지 내부 메커니즘을 설명합니다. 렌더링 중 외부 값이 변하면 다시 렌더링을 시도하거나 동기식 업데이트로 전환하여 사용자에게 항상 일관된 스냅샷을 보여주는 '일관성 보장' 전략을 분석합니다."

🔗 실전 변형 질문 (Related Variations)

Q182. 고차 컴포넌트(HOC) 패턴과 커스텀 훅 패턴의 장단점을 비교해 보세요.

• 🎯 출제 의도: 리액트의 로직 재사용 패턴 변천사를 이해하고, 상황에 맞는 가장 적절한 도구를 선택할 수 있는지 확인합니다.
• 💡 핵심 원리 & 답변: 커스텀 훅은 함수형 컴포넌트의 흐름 안에서 상태와 로직을 매우 유연하게 조합할 수 있어 현재 리액트의 표준입니다. 반면, HOC는 원본 컴포넌트를 감싸는 구조 특성상 Props가 어디서 오는지 불명확해지는 'Props Drilling'이나 '이름 충돌' 문제가 발생하기 쉽습니다. 하지만 인증 체크나 로깅처럼 UI 자체를 감싸거나 주입해야 하는 시각적인 횡단 관심사(Cross-cutting Concerns)에는 여전히 HOC가 선언적이고 깔끔한 대안이 될 수 있습니다.

Q249. 리액트에서 디바운스(Debounce)와 쓰로틀(Throttle)을 적용할 때 주의할 점은 무엇인가요?

• 🎯 출제 의도: 리렌더링 시마다 함수가 새로 생성되는 리액트의 특성과 타이머 메커니즘 간의 충돌을 방어할 수 있는지 확인합니다.
• 💡 핵심 원리 & 답변: 리액트 컴포넌트가 리렌더링될 때마다 정의된 함수는 새로 생성됩니다. 단순하게 lodash.debounce를 함수 안에 선언하면 리렌더링마다 새로운 타이머가 생겨 제 기능을 못 하게 됩니다. 이를 해결하려면 useMemo나 useCallback으로 디바운스된 함수 인스턴스를 유지하거나, useRef를 사용하여 렌더링 사이클과 무관하게 타이머 상태를 보존해야 합니다. 또한 컴포넌트 언마운트 시 반드시 cancel을 호출하여 메모리 누수와 예상치 못한 상태 업데이트를 방지해야 합니다.

Q258. 로컬 스토리지 동기화 훅을 설계할 때 SSR 환경의 'window is not defined' 에러를 어떻게 해결하나요?

• 🎯 출제 의도: 유니버설(Universal) 자바스크립트 실행 환경에 대한 이해와 Next.js 등 SSR 프레임워크에서의 예외 처리를 확인합니다.
• 💡 핵심 원리 & 답변: 서버 사이드 렌더링 시에는 브라우저 객체인 window가 존재하지 않습니다. 따라서 useState의 초기값으로 스토리지를 직접 읽으려 하면 에러가 납니다. 해결책으로는 useEffect 내에서만 window에 접근하여 런타임에 값을 설정하거나, typeof window !== 'undefined' 조건문으로 가드 로직을 작성해야 합니다. 또한 최신 리액트에서는 useSyncExternalStore의 세 번째 인자인 getServerSnapshot을 활용하여 서버용 기본값을 따로 제공함으로써 하이드레이션 불일치(Hydration Mismatch)를 방지할 수 있습니다.

🐣 영철이의 복기 일기

오늘 '테어링'이라는 말을 처음 들었는데, 화면이 찢어진다는 표현이 너무 무섭게 다가왔다. 그동안 내가 만든 전역 상태 구독 로직들이 이 위험에 노출되어 있었다니... 리액트가 왜 useSyncExternalStore라는 괴상한 이름의 훅을 만들었는지 이제야 이해가 간다.

💡 "컴포넌트에서 중요한 건 무엇을 그리느냐가 아니라, 무엇을 그리지 않기로 결정하느냐에 있다."

내일은 상태 관리의 전쟁터, 'Flux 아키텍처와 전역 상태'를 공부한다. Redux부터 Zustand까지, 이 수많은 도구들 중에서 우리 영수네 커뮤니티에 딱 맞는 칼을 골라내야지! ⚔️🛡️