Yoo HeehyeonYoo Heehyeon

1. 메인페이지 사전 렌더링에 대해

"웹사이트의 첫 화면을 빠르게 만들면서도, 일부 영역의 최신성과 개인화는 어떻게 유지할 것인가?"

이 질문은 단순한 최적화 팁이 아니라 렌더링 전략의 문제다. 메인페이지는 대개 가장 많이 조회되고, 가장 많은 데이터를 붙이며, 사용자 체감 성능에 가장 큰 영향을 주는 화면이다.
그래서 여기서의 판단은 단순히 메인 하나의 문제가 아니라 서비스 전체의 아키텍처 방향을 좌우한다.

이번에는 다음 내용을 정리했다.

• 왜 메인페이지는 구조적으로 무거워지기 쉬운지
• 정적 생성이 왜 강력한지
• 왜 정적 생성만으로는 끝나지 않는지
• HTMX가 어떤 종류의 문제를 풀어 주는지
• 이 방식이 어디까지 유효하고, 어디서부터 다른 도구가 필요한지

2. 문제 정의

메인페이지가 느려지는 이유는 단순히 컴포넌트가 많아서라기 보다는 한 화면 안에 요구사항이 서로 다른 데이터가 섞여 있기 때문으로 이해하고 있다.
예를 들어 메인페이지에 이런 요소가 있다고 하자.

• 하루에 한 번만 바뀌는 메인 배너
• 수시로 바뀌는 공지사항
• 몇 시간 단위로 바뀌는 인기 콘텐츠
• 로그인 사용자별로 달라지는 개인화 영역
• 외부 API를 붙여야 하는 추천 블록

문제는 이것들을 모두 같은 렌더링 전략으로 처리하려 할 때 발생한다. 만약 이것들을 전부 요청 시점에 렌더링하면 최신성은 좋지만 응답이 무거워진다.
반대로 전부 미리 생성하면 빠르지만 오래된 데이터가 표시된다.

핵심은 정적vs동적을 선택하는 것이 아니라 같은 페이지 안에서도 데이터의 생명주기가 다르다는 점이다.

3. 메인페이지 정적화의 강력함

메인페이지를 통째로 정적 HTML로 미리 생성해 둘 수 있을까?
스케줄러가 주기적으로 DB와 외부 API를 조회한 뒤 HTML을 만들어 저장하고, 실제 사용자 요청에는 그 결과물을 서빙하는 형태다.

이 전략이 강한 이유는 명확하게 보인다.

• 요청 시점의 DB 조회를 제거할 수 있다.
• 외부 API 지연이 사용자 응답 시간에 직접 반영되지 않는다.
• 애플리케이션 서버의 CPU/메모리 부하가 줄어든다.
• 캐시 전략이 단순해진다.
• TTFB와 초기 렌더 속도가 좋아진다.

단순 캐싱과는 무엇이 다를까?
캐시가 요청 후 결과를 저장하는 느낌이라면, 여기서 말하는 정적화는 아예 응답의 출처를 런타임 계산에서 사전 생성물로 바꾸는 것에 가깝다.
최적화가 아니라 공급 방식의 전환이라는 것이다.

4. 진짜 문제

정적화에는 단순히 최신 데이터가 아닐 수 있다는 문제에서 끝나지 않고 실제로 세 가지 문제의 계층이 있다.

• 시간 기반 신선도 문제:
  스케줄러가 하루에 한 번 돈다면 하루 안에 바뀐 정보는 표시되지 않는다. 이벤트 종료, 인기 키워드 변동, 공지 수정처럼 생각보다 많은 변화가 이 범주에 들어간다.
• 사용자별 개인화 문제:
  정적으로 구운 HTML에는 특정 사용자의 상태를 넣을 수 없다. 로그인 사용자 이름, 개인 추천, 최근 본 항목 같은 요소는 공용 HTML에 섞는 순간 캐시와 보안이 동시에 꼬인다.
• 장애의 전파 방식 문제:
  실시간 렌더링은 느리더라도 최신 데이터를 보장할 수 있다. 반면 정적 생성은 생성 시점에 실패하면 오래된 결과물이 계속 살아는다. 즉, 실패가 요청 시점이 아니라 배치 시점에서 일어난다.

이 세 가지를 이해하면 '정적화하면 빨라진다'는 말을 실무 수준으로 끌고 올 수 있을 것이다.

5. 문제를 푸는 기존의 방식들

iframe, CSR/AJAX를 비교해서 각각이 어떤 비용 구조를 가지는지 보자.

• iframe: 분리에는 좋지만 통합에는 약하다. iframe은 동적인 부분을 아예 별도 문서로 떼어내는 방식이다. 장점으로는 구현이 단순하고, 경계를 분명히 나눌 수 있으며, 독립 배포나 외부 위젯 삽입에 유리하다. 그러나 단점으로는 디자인 시스템과 자연스럽게 통합되기 어렵고, 높이, 스크롤, 반응형 처리가 까다로우며, 접근성과 상태 공유가 불편하다. 메인 콘텐츠 일부처럼 보이는 영역에는 이질감도 생긴다. 즉 iframe은 "독립된 앱을 박아 넣는 방식"이지, "한 페이지의 일부를 자연스럽게 갱신하는 방식"은 아니다.

• CSR/AJAX: 유연하지만 요청 비용 문제가 있다. 페이지가 로드된 뒤 브라우저가 JSON을 요청하고, 자바스크립트가 DOM을 다시 그리는 방식으로 인터랙션이 자유롭고, 클라이언트 상태와 쉽게 연결되며 사용자별 동작을 세밀하게 제어할 수 있다는 장점이 있지만, 페이지 로드 시점마다 서버 조회 비용이 다시 발생하고, JSON을 화면 구조로 변환하는 프론트 로직이 필요하며 SEO나 초기 렌더 측면에서 불리할 수 있다. 단순한 읽기 중심 블록에도 과한 클라이언트 책임이 생기는 문제도 있다. 즉 CSR은 강력하지만, 메인페이지의 일부를 최신화하는 문제에 대해서는 오버 엔지니어링이 되는 경향이 있다.

6. HTMX를 통해 얻는 구조적 이점

핵심은 HTMX이다. 단순한 편의 라이브러리가 아니라 정적 페이지 안에 동적 프래그먼트를 안전하게 삽입하는 도구로 쓰는 것인데,
HTMX 방식에서는 브라우저가 JSON을 받아 렌더링하지 않는다는 점이 주요 포인트이다.
HTMX는 서버가 이미 렌더링한 HTML 조각을 받아서 페이지 일부에 교체한다.

결국 다음과 같은 장점이 있다.

• 서버가 마크업의 최종 형태를 통제한다.
• 클라이언트는 상태 머신 대신 '언제 가져오고 어디에 넣을지'만 안다.
• 기존 SSR/템플릿 기반 애플리케이션과 잘 맞는다.
• 페이지 일부만 동적으로 바꾸면서도 서버 주도 UI 흐름을 유지할 수 있다.

즉 HTMX의 장점은 자바스크립트를 안 써도 된다가 아니라, 클라이언트가 렌더링 책임을 과하게 가져가지 않아도 된다는 데 있다.

7. 아키텍처 포인트

메인페이지 전체를 다시 그리지 말라는 이야기가 있다.
좀 더 기술적으로 풀면 이렇다.

• 전체 페이지는 static shell로 둔다.
• 자주 바뀌는 일부는 dynamic fragment로 분리한다.
• fragment는 필요 시점에만 교체한다.
• fragment의 갱신 주기는 각 블록별로 다르게 둔다.

이 전략은 결국 페이지를 단일 렌더링 단위로 보지 않고, 신선도? 같은 단위로 분해해서 본다는 뜻이다.
많은 서비스가 여전히 '이 페이지는 SSR', '이 페이지는 CSR'처럼 페이지 단위로 렌더링 전략을 잡는다. 나도 그렇고.
하지만 실제 사용성이나 UX는 페이지 전체가 아니라 블록별 신선도 요구사항에 의해 결정되는 경우를 생각해보라는 것이다.

8. 실무에서 생각해볼만한 점

정말 실시간이어야 하는가?

• 개발자가 "동적"이라고 부르는 것 중 상당수는 사실 실시간이 아니다.
• 인기 콘텐츠는 10분~1시간 캐시도 충분한 경우가 많다.
• 추천 블록은 배치 계산 후 정적 조각으로 내려도 체감상 문제없는 경우가 많다.
• 개인화 영역은 로그인 시 1회 로드면 충분할 수 있다.
  즉 동적이라는 말은 종종 요청마다 다시 계산과 혼동된다. 이걸 분리해야 한다.

fragment도 미리 구울 수 있다

• 동적 영역조차도 매 요청마다 계산할 필요가 있을까?
• 예를 들어 메인페이지는 하루 단위로, 인기 블록은 1시간 단위로, 공지 블록은 10분 단위로 각각 따로 생성해 둘 수 있다.
• 그러면 사용자는 메인 셸과 조각을 가져오기만 하면 되고, 서버는 런타임 계산 대신 정적 산출물을 조합하게 된다.
• 생각보다 강력해 보인다. 왜냐하면 동적 fragment라고 해도 사실상 갱신 주기가 더 짧은 정적 산출물로 운영할 수 있기 때문이다.

개인화는 공용 캐시 영역과 분리해야

• 로그인 사용자 정보는 정적 fragment와 섞으면 안 된다. 공용 캐시와 개인 데이터를 섞는 순간 캐시 오염, 보안 사고, 잘못된 사용자 노출 문제가 발생한다.
• 따라서 개인화 블록은 보통 페이지 로드 후 사용자 세션 기준으로 별도 요청, 인증된 API 응답을 서버에서 부분 렌더링, edge/session-aware rendering 중 하나로 처리해야 한다.
• 부분 동적 갱신 안에서도 공용 데이터와 개인 데이터는 같은 종류가 아니라는 점이다.

9. 이 방식이 특히 잘 맞는 서비스가 뭘까

모든 서비스에 만능은 아닐 것이다. 다음 조건에서 특히 잘 맞을 것 같다.

• 읽기 중심의 메인페이지
• 초기 인상과 속도 체감이 중요한 랜딩 화면
• 데이터 소스가 많아 요청 시점 조립 비용이 큰 화면
• 일부 블록만 신선도가 필요한 화면
• 서버 중심 템플릿 또는 SSR 흐름을 이미 갖춘 시스템

반대로 이런 경우엔 한계가 빨리 온다.

• 강한 사용자 인터랙션이 핵심인 대시보드
• 클라이언트 상태 동기화가 복잡한 화면
• 오프라인 상태, 드래그 앤 드롭, 복합 폼 같은 앱형 UI
  HTMX는 React를 대체하는 만능 솔루션이 아니라, 읽기 중심 페이지에서 클라이언트 복잡도를 낮추는 데 특화된 도구로 보는 편이 정확하겠다.

결론

웹 성능 최적화는 페이지를 정적으로 만들지 동적으로 만들지의 문제가 아니라, 같은 페이지 안에서 무엇을 언제 다시 계산해야 하는지를 구분하는 문제다.
즉 메인페이지 최적화의 본질은 렌더링 기술 선택이 아니라 신선도의 예산을 설계하는 일에 가깝다.
정적으로 구울 수 있는 것은 최대한 구워서 빠른 뼈대를 만들고, 정말 바뀌어야 하는 조각만 더 짧은 주기로 따로 갱신한다. 그리고 개인화는 공용 조각과 섞지 않는다.
이 관점을 잡고 보면 HTMX는 단순한 라이브러리가 아니라, 정적 셸 + 동적 프래그먼트라는 아키텍처를 구현하는 매우 가벼운 도구로 보인다.

전체를 다시 그리지 말고, 바뀌는 부분만 바꿔라.