애호가 플러그인 개발자 사례 연구

2024년 나는 일자리를 구하고 있었습니다. 저는 커뮤니티 컨설턴트로서 제 서비스를 제공하기로 결정했습니다. 하지만 대부분의 경우, 사람들은 자신의 Discourse 사이트를 수정하거나 업데이트하는 데 도움이 되는 기술적인 지원을 원했습니다. 잠재적 고객 중 한 명은 계정이 없는 사람들이 피드백을 보낼 수 있도록 연락처 양식을 추가할 수 있는지 물었습니다. 저는 주변을 둘러본 끝에 그것이 불가능하다는 결론을 내렸습니다. 하지만 저는 충분한 여가 시간이 있었기 때문에 플러그인 개발자 튜토리얼을 따라가며 제가 할 수 있는 일이 무엇인지 확인해 보았습니다. 결국 저는 연락처 양식 플러그인을 개발했고 그 고객을 확보했습니다.[1]

모두가 명확하게 이해할 수 있도록 말씀드립니다: 저는 프론트엔드 프로그래머가 아닙니다! 제가 어떤 종류의 전문 프로그래머로 활동했던 지 13년이 지났습니다. HTML 양식을 만드는 법을 아는 정도가 제 지식의 한계입니다. 그래서 저는 튜토리얼의 Ember와 Handlebars 섹션을 헤매며, 충분히 잘 작동하는 해킹 코드를 조립해 냈습니다. 다행히도 저는 이전 직장에서 템플릿 시스템을 사용해 본 경험이 있어 템플릿 시스템에 익숙했습니다.

저는 OpenSSL Foundation에서 일자리를 얻었고[2] 대부분의 고객들을 포기했습니다. 하지만 플러그인을 만들어 준 고객은 제 작업을 정말로 높이 평가해 저를 유지보수 계약에 남겼습니다. (저는 그에게 몇 가지 무관한 프로젝트도 수행했습니다.) 유지보수 계약금을 벌기 위해 저는 그의 Discourse 서버를 업그레이드하기로 결정했습니다. 제가 본 것은 다음과 같았습니다:

이것은 제 고객 사이트에서만 발생했습니다. 제가 멍청하게도 스테이징 사이트에 연락처 플러그인을 설치했지만 활성화하지 않았기 때문입니다. 그래서 저는 빠르게 안전 모드로 진입하여 플러그인을 비활성화했습니다. 지난 주말에 저는 무엇이 잘못되었고 고객을 위해 어떻게 수정할 수 있는지 파악하는 데 시간을 보냈습니다.

일부 검색 끝에, 저는 테마와 플러그인에서 .hbs 파일 확장자 비추천을 발견했습니다:

최신 버전의 Discourse에서 테마와 플러그인에 .hbs 파일을 사용하는 것은 비추천(deprecated)되었습니다. 이 파일 형식에 대한 지원은 다음 ESR 릴리스 이후에 제거될 것입니다.

이것은 3월에 발표된 내용으로, 만약 제가 ESR 릴리스를 사용했다면 기본적으로 9월 말까지 수정할 시간이 있었을 것입니다. 하지만 제 Discourse 설정은 "tests-passed"[3]를 사용하고 있기 때문에, 저는 몇 개월 앞서서 그 오류를 받게 된 것 같습니다.

어쨌든 수정해야 하므로(또는 고객을 실망시켜야 하므로) 저는 설명서로 바로 뛰어들었습니다: 테마와 플러그인을 .gjs 파일 형식으로 자동 업데이트하기. 첫 번째 단계는 개발 환경 설치였습니다. 마지막으로 이 작업을 시도했던 때 이후로 노트북을 바꿨기 때문입니다.[4] 마침내 Discourse를 실행하고 제 플러그인이 로컬에서 깨져 있음을 확인한 후, 저는 린트 과정을 실행했습니다.[5]:

$ pnpm eslint --fix .

/Users/jericson/src/discourse-contact-plugin/assets/javascripts/discourse/components/contact-form.js
   1:8   error  Use Glimmer components(@glimmer/component) instead of classic components(@ember/component)          ember/no-classic-components
   3:16  error  Native JS classes should be used instead of classic classes                                         ember/no-classic-classes
   3:16  error  Please switch to a tagless component by setting `tagName: ''` or converting to a Glimmer component  ember/require-tagless-components
  20:3   error  Use the @action decorator instead of declaring an actions hash                                      ember/no-actions-hash

✖ 4 problems (4 errors, 0 warnings)

플러그인을 변경해야 한다는 점이 귀찮기는 하지만, 적어도 린트 과정이 제 코드를 정리하고 현대화하는 데 도움이 되었습니다. 하지만 자동화 스크립트는 .gjs로 변환하는 것을 시도하다가 실패했습니다. 그래서 저는 https://ask.discourse.com/ 을 사용해 보기로 했습니다.

거기에는 제 질문이 12개 있습니다. 저는 인간과 공유하지 않을 것입니다. 왜냐하면 그것은 점점 더 좌절된 프로그래머의 발버둥에 불과하기 때문입니다. 어느 시점에서 봇은 제 하위 문제 중 하나에 대해 "더 견고한 현대적 접근법"을 제안했는데, 그것은 . . . .js 파일과 .hbs 파일을 포함하고 있었습니다.

감독이 *8½*에 대한 비평가의 부정적인 리뷰를 쓰레기통에 던지는 *8½* 스틸.

이것이 왜 일어나는지 저는 압니다. 이는 Meta Discourse 토론으로 학습되었기 때문이며, 여전히 Handlebars 코드가 포함된 게시물이 많이 있습니다. 여기에는 공식 플러그인 개발자 튜토리얼의 두 번째 부분도 포함됩니다. 그 내용들은 시간이 지나면서 업데이트될 것이지만, 공식적인 조언이 업그레이드 관련 도움을 받기 위해 Meta Discourse에서 질문하는 대신 채팅 봇에게 묻도록 권장하고 있기 때문에, 조금 더 시간이 걸릴 것 같아 우려됩니다.

불평하지 말아야 할 것 같습니다. 제 코드를 정리하는 데 도움이 되었고, 아마도 인간에게 묻는 것보다 더 적은 마찰로 이루어졌을 테니까요.

플랫폼 안정성

이제 저는 OpenSSL Foundation에서 일하고 있습니다. Heartbleed 때문에 OpenSSL에 대해 알고 계실 것입니다. 그것은 어디에나 사용됩니다. 가장 인기 있는 다운로드 버전은 2023년에 수명 종료(end-of-life)에 도달한 1.1.1입니다. 다음으로 인기 있는 것은 2021년에 출시되었지만 여전히 장기 지원(LTS) 릴리스로 지원되고 있는 3.0입니다. 다음은 우리의 최신 LTS인 3.5입니다. 이 세 가지 릴리스는 GitHub 다운로드의 거의 2/3를 차지합니다.

3.5에는 몇 가지 멋진 새로운 기능이 있지만, 이는 다소 실망스러운 부분입니다. 하지만 궁극적으로 사람들이 가장 중요하게 여기는 기능은 SSL/TLS암호화 원시 기능의 어떤 조합일 것입니다. 양자 내성 암호화 알고리즘에 열정을 느끼지 않는 한, 업그레이드의 고통을 가능한 한 오래 미루게 될 것입니다.

물론 OpenSSL은 Discourse보다 스택의 훨씬 아래에 위치합니다. 하지만 원리는 동일합니다. 새로운 기능이 없다면, 사람들은 깨지는 업그레이드(breaking upgrades)에 관심이 없습니다. 저는 _여러분_이 Discourse에 추가된 새로운 기능에 대해 설레는 것을 압니다. 나중에 몇 가지 최적화를 얻기 위해 API를 변경하고 싶은 마음을 이해합니다. 저는 단지 너무 빠르게 움직이는 것이 커뮤니티가 구축되는 플랫폼으로서의 Discourse에 해가 될까 봐 우려할 뿐입니다.

그것에 관해 말하자면, Alex Komoroske가 작성한 Gardening Platforms라는 매우 유용한 슬라이드 덱이 있습니다. 90번째 슬라이드에서 "Platform + Ecosystem"이라는 섹션이 시작되며, 플랫폼은 그 생태계와 공진화(coevolve)해야 한다는 것을 설명합니다. 이 경우, Discourse는 플러그인과 테마 디자이너, 호스팅 서비스, Meta Discourse 커뮤니티, 그리고 심지어 Discourse 위에 구축된 커뮤니티까지 포함하는 생태계를 지원하는 플랫폼입니다. 98번째 슬라이드의 발표자 노트에서 중요한 통찰:

하지만 그것들은 독립적이지 않습니다; 그것들은 상생적으로 관련되어 있습니다.

한쪽에서 일어나는 행동은 다른 쪽에 영향을 미치고, 그 반대도 마찬가지입니다. 그것들을 양방향으로 연결하는 피드백 루프라고 생각하십시오.

그것들은 강하게 묶여 있는 것이 아니라, 그것들을 연결하는 고무줄과 더 비슷합니다. 그것은 중력적 끌음입니다.

플랫폼과 생태계가 서로에 대해 너무 빠르게 움직이면, 그 유대는 재앙적인 효과로 끊어집니다. 저는 Discourse가 생태계에 정당한 대우를 할 것이라고 신뢰합니다. 단지 지난 주말 같은 주말들이 그 신뢰를 약화시킬 뿐입니다.


  1. 결과적으로 상당히 정적인 사이트가 되었지만, 제 작업에 대해 꽤 자부심을 가지고 있습니다. ↩︎

  2. 예고편! ↩︎

  3. 이것도 업데이트가 필요합니다 ↩︎

  4. Redis와 Rails를 설치하는 것이 기억하는 것보다 더 어려웠습니다. ↩︎

  5. 하지만 eslint.config.mjs가져오는 데 많은 시간을 허비한 후에야 말입니다. ↩︎

지금 바로 플러그인 업데이트가 필요해서가 아니라 이 버그 때문에 오류가 발생한 것 같습니다.

저도 제가 작성한 여러 플러그인에서 같은 경험을 했습니다. Discourse 표준에 맞게 이를 현대화할 여유가 없었거든요. 저는 데이터 과학 관련 직무를 맡고 있어서 소프트웨어 엔지니어링 개념은 알고 있지만, 웹 개발의 세부적인 최신 동향까지 계속 따라가지는 못합니다. 결국 이 비추천(deprecated) 플러그인에 의존하고 있었기 때문에 8개월 동안 제 사이트를 업데이트하지 못했습니다.

질문자님의 고충을 가볍게 여긴다는 뜻은 아니지만, 기본적으로 에이전틱 코딩(agentic coding)의 등장으로 인해 이러한 개발 속도는 더 이상 문제가 되지 않는다고 생각합니다. 제가 직접 고치고 제대로 동작하게 만드는 데 일주일에서 두 주 정도가 걸렸을 일을, 20달러짜리 Claude Code 구독료와 플러그인당 몇 분의 노력으로 해결할 수 있었습니다. 게다가 성능 최적화까지 할 수 있었습니다. 에이전틱 코딩을 몇몇 업무 및 취미 프로젝트에 사용해 본 후로는, 제 인생에서 더 이상 무언가를 처음부터 직접 코딩하지는 않을 것 같습니다. 손편지를 써서 직접 전달하는 것과 이메일을 보내는 것의 기술적 차이와도 같습니다. 약간 쓸쓸한 기분이 들면서도, 동시에 신적인 수준의 힘을 얻은 것 같은 기분이 듭니다.

그렇네요. 최신 ESR으로 업그레이드하고(테스트 시 조금 더 주의를 기울이는 것) 앞으로는 좋은 계획인 것 같습니다.

개발 속도 자체가 문제라고 생각하지 않습니다. _모든 것_의 속도가 문제입니다. 예를 들어 플러그인 튜토리얼은 왜 아직 업데이트되지 않았습니까? 플러그인을 만들고자 하는 불쌍한 누군가의 얼굴에 폭발할지 모를 지뢰와 같습니다. 당장은 작동하겠지만, 결국 저와 같은 문제에 직면하게 될 것입니다. 해결책은 나중에 AI를 이용해 플러그인을 수정하는 것이 아니라, 지금 플러그인 제작에 관한 설명서를 수정하는 것입니다. 말하자면, 여전히 구식 방식을 가르킬 이유는 없지 않습니까?

우리는 거대한 코드베이스를 유지보수하는 상대적으로 작은 팀이며, 유료 고객들을 위한 새로운 기능을 구현해야 하고, 동시에 오픈소스 커뮤니티를 위해 지원을 제공하고 시스템을 정상적으로 유지해야 합니다.

하루에 할 수 있는 일은 한계가 있고, 문서화는 종종 그 뒤를 따라갑니다.

분들의 답답한 마음을 충분히 이해하지만, 이 점도 언급할 가치가 있다고 생각합니다.

상세한 정보를 제공해 주셔서 감사합니다, @jericson. 말씀하신 대로, Discourse는 사용 방식과 스택 내 위치 면에서 OpenSSL과 매우 다른 위치에 있습니다. 이는 진보, 사용자 정의 가능성, 안정성 사이의 끊임없는 균형 조절 과정입니다. 모두를 만족시킬 완벽한 해결책은 없지만,我们始终 고객과 오픈소스 커뮤니티의 피드백을 반영하고 있습니다. 공유해 주신 인용구가 정말 마음에 듭니다:

:chefs_kiss:

@moin님이 언급하신 대로, .hbs 비표준화(deprecation)와 관련하여 경험하신 문제는 약 한 주 동안 latest 버전에서 발생한 버그였습니다. 그 점에 대해 정말 죄송합니다! .hbs 사용은 비표준화되었지만 여전히 지원됩니다. 이제 당신의 .hbs 코드가 다시 정상적으로 작동해야 합니다.

이 부분을 지적해 주셔서 감사합니다. 문서에 남아 있는 .hbs 언급을 정리하기 위해 한 번 검토를 해 보았습니다:

전적으로 이해합니다.[1] 저는 Discourse를 정말 좋아합니다 이 글을 쓴 이유는 Discourse가 지속적인 성공을 거두기를 원하기 때문입니다.

제가 배운 것은 커뮤니티가 변화를 좋아하지는 않지만, 그들이 주도권을 가졌다고 느끼면 변화에 훨씬 더 개방적이라는 점입니다. 사람들에게 주도권을 부여하는 방법은 무궁무진합니다. 예를 들어, 튜토리얼을 위키 게시물로 전환하면 저 같은 사람들이 이를 업데이트할 수 있습니다. ESR 계획을 구현하는 것도 도움이 되는데, 이는 사람들이 즉시 변경 사항을 적용하지 않을 선택지를 주기 때문입니다.[2] 제 경험을 작성하여 오픈소스 프로젝트를 관리하는 사람들에게 보여줄 수 있는 것도 도움이 됩니다. 특히 제가 불평했던 문제들이 하룻밤 사이에 수정되었기 때문입니다. :wink:

"사용자 청취가 해롭다고 생각되나요?"라는 글에서[3] 캐시 시에라(Kathy Sierra)는 이렇게 썼습니다:

우리 대부분은 포커스 그룹이 많은 측면에서 notoriously 비효율적이라는 것을 인식하지만, 여전히 실제 사용자로부터의 실제 피드백을 청취하는 것이 새로운 제품과 서비스를 주도하고 기존 것을 개선하는 최선의 방법이라고 가정합니다. 그러나 여기에는 큰 문제가 있습니다 – 사람들은 자신이 상상해 본 적이 없는 것을 어떻게 요청해야 하는지 반드시 알지 못합니다! 대부분의 사람들은 점진적인 개선에 기반하여 제안을 합니다. 존재하는 것을 보고 그것이 어떻게 더 나아질 수 있을지 생각해보는 것이죠. 하지만 그것은 근본적으로 새로운 무언가에 대한 비전을 가지는 것과 매우 다릅니다.

진정한 혁신은 사용자가 직접 말하는 것에서 거의 나오지 않습니다.

말했듯이, 저는 프론트엔드 개발자가 아닙니다. 왜 이러한 변경 사항이 이루어졌는지 또는 그것이 저에게 어떤 이점을 줄지 정확히 이해하지 못합니다.[4] 그리고 그것이 궁극적으로 Discourse를 더 좋게 만든다면 괜찮습니다.

그래도, 비전을 조금 더 명확하게 볼 수 있다면 저 같은 사람들이 적응하는 데 도움이 될 수 있습니다. 이 변경 사항에 대한 제안은 다음과 같습니다:

  1. 훨씬 더 나은 개발 경험
  2. 향후 버전의 Discourse에서 대규모 성능 향상을 가능하게 함

좋아 보이긴 하죠? 저는 #1과 #2가 많은 것을 의미할 수 있다는 것을 특별히 인지하지 못했습니다. 저에게 더 효과적인 것은 다음과 같은 것일 것입니다(전적으로 제가 지어낸 것입니다):

  1. 공식 Discourse 플러그인을 변환할 때 코드 라인 수를 X% 줄인 것을 발견했습니다. 템플릿을 JavaScript와 동일한 파일에 두면 코드를 이해하고 나중에 수정하기가 더 쉬워집니다.
  2. Handlebars를 완전히 제거하는 것을 테스트하는 브랜치를 설정했는데, 그 변경 사항으로 페이지 로딩이 X% 빨라지는 것을 발견했습니다. 뿐만 아니라, [사용자들이 제기한 일부 문제]를 제거할 수 있는 잠재적 최적화도 발견했습니다.

비전문가를 교육하는 데 초점을 맞춘 조금 더 자세한 설명은 신뢰를 유지하는 데 큰 도움이 됩니다. 저는 변경 사항을 좋아하지 않을 수 있지만, 다른 사용자가 직면한 실제 문제를 수정하는 것과 어떻게 논쟁할 수 있겠습니까?


  1. OpenSSL도 비슷한 동력을 가지고 있습니다. 지원 계약을 판매하는 법인(약 15명)과 비상업적 이익을 관리하는 재단(저를 포함하여 10명)이 있습니다. 우리의 문서도 뒤처져 있습니다. 원본 글을 작성하면서 지난월에 제거된 기능에 대한 참조가 여전히 남아있다는 것을 발견했습니다. 이를 위한 PR을 작성하고 있습니다. 또한 하류 프로젝트들이 매우 비판적으로 평가한 몇 가지 변경 사항을 수행했습니다. ↩︎

  2. 최신 기능을 선호하는 커뮤니티를 지원하려는 플러그인 개발자에게는 도움이 되지 않습니다. 하지만 제 플러그인을 사용하는 유일한 사람이라고 생각하므로 저에게는 매우 좋습니다. ↩︎

  3. 그녀의 블로그는 인터넷에서 사라졌지만, PDF 아카이브가 있습니다. ↩︎

  4. 큰 그림에서 제가 그렇게 중요하지는 않다는 것을 알면서도요. 저는 Discourse에 의존하는 다른 사람들을 대변하는 제 자신에 대해 이야기하고 있습니다. 결국, 대부분의 사람들보다 제 자신을 더 잘 알고 있으니까요! ↩︎

그렇게 하려면 왜 꼭 위키여야 합니까? 개발자 문서는 GitHub을 통해 관리됩니다. 저는 위키보다 변경 사항이 검토되는 프로세스를 더 좋아합니다.

이 시점에서 플러그인 문서가 업데이트되어야 한다는 점에 동의합니다. 플러그인은 여전히 작동하지만 사이트가 곧 깨질 것이라는 경고를 표시하는 “비추천(deprecation)” 기간의 목표는 플러그인 개발자에게 수정할 충분한 시간을 주는 것입니다. 그런데 그 기간 동안 풀타임으로 급여를 받는 개발자 팀조차 핵심 플러그인 개발 문서를 업데이트하지 못했습니다. 팀이 같은 기간 동안 이를 완전히 관리하지 못하는 상황에서 개인 개발자에게 이러한 기대를 하는 것은 다소 이상한 일입니다.

저에게 이것이 시사하는 바는 개발 속도가 너무 빠르거나, Discourse에서 플러그인 개발자가 중요한 우선순위가 아니라는 것입니다. 개인적으로는 후자가 더 큰 이유라고 생각합니다. 무언가는 우선순위에서 밀려날 수밖에 없으므로, 이는 비판이라기보다 제 관찰입니다. Discourse는 여전히 플러그인을 통해 완전히 커스터마이징할 수 있으며, 지속적인 개선에 감사드립니다.

그러나 모든 것을 종합하면, 보일러플레이트 플러그인을 만드는 단계별 문서 가이드는 이제 구식 아이디어라고 생각합니다. 아마추어 플러그인 개발자에게 필요한 것은 에이전트가 읽고 플러그인 골격을 구축할 수 있는 단일 컨텍스트 문서뿐입니다. 실제로 Discourse와 같은 오픈소스 코드베이스의 경우, 에이전트가 코드베이스 자체에서 직접 컨텍스트를 얻기 때문에 문서가 전혀 필요하지 않습니다. 제가 플러그인을 작업할 때 Claude가 기존 플러그인을 읽으며 디자인 패턴을 학습하는 것을 보았습니다. 또한 핵심 코드에서 버그를 찾아내는 데에도 성공했습니다: Chat Pitchfork timeouts: replies silently create threads and auto-tracking bloats over time

결론적으로, 아마추어 플러그인 개발자가 되고자 하는 이 글을 읽는 모든 분께 말씀드리자면, 문서가 오래되었을 수 있지만 플러그인을 만드는 일은 과거 어느 때보다 1000배나 쉬워졌습니다.

이 점에 대해 명확히 하자면: hbs에 대한 비추천(deprecation) 타임라인은 최근에야 시작되었습니다. 지원 종료(drop support)를 고려할 수 있는 가장 빠른 시점은 다음 ESR(7월 말) 이후입니다. 따라서 네, 우리는 더 일찍 문서를 업데이트했어야 했지만, 이는 ‘충분한 경고 없이 지원을 중단하는’ 경우는 아닙니다. .hbs는 여전히 지원되고 있으며, 필요한 변경 사항을 위해 충분한 시간이 있습니다.

우리는 600개 이상의 테마와 플러그인을 유지 관리하고 있으므로, 이러한 마이그레이션의 고통을 우리도 충분히 느끼고 있다고 확신합니다. 우리는 모두를 위해 변경 사항을 최대한 부드럽게 만들기 위해 최선을 다하고 있으며, 우리가 만드는 각 변경 사항에서 계속 배워나갈 것입니다.

:100: 맞습니다

우리는 아직 이것이 완전히 갖춰지지는 않았습니다. 하지만 우리는 핵심 저장소에 스킬 디렉터리를 구축하기 시작하고 있습니다. 또한, AI 에이전트가 참조하기 쉽게 하기 위해 개발 문서 마크다운 파일 전체를 핵심 저장소로 이동시켰습니다.

Ember 6 업그레이드(제게는 큰 업그레이드 장애물이었던)를 위한 플러그인 수정과 hbs 마이그레이션을 동시에 진행했기 때문에, 제 머릿속에서 개념들이 혼동된 것 같습니다. 지나치게 단정적으로 말해버려서 죄송합니다!

하지만 만약 Discourse가 사용자가 만든 플러그인 생태계를 성장시키고 싶다면, 현대적인 “바이브코딩(vibecoding)” 튜토리얼이 유용할 것 같습니다. 하지만 다시 한번 말하지만, 바이브코딩으로 작성된 플러그인의 물결이 쏟아지는 것을 허용하는 것이 바람직한 일일까요? 단언하기 어렵습니다 :smile:

아! 도움이 되네요. PR을 제출했습니다.

문서를 GitHub에 올리는 방식을 좋아합니다. 위키 포스트를 편집하는 것보다 변경 사항을 제출하는 데 훨씬 더 많은 노력이 필요하지만, 검토 단계는 도움이 됩니다. (그리고 플러그인 개발자 문서의 경우, Git에 대한 지식을 요구하는 것은 그다지 높은 장벽이 아닙니다.)