나단, 안녕하세요. 
현재 AWS를 통해 호주에서 호스팅 서비스를 제공하고 있지만, 해당 지역에서 코로케이션(물리적 서버 임대) 호스팅을 제공할 계획은 현재 로드맵에 없습니다. 이는 해당 지역의 수요가 높지 않기 때문입니다. 미국이나 유럽의 호스팅 대신 현지 호스팅을 선호하는 특별한 이유가 있을까요?
글쎄요, 전 세계적으로 분산되어 있다는 것의 까다로운 점은 이 유형의 이벤트를 위한 지역을 우선순위로 정하기가 매우 어렵다는 것입니다. 하지만 궁금합니다 – 시드니까지 여행할 만큼 충분한 가치를 제공하는 이벤트라면 어떤 종류의 이벤트일까요?
이 질문에 공감하며, 네, 우리는 보장을 제공합니다:
Discourse ID의 FAQ 하단에서: https://id.discourse.com/faq 우리의 개인정보 처리 방침으로 링크합니다:
https://www.discourse.org/privacy
이것은 다음 질문에 대한 내용을 다루고 있습니다:
CDCK는 제 개인 정보를 판매하거나 행동 광고를 제공하기 위해 공유합니까?
아니요, CDCK는 개인 정보를 판매하거나 맥락을 넘나드는 행동 광고 목적으로 제3자와 공유하지 않습니다.
Jeff는 세상 이곳저곳을 돌아다니고 있습니다. 그를 여기서 팔로우할 수 있습니다: https://infosec.exchange/@codinghorror
이것은 어려운 질문입니다. 매년 열리는 팀 모임에서 직접 만나 이야기를 나눌 수 있는 순간들이 제게는 매우 큰 의미를 가집니다.
안녕하세요!
이 주제에 대해 정말 열정적인데, 이렇게 질문해 주셔서 정말 기쁩니다. 제 예측에 대해 상당히 상세하게 여기에서, 그리고 커뮤니티 빌더들이 고민해야 할 사항에 대해 여기에서 이야기했습니다. 또한 Mae는 AI 탐색을 위한 커뮤니티 콘텐츠 최적화에 대한 조언을 여기에서 나누고 있습니다.
우리는 Discourse 커뮤니티가 데이터를 활용(및 보호)하는 방식에 대해 유연한 선택을 할 수 있도록 더 잘 지원할 방법에 대해 많은 시간을 보내고 있습니다.
현재 Discourse MCP에 대해 매우 기대하고 있으며, 향후 혁신에 대한 소식은 여기에서 확인하실 수 있습니다.
안녕하세요, 공정하지 않네요. 1개 안에 질문이 3개네요 
launcher 2 작업의 일부는 사전 구축된 docker 이미지를 제공하는 것입니다. 그렇기 때문에, 우리는 계획을 가지고 있으며 이미 베타 형태로 시도해 볼 수 있습니다 
테마에서의 사용자별 저장소에 관하여. 이는 제가 아주 오랫동안 구축하고 싶었던 분야입니다. 저는 수년에 걸쳐 @david와 이 주제에 대해 여러 번 논의했습니다. 여기에서 가장 큰 우려 사항 중 하나는 적절한 제약 조건을 확보하는 것입니다. 우리는 잘못된 테마가 서버 측 저장 공간의 테라바이트 단위를 소비하는 것을 원하지 않습니다. 적절한 범위를 찾는 것은 어렵습니다. 저는 방금 GitHub 어시스턴트와 이 주제에 대해 약간 브레인스토밍을 했습니다. 참고: https://meta.discourse.org/discourse-ai/ai-bot/shared-ai-conversations/OjpV557puqmyvwFkEIcUvA
테마 개발자에게 게임 체인저가 될 수 있으므로 선택적으로 "preload"를 허용하는 API 아이디어를 좋아합니다.
오픈소스는 Discourse의 DNA에 깊이 뿌리내려 있습니다. 우리는 불행히도 세상을 장악해 가고 있는 막대한 양의 클로즈드 소스 실로(silos)에 대한 개방형 대안이 항상 존재하길 원했습니다. 우리는 우리의 코드가 먼 미래까지 생존하고, 우리가 호스팅하거나 자체 호스팅된 Discourse 인스턴스를 긍정적인 것으로 보고 싶습니다.
오픈소스 특성은 사람들이 코드를 감사(audit)하기 때문에 Discourse가 많은 다른 대안보다 더 안전할 수 있도록 돕고, 플랫폼이 기이하고도 놀라운 방식으로 확장될 수 있게 합니다.
우리는 오픈소스 커뮤니티와 meta의 훌륭한 기여자들과 교류하는 것을 좋아합니다
젠, 저도 이 질문에 정말 공감합니다. 여기에서 공유한 내용처럼, 이 주제에 대해 꽤 많은 생각을 하고 있습니다. 스마트한 커뮤니티 빌더들은 콘텐츠가 어떻게 배포되고 소비되는지를 관리하는 데 중요한 역할을 한다는 것을 인식하고 있다고 생각합니다. 다만, 회원 주도형 거버넌스 구조를 가지고 계신 점을 고려하면 이것이 도전적일 수 있을 것 같습니다. 물론 잘 작동할 수도 있습니다. 여기에는 크라우드소싱 거버넌스 하에서 커뮤니케이션을 효과적으로 확장한 커뮤니티의 사례 연구가 있는데, 그들은 처음부터 이를 전략적으로 관리했습니다.
안녕하세요! (여기서 밤 11시입니다 ). How Discourse Uses Discourse 글을 올려주셔서 감사합니다. 동료들에게 바로 공유했습니다. 그래서 오늘 그 글 중 한 명이 블로그를 읽고 저에게 이렇게 물었습니다:
“왜 그들처럼 Discourse Chat을 사용하지 않는 거죠?”
(우리는 IM용으로 Discord를 사용하는데, 우리의 두 가지 주요 소통 플랫폼이 Discourse와 Discord이기 때문에 대부분의 사람들이 이 조합에 열광합니다 
)
그래서 제 답변은 이랬습니다:
“기본적으로는 푸시 알림이 부족해서, 특히 셀프호스팅 환경에서 그렇습니다.”
그러다 저는 Discourse가 Discourse ID처럼 푸시 알림에 대해서도 무언가를 할 수 있지 않을까 생각했습니다. 하지만 아마도 그럴 일은 없을 거라고 생각했어요. 그렇게 하면 그들의 호스팅 부가가치가 훼손될 테니까요… 하지만 어쨌든 다른 사람들에게는 흥미로운 질문일 수 있겠죠?
저희 블로그에서 가능한 단점들에 대해 약간 경고한 바 있습니다. 따라서 이 분야는 항상 신중하게 접근해야 합니다.
그럼에도 불구하고 아직 초기 단계이지만, Discourse Vibe가 어떻게 발전하는지 직접 사용해 보고(그리고 지켜보며) 강력히 권장합니다:
AI 에이전트들은 눈부신 속도로 진화하고 있으며, 우리는 에이전트가 업무를 잘 수행할 수 있도록 Discourse가 최적의 컨텍스트와 도구를 제공할 수 있도록 보장하고 있습니다.
예를 들어, 최근에는 에이전트가 적절한 빌드-테스트-빌드-테스트 루프를 가질 수 있도록 돕는 데 필요한 3가지 도구 세트를 완성했습니다.
bin/rspec FILENAME으로 어떤 스펙이든 실행
bin/lint FILENAME으로 어떤 파일이든 린트 검사 (신규)
bin/qunit FILENAME으로 어떤 qunit 테스트든 실행 (신규)
그 외에도 이제 Discourse MCP를 함께 제공하여, 에이전트가 테스트 데이터를 생성하고 수동 테스트를 수행하기 쉽게 만들었습니다.
"AI가 저를 위해 UI를 변경해 주는 것"에 대해
dv config theme를 실험해 보고 있어 테마 빌드를 위한 샌드박스를 시작하는 데 도움이 되고 있지만, 아직 초기 단계입니다. 간단한 테마 스캐폴딩(구조 생성)을 수행할 수 있는 상태로 만들기를 희망합니다.
당연히 셀프서비스 고객이 단순히 웹사이트를 가리키며 "이것이 제 웹사이트인데, 포럼을 조금 더 이 사이트처럼 보이게 해 줘"라고 말하는 미래가 올 것이라고 생각합니다.
흥분되는 시대가 다가오고 있습니다.
LLM이 더 저렴하고 빨라지면서 검색은 크게 진화할 것으로 예상되는 분야 중 하나입니다.
비판적 경로(critical path)에 LLM을 배치하는 것은 다소 까다로울 수 있습니다. 검색이 더 이상 '즉시’가 될 수 없기 때문입니다.
그럼에도 불구하고, ask.discourse.com이 증명하듯, 사용자는 훌륭한 결과를 얻기 위해 잠시 기다리는 것을 마다하지 않습니다.
"더 빠르고 좋은 검색"에 관해, BM-25를 Discourse에 적용하는 방법을 연구하고, LLM을 활용하여 사전 처리 단계에서 몇 가지 기이하고 흥미로운 철자 문제를 처리하는 개념을 주입하는 조합을 고려하고 있습니다. (즉, 검색 중에 LLM을 호출하는 것이 아니라 사전 처리를 수행하는 방식입니다.)
로드맵에 구체적인 계획은 없지만, 더 빠르고 좋은 검색은 우리가 항상 추구하는 목표입니다.
현재 이 프로젝트는 여전히 "실험 단계"에 머물러 있습니다.
@angus 님이 완료한 많은 작업을 후원했습니다. @pmusaraj 님은 그 과정에서 진전 사항을 신중하게 테스트해 왔습니다.
플러그인은 이제 놀라운 기능을 갖추고 있으며, 더 널리 채택되기를 바라고 커뮤니티의 미래에 대한 훌륭한 아이디어를 듣고 싶습니다.
아마도 질문은 다시 당신 쪽으로 돌아갈 것입니다. 여러분이 가장 크게 느끼는 부족함은 무엇입니까?
S3 호환은 항상 어느 정도의 타협을 수반합니다. 정말로 S3와 호환되는 건가요? 예를 들어 서명된 직접 업로드를 지원하나요? 동일한 라이프사이클 정책 XML을 지원하나요? 이런 목록은 끝이 없습니다.
우리는 기본 기능이 정상적으로 작동하도록 확인하려 노력하지만, 호환성 수준이 각기 다른 수많은 “호환” S3 제공업체가 존재하기 때문에 uphill battle(고난의 과정)이 될 수 있습니다.
다만 프록시와 CDN은 1급(first-class) 기능입니다. 구성이 까다로울 수 있으며(특히 프록시의 경우), IP를 안전하게 전달해야 하고 디버깅이 어려울 수 있기 때문입니다.
이는 Discourse ID를 더 매력적으로 만들기 위해 검토해 볼 수 있는 확실한 부가 가치입니다. 이 중 일부는 프로토콜의 과제이며, 특히 제3자 사이트에서 그렇습니다.
우리는 사적 포럼 데이터를 저장하고 싶지 않으므로, "사이트 X에 새 알림이 있습니다"라고 알리고 앱이 사이트 X에서 알림을 조회하는 프로토콜을 사용할 수 있습니다. 또는 종단 간 암호화를 사용하는 것도 방법입니다.
이는 까다로운 기술적 문제입니다.
그럼에도 불구하고 Discourse PWA는 이미 iOS와 Android 모두에서 푸시 알림을 지원합니다.
그리고 이 질문은 두 분 모두에게 좀 더 개인적인 내용입니다:
회사를 운영하면서 가장 어려웠던 부분이 무엇이었나요? 그리고 어떻게 극복하셨나요?
감사합니다 
건강하고 회복력 있는 방식으로 성장을 관리하는 것은 정말 어렵습니다. 비즈니스가 성장하면서 우리의 시스템과 프로세스도 유기적으로 발전해 왔습니다. 제가 입사했을 당시처럼 팀원이 14명뿐이었을 때는 스프레드시트와 이메일만으로 모든 일을 처리하는 것이 가능했습니다. 관료주의나 복잡한 절차가 거의 없어 빠르게 일할 수 있었습니다.
회사가 커질수록 더 견고한 프레임워크가 필요하며, 이는 프로세스를 수반합니다. 일부는 이러한 변화에 적응하는 데 더 많은 어려움을 겪지만, 우리는 모든 구성원이 함께 이 여정을 걸어가기를 원합니다. 좋은 예로, 최근 네덜란드에 CDCK.BV를 설립하여 EU 지역 전 직원을 고용했습니다. 이는 이전에 경험하지 못했던 엄청난 수준의 복잡성을 가져왔습니다. 회사와 개인 모두에게 분명히 이점이 있지만, 이를 처리하는 데 필요한 업무량은 방대합니다.
마찬가지로, 완전히 원격이고 비동기(async-first) 중심인 환경에서 커뮤니케이션을 확장하는 것도 도전적입니다. 시그널 대 노이즈 비율을 적절히 조절하는 것이 점점 더 어려워지고 있습니다.
아직 우리가 일하는 방식에 맞춰 세팅되지 않은 세상에서 이러한 도전을 해결하는 방법을 찾는 것은 어렵습니다. 아직 완전히 극복하지는 못했지만, 변화를 이끌어내기 위해 확실히 노력하고 있습니다.
정말 죄송합니다. 이 질문에 답하기 위해 정말 많이 고민했습니다.
조금 시간을 거슬러 올라가 보면, 5년 전 저는 디스코스가 더 나은 커뮤니티 플랫폼이 되기를 기대했고, 실제로 그렇게 되었습니다.
5년 후에는 시대에 맞춰 적응하고, 사람들이 모여 흥미로운 이야기를 나눌 수 있는 수많은 의미 있는 온라인 공간을 만들어내는, 훨씬 더 나은 커뮤니티 플랫폼이 될 것이라고 기대합니다.
그리고 여기서 마무리합니다! 참여해 주신 모든 분께 감사드리며, 질문들을 정말 재미있게 들었습니다.
정말 훌륭했습니다! 
어제 깊이 있는 답변을 주신 @sam님과 @hawk님께 감사드립니다. 질문이 계속 들어오면서 이번 주 내내 기다리고 있었어요!
모두, 라이브 AMA가 종료되었으니 이제 이 자리에서 자유롭게 이야기를 이어가 주세요. 이 토픽은 계속 열어둘 예정입니다.
포맷에 대한 피드백도 있으시면 알려주세요. 다음에도 꼭 하고 싶습니다!
게시글이 새로운 주제로 분리되었습니다: Discourse Meetup at 39C3 Hamburg?