React 바깥의 프론트엔드

1. 프론트엔드 프레임워크의 역사와 각 단계의 의미

MPA(서버 렌더링, 페이지 새로고침) → jQuery(DOM 조작 단순화) → Backbone/Angular(MVC로 구조화) → React(단방향 데이터 흐름, Virtual DOM)의 흐름입니다. 각 단계는 이전 방식의 한계를 해결합니다: jQuery는 브라우저 호환성 문제를, React는 복잡한 상태와 UI 동기화 문제를 해결했습니다. 하지만 React의 JSX와 Virtual DOM은 HTML 표준에서 멀어지는 방향이었고, 번들러·빌드 도구 없이는 사용하기 어려운 복잡성을 도입했습니다.

핵심 용어

2. Virtual DOM의 동작 원리와 한계

Virtual DOM은 실제 DOM의 가벼운 JavaScript 객체 복사본입니다. 상태 변화 시 새 Virtual DOM 트리를 생성하고 이전 트리와 비교(diffing)해 최소 변경만 실제 DOM에 적용합니다. 성능 오해: Virtual DOM이 '항상' 빠른 것이 아닙니다. 단순한 업데이트는 직접 DOM 조작이 더 빠를 수 있습니다. Virtual DOM의 진짜 가치는 성능보다 '예측 가능한 선언적 UI 업데이트'입니다. 한계: 불필요한 리렌더링(부모가 바뀌면 자식 전체 재렌더), diff 연산 오버헤드.

핵심 용어

3. 시그널(Signal) 기반 반응성: React의 대안

시그널은 '값이 바뀌면 그 값을 구독한 곳만 자동으로 업데이트'하는 반응성 프리미티브입니다. React와의 차이: React는 상태 변화 시 컴포넌트 전체를 재실행(함수 호출)하고 Virtual DOM diff로 실제 변경을 찾지만, 시그널은 변경된 DOM 노드만 직접 업데이트해 diff가 필요 없습니다. `const [count, setCount] = createSignal(0)` — Signal의 값은 get(), set() 함수로 접근하며, `count()`를 참조한 곳이 의존성으로 자동 등록됩니다. Solid.js, Vue 3, Angular 16+, Svelte 5가 이 패러다임을 채택했습니다.

핵심 용어

4. 도구 선택 기준과 웹 표준의 중요성

프레임워크 선택은 기술 우위보다 맥락이 중요합니다. React: 큰 생태계, 채용 시장 강점, 충분한 성숙도. Solid/Svelte: 더 나은 성능, 작은 번들, 학습 용이. Astro: 콘텐츠 중심 사이트에서 뛰어난 성능(Island 아키텍처). 웹 표준의 가치: Web Components, Custom Elements, CSS 변수 같은 표준 기술은 프레임워크에 종속되지 않아 수명이 깁니다. '이 도구가 없어진다면 무엇이 남는가'를 생각하면 웹 표준 학습의 중요성이 명확해집니다.

핵심 용어

Q1. React의 Virtual DOM이 실제로 성능 최적화에 도움이 되나요? Virtual DOM의 진짜 가치는 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "React의 Virtual DOM이 실제로 성능 최적화에 도움이 되나요? Virtual DOM의 진짜 가치는 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 오해를 먼저 바로잡으세요: Virtual DOM이 '항상' 빠른 것은 아닙니다. 단순한 DOM 조작은 직접 하는 게 더 빠릅니다. Virtual DOM의 진짜 가치는 성능이 아니라 '선언적 UI 업데이트'입니다. 개발자가 '현재 상태에서 어떻게 변하는가'를 명시하지 않고 '상태에 따라 UI가 어떻게 보여야 하는가'만 선언하면 React가 변경을 계산한다는 점을 설명하면 됩니다.

Q2. 시그널(Signal)이란 무엇이고 React의 상태 관리와 어떻게 다른가요?

힌트

[감점 답변] 정의만 반복하거나 "시그널(Signal)이란 무엇이고 React의 상태 관리와 어떻게 다른가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] React 방식: useState로 상태 변경 → 컴포넌트 함수 전체 재실행 → Virtual DOM diff → DOM 업데이트. 시그널 방식: 시그널 값 변경 → 이 값을 참조한 DOM 노드만 직접 업데이트 (컴포넌트 재실행 없음). Solid.js의 createSignal 예시를 들어 설명하면 구체적입니다. '컴포넌트가 한 번만 실행되고 이후 상태 변화는 시그널이 처리한다'는 점이 핵심입니다.

Q3. Svelte나 Solid.js가 React보다 번들 크기가 작은 이유는 무엇인가요?

힌트

[감점 답변] 정의만 반복하거나 "Svelte나 Solid.js가 React보다 번들 크기가 작은 이유는 무엇인가요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 두 가지로 나눠 설명하세요: Svelte — 컴파일러가 컴포넌트를 순수 DOM 조작 코드로 변환해 런타임이 필요 없음(Virtual DOM 라이브러리 자체가 번들에 없음). Solid — 시그널 기반이라 React reconciler 같은 무거운 런타임 없이 동작. React는 ~40KB(gzip)의 런타임이 항상 포함되는데, 이 차이가 작은 앱에서 두드러집니다.

Q4. 새 프로젝트에서 React vs 다른 프레임워크를 선택하는 기준을 설명해 주세요.

힌트

[감점 답변] 정의만 반복하거나 "새 프로젝트에서 React vs 다른 프레임워크를 선택하는 기준을 설명해 주세요."에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] 기술적 우위보다 맥락으로 설명하세요: (1) 팀 역량과 채용 시장 — React 경험자가 많다면 React, (2) 프로젝트 특성 — 콘텐츠 중심 정적 사이트라면 Astro, 성능 극한화 필요하면 Solid, (3) 생태계 — 필요한 라이브러리가 있는지 확인. '최신 = 최선이 아니라 상황에 맞는 도구'가 최선이라는 원칙을 강조하면 성숙한 답변이 됩니다.

Q5. React 없이 웹 표준만으로 SPA를 구현하면 어떤 도전이 있나요?

힌트

[감점 답변] 정의만 반복하거나 "React 없이 웹 표준만으로 SPA를 구현하면 어떤 도전이 있나요?"에 대해 장단점 없이 단편적으로 답하면 감점 포인트입니다. 면접관은 실무 적용 경험이 부족하다고 판단합니다. [좋은 답변] React가 해결해준 것들을 열거하면 반대로 도전 과제가 됩니다: 상태와 UI 동기화(수동으로 DOM 업데이트), 컴포넌트 재사용(Web Components로 부분 가능), 라우팅(History API 직접 구현), 생태계(라이브러리 부족). 웹 표준으로 SPA를 만드는 것이 불가능하지는 않지만, 팀 생산성과 유지보수 비용을 고려하면 현실적 선택지는 제한됩니다. 웹 표준 학습의 가치는 '어느 프레임워크에서도 이전 가능한 기반 지식'에 있다고 설명하면 됩니다.