TSBOARD를 만들면서, 언젠가 커뮤니티 사이트에 걸맞는 앱도 하나쯤 있으면 좋겠다는 생각을 종종 했었습니다. 그리고 몇 달간의 학습 겸 개발을 진행하고서 마침내 구글 플레이 스토어에 앱을 출시 하였습니다. 앱도, TSBOARD의 여정도 이제 시작이라는 느낌입니다만, 그럼에도 이 정도에서 한 번쯤은 후기를 한 번 남겨보는 것도 좋을 것 같아 끄적여 봅니다.

구글 개발자 신원 확인

앱 출시에 있어서 가장 큰 난관은 앱의 산적했던 버그들이 아니라, 바로 저에 대한 신원 확인이었습니다. 저의 경우 아주 오래전에 구글 개발자로 등록한 이력이 있었으나, 거의 등록만 해두고 별다른 활동을 하지 않았었기 때문에 중간에 있었던 강화된 신원 확인 절차를 진행 하지 않았습니다. 그러다보니 이 신원 확인 절차가 정말로 생소했습니다.

개발자 신원 확인을 위해서는 개발자의 이름과 주소가 명시된 공문서를 pdf 형태로 등록해야 합니다. 가이드를 보면 고지서 같은거나 정부에서 발행한 지로 영수증 같은 걸 사진으로 찍어서 PDF 변환 후 업로드하면 되는 것처럼 나와 있는데, 문제는 사진의 경우 글씨가 또렷해야하고, 문서의 꼭지점 부분이 명확하게 나와야 하며, 결정적으로 1MB를 넘어선 안된다는 것입니다. 제가 집으로 날아온 고지서 여러 장을 사진으로 찍고 다시 줄여서 PDF로 만들어 보았습니다만, 대부분 1MB는 훌쩍 넘었고, 그마저도 크기를 억지로 맞출 경우 글씨가 굉장히 흐릿하게 나타나는 문제가 있었습니다.

구글같은 기업에서 문서들을 일일히 사람 눈으로 확인하거나 하진 않을테니, 당연히 기계가 문서를 판독할텐데 안타깝게도 성능이 그리 좋지 못한 것 같더라구요. 한 3번 정도 반려를 먹었습니다. 한 번은 집 주소가 나오지 않은 고지서라서, 또 한 번은 문서가 너무 흐릿해서, 마지막으로는 둘 다 해당되어 반려되었던 것 같습니다. 정말 이 때는 엄청 빡치긴 하더라구요. 사실 가장 큰 불만은, 구글에 제가 유튜브 프리미엄이나 구글 포토 등으로 내는 돈이 있을텐데 그건 그거고 개발자 신원은 상관없이 까다롭게 확인하는 것이었습니다.

마지막으로 시도했던 것이 은행 앱을 통해서 발급받은 원천징수 영수증이었습니다. 해당 영수증을 살펴보니, 제 이름과 주소가 명확하게 나와 있었고, 나름 은행에서 발급했다는 인장 같은 것도 있는데다 결정적으로 이 문서는 사진을 찍을 필요 없이 바로 PDF로 업로드가 가능했습니다. 물론 1MB 이하의 크기로 업로드 규격도 만족합니다. 이 문서를 업로드하면서 비로소 개발자 신원 확인을 받을 수 있었습니다. 통상 신원 확인에 성공하든 실패하든 업로드 시점으로부터 하루 정도 소요되었던 것 같은데, 이걸 4번 정도 하다보니까 이러다가 플레이 스토어에 출시도 못해보고 끝나는 거 아닌가 하는 걱정도 사실 많이 했었습니다.

구글 계정으로 로그인

앱을 개발하다보니 웹에서 이미 구현했던 OAuth2 로그인 기능도 약간 새로운 부분이 있었습니다. 안드로이드 앱을 처음 만들어서 저만 조금 어려웠던 것일지도 모르겠습니다. 구글 계정으로 로그인을 구현하려면, 구글 개발자 콘솔에서 사용자 인증 부분에 안드로이드 앱에 등록되어 있는 SHA-1 디지털 지문을 등록해줘야 합니다. 이 SHA-1 코드는 안드로이드 스튜디오나 콘솔에서 keytool 도구를 이용하여 쉽게 만들 수 있습니다.

처음에는 당연히 디버그 모드로 테스트를 해야 하니까, 구글 개발자 콘솔에 Debug 모드에서 생성한 SHA-1 디지털 지문만 등록했었습니다. 그러면서 한참동안 디버그 모드로만 개발을 진행하다보니, 정작 출시 시점에서는 Release 모드에서 생성한 SHA-1 디지털 지문 등록을 까먹은 겁니다. 그래서 당연히 릴리즈 모드에서는 구글 로그인을 시도하면 NoCredentialException 예외가 발생하고, 하필 제가 그 때 예외 처리를 제대로 안해둬서 앱이 강제로 종료되는 문제가 생겼었습니다. 다행히 원인을 빨리 파악해서 부랴부랴 Release 모드에서 SHA-1 지문을 다시 구글 개발자 콘솔에 추가로 등록하고, 문제를 해결했다고 생각했습니다.

그러나 생각지도 못하게, 구글 플레이 스토어에 등록한 앱을 내려 받고서 다시 테스트를 해보니 이번에는 예외 처리가 되어서 죽진 않았지만 여전히 로그인에 실패하는 겁니다. 이 때 살짝 멘붕이 왔었습니다. 아니, 분명히 Debug 도 Release도 모두 SHA-1 디지털 지문을 구글 개발자 콘솔에 등록했는데? 혹시 Debug 모드는 지우고 하나만 남겨뒀어야 하나? 별에 별 생각을 다 하다가, 뒤늦게 구글 플레이 스토어가 앱에 또 다른 SHA-1 디지털 지문을 이식한다는 걸 알게 되었습니다. 그러니까, 구글 개발자 콘솔에 사용자 인증 부분에서 제가 등록해둬야 하는 디지털 지문이 총 3개가 되는 겁니다. Debug, Release 그리고 구글 플레이 스토어에서 생성한 SHA-1 지문까지.

구글 개발자 콘솔 말고, 구글 플레이 콘솔에 들어가면 테스트 및 출시 > 설정 > 앱 서명 부분에서 SHA-1 디지털 지문을 만날 수 있었습니다. 이걸 다시 구글 개발자 콘솔에 또 등록을 해줬어야 했던 겁니다. 처음 하다보니 구글 계정으로 로그인 같은 간단한 기능도 사실 좀 어려웠습니다. 다행히 지금은 잘 동작합니다만, 그냥 무작정 이것 저것 하다보니 이런 시행착오가 많았습니다.

라이브러리 호환성 맞추기

TSBOARD 프로젝트를 처음 시작할 때 조금 어려웠던 게 NPM을 통한 라이브러리들 내려받기 였습니다. 왜냐면 생각보다 너무 많은 라이브러리들을 받아야 하는데다 가끔씩 버전 호환성 이슈를 만나면 해결이 난감했기 때문입니다. 다행히 NPM도 발전하고, 저도 내성이 생기면서부터는 프론트엔드나 백엔드 프로젝트 모두에서 큰 어려움 없이 개발을 할 수 있었습니다.

하지만 안드로이드 앱의 경우는, 뭔가 차원이 다른 어려움이 있었습니다. 일단 제가 모르는 걸지도 모르겠지만, 필요한 라이브러리들을 버전까지 명시해서 build.gradle.kts 파일에 기록해야 했습니다. 만약 제가 명시한 Android SDK 버전에서 지원이 안되면, 다시 라이브러리의 버전을 내리면서 어떤 버전을 써야 하는지 직접 찾아야 하는 문제가 있었습니다. NPM이 정말 혁신적인 패키지 매니저였구나, 하고 느끼면서도 왜 안드로이드에서는 저런 게 없지? 하는 생각도 많이 들었습니다.

또 까다로운 문제라고 하면, 생각보다 Deprecated가 빨리 된다는 점입니다. Material 3 컴포즈 관련 라이브러리들은 메소드 이름부터 사용법까지 꽤나 드라마틱하게 변경되고 있었습니다. 물론 Deprecated된 메소드들은 대체제를 IDE에서 문서로 쉽게 확인할 수 있기 때문에 사실 너무 어렵다거나 한 건 아니지만, 그래도 처음 앱을 만들어보는 입장에서는 여간 까다로운 게 아니었습니다. 라이브러리들의 버전을 함부로 올리지 말라는 조언이 왜 나온 것인지 알 수 있었네요.

웹과는 다른 UX

앱을 만들면서, 구글이 제공하는 Material Design에 대해서 좀 더 내용을 확인해보고, 권장하는 UX가 어떤 것인지를 되새기면서 작업을 하고자 했습니다. TSBOARD는 물론 모바일 브라우저에서도 스크린 크기에 맞춰 화면을 훌륭하게 구성해서 보여주긴 하지만, 아무래도 손가락으로 터치한다는 개념 보다는 마우스 포인터로 클릭한다는 개념이 좀 더 녹아져 있는 디자인이었습니다. 그래서 이왕 안드로이드 앱을 만드는 거라면, 좀 더 터치에 적합한 UI로 구성해야겠다는 생각을 했었습니다.

그러면서 https://material-foundation.github.io/material-theme-builder/ 이 사이트에서 컬러 셋부터 시작해서 디자인 구성까지 많은 걸 참조했습니다. Material Design에서 제공하는 기본적인 요소들과 컬러들만 가지고도 이처럼 훌륭하게 디자인을 할 수 있다면, 굳이 웹에서 했던 디자인을 답습할 필요 없이 처음부터 다시 고민해서 만들어 보는 것도 나쁘진 않겠다는 확신을 가지고 앱을 디자인 했었습니다. 그 결과 좀 더 단순하고 정갈한, 아주 기본에 충실한 디자인으로 앱을 만들 수 있었습니다.

조금 아쉬운 건, 나름의 고민과 노력으로 어떻게든 해보긴 했습니다만 그럼에도 상용 앱들이 보여주는 훌륭한 UI와 사용자 친화적인 UX에는 아직 따라가지 못한다는 점입니다. 이 점은 훌륭한 UX로 손꼽히는 토스 앱 같은 걸 참조해서 저도 계속 개선해야 하겠습니다.

끝이 아닌 시작, 조금씩 그러나 꾸준히

TSBOARD도 마찬가지입니다만, 이번 안드로이드 앱 역시도 조금씩 하지만 꾸준히 기능들을 개선하고 UX를 다듬어 나가고자 합니다. 사용자가 많진 않지만, 어쨌든 제가 즐겁게 쓰고 있으니 제가 편하게 쓰기 위해서라도 점진적으로 개선해 보고자 합니다. 처음부터 잘 할 수는 없으니, 꾸준히 노력해서 개선하는 것이라도 해봐야겠지요.

https://play.google.com/store/apps/details?id=me.sensta

구글 플레이 스토어에서 Sensta를 검색하시면 카메라를 앞에 둔 다람쥐를 만나 보실 수 있습니다. 우여곡절이 많은 앱입니다만, 안드로이드 스마트폰을 쓰시고 사진 좋아하신다면 한 번 사용해 보시고, 의견도 부탁드립니다.

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

TSBOARD 기반으로 만들어진 커뮤니티를 위한 안드로이드 전용 앱, SENSTA의 공개가 이제 코 앞으로 다가왔습니다.

Kotlin 언어와 함께한 시간들을 마무리하면서, 앱에서 필요했던 기능들과 앱에 이미 구현된 기능들을 이번 업데이트에서

아래와 같이 반영해 보았습니다.

[Backend - GOAPI]

• 안드로이드 네이티브 앱 SENSTA 와의 원할한 연동을 위해 아래 사항들이 반영되었습니다.

  • id_token 값을 받으면 구글 OAuth2 API로 인증 후 사용자 정보를 JSON 형태로 바로 반환하도록 추가하였습니다.

  • 채팅 메시지를 저장할 때 가끔 처리되지 않던 nil pointer exception 문제를 수정하였습니다.

  • 앱에서 사용자 정보를 요청할 때 사용자 고유 번호를 생략하던 문제를 수정하였습니다.

• 삭제 처리된 댓글은 댓글 개수에 반영하지 않도록 수정하였습니다.

• 채팅 메시지를 받으면 중복 여부를 검사하지 않고, 매번 새 알림이 되도록 변경하였습니다.

• 최근 사용된 해시태그 목록을 조회하는 기능을 추가하였습니다.

• 작성자명, 분류명 검색 시 부분 문자열로 검색해도 되도록 개선하였습니다.

• 첨부 이미지에 대해서 AI가 설명한 내용으로 게시글을 검색하는 기능을 추가하였습니다.

  • 갤러리 게시판 좌측 하단의 검색에서도 이제 이미지 항목으로 검색이 가능합니다.

  • 홈화면 상단 전체 검색에서도 이미지로 검색이 가능합니다.

[Frontend - TSBOARD]

• 홈 화면에서 현재 로그인 상태일 경우 액세스 토큰을 갱신합니다.

• 구글 및 외부 CDN으로 사용하던 폰트들을 서버에서 직접 제공하는 방식으로 변경하였습니다.

  • 모든 폰트는 압축된 woff2 형식으로 제공됩니다.

  • Cal Sans, 0xProtoNerdFontMono, Pretendard 3종이 제공됩니다.

• 백엔드 변경사항에 맞춰 UI 부분도 개선 하였습니다.

• 사용중인 라이브러리들을 본 배포 시점에서 최신 버전으로 모두 업데이트 하였습니다.

  • npm install 실행이 필요합니다!

[Android - SENSTA]

• 안드로이드 네이티브 앱으로 곧 구글 플레이 스토어에 출시 예정인 SENSTA 는 아래와 같은 특징을 가지고 있습니다.

  • TSBOARD v1.0.5 이상으로 만들어진 사이트와 연동됩니다.

  • TSBOARD에서 만들어진 (갤러리) 게시판 하나를 앱에서 접근합니다. (일종의 커뮤니티 전용 인스타그램인 셈입니다)

  • SENSTA 앱을 여러분이 운영하시는 커뮤니티 사이트에 맞게 일부분 수정이 필요합니다.

    • data/src/main/java/me/data/env/Env.kt 파일을 열어서 아래 코드를 살펴보시고, 수정하시면 됩니다.

  package me.data.env
  
  object Env {
      const val TITLE = "SENSTA"                      // 앱 타이틀
      const val DOMAIN = "https://sensta.me"          // TSBOARD로 개발된 웹사이트 주소
      const val BOARD_ID = "photo"                    // Board ID on TSBOARD
      const val BOARD_UID = 2                         // Board UID on TSBOARD
      const val CATEGORY_UID = 5                      // 기본 카테고리 고유 번호, 게시판 설정에서 카테고리 안쓸 경우 무시됨
      const val MAX_UPLOAD_COUNT = 9                  // 한 번에 9장까지 업로드 가능
      const val MAX_UPLOAD_SIZE = 100L * 1024 * 1024  // 한 번에 최대 100MB까지 업로드 가능
  
      const val VERSION = "v1.0.0"
      const val MIN_TSBOARD_VER = "≥ v1.0.5"          // 이 앱은 운용중인 서버의 TSBOARD가 v1.0.5 이상이어야 동작합니다
      const val MIN_ANDROID_VER = "≥ 14"              // 안드로이드 14 (Samsung Galaxy S23 시리즈 이후) 이상 버전 필요
      const val GITHUB_URL = "https://github.com/sirini/sensta" // 이 앱의 전체 소스코드 GitHub 주소
  }

• SENSTA 앱의 소스코드를 GitHub에서 포크(fork)하신 후, 여러분의 사이트에 맞게 수정하셔서 별도의 전용 앱을 만들어보세요!

  • 앱을 제작하신 후에는 직접 구글 플레이 스토어에 심사를 거처 등록을 하셔야 합니다.

  • SENSTA 앱은 안드로이드 네이티브 앱으로, iOS 버전은 현재 없으며 개발에는 Kotlin 언어가 사용되었습니다.

  • 추후 TSBOARD가 업데이트 되면서 앱도 계속 개선될 예정이니, 가급적 변경점을 최소화 하시는 걸 권장합니다!

• TSBOARD가 이미 모바일 기기도 잘 지원하는데 왜 별도의 안드로이드 전용 앱을 만들었는지 궁금하신가요?

  • 제 블로그에 뒷얘기가 있습니다 : https://tsboard.dev/blog/sirini/66

  • TSBOARD 기반으로 직접 만들어서 운영중인 sensta.me 사이트 이용자분들을 위해 만들기 시작했습니다.

  • 만들다보니, 조금만 고치면 다른 TSBOARD 기반 커뮤니티에서도 유용하게 쓰일 것 같아 코드를 공개하였습니다.

TSBOARD는 이제 커뮤니티 사이트를 위한 종합선물세트가 되어가고 있습니다.

아직도 많이 알려지진 않았습니다만, 언젠가는 이 글을 보실 여러분들 혹은 다른 개발자분들에게 도움이 되리라 생각합니다. 😊

개인적으로는 TypeScript / Go / Kotlin과 같은 쓰기 좋은 언어들과 함께 시간을 보낼 수 있어 기쁩니다. (C++이 없어서 천만다행…?!)

마지막으로 TSBOARD v1.0.5 태그 페이지 링크로 마무리 하겠습니다!

👉 https://github.com/sirini/tsboard/releases/tag/v1.0.5

요즘 저는 안드로이드 앱 개발에 빠져 있습니다. TSBOARD로 개발하여 운영중인 저의 첫 커뮤니티, sensta.me 사이트 사용자분들을 위한 안드로이드 전용 앱을 만들고 있는데, 정말 재밌습니다. TSBOARD를 만들면서 접했던 여러 개념들이 비슷하게 등장하는 것도 신기했는데, 타입스크립트와 Go 언어에 이어서 코틀린 언어의 매력에 허우적거리는 제 모습이 낯설기도 하고 신기하기도 합니다. 그 중에서도 안드로이드의 클린 아키텍처는 정말 배울만하다는 생각이 들었습니다.

안드로이드 클린 아키텍처

안드로이드는 공식 아키텍처로 클린 아키텍처를 소개하고 있습니다. Presentation / Domain / Data 이렇게 크게는 3개로 모듈을 나눠서, 각각의 역할을 분리하는 것이 핵심입니다. 처음에는 별로 크지도 않은 앱을 만드는데 무슨 모듈을 3개씩이나 만들지? 라고 생각하고 그냥 하나의 모듈에서 개발을 했습니다만, sensta.me 앱을 만들면서 그게 아니라는 걸 금방 깨달았습니다.

저에게 있어 모듈을 나누는 가장 큰 이유라고 한다면, 약간 이상할 수 있는데 파일이 많아서라고 답하고 싶습니다. Presentation 모듈이 UI와 ViewModel 부분을 담당하고 있는데, 여기도 Jetpack Compose기반으로 앱을 만들다보면 목적에 따라서 여러 컴포저블 함수들이 생성되고, 대부분은 별도의 파일에 속하게 됩니다. 당연히 파일도 엄청 많아지고 덩달아서 파일들을 패키지로 묶어야 하니 패키지도 많아지게 됩니다. 충분히 하나의 독립된 모듈로 빼둘만 하더라구요.

Domain 모듈의 경우 설계상 순수 코틀린 언어로만 작성이 필요합니다. 안드로이드 코드가 있어선 안되고, 원칙적으로는 외부 라이브러리에 의존하지 않습니다. 이곳에서는 리포지토리의 인터페이스들을 정의하고, 모델들을 정의합니다. 그리고 UseCase라고 부르는 것들을 작성하는데, 하나의 UseCase를 보통 하나의 파일에 저장하니까 이 역시도 파일이 많아질 수 밖에 없습니다. 여러 모델들과 리포지토리 인터페이스, 그리고 ViewModel에서 기능 호출할 때 사용하는 UseCase까지 파일이 많아지니까 자연스럽게 이걸 하나의 독립된 모듈로 구성하는 게 낫겠다는 생각이 들더군요.

Data 모듈은 실질적으로 데이터 입출력과 관련된 일들을 하는 곳이고, Domain 모듈에서 정의해둔 리포지토리 인터페이스들을 구현하는 곳이니만큼 당연히 파일들이 많아집니다. 특히 저의 경우는 앱 자체가 외부 서버에서 JSON 타입의 데이터를 가져와야 하다보니 JSON 타입과 매칭되는 DTO를 여기서 정의해 두었습니다. DTO가 거의 대부분 모델과 일대일 매칭이 되므로 역시 파일이 많아집니다. 결국 독립된 모듈로 구성하는 것이 정답이었다고 할 수 있습니다.

마법같은 Coroutine

안드로이드 앱은 사용자에게 보여지는 UI가 있고, 해당 UI에서 특정 버튼이나 행위(예: 스크롤)를 했을 때 그에 맞춰 동작이 일어나야 합니다. 때로는 시간이 소요되기도 하겠죠. 그러나 어떠한 경우에도 사용자의 UI는 멈춰선 안됩니다. 버튼을 터치했을 때 날씨를 가져와서 보여준다고 가정하면, 날씨 데이터는 결국 인터넷 망을 통해서 가져와야하니 시간이 걸리게 됩니다. 가령 5초가 걸렸다고 합시다. 이 때 안드로이드 앱의 화면 여기저기를 터치하거나 했을때 먹통이 되어버린다면 어떨까요? 당연히 해당 앱은 쓸 수 없는 앱이 됩니다.

이걸 막기 위해서 코틀린은 코루틴(Coroutine)을 지원하고 있습니다. 이게 참 신기하게도, TSBOARD를 개발하면서 백엔드를 Go언어로 재작성 할 때 이미 고루틴(Goroutine)을 맛본 상태라 다행히 개념이 어렵진 않았습니다. 고루틴이 언어 자체적으로 지원하는 기능이라는 점과 사용이 훨씬 쉽다는 점을 제외하면, 코틀린 언어의 코루틴도 정말 훌륭한 동시성 구현이라고 생각합니다.

안드로이드 앱 개발을 할 때는, UI에서 특정 버튼이 터치되었다고 가정해보면, 해당 버튼의 onClick 이벤트 리스너에서는 ViewModel의 특정 함수를 호출하고, 해당 함수는 내부적으로 viewModelScope.launch { … } 블럭을 실행하면서 그 블럭 안에서 UseCase를 호출하도록 보통 구현한다고 합니다. 저도 조금 생소하긴 했었는데, 몇번 하다보니 금새 익숙해 졌습니다.

    // 개별 알림 확인 처리하기
    fun checkNotification(notiUid: Int) {
        viewModelScope.launch {
            val user = getUserInfo()
            if (user.token.isEmpty()) {
                return@launch
            }

            checkNotificationUseCase(user.token, notiUid).collect {
                if (it is TsboardResponse.Success) {
                    loadNotifications()
                }
            }
        }
    }

viewModelScope.launch 블럭은 코루틴 영역이고, 기존 코드 흐름과는 별도의 영역에서 실행됩니다. 그리고 그 안에서 호출되는 UseCase는 보통 Flow를 반환하는데, collect 함수가 호출되면 그 때 emit 함수로 필요한 데이터를 가져옵니다. 저는 이 과정이 정말 굉장하다고 생각했는데, 일반적으로 Blocking을 하면서 데이터 받는 걸 기다리는 게 아니라, Non Blocking으로 메인 스레드를 막지 않으면서도 데이터를 가져오는 이 흐름이 정말 낯설면서도 한편으로는 익숙하다는 느낌을 받았습니다. TSBOARD를 처음 만들때 Node.js의 비동기 I/O 개념을 배운 게 여기서도 도움이 되더라구요.

Node.js의 혁신적이었던 비동기 I/O 동작과 콜백 기반의 처리, 그리고 Promise를 통해서 해소된 콜백 지옥… 이 배움들이 코틀린 언어의 코루틴을 사용하면서도 그대로 적용되었습니다. 코루틴에서도 새로운 코루틴 영역을 만들어주는 async {…} 블럭이 있고, await 함수를 통해서 비동기적으로 동작하는 함수들의 실행 결과를 기다렸다가 받아서 처리할 수도 있었습니다. 타입스크립트와 Node.js 그리고 Bun과 함께했던 시간들이, Go언어와의 시간들이 헛되지 않고 계속해서 새로운 배움의 마중물이 되어준 것입니다.

만족스러운 네이티브 앱의 성능

안드로이드 앱 개발을 즐겁게 만들어주는 가장 마지막 요소라고 한다면, 단연 네이티브 앱이 보여주는 성능이 아닐까 싶습니다. 물론 Flutter와 같은 크로스 플랫폼 개발 프레임워크가 여러 장점들이 있다는 것을 잘 알고 있습니다. Dart 언어 역시 훌륭하고, 지금 생각해보니 Flutter의 선언형 UI 개념들이 Jetpack Compose에서도 자연스럽게 이어지는 것 같다는 생각이 들었습니다.

그러나, 크로스 플랫폼을 위해 별도의 UI 엔진을 불러와야하고, 코틀린이 아닌 Dart 언어로 개발해야 한다는 점 등이 조금 걸렸습니다. Dart 언어는 물론 훌륭한 언어이고, 한 때 자바스크립트를 대체하기 위해 야심차게 소개된 것도 알지만 현실적으로 Flutter외에는 잘 안쓰이는 언어이다보니 배우고 싶다는 동기부여가 잘 안되었다는 점도 말씀드리고 싶습니다. 초기 로드 외에도 네이티브 앱이 조금이라도 더 빠릿하게 반응하고 더 부드럽게 애니메이션을 해주며 더 빠르게 데이터를 처리하지 않을까 하는 믿음도 있습니다. ㅎㅎ

그런 관점에서, React Native는 애초에 고민하지도 않았습니다. 웹 기반 기술은 브라우저가 가장 적합한 플랫폼이라고 생각합니다. TSBOARD의 경우 지금까지 타입스크립트를 계속 사용했었고, 한 때 백엔드에서도 썼던 만큼 안드로이드 앱을 만든다고 하면 가장 좋은 선택지가 React Native입니다. 하지만 지금 다시 생각해보면, 오히려 React Native를 선택하지 않은 덕분에 코틀린 언어에 대해서 알게 되고 기존에 배우고 써왔던 다른 언어와의 공통점들도 발견하게 될 수 있었습니다. 결정적으로 Flutter와 비교했을 때 성능 차이가 확연히 드러났을거라 생각합니다.

딱 한가지 아쉬운 점은, vscode를 사용할 수 없다는 점입니다. 엄밀히 말해서 쓸 수 없는 것 까지는 아니지만, 안드로이드 스튜디오가 압도적으로 개발 생산성이 좋습니다. 딱 이 점만 제외하면, 코틀린 언어와 함께하는 안드로이드 앱 개발은 정말 즐거운 여정입니다.

곧 소개하겠습니다 : Sensta 앱

TSBOARD 기반 커뮤니티에서 쉽게 활용 가능한 안드로이드 앱, Sensta 프로젝트는 GitHub에 전체 코드를 공개(https://github.com/sirini/sensta)하고 있습니다. 우선은 sensta.me 사이트 사용자분들을 위해서만 개발되고 있지만, TSBOARD로 운영되는 그 어떤 커뮤니티에서도 쉽게 활용 가능합니다. 1차 목표는 4월 30일까지 구글 플레이에 등록 가능한 수준으로 만들어보는 것인데, 잘 될 수 있도록 응원을 부탁드리겠습니다!

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

TSBOARD 프로젝트와 연계한 신규 프로젝트를 슬슬 소개해 드리고자 합니다.

(졸린 와중에 쓰는 글이라 조금 횡설수설 한 것 같습니다. 양해 부탁드립니다!)

제가 이 곳에서도 잠깐 소개해 드렸던 sensta.me 사이트, 혹시 기억하시나요?

사진 좋아하는 사람들끼리 서로 사진도 올리고 구경도 할 수 있는 그런 곳이면서,

동시에 TSBOARD의 커뮤니티 기능들을 테스트 해보는 공간입니다.

해당 사이트를 개발할 때부터 사실 자체적으로 앱을 만들어서 사용자 분들이 좀 더 편리하게 사진도 공유하고

알림 기능을 통해서 서로 메시지도 주고 받으면 좋겠다는 생각을 쭉 했었는데,

이번에 TSBOARD가 어느 정도 안정화되면서 미뤘던 앱 개발 프로젝트를 시작하였습니다.

(아직 구현된 페이지보다 안된 페이지들이 훨씬 많긴 합니다… ㅎㅎ)

대략적인 디자인이나 구성은 위의 이미지들과 같습니다.

아마 의아하실 분들도 계실듯 합니다. React Native나 하다 못해 Flutter 기반으로 개발하는 게 아니라

굳이 안드로이드 네이티브 기반으로 개발중인 이유가 뭐냐? 아이폰 용은 어떻게 할거냐?

일단 변명 아닌 변명을 하자면, 웹 기반이나 크로스 플랫폼은 기기에 최적화된 성능을 내기 어렵다는 생각이

많이 들어서 처음부터 제외했습니다. 물론 아이폰용 앱도 개발을 할 예정인데, 굳이 안드로이드를 먼저 한 건

회사에서도 마침 안드로이드 앱 관련 프로젝트 일부를 맡게 되어서이기도 하지요.

(그리고 이번 기회에 Kotlin 언어를 배워보려고 합니다)

위 프로젝트는 사이트 이름에 맞춰서 SENSTA 라는 이름으로 진행중입니다.

삼성 갤럭시 S23 Ultra 기기를 제가 가지고 있어서 그걸 테스트용 삼아서 만들어 나가고 있습니다.

근데, 여기까지만 보면 딱히 새로울 거 없는 평범한 안드로이드 앱 아닌가? 하는 생각이 드실 겁니다.

SENSTA 앱의 가장 큰 특징은, 아주 쉽게 설정만 변경해도 여러분의 커뮤니티 사이트에 딱맞는 앱을

바로 만들 수 있다는 점입니다.

object Env {
    const val title = "SENSTA"
    const val domain = "https://sensta.me"
    const val boardId = "photo"
}

SENSTA 프로젝트에서 Env.kt 파일을 보시면 위와 같이 되어 있습니다.

사이트 이름과 도메인, 그리고 주로 열람할 게시판 ID 하나만 지정하시면 여러분의 커뮤니티 전용 앱이 완성됩니다.

(물론 앱 아이콘 변경 같은 약간의 작업 정도는 해주셔야 합니다만 … ㅎㅎ)

자체 앱을 제작하려면 SENSTA의 소스 코드를 받을 수 있어야 하겠죠?

아래의 경로에서 확인 하실 수 있습니다.

https://github.com/sirini/sensta

TSBOARD 백엔드와 좀 더 잘 통합되도록 개발해 나가면서, 안드로이드 기기에 최적화된 UI/UX로

사이트 이용자분들이 더 편리하게 서비스에 접근하실 수 있도록 해보려고 합니다.

언제 구글 플레이에 올릴 수 있을지 정확히는 잘 모르겠지만, 가능하면 올해 상반기 내 출시를 해보겠습니다.

sensta.me 사이트에도 많은 관심 부탁드리고, SENSTA 프로젝트에도 많은 응원 부탁드립니다! 😆

최근 안드로이드 앱 개발을 해야 할 일이 생겨서, 이래 저래 코틀린(Kotlin) 언어 세미나를 자청해 배운 내용들을 정리하고 내부에 공유하는 작업을 진행하고 있습니다. 그러면서 자연스레 후배 동료분들에게 어떤 식으로 설명을 하는 게 좋을지, 어떤 개념들을 어떤 순서로 말하고 이해하도록 하는 것이 좋을지 고민하게 되었습니다. 그러다 문득, 깨달은 한가지가 있었습니다. 아 내가 안다고 생각했던 것들이 실제로는 제대로 아는 게 아니었구나, 하는 것을요.

변수인데 왜 변경이 안되는 게 있는거지?

코틀린 언어는 저에게 있어서도 생소했고, 부서원들에게도 물론 생소한 언어였습니다. 부서원 대부분은 C++만 사용하고 있고, 그마저도 최근에 조인하신 분은 파이썬으로 과제 정도를 진행해 본 것이 전부인 분입니다. 그래도 저의 경우 TSBOARD 프로젝트를 진행 하면서 Go 언어를 배우고 사용할 기회가 있었고, 타입스크립트(자바스크립트) 언어도 사용해서 그런지 문법이나 개념들이 크게 어려워 보이진 않았습니다. 즉 다른 언어를 사용하면서 무의식중에 체득한 지식들 상당수가 코틀린 언어에서도 그대로 적용된 것입니다. 그래서 처음에는 다른 동료분들에게 제가 배운 내용을 설명하는 것이 그렇게 어려울 거라고 생각하지 못했습니다. 제가 이미 아는 개념이 코틀린에서는 어떤지 파악한 다음, 그 내용을 잘 녹여서 설명하면 될거라고 (안이하게) 생각했던 거죠.

그러나 이 생각이 얼마나 잘못된 것이었는지 코틀린 언어의 변수 부분을 설명하면서 바로 깨닫게 되었습니다. 그나마 C++를 사용하고 있는 동료분들은 C++이라는 비교 대상이 있어서 공통점과 차이점 중심으로 빠르게 학습할 수 있는데, 파이썬만 접한 상황에서 코틀린의 변수 개념을 접할 때는 다소 이해가 안가는 게 있을 거라고 생각하지 못했습니다. 가령 이름이 변수인데 변경 가능한 변수가 따로 있고 변경 불가능한 것이 따로 있는 게 무슨 의미인가? 와 같은 생각을 제가 해본 적이 없었던 것이었습니다. 그저 의례 하는 것처럼 “대충” 다른 언어에 있는 개념이니까 깊게 생각하지 않았었는데, 이러한 의문에 대해 제가 답을 해야 하는 상황이 오자 답변이 막막했습니다. 스스로 굉장히 부끄러웠습니다.

변경 불가능한 변수가 왜 필요한가? 코드를 작성하면서 이후에 잘못된 변경 시도를 방지할 수 있다. 그렇게 했을때 뭐가 좋은가? 의도하지 않은 잘못된 값이 사용 되는 걸 방지할 수 있다. 그 밖에 무슨 장점이 있는가? 컴파일 시점에 이미 값이 변경 안되는 걸 알기에 더 최적화에 용이하다. 또 다른 장점은? 예를 들어 매직 넘버(숫자만 적힌 것)를 의미 있는 이름을 부여해서 사용할 수 있다. 등등…

이전까지 알고 있다고 착각했던 것들은 실제로는 아는 게 아니었습니다. 말 그대로 착각인 겁니다. 변수라는 개념은 프로그래밍 언어를 배울 때 가장 먼저 배웁니다. 하지만 그렇다고 해서 이 변수가 가장 쉽고 간단하기 때문에 먼저 배우는 건 아닙니다. 이 개념을 알아야 그 뒤에 이어지는 제어문이나 함수, 클래스와 같은 개념들을 이해할 때 더 쉽기 때문에 가장 먼저 배우는 것일 뿐입니다. 이름이 변수인데 정작 변경이 안되는 변수에 대한 의문을 깨닫게 되면서, 이런 중요한 걸 이제서야 배우다니! 하는 탄식도 들었습니다.

문은 뭐고 식은 뭔가요?

우리가 통상 제어문을 배울 때 의식하지 않고 “문” 이라고 표현해서 배웁니다. 저도 여지껏 새로운 언어를 배울 때마다 제어문(statement)이라는 단어에 대해서 생소하다는 느낌을 받아본적이 없었습니다. 하지만 이걸 설명하려고 다시 생각을 해보니까, 정확히 이걸 구분해서 생각한 적이 없었다는 생각이 들었습니다.

코틀린은 if나 else 혹은 switch를 대신하는 when이 표현식(expression)입니다. 보통 제어문이라고 배우는데, 코틀린은 아닙니다. if 나 else, when 같은 표현식은 마지막 값이 리턴값이 되어서 변수에 넣을 수가 있거든요. 아주 간단히 생각하면 값 처럼 평가가 되는 겁니다.

fun main() {
    val a = 10
    val b = 20

    // if 표현식
    val max = if (a > b) a else b
    println("Max: $max") // 출력: Max: 20

    // when 표현식
    val grade = 85
    val result = when {
        grade >= 90 -> "A"
        grade >= 80 -> "B"
        grade >= 70 -> "C"
        else -> "F"
    }
    println("Grade: $result") // 출력: Grade: B
}

삼항 연산자가 없는 코틀린이 불편하지 않은 이유도 if 가 표현식으로 값으로 평가되기 때문입니다. 그런데 이 개념, C++만 사용한 동료들에게는 정말 생소한 개념이었습니다. if 가 값처럼 취급된다는 소리가 이해가 안되는 것입니다.

#include using namespace std;

int main() {
    int a = 10, b = 20;

    // if 문 (표현식이 아님, 변수에 직접 할당 불가)
    int max;
    if (a > b)
        max = a;
    else
        max = b;
    cout << "Max: " << max << endl; // 출력: Max: 20

    // switch 문 (값을 반환하지 않음)
    int grade = 85;
    string result;
    switch (grade / 10) {
        case 10:
        case 9: result = "A"; break;
        case 8: result = "B"; break;
        case 7: result = "C"; break;
        default: result = "F";
    }
    cout << "Grade: " << result << endl; // 출력: Grade: B
}

그 때문에 문은 무엇이고 식은 무엇인지에 대해서 다함께 다시 생각해보는 시간을 가지게 되었습니다. 저에게 있어서는 비유를 들자면 C++에서 말하는 lvalue / rvalue를 명시적으로 구분하는 것에 버금가는 배움의 기회였습니다.

코루틴(Coroutine)은 스레드(Thread)에요?

코루틴에 대한 부분을 설명할 때는 정말 저 스스로가 진짜 많이 모른다고 생각이 들었던게, 그냥 스레드인데 가벼운 스레드다! 라고 설명 하자니 너무 축약된 부분이 많다는 점을 알게 되었습니다. 코루틴은 엄밀히 말하자면 스레드가 실행 환경이 되는 것이고, 그 안에서 돌아가는 중단 가능한 객체들을 코루틴이라고 해야 할텐데 이걸 설명하는 것도 쉽지 않았습니다.

그리고 스레드라는 개념도 약간 생소한 상황에서 저런 설명을 들어봤자, 이해가 하나도 안되는 게 사실입니다. 그래서 고민을 하다보니, 아래와 같은 순서로 개념들을 쌓아 나가야 코루틴까지 다다를 수 있겠다는 생각이 들었습니다.

• 동시성(Concurrency)은 무엇이고 병렬성(Parallelism)은 무엇인가?

• 기존의 멀티 스레드(Multi Thread) 방식은 무엇이 문제였나?

• 동기(Synchronous)와 비동기(Asynchronous)의 차이는 뭔가?

• 블록(Block)과 논블록(Non-Block)의 차이는 뭔가?

  • 그리고 동기와 비동기와의 관계는?

• 코루틴은 멀티 스레드와 어떻게 다른가?

• 중단 가능한 객체라는 것은 무슨 의미인가?

• 코루틴 빌더는 무엇이고 코루틴 스코프는 또 무엇인가?

• 구조적 동시성이라는 개념은 무엇인가?

• 메인 스레드와 코루틴이 동작하는 스레드의 차이는 무엇인가?

  • 그리고 코루틴이 동작할 스레드를 바꿀 수 있다는 의미는 무엇인가?

• 안드로이드에서 쓸 수 있는 코루틴 스코프는 무엇인가? 왜 따로 정의되어 있는가?

코루틴이라는 하나의 개념에 이르기까지 생각보다 많은 개념들을 알아야 한다는 걸 알게 되었습니다. 그냥 막연히 이럴 것이다, 혹은 Go 언어의 고루틴과 비슷한거야, 라고 단정짓는 것은 뇌에 일종의 속임수를 쓰는 것이나 다름 없었습니다. 더 깊게 고민하거나 개념들을 애써 정리하게되면 에너지가 소모 되니까, 에너지를 덜 쓰는 방향으로 그동안 스스로를 속였던 셈입니다.

이 모든 진실들을, 누군가에게 제가 알고 있는 개념이나 배운 내용에 대해서 설명하려고 할 때 비로소 깨닫게 되었습니다. 하나의 개념을 제대로 이해하기 위해서는 생각보다 더 많은 사전 지식이 필요합니다. 대충 설명하는 건 쉽지만 제대로 설명하는 건 어렵습니다. 때론 아주 단순한 하나의 개념 속에도 미처 생각하지 못한 점들이 많이 있었습니다. 겉으로는 제가 누군가에게 지식을 전달하는 단순한 일이었지만, 실제로는 제가 그동안 안다고 착각했던 지식들을 다시 한 번 점검하고, 이면을 깨닫고, 개념을 더 엄밀하게 파악할 수 있는 소중한 기회였습니다.

누군가를 가르친다는 건 실제로는 스스로의 무지를 깨우치는 훌륭한 학습법이라고 생각합니다. 이번 코틀린 언어 학습이 잘 마무리되면 자청해서 다른 프레임워크나 언어에 대한 세미나도 진행해봐야 겠습니다. 😊

TSBOARD에도 드디어 회원 간의 물품 거래를 보다 편리하게 할 수 있도록 하는 기능이 생겼습니다. 개발에는 생각보다 시간이 제법 걸렸는데, 이번에는 안드로이드 개발 공부도 있긴 했지만 의도적으로 속도를 좀 늦췄습니다. 천천히 개발하면서 과연 어떤 방향이 더 맞을지 생각하는 시간을 많이 가졌고, 덕분에 처음 구상한 기능들을 덜어내면서 최소한의 기능만으로도 훌륭하게 첫 발을 내딛을 수 있었습니다. 몇가지 고민했던 부분들과 제가 정리한 방향에 대해서 기록을 남겨봅니다.

물품 거래 후 피드백

물품 거래 기능을 개발할 때, 몇가지 레퍼런스를 두고 시작 했습니다. 단연 그중 으뜸은 당근입니다. 저 뿐만 아니라 많은 분들이 사용하고 계시는 국민 앱이 되었는데, 이 당근 앱을 보면 중고 물품을 거래하고 난 이후 서로에 대한 피드백을 남기도록 되어 있습니다. 약속 시간에는 제때 왔는지, 물품의 상태는 게시글에 적힌 것과 같은지 등이며 이런 피드백들이 쌓여서 매너 온도라는 지표가 업데이트 됩니다.

처음에는 TSBOARD에서도 이런 피드백 과정을 염두해 두고 개발을 진행했습니다. 아무래도 회원 간의 거래다보니 뭔가 까다로운 피드백 절차 까지는 아니더라도 별점을 매긴다던지 하는 게 필요하다고 생각했었거든요. (매너 온도 비슷한 지표를 생각했습니다) 그러다가 다른 커뮤니티 사이트에서는 중고 물품을 어떤 식으로 거래하고 있는지 살펴보았는데, 의외로 피드백 부분이 없었습니다. 처음에는 다른 커뮤니티 사이트에서 구현하지 않았으니까 TSBOARD에서 하면 의미가 있겠다! 싶었는데, 곰곰히 생각해보니 굳이 그럴 필요가 없어 보였습니다.

일단 커뮤니티 사이트는 특정 주제 중심인 경우가 많고, 대부분은 중고나라처럼 무언가를 팔거나 사기 위해서만 이용하지 않습니다. 때문에 물건을 판매하는 쪽에서도 사는 사람이 같은 커뮤니티 이용자라는 점을 인지한 상태로 팔고, 사는 분도 마찬가지여서 완전 생판 모르는 사이끼리 거래는 아니라는 점이 달랐습니다. 또한 커뮤니티 사이트내의 중고 물품 거래는 어차피 댓글 등을 작성하면 모두가 볼 수 있어서 그것이 좋은 피드백이든 살벌한 비판이든 바로 드러나게 됩니다. 따라서 굳이 별점이나 여러 피드백 절차를 추가할 필요가 없다는 결론에 도달하였습니다.

구매자와 판매자간의 소통

가장 고민을 많이 했던 부분입니다. 당근의 경우 앱이기 때문에 채팅 기능도 있고, 앱 알림도 바로 오기에 크게 문제가 없지만 TSBOARD는 아직 앱이 없어서 고민이 되었습니다. 그나마 쪽지 기능이 1:1 소통으로 가능하기 때문에 우선적으로는 메시지 보내기 같은 기능으로 대체하고, 추후 TSBOARD 앱이 개발되면 그 때 알림 기능을 반영하는 걸로 타협을 보았습니다.

판매자가 자신의 전화번호를 입력하게 해도 되는데, 아무래도 개인정보라서 이걸 보관하게 두는 것이 맞나 하는 생각이 계속 들었습니다. 가능하면 판매자가 오픈카톡방을 만들어서 링크를 전달해주고, 서로 소통 후에 거래 의사가 확실해지면 그 때 판매자의 자의로 전화번호를 메시지 혹은 오픈카톡을 통해서 전달하는 방식을 선택했습니다.

찜하기

당근의 경우 마음에 드는 물건이 있다면 찜하기로 찜해두고, 언제든지 해당 제품의 가격 변동 상황을 파악하거나 할 수 있습니다. 판매자에게도 이건 좋은 기능인데, 많은 사람들이 찜을 했다는 건 그만큼 관심을 많이 받고 있다는 뜻이므로 판매될 가능성이 높다는 시그널을 받을 수 있습니다. 그래서 저도 이 찜하기 기능을 구현 하면서 동시에 내가 찜한 물품의 가격이 변동되면 TSBOARD 시스템으로부터 쪽지를 받게 한다거나 메일로 알림을 받도록 하려고 했었습니다.

테이블도 간단하게 구성하고 구현을 하려다가, 문득 TSBOARD의 좋아요 기능이 결국 찜하기와 같은 맥락이 아닌가? 하는 생각이 들었습니다. 좋아요 기능은 게시글이 마음에 들면 눌러서 표시하는 건데, 물품 거래 게시판에서 특정 게시글에 좋아요를 눌렀다는 건 결국 찜하기와 동일한 맥락이 아닌가? 하는 생각에 다다른 것입니다. 그래서 불필요하게 찜하기 관련 DB 테이블을 만들거나 하지 않고, 좋아요 기능을 그대로 쓰도록 하되, 추후 좋아요를 누른 사용자에게 선택적으로 가격 변동 등에 알림을 받도록 하는 방향으로 수정하였습니다. (이 기능은 추후 구현 예정)

어찌보면 참 간단한 기능인데 생각보다 많은 부분들을 고민했던 것 같습니다. 만약 시간에 쫓겨서 개발을 진행했다면 아마도 불필요한 기능들만 중구난방으로 구현해두고 나중에 가서야 또 제거하는 일을 벌여야 했을 겁니다. 구현보다 설계에 좀 더 시간을 쓰라는 격언을 새삼 떠올려 봅니다.

안녕하세요! 아주 오랜만에 TSBOARD 업데이트 소식을 가지고 왔습니다!

업데이트 작업을 간간히 하는동안, TSBOARD를 사용하는 커뮤니티 사이트에서 쉽게 활용 하실 수 있는

안드로이드 앱을 어떻게 만드는지 공부 하느라 조금 늦어졌습니다. 🥲

(v1.0.4 이후에는 안드로이드 앱 개발이 진행될 예정입니다.)

🚨 먼저 v1.0.4 업데이트를 위해서는 아래와 같이 goapi-linux-x64 바이너리를 실행해 주셔야 합니다.

./goapi-linux-x64 update

update 인자를 전달하면 trade 테이블을 새로 추가하는 작업이 진행된 후, 백엔드가 실행됩니다.

이번 업데이트는 아래의 변경사항을 포함합니다.

• 물품 거래 게시판이 추가되었습니다.

  • 신규 혹은 기존 게시판의 타입을 “거래” 로 설정하시면 반영됩니다.

  • 이곳에서 샘플을 보실 수 있습니다: https://tsboard.dev/trade/market

  • 기본 화폐 단위 아이콘은 원화로 설정되어 있습니다. 변경을 원할 경우 tsboard.config.ts CURRENCY 변수에 값을 변경해주세요.

• 첫 페이지 로드 시 페이지가 3번 빠르게 변경되는 버그를 수정하였습니다.

• 기본 폰트가 Pretendard로 변경되었습니다. 로고 폰트도 동일하게 변경되었습니다.

• YouTube 영상 임베딩이 안되던 문제를 수정하였습니다.

• 게시판의 카테고리 사용 여부 설정이 업데이트 안되던 버그를 수정하였습니다.

물품 거래 기능은 커뮤니티 사이트에서 거의 대부분 가지고 있는 기능입니다.

일반적인 게시판에 회원들이 글 내용을 양식에 맞춰서 입력하도록 하거나, 혹은 추가적인 기능을 제공해서

회원들이 거래 관련 정보를 더 입력할 수 있도록 해주고 있습니다.

TSBOARD에서는 중고 물품 거래에 필수적으로 요구되는 아래 정보들을 trade 테이블에서 관리하도록 했습니다.

• 제조사 이름 혹은 브랜드

• 물품 분류

• 가격

• 물품 상태

• 거래 위치

• 거래 방식 (택배 혹은 직거래)

거래가 완료되면, 게시글 작성자가 쉽게 거래 상태를 완료로 변경 하실 수 있습니다.

한가지 고민은 전화번호를 추가로 보관해야 할까 하는 것인데, 가급적 TSBOARD 쪽지 기능으로 1:1 대화를 통해서

구매자와 판매자가 소통을 시작하고, 거기서 필요 시 오픈카톡방 URL 혹은 전화번호를 교환하는 걸로

사용 흐름을 잡았습니다. 추후 TSBOARD 안드로이드 앱이 준비되면, 안드로이드 사용자분들은

(아마도?) 앱 알림을 통해서 메시지 내용을 바로 받으실 수 있으실 겁니다.

v1.0.4를 기다려주신 분들께 감사 드립니다! 사용중에 버그를 발견 하셨다면 언제든지 알려주세요!

🚨 이 글은 TSBOARD v1.0.4에 추가된 물품 거래 기능의 테스트를 위해 작성된 샘플 입니다. 🚨

비운의 마지막 인텔칩 맥북 프로입니다.

출시될 때는 끝판왕의 사양으로 개발 생산성이 마구마구 올라갔었지만, 얼마 지나지 않아 더 미친 애플 실리콘칩이 나와서

좌절하게 되었습니다. 끝까지 안고 가려다가 내놓게 되었습니다.

• 2.3 GHz 8 core Intel Core i9

• Intel UHD Graphics 630 1536 MB

• 32GB 2667 MHz DDR4

• 배터리 사이클 수 : 67 (정상)

• 애플 보증 만료됨

화면 품질이나 스피커는 지금 봐도 정말 수준급입니다. 당시에는 정말 끝판왕이었습니다.

이제는 부트 캠프를 쓸 생각이 있거나 패럴럴즈 같은 걸 쓸 게 아니라면 약간 고민되시겠지만,

기본적인 기능들은 여전히 잘 동작하고, 개발용으로도 여전히 좋습니다. (무엇을 개발하시냐에 따라 다르겠지만요!)

정품 충전기와 USB-C to C 케이블은 같이 드릴 수 있고, 박스 등은 없습니다.

외관상 흠집 정말 찾기 어려울 정도로 애지중지 썼고, 기능상 문제도 없습니다.

거래 성사되면 바로 초기화까지 싹 해서 드리겠습니다.

구매 희망하시는 분들은 메시지 보내기나 댓글로 말씀해주세요.

직거래 희망하며 현장 네고는 정중히 사양하겠습니다.

🚨 이 글은 TSBOARD v1.0.4에 추가된 물품 거래 기능의 테스트를 위해 작성된 샘플 입니다. 🚨

로봇청소기의 끝판왕이라 할 수 있는 로보락의 S6 Max V 제품입니다.

물걸레 기능은 거의 쓰지도 않았고, 가끔 먼지통 비워주고 알리나 테무에서 필터류 같은 소모품들을

저렴하게 구매해서 교체하여 사용하였습니다.

이번에 S9 Max V 제품으로 업그레이드를 하게 되면서 기존에 쓰던 로봇청소기를 내놓고자 합니다.

삶의 질을 상승시켜주는 건조기 식세기 로청기 3대장은 집에 꼭 있으면 좋은데,

만약 저렴하게 영입하고자 하시는 분들이라면 이번 기회에 업어가보세요!

거래는 직거래 희망하고, 화성반월초등학교에서 거래 희망합니다.

구매 희망하시면 저에게 메시지 보내주시거나 댓글로 알려주세요!

꼭 거창한 프로젝트가 아니더라도, 무언가를 만들고 이를 공개 하면서 다른 사람들의 피드백도 받아보고 또 개선하는 활동은 에너지를 필요로 합니다. 생업으로 하는 프로젝트는 월급이나 기타 수익을 기대하는 마음으로 시간을 쏟을 수 있지만, TSBOARD처럼 그냥 기대 이익 없이 하는 프로젝트의 경우 동기 부여가 없다면 지속하기 어렵거든요.

사이드 프로젝트를 진행하면서, 생업과 크게 관련없는 작업물을 만들어가는데 시간을 무한정 쓸 수는 없습니다. 개발자도 사람이고, 사람은 기계가 아니기 때문에 전기만 넣어준다고 언제나 풀파워로 작업 할 수는 없거든요. 오히려 계속 작업하는 게 해당 프로젝트를 빨리 끝내버리는 기폭제가 될 수도 있습니다.

그렇다면, 생업에 직결된 것도 아니고, 그저 남는 시간에 재미로 혹은 그저 내가 만들어 쓰고 싶어서 진행하는 사이드 프로젝트를 오래도록 유지할 수 있는 비결이 있다면 무엇이 있을까요? 저도 사실 정답을 알고서 쓰는 글은 아니지만, 나름의 생각을 공유해 보려고 합니다.

완급 조절하기 : 100m 전력 질주 하지 않기

프로젝트를 진행하다보면 어느 시점(예를 들어 v1.0.0)에 이르러 프로젝트의 초기 목표를 달성 했거나, 최소한 기본적인 기능은 나름대로 동작하게 됩니다. 그 때가 오면 당장 새로운 기능을 추가하지 않는 한, 기본적인 버그 수정 등을 거친 후에 프로젝트 개발 속도가 조금씩 감소하게 됩니다. 사실 지금의 TSBOARD 역시 v1.0.3을 지나고 v1.0.4부터는 템포가 조금 느려지고 있습니다. 이런 현상은 자연스럽다고 생각하고, 열심히 TODO 리스트를 지워가던 시기가 있다면 지금처럼 새로운 TODO 리스트를 상상하는 시간도 있어야 한다고 생각합니다.

운동도 사이드 프로젝트도 완급 조절이 중요합니다. 처음에 프로젝트를 시작했을 때의 열정과 에너지는 무한히 지속되지 않습니다. 이를 인정하고, 빠르게 달릴 때와 속도를 늦추고 새로운 가능성을 탐구하는 시간이 꼭 필요합니다. 저도 마찬가지지만 우리의 프로젝트가 하루 이틀만에 완성되는 초단기 프로젝트가 아니라면, 호흡을 너무 바삐 가져갈 필요는 없습니다.

기대 금지 : 다른 사람은 이 프로젝트에 관심이 없다

이건 정말 중요한데, 다른 사람들이 내가 진행하고 있는 프로젝트에 대해서 큰 관심이 없다는 당연한 사실을 받아들여야 합니다. 누가 봐도 내 프로젝트는 정말 중요해! 라고 할 수 있는 건 정말로 드물다고 할 수 있습니다. 정말로 중요했다면, 누군가가 이미 했을 것입니다. 그리고 진짜 많은 관심을 받아야 마땅한 프로젝트라면, 누군가가 이미 알아봐 주었을 것입니다. 개인이든 기업이든 후원을 해주고 이 프로젝트가 진심으로 계속 될 수 있도록 여러분의 시간에 마땅한 투자를 해주었을 겁니다. 그렇지 않다는 것은, 이 프로젝트가 객관적으로 다른 사람들에게까지 중요하거나 관심을 받을 수 있는 건 아니라는 것입니다. 이 점을 받아들여야 합니다.

그렇다고 해서 저나 여러분이 하고 있는 사이드 프로젝트가 가치 없다거나 무의미한 것이라는 뜻은 결코 아닙니다. 다른 사람들이 알아봐 주지 않더라도, 적어도 그 프로젝트를 진행하는 여러분들에게 있어서는 큰 가치가 있습니다. 저만 하더라도 TSBOARD 프로젝트를 통해서 현대적인 웹 개발에 대해 배울 수 있었고, 타입스크립트라는 언어를 통해서 풀스택 개발을 해보는 경험을 빠르게 쌓을 수 있었습니다. 지금도 조금 생소한 Bun 런타임을 먼저 써보면서 장단점을 배울 수 있었고, Go 언어에 대해서 배워가면서 백엔드를 더 안정적으로 운영하는 길도 찾아가고 있습니다. 사이드 프로젝트를 통해서 저는 많은 것을 배웠고, 배우고 있습니다. 그리고 저에게 있어 그것 만으로도 이미 충분합니다. 여러분들도 마찬가지일 거라 생각합니다.

늘 미완성인 부분을 남겨두기

마지막으로 가장 중요한 비법, 프로젝트를 끊임없이 지속하는 방법은 바로 미완성인 부분을 늘 코드에 남겨두는 것입니다. 예를 들어 // TODO : 추후 구현할 것(개선할 것) 처럼요. 새로운 기능들을 추가할 때 한 번에 작업하려고 하지 말고, 우선 설계만 잡아둔 상황에서 빈 함수들이나 혹은 인터페이스만 선언해 둡니다. 새로운 기능들이 UI 상에서 드러나지 않거나 어딘가로부터 요청되지 않는다면, 해당 코드는 사실상 코드 관점에서는 아무 일도 하지 않습니다. 사실 없어도 그만인 코드니까요.

하지만 앞서 계속 언급한 것처럼, 개발자인 우리는 사람이고, 사람은 그렇게 미완성으로 남은 코드 조각들을 편한 마음으로 볼 수가 없습니다. 비어 있는 함수들은 계속 생각이 나고, 언젠가 시간이 좀 나면 이렇게 저렇게 채워둬야지 정도의 생각이 머리 속 한켠에 늘 남아있게 됩니다. 그러다가 문득 시간이 비는 날이면, 아 맞다! 그 // TODO 부분이나 좀 채워둬야지 하고 에디터를 열게 됩니다. 일종의 스스로에게 넛지(옆구리를 슬쩍 찌르기)하는 셈이죠. 이렇게 미완성인 채로 계속 신경 쓰이게 만드는 코드를 남겨두면, 언젠가 그걸 채우게 되고, 또 다시 새로운 미완성 조각들을 남겨두면서 프로젝트가 죽지 않고 계속 살아있게 만들 수 있습니다. 사실 프로젝트에 완성이라는 건 없지만, 좀 더 현실적으로 코드 관점에서도 미완성인 영역이 눈에 보이게 만드는 게 핵심입니다.

지속 가능한 사이드 프로젝트를 위하여

사이드 프로젝트는 개발자에게 배움의 기회와 무언가를 만들어가는 재미를 선사합니다. 이 배움과 만드는 재미를 오래도록 누리기 위해서는 좀 더 느긋하게 마음 먹고, 다른 사람으로부터의 관심이나 인정에 목매지 않으면서, 늘 미완성인 부분을 코드에 남겨두는 지혜가 필요합니다. (사실 이 글을 쓰면서 스스로에게 하는 조언이라고 생각하며 썼습니다 ㅎㅎ) 우리 신나게 느긋하게 사이드 프로젝트 개발해봐요. 😊

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

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

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

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

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

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

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

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

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

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

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

안녕하세요.

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

정말 반갑습니다. 😀

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

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

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

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

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

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

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

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

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

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

새해 복 많이 받으세요!

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/sensta

멋지네요

지금은 이 곳 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를 개발하고 있는 시리니입니다.

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를 개발하고 있는 시리니입니다.

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

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

이 곳에서도 언급한 적이 있었지만, 저에게 있어 웹은 곧 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 언어에 충분히 능숙해지면 그 때 또 후기 비스무리하게 글을 끄적여 볼께요. 😊

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

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

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 링크들을 공유드립니다. (개발자 여러분들, 스타 한번씩 부탁드려요!)

• TSBOARD - https://github.com/sirini/tsboard

• GOAPI - https://github.com/sirini/goapi

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

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

감사합니다.

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

안녕하세요! 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 부분을 먼저 읽어주시고

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

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

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

• 정말 작고 조용하다

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

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

• 진짜 빠르다

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

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

• 하지만 가격이 사악해

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

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

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

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

안녕하세요! 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 개발하고 있는 시리니입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(참고: 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배 가량 높았지만, 그럼에도 이 결과만 두고 봤을때는 정말 놀라운 수준입니다.

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

(참고: 이번에도 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 언어에 대한 이 글의 비교 결과를 어떻게 생각하시는지 의견도 나눠보고 싶습니다!

• TSBOARD 프로젝트: https://github.com/sirini/tsboard

• TSBOARD GOAPI: https://github.com/sirini/goapi

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

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

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

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

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

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

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

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

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

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

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

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

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

현재 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/

저는 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 개발하고 있는 시리니입니다.

열심히 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 개발자 시리니입니다.

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

• 에디터 툴바 기능 개선

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 글보기 내비게이션 추가

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

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

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

• 알림 메시지 버그 수정

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

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

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

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

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

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

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

감사합니다!

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

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

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

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

더 많은 분들에게 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 언어와 친해져서 이것 저것 재미난 것들 만들어보고 싶네요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

감사합니다.

광복절입니다.

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

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

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

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

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

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

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

안녕하세요! 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 절로 하지 않기로 하면서 이 고민들이 시작되었는데,

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

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

저는 코딩을 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++언어를 만나게 되는 순간이 있을 겁니다. 그 때 부디 유쾌한 재회가 될 수 있기를 기원합니다. 저도 이제는 다리 전체를 날려버리는 멍청한 짓은 이제 그만둘 수 있기를 바래봅니다.

안녕하세요! 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를 이용한 다양한 커뮤니티 사이트가 생길 그 날을 기대해 봅니다!

감사합니다.

예전에 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 개발자 시리니입니다.

약 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 개발하고 있는 시리니 입니다.

아직 오피셜하게 업데이트 공지를 드리지는 못했습니다만, 기본적인 블로그 작업은 마무리되어서

우선 제 블로그부터 하나 만들어 보았습니다. ㅎㅎ

사실 이름을 TSBOARD 라고 짓기는 했습니다만, 저는 제가 만든 블로그를 운영해 보는 게 목표였는데

이제 한걸음 다가간 셈입니다. 공식 업데이트 소식에서 좀 더 자세한 내용을 설명드리겠지만,

아래에 간략히 블로그 작업하면서 신경썼거나 의도한 부분들 먼저 소개 드리겠습니다!

• TSBOARD의 블로그는 기본적으로 어두운 테마 기준으로 작업되었습니다. 이는 게시판이나 갤러리와 구분되도록 의도한 것으로, 블로그라는 게 게시판과 달리 보통은 한명 내지는 소수의 인원만 사용하는 게 일반적이라서 좀 더 개인적인(?) 느낌을 드러내고자 색상을 다르게 가져갔습니다.

• 블로그는 TSBOARD 게시판 설정에서 게시판 관리자로 지정된 사람만 사용할 수 있도록 할 생각입니다. 만약 TSBOARD로 10명에게 각각 블로그를 만들어주려면 10개의 게시판을 생성해야 합니다.

• 블로그에 작성된 글은 홈 화면의 최근 게시글에서도 그대로 만나 보실 수 있습니다. 그러고보니 홈 화면의 게시글들을 지금은 최신 순으로만 볼 수 있는데 앞으로는 특정 기간 동안의 좋아요나 조회수 기준으로 정렬하는 것도 구현할 예정입니다.

이제 첫 삽을 퍼올린 셈이라, 여기 저기 손봐야 할 부분들이 많습니다.

어느 정도 정리가 되면 TSBOARD v0.9.0 업데이트 소식으로 공유 드릴께요!

블로그 한 번 씩 봐주시고 어떠신지 의견들도 많이 부탁드립니다 😆

퀄이 너무 좋습니다~

지금은 홈서버로 돌리고 계신데…

이미지 업로드는 역시 홈서버로 되는 거죠?

중대형으로 가게 되면 이미지 트래픽 비용이 엄청 나게 많이 나온다던데 거기에 대한 대비책은 있을까요?