Discourse 사용 경험기

커뮤니티 구축
1

안녕하세요.

이것은 제가 meta.discourse에서 작성하는 첫 번째 주제이며, 제 의견과 Discourse를 처음 접한 결과에 대해 꼭 쓰고 싶습니다.

배경

제가 Discourse를 알게 된 것은 우연한 기회였습니다. 제 용도에 적합한 포럼 엔진을 찾던 중이었거든요. 그리고 적응 과정은 꽤 긍정적이었습니다. 특히 제가 필요로 하는 기능들이 잘 구현되어 있다는 것을 깨달았기 때문입니다:

  1. Webhooks
  2. 업적 시스템 (Achievement system)
  3. 다른 서비스와의 풍부한 통합 기능
  4. 인터페이스 현대화 및 기타 많은 것들…

솔직히 말씀드리면, Discourse의 기능에 놀랐습니다. 이 프로젝트를 지속적으로 지원해 주시는 개발자분들에게 감사드립니다.

첫 번째 문제들

하지만 안타깝게도, 제가 직접 발견한 단점들이 여전히 존재하며, 이 때문에 Discourse와의 상호작용을 지속하지 못했습니다. 순서대로 말씀드리자면, 제가 적합하다고 판단한 포럼 엔진에 대해 3가지 기준을 정했습니다:

  1. API 관리
  2. 편리한 관리 (Administration)
  3. 필요에 맞게 모든 인터페이스를 커스터마이징할 수 있는 능력.

Discourse는 API와 관리 패널에서는 잘 되어 있지만… 현대화(커스터마이징)에 깊이 들어갔을 때 막혔습니다.

저를 공격한 첫 번째 '괴물’은 Discourse 버전 간의 차이와, 그 결과로 인한 Discourse 컴포넌트와 테마 작성 방식의 차이였습니다. 어떤 것은 위젯(widgets)을 사용하고, 어떤 것은 Ember JS를, 또 어떤 것은 다른 것을 사용했습니다… 이 모든 것이 저뿐만 아니라, Discourse 학습을 가속화하기 위해 주기적으로 시도했던 AI에게도 혼란을 야기했습니다 - 하지만 다음 ‘괴물’ 때문에 AI는 오히려 저를 더 혼란스럽게 만들었습니다…

두 번째 '괴물’은 읽기 쉽고 여러 언어로 제공되는 고품질 문서의 부재입니다. 관리진분들이 이 문제에 조속히 관심을 가져주셨으면 좋겠습니다. 네, 물론 Discourse 컴포넌트와 테마를 설정하고 만드는 방법에 대한 주제들을 읽었습니다 - 하지만 그것들은 Discourse의 아키텍처를 이해하는 데 필요한 지식을 제공하지 못했습니다. 특히, 저는 우연히 이 글을 발견했습니다: Upcoming Header Changes - Preparing Themes and Plugins 이 글 덕분에 왜 베타 버전에서 항상 코드를 잘못 작성하고 있었는지를 이해할 수 있었습니다 :slight_smile: 버전 차이에 명확하고 상세한 문서가 없는 것은 Discourse의 아픈 문제입니다… 왜냐하면 이 둘의 결합은 상당한 부정적인 결과를 낳으며, 이는 제가 Discourse를 최대한 활용하는 것을 방해했기 때문입니다. 저는 포럼의 외관을 깊이 있게 현대화하는 것이 매우 필요하지만, 아쉽게도 현재 '문서’로는 이를 수행할 수 없습니다. 이 때문에 저는 아마도 당분간 Discourse와 작별을 고해야겠지만, 그 개발을 계속 지켜볼 것입니다.

그리고 세 번째 '괴물’은 Discourse에 대한 정보의 상대적인 분류화(정리) 상태입니다. 특정 정보나 특정 작업을 수행하는 방법을 찾는 것은 매우 어렵습니다. 저는 이것이 당신의 운과 영어 실력에 달려 있다고 말할 수 있습니다. 그렇지 않다면, '운 좋은 영어 사용자’가 아니라면 - 하루 이상을 씨름해야 할 것입니다. 이는 지치게 만듭니다.

마지막으로, 저에게 Discourse의 개인적인 단점은 Docker만(공식 설치 방법으로) 사용하는 것입니다. 이 진술로 인해 혐오의 물결을 맞을 수 있다고 확신하지만, 여전히 저는 이러한 제품이 우회 방법(workarounds) 없이 대체 설치 방법을 가져야 한다고 생각합니다. 때로는 기존 docker 이미지 파일을 현대화해야 할 수도 있는데 - 컨테이너 빌더 때문에 이를 구현하는 것은 매우 불편합니다. 음, 아니면 제가 올바른 방법을 찾지 못했을 수도 있고요…

결론

Discourse가 제가 지금 선택하지 않는 데 충분한 단점들을 가지고 있다는 사실과 무관하게, 저는 미래에 제 용도로 이를 선택하고 사용할 수 있을 것이라고 확신합니다. 왜냐하면 저는 이 프로젝트의 개발자와 관리자가 Discourse의 단점들(이 주제/글에 명시된 것을 포함하여)에 관심을 기울일 것이라고 기대하기 때문입니다. 제 생각에 Discourse는 이미 매우 고품질 프로젝트이지만, 아직 ‘보통’ 사용(일반 대중의 사용)에 이르지는 못한 것 같습니다. 하지만 이것은 일시적인 것입니다.

글에 관심을 가져주셔서 감사합니다.
P.s. 러시아어에서 영어로 번역할 때 AI "Manus"가 사용되었습니다.

13개의 좋아요
2

네. 10년 전에 잘 작동하던 것들이 지금은 그렇지 않은 경우가 있습니다. 이제 새로운 테마 개발자 가이드가 있습니다. 꽤 훌륭하며, 여러분의 여러 '고질적인 문제’들을 다루고 있습니다: Theme Developer Tutorial: 1. Introduction

9개의 좋아요
3

안녕하세요. 비공식 설치(unsupported-install)이지만, Docker 없이 Discourse를 설치하는 가이드가 있습니다:

4개의 좋아요
4

맞습니다. 그래서 공식적인 설치 방법이 없음을 명확히 했습니다.

5

제 가장 큰 문제는… 현재 나와 있는 많은 플러그인이 최신 설치 환경에서 설치를 하다 보면 단순히 실패한다는 점입니다.
그리고 제가 노력을 안 해서 그런 것도 아닙니다. 제 첫 사이트 설치 환경은 Ubuntu 24.04LTS와 Docker를 사용한 것이었고, 초기 설치 후 몇 가지 플러그인(최신 버전이고 지원되는 것으로 표시되어 있었죠 - 네, 맞습니다)을 추가한 후 거의 모든 재빌드 시 Discourse 앱이 완전히 엉망이 되어 정기적으로 실패했습니다.
그런 다음 해당 플러그인을 제거하고 재빌드를 시도하면… 다시 실패했습니다.
제 최종 해결책은 실제로 AlmaLinux 설치 환경으로 Docker를 다시 사용하는 것이었습니다. 적어도 이렇게 하면 현재 버전과 호환되지 않는 플러그인을 추가했을 때, app.yml에서 해당 플러그인을 제거하면 앱을 실제로 재빌드할 수 있습니다. Ubuntu 설치 환경에서는 이것이 불가능했죠.

그리고 아니요, 저는 웹사이트 운영에 있어 새로운 관리자가 아닙니다. 저는 10년 이상 포럼 기반 웹사이트를 운영해 왔으며, Woltlab, Xenforo, Invision, SMF, phpBB, myBB, NodeBB 및 기타 여러 플랫폼에 대한 경험을 갖추고 있습니다. 심지어 MS-DOS/DesqView 시대와 멀티노드 BBS(최종적으로 OS/2 Maximus/2 멀티노드 시스템으로, 4개의 노드 중 3개는 사용자가 직접 접근할 수 있었고, 4개 모두 FidoNet 메일을 처리할 수 있었습니다)까지 거슬러 올라가는 경험도 있습니다. 따라서 저는 이 분야에 대해 전혀 낯선 사람이 아닙니다.

제 사이트(my site)에서 Discourse를 운영하고 있는데, 지금까지 본 부분에는 만족합니다. 하지만 셀프 호스팅 사이트를 운영하는 초보자들이 이 시스템에서 겪을 수 있는 문제들이 어디에 있는지 빠르게 파악할 수 있습니다. 저는 현재 여러 사이트에서 Xenforo와 NodeBB를 운영하고 있는데, 솔직히 말하면 멀티 사이트 시스템에 대한 NodeBB 설정은 Discourse의 제공 방식보다 훨씬 다루기 쉽습니다. VPS 인스턴스에서 NodeBB 4개 노드를 실행하는 것이 VPS 설치 환경에서 단일 Discourse 노드를 실행하는 것보다 영향이 적다는 점에 대해서는 언급조차 하지 않겠습니다. 그리고 네, 저는 멀티 사이트 사용에 대해 조사해 봤습니다… 하지만 현재로서는 그만한 가치가 없는 번거로움입니다. 그리고 네, 저는 다양한 스크립트로 놀아보는 것을 좋아합니다… 그리고 그 중 어떤 것에서든 발견하는 결점을 지적하는 데 전혀 문제가 없습니다. :wink:

Discourse는 탄탄한 기반을 가지고 있습니다… 하지만 셀프 호스팅 환경에서 관리자가 여러 사이트를 운영할 때, 현재와 같은 복잡한 과정을 거치지 않고 더 쉽게 할 수 있도록 개선이 여전히 필요합니다.

1개의 좋아요
6

아, Telegard Hack BBS가 있던 DOS 시대였죠. 가장 인기 있는 BBS 중 하나는 Renegade BBS였습니다. 하지만 자체 스크립트 프로그래밍 언어를 가진 PCBoard, 그리고 Amiga와 Commodore 64 BBS도 기억해 주셨으면 합니다. 정말 재미있던 시절이었죠.

저는 Ubuntu LTS에서 Discourse를 운영하는 행운을 누렸습니다. 플러그인 설치가 제대로 되지 않았을 때, 보통 플러그인 줄을 삭제하거나 주석 처리하는 것만으로 최소한의 문제만 발생했습니다. 하지만 가끔은 실패했을 때 두 번 다시 빌드해야 하는 경우도 있었습니다.

7

제가 겪었던 문제는 목록에 있는 플러그인이 있을 때 절대 다시 빌드가 되지 않다는 것이었습니다.
하지만 제가 겪고 있던 추가적인 문제도 발견한 것 같습니다. 설정 파일이 정확하지 않으면(새 줄에 불필요한 공백이나 탭이 있는 경우) 플러그인을 추가할 때 잘 동작하지 않는 것 같습니다. 플러그인 목록 아래에 있는 모든 빈 줄을 제거한 후, 이제 플러그인이 정상적으로 빌드되는 것 같습니다.
대부분이 Ubuntu를 사용한다는 것을 알고 있으며, 이는 훌륭한 운영체제입니다(제가 사용하는 천체사진 촬영 소프트웨어의 기반이기도 합니다). 하지만 저는 이미 꽤 오랫동안 AlmaLinux를 사용하며 선호하고 있으며, 실제로 잘 작동하는 것 같습니다.

1개의 좋아요
8

네, yml 파일은 레이아웃에 꽤 까다로워요.

9

음… 나도 그걸 깨닫고 있어요. 솔직히 말하면, 이 스크립트는 여러모로 약점이 많아요.
저는 유료 스크립트를 사용하는데, 플러그인(애드온) 설치 기능이 훨씬 더 통합되어 있어요. 그런데 안타깝게도 그 스크립트도 현재로서는 돈을 지불한 라이선스 보유자에게 제공해야 할 수준에 아직 못 미치고 있어요.
디스코urs 개발진이 텍스트 기반 설정 파일을 수정할 필요 없이 스크립트 자체에서 애드온을 직접 설치할 수 있도록 통합해 준다면, 이는 엄청난 개선이 될 거예요. 하지만 안타깝게도 다른 몇몇 스크립트와 마찬가지로, 개발진들은 자기 방식에 고집을 부리며 많은 사람들이 앞으로 나아가는 방향으로 보는 것을 원하지 않는 것 같아요.

사람들에게 그들에게 가장 적합한 스크립트를 추천하는 데에는 전혀 문제가 없어요. 하지만 초보자의 경우, 디스코urs는 여전히 셀프호스팅에 적합하지 않아요. 특히 하나의 서버 인스턴스에서 여러 사이트를 운영하려는 경우에는 더욱 그렇습니다.
저는 한 사이트에는 계속 사용하겠지만, 디스코urs를 하나의 서버에서 멀티호밍하는 것은 여전히 큰 골칫거리(PITA)예요. 심지어 NodeBB도 많은 측면에서 디스코urs가 제공하는 것보다 더 나은 기능을 갖추고 있어요.

1개의 좋아요
10

솔직히 말해서, 이 도구는 사용자 친화적인 편은 아닙니다. @pfaffman 님이 웹 인터페이스를 제공하고 계신데, 제 기억이 맞다면 플러그인 설치 등 다양한 작업을 자동화할 수 있고 여러 가지 추가 혜택도 있습니다. 다만 연 단위 과금 방식이지만, 제 생각에는 제공하는 기능에 비해 가격대가 꽤 합리적입니다.

2개의 좋아요
11

감사합니다. 하지만 저는 XenForo와 NodeBB 모두에서 ACP를 통해 직접 설치할 수 있는 데 익숙합니다.
그 특이점을 알아냈으니, 이제 그 기능을 위해 돈을 내는 번거로움은 별로 필요 없다고 봅니다. :wink:
저는 수익이 전혀 없는 사이트/서버에 이미 연간 약 2,800달러를 지출하고 있습니다. 제게 이건 그냥 취미일 뿐이니까요.
스크립트에 돈을 투자하려면, 단순한 포럼에 몇 가지 튜닝을 한 것 이상으로 훨씬 더 많은 기능을 갖추길 원합니다. 그래서 제가 운영하는 우주 관련 사이트가 있는 것이죠.

2개의 좋아요