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 호출, 정렬 로직, 필터 로직이 섞여 있어서 하나를 바꾸면 예상 밖의 화면까지 영향을 받아요."
• 🦁 영호 (리드): "영철 님, 이제는 코드 길이보다 변화 이유를 봐야 합니다. 컴포넌트는 화면 표현에 집중하고, 데이터 흐름과 부수효과는 이름 있는 훅으로 분리해 봅시다."

면접 질문 1. 관심사의 분리를 위해 비즈니스 로직을 커스텀 훅으로 추출할 때, 뷰(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([]);
  // 네트워크 요청과 에러/로딩 처리는 이 훅 안에서 한 곳에 모은다.
  // 그러면 화면 컴포넌트는 데이터가 어디서 오는지 몰라도 된다.
 
  const processUsers = (data) => {
    return data
      .toSorted((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>
  );
}

sort는 원본 배열을 변경하므로 서버 응답이나 캐시 데이터를 그대로 다룰 때 부작용을 만들 수 있습니다. 예시처럼 toSorted 또는 복사 후 정렬을 사용하면 훅 내부에서도 불변성을 지킬 수 있습니다.

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

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

면접 질문 2. 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,
  getServerSnapshot: () => 0,
};
 
function useWindowWidth() {
  // ✅ 리액트에게 '이 값은 외부에서 오니까 렌더링 중에 바뀌면 중단해!'라고 알려줌
  return useSyncExternalStore(
    widthStore.subscribe,
    widthStore.getSnapshot,
    widthStore.getServerSnapshot
  );
}

SSR 환경에서는 window가 없으므로 서버용 snapshot을 따로 제공해야 합니다. 실제 서비스에서는 0 대신 레이아웃이 흔들리지 않는 기본값을 정하고, 클라이언트에서 첫 구독 이후 실제 너비로 동기화하는 전략을 세웁니다.

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

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

🔗 실전 변형 질문 (Related Variations)

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

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

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

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

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

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

📝 마무리 퀴즈

Q1. 커스텀 훅으로 로직을 분리할 때 가장 먼저 확인해야 할 기준은 무엇인가요?

✅ 정답: UI 렌더링 책임과 데이터/상태/이벤트 흐름 책임이 명확히 분리되는지 확인하는 것

💡 상세 해설:

• 원리 설명: 커스텀 훅은 코드 줄 수를 줄이는 도구가 아니라, 컴포넌트가 화면 표현에 집중하도록 경계를 나누는 설계 도구입니다.
• 오답 피드백: 단순히 모든 함수를 useSomething으로 빼면 오히려 의존성과 부수효과가 숨어 테스트하기 어려워질 수 있습니다.
• 📌 핵심 기억법: 훅은 숨기는 곳이 아니라 책임을 이름 붙이는 곳입니다.

Q2. useSyncExternalStore가 필요한 대표적인 이유는 무엇인가요?

✅ 정답: 동시성 렌더링 중 외부 스토어 값이 바뀌어 화면 일부가 서로 다른 상태를 보여주는 테어링을 막기 위해서

💡 상세 해설:

• 원리 설명: React 외부 스토어를 직접 구독하면 렌더링 중간에 값이 바뀌었을 때 일관성이 깨질 수 있습니다. useSyncExternalStore는 구독과 snapshot 읽기 계약을 React와 맞춥니다.
• 오답 피드백: 단순히 useEffect로 subscribe/unsubscribe를 구현하면 동시성 환경의 snapshot 일관성을 보장하지 못합니다.
• 📌 핵심 기억법: 외부 상태는 React와 읽는 약속을 맞춰야 합니다.

Q3. 영철이의 테스트 타임: 커스텀 훅을 만들기 전 영호가 물어볼 질문은 무엇일까요?

✅ 정답: 이 훅이 화면 표현을 숨기는지, 아니면 재사용 가능한 상태 전이와 부수효과 경계를 분리하는지 확인한다

💡 상세 해설:

• 원리 설명: 좋은 훅은 호출하는 컴포넌트가 "무엇을 보여줄지"에 집중하게 만들고, 네트워크/스토어/이벤트 같은 변화의 경계를 테스트 가능한 단위로 묶습니다.
• 오답 피드백: 비슷한 코드가 두 번 나왔다고 바로 훅으로 빼면, 오히려 변화 이유가 다른 로직을 무리하게 결합할 수 있습니다.
• 📌 핵심 기억법: 재사용보다 먼저 책임의 경계를 봅니다.

🐣 영철이의 퇴근 일기

오늘은 커스텀 훅을 "중복 제거용 폴더"처럼 쓰던 생각을 고쳤다. 영호 님이 같은 코드라도 변화 이유가 다르면 분리하지 말라고 했을 때는 조금 당황했지만, 이제는 훅이 책임의 이름이라는 말이 이해된다.

💡 "좋은 훅은 코드를 숨기는 게 아니라, 변화가 일어나는 경계를 드러낸다."

내일부터 외부 스토어를 직접 구독하는 코드를 보면 useEffect가 아니라 snapshot 일관성부터 떠올려야겠다. 이제 나는 단순히 훅을 많이 아는 사람이 아니라, 훅이 팀 코드의 경계를 어떻게 바꾸는지 설명할 수 있는 사람이 되어가는 중이다.