A
약 90초
기술 경험 중심 1인칭 답변
팀 프로젝트에서 Next.js를 사용해 콘텐츠 서비스의 SSR 기반 웹 서비스를 구현한 경험이 있습니다. 초기에는 CSR로 개발했는데, 검색 크롤러가 동적 렌더링 페이지를 제대로 인덱싱하지 못해 SEO 점수가 낮게 나오는 문제가 있었습니다. SSR로 전환하면서 서버에서 HTML을 완성해 전달하니 초기 로딩 속도와 LCP 지표가 개선됐습니다. 다만 서버 부하가 늘어나는 부분은 getStaticProps를 적용할 수 있는 정적 페이지와 SSR이 필요한 동적 페이지를 분리해 처리했습니다. 이 과정에서 캐시 전략과 revalidate 설정이 실시간성과 서버 비용 사이의 균형을 조절하는 핵심 파라미터임을 배웠습니다.
SSR은 무조건 적용하는 것이 아니라 페이지 성격에 따라 정적·동적 렌더링을 혼합해 사용하는 것이 더 현실적인 접근입니다. 앞으로도 페이지 성격에 따라 SSR과 정적 생성을 혼합하는 방식으로 Next.js 서비스를 설계하겠습니다. revalidate 설정이 실시간성과 서버 비용 사이의 균형을 조절하는 핵심 파라미터입니다. 캐시 전략을 잘못 설계하면 데이터 신선도와 성능 모두를 잃는 결과가 생길 수 있습니다.
이 결의 특징
CSR에서 SEO 문제를 겪고 SSR로 전환한 흔적을 구체적으로 짚고, getStaticProps와 SSR을 페이지 성격별로 나눠 서버 부하를 관리한 결이 있습니다.
이 결이 통하는 자리
LCP 개선 수치와 revalidate 설정이 구체적으로 살아 있을 때 통합니다. SSR을 일괄 적용하지 않고 정적·동적을 혼합한다는 판단이 붙을 때 면접관이 실무 균형 감각을 읽는 결이 보입니다.