SIRINI`s Blog

요즘 문득 드는 (쓸데없는) 고민이 하나 있는데, 바로 고성능 백엔드 입니다.물론 지금 신세지고 있는 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 언어와 친해져서 이것 저것 재미난 것들 만들어보고 싶네요.

저는 코딩을 PHP부터 시작했고, 스크립트 언어 위주로 사용하다가 시간이 조금 지나서 이제는 화석이 되어버린 MFC를 써야하는 시점에 C++ 언어를 제대로 접하게 되었습니다. 학부 시절에 로우 레벨 언어로 사용했던 C언어와 간혹 같이 붙여서 C/C++ 로 표현하기도 했었지만, C++의 뜨거운 맛을 맛본 뒤로는 C언어와 동일 선상에서 부르는 건 그만두게 되었지요.C++언어는 정말 경이로운 언어입니다. 만들어질 당시 컴퓨팅 파워는 지금의 라즈베리파이보다 못한 수준이었을테고, 그럼에도 최적화된 성능을 이끌어내기 위해서 컴파일러나 언어 사용자나 많은 고생을 해야만 했을 겁니다. C언어 수준의 속도를 보장하면서도 여러 패러다임들을 받아들이기 위해 마개조스러운 변화가 반영되었고, 그럼에도 예전 코드가 최신 컴파일러에서 제대로 동작하도록 하위 호환성에도 미친듯한 신경을 썼습니다. 과거의 유산을 포기하지 않으면서 여전히 미래로 도전하는 이 언어는 감히 평해보자면, SW업계에 공기와도 같은 존재로서 어디서나 만날 수 있는 언어라 말할 수 있겠습니다.C++언어의 창시자와 다른 구루들이 남긴 말을 살펴보면, 이 언어의 진가를 알 수 있습니다.50년간 연구를 했다. 결국 C++인가? (Richard A. O’Keefe, Functional Programming 연구에 힘쓰는 컴퓨터 과학자)C,C++을 쓰는 건 안전가드를 제거한 전기톱을 쓰는 것과 같다. (Bob Gray)C++ 에서는 스스로 발을 쏘는 행위는 거의 일어나지 않는다. 하지만 그런 일이 일어난다면 다리 전체가 날아가 버릴 거다. (Bjarne Stroustrup, C++언어의 창시자)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++언어를 만나게 되는 순간이 있을 겁니다. 그 때 부디 유쾌한 재회가 될 수 있기를 기원합니다. 저도 이제는 다리 전체를 날려버리는 멍청한 짓은 이제 그만둘 수 있기를 바래봅니다.

예전에 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 언어로 백엔드를 다시 만들어야 하나… 🧐)

야심한 시각에 코딩하다가 문득 짧게라도 기록해두고 싶은 이야기가 있어서 이곳에 왔습니다.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 업데이트를 조금씩 진행하고 있습니다.이번에는 이것 저것 자잘한 부분들, 그동안 바빠서 신경을 못썼던 부분들 먼저 소소하게 챙기고대부분의 사용자에겐 필요 없지만 저에겐 필요한 데이터 전달용 라우터도 추가하였습니다.저의 경우 물리적으로 분리된 서버 간에 데이터를 주기적으로 동기화해야 할 필요가 가끔 있었습니다.원래는 정식 코드에 반영하지 않고 따로 분리해서 작성했습니다만, 계속 이런 식으로 코드를 파편화 시키면나중에 제가 감당이 되지 않을 것 같아서 이번부터 반영을 하였습니다.(일반적인 사용자는 해당 기능을 신경 쓰실 필요가 없습니다. 😃)TSBOARD라고 이름 짓지 말고 TSBLOG라고 할 걸 그랬나? 싶을 정도로 사실 지금의 블로그 형태가저 스스로는 꽤나 마음에 듭니다. ㅎㅎ 디자인이 비록 너무 심플하기도 하고, 아직 워드프레스에비벼볼 깜냥은 아닙니다만, 그럼에도 직접 개발한 도구를 이용해서 글을 작성하는 즐거움이 있습니다.가장 보람되는 것은, 처음 TSBOARD를 개발할 때 생각했던 컴포넌트 재활용 전략이 잘 먹혔다는 점입니다. 개발 기간을 줄이면서도 효과적으로 필요한 기능들을 추가하고, 검증하려면할 수 있는 한 컴포넌트들의 재활용 비율을 높여야 합니다.하다못해 디자인을 하더라도 서로 비슷하게 구성을 해야 필요할 때 쉽게 가져다 쓰거나 조금만 바꿔서 익숙한 듯 새로운 느낌을 줄 수 있었습니다.그래서 처음 개발할 때 우선 게시판과 갤러리만 집중해서 개발을 했었고, v0.8.z 버전대를 지나오면서충분히 기반이 단단해 질 때까지 반년 이상 시간을 쏟아부었습니다. 그 덕분에 사실 블로그는 예상 외로굉장히 빠르게 틀을 잡아서 만들 수 있게 되었네요. 😋디자인 관점에서는 여전히 아쉬운 점도 많고, 무엇보다 커스텀 테마까지 제공할 여력이 안되는 점이 제일 아쉽습니다만천천히 이것 저것 궁리해 나가면서 하나하나 개선해 보려고 합니다.게시판, 갤러리 그리고 블로그까지… TSBOARD의 도전은 계속 됩니다!

안녕하세요! TSBOARD 개발하고 있는 시리니 입니다.아직 오피셜하게 업데이트 공지를 드리지는 못했습니다만, 기본적인 블로그 작업은 마무리되어서우선 제 블로그부터 하나 만들어 보았습니다. ㅎㅎ사실 이름을 TSBOARD 라고 짓기는 했습니다만, 저는 제가 만든 블로그를 운영해 보는 게 목표였는데이제 한걸음 다가간 셈입니다. 공식 업데이트 소식에서 좀 더 자세한 내용을 설명드리겠지만,아래에 간략히 블로그 작업하면서 신경썼거나 의도한 부분들 먼저 소개 드리겠습니다!TSBOARD의 블로그는 기본적으로 어두운 테마 기준으로 작업되었습니다. 이는 게시판이나 갤러리와 구분되도록 의도한 것으로, 블로그라는 게 게시판과 달리 보통은 한명 내지는 소수의 인원만 사용하는 게 일반적이라서 좀 더 개인적인(?) 느낌을 드러내고자 색상을 다르게 가져갔습니다.블로그는 TSBOARD 게시판 설정에서 게시판 관리자로 지정된 사람만 사용할 수 있도록 할 생각입니다. 만약 TSBOARD로 10명에게 각각 블로그를 만들어주려면 10개의 게시판을 생성해야 합니다. 블로그에 작성된 글은 홈 화면의 최근 게시글에서도 그대로 만나 보실 수 있습니다. 그러고보니 홈 화면의 게시글들을 지금은 최신 순으로만 볼 수 있는데 앞으로는 특정 기간 동안의 좋아요나 조회수 기준으로 정렬하는 것도 구현할 예정입니다. 이제 첫 삽을 퍼올린 셈이라, 여기 저기 손봐야 할 부분들이 많습니다.어느 정도 정리가 되면 TSBOARD v0.9.0 업데이트 소식으로 공유 드릴께요!블로그 한 번 씩 봐주시고 어떠신지 의견들도 많이 부탁드립니다 😆