[기술 면접] 2026-03-10 — 오늘의 기술 면접

오늘의 면접 주제

 

GitHub 트렌딩의 facebook/react와 developer-roadmap 흐름을 보면, 여전히 프론트엔드 면접의 핵심은 React의 렌더링 원리와 상태 관리입니다.

핵심 한 줄 요약

React 면접의 본질은 "상태 변화가 언제 어떤 단위로 렌더링을 유발하고, 그 비용을 어떻게 통제할 것인가"를 설명하는 능력입니다.

면접 질문 & 모범 답변

Q1. React에서 state와 props의 차이는 무엇인가요?

기본 답변 (2-3문장): props는 부모가 자식에게 전달하는 읽기 전용 데이터이고, state는 컴포넌트 내부에서 직접 관리하는 변경 가능한 값입니다. props가 바뀌면 자식은 새로운 입력을 받아 다시 렌더링되고, state가 바뀌어도 해당 컴포넌트는 다시 렌더링됩니다.
심화 포인트: 많은 지원자가 둘 다 "렌더링을 일으키는 값" 정도로만 설명하는데, 실제로는 데이터 소유권과 변경 책임이 어디에 있는지까지 말해야 설계 이해도가 드러납니다.

Q2. React는 state가 변경되면 어떻게 화면을 갱신하나요?

기본 답변 (2-3문장): React는 state 변경 시 새로운 Virtual DOM 트리를 만들고, 이전 결과와 비교해 실제 DOM에 필요한 최소 변경만 반영합니다. 이 과정에서 컴포넌트 함수는 다시 실행되지만, 브라우저 DOM 전체를 매번 다시 그리는 것은 아닙니다.
심화 포인트: "함수 재실행"과 "실제 DOM 변경"을 구분해서 설명해야 합니다. 이 차이를 모르면 성능 최적화도 감으로만 하게 됩니다.

Q3. useState와 useRef는 언제 각각 써야 하나요?

기본 답변 (2-3문장): 화면에 반영되어야 하는 값이면 useState, 값은 유지해야 하지만 변경이 렌더링을 유발할 필요가 없으면 useRef를 사용합니다. 예를 들어 입력 포커스 제어나 이전 값 저장은 useRef가 적합합니다.
심화 포인트: useRef를 state 대용으로 남용하면 UI와 데이터가 어긋날 수 있습니다. 반대로 렌더링과 무관한 값을 useState로 들고 있으면 불필요한 재렌더링이 생깁니다.

Q4. React에서 리스트 렌더링 시 key가 왜 중요한가요?

기본 답변 (2-3문장): key는 React가 각 요소의 정체성을 식별하는 기준입니다. 안정적인 key가 있어야 항목 추가, 삭제, 재정렬 시 기존 컴포넌트 상태를 올바르게 유지할 수 있습니다.
심화 포인트: 단순히 경고를 없애는 용도가 아닙니다. index를 key로 쓰면 정렬 변경 시 input 값이 엉뚱한 행에 남는 등 실제 버그로 이어질 수 있습니다.

Q5. useEffect는 언제 써야 하고, 남용하면 왜 문제인가요?

기본 답변 (2-3문장): useEffect는 렌더링 이후 실행되어야 하는 side effect, 예를 들면 API 호출, 구독 등록, 타이머 제어에 사용합니다. 계산 가능한 값을 effect로 동기화하려 하면 로직이 복잡해지고 중복 상태가 생깁니다.
심화 포인트: 좋은 React 코드는 "effect를 줄이는 방향"으로 설계됩니다. 파생 가능한 값은 렌더링 중 계산하고, effect는 외부 세계와의 동기화에만 쓰는 것이 핵심입니다.

Q6. React 성능 최적화는 어떤 기준으로 접근하시나요?

기본 답변 (2-3문장): 먼저 병목을 측정하고, 그다음 불필요한 재렌더링이 실제 문제인지 확인합니다. 이후 memo, state 위치 조정, 리스트 분할, 비싼 계산 분리 같은 방법을 선택합니다.
심화 포인트: 무조건 useMemo나 useCallback를 추가하는 것은 오히려 복잡도만 높일 수 있습니다. 면접에서는 "최적화 자체"보다 "최적화가 필요한 근거"를 말하는 지원자가 강합니다.

Q7. 실무에서 React 상태 관리가 꼬였던 경험이 있다면 어떻게 해결하시겠습니까?

기본 답변 (2-3문장): 저는 먼저 전역 상태, 서버 상태, UI 상태를 분리합니다. 그 후 상태의 소유자를 명확히 하고, 중복 저장을 줄이며, 필요한 경우 Context, Redux, Zustand, React Query 같은 도구를 역할에 맞게 선택합니다.
심화 포인트: 실무 문제의 본질은 라이브러리 선택보다 상태 경계 설계입니다. 특히 서버 응답을 전역 상태에 복제 저장하는 구조는 캐시 불일치와 복잡도를 빠르게 키웁니다.

꼬리 질문 대비

React Query와 Redux는 해결하려는 문제가 어떻게 다른가요?
컴포넌트를 잘게 나누면 항상 성능이 좋아지나요?
memo가 동작하지 않는 대표적인 경우는 무엇인가요?
Strict Mode에서 effect가 두 번 실행되는 이유를 설명해보세요.
상태를 끌어올리는 것과 Context 도입의 기준은 무엇인가요?

헷갈리기 쉬운 포인트

Virtual DOM이 곧 성능 최적화 그 자체는 아닙니다. 핵심은 변경 계산을 선언적으로 관리한다는 점입니다.
컴포넌트 함수가 다시 실행된다고 해서 실제 DOM도 전부 바뀌는 것은 아닙니다.
useEffect는 "렌더링 후 실행되는 로직"이지, 모든 비즈니스 로직을 넣는 공간이 아닙니다.

면접관 시각

이 주제에서는 React API를 많이 외웠는지보다, 렌더링과 상태 흐름을 원인-결과로 설명하는지를 봅니다. 특히 왜 이 훅을 썼는지, 왜 이 구조가 버그를 줄이는지, 왜 이 최적화가 필요한지를 말하는 지원자는 실무 적응력이 높습니다. 반대로 용어는 많이 아는데 state 소유권, effect 남용, key의 의미를 정확히 설명하지 못하면 깊이가 얕다고 판단합니다.