최신 버전의 Discourse에서는 테마와 플러그인에 .hbs 파일을 사용하는 것이 비추천(deprecated)되었습니다. 이 파일 형식에 대한 지원은 다음 ESR 릴리스 이후에 제거될 예정입니다.
Handlebars 템플릿은 더 현대적인 .gjs 형식으로 교체해야 합니다. 이 형식은 개발 경험을 훨씬 향상시킬 뿐만 아니라, 향후 Discourse 버전에서 큰 성능 향상을 가능하게 합니다.
단순한 경우, 코드를 https://ask.discourse.com/ 에 공유하고 .gjs 형식으로 다시 작성해 달라고 요청할 수 있습니다.
더 복잡한 경우를 위해서는 다음 codemod을 사용하여 업데이트를 자동화할 수 있습니다:
2026.7에서는 여전히 hbs 파일을 지원하고, 2027.1가 이를 지원하지 않는 첫 번째 ESR 릴리스라는 점을 제가 올바르게 이해한 건가요?
네, 정확합니다.
2026.8.0-latest에서 지원을 중단할 가능성이 가장 높습니다. 다만 실제 사용 데이터와 커뮤니티 피드백에 따라 그 시점이 더 늦어질 수도 있습니다.
이것을 방금 발견했는데, 업데이트가 필요한 것 같습니다.
감사합니다! 지난 1년 동안 관리자 배너를 통해 비추천(deprecated) 처리되어 왔기 때문에, 대부분의 사용자가 이미 관련 작업을 완료했을 것으로 생각합니다. 혹시 모르니 다음 내용을 추가했습니다:
저는 제 개인용 작은 플러그인에 대해 시도해 보았으며, ask Discourse의 도움으로 hbs 파일과 js 파일을 하나의 gjs 파일로 병합하는 데 성공했습니다.
저처럼 개발에 어려움을 겪고 있는 분들에게는 이 문제를 해결하기 위해 ask Discourse의 사용을 강력히 권합니다. 
훌륭합니다! OP에도 ask.discourse.com에 대한 메모를 추가했습니다. 파일이 몇 개뿐이라면 아주 잘 작동할 수 있습니다 
.gjs 파일이 뭔지 전혀 모르겠고, 그것에 대해 공부하고 여러 플러그인을 다시 작성할 시간도 없습니다. 이건 정말 터무니없습니다.
Discourse의 플러그인 API처럼 취약한데도, 왜 굳이 플러그인 API를 제공하는지 그 의도가 궁금합니다. 이 포럼 소프트웨어의 플러그인을 유지보수하는 일은 문제만 일으켰을 뿐입니다.
그것은 터무니없는 일이 아닙니다.
커스터마이징을 관리할 예산이나 여력이 없다면, 설정을 단순화할 것을 권합니다.
제 생각에는, 끊임없이 혁신하고 성능을 개선하며 빈번한 보안 패치를 배포하고 변화하는 표준을 따라가는 최첨단 고(高)속 플랫폼에 머무르는 데 드는 (합리적인) 대가라고 볼 수 있습니다.
Discourse 팀은 기능이 사라지기 전에 충분한 시간 전에 비추천(deprecation) 경고 메시지를 표시하도록 많은 노력을 기울이는 것으로 보입니다.
기능이 적은 비보안 플랫폼에 머무는 것이 더 낫겠습니까?
무료로 다운로드할 수 있는 잘 관리되는 코어에서 얻는 가치를 생각해 보세요.
.gjs 파일이 무엇인지 알 필요가조차 없습니다: Automatically updating themes and plugins to .gjs file format
제 작은 플러그인에는 작동하지 않았습니다. 
하지만 ask.discourse.com의 도움으로 제 코드를 읽고 hbs와 js 파일을 .gjs로 변환해 주었습니다. 그래서 첫 번째 방법이 작동하지 않으면 주저하지 말고 도움을 청하세요.
이 내용도 여기에서 답변된 것으로 보입니다:
또한,
여기서 플러그인, 테마 또는 컴포넌트를 개발해본 모든 사람은 비추천(deprecation)과 강제 업데이트에 직면하고 있다는 점을 이해하고 있습니다.
다른 몇몇 사용자도 불만을 표하고 있습니다:
저는 더 이상 어떤 Discourse 플러그인 작업도 하지 않을 것입니다. 정말로 그럴 가치가 없기 때문입니다.
다른 사람들이 제 플러그인 중 두 개를 사용하고 있는데, 다른 사람에게 문제를 일으키지 않고 삭제하는 절차가 무엇인가요?
몇 달에 한 번씩, 대개는 전혀 이해할 수 없는 이유로 플러그인이 깨지는 것을 견디다 못했습니다. 그리고 포럼이 정상적으로 작동하도록 유지하는 데만 얼마나 많은 시간과 노력이 드는지 모릅니다.
저는 "최신 트렌드를 따라가는 것"을 원하지 않습니다. 그저 작동하고 안정적인 웹 포럼을 원할 뿐입니다.
보안 업데이트가 필요하기 때문에 "업데이트하지 않는 것"도 선택지가 아닙니다. 제가 마지막으로 불만을 제기했을 때 누군가 그걸 제안한 건 정말 터무니없는 일이었습니다.
Discourse 팀은 호환성에 더 신경 쓰고 기존 포럼이나 코드를 깨뜨리지 않도록 해야 합니다. 그들은 이에 대해 전혀 생각하지 않는 것 같습니다. 자기들 쪽에서 조금 더 깔끔하게 정리하기 위해 호환성을 깨뜨리는 변경사항을 도입합니다. 다른 사람들이 사용하는 플랫폼과 API를 그렇게 관리하는 것은 아닙니다. 저는 더 이상 이 일에 관여하고 싶지 않습니다.
그런 소식이 정말 죄송합니다!
이 방향으로 진행하시길 원하신다면, README와 메타(Meta) 토픽에 주석을 달고 broken 태그를 붙인 뒤 GitHub 저장소를 아카이빙하는 것을 권장합니다. 이렇게 하면(라이선스가 충분히 허용적인 경우를 전제로) 다른 사람들이 포크를 할 수 있도록 계속 유지됩니다.
우리는 호환성과 시스템의 정상 작동에 대해 절대적으로 신경 쓰고 있습니다. 그래서 완전 자동화된 업그레이드 경로를 갖춘 긴 비추천(deprecation) 기간을 두고 있는 것입니다.
우리는 항상 커스터마이징의 유연성과 안정성 사이의 균형을 맞추려고 노력하고 있습니다. Discourse 테마와 플러그인이 강력한 이유는 브라우저/프레임워크의 기본 API에 직접 접근할 수 있기 때문입니다. 이러한 막대한 힘에는 기본 변경 사항에 발맞춰 최신 상태를 유지해야 하는 일정한 책임이 따릅니다.
그렇습니다 - 최신 상태를 유지하는 것은 중요합니다. 지난 몇 달간 우리는 릴리스 파이프라인에 대대적으로 투자하여 ESR(이전에는 'stable’로 불렸던) 사용자의 환경을 훨씬 더 좋게 만들었습니다. 자세한 내용은 여기에서 확인하실 수 있습니다. 여전히 업데이트가 필요하지만, 타이밍과 시급성에 훨씬 더 많은 유연성이 부여되었습니다.
이 특정 비추천(deprecation)에 대한 해결책은 완전히 자동화되어 있습니다. 플러그인 이름을 알려주시면, 대신 코드모드(codemod)를 실행하고 PR을 만들어 드리겠습니다. 우리가 유지 관리하는 600개 이상의 테마/플러그인에 대해 이미 이 작업을 수행했기 때문에, 이제는 매우 잘 오일링된 기계처럼 잘 돌아가고 있습니다.
이 게시물에서 저는 unmaintained 태그 또는 end-of-life 태그를 추가하는 것을 제안했습니다.
몇 달 뒤에 돌아와서 많은 것이 변해 있는 것을 발견하게 되면 쉬운 일이 아닐 수 있습니다. 이러한 변화를 따라가는 것이 쉽지 않을 수 있지만, 제 생각에는 방대한 API를 갖춘 최첨단 포럼 소프트웨어를 사용하는 대가로 치러야 할 비용입니다.
그런데 왜 호환성을 해치면서까지, 여러분 쪽의 사소한 잔재들을 정리한다는 명목으로 계속 변경 사항을 적용하는 건가요?
그 레거시 잔재는 플랫폼이나 API를 유지보수하는 데 따르는 비용의 일부입니다. 실제로는 문제를 일으키지 않습니다. 하지만 여러분은 그것을 고집스럽게 변경하거나 제거해서, 다른 사람들이 추가로 일하고 테스트해야 하는 상황을 만들고 있습니다.
ESR은 고작 9개월밖에 지속되지 않습니다. 이는 장기 지원이라고 보기 어렵습니다.
그리고 그걸 사용하게 되면, 문제의 원인을 파악하기 위해 훨씬 더 많은 커밋 목록을 검색해야 하는 상황에서, 모든 깨지는 변경사항(breaking changes)을 한꺼번에 처리해야 합니다.
현재의 ESR은 이 문제를 더 악화시킬 뿐, 개선시키지 않습니다.
유일한 해결책은 API를 실제로 신경 쓰고 유지보수하는 것입니다. 깨지는 변경사항은 최후의 수단으로만 사용해야 하며, ‘있으면 좋겠다’는 수준의 사소한 정리 목적으로는 사용해선 안 됩니다. 또한 여러분이 다른 프레임워크를 사용하고 싶다는 이유, 혹은 그 어떤 이유든, 사람들이 사용 중인 프레임워크 전체를 폐기해서는 안 됩니다.
여기서 따르는 프로세스는 프로덕션 환경을 ESR에, 스테이징 환경을 월간 릴리스나 tests-passed에 두는 것입니다.
스테이징을 매일/매주/매월 업데이트한다면 — 심지어 이를 자동화할 수도 있습니다 — 플러그인과 테마를 반복적으로 업데이트하여 작동하는 상태로 유지할 수 있습니다.
프로덕션을 ESR에 유지함으로써 문제를 수정하기 위해 최소 3개월의 여유를 가질 수 있습니다.
공개된 API는 계속 바뀌는 대상이어서는 안 된다는 개념을 이해하지 못하는 것 같습니다.
마이크로소프트가 6개월마다 모든 Windows 개발자에게 코드 수정을 요구한다고 상상해 보세요. 그것은 상상할 수 없는 일입니다. 30년 전에 작성된 Windows 95용 코드를 오늘날의 최신 컴퓨터에서 아무런 수정 없이 컴파일하고 실행할 수 있습니다.
자신이 정한 사양에 따라 작성된 코드가 전적으로 본인의 결정으로 인해 더 이상 작동하지 않을 수 있을 때, 호환성을 중시한다고 주장할 수는 없습니다.
Windows는 전체 스택을 직접 제어하지만, Discourse는 살아있는 생태계 위에 플랫폼을 구축하고 있습니다. Ember만 해도 주요 버전마다 반복적으로 하위 호환성을 깨뜨려 왔습니다. 그리고 이는 프론트엔드 생태계에서 예외가 아닌 일반적 현상입니다.
저에게 이는 매우 명확합니다. 여기서는 Windows 모델이 아니라, 다른 API 플랫폼들이 취하는 방식이 올바른 모델입니다. 즉, 명확한 버전 관리, 비추천(deprecation) 공지, 그리고 합리적인 마이그레이션 기간을 제공하는 것입니다.
.hbs 파일의 남은 사용 사례는 이제 관리자에게 경고 배너를 표시합니다. 실제 사용 환경의 원격 측정 데이터에 따라, 2026.8.0-latest 주기에서 해당 지원을 제거할 예정입니다. 2026.7 ESR은 hbs를 지원하는 마지막 릴리스가 될 것입니다.