안녕하세요! 댓글 남겨 주셔서 감사합니다. (사실 무관심 속에 뭍힐 거라 생각했는데 감동입니다)
질문해주신 내용들이 저도 고민을 굉장히 많이 했었는데, 그냥 이런 생각도 있구나 하고 봐주시면 좋겠습니다.
아, 참고로 저는 PHP 이후로는 현생에서 단 한번도 웹개발을 이어간 적이 없었습니다. Node.js 개혁의 시대도, React가 웹 세상을 바꿀 때도 관심을 두지 않았었기 때문에 다소 생소한 관점도 있을 수 있겠습니다. ㅎㅎ
- 백엔드를 왜 Node.js 호환되게 하지 않았나?
저는 처음에 TSBOARD를 개발할 때, 이미 Node.js 기반의 (제가 모르는) 유명한 게시판이나 블로그나 여하간 제가 만들려던 거랑 유사한 게 있을거라고 지레짐작했습니다. 서두에도 언급했지만 현생에서 웹개발을 할 일이 없기도 했고, 따로 사이드 프로젝트라는 걸 해본적이 없어서 더 그랬던 것 같습니다. 저는 당연히 Node.js 기반으로 나온 뭔가가 있을텐데 내가 또 새로운 걸 하는 건 큰 의미가 없겠다 싶어서 기왕 새로 배우는 거 Bun 기반으로 해보자, 하고 결정한 게 지금까지 오게 되었습니다.
퍼포먼스 문제를 고민해보면, 사실 제가 목표로 했던 소규모 커뮤니티 사이트 (동접 10명 미만) 에서는 Node.js 로 충분하다고 생각합니다. Bun 검토하기 전에 Node.js + Hono 기반으로도 테스트를 해봤었는데 사실 제 생각엔 문제가 없었습니다. 그러나 Bun 이 제시했던 압도적인 퍼포먼스와 더불어, 그 Bun 을 기반으로하는 ElysiaJS 퍼포먼스가 정말 인상적이어서, 이걸 포기하고 싶지 않았습니다. 이미 다른 누군가가 Node.js 기반으로 훌륭하게 만든 게시판이 있을 거라 생각한 저는 그 가상의 게시판과 경쟁하려면 더 높은 퍼포먼스가 필요하다고 생각했고, 결국 Node.js 호환성을 포기하고 Bun 의존적으로 설계를 하게 되었습니다. (지금은 살짝 후회중입니다. Node.js 기반으로 그누보드나 라이믹스, XE 같은 유명한 게시판이 없...더라구요. 제가 못찾은 걸까요??)
- CSR을 선택하면 SEO는?
말씀하신 부분이 전적으로 맞습니다. 검색 유입을 하려면 어쨌든 구글 크롤러가 내용을 읽어드리고, 검색 매칭이 되도록 해야 합니다. 이 부분은 아직 구현하지 않았습니다만, 사용자가 원할 경우 마치 RSS 피드를 노출하는 것처럼 최신 컨텐츠들을 정적 형태로 따로 공유하면 어떨까 생각하고 있습니다. JSON 형태로 외부 노출을 하면 수집기가 더 편하게 데이터를 갱신할 수 있지 않을까? 하는 생각을 가지고 있는데 좀 더 고민해 보겠습니다. (RSS 를 생각했었는데 요즘엔 이걸 대부분 안쓰시더라구요?? 제가 너무 오래 웹을 안했나봐요 ㅠ)
SEO 보완책과는 별개로, CSR로 간 이유는 서버 부담을 좀 더 적극적으로 줄이고자 했기 때문입니다. 최근에 생긴 다모앙(이거 커뮤니티 이름을 막 공개해도 되나 모르겠네요) 사이트의 경우에도 트래픽 부하나 서버 부담이 상당히 되는 걸로 알고 있습니다. 커뮤니티 빌더라는 걸 생각했을 때 SEO도 중요하지만 우선 비용과 직결되는 문제부터 해결해야겠다는 생각에 CSR를 우선적으로 선택하였습니다. PHP를 여전히 사랑하는 저로서는 SSR이 오히려 익숙합니다만, 클라이언트가 좀 더 적극적으로 컴퓨팅 파워를 쓰면 서버가 더 여유를 되찾지 않을까? 하는 생각으로 한 선택이라 보시면 되겠습니다.
궁금증이 좀 해소되셨으면 좋겠습니다. 아울러 제가 한 선택들은 장단점이 명확해서 사실 TSBOARD가 정답이라고 생각하진 않습니다. 여러 트레이드오프를 고려했고, 저의 짧은 생각으로 내린 결정들이라고 보시면 될듯 합니다. 추후에 TSBOARD가 좀 더 많이 활용된다면 언제든지 제 생각을 바꿔서 다른 시도를 해볼 수 도 있겠습니다. ㅎㅎ
이미 설계가 CSR에 맞게 되어있어서, SSR로 바꾸려면 거의 재개발수준의 작업이 필요할걸로 보입니다ㅜㅜ
최근 검색 크롤러는 JS도 일부 개선한다고는 하지만.. 아무래도 plain HTML을 따라올수가 없을것 같습니다.
일반 브라우저는 CSR로 처리하되, 검색봇(GoogleBot, Yeti등)의 경우, SSR로 처리하는 방식도 있을 것 같습니다.
개인적으로는, 그러한 방식은 임시방편으로 생각되고, 결국 SEO를 잘 지원하려면 SSR이 정답이지 않을까 싶어요.
CSR이라 하더라도, 결국 요청량이 많아지면, 백엔드 부하가 생길것이고, 캐시설계나 다양한 장치들을 통하여 백엔드 부하를 줄이는 것이 좋은 방향인것 같긴 합니다^^;
TSBOARD의 경우 말씀하신대로 CSR 기준으로 모두 작업이 되어 있어서 적어도 v1.y.z 버전에서는 CSR only 기준으로 작업을 해야 할 것 같습니다. 일부 보완을 해보자면, 첫화면에 모든 게시글들이 나타나는 구조이니 첫화면만 SSR 방식을 적용한다던지, 아니면 말씀하신대로 봇들은 plain HTML쪽을 크롤링 할 수 있도록 별도 페이지를 추가하던지 해야 겠네요! 보완책은 v0.9.z 버전대에서 반영해 보도록 하겠습니다!
앗 혹시 TSBOARD가 CSR방식이라서 검색이 안된다! 라고 생각하실 분들이 계실까봐 조금 염려되어 말씀드리자면, 구글봇의 경우 CSR 방식으로 제작된 웹사이트 내용도 가져갈 수 있을 정도로 이미 개선되어 있다고 합니다! (구글이니까 가능...?) SEO가 불리한 방식임은 분명하나 전혀 안된다, 는 아니니 너무 걱정 안하셔도 좋을 것 같습니다.
CSR, SSR 뿐만 아니라 중간 어딘가의 방식들도 있을테니 좀 더 고민해보고 SEO를 개선하는 목표로 v2.0.0 로드맵도 수립해 보겠습니다. (아직은 먼 얘기입니다만 ㅎㅎ) 조언해 주셔서 감사드리고 부족한 프로젝트입니다만 TSBOARD 잘 부탁드립니다!
글을 보고 궁금한게 생겨 댓글을 남겨봅니다. (코드를 보진 않았습니다)
백엔드를 Nodejs compatible로 개발하지 않은 이유가 궁금합니다 (말씀하신 단점을 상쇄하기엔 너무 퍼포먼스가 안나오나요?)
CSR이면 SEO 처리는 어떻게 하실 계획인가요? 커뮤니티는 검색 유입도 신경써야될 것 같은데요