NUBO의 시작 : SSR

NUBO는 TSBOARD 프로젝트를 직접적으로 계승합니다.

DB 스키마도 완전히 동일하게 사용하며, GOAPI 백엔드의 경우 이제는 NUBO 위주로 업데이트가 되고 있지만, TSBOARD 시절과 비교하면 완전히 새롭게 변경되거나 하진 않았습니다.

가장 많이 변경된 부분은 바로 프론트엔드인데, TSBOARD를 긱뉴스에서 선보인 후로 가장 많은 피드백을 받았던 SSR(Server Side Rendering) 지원을 하기 위해서 시작한 프로젝트입니다.

처음에는 사실 내키지 않았습니다. 아무리 모던 웹 개발이 복잡해지고 어려워진다 하더라도, 프론트엔드에 이 정도까지 노력을 기울이는 게 가당찮아 보였기 때문입니다. 예전에 php4 시절에 했던 풀스택 개발 (그 때는 모든 웹 개발이 풀스택이었고 그게 당연했습니다) 보다 오늘날의 프론트엔드 개발이 더 복잡해지고 어려워졌습니다. 그런 상황에서 TSBOARD의 설계에서 가장 중요한 결정 사항이었던 SPA(Single Page Application) 구조를 버리고 SSR로 변환하는 게 두렵기도 했고, 괜한 고생길을 가는 거 아닌가 하는 우려도 있었습니다.

하지만 꽤나 많은 분들이 SSR로의 전환을 권해주시기도 했고, 결정적으로 TSBOARD 사이트의 컨텐츠 노출이나 게시글 업데이트 등이 구글에서 제대로 이뤄지지 않는 점을 목도하면서 백엔드 교체에 이어 프론트엔드 교체도 단행하게 되었습니다.

개발 스택 선택

개발 스택은 TSBOARD 프로젝트를 진행하면서도 꽤나 많이 바뀌었습니다. 애초에 정했던 건, 지금은 앤트로픽에 인수된 Bun 런타임 기반의 백엔드를 구성하고, 프론트엔드는 Vuetify를 중심으로 해서 SPA 기반으로 페이지를 구성하는 것이었습니다. 당시에 웹 프레임워크로 선택한 ElysiaJS의 경우 꽤나 빠른 동작 속도를 보여주기도 했고, 개발 편의성도 높았기 때문에 TSBOARD의 초반 성능은 제 기준에서 나름 훌륭했습니다.

원래 프로젝트의 목표가, TypeScript 라는 꽤나 멋진 언어를 처음 배워보면서 이 언어만으로 풀스택 웹개발을 해보자! 였기 때문에 프로젝트 이름도 TS를 따와서 TSBOARD가 된 것이었습니다. 여하간 문제 없이 1.0 버전까지 Bun 런타임 기반으로 쭈욱 이어질 줄 알았건만, 생각지도 못하게 당시 Bun 런타임의 가상 CPU 버그 문제에 발목이 잡히면서 백엔드를 교체하자는 결정을 내리게 됩니다.

그 때 당시에는 정말 미친 결정이었지만, 지금 생각해보면 너무나도 좋았던 Go 언어로 백엔드를 다시 개발한다는 결정을 한 후에 열심히 Go 언어를 배워가면서 기존에 TypeScript로 작성한 백엔드 코드를 변환하기 시작했습니다. 그리고 1.0 버전 공개 시점에 맞춰서 백엔드 교체까지 하고 TSBOARD를 선보일 수 있었습니다.

이제 SPA 에서 SSR 방식으로 프론트엔드를 렌더링 해야 하니, 당연하게도 Nuxt로의 전환을 가장 먼저 결정하였습니다. React를 썼었다면 당연히 Next.js로 아마 갔을테지만, 저는 Vue3을 꽤나 만족하면서 썼고 이제와서 모든 걸 버리고 React로 변경하는 건 생각하고 싶지 않았습니다. 일단 Nuxt로 결정하면서, 이어서 결정해야 하는 건 UI 라이브러리였는데 여기서는 살짝 도박을 하게 되었습니다. 바로 잘 쓰던 Vuetify를 떠나 Shadcn-vue를 선택한 것입니다.

Shadcn-vue로 교체한 이유는, 이 UI 라이브러리가 커스텀의 범위가 굉장히 넓고 tailwindcss를 배워서 써먹기에 꽤나 괜찮아 보였기 때문입니다. 접근성을 고려한 점도 물론 있습니다만, 커스텀과 tailwindcss가 정말로 컸습니다. 그리고 예시 UI 컴포넌트들도 꽤나 제 취향의 심플함이 반영되어 있었구요.

Nuxt에 적응하는 것과 더불어서 shadcn-vue, tailwindcss를 처음부터 새로 배워 나가면서 가만 생각해보니, 이정도까지 변경된 걸 그냥 TSBOARD 2.0으로 퉁칠 수 있을까? 하는 점이었습니다.

TSBOARD 2.0이 아닌 이유

처음에는 프로젝트명에 대해서 크게 고민하지 않았습니다. 그냥 TSBOARD v1.5라고 하자, 아니다 이 정도까지 바뀐거면 2.0 해도 되겠다. 그냥 TSBOARD 2.0라고 하자, 등등 여러 생각들이 떠올랐습니다.

하지만 계속 생각하면 할수록, 처음에 TSBOARD를 만들면서 품었던 계획과 목표, 그리고 수단이 어느 덧 많이 바뀐 것 같다는 생각이 점점 커지기 시작했습니다. 가장 핵심적인 이유는, 더 이상 TypeScript 단일 언어로 개발되는 프로젝트가 아니라는 점입니다. 이미 백엔드는 TSBOARD 시절에 Go 언어로 전환했고, 프론트엔드의 경우 TSBOARD는 그나마 별도의 프레임워크라고 할만한 게 없었습니다만 이제는 Nuxt라는 것이 핵심이 되었습니다. 처음에 TSBOARD라는 소박한 이름에 품었던 내용들이 어느 새 많이 희석된 것입니다.

그래서 이참에 새로 이름 하나 지어줘야겠다, 라는 생각이 들어서 TSBOARD 2.0이 아닌 NUBO라는, 다소 생뚱맞은 이름을 선택하게 됩니다.

NUBO : 차세대 커뮤니티 빌더

프로젝트 이름에 Board가 들어간 건 아주 오랜 옛날, 제로보드와 그누보드가 웹 세상을 호령하던 그 시절의 향수 때문이기도 했고 또 이전에 진행하였던 GR Board라는, 이제는 잊혀진 프로젝트에 대한 추억 때문이기도 했습니다.

그러나 이 프로젝트가 PHP 시절에 개발된 게시판이 아니라 사이트 자체를 빌드하고 더 큰 규모의 트래픽을 감당하도록 설계된 점, 그리고 확장성까지 고려하면서 나름 많은 고민을 안고 진행하는 점을 감안하여 이름을 새롭게 짓고 싶었습니다. 여러 아이디어들이 있었지만, 작명 센스가 정말 없구나 하는 한탄과 함께 Nuxt 와 TSBOARD의 알파벳들을 적당히 조합해서 NUBO라고 이름을 지었습니다. A New Unified Board 라는 설명 문구가 있긴 합니다만, 이거는 나중에 가져다 붙인거고 실제 NUBO는 무슨 축약어 같은 게 아니라 그냥 개똥이 처럼 지은 이름입니다.

이름에 대한 여러 해석들은 나중에 생각하기로 하고, 이 자칭 차세대 커뮤니티 빌더가 가져야 하는 가장 큰 특색을 무엇이 되어야할지 고민을 하게 되었습니다.

NUBO의 차별화 : 스킨 시스템

TSBOARD부터 NUBO에 이르기까지, 제가 웹 개발을 하면서 늘 가지고 있던 추억은 제로보드4와 그누보드5 시절에 만들던 스킨이었습니다. 지금은 오히려 스킨 보다는 테마나 템플릿이라는 용어를 많이 쓰기도 하고, 디자인 시스템을 굳이 바꾸거나 하지 않는 경우도 많아진 것 같습니다만, 당시에 스킨 시스템은 지금 돌이켜봐도 굉장히 혁신적이었고 생태계를 창조할 수 있는 힘이 있었습니다.

제가 스킨 제작자로 당시에 아주 조촐한 이름을 얻었던 기억이 있기 때문인지, TSBOARD를 개발할 때도 스킨 시스템을 꼭 넣고 싶다는 생각이 간절했었습니다. 다만 그 때는 Vue3나 Vuetify같은 것에 허덕이던 시절이었고, PHP가 사라진 웹 세상에서 덩그러니 혼자 방황하던 시절이라 스킨까지 고민하진 못했었습니다. 그냥 프로젝트 자체를 내려 받아서 다른 누군가가 필요하면 본인의 디자인 감각에 맞게 고쳐 쓰시겠지, 이 정도만 생각 했었죠.

그러나 저에게 부족한 건 작명 센스 뿐만이 아니라는 점이 점점 더 명확해지면서, NUBO 프로젝트에서는 반드시 스킨 시스템을 넣겠다는 각오로 열심히 고민하면서 개발을 진행하게 됩니다. 그러다 드디어 Provide & Inject 방식으로 디자인과 로직을 비교적 깔끔하게 분리할 수 있는 방안을 찾게 되면서 NUBO의 핵심적인 차별화 기능으로 모던 웹에서도 스킨 시스템을 도입할 수 있게 되었습니다.

NUBO에서는 nubo-basic-board, nubo-basic-login 처럼 각각의 기능들을 표현할 수 있는 기본 스킨들이 모두 제공됩니다. 크게는 레이아웃 디자인부터 작게는 에러 메시지 출력 페이지까지 모든 페이지들은 스킨으로 표현됩니다. 아직 개발을 시작하진 않았습니다만, 관리 화면도 마찬가지로 스킨으로 표현되므로 저보다 디자인 감각이 좋으신 대부분의 개발자분들이 더 멋진 대시보드와 UX로 무장한 관리자 화면용 스킨을 개발 하실 수도 있습니다.

Gofiber v3 기반의 고성능 백엔드 엔진이 이제 더 많은 일들을 해주고, 프론트엔드 역시 SEO(Search Engine Optimization)가 필요한 페이지들은 SSR 기반으로 렌더링된 페이지가 나오도록 해서 클라이언트와 부담을 나눠서 짊어지도록 할 수 있습니다. 또한 TSBOARD 시절에는 Bun 런타임이 우선이었지만 지금은 Node.js가 기본이고 Bun과 Deno가 선택 옵션이므로 더 보통의 환경에서 서버를 운용 하실 수 있게 됩니다.