NodeBB vs. Discourse: goodtek 커뮤니티를 NodeBB로 시작한 이유

Share
NodeBB vs. Discourse: goodtek 커뮤니티를 NodeBB로 시작한 이유

블로그 다음에는 커뮤니티가 필요했다

석가탄신일까지 이어지는 3일 연휴.

연휴라고 하면 뭔가 여유가 있을 것 같지만, 대한민국 아빠에게 연휴는 그렇게 단순하지 않습니다.

아이와 놀아주고, 밥 먹이고, 씻기고, 재우고 나면 하루가 거의 끝납니다.

기획할 시간도, 코딩할 시간도 생각보다 없습니다.

아이가 잠들고 나서야 겨우 제 시간이 생깁니다.

보통 한두 시간 정도입니다.

그 시간에 노트북을 열고, goodtek을 어떻게 만들어갈지 다시 생각합니다.

솔직히 쉽지는 않습니다.

피곤하고, 머리도 잘 안 돌아갑니다.

그래도 조금씩이라도 해보려고 합니다.

이 블로그도 그렇게 시작했습니다.

앞으로 goodtek에는 제가 한국에서 한 아이의 아빠이자 개발자로 살면서, 테크로 밀리어네어를 꿈꾸며 겪는 시행착오를 기록해보려고 합니다.

거창한 성공담을 쓰려는 건 아닙니다.

오히려 반대에 가깝습니다.

실제로 만들면서 겪는 고민, 선택, 실패, 그리고 다시 고치는 과정을 남기고 싶습니다.

첫 번째 글에서는 블로그를 Ghost로 시작한 이유를 정리했습니다.

그리고 이번에는 자연스럽게 그 다음 고민으로 넘어왔습니다.

블로그만으로 충분할까?

블로그는 기록에는 좋지만, 대화에는 약하다

블로그는 기록을 남기기에는 좋습니다.

제가 어떤 걸 만들고, 어떤 선택을 했고, 어디서 막혔는지를 정리하기에 좋습니다.

특히 goodtek처럼 AI automation, SaaS, 개발, 셀프호스팅, 수익화 같은 주제를 다루려면 블로그는 꼭 필요하다고 생각합니다.

하지만 블로그에는 분명한 한계도 있습니다.

블로그는 기본적으로 한 방향에 가깝습니다.

제가 글을 씁니다.
누군가 읽습니다.

물론 댓글을 붙일 수도 있습니다.

하지만 제가 만들고 싶은 goodtek의 방향을 생각하면, 댓글만으로는 조금 부족해 보였습니다.

제가 원하는 건 단순히 글을 발행하는 공간만은 아닙니다.

누군가 질문하고, 자기 경험을 남기고, 제가 놓친 부분을 알려주고, 비슷한 걸 만드는 사람들이 서로 이야기할 수 있는 공간이 필요했습니다.

블로그는 기록을 남기기에는 좋지만, 대화를 만들기에는 조금 약하다고 느꼈습니다.

그래서 블로그 다음에는 커뮤니티가 필요하겠다고 생각했습니다.

직접 만들까, 오픈소스를 쓸까

처음에는 커뮤니티 기능을 직접 만들 수도 있지 않을까 생각했습니다.

게시판, 댓글, 회원가입, 알림 정도면 어떻게든 만들 수 있을 것 같았습니다.

개발자라면 한 번쯤 이런 생각을 하게 됩니다.

“이 정도는 직접 만들 수 있지 않을까?”

그런데 조금만 더 생각해보니 바로 현실로 돌아왔습니다.

커뮤니티는 단순한 게시판이 아니었습니다.

직접 만들려면 생각보다 해야 할 게 많았습니다.

  • 회원가입
  • 이메일 인증
  • 로그인
  • 권한 관리
  • 게시글 작성, 수정, 삭제
  • 댓글과 대댓글
  • 알림
  • 검색
  • 신고와 차단
  • 스팸 대응
  • 관리자 화면
  • 사용자 프로필
  • 나중에 SSO 연동

처음에는 “게시판 정도면 되지 않을까?”라고 생각했는데, 적어보니 바로 생각이 바뀌었습니다.

지금 제가 만들려는 건 커뮤니티 소프트웨어 자체가 아닙니다.

goodtek이라는 브랜드를 만들고, 블로그와 SaaS 개발 여정을 공유하고, 그 과정에서 사람들과 대화할 공간이 필요한 것입니다.

그래서 직접 개발보다는 검증된 오픈소스 커뮤니티 도구를 먼저 보기로 했습니다.

그중 눈에 들어온 건 두 가지였습니다.

NodeBBDiscourse입니다.

NodeBB와 Discourse

둘 다 유명한 오픈소스 포럼 소프트웨어입니다.

Discourse는 이미 많은 커뮤니티에서 쓰이고 있고, 기능도 탄탄해 보였습니다.

NodeBB는 Node.js 기반이라 제 눈에 더 먼저 들어왔습니다.

앞으로 goodtek에서 만들 웹서비스나 SaaS도 대부분 JavaScript / TypeScript 쪽으로 갈 가능성이 높기 때문입니다.

처음 느낌은 이랬습니다.

Discourse는 완성도 높은 커뮤니티 플랫폼 같았습니다.

반면 NodeBB는 제가 직접 다루고, 연결하고, goodtek에 맞게 조금씩 확장하기 좋아 보이는 도구처럼 느껴졌습니다.

Discourse가 나쁘다는 뜻은 아닙니다.

오히려 기능만 보면 정말 좋아 보였습니다.

하지만 동시에 조금 큰 시스템처럼 느껴졌습니다.

첫 번째 글에서 WordPress를 봤을 때와 비슷한 느낌이 있었습니다.

좋고, 강력하고, 자료도 많고, 검증되어 있습니다.

그런데 지금 제가 필요한 것보다 조금 큰 느낌이었습니다.

기준 NodeBB Discourse
기술 스택 Node.js 기반 Ruby on Rails 기반
첫인상 가볍고 현대적인 느낌 완성도 높은 대형 커뮤니티 느낌
커스터마이징 직접 다루기 좋아 보임 구조가 조금 더 큰 느낌
셀프호스팅 가능 가능
SSO 연동 가능 성숙한 기능 존재
규모감 작게 시작하기 좋아 보임 큰 커뮤니티에도 잘 맞음
goodtek과의 궁합 웹서비스와 연결하기 좋아 보임 기능은 좋지만 조금 무거운 느낌

왜 NodeBB가 더 끌렸나

제가 NodeBB에 더 끌렸던 이유는 단순합니다.

goodtek의 기술 방향과 더 잘 맞아 보였기 때문입니다.

앞으로 goodtek은 단순 블로그에서 끝내고 싶지 않습니다.

블로그만 운영하는 게 목표라면 Ghost 하나만 잘 운영해도 됩니다.

하지만 제가 생각하는 goodtek은 조금 더 큽니다.

블로그에서 생각을 정리하고,
커뮤니티에서 대화를 만들고,
SaaS에서 실제 제품으로 검증하는 구조를 만들고 싶습니다.

처음에는 각각 따로 시작하더라도, 나중에는 하나의 goodtek 경험으로 묶고 싶습니다.

제가 머릿속으로 생각한 구조는 이렇습니다.

goodtek.xyz
├── blog.goodtek.xyz
│  └── Ghost 블로그
│    생각과 경험을 정리하는 공간

├── community.goodtek.xyz
│  └── NodeBB 커뮤니티
│    질문과 대화가 생기는 공간

└── app.goodtek.xyz
   └── SaaS 웹서비스
    실제 제품으로 검증하는 공간

블로그는 기록을 남기는 곳입니다.

커뮤니티는 대화가 생기는 곳입니다.

웹서비스는 실제 제품을 사용하는 곳입니다.

처음에는 각각 따로 시작하더라도, 나중에는 하나의 goodtek 경험으로 묶고 싶습니다.

특히 나중에는 SSO도 고려하고 있습니다.

이 구조가 잘 될지는 아직 모릅니다. 그래도 첫 번째 글에서 Ghost를 선택했듯이, 이번에는 커뮤니티 도구로 NodeBB를 선택했습니다.

완벽한 선택이라기보다는, 지금 goodtek의 방향에 가장 잘 맞는 선택이라고 생각합니다.

물론 Discourse가 더 좋은 선택일 수도 있습니다. 특히 이미 큰 커뮤니티를 안정적으로 운영해야 한다면 Discourse가 더 맞을 수 있습니다.

하지만 저는 지금 거대한 커뮤니티 플랫폼이 필요한 단계는 아니라고 느꼈습니다. 작게 시작해서, 제가 직접 이해하고, 블로그와 SaaS 사이를 자연스럽게 연결해갈 수 있는 커뮤니티가 필요했습니다.

그래서 NodeBB로 시작해보려고 합니다.

앞으로 goodtek에서는 SaaS를 만들어가는 과정, AI automation을 실제로 적용해보는 과정, 그리고 개발하면서 겪는 시행착오를 계속 기록해보려고 합니다.

블로그 댓글이나 이메일로 의견 주셔도 좋습니다. 비슷한 고민을 하고 있거나, 직접 SaaS를 만들고 있거나, AI automation에 관심이 있다면 언제든 편하게 이야기 나눠주세요.

커뮤니티가 열리면 그곳에서 goodtek의 여정을 조금 더 활발하게 공유하고 싶습니다. 질문하고, 피드백을 주고받고, 비슷한 관심을 가진 분들과 함께 고민할 수 있는 공간으로 만들어가고 싶습니다.

혼자 조용히 만드는 것보다, 비슷한 관심을 가진 사람들과 같이 고민하면서 만들어가는 쪽이 훨씬 더 오래 갈 수 있다고 믿습니다.

Read more

AI와 함께 코딩할 때 먼저 배운 것: 만든 것과 만들려던 것을 구분하기

AI와 함께 코딩할 때 먼저 배운 것: 만든 것과 만들려던 것을 구분하기

AI와 함께 코딩하면 계획, 프롬프트, 문서, 실제 코드가 쉽게 섞입니다. 이번 TASK-013에서는 공개 상태 페이지를 만들려 했지만, 실제로 ship된 것은 실시간 대시보드, 알림 테스트 상태 추적, 디자인 정합 작업이었습니다. 이번 글에서는 TASK 이름보다 머지된 코드를 기준으로 사실을 검증한 과정과, Realtime 아키텍처·비동기 상태 모델·공통 계약 관리 등 AI와 함께 개발할 때 놓치기 쉬운 기준들을 정리합니다. Build in Public 관점에서 ‘만들려던 것’과 ‘실제로 만든 것’을 구분하는 방법을 공유합니다.

By ● goodtek
감지 → 판단 → 알림: vibePulse의 심장을 만든 6개의 TASK

감지 → 판단 → 알림: vibePulse의 심장을 만든 6개의 TASK

goodtek이 만들고 있는 vibePulse는 "내가 만든 웹/API가 지금 살아 있는가"를 확인하고, 죽으면 즉시 알려주는 초간단 생존 확인 SaaS입니다. 이번 글은 그 핵심 파이프라인 — 모니터를 만들고(TASK-006), 주기적으로 찌르고(007), 장애를 판단하고(008), 신호가 끊기면 알아채고(009), 알림을 큐에 태워(010), 슬랙·카카오톡으로 보내기까지(011) — 를 한 호흡에 만든 기록입니다.

By ● goodtek