이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트로 만든 서비스가 검색에 노출이 안 된다는 피드백이 들어왔습니다. SPA로 만들었기 때문에 크롤러가 내용을 읽지 못하는 것이 원인이었습니다.
Next.js로 마이그레이션을 시도했습니다. 페이지 컴포넌트에 getServerSideProps를 추가하여 서버에서 데이터를 받아 HTML로 내려보내는 방식이었습니다. 처음에는 클라이언트에서만 사용하던 localStorage 접근 코드가 서버에서 실행되면서 에러가 발생했는데, 브라우저 API는 클라이언트 사이드 체크를 추가하여 해결했습니다.
적용 후 구글 크롤러가 내용을 읽기 시작했고 검색 결과에 나타나기 시작했습니다. SSR이 모든 상황에 필요한 것이 아니라 검색 노출이나 초기 로딩 속도가 중요한 페이지에 선택적으로 사용하는 것이 맞다는 것을 배웠습니다. 그 경험이 렌더링 방식을 맥락에 따라 선택하는 시각을 만들어주었습니다.
개인 프로젝트에서 SPA로 만들었을 때 처음 화면이 뜨는 데 빈 화면이 잠깐 보이는 문제가 있었어요. 데이터를 클라이언트에서 불러오다 보니 로딩 중에 아무것도 없는 상태가 생겼습니다.
SSR을 적용하면 서버에서 이미 데이터가 채워진 HTML을 받으니까 빈 화면 없이 바로 콘텐츠가 보이는 구조가 됐어요. 처음엔 서버와 클라이언트의 HTML이 다를 때 하이드레이션 에러가 나는 문제가 있었는데, 서버와 클라이언트에서 같은 데이터를 쓰도록 구조를 맞추면서 해결됐습니다.
그 경험에서 SSR의 장점이 SEO만이 아니라 사용자가 처음 보는 화면 경험에도 영향을 준다는 걸 배웠어요. 어떤 방식이 맞는지는 서비스 성격에 따라 다르다는 것도요. 그 경험 덕분에 한 단계 성장할 수 있었습니다.
Next.js 프로젝트에서 모든 페이지를 SSR로 만들었더니 서버 부하가 늘고 오히려 느려지는 경우가 생겼어요. SSR이 좋다고 해서 다 적용했던 게 실수였습니다.
각 페이지 성격을 분석해서 검색 노출이 필요하거나 초기 데이터가 중요한 페이지는 SSR, 그 외는 CSR로 분리했어요. 마이페이지처럼 검색 필요 없는 페이지는 CSR로 두고, 상품 목록처럼 검색에 나와야 하는 페이지는 SSR을 유지했습니다. 처음엔 어떤 기준으로 나눌지 모호했는데, '크롤러가 읽어야 하는가'와 '초기 화면 속도가 중요한가'를 기준으로 삼으니 명확해졌어요.
렌더링 방식은 하나를 전부 적용하는 게 아니라 페이지마다 맞는 방식을 선택해야 한다는 걸 그 경험에서 배웠습니다. 그 경험이 렌더링 전략을 의식적으로 결정하게 해줬어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.