Question 1

useState와 useEffect의 동작 원리를 설명해주세요.

Accepted Answer

### **useState**

`useState`는 컴포넌트의 **상태를 React 내부에 저장하고 관리**하기 위한 Hook입니다.

setter 함수를 호출하면 상태값이 즉시 현재 렌더링에서 변경되는 것이 아니라, **상태 변경이 예약되고 컴포넌트가 다시 렌더링**됩니다.

변경된 상태값은 **다음 렌더링에서 반영**되며, 같은 이벤트 안에서 여러 상태 업데이트가 발생하면 React가 이를 **배칭(Batching)** 해서 불필요한 렌더링을 줄일 수 있습니다.

### **useEffect**

`useEffect`는 렌더링 이후 **외부 시스템과 동기화하거나 Side Effect를 처리**하기 위한 Hook입니다.

대표적으로 **API 호출, 이벤트 등록, 타이머, 구독 처리** 등에 사용합니다.

렌더링 결과가 **실제 DOM에 Commit된 이후 effect가 실행**되며, **의존성 배열**을 기준으로 다시 실행할지를 판단합니다.

- `[]` : **마운트 이후 1

Question 2

useMemo와 useCallback의 차이점과 사용 시점은?

Accepted Answer

### **useMemo와 useCallback의 차이점과 사용 시점**

`useMemo`와 `useCallback`은 둘 다 **메모이제이션을 통해 불필요한 연산이나 재생성을 줄이기 위한 Hook**입니다.

핵심 차이는 **무엇을 메모이제이션하느냐**입니다.

- `useMemo` → **계산된 값**을 메모이제이션
- `useCallback` → **함수의 참조**를 메모이제이션

---

### **useMemo**

`useMemo`는 **계산 결과를 저장해두고 재사용**합니다.

컴포넌트가 다시 렌더링되더라도 의존성 배열의 값이 변경되지 않았다면 **이전 계산 결과를 그대로 사용**합니다.

따라서 다음과 같은 경우에 사용합니다.

- **비용이 큰 계산**
- 배열의 **filter, sort, map** 등의 결과를 반복해서 계산하는 경우
- 객체나 배열의 **참조를 유지해야 하는 경우**

즉,

**"이 값을 매번 다시 계산할 필요가 있는가?"**

를 기준으로

Question 3

React의 상태 관리 방법들을 비교해주세요.

Accepted Answer

### **React 앱의 상태 관리 방법**

React의 상태 관리는 **상태의 범위와 성격에 따라 도구를 선택하는 것**이 중요합니다.

크게 보면 상태는 **로컬 상태**, **전역 클라이언트 상태**, **서버 상태**로 나눌 수 있습니다.

---

### **useState**

`useState`는 가장 기본적인 상태 관리 방법으로, **하나의 컴포넌트 안에서 사용하는 단순한 로컬 상태**를 관리할 때 사용합니다.

주로 다음과 같은 경우에 적합합니다.

- 모달 열림 여부
- 입력값
- 체크박스 상태
- 간단한 카운트
- 특정 컴포넌트에서만 사용하는 UI 상태

즉, **상태를 사용하는 범위가 좁고 로직이 단순하다면 useState가 가장 적합**합니다.

---

### **useReducer**

`useReducer`는 여러 상태가 서로 연관되어 있거나, 상태 변경 규칙이 복잡한 경우 사용합니다.

`useState`가 단순히 값을 변경하는 방식이라면, `use

Question 4

React의 리렌더링 조건과 최적화 방법은?

Accepted Answer

### **React 컴포넌트는 언제 리렌더링되나요?**

React 컴포넌트는 대표적으로 다음과 같은 경우에 리렌더링됩니다.

1. **state가 변경될 때**
2. **props가 변경될 때**
3. **부모 컴포넌트가 리렌더링될 때**
4. **구독하고 있는 Context 값이 변경될 때**

여기서 중요한 점은 **부모 컴포넌트가 리렌더링되면 자식 컴포넌트도 기본적으로 다시 렌더링된다는 것**입니다.

자식의 props 값이 실제로 변경되지 않았더라도, 부모가 다시 렌더링되면 자식 컴포넌트 함수도 다시 실행될 수 있습니다.

---

### **state가 변경될 때**

컴포넌트의 state가 변경되면 React는 해당 컴포넌트의 **새로운 UI 결과를 계산하기 위해 리렌더링**을 수행합니다.

다만 state setter를 호출했다고 해서 항상 리렌더링되는 것은 아니고, **이전 상태와 새로운 상태가 동일하다고 판단되면 업데이트가 생략될 수 있습니다.**

---

##

Question 5

useRef의 다양한 용도와 사용법을 설명해주세요.

Accepted Answer

`useRef`는 **렌더링 사이에 값이 유지되지만, 변경해도 리렌더링을 일으키지 않는 저장소**입니다. `.current` 프로퍼티에 값을 읽고 씁니다.

### **대표적인 용도**

- **DOM 요소 접근** — ref를 요소에 연결해두고 포커스 이동, 스크롤 위치 조정, 크기 측정처럼 선언적으로 표현하기 어려운 명령형 작업을 할 때 사용합니다.
- **이전 값 저장** — 렌더링 후 effect에서 현재 값을 ref에 담아두면, 다음 렌더에서 "이전 렌더의 값"을 참조할 수 있습니다.
- **타이머·구독 ID 보관** — setTimeout이나 interval의 ID처럼, 화면에는 표시되지 않지만 정리(cleanup) 시점에 필요한 값을 보관합니다.
- **렌더와 무관한 플래그** — "이미 요청을 보냈는가" 같은 내부 플래그를 상태로 두면 불필요한 리렌더가 생기므로 ref에 둡니다.

### **useState와의 차이**

- `useState`는 값이 바뀌면 **리렌더

Question 6

useTransition과 useDeferredValue의 차이점과 사용 시점은?

Accepted Answer

둘 다 React 18의 Concurrent 기능으로, **긴급하지 않은 업데이트의 우선순위를 낮춰서** 사용자 입력 같은 급한 업데이트가 무거운 렌더링에 막히지 않게 합니다.

### **useTransition**

**상태 업데이트 함수를 감싸서** "이 업데이트는 급하지 않다"고 표시합니다.

예를 들어 검색 입력에서 입력값 반영은 즉시 하고, 무거운 결과 목록 갱신은 `startTransition`으로 감싸면 — 타이핑이 계속 들어올 때 React가 진행 중이던 결과 렌더링을 버리고 입력부터 처리합니다.

`isPending` 값을 제공하므로 **지연 중임을 UI에 표시**할 수 있습니다.

### **useDeferredValue**

**값 자체의 지연된 사본**을 만듭니다. 원본 값은 즉시 바뀌고, 지연된 값은 급한 렌더링이 끝난 뒤에 따라옵니다.

setter에 접근할 수 없는 경우 — 예를 들어 **props로 받은 값**을 기준으로 무거운 목록을 렌더링할 때 적합

Question 7

React.memo의 올바른 사용법과 한계를 설명해주세요.

Accepted Answer

`React.memo`는 **props가 바뀌지 않았으면 리렌더링을 건너뛰게** 하는 고차 컴포넌트입니다. 부모가 리렌더되면 자식은 props가 같아도 기본적으로 함께 리렌더되는데, memo는 이 지점에서 **props를 얕게 비교해** 같으면 이전 렌더 결과를 재사용합니다.

### **언제 쓰는가**

- **렌더링 비용이 높은 컴포넌트** — 긴 리스트, 차트, 복잡한 계산이 있는 트리
- **부모는 자주 리렌더되지만 자신의 props는 거의 바뀌지 않을 때**

이때 함수나 객체를 props로 내린다면 `useCallback`·`useMemo`로 **참조를 안정화**해야 memo가 실제로 동작합니다.

### **한계와 주의점**

- props에 **매번 새로 만든 객체나 함수**를 전달하면 얕은 비교가 항상 실패해서 무용지물이 됩니다. memo가 안 통하는 가장 흔한 원인입니다.
- **얕은 비교만** 수행하므로 중첩 객체의 내부 변경은 감지하지 못합니다. 필요하면 두 번

Question 8

React의 Error Boundary와 Suspense를 설명해주세요.

Accepted Answer

둘 다 **컴포넌트 트리의 특정 지점에서 예외 상황을 선언적으로 처리**하는 장치인데, 다루는 대상이 다릅니다.

### **Error Boundary**

자식 컴포넌트의 **렌더링 중 에러를 잡아서** 앱 전체가 죽는 대신 **폴백 UI를 보여주는** 컴포넌트입니다.

에러를 잡는 두 생명주기(`getDerivedStateFromError`, `componentDidCatch`)가 클래스에만 있어서 **아직 클래스 컴포넌트로만 만들 수 있습니다.** 실무에서는 `react-error-boundary` 라이브러리를 쓰는 것이 일반적입니다.

주의할 점은 **잡지 못하는 에러**가 있다는 것입니다 — 이벤트 핸들러, setTimeout 같은 비동기 코드, SSR 중 에러는 잡지 못합니다. 렌더링 경로의 에러만 잡습니다.

### **Suspense**

자식의 **비동기 작업이 끝날 때까지 폴백 UI를 보여주는** 내장 컴포넌트입니다. `React.lazy`를 통한 코드 스플리팅,

Question 9

Context API의 성능 문제와 해결 전략을 설명해주세요.

Accepted Answer

Context는 전역 값을 트리 아래로 전달하는 도구인데, **값이 바뀌면 그 Context를 구독하는 모든 컴포넌트가 리렌더**됩니다. 이게 성능 문제의 근원입니다.

### **문제가 생기는 전형적인 형태**

user와 theme을 **하나의 Context에 객체로 묶어서** 내려주면, user만 바뀌어도 theme만 쓰는 컴포넌트까지 전부 리렌더됩니다. 게다가 Provider의 value에 매 렌더 새 객체를 만들어 넘기면, 부모가 리렌더될 때마다 값이 "바뀐 것"으로 취급됩니다.

### **해결 전략**

- **Context 분리** — 변경 주기가 다른 값(user와 theme)은 각각의 Context로 나눕니다. 자기가 쓰는 값이 바뀔 때만 리렌더됩니다.
- **값과 업데이터 분리** — 읽기용 Context와 dispatch용 Context를 나누면, 값만 읽는 컴포넌트는 업데이터 참조 변경에 영향받지 않습니다.
- **value를 useMemo로 안정화** — P

Question 10

React에서 접근성(a11y)을 구현하는 핵심 전략은?

Accepted Answer

웹 접근성은 스크린 리더 사용자, 키보드만 쓰는 사용자를 포함한 **모든 사용자가 동등하게 서비스를 쓸 수 있게 하는 것**입니다. React에서의 핵심 전략은 다음과 같습니다.

### **1. 시맨틱 HTML 우선**

`div`에 onClick을 붙이는 대신 `button`, `a`, `input` 같은 **네이티브 요소**를 씁니다. 키보드 포커스, Enter/Space 동작, 스크린 리더 인식이 공짜로 따라옵니다. ARIA를 붙이기 전에 맞는 태그가 있는지 먼저 찾는 것이 원칙입니다.

### **2. 포커스 관리**

SPA는 화면이 바뀌어도 브라우저가 포커스를 옮겨주지 않으므로 직접 관리해야 합니다.

- 모달이 열리면 포커스를 모달 안으로 이동시키고, 닫히면 원래 위치로 되돌립니다.
- 모달이 열려 있는 동안 포커스가 바깥으로 나가지 않게 **focus trap**을 적용합니다.
- Escape로 닫기 같은 키보드 인터랙션을 지원합니다.

### **3. ARIA 속성

React

01useState와 useEffect의 동작 원리를 설명해주세요.보통Hooks

02useMemo와 useCallback의 차이점과 사용 시점은?보통Hooks

03React의 상태 관리 방법들을 비교해주세요.보통상태관리

04React의 리렌더링 조건과 최적화 방법은?보통렌더링

05useRef의 다양한 용도와 사용법을 설명해주세요.보통Hooks

06useTransition과 useDeferredValue의 차이점과 사용 시점은?보통Hooks

07React.memo의 올바른 사용법과 한계를 설명해주세요.보통최적화

08React의 Error Boundary와 Suspense를 설명해주세요.보통에러 처리

09Context API의 성능 문제와 해결 전략을 설명해주세요.보통상태관리

10React에서 접근성(a11y)을 구현하는 핵심 전략은?보통접근성