Zyke 구축: HTMX·Redis·CKEditor 기반 고성능 커뮤니티 플랫폼

출처: Dev.to

완벽한 SEO를 위한 서버 사이드 렌더링

Zyke(zyke.social)를 만들기 위해 시작했을 때 목표는 아주 단순했습니다. 엄청나게 빠르고, 검색 엔진에 최적화돼 있으며, 사용자가 글을 쓰는 것이 즐거운 커뮤니티 플랫폼을 만들고 싶었습니다. 현대 웹은 무거운 JavaScript 프레임워크로 인해 종종 과부하가 걸리지만, 저는 다른 접근 방식을 선택했습니다. 서버 사이드 렌더링(SSR)과 HTMX, Redis, 그리고 견고한 백엔드를 결합해 모든 면에서 뛰어난 아키텍처를 만들었습니다.
아래는 Zyke가 어떻게 구현됐는지 내부 구조를 살펴본 내용입니다.

완벽한 SEO를 위한 서버 사이드 렌더링

검색 엔진 최적화(SEO)는 모든 공개 포럼의 생명줄입니다. 검색 엔진이 콘텐츠를 효율적으로 색인하지 못하면 커뮤니티는 성장할 수 없습니다. 저는 Python과 Jinja2 템플릿을 사용한 전통적인 SSR 방식을 선택하고, 동적인 클라이언트‑사이드 인터랙션을 위해 HTMX를 추가했습니다.

HTML이 서버에서 완전히 렌더링되기 때문에 웹 크롤러는 사용자가 보는 그대로의 콘텐츠를 즉시 확인합니다. JavaScript 번들이 실행되어 DOM이 채워지기를 기다릴 필요가 없습니다. 또한 모든 페이지에 포괄적인 JSON‑LD 구조화 데이터를 구현했습니다. 홈 페이지의 WebSite 스키마부터 깊이 있는 토론을 위한 BreadcrumbList와 Article 스키마까지, 검색 엔진은 언제나 페이지 계층 구조를 정확히 파악합니다. 동적인 Open Graph와 Twitter Card 메타 태그 덕분에 사용자가 게시물을 공유할 때마다 링크 미리보기가 완벽하게 표시됩니다.

CKEditor 5로 풍부한 콘텐츠 제작

포럼은 사용자가 만들어 내는 콘텐츠만큼이나 가치가 있습니다. 저는 풍부한 텍스트, 인라인 이미지, 미디어 임베드를 완벽히 처리할 수 있는 편집기가 필요했습니다. 프론트엔드에 CKEditor 5를 통합했지만, 기본 설정만 사용하지는 않았습니다.

성능과 저장소 효율을 높이기 위해 맞춤형 업로드 어댑터를 직접 구현했습니다. 사용자가 편집기에 이미지를 붙여넣거나 업로드하면, 표준 base64 인코딩을 전혀 거치지 않고 바로 백엔드로 전송됩니다. 백엔드에서는 이미지를 압축한 뒤 Cloudinary에 직접 업로드하고, 보안된 CDN URL을 편집기에 반환합니다. 이렇게 하면 데이터베이스가 가볍게 유지되고, 사용자 생성 콘텐츠가 전 세계에 번개처럼 빠르게 전달됩니다. 최종 HTML은 완벽히 포맷되어 모든 디바이스에서 아름답게 렌더링됩니다.

Redis로 홈 페이지 확장

홈 페이지 피드는 Zyke에서 가장 많이 방문되는 영역입니다. 모든 방문자에게 정렬된 게시물 피드를 생성하려면 비용이 많이 드는 데이터베이스 쿼리가 필요합니다. 트래픽이 증가함에 따라 PostgreSQL을 매 요청마다 직접 조회하는 방식은 절대 확장되지 않습니다.

이를 해결하기 위해 Redis를 캐시 레이어로 도입했습니다. 메인 홈 피드, 트렌딩 섹션, 인기 게시물 모두 메모리에 캐시됩니다. 사용자가 첫 페이지를 요청하면 서버는 미리 계산된 데이터를 Redis에서 바로 가져옵니다. 이 덕분에 응답 시간이 몇 밀리초 수준으로 단축됩니다. 캐시 무효화는 전략적으로 처리합니다. 새 게시물이 생성되거나 투표 수가 특정 임계값에 도달하면 백그라운드에서 Redis 캐시를 업데이트합니다. 이렇게 하면 기본 데이터베이스에 과부하를 주지 않으면서 피드가 항상 최신 상태를 유지합니다.

결론

Zyke를 구축하는 과정은 성능, SEO, 사용자 경험을 균형 있게 맞추는 놀라운 솔로 여정이었습니다. Redis의 속도, CKEditor의 풍부한 포맷팅 기능, 서버 렌더링 HTML이 제공하는 막대한 SEO 이점을 활용해 즉시 반응하는 플랫폼을 만들었습니다. 이 스택은 동적인 웹 앱을 만들 때 반드시 거대한 싱글 페이지 애플리케이션이 필요하지 않다는 것을 증명합니다. 때로는 서버 사이드 렌더링과 몇 가지 잘 선택된 도구만으로도 원하는 결과를 얻을 수 있습니다.