React 리드·아키텍트 CS 기초 면접
새 면접Q. 대규모 React 애플리케이션에서 API 요청 시 TCP 연결 재사용을 최적화하려고 합니다. HTTP/1.1의 Keep-Alive와 HTTP/2의 Multiplexing의 동작 원리를 비교 설명하고, 각각의 환경에서 브라우저의 동시 연결 제한과 Head-of-Line Blocking 문제가 어떻게 다르게 나타나는지 설명해주세요. 또한 프론트엔드 아키텍트 관점에서 HTTP 버전 선택이 API 설계와 CDN 전략에 미치는 영향을 제시해주세요.
HTTP/1.1은 파이프라이닝의 한계, HTTP/2는 단일 TCP 연결 내 스트림 다중화를 생각해보세요.
HTTP/1.1 Keep-Alive는 TCP 연결을 재사용하지만 HOL Blocking으로 인해 브라우저당 도메인별 6~8개 연결을 병렬로 유지합니다. HTTP/2는 단일 TCP 연결에서 스트림 기반 멀티플렉싱으로 수십~수백 개 요청을 동시 처리하며 헤더 압축(HPACK)으로 오버헤드를 줄입니다. 하지만 HTTP/2도 TCP 레벨 HOL Blocking은 여전히 존재하며, 패킷 손실 시 모든 스트림이 영향받습니다. 프론트엔드에서는 HTTP/2 환경에서 도메인 샤딩이 오히려 역효과이므로 단일 도메인 전략이 유리하며, 리소스 번들링보다 세분화된 청크 전략이 효과적입니다. CDN 선택 시 HTTP/2 지원 여부와 Server Push 기능 활용 가능성을 고려해야 하며, HTTP/3(QUIC) 도입 시 UDP 기반으로 HOL Blocking을 근본적으로 해결할 수 있습니다.
- • HTTP/1.1은 연결당 순차 처리로 HOL Blocking 발생, 브라우저가 도메인당 6~8개 병렬 연결 유지
- • HTTP/2는 단일 TCP 연결에서 스트림 멀티플렉싱, 헤더 압축으로 성능 향상하지만 TCP 레벨 HOL은 존재
- • HTTP/2 환경에서는 도메인 샤딩 불필요, 리소스 세분화 전략이 유리
- • CDN과 프로토콜 버전 선택이 번들링 전략과 캐싱 정책에 직접 영향
API Gateway와 CDN 선택, 리소스 번들링 전략 수립 시 HTTP 프로토콜 버전에 따라 최적화 방향이 완전히 달라집니다.
HTTP/3(QUIC)를 도입한다면 기존 HTTP/2 대비 어떤 인프라 변경이 필요하고, 브라우저 호환성과 방화벽 이슈는 어떻게 대응하시겠습니까?
Q. 대규모 실시간 협업 도구(예: Figma, Notion 같은)를 React로 구축할 때, 수천 개의 오브젝트 간 계층 구조와 빠른 검색, 삽입, 삭제가 필요합니다. Tree 구조 중 B-Tree, Red-Black Tree, AVL Tree의 특성을 비교하고, 브라우저 메모리 환경에서 DOM과 유사한 계층 구조를 관리할 때 어떤 자료구조가 적합한지 설명해주세요. 또한 Undo/Redo 기능 구현 시 Persistent Data Structure(영속 자료구조)를 활용하는 방법과 메모리 트레이드오프를 제시해주세요.
균형 트리의 재조정 비용과 메모리 오버헤드, 그리고 불변성 유지를 위한 구조적 공유를 고려해보세요.
AVL Tree는 엄격한 균형(높이 차이 1 이하)으로 검색 O(log n)이 가장 빠르지만 삽입/삭제 시 회전이 빈번해 쓰기 성능이 낮습니다. Red-Black Tree는 느슨한 균형(높이 차이 2배 이하)으로 삽입/삭제가 AVL보다 빠르며 실무에서 가장 많이 사용됩니다. B-Tree는 노드당 다중 키를 저장해 디스크 I/O 최적화에 유리하지만 메모리 환경에서는 오버헤드가 큽니다. 브라우저 환경의 계층 구조는 Red-Black Tree 기반이 적합하며, 실제로 V8 엔진의 Map도 이를 사용합니다. Undo/Redo는 Persistent Data Structure로 구현하면 각 상태가 이전 구조를 참조하는 구조적 공유로 메모리 효율적이며, Immutable.js나 Immer 같은 라이브러리가 이를 구현합니다. 다만 깊은 복사 대비 참조 오버헤드와 GC 압력이 증가하므로 스냅샷 주기 조정이 필요합니다.
- • AVL은 검색 최적화, Red-Black은 삽입/삭제 균형, B-Tree는 디스크 I/O 최적화
- • 브라우저 메모리 환경에서는 Red-Black Tree가 읽기/쓰기 균형이 좋아 적합
- • Persistent Data Structure는 구조적 공유로 Undo/Redo를 메모리 효율적으로 구현
- • 불변 자료구조는 참조 오버헤드와 GC 압력 증가 트레이드오프 존재
Figma, Notion 같은 협업 도구의 오브젝트 관리와 히스토리 추적 시스템 설계에 직접 적용됩니다.
CRDT(Conflict-free Replicated Data Type)를 활용한 실시간 동기화 구현 시 어떤 자료구조와 알고리즘을 조합하시겠습니까?
Q. React 애플리케이션에서 IndexedDB를 활용해 오프라인 우선(Offline-First) 아키텍처를 구축하려고 합니다. IndexedDB의 트랜잭션 모델(readwrite, readonly, versionchange)과 ACID 속성 중 어떤 부분이 보장되고 어떤 부분이 제한되는지 설명해주세요. 또한 서버 DB와의 동기화 시 발생할 수 있는 Conflict Resolution 전략(Last Write Wins, Operational Transformation, CRDT)을 비교하고, 대규모 사용자 환경에서 데이터 정합성을 보장하기 위한 아키텍처 설계 원칙을 제시해주세요.
IndexedDB는 브라우저 내 트랜잭션 격리는 보장하지만 분산 환경의 일관성은 애플리케이션 레벨에서 해결해야 합니다.
IndexedDB는 단일 브라우저 내에서 Atomicity와 Isolation은 보장하지만 Durability는 브라우저 정책에 따라 제한되며, 분산 환경의 Consistency는 보장하지 않습니다. readwrite 트랜잭션은 배타적 잠금으로 동시성 제어하며, readonly는 공유 잠금으로 병렬 읽기가 가능합니다. 서버 동기화 시 Last Write Wins는 구현이 간단하지만 데이터 손실 위험이 있고, Operational Transformation은 Google Docs처럼 실시간 협업에 적합하지만 복잡도가 높습니다. CRDT는 수학적으로 수렴을 보장해 충돌 해결이 자동이지만 메모리 오버헤드가 큽니다. 아키텍처 설계 시 타임스탬프 기반 버저닝, 벡터 클록을 통한 인과관계 추적, 충돌 발생 시 사용자 개입 UI 제공, 그리고 주기적인 서버 상태 검증(checksum)을 조합해야 합니다.
- • IndexedDB는 로컬 ACID 중 A, I는 보장하지만 D는 제한적, 분산 C는 미보장
- • 트랜잭션 모드별 잠금 전략으로 동시성 제어
- • 동기화 전략은 Last Write Wins(단순), OT(실시간), CRDT(자동 수렴) 중 요구사항에 맞게 선택
- • 버저닝, 벡터 클록, 사용자 개입, 검증을 조합한 정합성 보장 필요
Google Docs, Trello, Notion 같은 오프라인 지원 웹 애플리케이션의 로컬 스토리지와 동기화 시스템 설계에 필수적입니다.
Service Worker와 IndexedDB를 결합한 캐싱 전략 설계 시, 캐시 무효화(Cache Invalidation) 정책과 스토리지 용량 제한 대응 방안은 어떻게 수립하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!