웹 아키텍처: 렌더링 전략을 미리 선택하세요은(는) 무엇을 하나요?
Claude가 기본적으로 선택하는 두 가지는 대부분 틀렸습니다: 모든 것을 브라우저에서 렌더링하는 것, 그리고 바닐라 HTML/JS로 멀티 페이지 앱을 수동 구축하는 것입니다. 둘 다 의도적인 사전 선택이어야 하며, 대부분의 실제 사이트에서 더 나은 답은 서버 렌더링 HTML과 프레임워크입니다. 사용자가 묻지 않았더라도 이를 제기하세요. 프로덕션 환경에 WAF를 적용하는 것과 같은 방식입니다.
클라이언트 렌더링이 아닌 서버 렌더링 HTML을 기본값으로
콘텐츠, SEO, 또는 초기 페인트가 중요한 모든 경우, 콘텐츠는 초기 HTML 응답에 포함되어야 하며 클라이언트 JavaScript가 그린 이후에 표시되어서는 안 됩니다. 클라이언트 측 렌더링(번들을 가져와 브라우저에서 렌더링하는 빈 셸)은 번들이 로드되고 실행될 때까지 빈 화면, 느린 LCP, 그리고 많은 크롤러와 LLM 검색기가 JavaScript를 안정적으로 실행하지 않기 때문에 볼 수 없는 콘텐츠를 의미합니다. 대신 서버에서 렌더링하세요:
- SSG (정적 생성): 빌드 시 렌더링하고 CDN에서 정적으로 제공합니다. 가장 빠르고, 가장 저렴하며, 가장 캐싱이 용이합니다. 요청마다 변경되지 않는 콘텐츠(마케팅, 문서, 블로그, 목록 및 카테고리 페이지로 재빌드 가능)의 기본값입니다.
- SSR (서버 사이드 렌더링): 서버에서 요청별로 렌더링합니다. 빌드 시 미리 생성할 수 없는 동적, 개인화, 또는 인증이 필요한 콘텐츠에 사용합니다.
- CSR / 아일랜드: 진정으로 상호작용이 필요한 부분이나 로그인 뒤의 대시보드처럼 SEO가 무의미한 앱과 유사한 표면에서만 브라우저에서 렌더링합니다. 아일랜드 접근 방식(Astro)에서는 페이지가 정적 HTML로 제공되고 상호작용 컴포넌트만 하이드레이션됩니다.
페이지마다 선택할 수 있으며, 혼합할 수도 있습니다: 동일한 사이트에서 정적 마케팅 페이지(SSG), 개인화된 계정 페이지(SSR), 대화형 위젯(아일랜드).
여러 페이지는 프레임워크를 사용하세요
프로젝트에 여러 페이지, 공유 레이아웃, 라우팅, 또는 실제 데이터 가져오기가 있다면 바닐라 JS로 수동 구축하는 것은 유지보수 및 성능의 함정이며, 달리 지시하지 않는 한 Claude의 기본값입니다. 프레임워크(Next.js, Astro, SvelteKit, Nuxt, Remix)를 사용하세요. 이들은 라우팅, SSR 및 SSG, 코드 분할, 데이터 로딩, 이미지 최적화를 기본으로 제공하며, 중요한 것은 서버 렌더링된 초기 HTML 위에 SPA 스타일의 클라이언트 탐색을 제공하여 초기 페인트와 SEO를 망치는 빈 클라이언트 전용 SPA를 제공하지 않으면서도 부드러운 멀티 페이지 앱 느낌을 줍니다.
차이점에 주목하세요: 순수 클라이언트 렌더링 SPA는 콘텐츠 사이트에서 피해야 할 대상입니다. SSR/SSG와 클라이언트 측 탐색을 수행하는 프레임워크는 앱 경험을 제공하면서도 콘텐츠를 HTML에 유지합니다.
하지만 도구를 프로젝트에 맞추세요
과도하게 교정하지 마세요. 단일 정적 페이지, 랜딩 페이지, 또는 작은 임베드 가능한 위젯은 Next.js가 필요하지 않습니다. 일반 HTML과 CSS가 올바르고 더 가벼운 선택이며, 거기에 무거운 프레임워크를 사용하는 것은 그 자체로 실수입니다. 실패는 양방향으로 발생합니다; 일반적인 경우는 과소 선택(모든 것을 바닐라로 브라우저에서 렌더링)이지만, 사소한 페이지를 과도하게 엔지니어링하는 것도 실제로 존재합니다. 결정 기준은: 페이지 수는 몇 개인가, 콘텐츠를 크롤링 가능하고 빠르게 제공해야 하는가, 상호작용성은 얼마나 필요한가입니다. 그런 다음 이를 충족하는 가장 가벼운 것을 선택하세요.
이 스킬은 성장하도록 설계되었습니다. 실제 아키텍처 호출에 안정적이고 방어 가능한 답변이 있을 때 규칙을 추가하세요.