Docmost - Confluence & Notion과 비슷한 오픈소스 협업 문서 및 위키 소프트웨어

 (github.com/docmost)
4P by GN⁺ | ★ favorite | 댓글 3개
  • Docmost는 오픈소스 협업 위키 및 문서화 소프트웨어로, 팀이 문서를 함께 작성하고 관리하는 용도의 프로젝트임
  • 주요 기능은 실시간 협업, Spaces, 권한 관리, 그룹, 댓글, 페이지 이력, 검색, 파일 첨부를 포함함
  • 문서에는 Draw.io, Excalidraw, Mermaid 기반 다이어그램, Airtable·Loom·Miro 등 임베드, 10개 이상 언어 번역 기능이 포함됨
  • 시작하려면 공식 문서를 참고하거나 클라우드 버전을 사용해 볼 수 있음
  • Docmost core는 AGPL 3.0으로 라이선스되며, Enterprise 기능과 지정 디렉터리의 파일은 Docmost Enterprise 라이선스를 따름

Docmost 개요

협업 및 문서 기능

  • Real-time collaboration을 지원함
  • 문서 공간을 나누는 Spaces 기능이 있음
  • 권한 관리와 그룹 기능을 제공함
  • 댓글과 페이지 이력을 지원함
  • 검색과 파일 첨부 기능이 포함됨

다이어그램, 임베드, 번역

  • Diagrams 기능은 Draw.io, Excalidraw, Mermaid를 지원함
  • Embeds는 Airtable, Loom, Miro 등을 포함함
  • 번역은 10개 이상 언어를 지원함

라이선스 구조

  • Docmost core는 오픈소스 AGPL 3.0 라이선스로 제공됨
  • Enterprise 기능은 Enterprise Edition의 엔터프라이즈 라이선스 아래 제공됨
  • 다음 디렉터리의 모든 파일은 packages/ee/License에 정의된 Docmost Enterprise license를 따름
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

개발 및 감사 표기

  • 기여자는 development documentation을 참고할 수 있음
  • Crowdin은 현지화 플랫폼 접근을 제공함
  • Algolia는 문서용 전체 텍스트 검색을 제공함

함께 보면 좋은 글 β

nutella   [-]

회사에서 노션도 안되고 옵시디언도 막혀서... 사용해보려고 하는데 괜찮은 대안이 될 것 같네요

답변달기
moderato   [-]

사용해보니 notion과 비슷하게 잘 만든 도구인데
너무 notion과 비슷하다보니 notion과 다른 지점에서 불편함이 생기기도 하더군요
잘 발전되면 좋겠습니다

답변달기
GN⁺   [-]
Hacker News 의견들

  • Notion과 Confluence의 접근성은 둘 다 정말 처참함
    Docmost를 만들면서 이 부분을 고려했는지 궁금함. 미국의 ADA와 곧 시행될 EU의 EAA를 생각하면 기업 도입에 꽤 중요한 요소이고, 이번에는 접근성 숙제를 제대로 한 제품이 있으면 좋겠음. 원하면 한 번 검토해줄 수 있음. 참고로 네이티브 스크린 리더 사용자이자 시각장애인, 개발자, 접근성 감사자임

    • 일반적인 손과 눈을 가진 사람에게도 그렇다면, 장애가 있는 사람들에게는 어떨지 상상해보면 됨
    • 접근성은 생각해봤음
      예를 들어 사이드바의 페이지 트리는 키보드 탐색을 지원함. 사용 중인 UI 라이브러리 Mantine도 접근성 모범 사례를 따르고 전체 키보드 지원을 제공함. 아직 할 일이 많지만 프로젝트가 진행되면서 지원이 더 늘어날 예정임. 예전에 Twitter 스레드를 오디오로 들을 수 있게 해주는 Twitter 봇 @threadvoice를 만든 적이 있고, 그때도 접근성이 동기 중 하나였음
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • 인증도 문제임. 이 두 사이트에서 다시 로그인 절차를 겪느니 차라리 모든 걸 잃는 편이 낫겠다는 생각이 듦
    • 기업들이 이미 접근성을 이렇게 못하는 Confluence와 Notion을 쓰고 있다면, 실제로 기업에 이게 얼마나 중요할지는 의문임
    • 중요하긴 하지만, 프로젝트를 막 시작할 때 가장 먼저 해결할 항목으로 두지는 않을 것 같음

  • 작은 피드백으로, 제품을 써보고 싶었고 웹사이트도 깔끔하고 유망해 보였지만 설치 페이지가 겁을 줘서 거의 이탈할 뻔했음
    처음 지시사항이 Docker 설치였는데, 섹션명이 “Prerequisites”인 건 알지만 설치 방법이 Docker뿐이라면 docker-compose와 변수 문서 정도를 기대했음. “Installation Steps”도 mkdir, cd, curl, vi로 시작한 뒤 결국 “이 docker-compose를 쓰라”는 흐름임. 전제 조건이 많은 사람에게 중요할 수 있고, 이게 문제라고 본다면 해결 방식은 여러 가지가 있음. 개발자와 기술에 익숙한 사람은 모든 걸 건너뛰고 터미널 명령이나 코드부터 봄. 그래서 저장소 README 상단에 “하지 말 것”을 너무 위에 넣으면 안 됨. 우리가 제일 먼저 복사해서 붙여넣을 부분이 되기 때문임. 비판은 아니고 훌륭하게 만든 것 같지만, 그 페이지에서 잃을 수도 있는 평범한 실험자의 피드백임
    https://docmost.com/docs/installation

    • Docker 설치 지침은 빼는 편이 좋겠음. 사람들은 Docker 문서에서 볼 수 있고, 다른 곳에 중복해서 넣을 이유가 별로 없음
      또 환경 변수 관리는 docker compose 파일을 수정하게 하기보다 .env 파일을 쓰는 게 좋겠음. 많은 사람이 yaml 파일을 버전 관리할 가능성이 높으니, 거기에 비밀값을 평문으로 두는 건 좋은 생각이 아님
      https://docs.docker.com/compose/environment-variables/set-en...
    • 도입을 늘리고 싶다면 올인원 컨테이너를 제공해야 한다고 봄
      runit을 쓰고 데이터베이스, redis, 앱을 같은 컨테이너에 넣은 뒤 큼직한 데이터 디렉터리 하나를 두면 됨. 컨테이너를 실행할 수 있는 대부분의 소규모 팀에는 그 정도면 충분하고, “한번 써보기” 경험이 그냥 docker run이 됨

  • 아직 VPN 뒤에서 Confluence 온프레미스를 쓰고 있음. 옮기려면 PDF 내보내기, Gliffy 같은 통합 다이어그램 편집기, 히스토리와 차이가 필요함
    지금까지는 Outline이 가장 가까웠지만 급하진 않아서 이 프로젝트의 발전도 지켜볼 예정임

    • XWiki SAS에서 Confluence에서 XWiki로 이전하는 도구를 만들고 있음
      XWiki는 Confluence와 비슷한 시기에 시작된 오픈소스 위키 소프트웨어이고, 언급한 기능을 모두 갖고 있음. 마이그레이션 지원과 컨설팅도 제공하며, 이전 도구는 콘텐츠와 기능을 가능한 많이 보존하려 하고 호환 매크로도 작업 중임. 필요하면 연락해도 됨
      https://xwiki.com
      http://xwiki.org
    • Confluence 쪽에서 오면 놓치기 쉬운 가장 큰 필요는 위키와 코드 문서의 통합이라고 봄
      코드의 README와 sphinx, mkdocs, swagger처럼 코드베이스에서 생성되는 문서를 위키와 함께 묶는 것이 중요함. 통합 다이어그램 편집기와 관련해서는 Mermaid나 Kroki 같은 문서-코드 추상화로 표준화하면, 차이 비교 가능한 다이어그램 코드와 여러 오픈소스 편집기를 활용할 수 있음. VSCode 확장에도 구현이 몇 가지 있고, Mermaid를 고르면 같은 다이어그램이 위키 도구, GitHub, Foam, Dendron, Obsidian.md 같은 로컬 우선 공개 콘텐츠 형식 도구에서 함께 동작해서 좋음
    • 이 용도로 Bookstack을 쓰고 있고 추천할 수 있음. 무료 오픈소스임
      PDF 내보내기, OAuth2, 리비전, 히스토리, 권한, WYSIWYG/Markdown/다이어그램 등을 지원함
      https://www.bookstackapp.com/
    • PDF 내보내기는 들어올 예정임
      다이어그램도 들어올 예정이고, 다음 순서는 MermaidJs임. Draw.io와 Excalidraw 같은 다른 다이어그램 제공자는 원본 데이터를 효율적으로 저장하고 가져오는 방식을 정리한 뒤 추가할 수 있음. 페이지 히스토리는 지원하지만 아직 차이 비교는 없음
    • Confluence에서는 안 써봤지만 https://www.tldraw.com/는 적어도 Notion에 임베드할 수 있고, 다이어그램 편집기로 아주 잘 동작함

  • 회사에서 문서 도구를 평가 중인데, 규제 환경이 특이해서 문서를 만든 사람과 검토·승인하는 사람이 다름
    이 때문에 문서용 병합 요청 개념이 차별화 기능이 될 수 있음. 누군가 문서를 만들고, 다른 사람이 수정한 뒤 변경사항을 검토 요청으로 제출하는 방식임. GitBook에는 있지만 다른 핵심 부분이 우리에게는 부족함

    • 예전부터 이걸 원했지만, 곰곰이 생각해보니 그냥 Git을 쓰고 Markdown 문서를 Notes System으로 푸시하는 방식을 더 선호하게 됐음
      편집, 리뷰, 병합을 다른 시스템이 처리하길 원하지 않음. Git에서 문서를 보내고, 필요한 문서 관련 기능을 제대로 호스팅해주는 시스템에 지속 배포만 하고 싶음
    • 훌륭한 기능이 될 것 같음. 비슷한 문제가 있는데, 검토 과정을 거친 공식 문서 버전이 있고 다음 버전을 Confluence에서 작업하려면 별도 작업용 페이지를 만들어야 함
      그러면 검색 결과가 오염되고 금방 지저분해짐
    • 문서 병합 요청이 핵심 요구라면, Git이나 다른 버전 관리 시스템으로는 충분하지 않은 다른 기능이 무엇인지 궁금함
    • 있으면 정말 좋을 기능임

  • 위키와 회사 내에서 위키를 쓰는 특정 방식들을 아주 좋아함
    다만 위키를 이해하지 못하는 고객을 상대로 한 기업 영업에 이끌리는 듯한 일부 위키 소프트웨어 제품은 그만큼 좋아하지 않음. 어떤 기업용 제품이 꽤 잘했던 점은 그리기 도구 통합이었음. 회사 모든 사람이 이 통합을 필요로 하진 않지만, 일부 사용자에게는 필요하고, 그 덕분에 없었으면 남지 않았을 아주 유용한 시각 자료가 기록될 수 있음

    • https://www.tldraw.com/는 적어도 Notion에 라이브 임베드할 수 있어서, 원래 그런 기능을 지원하지 않는 위키 안에서도 꽤 좋은 공동 그리기 기능을 제공함. Confluence나 다른 도구에서는 아직 안 써봤음
    • 위키를 좋아하는 이유에 대한 핵심 지혜를 몇 가지 요약해줄 수 있는지 궁금함. 특히 회사 안에서 어떤 사용 방식이 가장 효과적인지 알고 싶음

  • 대부분의 문서 소프트웨어에서 가장 큰 문제는 두 가지임
    첫째, 모든 것이 갇혀 있음. 노트를 쉽게 내보내거나 백업할 수 있어야 함. 둘째, 가격 정책이 너무 자잘하게 돈을 뜯는 느낌임. 문서 트리에 노드가 100개를 넘으면 요금제를 올리라든가, 프로젝트에 사람을 추가할 때마다 구매 결정이 되어 피로함. Postgres와 Redis를 어떻게 쓰는지 더 설명해줄 수 있으면 좋겠음

    • Postgres는 모든 워크스페이스와 사용자 관련 데이터를 저장하는 주 데이터베이스임
      Redis는 큐, 서버 간 협업 편집기 상태 동기화, 서버 간 WebSocket 동기화에 사용함. 마지막 두 기능은 여러 노드나 복제본으로 소프트웨어를 실행할 때 중요함

  • XWiki에서 일하고 있음. 오픈소스 대안을 만드는 동료들을 보니 반갑고, 이런 시도는 많을수록 좋음
    Confluence에 견줄 만한 것을 만들려면 정말 많은 작업이 필요하고, XWiki는 초창기부터 이 영역에 있었음. Docmost를 XWiki와 비교해 어떻게 포지셔닝하는지, 힘을 합치지 않기로 한 이유가 궁금함
    https://xwiki.org

    • Confluence에서 오픈소스 무언가로 옮기고 싶어서 XWiki를 써봤지만, 사용자 경험이 상대적으로 거칠게 느껴졌음
      Confluence 같은 경험을 원하는 사람들에게 더 받아들일 만하게 만들어주는 추천 확장 묶음이 있는지 궁금함

  • 이런 기능들이 있으면 좋겠음
    원하는 편집기를 써서 페이지를 Git이나 다른 버전 관리 시스템에서 일반 텍스트로 관리하고, 브라우저를 거치지 않고도 페이지를 커밋할 수 있으면 좋겠음. 페이지는 어떤 마크업 언어로 쓰되, Markdown은 일부 영역에서 표현력이 부족하니 단순 페이지는 파일 확장자로 Markdown임을 알 수 있게 하고, 위키는 reStructuredText처럼 사용자가 확장 가능한 더 강력한 형식도 허용하면 좋겠음. 또한 페이지를 서버 쪽에서 렌더링하고 쉽게 캐시할 수 있으면 좋겠음. 페이지가 파일이면 sha 합으로 캐시 유효성을 쉽게 확인할 수 있어, 느리고 형편없는 Confluence와 달리 거의 즉시 표시될 수 있음

    • 완전히 같은 용례는 아니지만, 한 프로젝트의 정적 문서 사이트를 만드는 데 https://nextra.site/를 아주 잘 쓰고 있음
      대부분 그냥 일반 Markdown을 쓰게 해주면서도 필요할 때 React 컴포넌트로 내려갈 수 있는 균형을 잘 잡았음. main에 병합하면 GitHub Pages로 지속 배포하는 식이면 꽤 좋은 경험임
    • 브라우저 밖에서 Markdown 문서를 쓰고 Git으로 버전 관리한다면 이런 도구가 왜 필요한지 모르겠음. 그 자체로 목적을 무너뜨리는 것 아닌가 싶음
      아니면 개발자 친화적인 워크플로로 문서를 올리고, 나머지 비개발자 팀원이 보게 하려는 건지 궁금함. 일반적으로는 정말 나쁜 생각이라고 봄. 직접 호스팅하는, 아마 버그 많은 MVP를 팀에 던져놓고 정작 본인은 모두가 쓰는 UI 계층을 다루지 않는다면 반발과 도구 교체가 일어날 조합임. 기술 창업자들이 이 실수를 정말 많이 봤음. 정적 사이트 + Markdown + Git이 비개발자에게 확장되지 않는다는 걸 깨닫고, 본인은 안 쓰는 헤드리스 CMS가 일상 사용에서 형편없다는 걸 알게 되는 마케팅 웹사이트 CMS에서도 같은 일이 벌어짐
    • 회사에서는 이 용도로 Jekyll을 쓰고, GitHub Actions로 사이트를 빌드한 뒤 GitHub Pages로 호스팅함
      아주 잘 동작하고 Mermaid 다이어그램, MathML 등도 지원함
    • MyST를 본 적 있는지 궁금함. ReST만큼 표현력이 좋고, 개인적으로는 훨씬 쓰기 쉽다고 봄
    • Markdown 반대에 한 표 더함
      Markdown은 단순 문서에는 괜찮지만, 페이지 간 링크가 핵심인 위키에는 매우 약함. 개인적으로는 Creole 마크업이 위키 작성에 훨씬 낫다고 봄. 파일 형식을 확장자에 저장하지 말고, 메타데이터는 제대로 메타데이터로 저장하는 편이 좋음. 애플리케이션이 어차피 훨씬 더 많은 메타데이터를 갖고 싶어 할 가능성이 높아서, 결국 메타데이터 저장 체계가 필요해짐. 파일명에서 메타데이터를 없애자는 외로운 십자군을 자처하고 있음

  • Confluence는 지금까지 써본 기업용 소프트웨어 중, 어쩌면 거대한 Jira를 제외하면 가장 느렸음
    PayPal에서는 “Confluence 기다리는 중”이 “내 모노레포가 모든 의존성을 다운로드하는 중” 같은 관용구가 됐음. 동네 반대편 문서가 로드되기를 기다리느라 길 건너 커피를 마시고 오는 긴 휴식이 가능했음. 그 문서를 업데이트하려고 시도하지도 않았으니, 이보다 나은 것은 무엇이든 더 나음. 거의 과장이 아님

  • 아주 멋진 프로젝트임. 후원할 방법이 있는지 궁금함
    문서가 Docusaurus를 쓰고 있는 것도 봤는데, 여기에 Docmost 자체를 사용하는 것도 좋을 듯함. 그러면 읽기 전용이라도 데모 환경이 되고, 동시에 직접 써보는 개발 방식도 될 수 있음

답변달기