TSBOARD

This page has been created to help search engines easily index the TSBOARD site.
For the page intended for actual users, please click here to visit.

열심히 안드로이드 앱 개발 공부중입니다

2025:02:11 23:02:29 / / written by 시리니

안녕하세요! 간만에 글 남기는 것 같습니다. ㅎㅎ


TSBOARD v1 버전 공개 이후로 몇가지 패치만 진행한 상황에서, 일전에 블로그에 작성한대로

안드로이드 앱 출시를 위해 열공하고 있습니다.


물론 겸사 겸사 업무적으로 안드로이드 앱 개발이 필요한 상황이 되어서 마침 기회다 싶어 열심히 공부중인데

생각보다 배워야 할 부분들도 많았고, 또 의외로 모던 웹 개발과 비슷한 부분들도 많아서

즐거운 마음으로 공부에 임하고 있습니다. (이건 완전히 다른 개념이네? 아 이건 또 엄청 비슷하네? 이렇게 ㅎㅎ)


우선 이번 학습의 가장 큰 목적이라 할 수 있는 코틀린(Kotlin) 언어에 대한 이해도를 높이고 있는데요,

고(Go) 언어와는 또 다른 매력을 알아가고 있습니다…! (고루틴과 비슷한듯 조금 다른 코루틴도 재밌네요!)


이왕 공부하는 거, 제대로 기초부터 배워서 TSBOARD 앱을 만들어두고

다시 앱에 필요한 TSBOARD 코어 기능들을 다듬어 나가는 방식으로 해보고자 합니다.


숨가쁘게 달려오다가 잠시 쉬어가는 타이밍인데, 잘 공부해서 TSBOARD 생태계를 더 넓혀 보겠습니다!

  • tsboard
  • app
  • android
  • kotlin
  • 공부

와 시리니님 반갑습니다

2025:02:03 14:28:35 / / written by kkigomi

안녕하세요.

예전에 시리니보드, GR보드 개발하셨던 그 분 맞으시죠?

정말 반갑습니다. 😀

 

다모앙에서 우연히 TS보드 얘기가 나와서 사이트에 방문했다가 ‘시리니’라는 닉네임에 추억이 소환되어 조금 살펴보니 GR보드까지 추억 소환되었네요 ㅎㅎ

 

여전히 오픈소스 개발을 하고 계시다니 대단하십니다.

 

그냥 반가운 마음에 들러서 글 하나 남겨봅니다. 😀

  • 와! 정말 반갑습니다! 저 추억의 이미지를 아직도 기억하고 계시다니 감동입니다…!!!

    저도 다모앙 눈팅만 간간히 했었는데 TSBOARD 얘기가 나왔을 줄은 꿈에도 몰랐습니다. (영광입니다!)

    한적한 곳입니다만 종종 들러주시면 좋겠습니다. ㅎㅎ 글 남겨주셔서 고맙습니다~! 😊

    2025:02:03 21:15:43 / / written by 시리니

즐거운 설 명절 보내세요!

2025:01:24 22:07:59 / / written by 시리니

안녕하세요! TSBOARD 개발하고 있는 시리니입니다.


2025년 1월 1일이 밝아온 지 얼마 안된 것 같은데, 벌써 민족의 명절 설날이 다가왔습니다.

이번에는 좀 더 길게 쉴 수 있어서 아마 차가 많이 막히진 않을 것 같습니다만, 그래도 오가시는 길 안전운전하시고

가정에 건강과 행복이 함께 하시길 바랍니다!


TSBOARD의 본격적인 개선 작업은 연휴가 끝나면 진행될 예정입니다.

올해는 더 다양한 기능들과 안정적인 기술들을 도입하고, 웹에 이어서 앱에서도 쉽게 만나보실 수 있도록

노력해 볼 생각입니다. 많은 응원 부탁드립니다!


새해 복 많이 받으세요!

  • 설날
  • 새해
  • 인사

안드로이드, 코틀린 그리고 TSBOARD

2025:01:17 00:08:09 / / written by 시리니

TSBOARD는 v1.0.3을 기점으로 우선은 좀 시간을 두면서 코드 개선이 필요한 부분들이 어디인지 살펴보고 있습니다. 그러는 동안, 저는 다소 뜬금 없지만 안드로이드 앱을 만들어보려고 합니다. 그것도 TSBOARD로 제작된 커뮤니티를 위해서요. (아직은 여기 뿐이지만…?) 저는 갑자기 왜 안드로이드를, 그것도 플러터나 React Native 같은 방식으로가 아닌 코틀린으로 네이티브 개발을 하려는 걸까요?


내 손안의 컴퓨터 세상, 모바일 웹 만으로는 부족해


TSBOARD를 개발할 때 모바일 버전과 PC/태블릿 버전을 함께 고려해서 개발 하기는 했습니다만, 그럼에도 약간 아쉬운 부분들은 존재합니다. 물론, 대부분의 기능들이 무리없이 모바일 브라우저에서 동작하기 때문에 앱 푸시 알림 같은 기능들을 제외한다면 이론적으로 안되는 건 그리 많지 않습니다. 그러나, 브라우저가 아닌 앱이 줄 수 있는 더 다양한 기능들과 더 부드러운 UI, 그리고 앱 아이콘을 찾아서 터치만 하면 바로 접근 가능한 점 등은 앱 개발에 대한 나름의 동기부여를 해줍니다.


유명한 커뮤니티 사이트들을 살펴보면, ① 해당 사이트의 내용을 크롤링해서 더 보기 편하게 해주는 앱이 있거나 ② 아예 자체적으로 앱을 개발해서 배포하는 경우가 종종 있습니다. ①의 경우 해당 사이트가 API를 제공하면 모르겠지만, 대부분은 제공하지 않기 때문에 크롤링이 언제나 가능하지는 않을 수 있고, 또 API가 공개 되어 있더라도 내부 사정에 의해 언젠가 바뀌게 되면 무용지물이 되는 경우도 있습니다. ②의 경우는 당연히 더 나은 상황이지만, 이렇게 자체적으로 지원하려면 커뮤니티 사이트 운영진이 추가로 앱까지 개발하고 유지/보수해야 하는 문제가 있죠.


여하간 이렇게 커뮤니티 사이트들을 살펴보면, 웹 만으로는 부족하다고 느끼는 분들이 많은 건 확실해 보입니다. 저 역시도 브라우저 영역이 예전 대비해서 훨씬 확장되고 더 강력하다는 것은 인정합니다만, 그럼에도 여전히 브라우저의 영역 밖에서 더 강력한 컴퓨팅 파워를 쓰고 싶은 갈망은 계속 있어왔습니다. 그러던 것이 결국 TSBOARD v1.0.0 공개를 기점으로 조금씩 분출되어 앱 개발까지 이어지게 되었습니다.


왜 크로스 플랫폼이 아닌가?


이왕 웹 개발과 조금 떨어져서 개발할거면, 웹 기반의 크로스 플랫폼은 아니길 희망했습니다. (아닐 수도 있지만) 너무 뻔하고, 제가 목표로 하는 더 부드러운 UI에도 그렇게 부합하지 않는다고 생각했기 때문입니다. 물론 구글이 밀고 있는 플러터(Flutter)의 경우 언젠가 데스크탑 애플리케이션을 개발할 날이 오게되면 그 때는 주저없이 선택하겠지만, 모바일에서는 아직까지 네이티브 개발이 퍼포먼스를 끌어내는데 유리하다고 판단했습니다.


이성적으로는 크로스 플랫폼으로 개발을 해야, 한 번에 안드로이드와 아이폰을 공략할 수 있으니 그렇게 하는 게 맞지 않나? 라고 생각했습니다. 그러나 TSBOARD 앱이 나온다면 그건 웹과는 확실히 달라야 한다는 생각이 들었고, 퍼포먼스 측면에서 보다 모바일 기기의 자원을 더 쉽게 끌어다 쓸 수 있기를 희망했기에 그러지 않았습니다. 감성적으로는, 이번 기회에 써보고 싶었던 코틀린(Kotlin)을 제대로 체험해보고 싶다는 생각이 들었습니다. 마침 업무적으로도 이제 써볼 기회가 생겨서 궁금하던 차였기에, 이왕 배우게 될 거 TSBOARD의 안드로이드 앱 개발에도 활용해보자는 생각이 들었습니다.


코틀린은 TSBOARD의 백엔드 언어로 한 때 유력하게 고민했던 언어입니다. 자바와 100% 호환되는 언어이고, 문법 설탕도 어느 정도 달달하게 들어가 있고, 여러 모로 개발자의 생산성에 집중한 언어에 Null Pointer Exception (NPE)을 막기 위한 안전장치까지 마련되어 있는 “요즘 언어” 라고 할 수 있습니다. 백엔드에서는 최종적으로 더 심플하고 제 기준에 딱 부합하는 Go 언어를 선택하면서 코틀린을 써볼 기회가 사라졌지만, 이제 TSBOARD 앱을 개발하게 되면서 다시 코틀린을 만나게 되는 셈입니다.


안드로이드 앱을 먼저 만드는 이유?


쓰는 장비들이 사과 농장에 버금가는 수준이라, 사실 처음에는 iOS용 앱을 개발할까 고민 했었습니다. 겸사 겸사 Swift 언어도 배우면서요. 그러나 업무적으로도 코틀린을 써야 하는 상황에서, 동시에 2개의 언어를 배워가며 이것 저것 하는 건 비효율적이라 생각 했습니다. 더군다나 저의 경우 업무용 스마트폰으로 이미 안드로이드 기기(Galaxy S23 Ultra)를 가지고 다니는데, 여지껏 한 번도 안드로이드 앱을 만들어 본 적이 없다는 사실이 뭔가 부끄럽기도 했습니다.


또한 앞서 언급한대로, 코틀린이라는 언어에 대한 갈증이라고나 할까요? 그런 점들이 분명히 있었기 때문에 고심 끝에 안드로이드용 앱을 먼저 만들어보기로 결정했습니다. 사실 이것 말고도 애플 개발자 등록 비용이랄까 그런 부분도 없잖아 고민을 했었습니다…😊


TSBOARD APP : 2025년의 목표


우선 올해는 TSBOARD를 안정적으로 개발하는 게 제일 큰 목표입니다. v1.0.z 버전대에서는 Go 언어로 작성된 백엔드의 퍼포먼스를 좀 더 높이는 목표를 설정하였고, 이어서 v1.1.0 에서 더 다양한 기능들을 담아낸 다음, v1.2.0 에서 쇼핑몰 기능도 추가해 보려고 합니다. 그러는 한 편, TSBOARD 안드로이드 앱을 개발하면서 TSBOARD의 다양한 기능들을 안드로이드 기기에서 보다 편리하게 사용하고, 푸시 알림 같은 걸 누릴 수 있도록 할 생각입니다.


이렇게 개발한다면 아마도 아래와 같은 게 가능해 질 것입니다.


  • TSBOARD로 제작된 커뮤니티 사이트는 따로 앱 개발이 필요 없어집니다. TSBOARD APP을 설치해서 해당 사이트를 등록하기만 하면 되니까요. 운영자분도 별도 앱 개발 없이 커뮤니티 회원분들에게 앱 설치 가이드만 제공하시면 됩니다.

  • TSBOARD로 운영되는 커뮤니티 사이트는 보다 컨텐츠에만 집중하실 수 있습니다. 사이트 유지/보수를 위한 여러 골치아픈 작업들부터 앱까지 개발에 관여하실 필요가 없습니다. 그 시간에 더 알찬 컨텐츠 생산과 관리에 시간을 쏟으실 수 있습니다.

  • TSBOARD 기반 커뮤니티를 이용하시는 회원 분들은 기존 사이트 이용 및 앱을 통한 푸시 알림도 원할하게 받으실 수 있습니다. 또한 앱 기반에서 동작 가능한 여러 부가 기능들 (키워드 푸시 알림 등)이 가능해 질 것입니다.


아직은 이렇게 할 수 있지 않을까…? 막연히 생각만 해보면서 이제서야 안드로이드 스튜디오를 설치하고 코틀린을 배워나가는 상황입니다만, 목표만 흔들리지 않는다면 더 많은 분들에게 실질적으로 유용한 플랫폼이자 앱이 될 것이라 믿습니다. 그렇게 되도록 작년 한 해 열심히 달려온 TSBOARD를 더 좋은 성능과 더 다양한 기능들로 무장시키고, 또 앱도 천천히 하지만 즐겁게 만들어 가보려고 합니다.


TSBOARD 안드로이드 앱은 아래 링크에서 코드를 보실 수 있습니다. 아직은 미약하지만, 올해가 가기 전에는 어느 정도 성과가 나와 주기를 기대해 봅니다…!


https://github.com/sirini/tsboard-android

  • 안드로이드
  • kotlin
  • 앱개발
  • tsboard

여기 멋지네요

2025:01:12 18:20:53 / / written by guest

멋지네요

  • 칭찬 감사합니다 ㅎㅎ

    2025:01:12 22:21:28 / / written by 시리니

나의 미니 PC 홈서버 활용기

2025:01:10 20:09:28 / / written by 시리니

지금은 이 곳 tsboard.dev 웹사이트가 카페24의 가상 서버 호스팅을 이용하고 있습니다만, 처음부터 호스팅을 이용하진 않았습니다. 처음에는 N100 cpu가 탑재된 알리/테무 발 미니 PC를 싸게 구매해서 ASUS 공유기에 물려준 후 포트포워딩, DDNS를 활용하여 홈서버로 운영을 했었죠. 그러면서 다른 사진 커뮤니티 서비스도 올리고 하다가 하필이면 긱뉴스(Geek News)에서 유입되는 트래픽이 많았던 날 접속 장애를 일으키는 바람에 결국 호스팅을 이용하게 되었습니다.


지금도 사실 접속 장애 문제가 가끔 있지만, 대용량의 저장 공간이 필요한 사진 커뮤니티를 차마 호스팅까지 구매해서 운영할 용기가 나지 않아서 계속 홈서버를 운영하고 있습니다. 그러면서 문득, 이 활용기를 공유하면 어떨까 싶어서 글을 남겨봅니다.


왜 미니 PC를 구매했나?


미니 PC는 인텔의 저전력 CPU인 N100의 가성비에 기반하여 지금까지도 꾸준히 주목을 받고 있습니다. 지금 제가 사용하고 있는 맥미니도 미니 PC 범주에 들어가죠. 예전과 달리 지금의 미니 PC는 성능도 훌륭하고, 전성비도 좋은데다 가격도 나름 합리적 입니다. 맥미니는 옵션을 올리기 시작하면 가성비라는 말이 쏙 들어가지만, 적어도 깡통 기준으로는 가성비가 맞습니다.


서버라면 우선 24시간 동작을 해야 하고, 집에서 구동한다면 아무래도 부피가 작은게 좋죠. 그렇다보니 자연스럽게 저전력과 작은 폼팩터를 찾게 되었고 마침 중국에서 불어온 N100의 열풍에 탑승하여 Beelink MINI S12 PRO를 구매했습니다. (광고 아닙니다!) 인텔이 해당 CPU가 인기 많을 걸 알았는지, 메모리 상한을 16GB로 잡은 것이 조금 아쉬웠지만, 어차피 Ubuntu Linux (server) OS를 설치해서 사용하니까 메모리도 크게 제약이 있는 건 아니었습니다. (참고로 코어는 저전력 코어로 총 4개입니다)


지금은 해당 모델보다 좀 더 고사양의 Genmachine RYZEN cpu 탑재 모델을 사용하면서 메모리도 32GB까지 올려두었습니다만, 그 때나 지금이나 미니 PC의 역할은 변함 없습니다. 여전히 집안 내부의 스토리지 허브 같은 역할도 하면서, 사진 관련 커뮤니티 사이트를 (가끔 접속 장애를 일으키며) 운영하는 중입니다. 그리고 외부에서 급하게 코드를 수정해야 할 때 code-server 도 활용하면서 전천후 개발 서버 및 취미 서비스를 운영중입니다.


홈서버, 어떻게 구성하는걸까?


홈서버라고 말하면 뭔가 막연하게 만들기 어렵지 않나? 생각하실 수도 있는데, 실제로는 그렇게 어렵진 않습니다. 물론 잘 운영하는 건 어렵지만, 시작하는 건 쉽다고도 할 수 있지요. Namecheap 같은 곳에서 도메인을 구매한 다음에, 내 공유기에서 설정한 DDNS까지 오기만 하면 거의 절반은 성공한 셈입니다. 추가로 해야할 건 포트 포워딩인데, 이건 공유기 설정에서 쉽게 조정할 수 있습니다.


대략적인 구성 방식은 아래와 같습니다.




웹호스팅이나 AWS같은 클라우드 서비스를 이용하면 없어도 되는 과정 2가지가 추가되는데, 중앙에 있는 DDNS 그리고 내 집 공유기의 포트 포워딩입니다. DDNS 설정은 유/무료 서비스들이 많이 있습니다만, 저는 개인적으로 공유기 제조사에서 제공하는 서비스를 추천드립니다. KT같은 망 사업자는 주기적으로 각 가정에 할당한 IP주소들을 필요에 따라 바꾸는데, 공유기가 이를 감지해서 자기네 DDNS 서비스에 갱신을 해줄 수 있기 때문에 관리가 좀 더 편하거든요. (물론 공유기 제조사의 DDNS 서비스가 안정적이냐? 하는 것과는 별개입니다만)


DDNS를 공유기 제조사 서비스로 하겠다고 하면, DDNS와 포트 포워딩 모두 공유기 설정화면에서 진행 할 수 있습니다. 각 제조사마다 WAN 같은 메뉴에서 설정할 수 있게 해두었는데, 용어가 좀 생소할 수는 있어도 설정해야 하는 내용은 쉽습니다. 저는 ASUS 공유기를 주로 사용하고 있어서 WAN 항목의 가상 서버 / 포트 포워딩 메뉴와 DDNS 메뉴에 필요한 설정들을 해두었는데, 위에 설명이 잘 되어 있어서 설명대로 추가하면 됩니다.


내 집 방구석에서 돌아가고 있는 미니 PC까지 사이트 접속 요청이 오는데 꽤나 많은 과정들이 있지만, 어쨌든 이 과정 자체는 대게의 경우 잘 됩니다. 여러분의 홈서버에 올려진 서비스를 이용해 보고자 하는 방문객은 여러분이 구매한 도메인만 보이니까, 뒤의 복잡한 접속 과정은 보이지도 않고 알 필요도 없지요. 또한 조금 느리게 접속되는 것 정도야 큰 문제는 아닐 겁니다.


홈서버 운영의 어려운 점은?


위의 설명에는 생략된 부분들이 많습니다. 예를 들어 구매한 도메인으로 CNAME 설정을 어떻게 해야 DDNS에 등록한 도메인으로 올 수 있는가? 같은 부분이 되겠죠. (이 부분은 정말 쉽습니다. 검색하면 나오니까요.) 하지만 가장 많이 생략된 부분은 트러블슈팅이 되겠습니다.


일단 여러분의 미니 PC는 집 안에서 전기를 먹으면서 일을 하고 있습니다. 그 말은, 저희 집처럼 별도의 정전 방지 시스템이 준비되어 있지 않다는 것이죠. 대부분은 다음 번에 켰을 때 문제 없이 다시 서비스를 운영할 수 있겠지만, 운이 나쁘면 어떨까요? DB가 깨지거나 잘 되던 서비스가 무슨 이유에서인지 잘 안되는 등의 상상도 하기 싫은 문제가 발생하게 됩니다. 할 수 있는 게 많진 않은데, 고가의 멀티탭에 전원 선을 꽂아두는 것 정도가 되겠네요.


더 큰 문제는 전원 뿐만 아니라 공유기 자체도 24시간 혹사 당하는 기기다보니 어쩌다 동작이 느려지거나 요청이 제대로 전달되지 않는 문제가 왕왕 발생합니다. 때문에 더 환장하는 건 내 서비스가 현재 제대로 운영되고 있는지 아닌지를 수시로 확인해야 한다는 점이죠. 설령 접속 장애를 알아차린다 하더라도, 바로 해결하기 어려운 순간들이 많다는 점이 가장 큰 문제입니다.


마지막으로 사용하는 DDNS의 접속 장애도 고려해야 합니다. 제가 사용하고 있는 ASUS의 DDNS는 접속 장애가 생각보다 자주 있습니다. 이게 정말 환장하는게, DDNS는 제가 운영하는 게 아니다 보니까 ASUS같은 공유기 제조사에서 별도로 조치를 취하기 전까지는 할 수 있는 게 없다는 점입니다. 내 서비스가 멀쩡하게 잘 띄워져 있다고 해도 이 경우에는 손가락만 빨 수 밖에 없습니다.


홈서버 운영, 그럼에도 권하는 이유는?


여러 어려움과 예상치 못한 장애 상황에도 불구하고, 홈서버 운영에는 몇가지 장점이 있습니다. 일단 가장 큰 장점은 낮은 하드웨어 가격으로 비교적 높은 성능을 확보할 수 있다는 점입니다. 특히 용량 문제를 언급하지 않을 수 없는데, 저의 경우 취미가 사진이다보니 사이즈가 큰 사진 원본들을 보관하기 위해서라도 2TB NVMe 같은 게 간절했습니다. 만약 클라우드 등의 서버를 이용한다면 어쩔 수 없이 원본 사진은 삭제하고, 사진도 최대한 압축해서 보관해야만 하겠죠. 홈서버는 그럴 필요가 없습니다. 필요하면 내가 직접 스토리지를 추가하면 되니까요.


다음으로는 내가 필요로하는 라이브러리나 운영체제등을 좀 더 자유롭게 선택할 수 있다는 점입니다. 물론 요즘에는 도커도 잘 되고 가상 서버 같은 경우에도 내가 필요로 하는 대부분이 문제 없이 지원되지만, 그럼에도 본인만의 필요에 의해 희귀한 라이브러리를 써야 한다거나 혹은 특정 하드웨어 부품이 요구되는 상황이 있을 수도 있으니까요. Ubuntu server 말고 전혀 다른 리눅스 배포판을 써보고 싶다거나 할 경우 언제든지 그렇게 해볼 수 있습니다.


마지막으로, 접속 장애가 왕왕 생기긴 하지만 그럼에도 대부분의 시간 동안은 예상 외로 제대로 동작합니다. 미니 PC를 24시간 365일 구동한다고 해서 전기세가 많이 나오냐? 하면 꼭 그렇지도 않구요. (한 달 5천원 미만으로 보시면 됩니다) 예상 외로 잘 동작하고, 운영 비용도 동등 사양의 서버 호스팅이나 클라우드에 비해 말도 안되게 저렴합니다. 미니 PC 가격이야 좋은 운동화 한켤레 수준이니 말 다했죠.


홈서버를 운영하면서 저의 경우에는 code-server를 설치해두고 급하게 외부에서 컴퓨터 없이 작업해야 할 때도 유용하게 사용했습니다. 삼성의 DeX와 크롬 브라우저, 그리고 홈서버의 code-server 데몬이 함께 있다면 어디서든 개발이 가능해집니다. (아, 물론 모니터 키보드 마우스는 별도입니다 ㅎㅎ) 사실상 개발용 서버를 겸하게 되는데, 오래 걸리는 컴파일 작업을 미리 걸어두고 싶다거나 할 경우에는 그냥 스마트폰에서 SSH로 접속한 다음 작업을 시켜 놓으면 되니까 편리함이 이루 말 할 수가 없습니다. (가끔 접속 장애가 날 때는 화딱지가 나지만요!)


여러분의 집에서도 홈서버가 함께하길 바라며


저의 경우 책상 밑 한 켠에 지금 이 순간에도 미니 PC가 RGB를 휘날리며 열심히 팬을 돌리고 있습니다. 없을 때는 몰랐는데, 생기고 나서는 이 녀석을 여기저기 활용해보고 싶어서 근질근질 합니다. 비록 TSBOARD 사이트는 접속 장애가 없길 바라는 마음에 호스팅 업체로 이사를 보냈지만, 여전히 남아있는 사진 커뮤니티는 지금도 조용히 운영이 되고 있습니다. 접속 장애 상황을 만날 때마다 그걸 해결하는 과정에서 노하우가 쌓이는 상황이라 이제는 즐기면서 장애를 해결해가며 운영중입니다.


이 글을 읽어주신 분들 중에서, 나도 홈서버를 운영해 볼 수 있을까? 하고 고민하는 분들이 계시다면 흔쾌히 한 번 도전해 보시라고 권해보고 싶습니다. 막상 해보면 별 거 아니고, GPT 선생님과 함께라면 한 두시간 정도면 완성 하실 수 있습니다. 도전해 보시다가 혹시 막히시는 분들은 댓글 남겨주시면 GPT 선생님 정도는 아니지만 그래도 함께 고민해 보겠습니다.


마지막으로 제가 (홈서버에서) 운영중인 사진 커뮤니티는 https://sensta.me 주소로 방문해 보실 수 있습니다. 제가 실수로 멀티탭 전원 버튼을 발로 누르거나 랜선을 건드리지 않았다면, 접속이 되실 겁니다. ㅎㅎ


쓰다보니 또 길어졌는데, 읽어주셔서 감사합니다!

  • tsboard
  • n100
  • 홈서버
  • 활용기
  • codeserver
  • ubuntu
  • 접속장애
  • 미니pc
  • 추가로 홈서버 관련해서 긱나이트에 발표를 해주신 K리그프로그래머님의 글을 공유드립니다!
    https://news.hada.io/topic?id=18274

    2025:01:10 20:55:07 / / written by 시리니
  • 저도 Mac Mini M4 로 개인용 홈서버 및 워크스테이션으로 활용중인데, 반가운 글이네요. 응원합니다!

    2025:01:14 10:59:09 / / written by CHANN
  • 와 대박입니다. 맥미니를 홈서버로 활용하시다니…! 맥미니 프로 구매해서 작업용으로 쓰고 있는데 진짜 홈서버로는 충분한 성능이라 생각합니다. ㅎㅎ 댓글 남겨주셔서 감사합니다!

    2025:01:14 20:24:02 / / written by 시리니

TSBOARD v1.0.3 업데이트 안내

2025:01:10 18:05:55 / / written by 시리니

안녕하세요! TSBOARD를 개발하고 있는 시리니입니다.


TSBOARD v1.0.3 버전을 아래와 같이 공개합니다.

이번에도 기존 기능의 안정화를 우선으로 해서, 필요로 했던 기능 일부를 추가 하였습니다.


  • 웹진 형식이 추가되었습니다.

    • 기존 게시판, 갤러리 및 블로그에 이어서 게시판의 변형으로 볼 수 있는 웹진 형식이 추가되었습니다.

    • 글 목록에서 이제 커버 이미지가 좌측에 나타나고, 우측에 제목과 본문 일부가 보입니다.

    • 글 보기에서 상단에 커버 이미지가 크게 나타나고, 이어서 하단에 본문이 나옵니다.

    • 기존 게시판 링크 (경로에 /board/ 포함)는 웹진 형태로 변경 시 자동으로 /webzine/ 으로 변경됩니다.

  • 관리 화면에서 대시 보드에 통계 탭이 추가되었습니다.

    • 대시 보드에 작게 나왔던 통계를 별도 페이지에서 더 크게 보실 수 있습니다.

    • 통계 기간도 변경 가능합니다. 1주일부터 1년까지 조정해서 방문자수 추이나 게시글/댓글 작성 추이를 살펴 보실 수 있습니다.

  • tsboard.config.ts 에서 설정한 COLOR 값의 적용 범위를 더 확대 하였습니다.


업데이트는 git pull 로 진행하시면 됩니다! (이후 npm run build 실행!)


백엔드 서버가 x86 기반의 리눅스가 아닐 경우, https://github.com/sirini/goapi 에서 프로젝트를 clone 후 직접 해당 플랫폼에서

컴파일 하시거나, 혹은 저에게 요청해 주시면 해당 플랫폼 바이너리 파일을 생성하여 tsboard repo에 반영해 놓겠습니다.


개발 중간에 댓글 작성이 잠시 안되던 버그도 수정 하였고, 그 밖에 여러 버그들을 수정 반영하였습니다.

(혹시 발견하신 버그가 있으시다면 언제든지 제보해주세요!)


감사합니다!

  • tsboard
  • 업데이트
  • 웹진
  • 대시보드
  • 통계

TSBOARD v1.0.2 업데이트 안내

2025:01:04 22:22:01 / / written by 시리니

안녕하세요! TSBOARD를 개발하고 있는 시리니입니다.


v1.0.0 정식 버전 공개 이후 빠른 속도로 안정화 패치 등을 반영한 후속 업데이트를 공개하게 되었습니다.

당분간은 가능하면 신규 기능 보다는 기존 기능이 제대로 동작하도록 하는데 주안점을 둘 생각입니다.

테스트를 도와주시는 분들께 감사드리며, 댓글 등으로 문제점을 알려주시면 빠른 시일 내에 수정 할 수 있도록 하겠습니다.


아래는 TSBOARD v1.0.2 업데이트 사항들을 정리한 것입니다.


  • 액세스 토큰 만료 시 리프레시 토큰을 확인해서 새로 갱신하도록 개선

    • 액세스 토큰이 만료되면, 기존에는 Unauthorized access 같은 에러 메시지와 함께 글쓰기나 관리 화면 접속 시 제대로 동작이 안되었습니다. 이제는 리프레시 토큰이 유효하다면 자동으로 액세스 토큰을 받아와서 기능을 계속 사용할 수 있습니다.

    • 페이지를 가능하면 새로 고치거나 현재 보고 있는 페이지에서 다른 페이지로 이동하는 걸 권장하는 메시지가 나타납니다.

  • 서버 응답에 대한 에러 핸들링 단순화

    • 프론트엔드에서 이제 서버의 응답을 받을 때 ResponseData 타입으로 받도록 변경하였습니다.

    • 응답이 어떤 타입으로 오는지 미리 지정되어 있기 때문에, 더 명확하게 받은 데이터들을 활용 하실 수 있습니다.

    • 서버 응답에 code (에러 코드) 값이 이제부터 함께 반환됩니다.

  • src/messages 폴더 내의 JSON 객체들을 알파벳 순서로 정렬

  • 코드를 보여줄 때 JetBrain 폰트로 보여지도록 수정

  • 작성된 코드의 하이라이트 색상이 적용되지 않던 문제 수정

  • 홈화면에 출력되는 최근 게시글들의 설정 (게시판 ID 및 개수 지정 등)을 tsboard.config.ts 파일에서 일괄적으로 하도록 개선

  • 10초 마다 작성중인 본문을 자동 저장하도록 개선

  • 한 줄 코드 표현식을 시각적으로 좀 더 도드라지게 표현되도록 개선

  • 알림이 제대로 출력되지 않는 문제 수정, 알림을 우측 drawer로 재구현

  • 본문 글자수 제한 부분 삭제

  • 서버에서 사용자 세션을 중복으로 검사하던 로직들을 제거

  • 채팅방 목록 반환 버그 수정


tsboard.config.ts 설정 파일에서 관여하는 설정 내용이 좀 더 많아졌지만,

그동안 여러 파일에서 각각 수정을 해야만 했던 부분들을 한 곳에 모아서 정의할 수 있도록 하여서

결과적으로는 더 편하게 본인 사이트에 맞도록 수정 후 사용 하실 수 있도록 했습니다.


이번 v1.0.2 에서는 프론트엔드에서 사용하고 있는 일부 라이브러리들의 업데이트가 반영되었습니다.

프로젝트를 git pull 로 내려 받으신 후, npm install 명령어를 실행하여 라이브러리 업데이트가 반영되도록 해주세요.

이후 위에 언급한 설정 파일을 주석 등을 참조하셔서 수정하시고 나서 npm run build 실행을 해주시면 됩니다.

(당연히 실행중이시던 goapi-linux-x64 백엔드는 중지 후 새 바이너리 파일로 다시 실행해주셔야 합니다!)


사용중에 궁금하신 점이나 혹은 개선 제안 등을 하고 싶으신 분들께서는 언제든지 글 남겨주세요!

혹시 사이트 내에 (댓)글을 남기기 어렵거나, 혹은 사이트 내 버그로 인해 글 작성이 어려우실 경우에는

sirini@gmail.com 으로 메일을 보내주시면 됩니다.


감사합니다!

  • tsboard
  • 업데이트
  • v1.0.3 작업 마무리 단계입니다. (댓글 작성이 안되던 버그 수정) 완료되는대로 v1.0.3 태그 붙여서 공개하겠습니다!

    2025:01:09 11:21:11 / / written by 시리니
  • TSBOARD v1.0.3 공개되었습니다. 지금 git pull 및 npm run build 해보세요!

    2025:01:10 18:08:45 / / written by 시리니

JS 월드에서 GO 월드로 이사한 후기

2025:01:03 00:34:33 / / written by 시리니

TSBOARD를 개발하면서 여러 도전들이 저를 기다리고 있었지만, 이번 백엔드 교체가 어쩌면 지금까지의 도전들 중 가장 험난하고도 다이나믹한 도전이 아니었나 생각합니다. 저의 도전기가 또 다른 누군가의 모험심을 자극시켜 줄 수 있다면 좋겠다는 생각으로 (조금 졸린 와중입니다만 ㅎㅎ) 두서 없이 이것 저것 기록의 파편들을 남겨보고자 합니다.

새로운 언어는 어떻게 배우는가

 

이 곳에서도 언급한 적이 있었지만, 저에게 있어 웹은 곧 PHP이고, PHP가 곧 웹개발을 뜻했습니다. 이제는 10년도 더 된 이야기 입니다만, 제가 처음 웹 프로그래밍이라는 걸 접했던 때는 제로보드4가 웹 세상을 지배하고 있던 때였고, 저는 그 때 스킨 같은 걸 만들어보면서 이것 저것 만드는 재미로 PHP4 라는 희대의 스크립트 언어를 배웠습니다. 당시에 사용했던 자바스크립트는 jQuery 의 다른 말이었기 때문에 jQuery도 필요에 의해 조금 배워서 썼던 때였네요.

당시에는 구글링이 곧 프로그래밍이었습니다. 스택오버플로우와 누군가의 블로그를 구글링으로 찾아가면서 궁금한 걸 해결해가는 과정이 저에게 있어 새로운 언어나 라이브러리를 배우는 과정이었습니다. 그러다가 직장인이 되고, 필요에 의해서 C++을 만지기 시작하면서 회사에서 제공하는 교육들을 통해 조금쯤은 더 체계적으로 새로운 언어나 프레임워크에 대해서 익혔던 것 같네요.

이번 TSBOARD의 새로운 백엔드는 고(Go) 언어로 작성되어 있습니다. 이전에 단 한 번도 써본 적이 없는 언어인데, 이번에는 어떻게 배웠을까요? 이번에는 책을 사거나 누군가의 블로그들을 구글링하거나 혹은 동영상 강의를 듣지 않았습니다. TSBOARD를 시작할 때는 그래도 패스트캠퍼스와 같은 동영상 강의 플랫폼에서 Vue 와 같은 프레임워크를 어떻게 쓰는지 등을 배웠었는데, 이번에는 아예 그런 과정도 없었습니다.

 

그저, ChatGPT를 옆에 켜두고, 처음부터 언어의 특징에 대해서 물어보고 제가 기존에 익혔던 언어와 유사점과 차이점을 계속 물어보면서 예제 코드를 받아보고, 제가 작성한 코드에 어떤 문제가 있는지 검토를 부탁하는 식으로 개발을 진행했습니다. 기존에 책이나 블로그 등을 통해서 학습하는 방식에 비해서, 효율성이 일단 두말 할 나위 없이 좋아졌고 이해가 더 잘되었습니다. 구글링 조차도 이제는 LLM이 대신 해주니까 새로운 언어를 배우는데 있어서 학습이 문제가 되거나 하진 않았습니다. 지금 시대에 태어났더라면 프로그래밍을 더 잘했을텐데 하는 아쉬움까지 들 정도입니다. ㅎㅎ

만약 새로운 언어를 배우는게 이전처럼 많은 시간과 노력을 요구했거나, 제가 그런 어려움을 극복할 정도의 필요를 느끼지 못했더라면 이번 백엔드 교체는 아마도 상당히 미뤄졌거나 어쩌면 불가능 했을 겁니다. 다행히도 GPT 덕분에 새로운 언어를 배워서 써야 한다는 부담은 적었고, 어쩌면 조금 만만하게(?) 생각할 수 있었던 것 같습니다. 물론 실전에 투입되고보니 결코 만만치 않았다는 점은 지나고보니 깨달은 것이지만요.

고(Go) 언어, 대체 어떤 언어인가

 

아직 고(Go)라는 언어를 그렇게 오랜 기간동안 사용해보진 않아서, 솔직하게 말씀드리면 잘 모르겠습니다. 겉보기에는 더할 나위 없이 심플한데다 고루틴이라는 막강한 동시성 제어까지 만능 언어처럼 느껴지기도 하는데, 일단 써보면 꼭 그렇진 않다는 걸 금방 알게 됩니다. 그러고보니 일전에 긱뉴스에서 Go vs Bun 비교(https://tsboard.dev/blog/sirini/41)하는 내용의 이 곳 블로그 글을 요약해서 공개한 적이 있었는데, 그 때 어떤 고 언어 사용자분께서 자칫 Go 언어에 대한 잘못된 편견이나 선입견을 줄 수 있다고 지적해주신 게 생각이 나네요. 어떤 마음으로 의견을 전해 주셨는지 이해가 되는 한 편, 그럼에도 어디까지나 도구로서의 언어는 목적에 맞게 평가되어야 한다는 생각이 그럼에도 들었습니다.

 

제가 배우고 사용해보면서 느낀 고 언어는 정말 절제된 언어라는 점이었습니다. 변수명도 길지 않고, 명시적으로 무언가를 거창하게 하지 않습니다. 반복문, 타입 정의 등은 모두 키워드가 하나이고 그 마저도 사용 방식이 정해져 있습니다. 처음 접하면 좀 이상하다 싶은 건 인터페이스 정도인데, 이제는 좀 적응이 되었습니다. 포인터 같은 건 기존에 C 계열 언어를 써보면 익숙하니까 반갑기도 했구요. 이런 단순하고 절제된 설계 덕분인지 모르겠지만 컴파일 언어 치고는 컴파일이 정말 빠릅니다. 외부 모듈 의존성 관리하는 것도 이 정도면 정말 깔끔하구요. 나무랄 부분이 별로 없습니다.

그럼에도, 감히 말씀드리자면 아쉬운 부분들이 적진 않았습니다. 일단 가장 큰 불만사항은 생각보다 쓸만한 라이브러리가 다양하지 않다는 점입니다. 이미징 라이브러리의 경우만 보더라도 일단 몇 개 뿐이고, 그 마저도 성능 측면에서 괜찮아 보이는 건 libvips 같은 외부 라이브러리를 사용하는 것 정도입니다. Go 언어가 스크립트 언어에 비한다면 충분히 의미있게 빠르겠지만, 이렇게 핵심적인 라이브러리들이 다 C 기반 라이브러리에 여전히 의존하는 점은 역설적이게도 Go 언어의 한계를 보여주는 부분이라고 생각합니다. 즉 C나 C++을 대체하는 언어는 아니라는 점입니다. 지향하는 바가 다르다는 걸 느낄 수 있었습니다.

그리고 가끔 왜 이렇게 했을까? 하는 부분들이 있는데, 2가지 정도만 언급해 보겠습니다. 첫번째는 if err ≠ nil { … } 과 같은 에러 핸들링입니다. 에러 처리는 Go 언어에서 즉시 하도록 설계되어 있고, 나중으로 미루거나 한 번에 모아서 한다 같은 개념은 없습니다. 물론 여러 개의 에러들을 핸들링하는 공통 로직이 있다면 그걸 묶어서 다시 에러 처리를 하면 되겠지만, 어쨌든 저 에러 처리 구문은 계속 등장합니다. 정말 나중에는 if err 코드를 입력하는 것 조차 짜증이 날 때가 있습니다. defer 같은 키워드도 제공해주면서 에러 처리는 왜 저렇게 하도록 하는 걸까 싶네요. 굳이 장점으로 뽑자면, 에러가 생기는 즉시 핸들링을 명시적으로 하기 때문에 문제를 빠르게 확인할 수 있다…? 잘 모르겠습니다. 일단 저렇게 해야 하니까 해야죠 뭐.

두번째는 슬라이스인데, var results []Result 이 코드와 results := make([]Result, 0) 의 차이입니다. Go 언어가 저보다 더 생소하실 분들을 위해 설명드리면, 두 코드는 기본적으로 같은 목적으로 사용됩니다. results 라는 변수는 슬라이스 변수인데, C 언어스럽게 표현해보면 일종의 배열의 포인터를 가지고 있는 변수입니다. 그래서 둘 중 어느 방식으로 변수를 선언하더라도, results = append(results, item) 처럼 배열에 값을 더 추가하거나 등의 작업을 할 수 있습니다. 여기까지만 읽으면 뭐가 문제지? 라고 생각하실 수 있는데… 문제는 저 코드들이 서로 다른 표현을 하는 이유가 있다는 점입니다.

var results []Result 같은 경우에는, 초기값이 nil 입니다. C++ 에서 말하는 nullptr 이랑 같다고 보시면 되고, 자바스크립트에서는 null 과 같다고 보시면 됩니다. 그리고 results := make([]Result, 0) 이 코드에서 results 는 nil 이 아닙니다. 빈 배열 슬라이스를 가지며 단지 크기가 0 일 뿐입니다. 좀 더 생각해보면, 초기화가 어쨌든 되어 있습니다. 응? 초기화가 안되어도, 초기화가 되어도 동작이 똑같다고?? 그렇습니다. 둘의 차이는 초기화의 차이지만, 동작은 동일합니다. 그럼 대체 뭐가 문제일까요?

 

문제는 아무런 값도 추가하지 않고 그냥 변수만 선언한 상황에서 값을 반환할 때 입니다. 특히 JSON 형태로 클라이언트에게 값을 전달해줘야 하는 경우를 생각해 볼 수 있습니다. 우리가 자바스크립트로 예를 들어서 서버로부터 넘어온 값을 받는다고 합시다. 이 때 results 라는 이름의 배열에 값들이 하나도 없을 경우, 우리는 무엇을 기대할 수 있을까요? 당연히 [] 입니다. 이렇게 넘겨 받아야 빈 배열이니까 results.length 같은 걸 사용 할 수 있겠죠.

results := make([]Result, 0) 으로 작성한 코드는 우리의 기대대로 동작합니다. 초기화가 되어 있고, 빈 배열 슬라이스를 가지므로 JSON으로 리턴할 때 [] 으로 리턴됩니다. 하지만 var results []Result[] 을 리턴하지 않습니다. 이 코드는 null 을 리턴합니다. 초기화가 되어 있지 않기 때문에, nil 값이 JSON 형태로 변환되면서 null 이 됩니다. 그럼 results.length 같은 걸 쓸 수 있을까요? 안되죠. 추가적으로 클라이언트에서는 null 검사를 해줘야 합니다. 그냥 빈 배열로 넘어오면 되는 문제인데, 생각지도 못하게 일이 꼬일 수가 있습니다. 저처럼 Go 언어에 익숙하지 않은 사람들은 이 함정에 생각보다 쉽게 빠질 수 있어서 주의가 필요합니다.

 

언어 자체적으로 비슷하게 동작하지만 서로 다른 결과를 낼 수도 있는 방식을 제공하는 건 조금 의외였습니다. 그 흔한 while 문도 없고 for 문으로 통일했으면서 왜 저건 저렇게 두는 건지 의아했습니다. 물론 제가 아직 잘 몰라서 그런 것이겠지만, 처음 접하는 입장에서는 저 차이를 모르고 그냥 막 썼다가 피를 보고나니 조금 물음표가 생기게 된 것도 사실입니다.

 

물론 저거 말고도 있습니다만, 장점도 그에 못지 않으니 이 정도로 마무리 하겠습니다. 장점 하니까 생각나는데, 아까 말씀드렸던 defer 키워드는 그래도 쓸만합니다. 예를 들어 어떤 핸들러를 열어놓고, 해당 코드를 포함하는 함수가 리턴하기 직전에 항상 닫아야 할 경우, Go 언어는 중간에 그 많은 if err ≠ nil { … } 코드마다 핸들러의 자원을 해제하는 코드를 추가해야 합니다. 끔찍하죠. 그러나 defer 키워드가 있으면 언제 로직이 종료되고 함수를 떠나더라도 그 직전에 항상 자원 해제 코드를 실행해 줍니다.

// 대시보드용 최근 게시글 목록 가져오기 (TSBOARD admin_repo.go 발췌)

func (r *TsboardAdminRepository) GetDashboardPosts(bunch uint) []models.AdminDashboardLatestContent {
	items := make([]models.AdminDashboardLatestContent, 0) // 빈 배열 슬라이스는 반드시 make로!
	query := fmt.Sprintf("SELECT uid, board_uid, user_uid, title FROM %s%s ORDER BY uid DESC LIMIT ?",
		configs.Env.Prefix, models.TABLE_POST)
	rows, err := r.db.Query(query, bunch)
	if err != nil {
		return items
	}
	defer rows.Close() // GetDashboardPosts 함수가 종료되는 시점에 맞춰서 호출해줍니다.
    
    for rows.Next() {
		item := models.AdminDashboardLatestContent{}
		var boardUid, userUid uint
		err = rows.Scan(&item.Uid, &boardUid, &userUid, &item.Content)
		if err != nil {
			return items
		}

		boardId, boardType := r.FindBoardIdTypeByUid(boardUid)
		item.Writer = r.FindWriterByUid(userUid)
		item.Id = boardId
		item.Type = boardType
		items = append(items, item)
	}
	return items
}

 

defer 키워드가 없었더라면 정말 어땠을지 끔찍하네요. 이 키워드 만큼은 특별히 예제 코드로 소개해 드리고 싶어서 가져왔습니다.

 

JS 월드에서 GO 월드 이사 후기

 

어쩌다보니 글이 또 길어졌는데, 이제 마무리 할 겸 이사 후기를 말씀드리겠습니다. 이제 저에게 JS 월드는 좀 익숙해진 바이크같은 느낌입니다. 배달용 스쿠터 말고 할리 데이비슨같은 그런 멋진 바이크요. 여러 대를 굴리면 가슴이 웅장해지고, 나름 쾌적하게 서비스를 운영할 수 있습니다. 물론 규모가 커지게 되면 여러 대의 바이크를 굴려야 하는 단점이 있지만, 그럼에도 작은 서비스나 빠르게 가야 할 때는 가끔 찾게 될 것 같습니다.

 

반면 GO 월드는 좀 이게 맞을지 모르겠는데 11인승 승합차같은 느낌입니다. 이것 저것 필요한 걸 잔뜩 실어두고 여러 명이 탑승해서 목적지까지 갈 수 있고, 고속도로에서 나름 속도도 낼 수 있는 그런 승합차를 타는 느낌입니다. 가까운 목적지(= 상대적으로 작은 작업) 부터 비교적 먼 거리(= 상대적으로 큰 규모의 작업)까지 두루 편하게 이용할 수 있다는 느낌입니다. 저의 경우에는 멋진 할리 데이비슨 바이크도 좋지만, 성향상 11인승 승합차가 더 편하고 익숙한 것 같습니다. 새로운 언어에서 느껴지는 익숙한 승차감이라고나 할까요?

만약 새로운 백엔드 작업이 있고, 사용자의 규모면에서나 서버 자원의 풍족함 등을 감안해야 할 경우 저는 이제 두 번 고민하지 않고 Go 언어로 작업을 하게 될 것 같습니다. 앞서 여러 불만사항들을 말했지만 그럼에도 이 언어는 충분히 배우고 부딪쳐 볼 가치가 충분한 언어라고 생각합니다. TSBOARD 뿐만 아니라 다른 목적으로도 충분히 활용 가능한 언어이니만큼, 이번에 Go 언어를 처음 접해보신 분들이라면 한 번쯤 본인의 프로젝트에도 활용해 보시는 걸 추천드리고 싶습니다.

 

언젠가 Go 언어에 충분히 능숙해지면 그 때 또 후기 비스무리하게 글을 끄적여 볼께요. 😊

  • tsboard
  • golang
  • javascript
  • 이사
  • 후기
  • defer
  • make
  • 슬라이스

TSBOARD v1.0.1 업데이트 안내

2025:01:02 23:01:13 / / written by 시리니

2025년 새해가 밝았습니다.

이 글을 읽어주실 여러분들께, 새해 복 많이 받으시고 올해는 가급적 웃는 날이 더 많아지기를 바래봅니다.

TSBOARD도 여러분들에게 더 도움이 될 수 있도록 노력하겠습니다.




TSBOARD v1.0.1 업데이트를 아래와 같이 안내드립니다.


  • 비밀글이 제대로 처리되지 못하던 문제를 수정하였습니다.

    • 비밀글 작성자와 관리자는 이제 비밀글을 문제 없이 열람 하실 수 있습니다.

    • 열람 권한이 없는 사용자라도 게시글 내용을 제외한 제목 등은 볼 수 있도록 수정되었습니다.

    • 홈 화면에서 비밀글이 그대로 노출되는 문제를 수정하였습니다.

  • 공지글이 출력되지 않던 문제를 수정하였습니다.

    • 공지글 데이터를 가져오지 않아 게시글 목록에 출력이 안되던 문제를 수정하였습니다.

    • 이번 버전부터 공지글과 일반 게시글(및 비밀글)은 서로 분리된 데이터로 관리됩니다. (BoardListResult 타입 참조)

  • 회원 가입 등의 페이지에서 상단 알림 영역의 여백 부분을 좀 더 보기 편하게 수정하였습니다.

  • goapi-linux 바이너라 파일명에 CPU 아키텍쳐를 추가하였습니다.

    • TSBOARD 프로젝트에서는 기본적으로 goapi-linux-x64 파일만 제공합니다.

    • 추가로 제공되는 goapi-mac 의 경우 애플 실리콘 맥을 사용하시는 개발자분들의 편의를 위해 가끔 제공됩니다.

    • goapi-linux-arm 등의 버전은 따로 제공하지 않습니다만, goapi GitHub를 통해 소스코드를 내려 받으셔서 직접 해당 플랫폼에 맞게 컴파일 하실 수 있습니다. (Windows 제외)

    • TSBOARD가 구동되는 서버에는 사전에 libvips 라이브러리가 설치되어 있어야 합니다.

  • 댓글에 달린 답글의 순서를 시간 순서로 보여지도록 수정하였습니다.

  • 회원 가입 시 인증 메일 (.env 파일에서 구글 지메일 앱 비밀번호를 설정하신 경우) 발송 후 인증 코드 입력 단계에서 실패하던 문제를 수정하였습니다.

    • 아울러 인증 메일의 디자인을 소폭 변경 하였습니다.

    • 인증 코드 메일은 자주 스팸함으로 빠집니다. 사용자분들에게 사전에 잘 안내를 해주셔야 합니다.


TSBOARD를 설치하신 이후, 정상적으로 페이지가 나오기 위해서는 거쳐야 할 몇가지 단계가 있습니다.


  1. 사용하시는 웹서버의 설정에서 Vue Router가 정상적으로 URL 조작을 할 수 있도록 설정 반영

    1. TSBOARD README.md 파일에서 확인 하실 수 있습니다.

    2. 파일 업로드 크기 제한, SSL 적용, Proxy 설정, root 경로 지정도 함께 진행이 필요합니다.

    3. 웹서버 설정에 어려움을 느끼시는 분들은 문의글을 통해 어디서 막히셨는지 내용을 공유해주세요!

  2. 생성된 .env 파일에서 포트 번호 등 서버 환경에 맞게 필요 시 값 수정

  3. tsboard.config.ts 파일에서 PROD_URL, PREFIX, QUICK_BUTTONS 등의 값들을 확인 후 필요시 수정

  4. npm i, npm run build 실행

  5. goapi-linux-x64 바이너리를 tmux 와 같은 곳에서 실행


위의 설명이 혹시 이해가 잘 안되시거나, 혹은 막히는 부분이 있으시다면 언제든지 문의글 부탁드립니다.


이번 v1.0.1 작업을 진행하면서, 생각보다 보완이 필요한 부분들이 많다는 걸 알게 되었습니다.

더 많은 테스트를 통해서 TSBOARD가 보다 안정적으로 대규모의 커뮤니티 사이트들을 지탱할 수 있도록

여러분들의 도움을 부탁 드립니다!

  • tsboard
  • 업데이트

2024년 마지막 커밋 기념 데스크샷

2024:12:31 23:34:15 / / written by 시리니

TSBOARD를 개발하면서 올해 (아마도) 마지막 커밋을 마치고 촬영한 데스크샷입니다. 한참 윈도만 사용해서 개발하다가, 어느 새 제 데스크에는 애플 제품이 가득 차 버렸네요. ㅎㅎ;;


가장 마지막에 산 맥미니 프로는 지금도 쓰면서 느끼는데 정말 감동적인 성능입니다. 내년에 맥 스튜디오는 또 얼마나 좋아질지 모르겠지만, 저는 이정도로도 개발은 충분히 할 수 있을 것 같습니다. 😊

  • 데스크샷
  • 2024
  • 마지막
  • 커밋
  • tsboard

TSBOARD v1.0.0 정식 버전 공개합니다

2024:12:30 22:54:41 / / written by 시리니

TSBOARD v1.0.0 출시 소식을 전하기에 앞서서

제주항공 여객기 참사로 희생된 모든 분들을 깊이 추모합니다.

 


 

안녕하세요. TSBOARD 개발하고 있는 시리니입니다.

 

지난 RC (출시 후보) 글에서 말씀드린대로, 2024년이 저물기 전에 (체감상) 1년 가까이 개발해 온 TSBOARD의 정식 버전을 공개합니다.

 

처음에는 프론트엔드와 백엔드 모두 타입스크립트로 작성한 고성능 웹 게시판(?)을 목표로 개발을 진행 했습니다.

그러다 백엔드 런타임으로 선택했던 Bun 초기 버전의 가상 cpu 동작 불가 버그 및 패키지 관리 문제를 만났습니다.

고심 끝에 v1.0.0 출시 전에 Go 언어로 백엔드를 완전히 새로 개발 한다는 결정을 내렸고, 마침내 v1.0.0 공개에 무리가 없는 수준까지 오게 되어서 내놓게 되었습니다.

 

많은 시행착오와 어려움이 있었지만, 새로웠던 Bun 런타임의 가능성과 한계를 알게 되어 행복했습니다.

또한 전혀 배운 적이 없던 Go 언어로 우여곡절 끝에 그럴듯한 백엔드 설계/구현까지 진행 할 수 있게 된 점이 가장 큰 성과라고 생각합니다.

그리고 TSBOARD라는 프로젝트를 시작하지 않았더라면 알 수 없었을 “만드는 즐거움”을 다시 되찾은 것이 무엇보다 가장 기쁩니다.

 

아직 많이 부족하고, 그러기에 TSBOARD는 계속해서 앞으로 전진할 생각입니다.

언젠가 많은 분들이 새로운 웹사이트를 TSBOARD로 개발하고, 또 여러 동료 개발자분들께서 새로운 웹서비스를 개발하실 때 기꺼이 참고가 되고 도움이 될만한 프로젝트로 거듭날 수 있도록 계속해서 즐겁게 하나씩 만들고 여러분들과 나누겠습니다.

 

아래는 v1.0.0 정식 버전의 출시 노트입니다.

 

  • 전체 사이트 설계는 Client Side Rendering 방식으로 구성되어 있습니다. 즉, 페이지 라우팅의 기준은 클라이언트입니다.

  • DB는 MySQL 혹은 Mariadb를 사용합니다. 설치 단계에서 mysqld.sock 혹은 mysql.sock 파일 경로를 기입하실 수 있습니다.

  • 사용을 위해 설치 후 자동으로 생성되는 .env 파일 및 tsboard.config.ts 파일의 수정이 필요합니다.

  • Windows 환경은 지원하지 않습니다. 아래 후술할 libvips 라이브러리 설치 및 링크 과정이 매끄럽지 못해 제외하였습니다.

  • TSBOARD에서 이미지 처리는 서버에 미리 설치된 libvips 라이브러리에 의존합니다. (README.md 에서 설치 안내 참조)

  • 프론트엔드 개발을 위해 Node.js 는 여전히 필요합니다. TSBOARD 프로젝트를 clone 하신 후 npm i 를 한 번 실행해주세요.

  • Bun 런타임에 대한 의존성은 제거되었습니다. 설치 및 백엔드 실행은 TSBOARD 프로젝트 내 goapi-linux 를 사용하세요.

  • 소셜 로그인 및 AI 기능 사용을 위해서는 각 서비스 업체에서 제공하는 정보들을 .env 파일에 기입해 주셔야 합니다. (필수 아님)

  • 회원 가입, 댓글 알림 등에 사용되는 메일 발송 기능을 사용하기 위해선 구글 지메일의 앱 비밀번호가 있어야 합니다. (필수 아님)

  • 사용을 위해 반드시 README.md 를 읽어주시고, 웹서버의 프록시 및 SSL 설정도 꼭 잊지 말고 해주시길 당부 드립니다.

  • 프론트엔드의 개발 스택은 아래와 같으며, 모두 타입스크립트로 작성되었습니다.

    • Vue3 (Composition API), Pinia, Vue Router, Vuetify (UI 프레임워크), Tiptap (에디터)

    • TSBOARD UI의 핵심은 Vuetify 입니다. 디자인 수정 등을 위해선 Vuetify에 대한 사전 지식이 필요합니다.

  • 백엔드의 개발 스택은 아래와 같으며, Go 언어로 작성되었습니다.

    • Fiber v3 (웹 프레임워크), go-mysql-driver (DB 드라이버), bimg (이미지 라이브러리) 등

    • 백엔드에서 참조하는 설정은 .env 파일에 있습니다. goapi-linux 실행 파일이 .env 파일과 같은 폴더에 있어야 합니다.

    • goapi-linux 파일에 실행 권한이 있어야 백엔드가 실행됩니다. chmod +x ./goapi-linux 등으로 부여해주세요.

    • 백엔드 코드는 TSBOARD 기본 프로젝트와 분리되어 개발되고 있습니다. 기본적으로는 TSBOARD 프로젝트 내에서 필요하신 부분들을 수정하여 사용하시고, 필요한 경우에만 goapi 프로젝트를 clone 하셔서 목적에 맞게 수정하여 사용하시는 걸 권장합니다.

  • TSBOARD는 일반적인 게시판, 블로그 및 갤러리를 기본으로 제공하고 있습니다. 더 많은 기능들이 앞으로 제공될 예정입니다.

  • 가장 이상적인 TSBOARD의 활용처는 중소 규모의 커뮤니티 사이트입니다.

  • TSBOARD 프로젝트는 MIT 라이선스로 제공됩니다.

  • 버그 제보 및 의견 제안 등 환영합니다. (가급적이면 여기 공홈에서 부탁드려요!)

 

아래는 쇼케이스 입니다. (제가 운영하고 있습니다)

 


 

사진 커뮤니티 : SENSTA.ME

 

TSBOARD v1.0.0 정식 버전 출시 소식을 보러 와주신 모든 분들께 감사 드립니다.

마지막으로 아래 GitHub 링크들을 공유드립니다. (개발자 여러분들, 스타 한번씩 부탁드려요!)

 

 

당분간은 v1.0.z 마이너 버전 업데이트로 찾아 뵙겠습니다.

2025년 새해 복 많이 받으시고, 새해에는 올해 연말의 여러 어려움들을 함께 극복할 수 있기를 바래봅니다.

 

감사합니다.

  • tsboard
  • 정식버전
  • 공개
  • 출시노트
  • 쇼케이스
  • node → go로 전환한게 흥미롭네요 재미있게 봤습니다.

    2024:12:31 18:33:46 / / written by 깁슨 (Gibson)
  • ㅎㅎㅎ 재밌게 봐 주셔서 감사합니다. 새해 복 많이 받으세요!

    2024:12:31 23:19:38 / / written by 시리니
  • 올해 마지막 커밋으로 답글 작성 시 보여지지 않던 문제를 수정 하였습니다…!

    이 글을 봐 주신 모든 분들께 새해 복 많이 받으시고 새해에도 TSBOARD 프로젝트에 많은 관심 부탁드립니다!

    2024:12:31 23:24:54 / / written by 시리니
  • 제가 사용하는 테스트 서버 oracle cloud에 있는 arm 서버인데 기본 tsboard 프로젝트 내 goapi-linux 는 exec format error 가 발생합니다. 그래서 goapi 프로젝트를 직접 clone 받아서 cmd 폴더 내에서 go build 를 실행 후에 생성된 바이너리 파일에 설치 프로세스를 진행하면 제일 마지막에 → Are you sure all the information you entered is correct? [Yes/No/Quit]: Y

    2025/01/02 13:41:03 💣 Failed to install TSBOARD, the database connection details you provided may be incorrect or you may not have the necessary permissions to create a new .env file. Please leave a support request on the [tsboard.dev] website! 에러가 나오네요. 입력한 mysql 계정에는 grant all 로 *.* 권한을 주었고 mariadb는 10.11.8 버전입니다. mariadb 에는 error log가 올라오는 건 없고, goapi를 생성하는 폴더의 소유자 및 권한은 ubuntu 계정 및 755 권한입니다.

    2025:01:02 13:53:40 / / written by 꼬반
  • 안녕하세요! 먼저 시간 내어 주셔서 테스트를 해주심에 감사드립니다!

    oracle cloud에서 제대로 동작하지 않는 문제가 있네요. 제가 무료 oracle clound (ARM cpu) 계정을 추후 생성해서 직접 디버깅을 해보겠습니다.

    조금 시간이 걸릴 수도 있는데 최대한 빠르게 디버깅해서 내용 공유드리겠습니다!

    2025:01:02 15:59:50 / / written by 시리니
  • 앗 아닙니다. 새로 빌드해서 동작시켰습니다 ㅎㅎ.


    다만 첫 화면 블로그 관련 최근글과 클릭 시 이동에서 param id 미 설정 으로 나오는 부분만 한번 확인 부탁 드려도 될까요?


    테스트 주소는 https://tsboard.ggoban.com 입니다. 감사합니다.

    2025:01:02 16:50:17 / / written by 꼬반
  • 앗 다행히 빌드 후 동작은 가능해졌군요!

    말씀해주신 부분 다시 확인해서 필요시 고치고 말씀드리겠습니다!

    2025:01:02 17:35:39 / / written by 시리니
  • 사이트에 잠깐 들어가 보았는데, Nginx 서버 설정 /etc/nginx/sites-enabled/default 부분 수정이 아직 안된 것 같습니다!


    README.md 파일을 보시면 Nginx 서버 설정 부분이 나타나는데, Vue Router의 원할한 동작을 위해서

    아래의 부분처럼 수정이 필요합니다.


      location / {
        try_files $uri $uri/ /index.html; # Vue Router 활용을 위한 설정 (CSR)
      }


    위 부분을 다시 확인해 보시고 어떻게 되어 있는지 말씀 부탁드릴께요!

    2025:01:02 17:40:06 / / written by 시리니
  • 바쁘신 와중에도 테스트를 도와주셔서 너무나도 감사드립니다…!

    아직 부족한 부분이 많습니다. 설치 과정에서 좀 더 나은 사용 경험을 위해 어떤 부분을 개선하면 좋을지 많은 의견 부탁드립니다!

    2025:01:02 23:12:34 / / written by 시리니
  • 답변 감사합니다. 우선 아래 nginx 쪽 설정을 중간에 안봤네요 ㅎ 보고 설정은 다 했습니다. 안그래도 admin 쪽 router가 왜 동작이 이상한가 했더니… 내일 일단 DB랑 .env를 지우고 다시 셋팅한번 해보려고 합니다. 답변 감사합니다.

    2025:01:02 22:48:37 / / written by 꼬반

멕시코 칸쿤 : 스칼렛 아르떼

2024:12:29 14:06:36 / / written by 시리니

업로드 테스트 겸 해서 올려보는 칸쿤 두번째 사진입니다. 태양이 따뜻하다못해 뜨거운 곳이었는데, 요즘처럼 몸과 마음이 추운 시기에 가면 좋을 곳입니다. 스칼렛 아르떼는 하야트 지바처럼 대부분의 식당이 숙박비에 포함되어 있고, 더불어서 야외 놀이 시설도 모두 포함되어 있었습니다. 더도 말고 덜도 말고 딱 한 달만 그렇게 살아보면 좋겠다는 생각이 무럭무럭 샘솟네요.

  • 멕시코
  • 칸쿤
  • 업로드
  • 테스트
  • 스칼렛
  • 아르떼
  • 업로드 및 이미지 처리가 진행중일 때는 이미지가 나타나지 않습니다. 처리가 완료되면, 썸네일 이미지 (및 이미지 설명, EXIF 등)가 보여집니다.
    2024:12:29 14:08:32 / / written by 시리니

TSBOARD v1.0.0 RC (출시 후보) 공개합니다!

2024:12:29 02:18:39 / / written by 시리니

안녕하세요! TSBOARD를 개발하고 있는 시리니입니다.


생각보다 공지글이 늦어졌습니다.

24년이 지나가기 전에 TSBOARD v1.0.0 출시할 수 있겠지, 라고 막연히 생각했었는데 ㅎㅎ

가까스로 시간을 맞출 수 있게 될 것 같습니다.


지금 보고 계시는 TSBOARD 공홈의 경우 이미 v1.0.0-rc 버전을 적용한 상태입니다.

디자인이 살짝 바뀌었나? 하실 수도 있는데, 이미 블로그를 통해서 소개드린대로, 백엔드를 Go 언어로 완전히 새롭게 작성하면서

초기에 Bun 런타임 기반의 TSBOARD에서는 꽤나 많은 부분들이 달라졌습니다.


굉장히 많은 변경사항들이 있기 때문에, 굵직한 부분들만 추려서 아래에 소개 드리겠습니다.


v1.0.0-rc 주요 변경사항


  • TSBOARD의 백엔드가 기존 Bun 기반의 타입스크립트 코드에서, Go 언어로 완전히 변경 되었습니다.

    • 새로운 백엔드는 서버 자원의 보다 효율적인 활용 및 고 가용성을 보장하기 위해 개발하였습니다.

    • Fiber (v3), go-mysql-driver 및 bimg 등의 라이브러리를 사용하여 빠르고 안정적인 동작이 가능합니다.

    • 새로운 백엔드는 Bun 런타임에 대한 의존성을 더 이상 가지지 않습니다. 단, Node.js는 여전히 필요합니다.

    • 새로운 백엔드는 이미징 처리를 위해 서버에 libvips 라이브러리가 미리 설치되어 있어야 합니다.

    • libvips 라이브러리 의존성 문제로 인해, TSBOARD는 Windows 환경에서의 동작을 지원하지 않습니다.

  • TSBOARD의 프론트엔드는 기존의 Vue3 + Vuetify3 조합으로 계속 유지됩니다.

    • tsboard.config.ts 설정 파일에서 COLOR 항목을 통해 사이트의 주요 색상값을 쉽게 변경 하실 수 있습니다.

    • v1.0.0-rc 버전부터 디자인이 좀 더 라운딩이 강조된 형태로 변경되었습니다.

    • 새로 작성된 백엔드에 API 요청을 보내고 받는 부분들은 모두 axios 라이브러리를 사용하는 걸로 변경되었습니다.

  • 설치는 goapi-linux 를 통해서 진행 하실 수 있습니다.

    • (리눅스의 경우) goapi-linux 바이너리를 실행 하시면, .env 파일이 없을 경우 설치 화면이 나타납니다.

    • CLI로 제작된 설치 화면에서 DB 접속 정보 등 몇가지 정보를 입력하시면 쉽게 설치 하실 수 있습니다.

    • 설치가 완료되고, DB 접속에 문제가 없을 경우 곧바로 백엔드 서버가 시작합니다.


RC (출시 후보)는 큰 문제가 없는 한 그대로 정식 버전으로 사용 가능한 버전 입니다.

공지글을 올리진 않았습니다만, 그 전에 beta 버전을 계속 진행하면서 큰 변화들을 적용 하였고,

이제는 변경 사항들 중에서 의도대로 동작하지 않거나 잘못 동작하는 부분들 위주로 디버깅을 진행할 예정입니다.


빠르면 12/29 저녁에, 늦어도 12/31 저녁 즈음에는 v1.0.0 정식 버전 출시 소식을 전해드릴 수 있도록 하겠습니다.

혹시 테스트를 도와주실 분들은 https://github.com/sirini/tsboard 깃헙의 README.md 부분을 먼저 읽어주시고

설치에 도전해 보시길 바랍니다! 잘 안되시는 부분들은 언제든지 질문 남겨주세요!

  • tsboard
  • 출시후보
  • beta
  • goapi
  • bun

Mac mini pro 간단 사용기

2024:12:10 00:31:55 / / written by 시리니

아주아주 간단하게 남겨보는 맥미니 프로 사용기입니다. (지금도 맥미니에서 작성중)

상세한 사용기는 한 달 이상 쓰고 나서 그 때 좀 더 업데이트를 해보도록 하겠습니다. 참고로 이전에 사용한 기기는 Mac Studio (M1 Max) 입니다!


  • 정말 작고 조용하다

    • 이렇게 작을 줄 몰랐습니다. 가볍기도 정말 가벼워서, 미니PC 살 돈을 두세번 모아서 차라리 맥미니를 사는 게 어떨까 싶을 정도로 괜찮습니다. 입력 포트도 이정도면 훌륭하네요. (아쉬운 건 USB-A 타입 포트랑 SD카드 리더기가 없다는 것)

    • 정말 조용합니다. 팬이 달려는 있는 건가? 싶었는데 가끔 존재감을 살짝 느끼게 해주고 다시 잠잠해지는 게, 홈서버로 쓰면 어떨까 싶을 정도입니다. 음, 홈서버로 쓸까 했는데 가성비가 좋진 않겠네요. ㅎㅎ

  • 진짜 빠르다

    • 이전에 사용한 Mac Studio (M1 Max) 대비해서도 굉장히 빠른 반응입니다. 이건 뭐 비교하기가 조금 미안한 수준일 듯 하고, 제가 주로 사용하는 프로그래밍 관련 도구들에서도 좀 더 쾌적함을 느낄 수 있었습니다.

    • 아직 써보진 않았는데, 예전에 많이 쓰던 파이널컷 기준으로 하면 맥미니 프로 정도에서 왠만한 작업은 무리없이 소화 가능하다고 합니다. 저도 기대중인데, 앞으로 영상 작업하시는 분들은 굳이 맥 스튜디오 구매하지 않으셔도 되지 않을까 싶습니다.

  • 하지만 가격이 사악해

    • 첫 시작 가격은 정말 좋은데, 저처럼 프로 모델을 고민하시거나 램 혹은 저장 공간을 늘리고 싶은 분들은 이 사악한 가격 정책에 소름 돋으실 겁니다. 진짜 너무 비싸요.

    • 불행인지 다행인지 썬더볼트 인터페이스를 이용한 SSD를 사용하거나 하면 저장 공간 문제는 좀 자유로워질 수 있는데, 램은 그게 안됩니다. 그래도 애플 인텔리전스 덕분에 시작 용량을 16GB로 해서 얼마나 다행인지, 이게 바로 혁신인 걸까요?


만약 저처럼 맥 스튜디오를 사용하시면서 32GB 램은 필수지! 하셨던 분들이 계시다면, 맥미니 프로에서 24GB 램으로 내려오셔도 괜찮지 않을까 싶습니다. 램이랑 CPU/GPU 숫자가 더 많아야 하시는 분들은 내년 상반기까지 맥 스튜디오 기다리시면 되는데, 솔직히 이제는 맥미니 프로 정도면 어지간한 작업들은 그냥 가능해서 더 올라갈 필요는 없어 보입니다. 그리고 모르긴 몰라도 맥미니 프로 가격들을 보니까 내년 상반기의 맥 스튜디오는 가격이 정말 사악하게 나올 가능성이 높습니다.


저는 맥미니 프로에서 몇 년 더 존버하면서 버티다가, 또 성능 향상이 큰 폭으로 생기는 시점에 업그레이드를 노려볼까 합니다. ㅎㅎ

  • 맥미니
  • 프로
  • mac
  • mini
  • pro
  • 간단
  • 사용기

TSBOARD v0.9.11 업데이트 안내

2024:12:02 23:34:38 / / written by 시리니

안녕하세요! TSBOARD 만들고 있는 시리니입니다.


백엔드 교체 및 Bun 런타임 의존성 제거라는 큰 변화를 앞두고 있는 TSBOARD의 마이너 업데이트를 아래와 같이 안내드립니다!


  • 블로그에서 글 수정 시 다크 테마가 제대로 적용되지 않던 문제 수정

  • code 내용이 길거나 모바일 기기에서 볼 때 잘린 영역이 스크롤 되지 않던 문제 수정

  • npm audit fix 적용 (라이브러리 업데이트), README 내용 일부 수정


TSBOARD는 JS/TS 런타임이자 올인원 도구인 Bun의 가능성에 주목하여, 처음 프로젝트를 시작할 때부터 지금까지 Bun과 함께 했습니다. 여러 가지 제약들이 있었지만, Bun의 놀라운 성능과 더불어 안되던 기능들이 지속적으로 개선되는 모습이 대단하기도 했고 또 제 선택이 옳았다는 자부심도 가질 수 있었습니다.


이제 가상 서버에서도 제대로 동작하고 (지금 보시는 이 곳 TSBOARD 공홈도 단칸방 같은 작은 가상서버 호스팅을 사용 중입니다!), 사용에 대부분은 문제가 없긴 합니다만… 그럼에도 여전히 npm i 대비 문제가 많은 bun install 부터 아직 보완이 필요한 부분들도 상당히 많습니다. 그리고 사용자에게 Node.js와 Bun 모두 설치를 요구하는 것도 더 이상 무리라고 판단하여, 곧 다가 올 v1.0부터는 Bun 런타임에 대한 의존성을 모두 제거할 예정입니다.


TSBOARD의 프론트엔드는 Vue3 + Vuetify3으로 구성되어 있습니다. 따라서 프론트엔드를 수정하고 빌드를 하려면 Node.js 및 npm은 계속 필요합니다. 다행스럽게도 Node.js가 세상에 나온지 이제 10년도 더 되었기 때문에, Node.js에 대한 의존성은 크게 부담되지 않으실 것 같습니다.


v1.0 출시 전까지 몇차례 더 지금과 같은 마이너 업데이트가 있을 예정입니다. 즐거운 마음으로 v1.0 출시를 기다려주세요!

  • tsboard
  • 마이너
  • 업데이트
  • bun
  • 런타임
  • 의존성
  • 제거
  • nodejs

서버 이전 완료!

2024:12:02 20:36:35 / / written by 시리니

안녕하세요! TSBOARD 개발하고 있는 시리니입니다.


예상치 못하게 일요일 저녁에 작성한 블로그 글이 news.hada.io 덕분에 핫해져서 오늘 이래 저래 접속이 원할하지 못했습니다.

사실 접속 문제는 DDNS의 문제였습니다만, 이참에 tsboard.dev 공홈을 방구석 미니PC에서 호스팅으로 옮기기로 결정하였습니다.

앞으로는 보다 원할하고 빠릿하게 방문하실 수 있습니다!


작업은 12월 2일 22시 이후부터 23시 사이에 진행될 예정이며, 이 시간 동안 접속이 어려우실 수 있습니다!




12월 2일 22시 30분을 기점으로 서버 이전 작업을 마무리하였습니다! (현재는 TSBOARD v0.9.11 작업 중…😆)

마치 고향에 논밭도 넓고 방도 여러 개인 전원 주택에 살다가, 서울 외각의 작은 원룸 하나를 얻은 듯한 기분입니다.

아주 작은 공간을 빌려서 시작하지만, 인생이 그렇듯 이 프로젝트도 언젠가 더 넓은 공간을 가질 수 있기를 기대해 봅니다…!


오늘 하루 접속이 불편하셨을텐데 이해해 주셔서 감사드립니다!

  • 서버
  • 이전
  • 안내
  • 호스팅
  • 새집
  • 원룸
  • 이사
  • 완료

Go vs Bun, Go언어는 정말 JS 런타임보다 빠를까?

2024:12:01 22:04:03 / / written by 시리니

정말 오랜만에 (아마도 장문이 될) 주제로 블로그에 글을 쓰는 것 같습니다. 먼저 서두에 밝혀두고 싶은 점은, 이번 벤치마크는 완전히 변수들을 통제한, 정말 제대로 각잡고 한 벤치마크는 아니라는 점입니다. 어디까지나 리얼 월드에서 과연 어느 정도의 차이가 벌어지는지 실제 프로젝트로 비교해본 것이라는 점을 밝혀둡니다.


먼저 제 글을 시작하기 전에, 한 번쯤 봐두면 좋을 다른 분의 블로그 글을 소개해 드립니다.

https://medium.com/deno-the-complete-reference/bun-vs-go-native-hello-world-performance-006791174df2


위 블로그의 글을 요약하면, “생각보다 Go가 그렇게 빠르진 않네?” 라는 결론이 나옵니다.

그리고 본 글에서도 결론은 동일합니다.


결론 먼저, Go 언어는 때때로 빠르지 않습니다.


Go언어는 단순하면서도 꽤나 빠른 속도로 동작한다고 알려져 있습니다. 그리고 실제로 여러 벤치마크를 통해 알려진 것처럼, Rust나 C++에 비할 정도는 아니어도 꽤나 빠릅니다. 특히 자바스크립트 런타임들이 가지고 있는 태생적인 한계인 CPU 집약적인 연산이나, 여러 병렬 처리 및 동시성 제어 등에서 정말 큰 장점들을 가지고 있습니다. 저도 TSBOARD의 새로운 백엔드를 Go언어로 재작성 하면서, 이런 점들을 확실히 알게 되었고 이 언어가 지향하는 곳이 클라우드라는 점도 명확히 알게 되었습니다.


우선 아래의 표를 먼저 살펴보시죠.


M1 Max

(Mac Studio)


Go (1.23.3)


Bun (1.1.37)


Test Path

Number of Requests

Number of Workers

Requests per second

Memory (MB, peak)

Requests per second

Memory (MB, peak)

/home/tsboard


100,000

10

66923.28

21.3

61038.01

99.5

(No DB conn.)

100,000

50

118127.24

21.3

64482.78

99.5


100,000

100

125999.24

21.2

64933.38

99.3


(참고: hey 라는 Go 언어로 작성된 도구를 이용하여 측정한 결과입니다.)


// /home/tsboard 접속 시 출력되는 내용, DB 연결 없음
{
  "success": true,
  "error": "",
  "result": {
    "success": true,
    "officialWebsite": "tsboard.dev",
    "version": "1.0.0-beta1",
    "license": "MIT",
    "github": "github.com/sirini/goapi"
  }
}


실제로는 서두에 언급한 것처럼 완벽하게 동일한 비교가 아니고, Go언어에서 출력해줘야 하는 데이터가 좀 더 많습니다. (Go의 요청 별 응답 크기: 160 bytes / Bun 응답 크기: 114 bytes) 그럼에도 불구하고, Go는 Bun과 비교했을 때 더 높은 초당 요청 처리횟수를 보여주면서도 메모리는 Bun 대비 20% 수준만 사용하고 있습니다. 물론 CPU 사용량은 Bun 대비 2~3배 가량 높았지만, 그럼에도 이 결과만 두고 봤을때는 정말 놀라운 수준입니다.


아니, 그럼 결론을 제가 잘못 말한 게 아닌가 싶겠지만…! 이제 아래의 표도 같이 살펴보시죠.


M1 Max

(Mac Studio)


Go (1.23.3)


Bun (1.1.37)


Test Path

Number of Requests

Number of Workers

Requests per second

Memory (MB, peak)

Requests per second

Memory (MB, peak)

/home/latest

1,000

10

70.98

35

101.45

142.5

100 posts

1,000

50

67.99

87.9

104.6

194.9

per request

1,000

100

67.97

159.5

102.57

250.5


(참고: 이번에도 Go의 요청 당 응답 크기가 더 높은 패널티가 있습니다 ▸ Go: 621,343 bytes / Bun: 526,198 bytes)


// /home/latest 출력 예시, DB 연결이 요구되며 한 번의 요청에 100건의 최근 게시글을 가져오도록 했습니다.
// Go로 백엔드를 재작성하면서, 필요한 데이터가 좀 더 많아져서 요청 당 응답 크기는 Go쪽이 불리합니다.

{
  "success": true,
  "error": "",
  "result": [
    {
      "uid": 1234,
      "title": "제목 예시 (실제로는 더 긴 데이터가 출력 되었습니다)",
      "content": "내용 예시",
      "submitted": 1732253323985,
      "modified": 1732276827209,
      "hit": 1,
      "status": 0,
      "category": {
        "uid": 1,
        "name": "일반"
      },
      "cover": "/upload/thumbnails/2024/11/22/this_is_sample_output.avif",
      "comment": 4,
      "like": 0,
      "liked": false,
      "writer": {
        "uid": 1,
        "name": "홍길동",
        "profile": "/upload/profile/2024/11/16/hong_gil_dong.avif",
        "signature": "어디까지나 예시용 데이터입니다"
      },
      "id": "photo",
      "type": 1,
      "useCategory": false
    },
   // ... 이하 99개의 최근 게시글 반환
 ]
}


거듭 말씀드리지만, 완벽하게 공정한 비교는 아닙니다. Go언어로 재작성 하면서 출력해야 할 데이터가 약간 늘어나긴 했거든요. 그걸 감안하고 데이터를 보더라도, 처음에 봤던 테이블과는 사뭇 다른 결과를 보실 수 있습니다. 메모리 사용량은 여전히 Bun 런타임 대비 현저히 낮지만, 초당 요청 처리 건수는 확연히 떨어지는 걸 보실 수 있습니다.


혹시 Go언어에 익숙하지 않은 저의 잘못으로 인해 이런 일이 발생한 걸까요? 저도 제가 뭔가 잘못된 코드를 작성해서 이런 사태가 벌어진 거면 좋겠지만… 수많은 여러 테스트와 코드 수정을 통해서 다다른 결론은, Go언어가 생각만큼 늘 빠르지는 않다는 점입니다. 오히려 DB 입출력이 잦은 리얼 월드에서는 Bun 런타임과 Elysia 웹프레임워크, 그리고 mysql2 라이브러리의 조합이 예상 외로 훌륭한 결과를 보여주었습니다. 동시 요청이 많아도 Go가 보여주는 것만큼의 안정적인 동작을 보여주었고, 미약해 보였던 싱글 스레드 기반의 이벤트 루프는 비동기 I/O와 함께 의외의 슈퍼 파워를 보여주었습니다.


Go의 표준 HTTP 라우터는 쓰지 마세요, 느립니다


TSBOARD의 새 백엔드를 작성할 때, 처음에는 Go 1.23에서 소개된 표준 HTTP 라우터만 사용했습니다. 동시 접속자가 적은 실제적인 상황에서는 꽤나 훌륭하게 동작했고, 별 문제가 없어보여서 그대로 진행하려고 했죠. 하지만 이미 Bun과 Elysia 조합으로 작성된 백엔드가 있었기 때문에, 정확히 어떤 부분들이 개선되었는지 확인이 필요했습니다. 그래서 hey 도구를 이용해서 부하 테스트를 진행했는데, 세상에… 앞서 보여드린 결과보다 더 열악한 결과만 나왔습니다. 동시 요청이 많아질수록 고루틴 간에 자원을 대기하는 기간이 늘어지고, DB 풀을 대기하면서 CPU 클럭만 차지하는 경우가 많아졌습니다.


응답 속도를 Bun보다 높게 하기 위해서 몇가지 도전적인 작업을 해보았지만, 빠른 응답을 위해 유실되는 응답이 많아져 이 길은 아니라고 생각하여 포기하였습니다. 어쩔 수 없이 웹 프레임워크를 쓰기로 결정하고 Fiber가 가장 마음에 들어서 선택하였습니다. 그 후 테스트를 해보니 이제서야 Bun(Elysia) 조합에 크게 떨어지지 않는 응답 속도를 회복할 수 있었습니다.


// Go의 표준 HTTP 라우터에서 실제로 구현했던 핸들러 예시입니다

func LoadAllPostsHandler(s *services.Service) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		actionUserUid := utils.FindUserUidFromHeader(r)
		sinceUid64, err := strconv.ParseUint(r.FormValue("sinceUid"), 10, 32)
		if err != nil {
			utils.Error(w, "Invalid since uid, not a valid number")
			return
		}
        // ...
		utils.Success(w, results)
	}
}


Go언어의 새로운 기능이라서 유튜브 등에서 이 표준 HTTP 라우터를 써보라고 권하는 분들이 계실 수도 있지만, 저는 권장하고 싶지 않습니다. 기능 자체는 동작하지만 프로덕션 레벨에서 빠릿하게 동작하는 수준은 결코 아닙니다. 제가 선택한 Fiber 혹은 다른 종류의 웹 프레임워크를 선택하시길 바랍니다.


// Fiber v3 기반으로 다시 변경한 핸들러 예시입니다

func (h *TsboardHomeHandler) LoadAllPostsHandler(c fiber.Ctx) error {
	actionUserUid := utils.ExtractUserUid(c.Get("Authorization"))
	sinceUid64, err := strconv.ParseUint(c.FormValue("sinceUid"), 10, 32)
	if err != nil {
		return utils.Err(c, "Invalid since uid, not a valid number")
	}
    // ...
	result, err := h.service.Home.GetLatestPosts(parameter)
	if err != nil {
		return utils.Err(c, "Failed to get latest posts")
	}
	return utils.Ok(c, result)
}


물론, TSBOARD가 처음에 선택했던 Bun과 Elysia의 조합은 여러분들이 상상하시는 것보다 더 바르고 빠르게 동작합니다. 높은 성능과 개발 생산성을 생각한다면 굳이 Go 언어를 고민하실 필요가 없습니다.


무엇이 잘못된걸까?


여러 가지 원인이 있을 수 있지만 (그 중에서 가장 좋은 이유라면 제가 뭔가를 잘못한 것이겠죠?!), 제가 생각한 문제는 데이터베이스 드라이버입니다. Go 언어에서 MySQL/MariaDB에 연결해서 작업을 하려면 가장 많이 쓰는 go-mysql-driver를 사용해야 합니다. 이 드라이버는 여러 기능들을 갖추고 제대로만 사용하면 자원 할당/해제는 기대한 대로 동작합니다. 실제로 이 글에서 언급하지 않은 수많은 다른 테스트에서도 안정성 만큼은 문제가 없었습니다.


// 기존 TSBOARD에서 DB 연결에 사용한 코드입니다.
// pool을 생성한 후, 전역 변수에 두고 필요할 때마다 pool에서 연결을 가져와 쓰고 반환하는 식으로 썼습니다.

import mysql, { ResultSetHeader, RowDataPacket } from "mysql2/promise"

const pool = mysql.createPool({
  host: process.env.DB_HOST,user: process.env.DB_USER,password: process.env.DB_PASS,
  database: process.env.DB_NAME,
  waitForConnections: true,
  connectionLimit: 10,
  maxIdle: 10,
  idleTimeout: 60000,
  queueLimit: 0,
  enableKeepAlive: true,
  keepAliveInitialDelay: 0,
  socketPath: process.env.DB_SOCK_PATH,
})

// SELECT 쿼리문을 실행하는 헬퍼 함수를 아래처럼 구현해서 사용했습니다.

export async function select(query: string, values: string[] = []): Promise<RowDataPacket[]> {
  let result: RowDataPacket[] = []const db = await pool.getConnection() 
  try {
    const [rows] = await db.execute<RowDataPacket[]>(query, values)
    if (!rows[0]) {
      return result
    }
    result = rows
  } catch (e: any) {
    console.log(`[error/select] ${query} (${e})`)
  } finally {
    db.release() // 명시적으로 사용이 끝나면 pool에 연결을 반환합니다.
  }
  return result
}


그러나, 이 드라이버는 제가 생각했던 것보다, 그리고 다른 언어에서 구현한 MySQL / MariaDB 드라이버보다 느리게 동작합니다. 자바스크립트 생태계에서 주로 사용하는 mysql2과 같은 드라이버는 go-mysql-driver만큼이나 다양한 기능들을 제공하지만, 결과적으로 더 빠르게 동작했습니다. 물론 이것만으로 범인을 특정(?!)하는 것은 문제가 있습니다만, 자바스크립트 생태계에 있을 땐 단 한 번도 고민하지 않았던 DB I/O 성능 이슈를 Go언어에서 겪게 되고, DB 연결이 필요 없는 작업과 비교해서 결과를 보니 의심을 지우긴 어렵습니다.


// Go언어로 작성한 TSBOARD 백엔드에서 DB에 접속하는 함수입니다.
// 여기서 반환된 *sql.DB 포인터는 DB 작업이 필요한 Repository 에 전달됩니다.
// DB Pool을 생성하고, 반환하는 등의 작업이 단일 포인터에서 모두 이루어집니다.

func Connect(cfg *configs.Config) *sql.DB {
	addr := fmt.Sprintf("tcp(%s:%s)", cfg.DBHost, cfg.DBPort)
	if len(cfg.DBSocket) > 0 {
		addr = fmt.Sprintf("unix(%s)", cfg.DBSocket)
	}
	dsn := fmt.Sprintf("%s:%s@%s/%s?charset=utf8mb4&loc=Local",
		cfg.DBUser, cfg.DBPass, addr, cfg.DBName)
	db, err := sql.Open("mysql", dsn)
	if err != nil {
		log.Fatal("❌ Failed to connect to database: ", err)
	}
	if err = db.Ping(); err != nil {
		log.Fatal("❌ Database ping failed: ", err)
	}
	maxIdle, err := strconv.ParseInt(cfg.DBMaxIdle, 10, 32)
	if err != nil {
		maxIdle = 20
	}
	maxOpen, err := strconv.ParseInt(cfg.DBMaxOpen, 10, 32)
	if err != nil {
		maxOpen = 20
	}
	db.SetMaxIdleConns(int(maxIdle))
	db.SetMaxOpenConns(int(maxOpen))
	db.SetConnMaxLifetime(3 * time.Minute)
	return db
}

// 댓글에 대한 좋아요 수를 반환하는 함수입니다. DB pool에 대한 접근은 r.db (*sql.DB) 로 합니다.

func (r *TsboardCommentRepository) GetLikedCount(commentUid uint) uint {
	query := fmt.Sprintf("SELECT COUNT(*) FROM %s%s WHERE comment_uid = ? AND liked = ?",
		configs.Env.Prefix, models.TABLE_COMMENT_LIKE)
	var count uint
	r.db.QueryRow(query, commentUid, 1).Scan(&count) // r.db 가 *sql.DB 포인터를 가지고 있습니다.
	return count
}


물론 제가 뭔가 잘못한 걸 수도 있습니다. go-mysql-driver의 권장 설정을 제대로 따르긴 했지만, 아직 스스로를 고퍼라고 생각하진 않기 때문에 만약 제가 저지른 실수가 있다면 참회하는 마음으로 다시 글을 업데이트 할 생각입니다. (지금 이 글을 쓰면서 부디 제가 뭔가 잘못한 것이길 바라고 있습니다…!)


Go 언어는 느리다, 가 아니라 빠르지는 않다


모든 언어가 마찬가지지만, Go 언어도 빠르게 동작할 수 있는 부분이 분명히 있고, 기대했던 것보다는 느리게 동작하는 부분도 있습니다. CPU 집약적인 연산(예를 들면 JWT encode/decode)이나 병렬 처리해도 동시성 관리가 거의 필요없는 부분에서는 발군의 성능을 뽐낼 수 있지만, 실제 DB를 사용해야하고, DB가 주요 병목일 수 밖에 없는 백엔드에서는 기대했던 것만큼 성능이 나오질 않습니다.


Node.js가 세상에 등장하고 Deno가 나오면서 점점 더 많은 사람들이 자바스크립트/타입스크립트 런타임에 의존하고 있습니다. 이 덕분에 Bun과 같은 고성능 런타임의 개발까지 이어졌다고 생각합니다. 정말 놀라운 결과이지만, Bun 런타임과 Elysia의 조합은 정말 인상적인 성능을 보여줍니다. TSBOARD 프로젝트를 처음 시작할 때 제가 선택한 이 스택을 보다 많은 개발자분들이 직접 써보시고, 실제 현업에서도 많이 활용해 보셨으면 좋겠습니다. 정말 좋거든요!


그래서, Go 언어로 만든 백엔드는 포기하나요?


지금까지 글을 읽어주신 분들 이라면 응당 제가 Go 언어에서 다시 Bun(Elysia) 조합으로 돌아 가겠구나, 하고 생각 하셨을 겁니다. 실제로 저도 진지하게 Go 재작성 프로젝트를 중단할까 고민도 했었습니다. 고성능 백엔드 개발에 쓸 만한 언어는 다양하게 있고, 저의 최애(?) 언어인 PHP도 건재하니 말이죠. (건재한 거 맞지 PHP…? 잘 지내니…?)


그러나, 아래의 이유로 Go 언어로 백엔드 재작성을 마무리 짓고 진정한 Gopher로 거듭나고자 합니다!


  • 타입스크립트가 제공하는 타입 안정성은 부족합니다. 보다 다양한 원시 타입을 쓰면서도 타입스크립트에서 누렸던 type 정의와 interface의 활용이 가능한 Go 언어의 타입 시스템이 마음에 들었습니다.

    • Go 언어에서 포인터는 비난의 대상이지만, 저는 오히려 반가웠습니다. 가끔 이 포인터의 존재가 그리웠어요!


  • 파이썬이나 자바스크립트 같은 코드는 바로 바로 고칠 수 있고 쉽게 배포도 가능하지만, 그 코드를 동작시키는 런타임을 반드시 필요로 합니다. 물론 저는 TSBOARD 프로젝트를 통해서 어느 정도 적응을 했습니다만, 가끔 npm install 가 불러오는 무지막지한 라이브러리들의 크기를 볼 때마다 내심 놀라곤 합니다.

    • 수십 KB의 내 코드를 동작 시키기 위해 수백 MB의 라이브러리들이 준비되어야 하고, 이 모든 걸 합쳐서 함께 바이너리로 만들어 배포하려고 보니 아주 간단한 기능 조차도 파일이 너무 커지게 됩니다. (런타임도 같이 넣으니까요.)

    • 저는 Go 언어가 제공하는 단일 바이너리 파일 배포가 정말 마음에 들었습니다. 더 이상 주절 주절 설명할 필요가 없으니까요!


  • 고루틴은 날카로운 병렬 검입니다. 잘못 쓰면 손가락이 날라가겠지만, 잘만 사용하면 하드웨어의 한계를 쥐어 짤 수 있습니다.

    • 본문에서는 언급하지 않았지만, 고루틴을 이용하여 파일 업로드를 구현하니 업로드 속도가 획기적으로 개선되었습니다. 동시에 진행해도 괜찮고, 모두 한 번에 마칠 필요가 없는 작업에서는 감히 고루틴보다 더 쉽고 강력한 답은 없으리라 생각합니다.

    • 아직 TSBOARD 백엔드에서 고루틴을 제대로 활용하질 못했습니다. 성능 개선의 여지는 충분하고, 제가 더 배우고 익힐수록 하드웨어 자원을 더 효율적으로 활용할 수 있으리라 생각합니다.




사람마다 선호하는 언어가 다르고, 자신이 생각하는 정답이 다른 사람과 다를 수도 있습니다. 저는 다른 언어들 만큼 Go 언어도 좋아하게 되었고, 비록 기대했던 것만큼 비약적인 성능 향상은 없었지만 그럼에도 Go 언어의 여러 장점들이 마음에 들어서 좀 더 사용해 보려고 합니다. 그리고 부디 언젠가 성능 향상의 비급서를 찾을 그 날을 꿈꿔봅니다.


이 긴 글을 읽어주신 분들께 감사드립니다. 혹시 기회가 된다면, 여러분들께서는 Go 언어에 대한 이 글의 비교 결과를 어떻게 생각하시는지 의견도 나눠보고 싶습니다!




  • bun
  • elysia
  • golang
  • fiber
  • mysql
  • 백엔드
  • 재작성
  • gopher
  • tsboard

Go언어로의 전환이 순탄치 않습니다... 🤣

2024:11:28 00:27:47 / / written by 시리니

안녕하세요! TSBOARD 개발하고 있는 시리니입니다!


앞선 글에서 전환이 순조롭게 되고 있다고 작성했는데, 안타깝게도 지금은 그렇지 못한 상황입니다.

우선 관리자 화면쪽 빼고는 백엔드 재작성을 얼추 마무리해서, 중간 점검 차 성능 테스트를 진행하고 있는데…

생각지도 못하게 mysql 쪽에서 집중된 부하 상황 시 뻗어버리거나 혹은 응답이 지연되는 문제가 발견되었습니다.


전반적으로 Bun + mysql2 기반으로 작성했던 처음 버전의 백엔드는 기존대로 준수한 성능을 보여준 반면,

고루틴을 등에 업고 진정한 풀파워 백엔드로 기대를 했었던 Go + go-mysql-driver 조합은

예상보다 못한 저조한 성능(특히 집중된 부하 테스트 상황에서)을 보여주고 있습니다.


문제는 제가 진득하게 Go 언어를 배워서 지금 만드는 게 아니라, 만들면서 이 언어를 배워나가고 있어서

정확히 어떤 부분을 해결해야 하는지 알기 어렵다는 점입니다.


일단 의심되는 부분들이 있어서 하나씩 배워가면서 실험을 해보고 있는데, 해결을 완료하면

블로그를 통해서 내용을 정리하여 공유드릴 수 있도록 하겠습니다. 🥹


부디 이 삽질의 끝에 즐거운 아하 모멘트가 나타나길…!!!

  • golang
  • 백엔드
  • 성능
  • 테스트
  • 난관
  • 고민
  • 다행스럽게도 Go의 표준 라이브러리 기반으로 제가 구현한 라우터의 성능 이슈가 발견되어

    과감히 제거하고, Fiber v3을 사용하는 걸로 변경하였습니다.

    아울러 핸들러 부분의 코드를 이참에 좀 더 개선하여서 보다 나은 동작을 기대할 수 있게 되었습니다…!


    다만, 예상과 달리 MySQL(Mariadb)가 끼어드는 리얼 월드에서는 Go언어의 성능이 Bun 대비 우세하진 않았습니다.

    TSBOARD가 사용하는 여러 API들을 다양하게 테스트 해보면, 동등에서 약 열세라고 볼 수 있네요.

    Go가 CPU 사용량은 더 많고, 메모리는 Bun 대비 더 적게 사용하고 있습니다.


    아래 간단히 상대적으로 비교해 보겠습니다.

    (여기서도 비슷한 결과를 보실 수 있습니다: https://medium.com/deno-the-complete-reference/bun-vs-go-native-hello-world-performance-006791174df2)

    (Mac Studio M1 Max)

    Go (1.23.3)

    Bun (1.1.37)

    처리 속도 (높을수록 좋음)

    90%

    100%

    CPU 사용량 (낮을수록 좋음)

    300%

    100%

    메모리 사용량 (낮을수록 좋음)

    60%

    100%

    물론 절대적인 기준으로 한 건 아니고 어디까지나 TSBOARD에서 부하가 가장 많은 몇몇 라우터들 기준으로

    hey 라는 도구를 이용해서 조금 가혹하게 (-n 3000 -c 100) 진행한 것 입니다만, 이 정도로 테스트 해봤으면

    이제 어느 정도 감은 잡은 것 같습니다.


    예상외로 Bun과 Elysia, 그리고 mysql2의 조합이 정말 찰떡이었구나 하는 점을 느꼈고

    처음에 TSBOARD 프로젝트를 시작할 때 신중하게 골랐던 이 스택이 황금 스택이었음을 깨닫습니다.


    그래서… 아깝지만 Go 언어로 재작성한 백엔드를 여기서 포기하고 그냥 기존 스택을 유지하면서 개발할까?

    아니면 새로 재작성한 백엔드의 다른 장점들을 살려서 나아갈까? 하는 고민이 남았네요.

    처음에는 Bun으로 다시 돌아가려고 했는데 (Fiber v3 사용 전), 지금은 성능 측면에선 (제 기준) 10% 약 열세를

    감안하더라도 별도의 런타임에 의존하지 않는 것이나, 낮은 메모리 사용량, 추가 성능 향상의 여지가 보여서

    우선은 계속 진행해 나가고자 합니다.


    추후 블로그에 좀 더 상세한 테스트 내용을 공유드릴 수 있도록 하겠습니다…!

    이제 TSBOARD : GOAPI 백엔드 프로젝트는 아래의 과정이 남았습니다.


    1) 관리화면용 백엔드 재작성

    2) TSBOARD (재)설치용 백엔드 재작성

    3) 응답성 개선을 위한 추가 튜닝


    최대한 이번 달 안으로 Go언어로의 전환을 마무리 하겠습니다!

    2024:12:01 00:18:30 / / written by 시리니

백엔드를 Go언어로 순조롭게 교체하고 있습니다.

2024:11:04 23:24:33 / / written by 시리니

안녕하세요! 간만에 진행상황을 말씀드릴 겸 글을 남겨봅니다.


현재 TSBOARD v1.0.0-beta 공개를 앞두고 백엔드를 기존 Bun 런타임 기반(typescript 코드)에서 Go언어로 재작성하고 있습니다.

여러 고민들 끝에 Go언어를 선택했는데, typescript 언어랑 비슷한 면도 있고 해서 학습에는 큰 어려움이 없었습니다.

그리고 Go언어의 net/http 표준 라이브러리가 정말 잘되어 있어서, 별도의 외부 라이브러리는 쓰지 않고 Go 1.23 기준으로만 구현중입니다.


따로 크게 테스트를 해보진 않았습니다만, 제 개발 환경(M1 Max 맥스튜디오)에서는 확실히 백엔드의 빠른 응답이 느껴지고 있습니다.

이 정도의 성능 개선이라면 새로운 언어를 배우면서까지 백엔드를 재작성하는 보람이 느껴질 것 같습니다. 😆


좀 더 서둘러서 작업을 해도 될 것 같습니다만, 이왕 재작성 하는 김에 꼼꼼히 확인하고 더 좋은 개선 방향을 계속 고민해가면서

여러분들에게 좀 더 좋은 결과물을 선보일 수 있도록 노력하겠습니다.


진행상황은 아래 GitHub 커밋 로그를 통해 확인해 보실 수 있습니다!

https://github.com/sirini/goapi/commits/main/

  • tsboard
  • backend
  • typescript
  • bun
  • golang
  • 성능
  • 개선
  • 재작성
  • 화이팅 입니다🙌
    로그인 후에 1초 정도 로그인 창이 잠깐 보이고 메인 페이지로 넘어가는데, 혹시 의도하신 걸까요? 저는 잠시 버그인가 했는데, 혹시 다른 분들도 그렇게 느낄 수도 있을 것 같아서요😦

    2024:11:11 10:49:16 / / written by 바나나머스탱
  • 화이팅 감사합니다! (으쌰!)

    로그인 후에 약간 딜레이를 넣은 건 의도한 것인데, 원래는 “홍길동님 환영합니다!” 같은 메시지를 보여주고 이동하려고 한 것이었습니다.

    그런데 남겨주신 글을 보고 다시 로그인을 해보니 좀 어색하다는 느낌이 들기 시작했습니다…!

    이 부분은 로그인을 하면 바로 게시판 혹은 첫페이지로 가도록 하는 걸로 바꿔놓겠습니다!

    2024:11:11 18:56:35 / / written by 시리니

Go언어로 갑니다! (Goodbye, Bun!)

2024:10:22 00:31:24 / / written by 시리니

저는 10년 만에 웹 개발을 다시 시작하면서, 자바스크립트 생태계의 천지개벽에 적잖게 당황했고 또 놀랬습니다.


React는 세상을 점령한 것처럼 보였고, 백엔드에서는 Node와 Deno의 등장으로 정말 어디서나 자바스크립트를 볼 수 있게 된 세상이 신기했습니다. 비동기 I/O가 주는 장점들을 십분 발휘 하면서도 다른 성능들과 개발 편의성도 동시에 급진적으로 개선되는 게 경이로웠고, 열광적으로 빠져들었던 기억이 납니다. 특히나 Node에서 Bun으로 런타임을 교체하며 동시에 타입스크립트로의 도전은 보다 큰 규모의 프로젝트를 무리없이 구성할 수 있겠다는 자신감까지 심어줬습니다. TSBOARD 개발은 전적으로 이 새로워진 자바스크립트 생태계 덕분입니다.


그렇지만, 길다면 길고 짧다면 짧았던 저의 자바스크립트(혹은 타입스크립트) 백엔드 개발은 이제 곧 끝날 예정입니다. 저는 곧 Go언어로 백엔드를 완전히 재작성 할 예정이고, 다시 자바스크립트 생태계로 돌아오진 않을 겁니다. (토이 프로젝트나 시간이 정말 급박하다면 또 얘기가 다르겠지만요…! 😉)


나는 왜 JS/TS 런타임으로부터 떠나는가?

사실 지금의 TSBOARD를 만들 수 있게 해준 건 전적으로 타입스크립트와 JS/TS 런타임인 Bun 덕분입니다. 이 개발 스택을 선택한 건 지금도 후회하지 않고, 만약 처음으로 다시 돌아간다고 해도 저는 똑같은 선택을 할겁니다. 특히 Node의 부족한 성능을 정말 획기적으로 개선해준 Bun, 그리고 그런 Bun에 최적화된 웹 프레임워크를 제작해준 ElysiaJS팀에 감사한 마음을 가지고 있습니다.


그럼에도, 여전히 마음 한구석에는 결국 싱글 스레드의 한계와 비동기 I/O 구조에만 지나치게 의존하는 런타임의 성능이 못내 아쉬웠습니다. 물론 트래픽이 엄청나게 적은 이곳 같은 경우에는 전혀 문제 될 것이 없고, 아마 동시 접속자수가 30여명이 넘어간다 하더라도 크게 무리가 되진 않을 겁니다. Bun이라면… 어쩌면 그 이상 해낼 지도 모르구요.


그렇지만, 자바스크립트 런타임은 결국 자바스크립트를 처리하는 엔진의 구조나 성능에 크게 제약을 받게 됩니다. 구글 크롬의 V8 엔진이 아무리 괴물같은 최적화를 통해 미친 성능을 보여 준다고 하더라도, 결국은 나의 자바스크립트 코드를 인터프린팅 해줘야 합니다. Bun은 분명 Node보다 빠르고, Zig 언어를 이용해서 세부적으로 더 고성능의 동작이 가능하도록 API를 잘 다듬었지만, 어쨌든 JavaScriptCore에 의존합니다. 특정 케이스에서는 높은 성능을 보여줄 수 있지만, 전반적으로 컴파일 언어 대비 느릴 수 밖에 없습니다. 또한 아무리 비동기 I/O 방식이 백엔드로 쓰기에 효과적이라 해도 싱글 스레드로 동작하는 이상 성능 저하는 피할 수가 없습니다. (내 서버의 여러 CPU core들을 효과적으로 괴롭혀주지 못하는 것도 아쉽죠!)


무엇보다, TSBOARD와 같은 도구를 실제 사용자에게 배포하는 과정이 간단하지 않습니다. 일단 전달 받는 쪽은 Bun이든 Node든 미리 설치해 두어야 합니다. 그리고 사용에 필요한 라이브러리들을 npm 등의 패키지 매니저를 통해 따로 내려 받아야 합니다. 또한 라이브러리들의 크기가 상당히 크고, 혹시나 버전이 꼬일 경우에는 이걸 처리하는 것만으로도 난감해집니다. 서버 환경에 따라서 라이브러리를 다르게 받아야 할 수도 있구요.


저의 경우 Bun 런타임이 한동안 가상 CPU에서는 제대로 동작하지 않는 버그가 있어서 이 배포 과정이 정말 힘들었습니다. (다행히 지금은 고쳐졌습니다!) 저조차도 특정 환경에서는 TSBOARD를 사용하지 못해 대체 솔루션을 찾아야 했을 정도니 그 스트레스가 이루 말할 수 없었죠. 사실 이 점이 저에게는 가장 크게 다가온 현실적인 문제이기도 했습니다. 내가 만든 프로젝트를 내가 쓰고 싶은 곳에 못썼던 시간이 너무 길었기에 대책을 세워야만 했거든요.


왜 Go언어인가?

자바스크립트 런타임이 가지는 한계를 점점 명확히 인식하면서, 저는 대안을 고민했습니다. 가장 좋아 보였던 선택은 의외로 러스트(Rust) 언어 였습니다. 메모리 안정성부터 C++과 맞먹는 성능, 그리고 많은 개발자들이 사랑하는 언어라서 가장 먼저 고민을 했습니다. 그러나 웹 개발을 하면서 메모리 문제까지 고민하며 진행하기에는 제 내공도 부족하고, 회사에서 어차피 써야하는 C++만으로도 이미 충분히 괴로웠기 때문에 아쉽지만 제외했습니다.


다음으로 떠올린 대안들은 그누보드가 선택한 파이썬(Python)이었습니다. 하지만 파이썬 언어도 사실 만만치 않게 성능 관점에서 약점이 있다고 생각했고, 회사에서 업무용으로 써본 경험에 비춰보면 웹에서까지 쓰고 싶다는 생각은 들지 않았었습니다. 언어 자체가 강타입 언어도 아니고 배포 과정이 Node나 Bun에 비할 바는 아니겠지만 그래도 간단하지는 않은 것 같았습니다. (어쨌든 파이썬이나 필수 라이브러리들을 받긴 해야 하니까요)


마지막으로 고려한 건 코틀린(Kotlin)과 스프링의 조합이었습니다. 정부 표준 프레임워크에 빛나는 자바 생태계에 마음이 끌리지 않았다면 솔직히 거짓말이고, 잠깐이나마 코틀린을 배워본 경험에 의하면 언어 자체가 자바 대비 선녀처럼 보였기 때문에 쓰고 싶었습니다. 그러나 아무리 스프링 프레임워크 설정이 쉬워졌다고 하더라도 여전히 저에겐 개발 환경 셋업도 어려웠습니다. Gradle 같은 빌드 도구들에도 솔직히 좋은 기억이 없어서 사실 가장 적합한 대안이라 생각했지만 제외했습니다.


그리고 나서 문득, Go언어는 어떨까 싶어 이것 저것 기웃 거리면서 알아봤는데… 제가 원하는 것들이 대부분 포함되어 있었습니다! 어째서 이제서야 이 언어를 고려하게 되었나 하는 자책을 할 정도로 마음에 쏙 들었습니다.


  • Go언어는 강타입의 컴파일 언어입니다. 타입 안정성이야 두말 할 필요가 없습니다.

  • 컴파일이 정말 빠릅니다. 인터프린터 언어에 비할 바는 아니라도 정말 빨라서 개발 생산성이 높습니다.

  • 배포 과정이 깔끔합니다. 크로스 컴파일도 잘되고, 생성된 바이너리 파일 하나만 있으면 바로 실행됩니다.

  • GC를 지원합니다! 물론 매뉴얼로 메모리를 관리하는 것 대비 느려지는 시점이 간간히 있지만 그래도 감수할 만 합니다.

  • 언어 자체가 간결함을 지향해서 배우기가 쉽습니다. 덕분에 빠르게 적응할 수 있습니다.


배포할 때 바이너리 파일 하나만 있으면 되고, 메모리 관리를 직접 하지 않아도 되는데다 배우기 쉽고 타입스크립트 언어와 약간 유사한 면도 있습니다. 덕분에 적응하는데도 그리 오래 걸리지 않아서 결과적으로 대 만족입니다. 이 Go언어 자체가 제가 가지고 있는 요구사항을 딱 맞춰서 개발한 것 같은 느낌도 들었습니다.


물론 가장 강력한 장점이라 할 수 있는 고루틴(Goroutine)은 정말 백번 얘기해도 부족하지 않을 정도로 큰 장점입니다. 자바스크립트 런타임이 싱글 스레드의 제약에 묶여 있는 것이 내내 마음에 걸렸었기 때문에, 고루틴의 존재는 그 자체로 정말 반가웠습니다. 아무리 비동기 I/O 방식으로 동작한다고 해도 역시 여러 CPU 코어를 동시에 괴롭혀 줄 수 있다면 성능이 더 오를 수 있겠죠…!


TSBOARD 백엔드는 언제 Go언어로 완전히 전환되나?

현재 목표는 올해 12월 말까지 작업을 마무리하고, v1.0.0 배포 시점에 맞춰서 공표하는 것입니다. 아마 12월 전에는 마무리가 될 수 있을 것 같고, 전환한 이후에는 다시 Bun 런타임 기반의 코드로 돌아가진 않을 것 같습니다. 다만 제가 Go언어를 제대로 공부하고 난 후에 개발을 하는 게 아니라 배우면서 동시에 개발을 하는 상황인지라 테스트 및 성능 개선 부분에 좀 더 시간이 소요될 수는 있겠습니다.


Go언어로의 전환이 완료되면 기존 TSBOARD의 server 폴더쪽 코드는 모두 제거될 예정이고, goapi (github.com/sirini/goapi) 의 OS별로 컴파일된 바이너리 파일만 추가되어서 배포될 겁니다. 물론 TSBOARD 사용자 분들 중에서 직접 백엔드를 고쳐서 쓰고 싶은 분들을 위해 goapi 코드 역시 Github에 계속 공개할 예정입니다. 만약 커스텀을 고려중이라면 걱정하지 않으셔도 된다고 말씀드리고 싶습니다.


이만하면 되었다, 를 경계하며…

TSBOARD를 만들면서 늘 경계하고자 했던 것 하나가, 바로 ‘이만하면 되지 않았나?’ 하는 생각입니다. TSBOARD 백엔드를 지탱해주고 있는 Bun, 그리고 ElysiaJS는 정말 기대 이상으로 잘해주고 있지만, 더 큰 기대를 품기에는 한계가 있습니다. 그 한계를 정확히 인식하고, 뛰어넘을 수 있도록 계속해서 노력해야 한다고 생각합니다. 그 것이 결국 TSBOARD를 사용하는 저나 다른 분들에게 더 큰 만족으로 돌아올테니까요.


무사히 전환할 수 있도록 응원을 부탁드립니다!

  • tsboard
  • golang
  • bun
  • elysia
  • 백엔드
  • 전환
  • 조용히 응원하고 있습니다 저는 프로젝트에 영감을 받아 nextjs + nestjs + prisma로 연습해보고 있습니다. go로 서버를 만든다는건 아쉽지만 ㅠ 이것도 보면서 공부해보겠습니다

    긱뉴스에서 보고나서 응원하고 프로젝트입니다! 저두 이거에 반만이라도 만들면 좋겠네요. 이제 gots 보드인가요 ㅋㅋ

    2024:10:30 16:34:01 / / written by 바나나머스탱
  • 응원에 감사드립니다! 😆 바나나머스탱님께서 만드시는 것도 구경해보고 싶네요! ㅎㅎ

    이름을 바꿔야하나? 고민을 잠시 했지만 ㅎㅎ Type Safety 의 약자로 밀고 나가보려고 합니다. ㅎㅎㅎ

    2024:10:30 20:28:57 / / written by 시리니

TSBOARD v0.9.9 업데이트 및 개발 로드맵 변경사항 안내 [중요!]

2024:10:19 23:41:45 / / written by 시리니

안녕하세요! TSBOARD 개발하고 있는 시리니입니다.


열심히 v1.0.0을 향해 나아가고 있는 와중에, 중간 업데이트로 v0.9.9를 소개드립니다.

아래와 같은 사항들이 반영되었습니다.


  • 본문을 클립보드에 복사하기

    • 로그인 한 사용자는 게시글 보기 화면 우측 하단에 “작업” 부분을 클릭 하시면 본문을 클립보드에 복사할 수 있는 버튼이 활성화 됩니다. 클릭하시면 본문 내용을 간편하게 복사 하실 수 있습니다.

  • 게시글 작성 시 HTML 입력하기 기능 추가

    • 위의 클립보드에 복사한 본문은 기본적으로 HTML 태그가 반영되어 있습니다. 그래서 그냥 에디터에 붙이시면 태그가 제대로 적용되지 않으므로, 글 작성란 좌측 하단에 HTML 버튼을 클릭하여 붙여 넣고자 하는 내용을 넣으신 후 APPLY 버튼을 클릭하시면 에디터 화면에서도 HTML 태그가 적용된 상태로 보실 수 있습니다.

  • home.color.header 값 변경으로 대부분의 색상값들이 변경될 수 있도록 수정

  • 새로 TSBOARD를 설치할 때 .env 파일에 GOAPI용 변수 미리 추가

    • 아래 내용처럼 지금 운영하는 TSBOARD에 수동으로 추가하실 수 있습니다.

    • GOAPI_VERSION=1.0.0

    • GOAPI_PORT=3003

  • 게시글 목록 가져오기 시 로딩 효과 추가, 처음 페이지 로드 시 게시판 폭이 너무 작게 나오는 문제 수정


그리고, 중요한(?) 개발 로드맵 변경사항을 안내드립니다.


  1. TSBOARD v1.0.0부터는 백엔드를 더 이상 Bun 런타임에 의지하지 않습니다. 대신, Go언어로 작성된 새로운 백엔드 바이너리 파일이 포함되어 배포됩니다. 새로운 백엔드 바이너리 파일들은 운영하시는 OS 버전에 맞춰 사전 빌드된 후 함께 전달되며, 수정을 원하시는 경우 GOAPI 리포지토리를 통해 코드를 내려 받으셔서 작업 하실 수 있습니다.

  2. TSBOARD 쇼핑몰 모듈은 v1.1.0 공개 때 소개 예정입니다. ‘25년 5월 중으로 공개하고자 하며, 그 전까지 게시판/갤러리 및 블로그 모듈의 기능 개선 및 안정화에 더 노력 하겠습니다.

  3. Client Side Rendering 방식 및 프론트엔드 쪽 스택은 변경사항이 없을 예정입니다. (검색 엔진을 위한 sitemap.xml 및 최신 글보기 기능 유지)


TSBOARD는 Bun 런타임과 ElysiaJS 웹프레임워크 기반의 커뮤니티 빌더입니다. (현재까지)

Bun 런타임 덕분에 타입스크립트를 프론트엔드에서 백엔드에 이르기까지 두루 사용할 수 있었고, 성능 측면에서도 크게 아쉬움없이 타입 안정성을 유지하면서 개발을 해 나갈 수 있었습니다. GeekNews에 소개한 후로 많은 분들의 관심을 받았었는데, 감사하게 생각하고 있습니다. 😉


제가 선택한 스택들에 대해서는 후회하지 않습니다. 만약 다시 선택한다 하더라도 똑같은 선택을 했을듯 합니다.

그러나, 아래의 몇가지 이유들로 인해 백엔드를 Go언어로 재작성하고자 합니다.


  1. Bun 런타임은 한동안 가상 서버 CPU에서 제대로 동작하지 못했습니다. 이제는 해결되어서 무리없이 동작하고 있습니다만, 이 문제는 한동안 저를 괴롭혔습니다. 아마도 이 문제가 처음부터 없었더라면, 백엔드를 재작성하겠다는 무시무시한 결정을 하진 못했을 겁니다.

  2. Node 혹은 Deno 기반으로 가는 것도 고려 했습니다만, Bun만큼의 성능이 나오지 않아 제외하였습니다. TSBOARD를 만들면서 가장 중요하게 생각했던 건 서버 쪽 리소스를 최대한 효율적으로 사용하면서도 고성능을 유지하는 것입니다. 국내 중소 규모의 커뮤니티 사이트에서도 무리 없이 트래픽을 감당할 수 있어야 하고, 더 빠른 피드백을 제공할 수 있도록 하기 위해 더 이상 자바스크립트/타입스크립트 런타임에는 의존하지 않기로 하였습니다.

  3. 그누보드가 선택한 파이썬부터 Rust, Go 등의 언어를 검토했고, 개발 생산성과 성능 등의 관점에서 최종적으로 Go언어를 선택하고 현재 초기 구조를 잡고 있는 상태입니다. 물론 이제는 좀 익숙해진 자바스크립트 기반으로 개발하는 것에 비할 바는 아니지만, 그럼에도 Go언어만의 간결함과 높은 개발 생산성, 그리고 크로스 컴파일러가 선택의 이유입니다.


Bun 런타임이 가지고 있던 고질적인 문제(가상 CPU에서의 버그)가 해결된 마당에, 굳이 백엔드를 바꿔야 할까 많이 고민했습니다. 사실 지금도 성능 측면에서는 꽤나 만족하고 있으니까요. 그러나, 더 개선할 여지가 분명히 있고 백엔드쪽 성능을 한단계 높이고 싶은 마음도 분명히 있기 때문에 일단 실행에 옮기기로 하였습니다. (이래놓고 후회하는 건 아닌가 모르겠군요)


계획대로 진행된다면 12월 말에 선보일 수 있을 것 같습니다.

아무쪼록 잘 진행할 수 있게 응원 부탁드립니다… 🥹


백엔드 교체와 관련한 보다 상세한 내용은 추후 블로그를 통해서 소개 하겠습니다!

  • tsboard
  • 업데이트
  • goapi
  • 백엔드
  • 재작성
  • golang
  • bun

TSBOARD v0.9.8 업데이트 안내!

2024:10:12 22:19:33 / / written by 시리니

안녕하세요! TSBOARD 개발자 시리니입니다.


v0.9.8 업데이트가 완료되어 아래에 변경사항들을 정리해서 소개 드립니다!


  • 에디터 툴바 기능 개선

    • 이제 글자 색상 변경 시 color picker를 이용하여 보다 자유롭게 색상을 바꾸실 수 있습니다. 말 그대로 색상 추출기이므로, 화면 내 어떤 곳이든 원하는 부분의 색상을 찍어서 글자색으로 사용 하실 수 있습니다.

    • 코드들도 연관된 부분들끼리 좀 더 모아서 별도 하위 컴포넌트로 옮겨두었습니다. 수정이 필요할 때 보다 편하게 원하는 부분을 찾아서 고치실 수 있습니다.

  • 관리화면 대시보드 그래프

    • 첫 화면에서 그동안 숫자로만 주요 지표를 보여드렸었는데, 최근 일주일간의 변동사항을 간단한 그래프로도 보실 수 있도록 변경 하였습니다. 커뮤니티 사이트라면 민감하실 방문자 수 추이나 게시글/댓글의 변동사항등을 보실 수 있습니다.

    • 추후 보다 긴 기간 동안의 변화를 시각적으로 확인 하실 수 있도록 할 예정이며, 관련해서 백엔드 쪽 코드 리팩토링을 진행 하였습니다.

  • 본문 내 이미지 업로드 기능 개선

    • 본문 내 이미지 삽입 시 가끔 게시판 번호가 제대로 기입되지 않아 업로드 한 이미지 목록에 나타나지 않거나, 혹은 업로드가 완료되지 않은 상태에서 이미지가 추가되어 이전에 업로드한 이미지가 본문에 삽입되던 문제가 있었는데 이를 수정하였습니다.

    • 본문에 삽입되는 이미지의 리사이즈 크기가 가로 기준으로 기존 480px 대비 640px으로 소폭 커졌습니다. (tsboard.config.ts에서 언제든지 수정 가능합니다. 아울러 갤러리에 업로드하는 이미지의 최대 크기도 2016px에서 2400px으로 좀 더 커졌습니다.)

  • 글보기 화면에서 다른 게시글로 이동 시 댓글 목록이 새로고침 되지 않는 문제 수정

    • 게시글을 이동하면 현재 위치와 무관하게 항상 최상단으로 스크롤을 이동하도록 수정하였습니다.

  • vite.config.ts에서 chunkSizeWarningLimit 값 추가

    • npm run build 작업 시 Warning 메시지 제거


TSBOARD는 서버의 부담을 최소한으로 하면서, 사용자에게는 풍부한 사용 경험을 제공하는 목적으로 설계되었습니다.

혹시 사용을 고려중이시라면, 테스트를 해보시고 궁금하신 점이나 개선 필요한 점들은 언제든지 이곳 사이트에서 의견 남겨주세요!


  • tsboard
  • 업데이트

멕시코 칸쿤 : 하얏트 지바 리조트

2024:10:05 20:28:46 / / written by 시리니

신혼여행에서 뉴욕을 거쳐 멕시코 칸쿤으로 향했었는데, 칸쿤에서의 첫번째 리조트가 바로 하얏트 지바 칸쿤이었습니다. 쏟아지는 햇살과 아름다운 바다, 그리고 풍족한 먹을 거리가 모두 만족스러웠고 기억에 많이 남네요. ㅎㅎㅎ (또 가고 싶어요오오~)

  • 멕시코
  • 칸쿤
  • 하얏트
  • 지바
  • 리조트
  • 신혼여행
  • 사진들을 보다보니 문득 또 가서 따사로운 햇살을 만끽해보고 싶다는 생각이 듭니다. ㅎㅎ
    2024:12:29 13:54:40 / / written by 시리니

신혼여행을 다녀와서 : 천국은 멀리 있었다 (멕시코 칸쿤)

2024:10:05 20:18:28 / / written by 시리니

8월 31일 인생에서 가장 큰 이벤트라 할 수 있는 결혼식을 마치고, 9월 2일에 뉴욕으로 향했습니다.

뉴욕에서의 5일도 정말 너무나 좋았었는데, 언젠가 한 번 이야기를 해볼 수 있으리라 생각하고, 오늘은 칸쿤에 대해서 짧게 남겨보고자 합니다.


천국은 멀리 있다 : 18시간의 비행

멕시코 칸쿤은 한 10년 전부터도 신혼여행의 성지로 불렸던 곳이라고 합니다.

혹자는 아무리 칸쿤이 좋아봤자, 몰디브에 비할 바는 아니라고 하시기도 하는데, 글쎄요… 둘 다 가보진 못했지만 저는 칸쿤이야말로 감히 신혼여행의 성지라 할만하다고 주장하고 싶습니다. 가히 천국이라 칭해도 부족하지 않은데, 딱 2가지의 문제만 있었습니다. 바로 가는데 걸리는 시간과 돈입니다.


칸쿤은 이 곳 대한민국에서 바로 간다고 하더라도 한 16시간 정도는 걸릴 것 같은데 (최근에 직항이 생겼다고 합니다), 뉴욕을 거쳐서 가게 되면 뉴욕까지 14시간, 다시 뉴욕에서 칸쿤까지 4시간 더 걸려서 최소 18시간이 소요됩니다. 하루가 24시간이니까, 사실 수속하고 이것저것 하다보면 하루를 그냥 비행기에서 보내는 셈입니다. 정말 멀어도 너무 멀다 싶긴 한데, 막상 칸쿤에 도착하고나서 리조트에 짐을 풀고 있노라면 멕시코 만과 카리브 해의 중간에서 맛보는 바다의 풍경이 일품이었습니다.


저는 이번 신혼여행에서 처음으로 10시간이 넘는 장거리 노선을 타보았습니다. 한 6~7년 전에 중국에서 잠깐 살때도 중국 내에서 이동하는데 4시간 정도 걸렸던 게 가장 긴 노선이었는데, 이제서야 미국과 칸쿤을 가게 되면서 장거리를 제대로 경험해 본 셈입니다. 혹자는 그래도 신혼여행이니까 비즈니스 정도는 타지 않았을까 지레 짐작하셨을 수도 있겠지만, 이코노미를 타고서 왕복으로 다녀왔기 때문에 조금 힘들긴 했습니다. 중간 중간에 일어나서 스트레칭도 하고 별 걸 다했는데, 그나마 제가 미리 출발하기 전에 네이버 시리즈나 카카오 페이지에서 볼만한 작품을 완결까지 모두 구매해놓고 출발해서 지루하진 않았던 것 같습니다. 만약 다음에도 장거리 노선을 타야 할 일이 생긴다면 똑같이 준비해서 심심하지 않게 할 생각입니다.


올 인클루시브 매직 : 그래도 팁은 준비해 두세요

칸쿤 리조트들은 대부분 올 인클루시브(All Inclusive)입니다. 즉 호텔 리조트 비용 안에 각종 부대비용들(레스토랑, 카페, 스낵, 아이스크림 등)이 모두 포함되어 있습니다. 따라서 현장에서는 따로 돈을 지불하실 게 사실 거의 없다고 보셔도 됩니다. 여기서 “거의” 없다고 표현한 건, 그래도 리조트마다 추가적인 비용을 지불해야만 이용할 수 있는 게 조금씩은 있기 때문입니다.


저희는 하얏트 지바 칸쿤에서 한 4일 정도 머물렀고, 이어서 스칼렛 아르떼로 이동하여 한 3일 정도 머물렀습니다. 둘 다 모두 훌륭한 곳으로 서로의 장단점이 있는데, 가격 차이가 한 2배 가까이 나는 만큼 스칼렛 아르떼의 시설이나 액티비티 등이 훨씬 가치 있었다고 말씀드릴 수 있겠습니다. 만약 다시 골라야 한다면 여전히 고민은 되겠지만, 아마 좀 무리를 해서라도 스칼렛 아르떼를 선택하지 않을까 싶습니다. 하긴 한국에서도 1박에 100만원이 넘는 곳에 숙박을 한다고 하면 그정도 만족감은 당연히 느껴야 하는 거겠죠? ㅎㅎ


하얏트 지바와 스칼렛 아르떼 모두 훌륭한 서비스를 보여줍니다만, 서비스의 질 자체는 하얏트 지바가 좀 더 좋았습니다. 직원들의 친절함이야 물론 말할 것도 없고, 서비스들도 나쁘지 않았습니다. 스칼렛 아르떼 역시 마찬가지로 친절하고 좋았지만 브랜드 호텔이 보여주는 그런 수준은 아니었던 것 같습니다. 반면 시설 같은 경우에는 지바가 좀 더 오래된 느낌도 있고, 숙박 시설 내부의 컨디션도 스칼렛 아르떼 대비 조금 떨어지는 건 어쩔 수 없었던 것 같습니다.


올 인클루시브는 무언가를 먹고 마시는데 있어 아무것도 신경쓰지 않게 해주니까 정말 좋았습니다. 다음에도 휴양 개념의 여행을 가게 된다면 올 인클루시브를 먼저 살펴보게 될 듯 합니다. 아, 그래도 혹시 모르니 미국 달러로 된 팁은 챙겨가시는 걸 추천드립니다. 여행사에서 제시하는 수준의 팁 까지는 줄 필요가 없어 보였습니다만(계속 관찰해봐도 팁을 주는 외국인들은 한 50% 정도입니다), 방 청소를 해주시는 분께 남기는 2달러 정도의 팁이나, 레스토랑에서 저희 테이블을 담당해준 서버에게 전해주는 2달러 정도의 팁은 괜찮아 보였습니다.


팁을 안준다고 해서 서비스가 형편없어 진다거나 하진 않았고, 팁을 받는 종업원들도 팁이 필수는 아니라고 이야기 해줬습니다. 그럼에도 무언가 메뉴를 전달 받거나 음료수를 주문해서 받았을 때 서로 기분 좋게 최소한 1달러씩 주는 건 나쁘지 않아 보였습니다. 개인적으로는 팁을 주는 문화권에 여행 간 것이 이번이 처음이어서 처음에는 조금 어색했는데, 그래도 와이프 따라서 몇 번 주다보니까 익숙해진 느낌입니다. 그럼에도 한국에는 팁 문화가 들어오지 않았으면 하는 생각도 들었습니다. ㅎㅎ


폭력적인 적도 태양 : 자외선 차단은 필수

칸쿤의 하루는 태양이 어느 정도 떠올랐는가에 따라서 갈립니다. 9월 초 칸쿤은 오전 11시부터 오후 3시까지는 야외에서 생활하는 것이 굉장히 힘들 정도로 태양이 뜨거웠습니다. 저는 적도 태양의 폭력적인 자외선이 얼마나 대단한지 미처 알지 못한 채로 딱 하루 동안 하루 종일 야외 수영장에서 튜브를 잡고 헤엄치며 놀다가 돌아다니다가 했었는데, 그 하루만에 노출된 팔이 모두 시커멓게 변해버리면서 따갑고 후끈거리게 되었습니다. 레쉬가드를 입었어야 했는데 그날 하루 안입었다고 이렇게 타버리나 싶기도 했고 여러모로 놀랬습니다.


리조트 직원분들은 애초에 전신을 꽁꽁 싸매고 근무하고 계셨었는데, 처음에는 날도 더운데 왜 저렇게 있지? 했지만 적도 태양의 폭력적인 뜨거움 앞에 고개를 끄덕일 수 밖에 없었습니다. 혹시 칸쿤으로 여행을 가신다면 레쉬가드 긴팔로 꼭 챙기시고, 자외선 차단을 위해서 썬크림은 자주 바르시기 바랍니다. 선글라스도 무조건 챙기셔야 합니다. 한낮의 태양빛도 무시무시한데, 물살에 반사되는 햇볕들도 눈을 때립니다.


한국 신혼부부들의 정모 장소 : 한국인듯 한국 아닌 한국 같은 칸쿤

우리나라의 혼인율과 출산율 감소는 이미 세계적으로도 잘 알려져 있는 심각한 문제입니다. 뉴스에서도 학계에서도 우리나라가 이대로만 가면 곧 소멸할 거라고 예측하고 있고, 실제로도 회사마다 20대 직원 비율이 현저히 낮아지는 등 문제가 속속 발견되고 있습니다. 그럼에도 칸쿤을 가보면, 그 귀한 신혼부부들을 심심치 않게 만나 보실 수 있습니다. 농담이 아니라 정말 많은 한국인 신혼부부들이 칸쿤 리조트에서 휴양을 만끽하고 있습니다. 그냥 리조트 어디를 걸어 가더라도, 수영장 어디를 가더라도 한국인 신혼부부들을 만나보실 수 있습니다. 정말 국민 신혼여행지라고 보셔도 됩니다.


처음에 뉴욕을 거쳐 멕시코 칸쿤으로 갈 때만 하더라도, 저에게 있어 멕시코라는 나라를 표현하는 단어들은 마약, 카르텔, 나르코스와 같은 다소 무섭고 부정적인 것이었습니다. 그러나 실제로 만나 본 칸쿤은 정말 지상낙원이라는 표현이 부족할 정도로 멋진 곳이었고, 리조트 시설이나 직원들의 친절함도 좋았습니다. 그리고 무엇보다, 젊은 한국인들이 정말 많았습니다! 뭔가 궁금하거나 모르는 게 생기면 근처에 지나가는 한국인 신혼부부 관광객에게 한국말로 그냥 물어봐도 될 정도입니다. 약간 외국이라는 느낌이 조금 덜해지는 아쉬움은 있지만, 반대로 이렇게나 많은 한국인 관광객들에게 선택받은 만큼 안전하겠구나 하는 생각도 들어서 조금 안심이 되었습니다.


언제 또 다시 가볼까… 또 가고 싶은 칸쿤

회사 동료분들 중에 한 분은 칸쿤이 너무 좋아서 결혼 후에 아이와 함께 다시 칸쿤을 찾았었다고 말씀해 주셨었는데, 그 마음을 이제는 좀 알 것 같습니다. 칸쿤이라는 곳이 주는 휴양의 느낌, 그리고 아름다운 바다의 모습과 여유롭게 휴양을 즐기는 사람들의 즐거움이 오래도록 기억에 남습니다. 만약 기회가 된다면 또 한 번 가보고 싶고, 좀 길게 휴양지를 즐겨보고 싶다는 생각이 듭니다. 전세계 어디서든 노트북 하나만 있으면 언제든지 일을 할 수 있다고 하는데, 칸쿤 리조트에서 카리브 해를 바라보며 TSBOARD 개발하면 어떨까 하는 상상도 해보았습니다. ㅎㅎ

  • 신혼여행
  • 칸쿤
  • 멕시코
  • 후기
  • 천국
  • 카리브해
  • 하얏트
  • 지바
  • 스칼렛
  • 아르떼

TSBOARD v0.9.7 업데이트 안내!

2024:10:02 22:50:55 / / written by 시리니

안녕하세요! 지난 글에서 말씀드린대로, v0.9.7 업데이트 소식을 가지고 왔습니다.

TSBOARD GitHub 페이지를 통해서 전체 코드를 내려 받으실 수 있고, Bun 런타임이 동작하는 서버에서 곧바로 사용 가능합니다!


아래 변경사항들이 이번 업데이트에서 반영 되었습니다.


  • 게시판 및 갤러리 부분 디자인 개편

    • 게시판과 갤러리 모두 이제 보시는 것 처럼 배경색이 들어갑니다. 전체적으로 메뉴, 버튼 등의 크기가 조금 더 작아졌고, 글작성 버튼 등 해당 페이지에서 핵심적인 역할을 해주는 버튼색은 메인 컬러로 더 강조되었습니다.

    • 라운딩이 살짝 들어간 박스 디자인들을 좀 더 활용하면서 전반적으로 좀 더 부드러워 보이면서도 단단한 형태로 디자인을 수정해 보았습니다.

    • 갤러리 뷰어의 경우 그 동안 모바일에서만 다크 모드였는데, 이제는 그 외 디바이스에서도 다크 모드로 볼 수 있도록 변경 하였습니다. 이를 통해 메인 컨텐츠인 사진에 좀 더 집중할 수 있도록 하였습니다.

  • 글보기 하단에 작성자의 이전 (댓)글 목록 보여주기 추가

    • 글보기 시 작성자가 이전에 남긴 게시글과 댓글을 볼 수 있도록 하였습니다. 이를 통해 작성자의 다른 글들을 보다 빠르게 확인 할 수 있고, 사이트 입장에서는 더 많은 트래픽을 유도할 수 있습니다.

  • 글보기 내비게이션 추가

    • 글보기 시 우측 중앙 부분에 미니 내비게이션 버튼들을 배치하여 상/하단으로 스크롤하기 및 이전글/다음글로 바로 이동할 수 있도록 하였습니다. 목록보기로 가지 않더라도 앞/뒤의 글들을 빠르게 탐색할 수 있습니다.

  • 에디터 툴바 위치 버그 수정

    • 에디터 툴바의 경우 스크롤 위치에 따라서 페이지 상단에 플로팅 되거나 고정이 되는데, 이 동작이 매끄럽게 동작하지 못했었습니다. 스크롤 위치가 조금만 내려가도 툴바가 떨어져 나와서 올라가버리는 문제가 있었는데, 이번 업데이트에서 문제가 수정되었습니다.

  • 알림 메시지 버그 수정

    • 알림 메시지를 클릭할 때 해당 게시글로 제대로 이동되지 않던 문제를 수정하였습니다. 다른 분들이 댓글을 남겨주거나 좋아요를 눌러주셨을때 이제 정확하게 해당 게시글을 찾아서 보여드립니다.

  • 관리화면에서 최근 (댓)글 열람 시 선택 삭제 기능 추가

    • 가끔 관리화면에서 여러 개의 연속된 게시글이나 댓글들을 선택하여 삭제할 필요가 있는데, 이번 버전부터 해당 기능을 지원합니다. 전체 선택을 통해 화면에 보여지는 게시글이나 댓글들을 한 번에 선택하여 삭제하실 수도 있습니다.

    • 참고로, TSBOARD에서 삭제 작업은 다음과 같습니다: 게시글은 상태값만 변경(데이터는 유지), 첨부파일은 실제로 삭제

  • 위 내용 이외에도 자잘한 버그들 수정


전반적으로 상당히 많은 버그들을 수정 하면서, 디자인 부분도 크고 작은 변경점들이 반영 되었습니다.

아직 v1.0.0 달성까지 가야 할 길이 멀긴 합니다만, 내년에는 v1.0.0 출시 소식을 전해드릴 수 있도록 계속 틈틈히 작업해 나가겠습니다…!


감사합니다!

  • tsboard
  • 업데이트
  • 디자인
  • 변경
  • v0.9.8 버전이 GitHub를 통해서 공개되었습니다…! 자세한 변경점은 주말에 마무리 작업 하고 공유드릴께요!

    2024:10:10 00:12:33 / / written by 시리니

v0.9.7 작업 시작했습니다

2024:09:29 22:10:42 / / written by 시리니

안녕하세요, 꿈같은 신혼여행을 마치고 이제 현실 세계에 적응중인 시리니입니다!


TSBOARD는 약 한 달 동안 업데이트가 잠시 멈췄다가, 이제 다시 업데이트 작업을 재개하였습니다.

저 스스로도 개밥먹기를 하면서 불편사항들을 하나씩 체크해놓고 있는데, 이번 업데이트에서는 진짜 답답해서 빨리 고쳐야겠다 싶은 항목들을 우선적으로 수정 작업중입니다…!


작업은 차주 징검다리 연휴 기간 동안 진행될 예정이며, 다음 주말 정도에 업데이트를 선보일 수 있을 것 같습니다.

더 많은 분들에게 TSBOARD가 도움이 될 수 있도록 더 노력하겠습니다!

  • 업데이트
  • 작업중
  • 신혼여행
  • 복귀

만약 TSBOARD 런타임을 더 고성능으로 만들어본다면?

2024:08:17 23:37:12 / / written by 시리니

요즘 문득 드는 (쓸데없는) 고민이 하나 있는데, 바로 고성능 백엔드 입니다.


물론 지금 신세지고 있는 Bun 런타임의 성능이 낮다거나 한 건 아닙니다. 지금 보여주는 퍼포먼스는 Node.js 와 비교하기에는 미안할 정도로 우수하고, 지금 이 순간에도 계속해서 업데이트 되면서 호환성과 속도를 계속 개선해 나가고 있습니다. 하지만, 특정 규모를 넘어서는 시점에서는 Bun이 아닌 다른 백엔드나 혹은 다른 구조가 요구될 수도 있습니다.


즉 미래 어느 시점에 백엔드를 좀 더 고사양으로 교체하거나, 혹은 고사양 백엔드 옵션을 제공할 필요가 생길 수도 있습니다. 즉 일반적인 상황에서는 TSBOARD가 제공하는 Bun 런타임 기반의 백엔드를 그대로 쓰고, 좀 더 고성능의 백엔드가 요구될 때는 별도의 프로젝트에서 제공되는 고성능 백엔드를 실행시켜서 응답 속도를 더 높이고 더 많은 요청을 처리하는 것입니다.


사실 이 고민은 어떻게 보면 저에게는 굉장히 쓸모 없으면서도 쓸모가 있습니다. TSBOARD 공홈이나 제가 따로 운영하는 사이트들은 그렇게 많은 트래픽을 감당할 필요가 없습니다. 즉 지금 사용하고 있는 Bun 런타임이 아니라 사실 Node.js 런타임이라 하더라도 크게 문제 되지는 않을 것입니다. 하지만 반대로 고성능 백엔드를 TSBOARD가 옵션이든 기본이든 제공할 수 있다면, TSBOARD 도입을 고려하는 분들에게 선택을 좀 더 쉽게 만들어드릴 수 있을 것입니다. 물론 고성능 백엔드를 구성할 수 있다면 저 역시도 배울 점이 많을테니 공부가 되겠죠.


추가적으로, Bun 런타임의 태생적 한계인지는 모르겠으나 가상 CPU에서는 제대로 동작하지 않는 문제고성능 백엔드 바이너리를 통해서 해결할 수 도 있습니다. Bun을 쓰지 못하더라도 다른 옵션이 있는 셈이니 사용자에게는 여러모로 이득이긴 합니다. (사실 저도 이 문제가 마음에 계속 걸려서 백엔드를 어떻게 할까 고민하기 시작했습니다)


고성능 백엔드, 한다면 어떤 언어로?


저에게는 고성능 하면 떠오르는 불멸의 언어 하나가 있습니다. 바로 (Modern) C++ 입니다. 물론 Rust, Zig 등의 언어도 있고 실제로 Bun 런타임의 경우 Zig 언어로 개발되었으니 고려해봄직 합니다. 그러나 여러 대안이 존재함에도, 백악관에서 쓰지 말라고 함에도 불구하고 고성능이 요구되는 프로젝트에서 C++을 빼놓고 생각하긴 어렵습니다. Rust 언어는 써볼려고 잠깐 학습하긴 했습니다만, 뭔가 손이 잘 가지 않습니다. 선생님같은 컴파일러 덕분에 무엇이 문제인지 친절히 배울 수 있다는 점은 좋았습니다만, 이걸로 당장 개발을 시작하기에는 스트레스가 더 많아질 것 같아서 아직은 엄두가 안납니다.


여러 고민들을 해보다가, 문득 Go 언어로 하면 어떨까? 하는 생각이 미쳐서 여러 사례들을 봤는데… 딱 제가 생각하는 고성능 백엔드에 적합한 개발 언어라는 생각이 들었습니다. 똑똑한 GC 덕분에 메모리 걱정을 좀 내려놓아도 되고, 문법도 크게 어렵지 않은데 컴파일도 빠르고 실행도 그만하면 빠르다는 생각이 들었습니다. 타입스크립트로 작성한 백엔드 보다는 개발 속도가 좀 늦어지겠지만, C++로 작성하는 것 보다는 훨씬 빠르게 만들 수 있지 않을까? 하는 막연한 확신(?!)도 들구요. ㅎㅎ


아직 TSBOARD가 v1.0.0 달성도 하지 못한 상태에서 백엔드를 하나 더 만드는 게 가당치도 않은 소리입니다만, 언젠가 백엔드를 필요에 따라서 교체해서 쓸 수 있는 이 아이디어를 구현할 수 있는 날이 왔으면 좋겠습니다. 이참에 저도 Go 언어와 친해져서 이것 저것 재미난 것들 만들어보고 싶네요.


  • 고성능
  • 백엔드
  • tsboard
  • bun
  • 런타임
  • 타입스크립트
  • golang
  • rust
  • zig
  • cpp

TSBOARD v0.9.6 업데이트 안내

2024:08:17 22:58:16 / / written by 시리니

안녕하세요! TSBOARD 개발자입니다.


간만에 업데이트 소식을 전해 드립니다. (사실 이번달에 제가 결혼을 앞두고 있어서 업데이트가 좀 늦어졌습니다…😅)


  • 모바일에서 이제 게시글 목록을 좀 더 시인성 있게 볼 수 있습니다.

  • 게시글 보기에서 긴 제목이 잘려서 출력되는 문제를 수정하였습니다.

  • 관리화면에서 특수문자가 제대로 출력되지 않던 문제를 수정하였습니다.

  • 관리화면에서 그룹 ID 변경이 가능하도록 기능 추가되었습니다.

    • 그룹 ID는 기본적으로 좌측 사이드 메뉴에 표시됩니다.

    • 따라서 이름이 마음에 들지 않을 경우 이번 업데이트를 통해서 손쉽게 바꾸실 수 있습니다.

  • 게시글 이동하기 기능을 추가하였습니다.

    • 아직은 게시판 글보기에서만 제공됩니다.

    • 글보기 화면에서 기존에 “수정” , “삭제” 버튼이 있던 곳이 이제 “작업” 이라는 이름의 버튼으로 통합되었고, 해당 버튼의 드롭다운 메뉴에 “글 이동하기” 기능을 사용 하실 수 있습니다.

  • TSBOARD가 의존하고 있는 여러 패키지들(vuetify, vue, tiptap, …)의 업데이트 작업을 반영하였습니다.


TSBOARD는 타입스크립트로 작성된 풀스택 오픈소스 게시판이자 커뮤니티 빌더입니다.

현재 게시판, 갤러리에 이어서 블로그까지 구현되어 있고 제 목표는 쇼핑몰 기능도 통합하는 것입니다.


새로운 게시판이자 커뮤니티 빌더가 필요하신 모든 분들께 도움이 될 수 있도록 더욱 정진하겠습니다!


감사합니다.

  • tsboard
  • 업데이트

79주년 광복절 기념

2024:08:14 22:53:17 / / written by 시리니

광복절입니다.


요즘은 언론에서 가끔 건국절이니 뭐니 말도 안되는 소리를 가끔 하는 것 같은데

제대로 배우고 역사를 기억하는 사람들은 모두 무엇이 진실인지 알고 있으리라 생각합니다.


과거는 그저 묻어두는 게 아니라 기억하고, 그로부터 교훈을 얻어서 앞으로 나아가기 위해 존재합니다.

왜곡한다고 해서 역사적 사실이 바뀌지 않고, 폄하한다고 해서 그 가치가 훼손되지 않을 것입니다.

기억하고, 선조들의 정신을 마음에 새기는 하루를 보내면 좋겠습니다.

  • 광복절
  • 79주년
  • 역사
  • 진실

사진 업로드 시험중입니다

2024:07:24 17:09:11 / / written by 시리니

이 곳 갤러리는 주로 테스트 할 때만 사용하는 것 같네요. ㅎㅎ

사진은 모두 unsplash 에서 퍼온 사진들입니다.

  • 갤러리
  • 테스트
  • unsplash

TSBOARD v0.9.4 업데이트 안내

2024:07:19 01:05:01 / / written by 시리니

안녕하세요! TSBOARD 개발하고 있는 시리니입니다.


이번에도 간만에 업데이트 소식을 전해 드립니다.

지난 번 v0.9.2 업데이트 이후 v0.9.3 업데이트 내용을 아래와 같이 댓글로 추가했었는데요,


  • TSBOARD.PREFIX가 이제 제대로 적용되도록 이미지 출력하는 코드 중심으로 모두 수정이 되었습니다. 만약 TSBOARD가 https://example.com/tsboard 경로에 설치되었다고 가정하면, TSBOARD.PREFIX 값을 /tsboard 로 설정할 경우 이미지나 리소스들이 정상적으로 출력 됩니다.

    • 지금 보시는 TSBOARD 공홈처럼 / 경로에 바로 설치가 되어 있거나, 혹은 apache / nginx 에서 root 경로를 / 로 잡아주신 경우에는 TSBOARD.PREFIX 값은 빈 문자열이 됩니다. 이 때 vite.config 기준으로 base 경로는 / 가 됩니다.

    • TSBOARD를 root 경로에 설치하지 않거나, apache 혹은 nginx 에서 따로 root 경로로 잡아주지 않으신 분들은 TSBOARD.PREFIX 값만 잘 설정하시면 됩니다!


이어서 v0.9.4 에서는 아래의 사항이 변경되었습니다!


  • 이제 기본 게시판 목록보기 시 페이지가 주소 표시줄에 표기되고, 페이지들을 이동하다가 게시글을 열람한 후 다시 목록으로 돌아갈 때 이전 페이지 목록으로 그대로 돌아옵니다.

    • 브라우저의 뒤로가기, 앞으로 이동하기 등과도 호환됩니다.

    • 주소 표시줄에서 임의의 페이지로 바로 이동하려는 경우는 지원하지 않습니다. 예를 들어, 이 곳 게시판에 접속 시 /page/123 처럼 주소에 직접 페이지 번호를 입력하더라도 처음 접속은 무조건 /page/1 로 고정됩니다.


페이징 처리는 처음 TSBOARD 개발을 할 때부터 어떻게 하면 좋을지 고민이 많았습니다.

처리 속도를 고려하고자 페이징 처리를 DB에서 LIMIT 절로 하지 않기로 하면서 이 고민들이 시작되었는데,

결국 편의성을 좀 더 높이면서 너무 복잡해지지 않도록 신경을 쓰느라 반영이 이제서야 되었네요.


페이징 부분에서 혹시 문제가 있거나 버그를 발견하신 분들은 알려주시면 빠르게 수정해 나가도록 하겠습니다!

  • tsboard
  • 업데이트
  • 페이지
  • 게시글
  • 목록
  • Github repo를 통해서 v0.9.5 업데이트가 공개되었습니다!


    • 글 수정에서 이미 첨부한 파일을 삭제한 경우, 해당 게시글이 제대로 불러지지 않는 문제를 수정하였습니다.

      • 이 문제는 특히 이미지 파일을 첨부한 갤러리에서 페이지가 보여지지 않던 문제를 야기했었습니다. 비슷한 문제를 겪으셨던 분들은 이번 버전으로의 업데이트를 추천드립니다.

    • 갤러리와 게시판을 오가며 댓글을 남길 때 게시판에 남겨져야 할 댓글이 갤러리에 남겨지거나 하는 문제를 수정하였습니다.

    • 이제 v0.9.5 설치부터 테이블 간의 의존 관계를 좀 더 명확히 하도록 외래 키 설정이 보강됩니다.

      • 기존 사용자의 경우 업데이트를 제공할 예정입니다.


    버그 제보나 새로운 기능 제안 등은 언제나 환영합니다! 많이 써보시고 필요한 것들은 언제든지 알려주세요~!

    2024:07:24 17:35:19 / / written by 시리니

살면서 언젠가 한 번은 C++를 써야 할 때가 온다

2024:07:07 22:41:36 / / written by 시리니

저는 코딩을 PHP부터 시작했고, 스크립트 언어 위주로 사용하다가 시간이 조금 지나서 이제는 화석이 되어버린 MFC를 써야하는 시점에 C++ 언어를 제대로 접하게 되었습니다. 학부 시절에 로우 레벨 언어로 사용했던 C언어와 간혹 같이 붙여서 C/C++ 로 표현하기도 했었지만, C++의 뜨거운 맛을 맛본 뒤로는 C언어와 동일 선상에서 부르는 건 그만두게 되었지요.


C++언어는 정말 경이로운 언어입니다. 만들어질 당시 컴퓨팅 파워는 지금의 라즈베리파이보다 못한 수준이었을테고, 그럼에도 최적화된 성능을 이끌어내기 위해서 컴파일러나 언어 사용자나 많은 고생을 해야만 했을 겁니다. C언어 수준의 속도를 보장하면서도 여러 패러다임들을 받아들이기 위해 마개조스러운 변화가 반영되었고, 그럼에도 예전 코드가 최신 컴파일러에서 제대로 동작하도록 하위 호환성에도 미친듯한 신경을 썼습니다. 과거의 유산을 포기하지 않으면서 여전히 미래로 도전하는 이 언어는 감히 평해보자면, SW업계에 공기와도 같은 존재로서 어디서나 만날 수 있는 언어라 말할 수 있겠습니다.


C++언어의 창시자와 다른 구루들이 남긴 말을 살펴보면, 이 언어의 진가를 알 수 있습니다.


  1. 50년간 연구를 했다. 결국 C++인가? (Richard A. O’Keefe, Functional Programming 연구에 힘쓰는 컴퓨터 과학자)

  2. C,C++을 쓰는 건 안전가드를 제거한 전기톱을 쓰는 것과 같다. (Bob Gray)

  3. C++ 에서는 스스로 발을 쏘는 행위는 거의 일어나지 않는다. 하지만 그런 일이 일어난다면 다리 전체가 날아가 버릴 거다. (Bjarne Stroustrup, C++언어의 창시자)

  4. C++ : 여기선 친구들이 당신의 Private Members에 접근할 수 있다. 코딩 농담임. (Gavin Russell Baker)

(출처 : https://subokim.wordpress.com/2015/03/12/101-great-computer-programming-quotes/)


제 생애 가장 프로그래밍이 고통스러웠던 순간을 떠올려보면, C++언어를 사용할 때라고 단언할 수 있습니다. 비록 그 때는 모던 C++ 시대가 아니었고, 제가 주로 사용했던 영역은 MFC였습니다만, 그럼에도 이 C++언어는 저로 하여금 스스로 다리 전체를 날려버리는 끔찍한 경험을 몇번이나 하게 만들었습니다.


포인터를 날려버리는 건 귀여운 애교 수준이었고, 가끔은 캐스팅을 잘못해서, 어쩔 땐 참조를 잘못써서 문제가 생기는 게 흔하던 시기였습니다. 저의 실력이 미천했던 것도 물론입니다만, 당시 제 느낌은 헬멧도 쓰지 않은채로 시속 100km로 달리는 오토바이 위에서 눈을 감고 서 있는 그런 느낌이었습니다. 운이 좋으면 오토바이가 멈출 때까지 (프로그램이 종료할 때까지) 아무런 일도 일어나지 않지만, 운이 나쁘면 저는 오토바이가 의도치 않게 멈춰 저는 어디론가 날아가 버릴 수도 있겠죠. ㅎㅎ;;


다른 언어도 마찬가지겠지만, C++언어는 모든 부분을 다 배워서 써먹는 게 불가능합니다. 이 언어만 몇십년동안 사용했던 개발자들도 하는 얘기니 믿을 수 있겠죠. 프로그래밍 언어의 역사가 이 언어 속에 녹아져 있고, 그걸 모두 배워서 써먹는 건 가능하지 않습니다. 그저 필요한 부분만 확실히 익혀서 써먹는 정도가 가능할 뿐이죠. 마치 학창시절부터 배워 온 영어가 아직 입 안 어딘가에 맴돌기만 하는 것과 같습니다.


가능하면 MFC를 쓸 때 이후로 다시는 C++언어와 만나고 싶진 않았습니다. 지금 TSBOARD 프로젝트처럼 이왕이면 타입스크립트 언어나 좀 더 네이티브로 나아간다면 Go 언어 정도를 배워서 써먹어야겠다 생각했는데… 어쩌다 보니 먹고 살기 위해서 다시 C++언어를 만날 준비를 하고 있습니다. 무서운 선생님을 다시 만나는 기분이라 약간 두려운 마음이 크네요. 부디 예전과 다른, 조금쯤은 더 친절해진 C++이 저를 맞이해 주기를 바라며 다시 열공중입니다.


프로그래밍을 하시는 분들이라면, 누구나 한 번쯤은 C++언어를 만나게 되는 순간이 있을 겁니다. 그 때 부디 유쾌한 재회가 될 수 있기를 기원합니다. 저도 이제는 다리 전체를 날려버리는 멍청한 짓은 이제 그만둘 수 있기를 바래봅니다.


  • cpp
  • 프로그래밍
  • 언어
  • mfc

TSBOARD v0.9.2 업데이트 안내드립니다!

2024:06:26 22:21:03 / / written by 시리니

안녕하세요! TSBOARD 개발자 시리니입니다.


간만에 업데이트 소식을 전해드립니다.

이번에는 이미 보신 것처럼 첫화면 디자인 개편이 주를 이루고 있습니다.

아래에 보다 자세히 안내드릴께요!


  • TSBOARD 첫화면에서 이제 게시판 ID로 구분하여 최근 게시물들을 나눠서 보여줄 수 있습니다.

    • 그동안 모든 게시글들이 구분 없이 최신 순서로만 출력이 가능했었는데, 이제는 구분해서 나오며 순서 역시 src/pages/home/HomePageCategoryWindow.vue 파일에서 TARGETS 배열을 수정하면 변경 하실 수 있습니다. (아래 코드 참조)

    const TARGETS = [
      { id: "free", limit: 8 },
      { id: "photo", limit: 4 },
      { id: "sirini", limit: 4 },
    ]
    • 기본의 최신 게시글 순서로 출력되는 것은 LATEST 탭을 통해서 여전히 보실 수 있으며, 첫화면 상단 통합검색 부분에 검색어 입력 시 자동으로 탭이 전환됩니다. 검색어를 지우고 엔터 입력 시 다시 분류 형태의 첫화면으로 돌아올 수 있습니다.

  • 게시글 입력 화면에서 좌측 하단에 불러오기 버튼을 추가하였습니다. 글 작성 도중에 만약 브라우저를 새로 고침 했거나 할 경우 당황하지 마시고 불러오기 버튼을 클릭하시면 직전에 작성하셨던 내용을 그대로 불러오실 수 있습니다.

  • TSBOARD를 여러 서버에 분산하여 설치 후 사용하는 경우에, 작성된 글 내용을 쉽게 동기화하거나 전달할 수 있도록 sync 기능이 추가되었습니다. 이 기능은 대부분의 경우 사용할 일이 없지만, 제가 필요하게 되어서 반영하게 되었습니다.

    • 이 기능은 상대방 서버의 .env 파일에 명시된 JWT_SECRET_KEY 값을 정확히 알고 있어야만 사용이 가능합니다. 즉 일반적으로는 사용이 불가능합니다.

    • 만약 이 동기화 기능을 보다 명확하게 사용하지 않기를 원하신다면, server/routers/sync.ts 파일을 삭제하시면 됩니다.


이 밖에 자잘한 버그 수정이 반영되었습니다!


0.9.z 버전대에서는 블로그 기능 구현에 좀 더 집중을 해야 하는데, 작업을 하다보니 첫 화면에 손을 대기 시작하면서 약간 지체되었습니다.

기본적으로 블로그 형태나 기능(rss 등)은 다 되어 있으므로 목차 자동 생성하기나 읽고 쓰는데 좀 더 편한 기능들을 하나씩 반영해 나가려고 합니다.


TSBOARD를 이용한 다양한 커뮤니티 사이트가 생길 그 날을 기대해 봅니다!


감사합니다.

  • tsboard
  • 업데이트
  • 첫화면
  • 개선
  • 블로그
  • v0.9.3 에서는 아래 사항들이 수정되었습니다.


    • TSBOARD.PREFIX가 이제 제대로 적용되도록 이미지 출력하는 코드 중심으로 모두 수정이 되었습니다. 만약 TSBOARD가 https://example.com/tsboard 경로에 설치되었다고 가정하면, TSBOARD.PREFIX 값을 /tsboard 로 설정할 경우 이미지나 리소스들이 정상적으로 출력 됩니다.

      • 지금 보시는 TSBOARD 공홈처럼 / 경로에 바로 설치가 되어 있거나, 혹은 apache / nginx 에서 root 경로를 / 로 잡아주신 경우에는 TSBOARD.PREFIX 값은 빈 문자열이 됩니다. 이 때 vite.config 기준으로 base 경로는 / 가 됩니다.

      • TSBOARD를 root 경로에 설치하지 않거나, apache 혹은 nginx 에서 따로 root 경로로 잡아주지 않으신 분들은 TSBOARD.PREFIX 값만 잘 설정하시면 됩니다!


    위 업데이트 사항은 v0.9.4 배포 시점에 다시 말씀드리겠습니다.

    2024:06:28 11:38:24 / / written by 시리니

Bun은 언제쯤 가상 CPU에서도 제대로 돌아갈까

2024:06:24 00:12:36 / / written by 시리니

예전에 GeekNews 에서 TSBOARD를 홍보했을 때,

TSBOARD가 의존하고 있는 Bun 런타임에 대한 설명으로 아래와 같이 말씀을 드린 적이 있습니다.


  • Bun 런타임은 가상 CPU에서의 동작이 제대로 안됩니다. 저렴하게 사용 가능한 가상서버 호스팅에서는 제대로 활용하기 어렵습니다. TSBOARD도 Bun에 의지하고 있어서 마찬가지입니다.


사실 좀 더 명확하게 원인을 표현하고 싶은데, 제대로 알지 못하는 상태로 단정짓는 것처럼 보여질까봐 조심스럽습니다.


그저 제가 파악한 바로는, Bun 런타임이 최적화된 성능을 발휘하기 위해서는 특정 CPU 명령어가 필요한데, 가상 CPU의 경우 지원하는 명령어가 그리 많지 않아서 제대로 동작이 되지 않는 것으로 알고 있습니다. 예외적으로 AVX2 명령어셋이 지원되지 않는 CPU의 경우 Bun 측에서 baseline 배포판을 따로 제공해주긴 합니다만, 아무튼 제약이 있다는 점은 분명합니다.


제가 이 문제를 겪었던 대표적인 호스팅 업체가 바로 cafe24 가상서버 였는데요.

직접 cafe24 지원 부서에도 문의해보았습니다만, Bun 런타임이 제대로 동작하지 않는 문제에 대해서는 따로 조치를 취하기 어렵다는 답변을 받았었습니다. 물론 SW 개발자가 어떻게 개발했는지 다 파악하기도 어렵고, 막상 문제를 알아도 수정하는 게 생각처럼 쉽지 않을테니 이해는 됩니다.


그냥 가상서버는 안되나보다, 하고 넘어가다가… 혹시? 싶어서 세계적으로 유명한 도메인 제공 업체인 Namecheap의 VPS는 어떨까 궁금해서 한 번 결제를 해보았습니다. 개발용으로 간단히 테스트를 돌려보고 싶은 게 있어서 사실 겸사겸사 제일 저렴한걸로 결제를 해보고 테스트를 했습니다만…


Namecheap VPS 역시 마찬가지 증상입니다 🥲


cafe24 가상서버와 마찬가지로 Bun이 제대로 동작 안됩니다.

CPU 제약이니까 아무래도 Bun 개발팀이 프로젝트를 새로 만들지 않는 한 어려워 보입니다. (슬프네요…)


참고로 Bun 런타임이 지원되는지 (안되는지) 파악하는 방법을 알려 드리겠습니다.

아주 간단합니다. 먼저 아래와 같이 console.table 을 이용하는 test.ts 코드를 작성합니다.


const test = { name: 'sirini', project: 'tsboard' }

console.table(test)


만약 Bun 런타임이 구동하는 CPU라면, 위의 코드는 문제 없이 표 형태로 데이터를 이쁘게 출력해줘야 합니다. 이는 ts-node 를 이용해서 실행해도 마찬가지입니다. 반면 지원되지 않는 CPU에서는 아래와 같이 나타납니다.


Bun v1.1.16 (bf7b327f) Linux x64 (baseline)
Args: "bun" "test.ts"
Features: jsc
Builtins: "bun:main"
Elapsed: 6ms | User: 4ms | Sys: 4ms
RSS: 1.07GB | Peak: 37.10MB | Commit: 1.07GB | Faults: 0

panic(main thread): Segmentation fault at address 0xFFFD
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.1.16/Ba1bf7b327AC216ymE+xyQ6uzynDopy1iDqto2/Ck2q3/C6ri5/C2661kE61nlgF_A2A6//D

Illegal instruction (core dumped)


결론, Bun 런타임을 쓰려면 가상 CPU 환경은 피하셔야 합니다.

따라서 Bun 런타임에 의존하고 있는 TSBOARD를 사용하고자 하시는 분들은 물리적인 서버를 준비하셔야 합니다. 속도를 위한 선택이었지만, 최근에 Node.js 에서는 동작 안하냐고 물어보시는 분들이 종종 계셔서 뭔가 괜히 저도 아쉽고 그렇습니다. ㅎㅎ


(Go 언어로 백엔드를 다시 만들어야 하나… 🧐)

  • bun
  • 런타임
  • cpu
  • cafe24
  • namecheap
  • vps
  • 가상서버
  • 어쩌면 조금 늦은 업데이트가 될 수도 있겠습니다만, Bun v1.1.31에서 다시 확인해 본 결과 가상 CPU에서도 이제 문제없이 정상적으로 동작하는 것을 확인하였습니다! 혹시나 이 글을 보시게 될 분들이 이 글을 보시고 Bun 런타임을 알아갈 수 있는 기회를 놓치시진 않을까 염려되어 댓글을 남겨놓습니다. 😅

    2024:10:21 22:57:23 / / written by 시리니

웹개발, 해야 한다면 풀스택으로 시작하자

2024:06:19 00:38:34 / / written by 시리니

야심한 시각에 코딩하다가 문득 짧게라도 기록해두고 싶은 이야기가 있어서 이곳에 왔습니다.


TSBOARD는 저에게 있어 여러모로 남다른 프로젝트인데, 타입스크립트 단일 언어로 작성하면서도

풀스택으로 개발된 (저에겐) 최초의 프로젝트입니다. 약간 거슬러 올라가면 GR Board라 이름 지었던

PHP 게시판이 있었고, 역시 풀스택 프로젝트였습니다. (그 땐 풀스택이라는 용어조차 생소했던 시기이긴 했네요)


좀 더 거슬러 올라가보니 저에게는 제로보드4 시절의 추억이 있었습니다.

이제는 제로보드를 기억하는 분들이 많이 없으시지만, 당시만 해도 정말 웹호스팅 업계를 먹여 살린 프로그램입니다.


그 때는 PHP 언어에도 익숙하질 않아서 지금 용어로 표현하면 프론트엔드만, 그 때 용어로는 “스킨” 만 만들었습니다.

스킨을 만들고 공유하다가 점점 내가 원하는 기능을 직접 구현해보자 싶어서 PHP 언어를 필요할 때마다 배워서

하나씩 구현한 게 저의 (허접한) 웹개발 역사네요. ㅎㅎ


제가 웹사이트라는 걸 만들고 싶다고 생각한지가 고등학생 때였으니까,

어림잡아서 뻥 좀 보태면 대충 20년이라는 시간이 벌써 흘렀습니다.

그 사이 PHP언어가 주름잡던 웹 생태계가 이제 다양해지면서 어느 새 자바스크립트 시대가 열리고

지금의 다변화된 웹 생태계가 만들어졌네요.


긴 시간을 통틀어서 만약 웹개발에 대해서 제 나름의 생각을 공유할 기회가 있다면

나는 과연 무슨 얘기를 해줄 수 있을까? 하는 생각이 잠시 들었습니다.


제일 좋은 조언은 웹개발은 하지 말고 더 돈이 되는 SW 개발을 하던지 AI/데이터 사이언스에 도전하세요, 라고 해야 겠지만

그럼에도 누군가는 저처럼 웹개발이 하고 싶을 것이고, 그 중에는 Evan You와 같은 슈퍼 개발자가 나타나기도 할겁니다.

순수 웹개발 경력은 사실 얼마 안되는 저입니다만, 그럼에도 만약 조언을 해준다면…

저는 아래의 메시지를 강조하고 싶습니다.


처음부터 풀스택으로 개발하세요


지금의 웹프로젝트는 사실 프론트와 백엔드로 나눠서 개발하는 게 정상일 정도로 충분히 복잡합니다.

백엔드만 해도 고민할 게 얼마나 많습니까? 동시 접속자 처리를 어떻게 하느냐에 따라 투입되는 리소스(=돈)가 달라지니

어떻게든 효율적으로 개발해야 하는 게 맞습니다. 게다가 서버쪽에서 렌더링을 해줘야 SEO에 더 유리하니까

이래 저래 고민할 부분들이 적지 않습니다. 저울질을 해야 할 순간들이 많을테지요.


프론트엔드도 만만치 않습니다. React나 Vue 혹은 Svelte나 Angular같은 프레임워크/라이브러리들을 보면

이건 정말 이것대로 따로 배워서 써먹어야겠다 싶을 정도입니다. 저도 TSBOARD 프로젝트를 시작하기전에

npm은 뭐고 왜 내가 이 수많은 패키지들을 설치해야만 하는 것인지 이해가 안되었습니다. (이제는 좀 이해가 됩니다 ㅎㅎ)

UX 디자이너와의 협업 또한 아무래도 프론트엔드 개발자분이 해주셔야 하는 몫이겠지요.


그럼에도, 저는 만약 새롭게 웹개발에 도전하시는 분이 계시다면 처음부터 풀스택으로 개발해보라고 말씀드릴 겁니다.

결국 웹은 눈에 보여지는 것도 필요하지만, 그 뒤를 받쳐주는 것에 대한 이해도 필요하거든요.

나중에 좀 더 자신에게 맞는 분야를 선택하게 되더라도, 그 전에는 풀스택으로 버튼 UI부터 SQL 실행까지

코드라는 실로 꿰어보는 연습이 필요하다고 생각합니다.


백엔드가 얼마나 힘겹게 여러 사용자들의 요청사항들을 대응하고 있는지 안다면, 프론트엔드에서 이를 해소할만한

아이디어를 궁리해 볼 기회가 생기게 됩니다. 반대로 프론트엔드에서 어떤 식으로 사용자와 상호작용을 하고 싶은지

이해한다면 백엔드를 좀 더 효율적으로 구성할 수 있는 다른 아이디어를 찾아보게 됩니다.

혼자서 역할을 바꿔 가면서 작업을 하다보면, 단순히 1 + 1 = 2 가 아니라 3도 되고 10도 되는 순간을 만끽할 수 있습니다.


TSBOARD처럼 클래식한 프로젝트로 작게 시작해보는 것도 좋고, 여러분이 흥미를 느끼는 그 어떤 웹 프로젝트도 좋습니다.

작게 시작하되, 풀스택으로 영역을 구분하지 말고 시작해보세요. SQL이 혹시 어렵다면 ChatGPT 선생님을 찾아가도 되고

검색만 할 줄 알면 그 어떤 것이라도 해낼 수 있습니다. 필요한 온라인 강의로 개념을 잡아보는 것도 좋습니다.


풀스택 개발, 어렵지 않습니다.

웹개발을 해보고 싶다면 처음부터 풀스택으로 시작해보세요.




야심한 시간에 졸린 와중에 글을 써서 다소 횡설수설 합니다만 ㅎㅎ

마지막 메시지만 기억해주시면 좋겠습니다. 😅

  • 풀스택
  • 웹개발
  • tsboard
  • 프론트엔드
  • 백엔드
  • 이야기

v0.9.1 작업중입니다.

2024:06:18 00:00:10 / / written by 시리니

TSBOARD 업데이트를 조금씩 진행하고 있습니다.


이번에는 이것 저것 자잘한 부분들, 그동안 바빠서 신경을 못썼던 부분들 먼저 소소하게 챙기고

대부분의 사용자에겐 필요 없지만 저에겐 필요한 데이터 전달용 라우터도 추가하였습니다.


저의 경우 물리적으로 분리된 서버 간에 데이터를 주기적으로 동기화해야 할 필요가 가끔 있었습니다.

원래는 정식 코드에 반영하지 않고 따로 분리해서 작성했습니다만, 계속 이런 식으로 코드를 파편화 시키면

나중에 제가 감당이 되지 않을 것 같아서 이번부터 반영을 하였습니다.

(일반적인 사용자는 해당 기능을 신경 쓰실 필요가 없습니다. 😃)


TSBOARD라고 이름 짓지 말고 TSBLOG라고 할 걸 그랬나? 싶을 정도로 사실 지금의 블로그 형태가

저 스스로는 꽤나 마음에 듭니다. ㅎㅎ 디자인이 비록 너무 심플하기도 하고, 아직 워드프레스에

비벼볼 깜냥은 아닙니다만, 그럼에도 직접 개발한 도구를 이용해서 글을 작성하는 즐거움이 있습니다.


가장 보람되는 것은, 처음 TSBOARD를 개발할 때 생각했던 컴포넌트 재활용 전략이 잘 먹혔다는 점입니다.


개발 기간을 줄이면서도 효과적으로 필요한 기능들을 추가하고, 검증하려면

할 수 있는 한 컴포넌트들의 재활용 비율을 높여야 합니다.

하다못해 디자인을 하더라도 서로 비슷하게 구성을 해야 필요할 때 쉽게 가져다 쓰거나

조금만 바꿔서 익숙한 듯 새로운 느낌을 줄 수 있었습니다.


그래서 처음 개발할 때 우선 게시판과 갤러리만 집중해서 개발을 했었고, v0.8.z 버전대를 지나오면서

충분히 기반이 단단해 질 때까지 반년 이상 시간을 쏟아부었습니다. 그 덕분에 사실 블로그는 예상 외로

굉장히 빠르게 틀을 잡아서 만들 수 있게 되었네요. 😋


디자인 관점에서는 여전히 아쉬운 점도 많고, 무엇보다 커스텀 테마까지 제공할 여력이 안되는 점이 제일 아쉽습니다만

천천히 이것 저것 궁리해 나가면서 하나하나 개선해 보려고 합니다.


게시판, 갤러리 그리고 블로그까지… TSBOARD의 도전은 계속 됩니다!

  • tsboard
  • blog
  • 업데이트
  • 주저리
  • 컴포넌트
  • 재활용

TSBOARD v0.9.0, BLOG 기능이 추가되었습니다!

2024:06:11 19:53:07 / / written by 시리니

안녕하세요! TSBOARD 개발자 시리니입니다.


약 9개월간의 v0.8.z 버전대를 거쳐서 이제 공식적으로 v0.9.z 으로 판올림 되었음을 알려드립니다!

이번 판올림에서는 드디어 제가 쓰고 싶었던 블로그 기능이 추가 되었습니다.

블로그니까 당연히 RSS 피드 제공 기능도 제공됩니다. ㅎㅎ


여러 변경점들이 있습니다만, 아래와 같이 간략히 공유드립니다!


  • 이제 게시판 / 갤러리에 이어서 게시판의 형태를 블로그 형태로 변경하실 수 있습니다. 블로그 형태일 때는 게시판 관리자로 지정된 사용자만 글쓰기가 가능합니다.

    • 만약 블로그 사용을 원하는 사용자가 10명이라고 하면, 블로그 형태로 지정된 게시판 10개를 각각 생성해야 합니다.

    • 각 게시판의 고유 ID가 블로그 주소에 사용됩니다. 이곳 TSBOARD 공홈 기준으로는 https://tsboard.dev/blog/sirini 처럼 됩니다. (/blog/ 뒤에 게시판 ID)

  • 블로그는 기본적으로 다크 테마입니다. 이는 게시판이나 갤러리와 달리 보다 개인적인 공간이라는 의미를 부여하기 위해 의도한 것입니다.

    • TSBOARD가 제공하는 Tiptap 기반의 에디터 역시 다크 테마로 제공됩니다. 글쓰기에 좀 더 집중해 보세요!

  • 블로그에 작성된 글은 기본적으로 첫 페이지 최근 게시글에 노출됩니다.

  • RSS 피드를 제공합니다. 이는 SEO를 위해 추가된 sitemap.xml 과 마찬가지로 서버 사이드 렌더링으로 출력됩니다.

  • 블로그 좌측 상단에 블로그 이름과 설명은 게시판 이름 / 설명입니다. 또한 게시판 관리자의 프로필 이미지가 블로그 상단 중앙에 나타납니다.

  • 블로그 게시글에 첨부한 이미지들은 내부 갤러리 형태로 보여지며, 하단에 사진/그림에 대한 텍스트 설명글이 자동으로 노출됩니다. (OpenAI API 연동 시)

  • 이번 v0.9.0 업데이트를 위해서는 bun update.ts 를 한 번 실행해 주시는 걸 추천합니다. (만약 기존에 설치하신 이력이 없다면 안하셔도 됩니다!)


이 밖에도 버전 업데이트를 진행하면서 자잘한 버그 수정을 함께 진행하였습니다.

게시판 / 갤러리 그리고 블로그까지! TSBOARD는 여러분의 웹 공간을 더욱 다채롭고 빠릿하게 만들어드립니다.

많이 알려주시고 한 번 써봐주세요!


감사합니다!

  • tsboard
  • blog
  • 업데이트
  • rss

TSBOARD 블로그 작업을 시작하였습니다.

2024:06:08 02:25:26 / / written by 시리니

안녕하세요! TSBOARD 개발하고 있는 시리니 입니다.


아직 오피셜하게 업데이트 공지를 드리지는 못했습니다만, 기본적인 블로그 작업은 마무리되어서

우선 제 블로그부터 하나 만들어 보았습니다. ㅎㅎ


사실 이름을 TSBOARD 라고 짓기는 했습니다만, 저는 제가 만든 블로그를 운영해 보는 게 목표였는데

이제 한걸음 다가간 셈입니다. 공식 업데이트 소식에서 좀 더 자세한 내용을 설명드리겠지만,

아래에 간략히 블로그 작업하면서 신경썼거나 의도한 부분들 먼저 소개 드리겠습니다!


  • TSBOARD의 블로그는 기본적으로 어두운 테마 기준으로 작업되었습니다. 이는 게시판이나 갤러리와 구분되도록 의도한 것으로, 블로그라는 게 게시판과 달리 보통은 한명 내지는 소수의 인원만 사용하는 게 일반적이라서 좀 더 개인적인(?) 느낌을 드러내고자 색상을 다르게 가져갔습니다.

  • 블로그는 TSBOARD 게시판 설정에서 게시판 관리자로 지정된 사람만 사용할 수 있도록 할 생각입니다. 만약 TSBOARD로 10명에게 각각 블로그를 만들어주려면 10개의 게시판을 생성해야 합니다.

  • 블로그에 작성된 글은 홈 화면의 최근 게시글에서도 그대로 만나 보실 수 있습니다. 그러고보니 홈 화면의 게시글들을 지금은 최신 순으로만 볼 수 있는데 앞으로는 특정 기간 동안의 좋아요나 조회수 기준으로 정렬하는 것도 구현할 예정입니다.


이제 첫 삽을 퍼올린 셈이라, 여기 저기 손봐야 할 부분들이 많습니다.

어느 정도 정리가 되면 TSBOARD v0.9.0 업데이트 소식으로 공유 드릴께요!

블로그 한 번 씩 봐주시고 어떠신지 의견들도 많이 부탁드립니다 😆

  • tsboard
  • blog
  • 작업
  • 시작

정말 훌륭하네요~

2024:06:04 06:51:24 / / written by Bryan

퀄이 너무 좋습니다~

지금은 홈서버로 돌리고 계신데…

이미지 업로드는 역시 홈서버로 되는 거죠?


중대형으로 가게 되면 이미지 트래픽 비용이 엄청 나게 많이 나온다던데 거기에 대한 대비책은 있을까요?


  • 안녕하세요! 글 남겨 주셔서 감사합니다 ㅎㅎ


    네 말씀하신대로 지금은 홈서버에서 구동중이고, 혹시나 TSBOARD 공홈이 만약 중대형 커뮤니티로

    성장하게 된다면 그 때는 호스팅을 따로 구하던가 해보려고 합니다. 그 때쯤이면 이미지 업로드는

    이미지 트래픽 무제한 호스팅을 이용하던가 해야 할 것 같습니다!


    이미지 트래픽이 무지막지한 점 때문에 고민을 하다가, TSBOARD는 처음부터 .avif 포맷만 적용하게 되었습니다.

    그나마 압축률이 높아서 트래픽을 가장 억제할 수 있는 방법이 아닌가 생각했었습니다. ㅎㅎ

    추가적으로 tsboard.config.ts 파일 설정을 통해서 썸네일 사이즈를 좀 더 줄이거나 하는 방식으로

    트래픽을 어느 정도 제어할 수 있을 것 같습니다.


    모든 건 당해봐야(!) 알겠지만 TSBOARD 공홈은 아마 크게 되긴 어려울 것 같고…

    TSBOARD를 이용한 다른 훌륭한 커뮤니티가 성장해 나가면서 겪는 문제들을 잘 듣고

    같이 해결책을 찾아보던지 해야 하겠습니다.


    의견 주셔서 감사드리고 자주 놀러와 주세요! ㅎㅎ

    2024:06:04 10:01:39 / / written by 시리니

TSBOARD v0.8.40 업데이트!

2024:06:02 18:54:12 / / written by 시리니

안녕하세요, 타입스크립트로 작성된 커뮤니티 빌더 TSBOARD 개발자입니다!


이번 업데이트는 생각보다 많은 변화가 담겨 있어서, 버전 점프를 많이 하게 되었습니다.

v0.9.z 버전 진입 전에 최대한 많은 개선점들을 반영해두고자 노력해 보았는데 어떨지 모르겠네요. ㅎㅎ

혹시 테스트를 해볼까 고민중이신 분들이라면, 이번 v0.8.40 버전을 기점으로 본격적으로

테스트를 해보셔도 좋을 것 같습니다.


이번 v0.8.40에서는 아래의 사항들이 반영되었습니다!


  • 이제 TSBOARD가 검색 엔진 최적화를 위해 sitemap.xml 을 제공합니다.

    • public/robots.txt 파일에 지정된 Sitemap: 경로를 통해서 크롤러는 TSBOARD 사이트의 구조, 데이터 업데이트 빈도 및 링크별 중요도를 명확하게 파악할 수 있습니다.

    • 홈 화면에서 보여지는 최근 게시물 목록처럼, sitemap.xml 파일에 명시된 main.html 파일 경로를 통해 검색 엔진이 수집해야 할 내용들을 명시적으로 알려줄 수 있습니다. 해당 main.html 파일은 서버에서 렌더링되며, TSBOARD 공홈 기준 https://tsboard.dev/tsapi/seo/main.html 경로를 통해 내용을 확인해 보실 수 있습니다.

    • 검색 엔진은 main.html 페이지를 통해 더 빠르게 데이터를 수집할 수 있고, 사용자는 검색을 통해 main.html 로 사이트에 방문하여 내부 링크들을 통해 다시 원래 웹사이트로 접속이 가능해집니다.

  • 테이블 간의 의존 관계를 명확히 하도록 외래 키(FOREIGN KEY)를 추가하였습니다. 기존 사용자는 bun update.ts 를 한 번 실행해야 합니다. 만약 아직 테스트 단계이고, 보존이 필요한 데이터가 없다면 v0.8.40은 클린 설치를 추천드립니다. (모두 삭제 후 다시 설치)

    • 외래 키 지정이 없더라도 TSBOARD 자체적으로는 테이블 간의 의존 관계를 활용하고 있습니다. 다만 이 작업은 보다 명시적인 의존 관계 설정을 통해 DBMS가 좀 더 데이터 무결성을 보장할 수 있도록 해줍니다.

  • TSBOARD가 의존하고 있는 외부 패키지들의 버전대를 최신 버전으로 반영하였습니다. git pull 작업 후 npm i 혹은 bun install 작업으로 외부 패키지들의 업데이트 작업을 진행해 주세요. (vite, elysia 등이 메이저 버전 업그레이드)

  • 글작성에 이어 댓글 작성 시 에디터 툴바 위치가 재조정 되도록 수정하였습니다.

  • 갤러리 뷰어 디자인 소폭 변경 및 util 스토어 리팩토링이 반영되었습니다.

  • 홈 화면 최근 게시글 및 게시판 최근글 디자인이 소폭 변경되었습니다.


위 내용과 더불어 README.md 내용도 v0.8.40 업데이트에 맞춰 내용을 갱신하였습니다.

(혹시 설명된 내용 중에 이해가 잘 안되는 부분이 있다면 알려주세요!)


TSBOARD 기반으로 더 많은 웹 커뮤니티가 생겨나길 바랍니다!


감사합니다.

  • tsboard
  • 업데이트
  • seo
  • sitemap
  • 외래키
  • 무결성
  • 에디터
  • 툴바

TSBOARD v0.8.30 업데이트 안내!

2024:05:29 00:12:05 / / written by 시리니

안녕하세요, TSBOARD 개발자 시리니입니다.


이번 v0.8.30 업데이트에서는 아래의 내용들이 변경되었습니다!


  • 이제 갤러리에 올려진 사진에 대해서 원본 파일 (.avif 로 압축된 파일이 아닌 .jpeg 처럼 사용자가 처음에 업로드한 원본) 을 내려받을 수 있습니다. 갤러리 뷰어 우측의 사이드바를 보시면 중간 쯤에 작성일과 조회수가 나타나는데, 우측에 원래는 작성자 이름이 나왔으나 이제는 원본 받기 버튼이 나타납니다. (사용자가 설정한 언어에 맞춰 표기됩니다)

    • 원본 파일 받기는 게시판의 다운로드 레벨 제한 및 필요 포인트 설정에 영향을 받습니다. 포인트가 차감되도록 설정하신 경우 비회원은 받을 수 없고, 마찬가지로 비회원의 경우 원본 파일은 내려 받을 수 없도록 되어 있습니다.

    • TSBOARD에서는 목록 보기나 글 내용 보기 이외에 (댓)글 작성, 수정, 다운로드 등의 활동에 사용자 세션을 요구합니다. 즉, 비회원은 원칙적으로 해당 행위를 할 수 없도록 제한되어 있습니다.

  • Adobe lightroom 과 같은 사진 편집 프로그램을 사용하여 수정한 파일을 업로드 할 때, EXIF 정보 일부가 유실되어 업로드 시 처리가 실패하는 현상을 수정하였습니다. 해당 프로그램으로 편집된 사진의 경우 가로 세로 크기 정보가 사라지는데, 이전 TSBOARD에서는 width 정보 유무로 판단하는 로직이 있어서 문제가 있었습니다.

  • 갤러리 뷰어의 디자인이 소폭 변경되었습니다. 원본 받기 버튼이 기존 사용자 이름 위치에 배치되면서 사용자 이름은 제목 하단으로 옮겨졌고, 그 옆에 EXIF 정보 보기/닫기 버튼이 배치되었습니다.


이번 v0.8.30은 댓글을 통해 업데이트 소식을 전해드린 v0.8.29 업데이트 내용을 모두 포함합니다!

(글자 색상 표현 추가, 회원 가입 시 알파멧 대문자 및 소문자 각각 필요한 것으로 수정)


TSBOARD는 여러분의 커뮤니티를 응원합니다!

타입스크립트 단일 언어로 작성되고, 종단간 타입 안정성을 가지며, Bun 런타임으로 더 빠르게

여러분들의 커뮤니티를 움직입니다. 궁금하신 점들은 언제든지 물어봐주세요!

  • tsboard
  • 업데이트
  • 갤러리
  • 원본파일
  • 다운로드
  • exif
  • v0.8.31 업데이트가 반영되었습니다. 곧 v0.8.32 업데이트 소개를 드리겠지만,

    댓글을 통해서 먼저 공유드립니다!

    (참고로 TSBOARD에서 끝자리 숫자가 지금처럼 홀수가 되면 아직 작업중이라는 뜻입니다.)


    • 이제 긴 글을 작성할 때, 에디터 툴바가 상단에 반투명한 상태로 항상 고정됩니다. 화면 내에 항상 툴바가 보여지므로, 글자 색상을 바꾸거나 스타일을 다르게 지정하고 싶을 때 매번 상단 스크롤까지 이동해서 클릭하고 다시 내려와서 텍스트를 입력할 필요가 없습니다.

      • 단, 아직 코멘트의 경우 굳이 상단으로 가지 않아도 되는데 올라가는 문제가 있어서 이는 수정할 예정입니다. 급하지 않다면 v0.8.32를 기다려주세요!

    • TSBOARD가 의존하고 있는 여러 (개발) 패키지들의 메이저 버전대를 올렸습니다. vite나 elysia의 경우 앞자리가 바뀌었고, 그 밖에 여러 패키지들이 오늘자 기준으로 가능하면 최신 패키지를 유지하도록 했습니다. 단, 일부 패키지들간의 의존성 문제가 있어 가장 최신 버전은 아닐 수 있습니다. npm i 명령어 혹은 bun install 명령어를 통해서 패키지들이 최신으로 업데이트 되도록 해주세요!

    • SEO에 조금이나마 도움이 되고자, GeekNews에서 받은 피드백대로 우선 sitemap 기능을 추가 하였습니다. sitemap.xml 경로를 통해 검색엔진이 사이트 구조 파악에 도움이 된다고 합니다. 아직은 SPA 경로라서 크게 도움이 안되는 건 맞습니다만, 곧 서버쪽에서 렌더링한 페이지 경로로 교체해서 제공할 예정이므로 SEO 최적화에 도움이 될겁니다. (어차피 같은 데이터지만 사용자는 SPA로, 크롤러는 따로 차려진 SSR로 접근하는 셈. 수집된 페이지로 사용자가 접근하면 링크를 통해 다시 SPA로 넘어올 수 있도록 해보겠습니다.)

      • public/robots.txt 파일을 열어서 하단에 https://tsboard.dev 라고 작성된 부분을 본인의 도메인으로 교체하여 저장하시고, 그 후 npm run build 를 통해서 /dist 폴더 아래에 저장되도록 해야 합니다. 이 작업은 한 번 만 하시면 됩니다.

      • SEO에도 TSBOARD가 더 이상 약점을 가지지 않도록 sitemap 관련 기능을 보완하도록 하겠사오니 조금만 더 기다려주세요!


    블로그 작업 전에 SEO 최적화 문제를 좀 더 해결해 보겠습니다!

    혹시 도움말을 주실 수 있으신 분들은 주저 마시고 댓글이나 글을 통해서 알고 계시는 내용들을 공유 부탁드릴께요!

    2024:05:29 22:58:24 / / written by 시리니

GeekNews 에 소개하길 잘했네요. ㅎㅎ

2024:05:23 23:56:41 / / written by 시리니

TSBOARD를 GeekNews(https://news.hada.io/topic?id=14914#cid25515)에

소개한 이후 생각보다 많은 관심과 의견들을 들을 수 있었습니다!


개발자로서 가장 기쁜 순간이라고 하면 당연히 다른 개발자분들이 프로젝트에 대해서 관심을 표해 주시고

이것 저것 물어봐 주시는 게 아닐까 싶은데, 감사할 따름입니다. 놓쳤던 부분들을 다시 상기할 수 있었고,

보완해야 할 부분들도 점검 받을 수 있어 기뻤습니다. ㅎㅎ


GeekNews에서 받은 피드백들을 바탕으로 다음 버전 업데이트를 좀 더 재미나게 준비해 나갈 수 있을 것 같습니다.

아직 타입스크립트 기반으로 작성된 게시판 프로그램이 없었던 만큼, 앞으로 나타날 여러 프로젝트들에

부끄럽지 않도록 기초를 다지고, 이어서 제가 쓰고 싶고 다른 분들에게도 쓰고 싶은 그런 커뮤니티 빌더로 만들어 나가겠습니다!


참, GeekNews 댓글 중에 TSBOARD가 사용하고 있는 Bun 런타임에 대한 이야기가 나와서 제가 답글을 남겼었는데요,

아래에도 인용해서 공유해 드리고자 합니다.


GeekNews [dogtree 님]

저도 취미로 만드는 프로젝트를 bun으로 돌릴까 생각중이었는데, 가상CPU에서 동작이 제대로 안된다니 놀랍네요.


저의 답변

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 런타임 생태계에 도전하는 모습들이 뭔가 마음을 움직이더라구요. ㅎㅎㅎ


여기서 좀만 더 얘기해 보자면 (어차피 여기는 자유롭게 글 남기려고 만든 게시판이니 😆)


Bun은 정말 속도 하나만큼은 절대 어떤 런타임에도 지지 않겠다는 아주 강력한 의지를 매 릴리즈마다 보여주고 있습니다.

Node.js 대비 40배가 빠른 땡땡 함수, 뭐보다 8배 더 빠른 API 같은 표현은 일상적으로 나옵니다.


뭐랄까요, 이성적으로 생각하면 호환성 측면에서나 안정성 면에서 사실 TSBOARD 같은 게시판 프로그램은

당연히 Node.js를 선택해야 한다고 머리로는 납득을 했는데, 마음 한켠에서는 JS 생태계에 매드 맥스처럼 불지르러 나타난

이 Bun 프로젝트에 마음을 뺏겨버렸다고 해야 할까요? ㅎㅎㅎ


TSBOARD를 처음 만들기 시작했을 때, 다른 건 몰라도 서버 부담 만큼은 확실하게 줄여주고 무엇보다 빠르게 동작하는

게시판이면 좋겠다는 생각도 했었습니다. 그 때 제 마음을 마치 읽은 것처럼 Bun 이 등장하고 ElysiaJS 웹프레임워크가 나타나서

저도 어쩌다보니? Bun을 선택하게 되었고 이제는 Bun처럼 저도 약간 속도에 집착하게 되었습니다. ㅎ


혹시 상업적인 목적이나 공공기관 등 뭔가 안정성이 필요한 곳에서 JS 런타임을 쓰실 일이 있으시다면,

Bun 말고 Node.js LTS 버전을 쓰시길 추천 드립니다. 합리적인 선택이고, 당연한 선택입니다.


하지만, 만약 취미 프로젝트나 다소 도전적인 개발 스택도 허용되는 JS 프로젝트를 하시게 된다면,

마음 한켠에 JS 생태계의 매드 맥스가 꿈틀대고 있다면, Bun을 선택해 보세요. 후회하지 않으실 겁니다. 😁


  • tsboard
  • bun
  • javascript
  • typescript
  • runtime
  • node.js
  • 매드맥스
  • elysiajs

TSBOARD v0.8.28 업데이트 안내

2024:05:22 18:34:23 / / written by 시리니

안녕하세요! TSBOARD 개발자 시리니입니다.


먼저 GeekNews에서 TSBOARD를 소개한 이후 생각보다 많은 관심을 받았습니다. 감사드립니다!

이 관심은 이제 곧 사그러들겠지만, 저는 계속해서 Bun 기반의 빠르고 쓸만한 커뮤니티 빌더이자 게시판인

TSBOARD 개선에 최선을 다 하겠습니다. 많이 테스트 해주시고, 혹시 괜찮으시면 한 번 써봐주시면 좋겠습니다!

(주변에도 TSBOARD 라고 들어봤니~? 라고 소개해 주시면 더더욱 좋겠습니다. ㅎㅎ)


v0.8.28에서는 아래의 업데이트가 반영되었습니다.


  • 이제 비밀글 기능이 지원됩니다.

    • 비밀글은 글 작성자와 TSBOARD의 관리자(들)만 볼 수 있습니다.

    • TSBOARD의 관리자 정의는 슈퍼 관리자 / 그룹 관리자 그리고 글이 작성된 해당 게시판의 관리자입니다.

    • 비밀글 기능은 게시판 설정이 따로 없습니다. 기본적으로 제공되며 쓰고 싶지 않을 땐 src/pages/board/Write.vue 파일을 수정하시면 됩니다. (더 좋은 방법은 별도의 Write.vue 파일을 생성하여 수정 후 Vue Router 에서 경로 변경!) 옵션으로 빼두지 않은 이유는 게시판 설정값이 지나치게 비대해지는 걸 막기 위함입니다. TSBOARD는 빠르게 동작하기 위해 모든 것을 옵션화하지 않습니다.

  • 전체 / 게시판 / 갤러리 검색에서 이제 검색어 기록이 최대 10개까지 나타납니다.

    • 사이트를 새고로침하면 검색어 기록은 사라집니다.

  • 공지글로 등록하기는 이제 TSBOARD의 관리자에 해당하지 않으면 애초에 보여지지 않습니다.


이제 약 반년 넘게 이어진 v0.8.z 버전대를 곧 마무리하고, v0.9.z 로 넘어가고자 합니다.


사실 TSBOARD 라고 이름을 짓긴 했습니다만, 저는 블로그쇼핑몰이 가지고 싶었습니다!

이제 게시판과 갤러리 같은 기본적인 기능이 준비되었으니, 다음으로 블로그부터 작업을 할 예정입니다.

중간 중간에 계속 소식 공유드리고자 합니다. 많은 관심과 의견 부탁드립니다!


감사합니다.

  • tsboard
  • 업데이트
  • 블로그
  • 쇼핑몰
  • v0.8.29 마이너 업데이트 안내드립니다!

     

    • 이제 게시글과 댓글에서 글자 색상 표현이 가능해졌습니다. 아울러 게시글과 댓글에 대한 사용자 입력값 검사 필터가 하나로 통일됩니다. (editor 와 comment 에 있던 htmlFilter 가 util/tools 로 이동하면서 DEFAULT_HTML_FILTER 로 설정)

    • 이미지 파일 업로드 시 Vision AI (ChatGPT-4o API) 가 제대로 동작하지 않을 경우 한장만 업로드 되던 문제를 수정 (이 부분은 테스트를 좀 더 해보면서 추이를 지켜보겠습니다)

     

    추가적인 업데이트가 있다면 다시 댓글로 알려드릴께요!

    2024:05:26 13:53:11 / / written by 시리니
  • v0.8.29 추가 마이너 업데이트 입니다!


    • 회원 가입 시 비밀번호 규칙에 알파벳 대문자 및 소문자를 포함하는 걸로 안내 문구를 변경하였습니다. (GeekNews 에서 받은 댓글 피드백 반영)

      • [GeekNews dogtree님] 그리고 회원가입할때 비밀번호 조건에 대문자 라고 써있어서 소문자는 포함 안시켜도 되는줄 알았는데 낚였네요 ㅋ 대소문자라고 쓰셔야할듯

    2024:05:26 21:45:01 / / written by 시리니

GeekNews에서 받은 질문들에 대한 답변 공유

2024:05:21 14:45:33 / / written by 시리니

안녕하세요! TSBOARD 개발자 시리니입니다.


어젯밤에 TSBOARD v0.8.26 업데이트 후 처음으로 외부 사이트에 TSBOARD 홍보를 게시했습니다.

평소에 GeekNews (https://news.hada.io) 사이트에서 유용한 정보들도 많이 보고 해서 처음 홍보는 GeekNews로 정했는데

예상외로 따뜻한 관심과 응원의 댓글을 받아서 감동이었습니다…!


그 중에 첫 댓글에서 받은 질문 내용이 아무래도 다른 분들도 궁금해 하실 것 같아

아래에 다시 정리해서 공유드리고자 합니다.


GeekNews [Superwoou] 님:

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

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


저의 답변

안녕하세요! 댓글 남겨 주셔서 감사합니다. (사실 무관심 속에 뭍힐 거라 생각했는데 감동입니다)


질문해주신 내용들이 저도 고민을 굉장히 많이 했었는데, 그냥 이런 생각도 있구나 하고 봐주시면 좋겠습니다.
아, 참고로 저는 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가 좀 더 많이 활용된다면 언제든지 제 생각을 바꿔서 다른 시도를 해볼 수 도 있겠습니다. ㅎㅎ

웹 생태계에는 이미 그누보드나 XE(라이믹스) 같은 훌륭한 게시판 엔진들이 존재하고,

각 엔진마다 선택한 전략이 비슷한 것도 있고 다른 것도 있을 겁니다.


TSBOARD는 그런 선택에 있어서 조금 뭐랄까요, 좀 더 극한의 케이스를 고려해서 만들고 있다고 생각해주시면 좋겠습니다.

서버의 부담을 줄이고, 클라이언트에서 JS엔진이 좀 더 많은 일을 하도록 하면서 빠르게 동작하도록 했습니다.

또한 더 작은 서버에서 더 많은 트래픽을 소화해 내도록 하는데 집중했다고 봐주시면 좋겠습니다.


디자인 과정에서 선택한 전략이 어떤 경우에나 정답은 아닙니다.

만약 여러분들에게 필요한 전략이 제가 선택한 것과 조금 다르다면, 다른 언어/엔진을 선택하시는 것이 당연히 더 좋습니다.

혹은 TSBOARD를 포크해서 본인의 입맛에 맞게 수정하여 쓰셔도 좋구요!


이번에 GeekNews를 통해서나 혹은 다른 경로로 TSBOARD를 접하신 분들께

언젠가 필요해질 그 날을 기다리며 계속해서 더 개선해 나가도록 하겠습니다. :D


감사합니다!

  • geeknews
  • 홍보
  • tsboard
  • 소개
  • 댓글
  • 문답
  • 인용
  • 그누보드
  • xe
  • 라이믹스
  • 추가로 비회원 기능 지원과 관련된 문의가 있었습니다. 아래에 좀 더 정리해서 답글을 남겨놓고자 합니다.


    TSBOARD는 현재 구조상 사용자가 회원 가입을 해야만 제대로 사용할 수 있도록 되어 있습니다.

    물론 비회원도 게시글을 읽거나 목록을 보거나 혹은 사진을 구경하는 정도는 가능합니다만,

    TSBOARD가 제공하는 게시판마다의 레벨 및 포인트 설정에 따라 비회원의 경우 해당 작업이 안될 수도 있습니다.


    글작성의 경우는 현재 구조상 더더욱 비회원이 하기 어렵도록 되어 있는데, 설계상의 단순함을 유지하려면

    어쩔 수 없는 선택이었습니다. 예외 케이스가 많아지는만큼 고려되어야 할 부분들이 많은데,

    한정된 개발 리소스를 고려하지 않을 수 없었습니다. TSBOARD가 내부적으로 회원 번호 기반으로 의존하는 부분들이

    적지 않기 때문에, 앞으로도 비회원에 대한 글쓰기나 포인트/레벨 제한이 걸린 게시글 열람 등은 어려울 것으로 예상합니다.

    (v2.0.0 에서는 근본적으로 가능한 방안을 좀 더 고려해 보겠습니다)


    대신 회원가입을 아무리 단순화해도 번거롭기 때문에, 소셜 로그인 기능을 처음부터 고민했었고

    현재 나름 성공적으로 반영된 것 같습니다. 게시글을 남기거나 사진을 올리고 싶을 땐 소셜 로그인으로 보다 편하게

    해당 작업을 하실 수 있습니다. 장기적으로는 커뮤니티라는 것이 회원들이 더 많이 활동하도록 유도하는 게

    중요하다고 생각하고 있어서, 비회원 관련 기능들은 앞으로 한동안 반영되지 않게 되는 점 미리 양해를 부탁드립니다!


    TSBOARD는 빠르게 동작해야 한다는 제 나름의 목표 아래 여러 디자인적인 선택을 했었습니다. (비회원 기능 포함)

    앞으로도 이런 얘기들은 많이 나누고 또 그 과정에서 대안을 발견할 수 있길 희망해 봅니다. ㅎㅎ

    2024:05:22 18:49:45 / / written by 시리니

TSBOARD v0.8.26 업데이트 안내

2024:05:20 21:09:29 / / written by 시리니

안녕하세요 TSBOARD 개발자입니다.


v0.8.26 업데이트를 아래와 같이 안내드립니다!


  • 이제 업로드된 이미지 사진에 대해서 Vision AI 기능으로 어떤 사진이 올려졌는지 텍스트로도 함께 보여줍니다. 이는 갤러리 뿐만 아니라 게시판에서도 가능하며, 본 게시글의 첨부파일들에서도 확인 하실 수 있습니다. (사진 출처 : https://unsplash.com/ko)

    • 이 기능은 OpenAI의 API 키가 .env 파일에 등록되어 있을 때에만 동작합니다. (ChatGPT-4o 모델 사용)

    • 이 기능을 사용하기 위해서, bun update.ts 를 한 번 실행하여 DB 테이블을 하나 생성해야 합니다.

    • 이 기능은 필수 기능이 아닙니다, 사용을 원하지 않을 경우 .env 파일에 키 값을 등록하지 않으시면 됩니다. (하지만 update.ts 는 한 번 실행해주세요!)

    • .env 파일에 추가해야 하는 OpenAI API 키 값은 아래와 같은 형태를 가집니다.

OPENAI_API_KEY=thi-s-is-an-examPlE-aPi-kEy-VaLuE_Of-opEN-Ai
  • 게시글 작성 시 키보드의 방향키 동작이 제대로 안되던 문제를 수정하였습니다. (마침내!)

  • 게시글 작성 시 잠시만 기다려달라는 메시지가 (선택하신 언어에 맞춰) 나타납니다. 모바일 기기에서 사용자에게 좀 더 분명한 피드백을 제공해 줍니다. 또한 작성 완료 버튼을 누른 경우 로딩 화면에 나타나면서 글작성 버튼도 비활성화 됩니다.


이 밖에 다양한 버그들을 수정하였고, v1.0.0 버전 달성을 위한 밑작업들을 진행중입니다.


v0.9.x 버전에서는 게시판과 갤러리에 이어서 블로그 기능을 본격적으로 추가할 예정입니다.

먼저 게시판과 갤러리 기능들이 충분히 사용성 있고 안정화 될 때까지 계속 작업하면서,

블로그 기능에 대해 천천히 고민해보고 기능 추가를 시작하도록 하겠습니다.


감사합니다!

  • tsboard
  • 업데이트
  • vision
  • openai
  • chatgpt4o
  • 블로그

TSBOARD v0.8.24 업데이트 안내!

2024:05:11 15:59:10 / / written by 시리니

안녕하세요 TSBOARD 만들고 있는 개발자입니다.


아래에 주요 업데이트 내용들을 소개 드립니다!


  • 이제 구글에 이어 네이버와 카카오 계정으로 로그인하기 기능이 추가되었습니다. 기존에 계정이 없으셨던 분들은 로그인과 동시에 회원 가입이 완료되고 별도의 비밀번호 등록 과정 없이 바로 로그인 됩니다. 원하실 경우 내정보 화면에서 비밀번호를 수정하여 다음부터는 소셜 로그인을 해도 되고, 직접 로그인을 하셔도 됩니다.

    • TSBOARD는 OAuth 로그인 기능 구현만 되어 있고, 여러분들이 이 기능을 사용하시려면 각 서비스 제공자들이 요구하는 등록 절차를 따르고 client_id / client_secret 등의 코드도 받으셔야 합니다.

    • client_id / client_secret 정보는 TSBOARD의 .env 파일을 열어보시면 입력하는 란이 나옵니다.

  • 게시판에서 게시글 목록이 제대로 출력 안되는 케이스가 발견되어 수정되었습니다. 공지 사항 개수에 따라 최신 글이 안나오던 문제가 있었는데 수정이 되었고, 이전/다음 왔다갔다 하다가 목록 버튼을 클릭할 경우 (이전 클릭 후 목록 클릭 케이스) 게시글이 나오지 않던 문제도 수정되었습니다.

  • 게시판에서 이제 첨부파일로 이미지를 선택하신 경우, 글보기 화면에서 작은 썸네일이 함께 표시되어 어떤 내용인지 확인해 볼 수 있습니다. 게시글 보기에서는 한 줄에 최대 4개의 썸네일 이미지가 출력되고, 그 이상의 파일들이 올려질 경우 4 x n 배열로 출력이 됩니다.


이 밖에 안정화를 위한 자잘한 업데이트를 반영해 놓았습니다.

이제 진짜 어디든 홍보를 좀 해보긴 해야 할 것 같네요! 😆

  • tsboard
  • 업데이트
  • 소셜로그인
  • naver
  • kakao

TSBOARD v0.8.22 업데이트!

2024:05:05 00:28:15 / / written by 시리니

TSBOARD v0.8.22 업데이트 소식을 아래와 같이 전해드립니다!


  • 이제 갤러리에 올려진 사진들 중에서 EXIF 정보가 포함된 사진은 자동으로 EXIF 정보를 추출하여 저장합니다. 사용자는 갤러리의 뷰어 다이얼로그에서 글제목 우측의 EXIF 버튼을 통해 해당 내용을 확인 하실 수 있습니다.

  • 게시판과 갤러리를 오갈 때 게시판 글보기에서 갤러리 글쓰기로 갈 경우 게시판 설정을 제대로 가져오지 못하는 문제를 수정하였습니다. 이제 게시판 상단의 게시판 이름과 설명이 제대로 출력됩니다.

  • 스마트폰에서 접속할 때 홈화면과 게시판 / 갤러리 목록보기 화면 우측 하단에 퀵 버튼이 생성됩니다. 이 버튼은 각각 게시판 글쓰기와 갤러리 사진 업로드를 바로 할 수 있는 버튼을 제공하며, 해당 버튼 설정은 tsboard.config.ts 파일에서 QUICK_BUTTONS 객체를 참조하시면 됩니다.

  • 홈화면에서 포스트의 댓글 숫자도 함께 표기되도록 수정하였습니다. 더불어 여백 부분을 조금 더 조정했습니다.

  • 이제 글작성 시 링크 삽입이 제대로 동작합니다. https://tsboard.dev/ 복붙하시면 링크가 바로 생성됩니다.


이 밖에 자잘한 버그들이 수정되었고, Bun v1.1.7 버전에 맞춰 테스트 되었습니다.

기존 버전을 사용하신 분들은 아마 없으시겠지만...? 혹시 있으시다면 bun update.ts 를 한 번 실행하셔서

exif 테이블을 새로 생성해주셔야 합니다!


아직 갈 길이 멀지만 조금씩 꾸준히 개선해 나가겠습니다!


감사합니다.

  • tsboard
  • 업데이트
  • exif
  • 퀵버튼

EXIF 정보 보기가 이제 가능해졌습니다.

2024:05:05 00:15:29 / / written by 시리니

TSBOARD v0.8.22부터 EXIF 정보를 확인하실 수 있습니다.

혹시 후보정 등을 하시다가, 혹은 앱에서 편집을 하고나서 EXIF 정보가 유실되는 경우도 있는데, 이 때는 확인할 수 있는 버튼이 나타나지 않습니다.

이 사진은 우측 상단의 글제목 옆에 EXIF 버튼을 클릭하시면 정보를 보실 수 있습니다!

  • exif
  • 테스트