SIRINI`s Blog

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 개발하면 어떨까 하는 상상도 해보았습니다. ㅎㅎ

요즘 문득 드는 (쓸데없는) 고민이 하나 있는데, 바로 고성능 백엔드 입니다.물론 지금 신세지고 있는 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 업데이트 소식으로 공유 드릴께요!블로그 한 번 씩 봐주시고 어떠신지 의견들도 많이 부탁드립니다 😆