Show GN: TSBOARD (타입스크립트로 작성된 오픈소스 커뮤니티 빌더)

TSBOARD란 무엇인가?

• TSBOARD 는 Type Safety BOARD로, 타입스크립트로 작성된 커뮤니티 빌더이자 게시판입니다.
• 이곳 GeekNews에서 소개된 적이 있는 Bun 런타임을 사용하고, ElysiaJS 라는 웹프레임워크를 이용하여 백엔드를 구성했습니다. 덕분에 일반적인 게시판 엔진 대비 동작 속도가 빠릅니다.
• 프론트엔드에는 Vue 와 Vuetify 가 사용되었습니다. 하지만 개발자의 미적 감각은 섭섭한 수준이기에, 훗날 귀인 디자이너분들의 도움도 받을 수 있지 않을까 하는 희망을 안고 이곳에 글을 쓰게 되었습니다. (+ 당연히 귀인 개발자분들의 도움도 필요하구요!)

왜 만들었나?

• 저는 웹 프로그램을 PHP로 시작했고, 제로보드와 그누보드 시절을 겪은 (이제는 아재) 개발자입니다.
• 제 머리 속 마지막 자바스크립트에 대한 추억은 jQuery 없으면 쓰레기(...)같은 언어, 정도였습니다.
• 그러나 지속적인 표준안 개선과 Node.js 의 등장, 그리고 MS의 타입스크립트에 뒤늦게 반해버렸습니다. (사실 너무 늦게 반한 것 같습니다)
• 그래서 다시 웹 프로그램을 한 번 만들어보고 싶었고, 늘 만들었던 게시판을 타입스크립트로만 작성해보고 싶었습니다.
• 더불어 (이왕이면) 쓰기 쉽고, 더 빠르고 안전하게 동작하도록 만들어보고 싶어서 만들게 되었습니다.

TSBOARD만의 장점

• TSBOARD는 프론트엔드와 백엔드 모두 타입스크립트로 작성되어 타입 안정성을 최대한 보장합니다. (뭐든 완벽한 것은 없지만, 가장 신경쓴 부분이 타입 안정성입니다)
• Node.js 기반의 풀스택 개발을 해보신 분들에게는 쉽게 이해되며, 바로 활용 가능한 디자인입니다. 저도 새로 처음부터 배우면서 만들었기에 다른 분들의 모범 사례를 많이 참조했습니다.
• 중소규모의 커뮤니티 사이트를 제작하는데 필요한 모든 기능들이 내장되어 있습니다. 개발할 때는 클리앙이나 퀘이사존, 기글하드웨어 또는 최근 새로 생긴 다모앙 같은 국내에 내노라 하는 커뮤니티 사이트들을 참조했었습니다.

단점도 있습니다.

• Bun 런타임은 가상 CPU에서의 동작이 제대로 안됩니다. 저렴하게 사용 가능한 가상서버 호스팅에서는 제대로 활용하기 어렵습니다. TSBOARD도 Bun에 의지하고 있어서 마찬가지입니다.
• TSBOARD는 Client Side Rendering 방식을 사용합니다. 저는 PHP를 여전히 아꼈던 사람으로서, Server Side Rendering 이라는 용어가 되려 생소했었습니다. 여러 장단이 있지만 일단 (저에게) 새로운 방식을 해보고 싶었고, 서버 부담을 줄이는 목적으로 TSBOARD를 개발했기에 이것이 누군가에겐 분명 단점으로 다가올 수도 있을 듯 합니다.
• 사실 개발을 시작한 지는 약 반년이 넘었습니다만, 이제서야 겨우 소개를 올릴 수 있을 정도로 부족한 점들이 많습니다. 이 단점은 훗날 만나게 될 귀인 여러분들의 도움으로 해소할 수 있길 기대하고 있습니다.

마무리 : 언젠가 유명 커뮤니티 사이트들이 TSBOARD를 채택할 날을 꿈꾸며

• 그누보드가 PHP에서 Python으로 넘어가는 걸 보면서 웹프로그램들도 새로운 시도들을 계속해서 하고 있구나, 하는 걸 느꼈습니다. XE에서 탄생한 라이믹스도 그렇구요. 여전히 웹은 역동적이고, 개발도 마찬가지더라구요.
• 저도 작게나마 TSBOARD 프로젝트를 통해서 웹 생태계에 기여하고자 하는 마음으로 소개글을 남겨봅니다.
• 언젠가 새롭게 탄생할 커뮤니티 사이트가 TSBOARD를 채택할 그 날을 꿈꿔봅니다. ㅎㅎ

긴 글 읽어주셔서 감사합니다!

[tsboard]

약 2주전에 올린 글에 댓글을 추가로 남기는게 도움이 될까 싶지만 ㅎㅎ
GeekNews에서 받은 SEO 관련 피드백들을 어떻게 반영할까 고민하다가,
sitemap.xml 을 구현하여 검색 엔진 최적화를 반영하여 내용 공유 차원에서 댓글로 남깁니다!

결론만 말씀드리면, 검색 엔진은 robots.txt > sitemap.xml 접근을 통해 최종적으로
https://tsboard.dev/tsapi/seo/main.html (예시 페이지) 경로에서 데이터를 수집하게 됩니다.
사용자가 검색으로 유입될 경우, 해당 페이지에서 다시 링크들을 통해 원래 사이트로 접속되도록 하였습니다.

자세한 내용은 아래 링크를 통해서 확인 하실 수 있습니다!

https://tsboard.dev/board/free/18

[dogtree]

저도 취미로 만드는 프로젝트를 bun으로 돌릴까 생각중이었는데, 가상CPU에서 동작이 제대로 안된다니 놀랍네요. 그리고 회원가입할때 비밀번호 조건에 대문자 라고 써있어서 소문자는 포함 안시켜도 되는줄 알았는데 낚였네요 ㅋ 대소문자라고 쓰셔야할듯

[tsboard]

혹시나 싶어서 답글을 남겨봅니다. Bun 런타임 고려중이신 분들은 이제 더 이상 가상 CPU에서의 동작 문제를 걱정하지 않으셔도 됩니다...! 1.1.31 버전에서 테스트를 해보니 무리 없이 동작되는 걸 확인하였습니다. :)

[tsboard]

아앗 댓글 감사드리고 말씀하신 비밀번호 조건 부분 수정도 꼭 해놓도록 하겠습니다. ㅎㅎㅎ

Bun은 저도 뭐랄까 깊게 써본 것은 아닙니다만, 쓰면서 여러 가지 의미로 놀라운 경험들을 많이 할 수 있었습니다. Node.js 에서는 당연히 되던 기능이 무슨 이유 때문인지 안되던 경험도 많았고 (그중에는 가령 폴더 생성 시 recursive: true 옵션이 지원 안되는 문제도 있었네요), 놀라울 정도로 속도에 집착하는 (그래서 제가 더 애정을 가질 수 밖에 없었던) 모습들도 많았습니다.

지금은 Bundows 라고 하던데 Windows 에서 Bun 런타임이 이제 공식 지원입니다만, 1.1 이전엔 안되어서 WSL2 상에서 돌렸어야 했었습니다. 말씀하신 가상 CPU에서의 동작은 Bun이 앞으로도 지원하지 않을 가능성이 높습니다. AVX2 명령어를 지원하지 않는 CPU를 위한 배포판 (baseline) 까지는 제공하고 있지만, 가상 CPU 미지원은 Bun 개발 언어인 Zig 의 한계인지 몰라도 여러 모로 아쉬운 상황이긴 합니다. 그냥 사용하면서 느낀 건 속도를 위해 Bun 역시 희생한 부분이 있는 것 같다, 이 정도입니다.

혹시 이 댓글을 보실 미래의 Bun 사용자분들이 계실지 몰라 조금만 더 첨언하자면, 여러 제약이 있음에도 불구하고 Bun은 매력적인 선택지입니다. 특히 웹 프레임워크로 ElysiaJS 를 선택하신다면 속도 측면에서는 적어도 아쉬울 점이 없으리라 생각하고 있습니다. 저는 다시 처음으로 돌아가서 런타임을 선택해야 하는 시점이 온다면... 조금 더 고민을 해보겠지만 결국 여러 문제에도 불구하고 Bun을 역시 선택할 것 같습니다. 처리 속도에 광적으로 집착하는거나, 이미 정답이 있는 JS 런타임 생태계에 도전하는 모습들이 뭔가 마음을 움직이더라구요. ㅎㅎㅎ

[boy672820]

깃헙 코드를 보는 중 궁금한 점이 있어서 질문 남겨봅니다.

1. 테이블 구조를 확인해보니 관계 설정이 안되어 있는데 그러한 이유가 있을까요?
2. 인덱스 효율을 위해서 테이블 관계 사용하지 않았다면, RDB 대신 NoSQL을 고려하지 않은 이유가 궁금합니다.

개인적으로 나와 주었으면 하는 TS 기반의 보드류가 나와서 감명 깊게 보았습니다!

[tsboard]

v0.8.40 업데이트에서 외래 키 설정이 반영되었습니다!
https://tsboard.dev/board/free/18

[tsboard]

앗 댓글 감사합니다!

관계 설정이라 하심은 외래 키 설정이 안되어 있는 것 말씀이시로군요! 따로 이유가 있었던 것은 아니고, 테이블 구조가 어느 정도 확정이 되면 설정을 해볼까 했었는데 도중에 다른 거 처리하다보니 아직까지 반영을 해놓지 못했습니다. 이미 TSBOARD 테이블 간의 의존 관계나 참조하는 컬럼이 어느 정도 안정화 되었으니 이제 외래 키 설정도 해놓고 좀 더 무결성을 보장하는 방식으로 바꾸도록 해보겠습니다!

NoSQL은 고민을 잠시 했었는데... 새로 배우는 게 우선 타입스크립트 언어부터 Vue, Node.js/Bun 등 너무 많아서 바꾸지 않기로 했습니다. 관계형 데이터베이스가 유구한 역사만큼 이제 오래되긴 했습니다만, 그래도 아직 많은 곳에서 여전히 유용하게 활용되고 있는 이유가 있지 않을까? 하는 고민도 있었습니다. 지금 댓글을 쓰는 시점에서는 이런데 혹시 나중에 뭔가 필요가 생기면 MongoDB 같은 걸 고려해 볼 수도 있겠습니다. ㅎㅎ

타입스크립트 기반의 게시판이 아직 없었다는 게 사실 개인적으로는 놀라운 일입니다만, 이것도 시간 문제가 아닐까 싶습니다. TSBOARD와는 다른 스타일의 또다른 프로젝트들이 많이 생기면 좋겠습니다! ㅎㅎ 댓글 감사드립니다!

[singed]

솔직히 예전 PHP 보드류들을 생각해서 별 기대를 안했는데, 데모사이트(https://tsboard.dev)를 보고 생각이 바뀌었습니다. 퀄리티가 너무 좋네요.

• SSR 지원
• 비로그인 글쓰기 허용 가능 (dc같은)

이런 점들이 필요하지 않을까 생각됩니다!

에디터는 직접 구현하신건가요? ㄷㄷ 아마 에디터 엔진(?)을 사용하신게 아닌가 싶긴 한데 엄청난 장인정신이 느껴집니다

[tsboard]

댓글 감사합니다! tsboard.dev 사이트의 퀄리티를 좋게 봐주시니 더 감사합니다. ㅎㅎ

말씀해주신 SSR 지원은 2단계로 나눠서 로드맵을 준비해 보았고, 보완책을 먼저 적용한 이후 후속 버전에서 CSR 과 SSR 방식을 적절히 섞어서 개발해 나가려고 합니다. 성능을 충분히 유지하면서 SEO에 좀 더 최적화하려면 무엇보다 제가 더 많이 배우기도 해야해서 시간이 좀 더 필요할 것 같습니다. 포기하지 않고 꾸준히 해보면 저도 다른 귀인 개발자분들을 만나 더 빨리 배우고 도움도 혹시 받을 수 있지 않을까 희망해 봅니다. ㅎㅎ

비로그인의 경우 TSBOARD를 만들때 개발 기간 단축이나 설계상의 단순성을 유지하기 위해 고려하지 않았었는데, 고민을 좀 더 해보겠습니다! 지금 답글을 남기는 시점에서는 비회원을 고려해야 할 경우 변경점들이 많이 필요해서 당장은 어려워 보입니다. ^^;;;

에디터는 tiptap 에디터 기반으로 한땀 한땀 구성을 했는데, 생각보다 에디터 구현에 시간을 많이 잡아먹었습니다. 예전 기억으로는 CKEditor였나...? 그런 걸 그냥 가져다 쓰면 되었던 것 같았는데 요즘에는 이렇게 한땀 한땀 레고 조립하듯 해야 하더라구요. ㅠ.ㅠ 거기에 TSBOARD 기능을 통합하려고 더 삽질을 했었습니다. 만들면서 느낀 건 이 에디터만 누가 좀 만들어주면 좋겠다 싶었는데 ㅎㅎㅎ... 혹시 tiptap 기반에 쓸만한(?) 에디터가 필요하신 분들은 TSBOARD에 제가 구현해둔 코드들 참조하시면 더 빨리 더 쉽게 개발하실 수 있으실듯 합니다.

생각외로 좋게 봐주시는 분들이 많아서 소개글 쓸 때 쓸까말까 고민하던 시간들이 아깝다는 생각이 들 정도입니다. TSBOARD 많이 부족합니다만, 아무쪼록 잘 부탁드립니다!

[yeppyshiba]

php 로 개발을 시작했고 저도 typescript 반해서 많이 시도하고 있을 시기네요.
뭔가 동질감 느껴서 반갑습니다.

[tsboard]

반갑습니다! 저도 비슷한 여정을 어쩌다보니 밟아가고 있네요. ㅎㅎ PHP 언어는 아직까지도 여기저기 혼나고 다녀서 개인적으로는 안타깝습니다만, 타입스크립트를 써보니 조금쯤은 혼나도 괜찮겠다는 생각이 듭니다. ㅎㅎ yeppyshiba님도 타입스크립트로 재밌는 프로젝트 많이 해보시면 좋겠습니다. :)

[jujumilk3]

넘 멋지십니다 👍

[tsboard]

감사합니다!! 부족한 프로젝트입니다만 좋게 봐주셔서 저도 행복합니다. ㅎㅎ
언젠가 TSBOARD가 필요해지실 때가 있을 때 자신있게 추천할 수 있도록 더 열심히 개선해 나가겠습니다. :)

[filekiwi]

이런게 아쉬웠는데.. 감사합니다.

[tsboard]

댓글 남겨주셔서 감사합니다! 혹시 언젠가 TSBOARD와 유사한 웹프로그램이 필요해질 때 한 번 기억해주시고 테스트 해봐주시면 좋겠습니다. 필요하실 때 더 편하게 쓰실 수 있도록 계속 열심히 만들어 나갈께요!

[jongpak]

오...! PHP 시절 sirini 보드 기억하는데, 정말 오랜만입니다.
나름 당시 시리니보드 스킨도 개발하고 보안취약점도 제보하고 그랬었는데, 잘 지내고 계시나요 :)

코드 보다보니 느낀점은, 서버쪽 코드가 뭔가 PHP 느낌이 많이 나네요 ㅎㅎ (PHP 느낌의 js 코드?)

다른분께서 말씀주신대로, CSR이면 SEO등에 불리하다는 단점이 있을텐데요.
이러한 부분이 잘 보완되면 좋을 것 같습니다ㅎㅎ

[tsboard]

앗 예전에 저를 도와주셨던 귀인이셨군요! 이렇게 다시 만나게 되어 반갑습니다 ㅎㅎ
아울러 그 때나 지금이나 약간 누구나 생각할법한 시시한 것만 만드는 것 같아 부끄럽네요. ^^;;

백엔드 코드는 말씀하신대로 PHP 스타일이 녹여져 있습니다 ㅎㅎ 저도 가끔 PHP에서 쓰던 함수들이 JS에는 없나? 하고 매번 찾다가 비슷한 이름으로 함수명을 지어서 쓰기도 합니다. 좀 더 JS/TS 코드에 익숙해지고 리팩토링을 하다보면 더 개선되지 않을까 싶기도 하네요. ㅎㅎㅎ

SEO 부분은 말씀해주신대로 보완을 해야겠습니다. 제 짧은 생각으로는 RSS 같은 다른 정적 페이지를 추가하는 것인데, 이것 저것 시도해 보도록 하겠습니다.

그나저나 PHP4 시절의 저를 기억해주시는 분이 있다는게 정말 놀랍고 감사한 일이네요! 사실 이 글 쓸까말까 고민을 많이 했었거든요. ㅎㅎ;; 더 많은 분들에게 작게나마 도움 될 수 있도록 노력해 보겠습니다. TSBOARD도 많이 사랑해주세요!

[superwoou]

글을 보고 궁금한게 생겨 댓글을 남겨봅니다. (코드를 보진 않았습니다)

백엔드를 Nodejs compatible로 개발하지 않은 이유가 궁금합니다 (말씀하신 단점을 상쇄하기엔 너무 퍼포먼스가 안나오나요?)
CSR이면 SEO 처리는 어떻게 하실 계획인가요? 커뮤니티는 검색 유입도 신경써야될 것 같은데요

[tsboard]

안녕하세요! 댓글 남겨 주셔서 감사합니다. (사실 무관심 속에 뭍힐 거라 생각했는데 감동입니다)
질문해주신 내용들이 저도 고민을 굉장히 많이 했었는데, 그냥 이런 생각도 있구나 하고 봐주시면 좋겠습니다.
아, 참고로 저는 PHP 이후로는 현생에서 단 한번도 웹개발을 이어간 적이 없었습니다. Node.js 개혁의 시대도, React가 웹 세상을 바꿀 때도 관심을 두지 않았었기 때문에 다소 생소한 관점도 있을 수 있겠습니다. ㅎㅎ

1. 백엔드를 왜 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 같은 유명한 게시판이 없...더라구요. 제가 못찾은 걸까요??)

2. CSR을 선택하면 SEO는?
   말씀하신 부분이 전적으로 맞습니다. 검색 유입을 하려면 어쨌든 구글 크롤러가 내용을 읽어드리고, 검색 매칭이 되도록 해야 합니다. 이 부분은 아직 구현하지 않았습니다만, 사용자가 원할 경우 마치 RSS 피드를 노출하는 것처럼 최신 컨텐츠들을 정적 형태로 따로 공유하면 어떨까 생각하고 있습니다. JSON 형태로 외부 노출을 하면 수집기가 더 편하게 데이터를 갱신할 수 있지 않을까? 하는 생각을 가지고 있는데 좀 더 고민해 보겠습니다. (RSS 를 생각했었는데 요즘엔 이걸 대부분 안쓰시더라구요?? 제가 너무 오래 웹을 안했나봐요 ㅠ)

SEO 보완책과는 별개로, CSR로 간 이유는 서버 부담을 좀 더 적극적으로 줄이고자 했기 때문입니다. 최근에 생긴 다모앙(이거 커뮤니티 이름을 막 공개해도 되나 모르겠네요) 사이트의 경우에도 트래픽 부하나 서버 부담이 상당히 되는 걸로 알고 있습니다. 커뮤니티 빌더라는 걸 생각했을 때 SEO도 중요하지만 우선 비용과 직결되는 문제부터 해결해야겠다는 생각에 CSR를 우선적으로 선택하였습니다. PHP를 여전히 사랑하는 저로서는 SSR이 오히려 익숙합니다만, 클라이언트가 좀 더 적극적으로 컴퓨팅 파워를 쓰면 서버가 더 여유를 되찾지 않을까? 하는 생각으로 한 선택이라 보시면 되겠습니다.

궁금증이 좀 해소되셨으면 좋겠습니다. 아울러 제가 한 선택들은 장단점이 명확해서 사실 TSBOARD가 정답이라고 생각하진 않습니다. 여러 트레이드오프를 고려했고, 저의 짧은 생각으로 내린 결정들이라고 보시면 될듯 합니다. 추후에 TSBOARD가 좀 더 많이 활용된다면 언제든지 제 생각을 바꿔서 다른 시도를 해볼 수 도 있겠습니다. ㅎㅎ

[jongpak]

이미 설계가 CSR에 맞게 되어있어서, SSR로 바꾸려면 거의 재개발수준의 작업이 필요할걸로 보입니다ㅜㅜ

최근 검색 크롤러는 JS도 일부 개선한다고는 하지만.. 아무래도 plain HTML을 따라올수가 없을것 같습니다.
일반 브라우저는 CSR로 처리하되, 검색봇(GoogleBot, Yeti등)의 경우, SSR로 처리하는 방식도 있을 것 같습니다.

개인적으로는, 그러한 방식은 임시방편으로 생각되고, 결국 SEO를 잘 지원하려면 SSR이 정답이지 않을까 싶어요.

CSR이라 하더라도, 결국 요청량이 많아지면, 백엔드 부하가 생길것이고, 캐시설계나 다양한 장치들을 통하여 백엔드 부하를 줄이는 것이 좋은 방향인것 같긴 합니다^^;

[tsboard]

TSBOARD의 경우 말씀하신대로 CSR 기준으로 모두 작업이 되어 있어서 적어도 v1.y.z 버전에서는 CSR only 기준으로 작업을 해야 할 것 같습니다. 일부 보완을 해보자면, 첫화면에 모든 게시글들이 나타나는 구조이니 첫화면만 SSR 방식을 적용한다던지, 아니면 말씀하신대로 봇들은 plain HTML쪽을 크롤링 할 수 있도록 별도 페이지를 추가하던지 해야 겠네요! 보완책은 v0.9.z 버전대에서 반영해 보도록 하겠습니다!

앗 혹시 TSBOARD가 CSR방식이라서 검색이 안된다! 라고 생각하실 분들이 계실까봐 조금 염려되어 말씀드리자면, 구글봇의 경우 CSR 방식으로 제작된 웹사이트 내용도 가져갈 수 있을 정도로 이미 개선되어 있다고 합니다! (구글이니까 가능...?) SEO가 불리한 방식임은 분명하나 전혀 안된다, 는 아니니 너무 걱정 안하셔도 좋을 것 같습니다.

CSR, SSR 뿐만 아니라 중간 어딘가의 방식들도 있을테니 좀 더 고민해보고 SEO를 개선하는 목표로 v2.0.0 로드맵도 수립해 보겠습니다. (아직은 먼 얘기입니다만 ㅎㅎ) 조언해 주셔서 감사드리고 부족한 프로젝트입니다만 TSBOARD 잘 부탁드립니다!