React 리드·아키텍트 기술면접
새 면접Q. React의 Fiber 아키텍처가 도입된 배경과 핵심 동작 원리를 설명하고, 기존 Stack Reconciler와 비교했을 때 어떤 문제를 해결했는지 구체적으로 설명해주세요.
동기적 렌더링의 한계와 작업 단위의 중단 가능성을 중심으로 생각해보세요.
Fiber 아키텍처는 React 16에서 도입된 새로운 재조정(Reconciliation) 엔진으로, 기존 Stack Reconciler의 동기적이고 중단 불가능한 렌더링 문제를 해결했습니다. Fiber는 각 컴포넌트를 작은 작업 단위로 분할하여 우선순위를 부여하고, 브라우저의 유휴 시간을 활용해 작업을 중단하거나 재개할 수 있게 합니다. 이를 통해 애니메이션이나 사용자 입력 같은 고우선순위 작업을 먼저 처리하고, 렌더링 작업을 여러 프레임에 분산시켜 메인 스레드 블로킹을 방지합니다. Fiber는 linked list 구조로 구현되어 부모-자식-형제 관계를 추적하며, requestIdleCallback과 유사한 스케줄링 메커니즘을 사용합니다. 결과적으로 대규모 컴포넌트 트리에서도 60fps를 유지하며 부드러운 사용자 경험을 제공할 수 있게 되었습니다.
- • 작업 단위를 분할하여 중단 및 재개가 가능한 구조
- • 우선순위 기반 스케줄링으로 중요한 업데이트 우선 처리
- • 메인 스레드 블로킹 방지로 60fps 유지
대규모 데이터 테이블이나 복잡한 대시보드에서 사용자 입력 반응성을 유지하면서 백그라운드 렌더링을 수행할 때 활용됩니다.
Concurrent Mode에서 useTransition과 useDeferredValue가 Fiber 아키텍처를 어떻게 활용하는지 설명해주실 수 있나요?
Q. 수만 개의 아이템을 렌더링해야 하는 대규모 리스트 컴포넌트의 성능을 최적화하기 위한 전략을 설계한다면, 어떤 기법들을 조합하여 사용하시겠습니까? 각 기법의 트레이드오프도 함께 설명해주세요.
가상화, 메모이제이션, 렌더링 최적화, 데이터 페칭 전략을 종합적으로 고려해보세요.
대규모 리스트 최적화는 가상 스크롤링을 핵심으로 하되 여러 기법을 조합해야 합니다. 첫째, react-window나 react-virtualized를 사용한 windowing으로 뷰포트에 보이는 아이템만 렌더링하여 DOM 노드 수를 줄입니다. 둘째, 각 리스트 아이템을 React.memo로 래핑하고 key를 안정적으로 유지하여 불필요한 리렌더링을 방지합니다. 셋째, Intersection Observer API를 활용한 무한 스크롤과 청크 단위 데이터 로딩으로 초기 로드 시간을 단축합니다. 넷째, useMemo와 useCallback으로 이벤트 핸들러와 계산 비용이 높은 값을 메모이제이션합니다. 트레이드오프로는 가상 스크롤링 시 스크롤바 정확도 문제, 메모이제이션의 메모리 오버헤드, 그리고 복잡도 증가에 따른 유지보수 비용이 있으며, 실제 데이터 크기와 업데이트 빈도를 측정하여 필요한 최적화만 선택적으로 적용해야 합니다.
- • 가상 스크롤링으로 DOM 노드 수 최소화
- • 메모이제이션과 안정적인 key로 리렌더링 방지
- • 데이터 로딩 전략과 최적화 기법의 트레이드오프 이해
전자상거래 사이트의 상품 목록, 소셜 미디어 피드, 관리자 대시보드의 대용량 데이터 테이블에서 필수적으로 적용됩니다.
가상 스크롤링을 사용할 때 동적 높이를 가진 아이템들을 어떻게 처리하시겠습니까?
Q. 대규모 엔터프라이즈 애플리케이션에서 Context API, Redux, Zustand, Jotai 같은 다양한 상태 관리 솔루션 중 어떤 기준으로 선택하시겠습니까? 각 솔루션의 적합한 사용 사례와 조직적 고려사항을 포함해 설명해주세요.
애플리케이션 규모, 팀 구성, 상태의 특성, 성능 요구사항을 기준으로 분류해보세요.
상태 관리 솔루션 선택은 상태의 특성과 조직 상황에 따라 달라집니다. Context API는 테마나 인증 정보 같은 저빈도 업데이트 전역 상태에 적합하지만, 잦은 업데이트 시 불필요한 리렌더링이 발생합니다. Redux는 복잡한 비즈니스 로직, 시간 여행 디버깅, 미들웨어 생태계가 필요한 대규모 애플리케이션에 적합하나 보일러플레이트가 많고 학습 곡선이 높습니다. Zustand는 간결한 API와 좋은 성능으로 중소규모 프로젝트나 Redux 마이그레이션에 적합하며, Jotai나 Recoil은 원자적 상태 관리로 세밀한 최적화가 필요한 경우 유용합니다. 조직적으로는 팀의 기존 경험, 채용 시장의 인력 풀, 장기 유지보수 관점을 고려해야 하며, 실제로는 여러 솔루션을 상태 특성별로 조합하는 하이브리드 접근이 효과적입니다.
- • 상태의 업데이트 빈도와 범위에 따른 솔루션 선택
- • 팀의 학습 곡선과 장기 유지보수 비용 고려
- • 단일 솔루션보다 상태 특성별 하이브리드 접근
레거시 Redux 애플리케이션을 현대적 상태 관리로 점진적 마이그레이션하거나, 신규 프로젝트의 기술 스택을 결정할 때 적용됩니다.
서버 상태와 클라이언트 상태를 분리하여 관리할 때 React Query나 SWR을 어떻게 통합하시겠습니까?
Q. React Server Components의 동작 원리와 기존 SSR과의 근본적인 차이점을 설명하고, 실제 프로덕션 환경에 도입할 때 고려해야 할 아키텍처 설계 포인트를 제시해주세요.
컴포넌트 실행 위치, 번들 크기, 데이터 페칭 방식의 차이를 중심으로 생각해보세요.
React Server Components(RSC)는 서버에서만 실행되는 컴포넌트로, 기존 SSR이 초기 HTML 생성 후 클라이언트에서 hydration하는 것과 달리 서버 컴포넌트 코드 자체가 클라이언트 번들에 포함되지 않습니다. RSC는 직렬화된 스트림 형태로 클라이언트에 전송되며, 클라이언트 컴포넌트와 서버 컴포넌트를 트리 구조로 조합할 수 있습니다. 데이터베이스 직접 접근이나 파일 시스템 사용이 가능하며, async/await를 자연스럽게 사용해 데이터 페칭의 waterfall 문제를 해결합니다. 프로덕션 도입 시 고려사항으로는 서버-클라이언트 경계 설정 전략, 캐싱 레이어 설계, 서버 인프라 확장성, props로 전달 가능한 데이터 타입 제약(직렬화 가능 데이터만), 그리고 기존 클라이언트 중심 라이브러리와의 호환성 문제가 있습니다. Next.js App Router 같은 프레임워크를 활용하면 라우팅과 통합된 RSC 아키텍처를 구축할 수 있습니다.
- • 서버 컴포넌트 코드가 클라이언트 번들에서 제외되어 번들 크기 감소
- • 서버에서 직접 데이터 페칭하여 waterfall 문제 해결
- • 서버-클라이언트 경계와 직렬화 제약 이해 필요
대용량 데이터를 다루는 대시보드나 SEO가 중요한 콘텐츠 사이트에서 초기 로드 성능과 번들 크기를 최적화할 때 사용됩니다.
Server Components와 Client Components를 효과적으로 조합하는 패턴과 안티패턴을 설명해주실 수 있나요?
Q. React의 Reconciliation 알고리즘이 어떻게 동작하는지 설명하고, key prop이 리스트 렌더링 성능에 미치는 영향을 내부 동작 원리 관점에서 상세히 설명해주세요.
Virtual DOM 비교 과정과 휴리스틱 알고리즘의 가정들을 중심으로 설명해보세요.
React의 Reconciliation은 이전 Virtual DOM 트리와 새 트리를 비교하여 최소한의 DOM 조작을 찾는 과정입니다. 일반적인 트리 diff 알고리즘은 O(n³) 복잡도를 가지지만, React는 두 가지 가정을 통해 O(n)으로 최적화합니다. 첫째, 다른 타입의 엘리먼트는 다른 트리를 생성하므로 비교하지 않고 교체하며, 둘째, key prop으로 자식 엘리먼트의 동일성을 판단합니다. 리스트 렌더링에서 key가 없거나 index를 사용하면 React는 위치 기반으로 비교하여 중간 삽입 시 이후 모든 엘리먼트를 다시 렌더링합니다. 반면 안정적이고 유일한 key를 사용하면 엘리먼트의 정체성을 추적하여 실제로 변경된 항목만 업데이트하고, 순서 변경 시에도 DOM 노드를 재사용할 수 있습니다. 특히 복잡한 자식 컴포넌트나 상태를 가진 컴포넌트에서 key의 영향이 크며, key 변경은 컴포넌트를 완전히 재생성하므로 의도적인 리셋에도 활용됩니다.
- • O(n³)을 O(n)으로 최적화하는 휴리스틱 알고리즘
- • key로 엘리먼트 정체성을 추적하여 최소 DOM 조작
- • index를 key로 사용 시 중간 삽입에서 성능 저하
드래그 앤 드롭으로 순서를 변경하는 리스트나 필터링되는 대규모 데이터 테이블에서 렌더링 성능을 최적화할 때 중요합니다.
key를 변경하여 컴포넌트를 강제로 리셋하는 패턴의 적절한 사용 사례와 주의점은 무엇인가요?
Q. Custom Hook을 설계할 때 단일 책임 원칙, 재사용성, 테스트 가능성을 고려한 설계 원칙과 안티패턴을 설명해주세요. 특히 복잡한 비즈니스 로직을 Hook으로 추상화할 때의 접근 방법을 제시해주세요.
Hook의 조합 가능성, 의존성 관리, 관심사 분리를 중심으로 생각해보세요.
Custom Hook 설계는 단일 책임 원칙에 따라 하나의 명확한 목적을 가져야 하며, 작은 Hook들을 조합하는 방식으로 복잡한 로직을 구성해야 합니다. useEffect의 의존성 배열을 정확히 관리하고, 불필요한 재실행을 방지하기 위해 useCallback과 useMemo를 적절히 활용합니다. 비즈니스 로직과 UI 로직을 분리하여 Hook은 상태와 부수효과만 관리하고, 렌더링 로직은 컴포넌트에 위임합니다. 반환값은 배열보다 객체 구조로 제공하여 선택적 사용이 가능하게 하고, 옵션 객체 패턴으로 확장성을 확보합니다. 안티패턴으로는 과도한 추상화로 인한 복잡도 증가, Hook 내부에서 다른 Hook을 조건부로 호출, 너무 많은 책임을 가진 God Hook, 그리고 테스트하기 어려운 강한 결합 구조가 있습니다. 테스트 가능성을 위해 외부 의존성은 주입받고, @testing-library/react-hooks를 활용한 단위 테스트를 작성합니다.
- • 단일 책임과 작은 Hook 조합으로 복잡도 관리
- • 의존성 배열 정확한 관리와 불필요한 재실행 방지
- • 비즈니스 로직과 UI 분리, 테스트 가능한 구조
인증, 데이터 페칭, 폼 관리 같은 반복되는 로직을 재사용 가능한 Hook으로 추상화하여 코드 중복을 줄이고 유지보수성을 높일 때 사용됩니다.
여러 컴포넌트에서 공유하는 복잡한 폼 로직을 Custom Hook으로 추상화한다면 어떤 구조로 설계하시겠습니까?
Q. 레거시 Class 컴포넌트 기반의 대규모 React 애플리케이션을 Function 컴포넌트와 Hooks로 점진적으로 마이그레이션하는 전략을 수립한다면, 어떤 단계와 우선순위로 진행하시겠습니까? 리스크 관리 방안도 포함해서 설명해주세요.
비즈니스 영향도, 기술 부채, 팀 역량, 점진적 전환 가능성을 종합적으로 고려해보세요.
레거시 마이그레이션은 비즈니스 연속성을 보장하며 점진적으로 진행해야 합니다. 첫 단계로 신규 기능은 Function 컴포넌트로만 개발하는 정책을 수립하고, 두 번째로 리프 노드부터 시작해 의존성이 적은 프레젠테이셔널 컴포넌트를 우선 마이그레이션합니다. 세 번째로 공통 컴포넌트와 유틸리티를 전환하여 재사용성을 높이고, 네 번째로 핵심 비즈니스 로직을 담은 컨테이너 컴포넌트를 단계적으로 전환합니다. Lifecycle 메서드는 useEffect로, HOC 패턴은 Custom Hook으로, Render Props는 Hook 조합으로 대체하되, 각 패턴의 동작을 정확히 이해하고 전환해야 합니다. 리스크 관리를 위해 충분한 테스트 커버리지 확보, 기능 플래그를 활용한 점진적 배포, 성능 모니터링 대시보드 구축, 그리고 롤백 계획을 준비합니다. 팀 교육과 코드 리뷰 프로세스를 통해 일관된 품질을 유지하며, 마이그레이션 진행 상황을 정량적으로 추적합니다.
- • 리프 노드부터 점진적 마이그레이션으로 리스크 최소화
- • Lifecycle 메서드, HOC, Render Props의 정확한 Hook 전환
- • 테스트 커버리지와 기능 플래그로 안정성 확보
수년간 운영된 대규모 프로덕션 애플리케이션의 기술 부채를 해소하고 최신 React 기능을 활용하기 위한 현대화 프로젝트에서 적용됩니다.
componentDidMount와 componentDidUpdate를 useEffect로 전환할 때 흔히 발생하는 버그와 해결 방법은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!