이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Next.js App Router로 블로그 플랫폼을 만들면서 서버 컴포넌트와 클라이언트 컴포넌트 경계 설정이 가장 도전적이었습니다. 처음에 상태 관리 라이브러리를 서버 컴포넌트에서 import했다가 빌드 오류가 계속 났고, 원인을 파악하니 use client 지시어 없이 브라우저 API를 사용하는 패키지를 서버에서 불러온 문제였습니다.
컴포넌트 트리의 경계선을 명시적으로 정의하는 패턴을 도입해, 서버에서 내려주는 데이터와 클라이언트에서만 필요한 인터랙션을 분리했습니다. 이후 초기 로딩 속도가 1.8초에서 0.9초로 줄었고 번들 크기도 30% 감소했습니다. 이 경험으로 렌더링 경계 설계가 Next.js 성능의 핵심이라는 것을 직접 확인했습니다.
포트폴리오 사이트를 Next.js로 만들면서 초기 로딩이 느리다는 것을 확인하고 원인을 찾아봤습니다. 페이지에 여러 컴포넌트가 있었는데 처음 방문할 때 사용하지 않는 컴포넌트까지 모두 불러오는 것이 문제였습니다. dynamic import를 사용해서 처음에 보이지 않는 컴포넌트는 필요할 때 불러오도록 바꾸고, 이미지도 next/image의 lazy loading을 활용해서 뷰포트 안에 들어올 때만 불러오도록 설정했습니다. 빌드 결과에서 번들 크기가 40% 줄었고, 페이지 인터랙티브 시점이 체감할 수 있을 정도로 빨라졌습니다. Next.js가 제공하는 최적화 도구를 쓰는 것과 컴포넌트 로딩 순서를 의식하는 것을 함께 해야 성능 개선의 폭이 크다는 것을 이 경험에서 배웠습니다.
Next.js로 콘텐츠 목록 페이지를 만들면서 모든 데이터를 클라이언트에서 불러오도록 구현했는데, 목록이 많아질수록 페이지가 느려지는 것을 경험했습니다. 사용자가 페이지에 처음 접근했을 때 데이터를 요청하는 구조라서 데이터를 받아오는 동안 빈 화면이 보이는 시간이 길었습니다. 목록 데이터는 자주 바뀌지 않는 것이어서 getStaticProps로 빌드 타임에 생성하고 revalidate로 일정 주기로 갱신하는 방식으로 바꿨습니다. 데이터 패칭 방식을 바꾸니 첫 방문 시 빈 화면 없이 바로 콘텐츠가 보이게 됐습니다. Next.js에서 데이터 패칭 전략을 선택하는 것은 성능과 데이터 신선도를 맞바꾸는 결정이고, 각 페이지의 특성에 맞게 선택해야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.