이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
React 기반 대시보드 애플리케이션을 팀 프로젝트로 설계하고 약 4개월간 운영했습니다. 가장 큰 도전은 컴포넌트가 늘어날수록 상태 관리가 복잡해지면서 예상치 못한 리렌더링이 빈번히 발생한 것이었습니다. 처음에는 props drilling으로 상태를 내려보냈는데, 컴포넌트 깊이가 4~5단계가 되면서 어디서 상태가 바뀌는지 추적하기 어려워졌습니다. Context API를 도입해 전역 상태를 분리했고, `useMemo`와 `React.memo`를 선택적으로 적용해 불필요한 렌더링을 줄였습니다. 이 과정에서 최적화를 처음부터 과하게 적용하면 코드가 복잡해지기만 하고 실제 성능 차이가 없는 경우도 있다는 것을 배웠습니다.
프로파일러로 측정 후 병목 구간에만 적용하는 방식으로 바꿨고, 그 이후 팀원들도 "왜 이게 여기 있지?"라는 혼란이 줄었습니다. 이 경험에서 성능 최적화는 측정 없이 하지 않는다는 원칙이 생겼습니다.
React 기반 애플리케이션에서 겪은 가장 큰 도전은 초기 컴포넌트 구조 결정이 이후 유지보수에 미치는 영향을 직접 경험한 것입니다. 초반에 기능별로 컴포넌트를 빠르게 만들었는데, 규모가 커지면서 props drilling 이 깊어지고 상태 관리가 복잡해졌습니다.
리팩토링을 거치면서 컨테이너-프레젠테이션 분리와 Context API 적용으로 구조를 바꿨고, 이후 기능 추가 속도가 확연히 달라졌습니다. 초기 설계에 시간을 더 투자했다면 리팩토링 비용을 줄일 수 있었습니다. 초기 컴포넌트 구조가 이후 유지보수 비용을 결정합니다.
props drilling이 깊어지면 리팩토링이 불가피합니다. 컨테이너-프레젠테이션 분리가 복잡도를 낮춥니다.
React 앱 운영에서 가장 어려웠던 것은 불필요한 리렌더링으로 인한 성능 저하 문제였습니다. 특정 인터랙션에서 화면이 느려지는 현상이 보고됐고, React DevTools Profiler로 분석하니 상위 컴포넌트 상태 변경이 관련 없는 하위 컴포넌트까지 리렌더링시키는 구조였습니다.
`React.memo`와 `useMemo`를 선택적으로 적용하고 상태를 필요한 범위에만 위치시키는 방식으로 리렌더링을 줄였습니다. 성능 문제는 측정 없이 최적화하면 방향이 틀리는 경우가 많아 Profiler로 먼저 확인하는 습관이 생겼습니다. 측정 없는 최적화는 방향이 틀릴 수 있습니다.
Profiler로 리렌더링 구조를 먼저 분석합니다. 상태 위치와 memo 적용이 렌더링 최적화의 핵심입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.