이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트와 인턴 경험을 통해 프론트엔드 개발 역량을 쌓아왔습니다. React를 주로 써왔는데, 처음에는 상태가 복잡해지면서 컴포넌트 간 데이터 흐름을 추적하기 어렵다는 문제를 경험했습니다. 그 이후로 상태를 가능한 한 아래 컴포넌트에 두고 위로 올릴 때만 올리는 방식을 기본으로 삼았습니다. 인턴 때 트래픽이 많은 페이지를 담당하면서 React.memo와 useMemo로 불필요한 리렌더링을 줄이는 최적화를 처음 해봤습니다.
CDN 설정과 번들 크기 최적화가 로딩 속도에 직접 영향을 준다는 걸 실제 지표로 확인했습니다. 코드 스플리팅으로 초기 번들을 나누니 첫 페이지 로딩 시간이 눈에 띄게 줄어드는 효과를 봤습니다. 프론트엔드 성능은 기능 완성 후 최적화가 아니라 구조 설계 단계부터 고려하는 자리라는 걸 배웠습니다.
인턴 기간에 대시보드 페이지를 오래 열어두면 브라우저가 느려지는 문제가 반복됐습니다. 처음에는 데이터 양이 많아서라고 봤는데, DevTools의 Memory 탭으로 힙 스냅샷을 찍어보니 컴포넌트 언마운트 후에도 이벤트 리스너가 계속 남아 있었습니다. 안에서 WebSocket 연결을 열고 정리 함수를 빠뜨린 게 원인이었습니다. 처음에는 왜 정리 함수가 필요한지 체감하지 못했는데, 이 디버깅으로 React 컴포넌트 수명과 사이드 이펙트 정리 시점이 어떻게 맞물리는지를 직접 확인했습니다.
cleanup 함수를 추가한 뒤 5분 이상 사용해도 메모리 사용량이 안정적으로 유지됐습니다. 이후 useEffect를 쓸 때는 정리 함수가 없어도 되는 케이스인지를 먼저 체크하는 습관이 생겼습니다.
학부 프로젝트에서 랜딩 페이지가 느리다는 피드백이 들어왔을 때, 막연히 서버 응답 속도 문제라고 생각했습니다. 로 진단해 보니 LCP가 4.2초로, 큰 이미지 여러 장이 한꺼번에 로드되는 게 주된 원인이었습니다. 레이지 로딩을 적용해 뷰포트 밖 이미지는 스크롤할 때 로드되도록 바꾸고, 사용 빈도가 낮은 컴포넌트는 로 분리해 초기 번들을 줄였습니다. 처음에는 lazy 속성을 히어로 이미지에도 붙여서 오히려 첫 화면 로딩이 더 느려지는 실수를 했습니다. 히어로 이미지만 우선 로드로 되돌리고 나머지에만 레이지 로딩을 적용하자 LCP가 1.8초로 줄었습니다. 성능 개선은 도구로 측정한 수치 없이는 방향을 잡기 어렵다는 걸 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.