이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트로 할 일 관리 웹앱을 만들 때 가장 어려웠던 건 드래그앤드롭 기능을 라이브러리 없이 직접 구현하는 부분이었습니다. 마우스 이벤트 좌표 계산과 드롭 대상 판별 로직이 예상보다 복잡했는데, 처음에는 mouseup 이벤트로 드롭 위치를 계산했다가 빠르게 움직일 때 이벤트가 대상 요소 바깥에서 발생하는 문제가 생겼습니다. 문서를 찾아보다 `document` 레벨에서 이벤트를 잡아야 한다는 걸 알게 됐고, 드래그 중인 아이템 인덱스를 ref로 관리하면서 대상 요소 순서를 실시간으로 계산하는 방식으로 바꿨습니다. 이후 터치 이벤트 지원도 추가해야 해서 터치·마우스 이벤트를 공통 핸들러로 묶는 구조로 리팩토링했습니다. 결과적으로 원하던 동작을 완성했고, 이 경험을 통해 브라우저 이벤트 모델을 직접 다뤄보는 것이 큰 공부가 됐습니다.
팀 프로젝트로 만든 일정 공유 웹앱에서 가장 어려웠던 건 데이터가 늘어날수록 달력 렌더링이 눈에 띄게 느려지는 문제였습니다. 처음에는 원인을 파악하지 않고 useMemo를 여러 곳에 붙여봤는데, 오히려 상태 업데이트 흐름이 꼬여 버그가 더 생겼습니다. 최적화 도구를 원인 파악 전에 갖다 붙인 것이 실수였습니다.
React DevTools Profiler로 실제 렌더링 시간을 측정해보니, 문제는 메모이제이션이 아니라 거대한 단일 컴포넌트가 데이터 전체를 한 번에 계산하는 구조에 있었습니다. 컴포넌트를 주차 단위로 나누고, 필요한 범위만 계산하는 방식으로 바꾸자 체감 속도가 확실히 개선됐습니다. 이 경험 이후 성능 문제를 만나면 측정 먼저, 최적화 나중 순서를 지키게 됐습니다. 도구를 믿기 전에 데이터를 보는 습관이 그 프로젝트에서 얻은 가장 큰 수확이었습니다.
포트폴리오용으로 혼자 만든 뮤직 플레이어 앱에서 예상 못 한 문제는 키보드만으로 조작이 아예 안 되는 구조였습니다. 디자이너 없이 혼자 UI를 짜다 보니 접근성을 처음부터 고려하지 않았고, 친구에게 리뷰를 부탁했을 때 탭 키로 버튼에 포커스가 가지 않는다는 피드백을 처음 들었습니다.
tabIndex와 aria-label 속성을 추가하는 것부터 시작했는데, 어디에 어떻게 붙여야 하는지 감이 없어서 몇 번을 다시 했습니다. MDN 문서와 WCAG 2.1 가이드라인을 참고하면서 포커스 순서와 역할 속성 구조를 잡아나갔습니다. 완전한 접근성 준수는 아직 부족하다고 생각하지만, 화면 낭독기로 직접 테스트하면서 개선 포인트를 찾는 방식은 이후 프로젝트에서도 유지하고 있습니다. 혼자 전체를 맡을 때 놓치기 쉬운 영역이 따로 있다는 것을 배운 경험이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.