Discourse의 기술 아키텍처에 대한 질문

안녕하세요

오래전에 기술에 밝은 사람이었지만 요즘은 그렇지 않습니다. 다른 곳에서 언급했듯이 저는 디지털 커뮤니티의 설계에 관심이 있습니다. 기술로 구축된 사회학이죠.

디스코urses의 아키텍처가 무엇인지 정확히 모르지만, 테마와 플러그인이 있다는 점은 알고 있습니다. 제가 모르는 다른 부분들이 있다면 그것도 모를 것입니다.

도와주세요 :slight_smile:

여러 가지 방법으로 'pair’를 검색해 보았지만, "여기가 바로 무엇인지/왜 그런지에 대한 101(입문 가이드)입니다"라고 말하는 결과를 찾지 못했습니다. 예를 들어: "프레젠테이션 계층, 저장 계층, 그리고 이 두 계층 사이에서 이 정보를 사용하여 컨텍스트를 설정하고 한 계층에서 다른 계층으로 선택하는 선택 과정이 있습니다. 기본 제공(out of the box) 기능으로는 x, y, z가 있습니다. 플러그인은 … 디렉터리에 있는 모든 것이 서버 프로세스(또는 유사한 것) 초기화 시 로드되며, …을 통해 UI/백엔드/프론트엔드 등에 연결됩니다. 현재 존재하는 것들은 …입니다. 테마는 기본 제공 기능과 플러그인의 프레젠테이션 계층(?)에 다음과 같은 방식으로 영향을 미칩니다…"라는 식의 설명을 원합니다.

누군가 저에게 알려줄 수 있는 그런 설명이 있을까요?

이 설명이 0에서 충분한 이해까지 이끌어 주면, 현재 존재하는 것들을 찾고 창의적인 사고를 할 수 있을 정도로 이해할 수 있을 것입니다.

왜냐하면

그렇게 하면 다양한 목적을 위한 커뮤니티 설계에서 개념적 빌딩 블록으로 활용할 수 있기 때문입니다.

저는 다음에 관심이 있습니다:
디스코urses가 #medical_grade(의료 등급) 표준을 충족하도록 '강화(hardened)'될 수 있는지 여부 - 특정 관할권에서 그 표준이 무엇인지는 아직 모르지만, 관심 있는 목적을 위해 필요할 것이며 지역별로 다를 것임을 알고 있습니다.

저는 계측된 재활 도구에 인터페이스하고, 진행 상황 및 효과 지표의 익명화 데이터 추출(gdpr 준수)을 코딩하여 연구용 개선 데이터를 확보하는 것에 관심이 있습니다.

저는 최상의 게시물들이 크림처럼 위로 떠오를 수 있는 방법에 관심이 있습니다. 그래야 새로운 사용자가 혼란스러운 시기에 갑자기 급한 필요를 느끼게 된 주제에서, 수천 개의 게시물과 스레드로 이루어진 정보 앞에서 낯선 디스코urses UX에 직면하지 않을 것입니다. 그 정보는 학술적이지만 사용자에게는 직관적이지 않은 위계적 구조만 가지고 있습니다…

위계적 구조는 일반적으로 먼저 숨을 고르고 검색 패턴을 적용할 수 있다면 잠재적 관심사에 대한 탐색에 더 적합하지만, 일반적으로는 깊이 우선 검색 패턴만 지원합니다 - 디스코드는 그 예로, 이미 주제를 알고 있다는 전제가 있습니다 - 이는 해시태그로 다소 완화될 수 있지만, 이는 제 독서 목록의 또 다른 주제입니다.

아마도 AI 봇 관련 기능이 그 격차를 메워줄까요? 또 다른 백로그 항목… :slight_smile:

또한 @jonobacon과의 블로그를 통해 몇 가지 영상을 보고 있으며, 끝나면 더 똑똑한 질문을 할 수 있을지도 모릅니다.

디스코urses의 맥락 내에서 창의적으로 생각하려면 어떤 구성 요소와 인터페이스가 존재하는지에 대한 더 깊은 이해가 필요합니다.

저에게 안내해 주실 수 있을까요? :slight_smile:

미리 감사드립니다.

기존 플러그인, 테마, 테마 컴포넌트를 살펴보면 커스터마이징으로 어떤 것이 가능한지 감을 잡을 수 있습니다:

:wave: @51mon - 디스코ourse 포럼 개발에 관심이 있다면 여기에 있는 정보가 도움이 될 수 있습니다. :slight_smile:

감사합니다 :slight_smile:

읽는 방법에 대한 안내를 기대했는데, 마치 사전만 건네준 것 같아요! - 이들이 무엇인지, 어떻게 작동하는지에 대해 그들이 무엇을 하는지보다 좀 더 부드럽고 입문적인 소개가 있을까요? :slight_smile:

링크에 많은 자료가 있지만, Discourse의 아키텍처가 무엇인지에 대한 개요가 없어요. 지금은 플러그인 등에서 어떤 기능이 제공되는지보다, 그것들이 실제로 무엇인지 파악하는 데 더 관심이 있습니다.

감사합니다. 한번 확인해 볼게요 :slight_smile:

제목이 "개발 중…"이라고 되어 있어서 약간 망설여지네요. 저는 코드 작성에는 관심이 없고, 아키텍처를 이해하는 쪽에 관심이 있거든요.

현재 텍스트가 제 요구사항을 충족하는지 명확하지 않아서 확인해 볼 생각이에요 (기원합니다).

알려드릴게요 — 물론 다른 제안이 있으시다면요 :). ?

@51mon 이 자료들을 살펴보셨을 거라고 가정합니다.

아니요, 그렇지 않았습니다 :slight_smile:
감사합니다

~~ "~~
[[수정사항]]

아이고! 첫 번째 링크는 15개의 스레드가 있는 헤더로带我去합니다.

두 번째와 세 번째 링크는 판매 페이지이지만, 적어도 페이지는 하나뿐입니다. 다만 기능 목록은 있지만 아키텍처 설명은 없습니다.

그리고 아이고, 마지막 링크가 무엇인지조차 확실하지 않네요. try.discourse.org에 로그인하여 사용해 보라는 초대인데, 100개 이상의 항목이 있는 스레드와 1,000개 이상의 항목이 있는 스레드 하나가 있습니다 -

지도는 없습니다. 쿡이 호주를 발견하고 그 해안을 따라 며칠 동안 항해했을 때의 기분과 비슷할 것입니다.

수정
기능 목록

이 페이지에는 사물들의 긴 목록이 나열되어 있습니다. 그중 일부는 개념적인 것입니다. 이름이 설명되지 않은 개념을 가리킬 때, 그것은 단순히 여기 어떤 것이 있다는 것만 알려줄 뿐, 그 사물이 무엇인지에 대한 이해를 전달하지 않습니다. 그래서 저는 기능 목록에서 많은 것들이 있다는 것만 알 수 있을 뿐, 언급된 많은 기능들로 무엇을 할 수 있는지에 대한 개념을 갖지 못합니다.
범위를 파악하는 데는 좋지만, 이미 아는 사람들에게는 좋은 기억 보조 자료이지만, 이해를 구하는 누군가가 이해를 얻기에는 어렵습니다.
또한 이 기능 목록을 통해 그것들이 플러그인인지, 테마인지, 기본 제공인지, discourse에 고유한 것인지, 아니면 모든 플랫폼에 공통적인 것인지 알 수 없습니다.
이 단계에서 그 페이지에 대해 제가 무엇을 해야 한다고 말하는 것은 아닙니다. 단지 대륙을 탐험할 것이므로 메모를 남기는 것입니다. 제 첫 게시물(OP)에서 요청했던 것은 달에서 지구를 바라본 사진 같은 것이었는데, 지금까지 저는 HMS Endeavor의 돛대 꼭대기까지 올라가지도 못했습니다 :grin:

세 번째 링크 "what is discourse"는 세일즈 피치와 다른 것들의 혼합입니다. 아키텍처를 제공하지도 않습니다 - 제공해야 한다고 말하는 것은 아니지만, 제공하지 않으므로 제가 찾는 것이 아닙니다.
또한 제게는 정확히 느껴지지 않습니다. 예를 들어 discourse가 복잡성을 제거했다고 주장하지만, UI에서 사용되는 빨간색은 좋아요 수와 게시물 수에 따라 변합니다. 이것은 UI의 매우 난해한 요소입니다. 또한 읽지 않은 게시물 목록에서 제목, 답변 수 또는 이름이 무엇인지 모르는 세 번째 필드를 클릭하느냐에 따라 스레드 내의 다른 곳으로 이동합니다. 이러한 것들은 모두 직관적이지 않고, 알려지지 않으며, 표시되지 않는 UX의 변형들로, UI에 존재한다는 것을 알기 전까지는 혼란을 줄 것입니다.

솔직히 @51mon, 질문이 어떤 건지 잘 모르겠어요. 좀 더 쉽게 다시 설명해 주시면 최대한 답변해 드리겠습니다.

정말 친절한 연락을 주셨네요 @JammyDodger. 시간이 나면 꼭 참여하고 싶지만, 지금은 그럴 수 없어요.

처음에 올린 글에서 제 생각은 제 귀에는 분명하게 전달되었지만, 상대방의 귀(눈!)에는 분명하게 전달되지 못한 것 같아요.

한번 이렇게 설명해 볼게요.

우리가 서서 자동차를 보고 있다면, "이 안에 앉아 슈퍼마켓이나 해변으로 갈 수 있어"라고 이야기할 수 있겠죠. 아니면 "이 차에는 바퀴와 가솔린 또는 배터리로 동력을 얻는 엔진, 그리고 조향 장치와 제동 장치가 있어"라고 대화할 수도 있어요.

브레이크나 방향지시등, 그리고 실내 조명이 자동으로 켜졌다 꺼지는지에 대한 이야기는 개발자 간의 대화입니다. 반면 해변으로 가거나 아침에 아이들을 학교에 데려다주거나, 휠체어를 뒷좌석에 넣을 수 있는지, 카라반을 견인할 수 있는지에 대한 이야기는 기술적인 영역에 접해 있는 사용자 중심의 토론입니다. 카라반을 견인하려면 후크를 설치해야 하는데, 이는 기본 사양이 아니에요. 차를 살 때 흰색, 회색, 검은색, 혹은 파란색 중 하나를 선택할 수 있었죠. 이런 것들은 일회성 선택 사항으로, 디스코urs(Discourse) 컨텍스트에서는 관리(Admin) 주제가 될 수도 있어요.

저는 수많은 관심사 중 하나로서, 디스코urs로 커뮤니티를 운영할 때, 관리자 설정과 기여자들의 게시글, 사용자 ID 등 여기저기에 흩어져 있는 정보가 데이터 보호를 위한 의료 등급 규정(CIA: 기밀성, 무결성, 가용성)을 준수해야 할 수 있는지에 대해 궁금합니다. 하지만 기초 아키텍처를 모르면 이 질문에 대한 판단을 내릴 수 없어요.

이 설명이 더 명확해지지 않았다면, 제가 사람들이 공유해 준 모든 자료를 읽을 때까지 기다려 주셔야 해요. 그래야 답변을 줄 수 있는 사람들에게 이해 가능한 질문을 할 수 있을 테니까요. 현재로서는 더 나은 질문을 구성할 수 없거든요.
감사합니다 - :slight_smile:

이것은 발견의 여정이고, 시간이 좀 걸릴 거라는 점에 만족합니다. 제가 필요한 발견을 하게 되면, 여기서 커뮤니티에 다시 공유하여 미래에 다른 사람들에게 도움이 되기를 바라며 정리해 볼 가능성이 큽니다.

솔직히 말씀드리면, 그 설명이 훨씬 더 명확해졌다고는 느끼지 못하겠습니다. :slight_smile: 다른 분들이 참여해서 필요한 정보를 제공해 주시길 바랍니다. :crossed_fingers:

아직 직접 시험해 볼 수 있는 포럼을 만들어 보셨나요? 아이디어를 탐색하고 어떤 것이 가능한지 감을 잡는 데 도움이 될 수 있습니다.

안녕하세요, @51mon.

문제의 일부가 비유에서 비롯된 것 같다고 생각합니다. 작성자가 입력하는 내용은 작성자 본인이 의도한 대로 이해될 수 있지만, 다른 사람들이 이해하기 어려울 수 있습니다.


자, 그럼 시작하겠습니다:

Discourse Meta는 기본적으로 커뮤니티 프레임워크의 기반이 되도록 설계되었습니다.

기본적인 토대를 제공하지만… 처음부터 바로 사용 가능한 상태라 다소 단조로울 수 있습니다.

나이나 당신 같은 세대라면 DOS 기반의 전자 BBS에 참여하거나 인지하고 있었을 수 있습니다.

그중 상당수가 Telegard BBS, 즉 Telegard Hacks의 파생 제품이었죠. (이쯤에서 잠시 벗어납니다…)

다시 본론으로 돌아와서.

그래서 당신은 …을 위한 Discourse Meta 포럼을 구축하고 싶으신 건가요?

여기가 시작점입니다. 앉아서 커뮤니티의 목적과 기능 및 기능 측면에서 무엇을 제공하고자 하는지 아이디어를 정리해 보세요.

그 다음 한 발짝 물러서세요.

어디까지 갈 수 있는지 더 명확한 그림을 얻기 위해서입니다. 이미 Discourse를 사용 중인 커뮤니티 목록을 탐색해 보세요. 현재 손에 바로 쓸 링크는 없지만, 기존 커뮤니티를 살펴보면 어떤 것이 가능한지, 그리고 일부 커뮤니티가 얼마나 유사한지, 혹은 범위와 기능 면에서 얼마나 다를 수 있는지에 대한 아이디어를 얻을 수 있습니다.

이제 다른 커뮤니티들이 가지고 있고 당신의 커뮤니티 아이디어에도 포함하고 싶은 기능들을 메모해 보세요.

삶의 질을 높여줄 수 있는 유료 호스팅을 선택할지, 아니면 강력한 확장성을 위해 원하는 플러그인을 자유롭게 선택할 수 있는 완전한 제어를 위해 셀프 호스팅을 선택할지 결정할 수 있습니다. 하지만 셀프 호스팅의 경우 VPS를 직접 유지 관리해야 한다는 비용이 따릅니다.

어떤 방법을 선택하든, 커뮤니티를 설계하기 위해 필요한 기능과 기능을 갖추기 위해 무엇을 알아야 하는지 조사해야 합니다.

자, 이제 생각 실험을 해 보겠습니다. 커뮤니티 아이디어의 예를 하나 제시해 주세요. 기존 커뮤니티를 사용해서도 좋습니다. 이 커뮤니티가 가진 것을 달성하기 위해 어떤 Customization > Plugin (필요한 경우), Customization > Theme, Customization > Theme component 가 필요한지 우리에게 질문해 주세요.

Hi @Heliosurge
:slight_smile: BBS에 대해 잊어버리세요. 나는 UKC가 캔터베리에서 300 baud 다이얼업 회선을 통해 운영했던 newsnet을 기억하고 있으며, freeagent 같은 NNTP 기반 서비스와 클라이언트도 기억합니다.

비유는 물론이고, 더 넓게 말해 문장 형태로 배열된 단어들은 종종 작성자 두뇌 안의 이해를 단순하게만 포괄하는 경우가 많다는 데에 전적으로 동의합니다. 다른 곳에서 이해를 만들어내더라도, 그것이 동일한 이해일 것이라는 보장은 없으니까요! :slight_smile:

이렇게 해보겠습니다.
나는 discourse가 게시글과 사용자의 데이터베이스를 포함하는 서버 측이 있다는 것을 이해합니다. 그리고 게시글과 사용자 모두에는 속성(attributes)이 있으며, 서로 연결되어 있습니다. 이것이 어딘가에 호스팅되어 있다는 점도 이해합니다. 호스트는 가상일 수 있고, 콘텐츠 전송 네트워크(CDN) 등일 수 있습니다.

클라이언트 측에는 게시글, 사용자의 인증 정보, 접근 권한 및 링크를 사용하여 피드(feed)를 생성하는 표현 계층(presentation layer)이 있다는 것을 이해합니다. 철학적으로 사용된 많은 구조들이 위계적(hierarchical)이라는 것을 볼 수 있습니다. 이 위계는 많은 교차 연결(cross linkage) 메커니즘에 의해 가려져 있습니다.

클라이언트 측에서 사용되는 색상 스키마 등은 실행 시점에 테마에 바인딩되며, 이 테마는 교체될 수 있다고 추정합니다. 따라서 이후의 실행은 새로운 테마에 바인딩되며, 콘텐츠는 변경되지 않지만 표현의 외관과 심지어 일부 기능적/탐색적/스타일적 구성 요소는 변경될 수 있다고 봅니다. 이 지점에서는 제 이해가 흐릿하고 추측적인 수준에 머물러 있습니다.

테마 구성 요소(theme components)가 존재한다는 것을 인지하고 있으며, 현재 제 머릿속에는 '테마 구성 요소의 조합이 테마를 만든다’는 모델을 가지고 있습니다. 하지만 이 부분도 다소 불안정합니다. 테마 구성 요소가 무엇을 하는지에 대한 몇 가지 예시를 파악하지 못하고 있습니다.

플러그인에 대해서는 이해가 더 부족합니다. 플러그인이 서버 측에 속하며, 콘텐츠를 서빙하는 실행 중인 인스턴스 내에 위치한다는 아키텍처적인 부분은 이해합니다. 하지만 테마와 플러그인 간의 상호작용을 명확히 파악하지는 못합니다. 서버 측 기능을 확장하면 클라이언트 측 표현도 확장해야 한다고 추측해 보지만, 그 부분은 불확실성 위에 쌓인 불확실성입니다.

또한 전체 아키텍처 모델이 서버, 서빙 소프트웨어, 클라이언트 앱/브라우저, 테마 구성 요소, 플러그인으로 구성되어 있는지, 아니면 다른 구성 요소가 있는지也不知道합니다.

"표준 discourse 커뮤니티는 페이월이나 다른 수익화 메커니즘 뒤에 있지 않는데, 이런 것을 추가할 수 있는가?"와 같은 질문들이 있습니다. 데이터는 CIA 삼중 구조(기밀성, 무결성, 가용성)의 일정한 수준을 갖춘 시스템에 저장됩니다. 대서양 양쪽의 의료 상호운용성 표준에 요구되는 수준으로 이를 강화할 수 있을까요?

이 후자의 요구 사항은 대화의 방향을 윤리 및 소프트웨어가 법적, 도덕적, 문화적 우려를 어떻게 지원하는지로 이동시키며, 이는 이 포럼의 주제에 적합하다고 생각합니다. 아키텍처에 대한 이해는 솔루션 설계의 전제 조건이며, 바람직하고 필수적이라고 여겨지는 시설을 형성하는 철학적 원칙의 결정, 그리고 바람직하지 않거나/불가하거나/비난받을 수 있는 것 및 그에 대한 심의 처리 역시 전제 조건입니다.

좋아요, 이제 이해가 가고 있네요. 여기 있는 것처럼 카테고리로 그룹화되고 태그로 정리된 주제에 대한 핵심 데이터베이스가 있습니다.

#customization:theme에는 두 가지 종류가 있습니다.

  • Basic: 기본 Discourse의 외관만 수정합니다.
  • Full Theme: 외관을 수정할 뿐만 아니라, 동작 방식을 변경하기 위해 일부 #customization:theme-component가 미리 패키징되어 있습니다.

이 사진입니다. 사이드바 메뉴를 소환하세요.

화살표로 강조한 하단 부분을 확장하세요. 기본부터 풀 테마까지 다양한 테마 모음이 있습니다. 하나를 선택해 실험해 보세요. 그러면 여기 Meta의 외관과 느낌이 어떻게 달라지는지 확인할 수 있습니다.

여러 가지를 시도해 보고 탐색해 보세요. 컴포넌트가 있을 때와 없을 때 테마가 어떤 일을 할 수 있는지에 대한 더 나은 이해를 얻을 수 있을 거라고 생각합니다.

예를 들어 Air 테마는 미리 설치된 컴포넌트를 가진 풀 테마입니다.

감사합니다.
이 답변을 통해 테마가 서버 측에 로드되고, 클라이언트가 시작 시 사용 가능한 테마를 조회한 다음, 데이터를 가져오거나(혹은 세션을 인스턴스화할 때?) 표시할 데이터를 제공할 때 테마 ID를 서버에 전달하며, 서버가 이를 사용하여 클라이언트에 전달할 HTML 요소를 인코딩한다는 것을 알게 되었습니다.

또한 앱이 다시 빌드되어야 한다고 하셨는데, 이는 링크 편집 과정이 맞을까요? 말씀하시는 내용은 동적 링크 라이브러리가 아닌 정적 메커니즘인 것 같습니다.

여전히 어떤 서비스가 플러그인을 통해 무엇을 제공할 수 있는지, 그리고 테마가 아이콘을 원에서 사각형으로 바꾸는 것 외에 어떻게 상호작용하는지 감을 잡지 못하고 있습니다. 제가 선택했을 때 그렇게 변화가 일어난 것 같은데, 그 테마 이름이 air였나요?

기존의 포럼 플랫폼(vBulletin, phpBB)과 달리 Discourse는 평탄한 서버 측 스크립트(PHP)와 독립된 데이터베이스의 집합이 아닙니다.

Discourse는 두 부분으로 구성됩니다: Docker에 존재하는 백엔드와 클라이언트 기기에 전달되는 단일 페이지 JavaScript 애플리케이션입니다.

백엔드 변경이 필요한 모든 작업은 Docker 컨테이너에 영향을 미치며, 가장 기본적인 설치 환경에서도 소량의 다운타임이 필요합니다. 사람들이 "앱이 다시 빌드되어야 한다"고 말할 때를 의미하는 것이 바로 이것입니다. 컨테이너 빌드 방식을 제어하는 설정 파일(YML 문서)을 편집한 후, SSH를 통해 launcher에 재빌드를 지시해야 합니다. 플러그인 설치에는 재빌드가 필요하지만, SMTP와 같은 단순한 변경 사항은 재시작에 더 가깝습니다.

새로운 테마 및 테마 컴포넌트를 도입하는 것은 기본적으로 실행 중인 웹 애플리케이션 내에서 수행되는 프론트엔드 변경입니다. 기본 애플리케이션과 데이터베이스가 실질적으로 변경되지 않기 때문에 다운타임이 발생하지 않습니다.

스티븐, 고마워 :slight_smile:

저는 기술적인 결격 사유가 몇 가지 있어. 제 실무 경험은 도커가 나온 것보다 한 세대나 앞서거든! 사실 저는 고슬링이 자바를 경량 언어로 정당화한 것이 그 달의 가장 뜨거운 화두였던 때를 기억해. 그때 저는 K&R C, ingres, oracle, 시스템 관리, DBA에 몰두하고 있었지.

제가 파악하기로는, 프론트엔드와 백엔드라는 단어가 클라이언트-서버 사이드 구분이 아니라 서버에서 실행되는 프로세스를 가리키는 것으로 쓰이는 것 같은데, 맞지?

서버 위에 공유 메모리나 파이프 등으로 협력하는 프로세스들이 있고, 그 다음에 TCP로 캡슐화된 메시지 스트림이 클라이언트 소프트웨어가 설치된 IP로 데이터를 보내는 구조인 거야?

이 아키텍처에 대한 블록 다이어그램을 그려본 사람이 있을까?

이건 확실히 #커뮤니티-빌딩에서 벗어나고 있는 것 같아요 :slight_smile: 기술적인 요소에 더 초점이 맞춰져 있으니 #dev로 옮기죠.

이 주제는 두 가지 아이디어가 혼합되어 있는 것으로 보입니다:

  1. “내 Discourse 인스턴스를 설계하는 데 도움이 될 고수준 개요/도면이 필요함”
  2. “Discourse의 기능을 제 요구사항과 비교해 보려 했지만 특정 정보를 찾을 수 없음”.

아키텍처에 관한 첫 번째 점은 다소 논의되었지만, 불행히도 여전히 최상위 도면이 부재한 상태입니다. 더 나은 이해를 가진 누군가가 #mermaid를 사용하여 여기서 우리에게 무언가를 그려주기를 희망하지만, 저는 적어도(희망적으로) 원래 요구사항에 대해 일부 지침을 제공할 수 있습니다.

Discourse가 의료/정부/자동차 정보 보안 요구사항 및 표준을 충족할 수 있는가?

이 요구사항이 정확히 무엇인지 더 구체적으로 설명해야 합니다. 그러나 의료 및 자동차 분야는 그렇게 큰 차이가 없으므로 도움이 되기를 바라며 제 경험을 공유합니다. 배경을 설명하자면, 저는 독일의 대형 자동차 부품 공급업체를 위해 인너소스(innersource) 인스턴스를 운영합니다. 이는 법적 골칫거리였지만, 천진난만한 수준의 끈기, 어리석은 수준의 인내심, 그리고 incredibly 유용하고 인내심 있는 법적 팀 덕분에 달성할 수 있었습니다. 진심으로, 법적 팀에게 매우 친절하세요 :laughing:

답변해야 할 가장 큰 질문들은 다음과 같습니다:

  1. 누가 정보에 접근합니까?
    • 대중?
    • 직원?
    • 직원과 대중의 혼합?
  2. 플랫폼에 어떤 종류의 정보가 있을 것입니까?
    • 대중용만?
    • 대중용과 내부용의 혼합?
    • 기밀? – 이 정보를 플랫폼에 호스팅할 계획을 세우는 순간부터 상황이 훨씬 어려워진다는 점에 유의하세요.
  3. 어디에 호스팅됩니까?
    • 온사이트(자체 데이터센터)
    • Discourse 또는 다른 호스트에 의해

우리의 경우, 내부 직원만 접근 가능하고, 내부 정보만(즉, 기밀이 아닌 회사 정보 공유) 포함되며, 원래는 자체 호스팅이었지만 호스팅을 위해 Discourse로 이전했습니다.

Discourse를 통한 호스팅에 관해서는, 우리의 정보 보안 사무국은 이전을 결정했을 때 중요한 문제를 발견하지 못했습니다.

또한 우리는 여러 국가에 이 정보를 배포하고 있습니다: 중국, 인도, 독일, 루마니아, 미국, 프랑스 등. 중국은 다소 번거로웠지만, Discourse 팀은 우리가 직면한 CDN 문제를 해결하여 우리를 목표에 도달하게 하는 훌륭한 작업을 수행했습니다.

질문 번호 3: "어디에 호스팅될 것인가"는 데이터 보호 및 보안 질문의 대부분을 답해 주는 것임을 유의하세요.

로그인 및 인증

로그인의 경우 SAML에 의존하는 것이 좋습니다. Discourse 엔터프라이즈 고객인 경우 Discourse 팀이 이 설정을 도와줍니다. 우리의 IDP는 회사의 VPN 뒤에 있을 때만 접근할 수 있으므로, 이는 우리에게 추가적인 보안 계층을 제공합니다(즉, 네트워크에 있지 않으면 로그인 화면조차 로드할 수 없습니다).

SSH

또한 표준 설치에는 ssh 암호화가 제공됩니다. 저는 CIA에 소속되어 있지 않으므로 그 이상이 필요한지 알지 못합니다. :male_detective: 소문에 따르면

Discourse를 다른 도구와 인터페이스하는 방법

API에 의존하기

인터페이스링을 위해 Discourse API가 당신의 친구입니다. API 키와 일부 Python을 사용하여 데이터를 가져오고 설정할 수 있습니다.

여기에 훌륭한 예시 모음이 있습니다: Discourse REST API comprehensive examples

GDPR 준수를 위한 사용자 데이터 익명화

GDPR의 경우, 데이터 탐색기(data explorer)에서 쿼리를 실행하여 소스에서 사용자 정보를 생략하면서 플랫폼에서 데이터를 추출할 수 있습니다.

이는 Discourse API를 사용하는 것과 대비됩니다. JSON 응답에는 일반적으로 게시물에 대한 전체 정보가 포함됩니다:

  • 게시물 내용 (cooked HTML 및 raw Markdown)
  • 게시물 ID
  • 속한 주제 ID
  • 게시자의 사용자 이름
  • 주제 내 게시물 번호
  • 게시물의 생성 및 마지막 업데이트 타임스탬프
  • 좋아요, 답변, 인용 등의 수.

인기 있는 게시물과 익숙한 UI를 얻는 방법?

아직 보지 못했을 수 있지만, 이 테마를 결합할 수 있습니다:

다음과 같은 것들과 함께:

미국의 HIPAA 법에 따르면, 의료 기록 데이터의 경우, 환자가 공식적인 정보 공개 서명서를 서명하면 의료 제공자는 가족, 친구, 간병인 및 환자가 선택한 다른 누구와도 이를 공유할 수 있습니다. 이러한 서명서에는 보통 몇 개월 또는 몇 년이라는 만료일이 설정되어 있습니다.

이것을 단순한 다이어그램으로 표현하자면, 모든 의료 데이터는 응급 상황에서도 절대 열릴 수 있는 거대한 잠금 금고에 보관되는 것과 같습니다. 단, 응급 서비스 인력이 환자로부터 서면 서류를 제출한 경우를 제외합니다.

다만, 환자가 의식을 잃었거나, 특히 장기적으로 혼수 상태에 있거나, 정신적으로 정상적이지 않아 법원 및 판사가 환자의 재산을 스스로 관리할 수 없다고 판결한 경우, 또는 그와 유사한 상황이라면 다른 사람이 이를 대신 처리하도록 지정될 수 있습니다.

이 두 가지 시나리오 중 어느 쪽이든, 금고 열쇠로 비유할 수 있으며, 이 열쇠는 일부 의료 데이터를 특정 사람만 접근할 수 있는 제한된 접근 권한을 가진 보조 금고로 이동시키는 데 사용됩니다.

이것은 그룹이 될 수 있지만, 대부분의 경우 의료 데이터에 접근할 권한을 부여받으려면 개별적으로 이름이 명시되어야 한다고 생각합니다.

https://www.cdc.gov/phlp/publications/topic/hipaa.html