JavaScript 시니어 프레임워크 심화 기술면접

JavaScript 시니어 (7년+) 프레임워크 5문항 조회수 114 · 2026-06-18 (목) 11:11:08
1 React Reconciliation
Hard

Q. React의 Fiber 아키텍처가 도입된 배경과 기존 Stack Reconciler의 한계를 설명하고, Fiber가 어떻게 작업을 중단하고 재개할 수 있는지(Incremental Rendering) 그 메커니즘을 설명해주세요. 또한 Time Slicing과 Suspense가 Fiber 아키텍처를 어떻게 활용하는지도 함께 설명해주세요.

A. 모범답안

기존 Stack Reconciler는 재귀적으로 동작하여 한 번 시작하면 중단할 수 없어 16ms 프레임 버짓을 초과하면 UI가 끊기는 문제가 있었습니다. Fiber는 각 컴포넌트를 작은 작업 단위(Fiber Node)로 분할하고 Linked List 구조로 연결하여, requestIdleCallback을 활용해 우선순위에 따라 작업을 중단하고 재개할 수 있습니다. Time Slicing은 Fiber의 우선순위 스케줄링을 통해 긴급한 업데이트(사용자 입력)를 먼저 처리하고, Suspense는 비동기 컴포넌트 로딩 시 Fiber 트리의 일부를 pending 상태로 유지하며 fallback을 렌더링합니다. 이를 통해 대규모 업데이트에서도 60fps를 유지하며 사용자 경험을 개선할 수 있습니다.

핵심 포인트
  • • Stack Reconciler의 한계: 재귀 호출로 인한 중단 불가능, 긴 작업 시 UI 블로킹
  • • Fiber의 핵심: 작업을 작은 단위로 분할하고 Linked List로 관리하여 중단/재개 가능
  • • 우선순위 기반 스케줄링: 긴급한 업데이트를 먼저 처리하고 덜 중요한 작업은 지연
  • • Time Slicing과 Suspense: Fiber 아키텍처를 활용한 비동기 렌더링 최적화
Follow-up 질문

React 18의 Concurrent Mode에서 useTransition과 useDeferredValue가 내부적으로 어떻게 우선순위를 낮춰서 작업을 처리하는지, 그리고 실무에서 어떤 상황에 각각을 사용해야 하는지 설명해주세요.

2 Vue.js Reactivity System
Hard

Q. Vue 2의 Object.defineProperty 기반 반응성 시스템과 Vue 3의 Proxy 기반 반응성 시스템의 차이점을 설명하고, 각각의 장단점과 성능 특성을 비교해주세요. 또한 Vue 3의 Composition API에서 ref와 reactive의 내부 구현 차이와 언제 어느 것을 선택해야 하는지 설명해주세요.

A. 모범답안

Vue 2는 Object.defineProperty를 사용하여 각 속성마다 getter/setter를 정의하지만, 새로운 속성 추가나 배열 인덱스 변경을 감지할 수 없고 초기화 시 모든 속성을 순회해야 하는 한계가 있습니다. Vue 3의 Proxy는 객체 전체를 가로채서 동적 속성 추가/삭제, 배열 메서드를 모두 감지할 수 있고 lazy하게 중첩 객체를 반응형으로 만들어 성능이 향상됩니다. ref는 원시값을 .value 속성을 가진 객체로 래핑하여 반응성을 제공하고, reactive는 객체를 Proxy로 감싸며 ref는 자동 언래핑됩니다. 원시값이나 단일 값에는 ref를, 관련된 여러 속성을 가진 객체에는 reactive를 사용하는 것이 권장됩니다.

핵심 포인트
  • • Object.defineProperty의 한계: 동적 속성 추가 미감지, 배열 인덱스 변경 미감지, 초기화 비용
  • • Proxy의 장점: 모든 작업 가로채기 가능, lazy 반응성, 더 나은 성능과 메모리 효율
  • • ref vs reactive: ref는 원시값 래핑, reactive는 객체 Proxy 변환, 사용 컨텍스트에 따른 선택
  • • Vue 3의 성능 개선: 중첩 객체의 lazy 변환으로 초기화 속도 향상
Follow-up 질문

대규모 Vue 애플리케이션에서 불필요한 반응성 추적으로 인한 성능 저하를 방지하기 위해 shallowRef, shallowReactive, markRaw를 어떻게 활용할 수 있는지 실무 사례와 함께 설명해주세요.

3 Angular Change Detection
Hard

Q. Angular의 Zone.js 기반 Change Detection 메커니즘을 설명하고, Default Strategy와 OnPush Strategy의 차이점 및 성능 최적화 방법을 제시해주세요. 또한 대규모 애플리케이션에서 Change Detection을 수동으로 제어하기 위한 detach, reattach, detectChanges 메서드의 활용 전략을 설명해주세요.

A. 모범답안

Zone.js는 비동기 작업(이벤트, setTimeout, HTTP 요청)을 monkey patching으로 가로채서 작업 완료 시 자동으로 Change Detection을 트리거합니다. Default Strategy는 모든 컴포넌트 트리를 검사하지만, OnPush Strategy는 Input 속성 참조 변경이나 이벤트 발생 시에만 해당 컴포넌트와 자식들을 검사하여 성능을 크게 향상시킵니다. detach()로 컴포넌트를 Change Detection 트리에서 분리하고, 필요한 시점에만 detectChanges()로 수동 검사하며, reattach()로 다시 연결할 수 있습니다. 실시간 대시보드나 대용량 리스트에서 불필요한 검사를 줄이고 throttle이나 debounce와 함께 사용하면 효과적입니다.

핵심 포인트
  • • Zone.js의 역할: 비동기 작업 가로채기 및 자동 Change Detection 트리거
  • • OnPush Strategy: Input 참조 변경 시에만 검사하여 성능 최적화, 불변성 패턴 필요
  • • 수동 제어: detach로 분리, detectChanges로 선택적 검사, reattach로 재연결
  • • 실무 활용: 대용량 데이터, 실시간 업데이트에서 throttle과 함께 사용
Follow-up 질문

Angular 14에서 도입된 Signals 기반 반응성 시스템이 기존 Zone.js 기반 Change Detection과 어떻게 다르며, 향후 Angular 애플리케이션의 성능과 아키텍처에 어떤 영향을 미칠지 전망해주세요.

4 Server-Side Rendering
Hard

Q. Next.js의 SSR(Server-Side Rendering), SSG(Static Site Generation), ISR(Incremental Static Regeneration)의 차이점과 각각의 적합한 사용 사례를 설명하고, Hydration 과정에서 발생할 수 있는 문제점과 해결 방법을 제시해주세요. 또한 React Server Components가 기존 SSR과 어떻게 다른지 설명해주세요.

A. 모범답안

SSR은 요청마다 서버에서 HTML을 생성하여 최신 데이터를 보장하지만 TTFB가 길고, SSG는 빌드 시 HTML을 생성하여 CDN으로 빠르게 제공하지만 데이터가 정적이며, ISR은 일정 시간마다 페이지를 재생성하여 둘의 장점을 결합합니다. Hydration 시 서버와 클라이언트의 마크업 불일치, 큰 번들로 인한 TTI 지연, 중복 데이터 fetching 문제가 발생할 수 있으며, 조건부 렌더링 최소화, Progressive Hydration, Streaming SSR로 해결합니다. React Server Components는 서버에서만 실행되어 클라이언트 번들에 포함되지 않고, 직접 DB 접근이 가능하며 자동 코드 스플리팅을 제공하여 기존 SSR보다 효율적입니다.

핵심 포인트
  • • SSR/SSG/ISR 비교: 데이터 신선도, 성능, 서버 부하의 트레이드오프
  • • Hydration 문제: 마크업 불일치, TTI 지연, 중복 fetching
  • • 해결 방법: Progressive Hydration, Streaming SSR, Selective Hydration
  • • React Server Components: 서버 전용 실행, 번들 크기 감소, 직접 데이터 접근
Follow-up 질문

대규모 e-commerce 사이트에서 상품 목록은 ISR, 상품 상세는 SSR, 마이페이지는 CSR로 구성할 때, 각 페이지 간 전환 시 발생할 수 있는 사용자 경험 문제와 이를 해결하기 위한 데이터 프리페칭 및 캐싱 전략을 제시해주세요.

5 State Management Architecture
Hard

Q. 대규모 React 애플리케이션에서 Redux, MobX, Zustand, Jotai, Recoil 같은 상태 관리 라이브러리들의 아키텍처 차이와 각각의 장단점을 비교하고, 어떤 상황에서 어떤 라이브러리를 선택해야 하는지 기술적 의사결정 기준을 제시해주세요. 또한 Server State(React Query, SWR)와 Client State를 어떻게 구분하고 관리해야 하는지 설명해주세요.

A. 모범답안

Redux는 단방향 데이터 흐름과 불변성 기반으로 예측 가능하지만 보일러플레이트가 많고, MobX는 Observable 기반 자동 추적으로 간결하지만 암묵적 동작이 디버깅을 어렵게 합니다. Zustand는 경량 flux 패턴으로 간단하고, Jotai/Recoil은 Atomic 상태로 세밀한 구독과 동시성을 지원합니다. 복잡한 비즈니스 로직과 시간여행 디버깅이 필요하면 Redux, 반응형과 간결함이 중요하면 MobX, 작은 앱이나 빠른 개발은 Zustand, 세밀한 최적화는 Jotai/Recoil을 선택합니다. Server State는 캐싱, 재검증, 백그라운드 업데이트가 필요하므로 React Query/SWR로 관리하고, Client State(UI 상태, 폼 데이터)는 가벼운 라이브러리나 Context로 분리하여 관심사를 명확히 합니다.

핵심 포인트
  • • 아키텍처 비교: Flux(Redux/Zustand), Reactive(MobX), Atomic(Jotai/Recoil)
  • • 선택 기준: 프로젝트 규모, 팀 경험, 성능 요구사항, 디버깅 필요성
  • • Server State 분리: 캐싱과 동기화는 React Query/SWR, Client State는 경량 라이브러리
  • • 실무 전략: 상태 특성에 따른 도구 조합, 과도한 전역 상태 지양
Follow-up 질문

마이크로 프론트엔드 아키텍처에서 여러 독립적인 React 애플리케이션이 공유해야 하는 상태(인증, 사용자 정보)를 어떻게 관리하고 동기화할 수 있는지, 그리고 각 앱의 독립성을 유지하면서도 일관된 사용자 경험을 제공하기 위한 전략을 제시해주세요.

댓글 0

로그인 후 댓글을 작성할 수 있습니다.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!