React 시니어 CS 기초 기술면접
새 면접Q. React SPA에서 HTTP/2와 HTTP/3(QUIC)를 활용할 때의 성능 최적화 전략을 설명해주세요. 특히 멀티플렉싱, 서버 푸시, 헤더 압축 등의 기능이 번들링 전략과 리소스 로딩에 어떤 영향을 미치는지, 그리고 HTTP/1.1 시대의 베스트 프랙티스와 어떻게 달라지는지 설명해주세요.
HTTP/2의 멀티플렉싱은 하나의 TCP 연결에서 여러 요청을 동시에 처리하므로, HTTP/1.1에서 사용하던 도메인 샤딩이나 스프라이트 이미지 같은 기법이 불필요해집니다. 오히려 많은 작은 파일로 분할하여 캐싱 효율을 높이는 것이 유리하며, 서버 푸시를 활용하면 critical CSS나 필수 JS를 먼저 전송할 수 있습니다. HTTP/3는 UDP 기반 QUIC 프로토콜로 Head-of-Line Blocking 문제를 해결하여 패킷 손실 환경에서도 안정적인 성능을 제공하므로, 모바일 환경에서 특히 유리합니다. 번들 크기보다는 청크 분할과 병렬 로딩에 집중하는 전략으로 전환해야 하며, 리소스 힌트(preload, prefetch)를 적극 활용하는 것이 중요합니다.
- • HTTP/2 멀티플렉싱으로 인한 번들링 전략 변화 (작은 파일 분할이 유리)
- • 서버 푸시를 활용한 critical resource 우선 전송
- • HTTP/3 QUIC의 Head-of-Line Blocking 해결과 모바일 환경 최적화
- • 도메인 샤딩, 스프라이트 이미지 등 레거시 최적화 기법의 불필요성
HTTP/2 서버 푸시를 React 애플리케이션에 적용할 때 over-pushing 문제를 어떻게 방지할 수 있나요? Service Worker와의 상호작용은 어떻게 처리하시겠습니까?
Q. 브라우저의 멀티 프로세스 아키텍처(Multi-Process Architecture)가 React 애플리케이션의 성능에 미치는 영향을 설명해주세요. 특히 Main Process, Renderer Process, GPU Process의 역할과, Web Worker 및 SharedArrayBuffer를 활용한 병렬 처리 전략, 그리고 프로세스 간 통신(IPC) 오버헤드를 최소화하는 방법을 다뤄주세요.
Chrome은 각 탭을 별도의 Renderer Process로 실행하여 격리성과 안정성을 보장하며, Main Process는 UI와 네트워크를 관리하고 GPU Process는 하드웨어 가속 렌더링을 담당합니다. React 애플리케이션에서 무거운 계산은 Web Worker로 분리하여 메인 스레드 블로킹을 방지할 수 있으며, SharedArrayBuffer를 사용하면 복사 없이 데이터를 공유할 수 있습니다. 프로세스 간 통신은 postMessage를 통해 이루어지는데, 큰 데이터를 전송할 때는 Transferable Objects를 사용하여 복사 오버헤드를 제거해야 합니다. 이미지 처리, 대용량 데이터 파싱, 복잡한 계산 등을 Worker로 오프로드하면 60fps UI 응답성을 유지할 수 있으며, Comlink 같은 라이브러리로 Worker와의 통신을 추상화할 수 있습니다.
- • 브라우저의 멀티 프로세스 구조 (Main, Renderer, GPU Process)와 역할 분담
- • Web Worker를 통한 메인 스레드 블로킹 방지 및 병렬 처리
- • SharedArrayBuffer와 Transferable Objects를 활용한 효율적인 데이터 공유
- • 프로세스 간 통신(IPC) 오버헤드 최소화 전략
React 컴포넌트에서 Web Worker를 사용할 때 상태 동기화와 라이프사이클 관리를 어떻게 설계하시겠습니까? Worker Pool 패턴의 장단점도 설명해주세요.
Q. React 애플리케이션에서 대규모 트리 구조 데이터(예: 파일 시스템, 조직도)를 효율적으로 관리하고 렌더링하기 위한 자료구조 설계를 제시해주세요. 특히 깊이 우선 탐색(DFS)과 너비 우선 탐색(BFS)의 활용 시나리오, 경로 압축(Path Compression)을 통한 조회 최적화, 그리고 부분 트리 업데이트 시 불변성 유지 전략을 설명해주세요.
트리 구조는 인접 리스트 형태의 Map으로 저장하되, 각 노드 ID를 키로 하고 자식 ID 배열과 메타데이터를 값으로 관리합니다. 전체 트리 순회는 BFS로 레벨별 렌더링에 활용하고, 특정 노드 검색은 DFS로 구현하며, 경로 조회는 부모 포인터를 역추적하는 방식으로 최적화합니다. 불변성 유지를 위해 Immer나 structural sharing을 활용하되, 노드 업데이트 시 루트부터 해당 노드까지의 경로만 새로 생성하고 나머지는 재사용합니다. 대규모 트리는 가상화(react-window)와 lazy loading을 결합하여 보이는 노드만 렌더링하고, Trie 구조를 활용한 경로 압축으로 O(1) 조회를 구현할 수 있습니다. 노드 확장/축소 상태는 별도 Set으로 관리하여 트리 데이터와 UI 상태를 분리합니다.
- • Map 기반 인접 리스트 구조와 부모 포인터를 활용한 효율적인 트리 표현
- • DFS/BFS의 활용 시나리오 구분 (검색 vs 레벨별 렌더링)
- • Structural sharing을 통한 불변성 유지와 부분 업데이트 최적화
- • 경로 압축과 가상화를 결합한 대규모 트리 성능 최적화
트리 구조에서 드래그 앤 드롭으로 노드를 이동시킬 때, 순환 참조를 방지하고 효율적으로 유효성을 검증하는 알고리즘을 설계한다면 어떻게 하시겠습니까?
Q. React 애플리케이션에서 IndexedDB를 사용할 때 트랜잭션 격리 수준과 동시성 제어 메커니즘을 설명해주세요. 특히 여러 탭에서 동시에 같은 데이터를 수정할 때 발생할 수 있는 문제와 해결 방법, 그리고 인덱스 설계를 통한 쿼리 최적화 전략을 다뤄주세요.
IndexedDB는 Read Committed 수준의 격리를 제공하며, 트랜잭션은 readonly, readwrite, versionchange 세 가지 모드로 동작합니다. 동일 스코프의 readwrite 트랜잭션은 직렬화되어 순차 실행되므로 락 경합이 발생할 수 있으며, 여러 탭 간 동시 쓰기는 Broadcast Channel API나 SharedWorker를 통해 조율해야 합니다. 낙관적 잠금(Optimistic Locking) 패턴으로 버전 필드를 추가하고, 업데이트 시 버전을 검증하여 충돌을 감지할 수 있습니다. 인덱스는 자주 조회되는 필드에만 생성하되, 복합 인덱스는 쿼리 패턴을 고려하여 설계해야 하며, 과도한 인덱스는 쓰기 성능을 저하시킵니다. 범위 쿼리에는 IDBKeyRange를 활용하고, 커서를 사용한 페이지네이션으로 대량 데이터를 효율적으로 처리할 수 있습니다.
- • IndexedDB 트랜잭션 격리 수준과 모드별 동시성 제어
- • Broadcast Channel API를 활용한 다중 탭 간 동기화
- • 낙관적 잠금을 통한 충돌 감지 및 해결
- • 인덱스 설계와 IDBKeyRange를 활용한 쿼리 최적화
IndexedDB의 용량 제한과 쿼터 관리 전략은 어떻게 수립하시겠습니까? 데이터 마이그레이션이 필요할 때 versionchange 트랜잭션을 안전하게 처리하는 방법도 설명해주세요.
Q. React 애플리케이션에서 복잡한 의존성을 가진 컴포넌트들의 렌더링 순서를 최적화하기 위해 위상 정렬(Topological Sort) 알고리즘을 적용하는 시나리오를 설명해주세요. 특히 순환 의존성 감지, 우선순위 기반 스케줄링, 그리고 React의 Concurrent Mode와의 연계 방안을 다뤄주세요.
컴포넌트 간 데이터 의존성을 방향 그래프(DAG)로 모델링하고, Kahn 알고리즘이나 DFS 기반 위상 정렬로 렌더링 순서를 결정할 수 있습니다. 각 컴포넌트를 노드로, 데이터 의존성을 간선으로 표현하여 진입 차수가 0인 노드부터 처리하며, 순환 의존성이 발견되면 에러를 발생시키거나 경고를 표시합니다. React의 Concurrent Mode에서는 우선순위 큐를 결합하여 중요한 컴포넌트를 먼저 렌더링하고, startTransition으로 낮은 우선순위 업데이트를 지연시킬 수 있습니다. 의존성 그래프는 컴포넌트 마운트 시 구축하고, 동적 의존성 변경 시 증분 업데이트하여 재계산 비용을 최소화합니다. 이를 통해 critical rendering path를 최적화하고, 불필요한 리렌더링을 방지할 수 있습니다.
- • 컴포넌트 의존성을 DAG로 모델링하고 위상 정렬로 렌더링 순서 결정
- • Kahn 알고리즘 또는 DFS를 활용한 순환 의존성 감지
- • 우선순위 큐와 Concurrent Mode의 startTransition 연계
- • 증분 업데이트를 통한 의존성 그래프 유지 비용 최소화
동적으로 로드되는 컴포넌트가 추가될 때 의존성 그래프를 실시간으로 업데이트하는 전략은 무엇인가요? 의존성 순환이 불가피한 경우 어떻게 처리하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!