셀프 호스팅 Slack 대안 비교: Mattermost, Rocket.Chat 등

운영해 볼 만한 셀프 호스팅 Slack 대안

소규모 팀이 시간을 투자할 가치가 있는 셀프 호스팅 Slack 대안으로는 Mattermost, Rocket.Chat, Matrix(Synapse 포함), Zulip이 있습니다. 단일 서버에서 내부 팀용 도구로 운영한다면 Mattermost를 선택하십시오. 공개 커뮤니티용이라면 Zulip이 적합합니다. 타인이 소유한 서버와 통신해야 하는 경우에만 Matrix와 Synapse를 운영하십시오. 페더레이션은 다른 도구들이 모방할 수 없는 유일한 기능인 동시에, 관리자로서 수행해야 할 업무의 성격을 완전히 바꾸어 놓기 때문입니다.

이 네 가지 도구는 기능 목록만으로는 차별화하기 어렵습니다. 모두 채널, 스레드, 검색, 파일 업로드, 모바일 앱 기능을 제공합니다. 이들을 구분 짓는 기준은 매달 관리자에게 요구하는 사항들입니다. 즉, 메모리 사용량, 유지 관리해야 하는 데이터베이스, 직접 제어하기 어려울 수 있는 모바일 푸시 경로, 그리고 필요한 기능이 유료 결제 뒤에 숨어 있는지 결정하는 라이선스 정책이 핵심입니다. 아래의 비교는 사용자 10명과 100명 규모를 기준으로 작성되었습니다.

네 가지 솔루션의 실제 정체

Mattermost는 PostgreSQL 데이터베이스를 사용하는 Go 기반 서버입니다. 하나의 바이너리, 하나의 데이터베이스, 하나의 설정 파일로 구성됩니다. 스레드와 슬래시 명령어를 포함하여 Slack과 유사하게 동작하며, 운영 측면에서 이 네 가지 중 가장 흥미롭지 않다는 점은 오히려 장점입니다.

Rocket.Chat은 MongoDB 위에서 동작하는 Node.js 애플리케이션입니다. 음성 및 영상 통화, 이메일과 소셜 채널의 고객 대화를 하나의 인터페이스로 통합하는 옴니채널 받은 편지함 등 여기 소개된 솔루션 중 가장 방대한 기능을 제공합니다. 만약 이 받은 편지함 기능 때문에 도입을 고려한다면, 전용 지원 데스크인 Chatwoot과 먼저 비교해 보십시오. 지원 업무를 수행하는 채팅 서버와 팀 협업을 위한 채팅 서버는 요구되는 역할이 다르기 때문입니다.

Matrix는 제품이 아닌 프로토콜입니다. Synapse는 참조용 서버(Python, PostgreSQL)이며, Element는 가장 널리 사용되는 클라이언트입니다. 이 목록에서 유일하게 본인이 운영하지 않는 외부 서버와 통신할 수 있는 옵션입니다.

Zulip은 PostgreSQL, RabbitMQ, memcached, Redis를 기반으로 하는 Python 서버(Django 및 Tornado)이며, 자체 스크립트를 통해 하나의 단위로 설치됩니다. 채널 내 토픽 기반의 모델을 채택하고 있어 화요일에 나눈 대화를 금요일에도 쉽게 찾을 수 있습니다. 2026년 4월에 버전 12.0이 출시되었습니다.

10명 및 100명 사용자 환경에서의 RAM 용량과 데이터베이스 선택

아래 표의 모든 수치는 2026년 8월 기준 해당 프로젝트의 공식 문서를 바탕으로 합니다. 이는 필자가 직접 측정한 값이 아니며 임의로 생성한 수치도 아닙니다. 모든 행은 동일한 기준을 따릅니다. 즉, 프로젝트가 게시한 최소 구성 사양이며, 데이터베이스가 별도로 명시된 경우 해당 용량을 포함합니다.

[
  {
    "label": "Synapse",
    "published_ram_gb": 1,
    "notes": "Synapse install docs: at least 1 GB free RAM if you want to join large public rooms. PostgreSQL is required for production and is not sized."
  },
  {
    "label": "Mattermost",
    "published_ram_gb": 2,
    "notes": "Mattermost requirements: 1 to 1,000 users on 1 vCPU and 2 GB RAM, single server, database included."
  },
  {
    "label": "Zulip",
    "published_ram_gb": 2,
    "notes": "Zulip requirements: under 100 users on 1 CPU, 2 GB RAM and 2 GB swap. 100 users and above needs 2 CPUs and 4 GB."
  },
  {
    "label": "Rocket.Chat",
    "published_ram_gb": 8,
    "notes": "Rocket.Chat requirements: smallest published tier is 4 GiB for the app plus 4 GiB for MongoDB, rated up to 500 concurrent users."
  }
]

각 행의 구성 방식이 다르다는 점이 첫 번째로 주목할 만한 사실입니다. Synapse의 1 GB는 Synapse 프로세스만을 위한 최소 사양이며, 대규모 공개 방에 참여하려면 그만큼의 여유 RAM이 추가로 필요하다는 조건이 붙습니다. PostgreSQL은 이 수치에 포함되지 않습니다. Mattermost의 2 GB는 데이터베이스를 포함한 전체 시스템 사양이며, 단일 vCPU 환경에서 1명부터 1,000명까지의 사용자를 수용합니다. Zulip은 100명 미만 사용자 환경에서 2 GB RAM과 CPU 1개, 그리고 2 GB의 스왑(swap)을 권장하며, 100명 이상부터는 4 GB RAM과 CPU 2개를 요구합니다. Rocket.Chat은 여기서 가장 큰 수치인 8 GB를 제시하는데, 이는 애플리케이션에 4 GiB, MongoDB에 4 GiB를 할당하기 때문이며 이 사양은 최대 500명의 동시 접속자를 기준으로 합니다.

사용자가 10명일 때는 4개 서비스 모두 일반적인 하드웨어 사양에서 문제없이 구동됩니다. 사용자가 100명으로 늘어나면 요구 사양이 갈라집니다. Mattermost는 여전히 2 GB 사양 내에서 동작하지만, Zulip은 4 GB RAM과 두 번째 CPU를 요구하며, Rocket.Chat은 최소 사양이 8 GB로 고정되어 있습니다. 이는 MongoDB의 메모리 점유율이 사용자 수보다는 시스템 전체 사양에 따라 결정되기 때문입니다.

데이터베이스 선택은 일일 성능보다 향후 업그레이드 계획에 더 큰 영향을 미칩니다. Mattermost는 PostgreSQL 14 이상을 필요로 하며 v11부터 MySQL 지원을 중단했으므로, 현재 MySQL을 설치하면 추후 마이그레이션이 필수적입니다. Synapse는 SQLite에서 구동되지만, 대규모 방에서 성능이 저하되므로 테스트 용도로만 적합하다고 공식 문서에 명시되어 있습니다. Rocket.Chat 8은 MongoDB 8.0을 요구하므로, 데이터베이스 업그레이드와 채팅 서비스 업그레이드를 별개의 작업이 아닌 하나의 프로젝트로 진행해야 합니다.

2 GB VPS로 실제로 무엇을 할 수 있는가

2 GB 플랜은 대부분의 제공업체에서 제공하는 기본 사양이며, 아래 네 가지 항목 중 두 가지에 대한 실질적인 해답이 됩니다.

• Mattermost는 적합합니다. 이 서비스는 공급업체 문서에서 2 GB 사양을 명시하고 있으며, PostgreSQL을 같은 서버에 설치할 경우 최대 1,000명의 사용자를 수용할 수 있습니다. 10명 정도의 사용자가 2 GB 환경에서 쾌적하게 사용할 수 있습니다.
• Zulip은 swap을 사용하면 적합합니다. 공식 문서에서는 5 GB 미만의 시스템에 swap 설정을 권장하며, RAM이 부족한 환경에서는 업그레이드 도중 메모리 부족 오류가 발생할 수 있다고 경고합니다. 이때 tools/webpack 단계에서 실패가 발생합니다. 이는 설치 시점이 아닌 업그레이드 시점에 직면하게 되는 실제 장애입니다.
• Synapse는 사용량이 적을 때 적합합니다. 유휴 상태의 메모리 점유율은 낮습니다. 문제는 사용량이 급증할 때 발생하며, 아래의 페더레이션 관련 섹션에서 그 원인을 설명합니다.
• Rocket.Chat은 2 GB 환경에서 피해야 할 서비스입니다. 그 원인은 MongoDB의 스토리지 엔진 때문입니다. WiredTiger는 내부 캐시 크기를 (RAM - 1 GB)의 50% 또는 256 MB 중 큰 값으로 설정합니다. 따라서 2 GB 장비에서는 Node.js가 시작되기도 전에 약 512 MB를 점유합니다. 결과는 깔끔한 실행 거부가 아닙니다. 설치는 되고 실행도 되지만, 기록이 쌓일수록 느려지다가 결국 커널의 out of memory killer가 당시 가장 메모리를 많이 점유하던 프로세스를 강제로 종료하게 됩니다.

결정을 내리기 전에 실제 사양을 확인하십시오. 제공업체마다 RAM을 계산하는 방식이 free와 다를 수 있기 때문입니다.

free -h
swapon --show

채팅 서버만이 서버의 유일한 작업이 아님을 기억하십시오. TLS(transport layer security) 종료, 백업, 컨테이너 런타임 모두 메모리를 사용합니다. 어떤 서버를 선택하든 Nginx, Caddy, Traefik 등 익숙한 리버스 프록시 뒤에 배치하십시오. 컨테이너로 배포한다면 VPS를 위한 Docker Compose 기초를 먼저 올바르게 설정하는 것이 중요합니다.

모바일 앱에 자체 푸시 서버가 필요한가

이 질문은 배포 후에야 마주하게 되는 핵심이며, 운영 방식을 결정짓는 가장 중요한 요소입니다.

작동 원리는 다음과 같습니다. Apple Push Notification service(APNs)와 Firebase Cloud Messaging(FCM)은 해당 앱의 서명 자격 증명을 보유한 주체로부터만 알림을 수락합니다. 사용자가 직접 빌드하지 않은 앱에는 서버가 푸시를 보낼 수 없습니다. 따라서 벤더가 제공하는 App Store 빌드를 사용하는 자체 호스팅 채팅 서버는 벤더의 게이트웨이를 거쳐야 하며, 이때 벤더가 정한 조건을 따라야 합니다.

• Mattermost. 무료 경로는 https://push-test.mattermost.com에 위치한 Test Push Notification Service(TPNS)를 사용하는 것이지만, 문서에 명시된 대로 프로덕션 환경에는 권장되지 않으며 서비스 수준 협약(SLA)도 제공하지 않습니다. 이 서비스는 App Store 및 Play Store 빌드에서만 작동합니다. Hosted Push Notification Service(HPNS)는 프로덕션 등급이며 유료 구독이 필요합니다. 세 번째 방법은 푸시 프록시를 직접 컴파일하는 것인데, 이 경우 자체 APNs 및 FCM 자격 증명을 포함하여 앱을 직접 빌드하고 배포해야 합니다.
• Rocket.Chat. 푸시 기능을 사용하려면 워크스페이스를 Rocket.Chat Cloud에 등록해야 하며, 커뮤니티 워크스페이스는 월 10,000건의 푸시 알림으로 제한됩니다. 이는 워크스페이스 전체에서 하루 약 330건에 해당합니다. 할당량을 모두 소진하면 월이 바뀔 때까지 알림이 전송되지 않으며, 사용자들은 이를 앱이 고장 난 것으로 인식하게 됩니다.
• Matrix with Element. Synapse는 푸시 게이트웨이로 알림을 보내며, 공식 Element 앱은 https://matrix.org/_matrix/push/v1/notify에서 운영되는 matrix.org 게이트웨이를 사용하도록 설정되어 있습니다. 페이로드에는 메시지 본문 대신 이벤트 및 방 식별자가 포함되며, 앱이 서버에서 콘텐츠를 직접 가져오는 방식이므로 게이트웨이는 대화 내용이 아닌 메타데이터만 확인하게 됩니다. 자체 Sygnal 게이트웨이를 운영하는 것도 가능하지만, 이 경우 앱을 직접 빌드하고 배포해야 합니다. Android의 경우 중간 단계로 직접 호스팅하는 ntfy 서버와 UnifiedPush를 사용하는 방법이 있습니다.
• Zulip. 무료 플랜은 최대 10명의 사용자까지 모바일 푸시 서비스를 제공합니다. 10명을 초과하면 플랜이 필요하지만, 무료 Community 플랜이 많은 비영리 조직을 지원합니다. 2026년 4월에 출시된 Zulip 12.0부터는 푸시 페이로드에 대한 종단간 암호화(E2EE)가 추가되었습니다.

사용자가 10명일 때는 위 서비스 모두 비용 부담 없이 알림 기능을 사용할 수 있습니다. 하지만 사용자가 100명으로 늘어나면 상황이 달라집니다. Zulip은 유료 플랜이 필요하고, Mattermost는 SLA와 지원이 없는 테스트 서비스를 계속 사용해야 하며, Rocket.Chat은 월간 제한이 제약 조건이 됩니다. 반면 Matrix는 게이트웨이를 무료로 사용할 수 있어 영향을 받지 않습니다.

무료로 싱글 사인온(SSO)을 제공하는 서비스

싱글 사인온(SSO)은 오픈 코어 비즈니스 모델이 가장 명확하게 드러나는 지점입니다.

• Zulip은 SAML(Security Assertion Markup Language) 및 LDAP(Lightweight Directory Access Protocol) 기능을 자체 호스팅 서버에 무료로 포함합니다. 별도로 구매해야 하는 계층은 없습니다.
• Synapse는 자체 설정 파일에서 OpenID Connect(OIDC), SAML 및 CAS를 무료로 지원합니다. 최근 배포 환경에서는 기존 Synapse 인증에서 단방향 마이그레이션이 가능한 별도 서비스인 Matrix Authentication Service를 사용하는 경우가 늘고 있으므로, 나중에 발견하기보다 미리 해당 전환을 계획하십시오.
• Rocket.Chat 커뮤니티 에디션은 기본적인 LDAP 및 SAML 로그인을 제공합니다. 확장된 사용자 속성 동기화, 그룹 및 팀 매핑, 백그라운드 동기화는 엔터프라이즈 라이선스가 필요합니다.
• Mattermost 무료 Team Edition은 GitLab OAuth만 제공합니다. SAML, AD/LDAP 및 OpenID Connect는 유료 기능입니다.

여러 서비스를 하나의 로그인으로 운영할 계획이라면, 서비스 앞단에 자체 호스팅 Authentik ID 공급자를 배치하고 보유한 라이선스로 해당 서비스들과 연동이 가능한지 확인하십시오.

페더레이션이 실제로 요구하는 비용

페더레이션은 Matrix가 존재하는 이유입니다. 사용자가 다른 사람이 호스팅하는 방에 참여하여 해당 서버에 계정을 둔 사람들과 대화하는 방식은 메일 서버가 메일을 교환하는 방식과 같습니다. 이 페이지에 나열된 다른 어떤 선택지도 이 기능을 제공하지 않습니다. 이 기능이 필요하다면 다른 대안은 없습니다.

또한 페더레이션은 Synapse가 다른 종류의 워크로드를 가지는 이유이기도 합니다. 사용자가 페더레이션된 방에 참여하면, 서버는 해당 방의 상태와 이벤트 사본을 가져오며 다른 서버의 사용자가 게시한 아바타, 이미지, 파일 등의 미디어를 캐시합니다. 따라서 디스크 사용량은 본인이 생성하지 않은 방과 서버에 계정이 없는 사람들에 의해 결정됩니다. 이것이 바로 Synapse 설치 환경에서 자체 사용자가 보낸 메시지 양보다 훨씬 큰 미디어 저장소가 생성되는 이유입니다. 또한 대규모 공개 방에 참여하는 작업이 문서에서 메모리 조건을 명시하는 이유이기도 합니다.

디스크가 가득 찬 날이 아니라 첫날에 보존 정책을 설정하십시오.

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Synapse는 버전 1.61에서 media_retention 기능을 추가했으며, 로컬 미디어와 원격 미디어에 대해 별도의 보존 기간을 설정할 수 있습니다. 원격 미디어는 캐시이므로 사용자가 삭제된 파일을 다시 요청하면 Synapse는 해당 파일이 원래 있던 서버에서 다시 가져옵니다. 로컬 미디어는 캐시가 아니므로 짧은 local_media_lifetime 설정은 사용자가 업로드한 파일을 영구적으로 삭제합니다.

솔직한 요약: 사용자들이 서로 간에만 대화한다면, 페더레이션은 아무런 이점을 주지 않으면서 디스크, 대역폭, 더 복잡한 업그레이드 경로라는 비용만 발생시킵니다. 페더레이션을 끄거나 다른 서버를 선택하십시오.

업그레이드는 어떻게 진행됩니까

Zulip은 가장 간편합니다. 스크립트 하나로 처리되며, 대규모 데이터베이스 마이그레이션이 포함되지 않는 한 문서화된 다운타임은 30초 미만입니다. 설치 및 업그레이드는 서버에서 직접 다음 명령을 실행하여 수행합니다.

cd $(mktemp -d)
curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
tar -xf zulip-server-latest.tar.gz

설치 프로그램은 root 권한으로 실행하십시오. --push-notifications 플래그는 설치 중에 서버를 모바일 푸시 서비스에 등록하며, 이때 서비스 약관 동의를 요청하므로 시작하기 전에 미리 읽어보시기 바랍니다.

sudo ./zulip-server-*/scripts/setup/install --push-notifications --certbot \
    --email=YOUR_EMAIL --hostname=YOUR_HOSTNAME

이후의 업그레이드는 동일한 tarball을 사용하며 명령어 하나로 완료됩니다.

curl -fLO https://download.zulip.com/server/zulip-server-latest.tar.gz
sudo /home/zulip/deployments/current/scripts/upgrade-zulip zulip-server-latest.tar.gz

Mattermost는 예측 가능합니다. 바이너리를 교체하고 재시작하면 시작 시점에 마이그레이션이 실행됩니다. 2025년 8월 릴리스부터 Extended Support Release (ESR) 트랙이 9개월마다 출시되며 12개월간 지원을 제공합니다. ESR에서 ESR로의 업그레이드가 검증된 경로입니다. 여러 ESR 버전을 건너뛰는 것도 지원은 하지만 테스트되지는 않았으므로, 실제로는 사용자가 직접 테스트하는 셈이 됩니다.

Rocket.Chat은 세 가지 업그레이드가 결합되어 있습니다. 2026년 8월 기준으로 8.x 라인이 최신이며, 2026년 8월 6일에 8.7.0이 릴리스되었습니다. 이 버전은 MongoDB 8.0과 일치하는 Node.js 버전을 요구합니다. 메이저 버전을 건너뛰면 애플리케이션이 데이터베이스를 열지 못하는 상황이 발생할 수 있습니다. Rocket.Chat Docker Compose 설치 가이드는 이러한 의존성을 고정해주며, 이것이 컨테이너 방식을 권장하는 주된 이유입니다.

Synapse는 주의 깊은 확인이 필요합니다. 모든 릴리스에는 업그레이드 노트가 있으며, 최종 도착 버전뿐만 아니라 거쳐 가는 모든 버전의 노트를 읽어야 합니다. 업그레이드 후 Synapse는 데이터베이스에 대해 백그라운드 업데이트를 실행합니다. 소규모 서버에서는 이 작업으로 인해 몇 시간 동안 시스템이 느려질 수 있으며, 이는 오류가 아닌 정상적인 동작입니다.

라이선스 조건에 대한 쉬운 설명

Mattermost는 컴파일된 Team Edition 빌드를 MIT 라이선스로 배포합니다. 반면 소스 코드는 AGPLv3 또는 상용 라이선스로 제공되며, 저장소의 일부는 프로덕션 환경에서 실행 시 유료 라이선스가 필요한 Mattermost Source Available License를 따릅니다. Rocket.Chat은 ee/ 디렉터리를 제외하고는 MIT 라이선스를 따르며, 해당 디렉터리는 별도의 엔터프라이즈 라이선스가 적용됩니다. Synapse는 1.99.0 버전부터 Apache 2.0에서 AGPLv3로 라이선스를 변경했으며, 기여자들은 Element가 해당 라이선스에 대한 예외 조항을 판매할 수 있도록 허용하는 CLA에 서명합니다. Zulip은 엔터프라이즈 디렉터리가 없는 Apache 2.0 라이선스를 따르며, 이것이 Zulip의 SSO 기능에 별도의 제약 사항이 없는 이유입니다.

실질적인 해석은 다음과 같습니다. AGPL은 서버를 수정하여 타인에게 서비스 형태로 제공하려는 경우에만 중요합니다. 소규모 팀에게 훨씬 더 중요한 것은 오픈 코어 정책, 즉 무료 빌드에서 제외된 기능이 무엇인지입니다. Zulip은 제외된 기능이 가장 적고, Mattermost는 가장 많습니다.

어떤 것을 선택해야 하는가

내부 팀 도구. Mattermost를 선택하십시오. 문서화된 리소스 점유율이 가장 낮고, 업그레이드가 가장 안정적이며, 별도의 설명이 필요 없는 익숙한 인터페이스를 제공합니다. SSO가 필수 요구 사항이 되는 날을 대비해 유료 플랜을 계획하십시오. 대부분의 팀에게 그날은 반드시 찾아오기 때문입니다.

커뮤니티 서버. Zulip을 선택하십시오. 토픽 기능은 활발한 공개 채널을 몇 달이 지나도 읽기 쉽게 유지해주며, SAML과 LDAP은 무료로 제공되고, 업그레이드는 명령어 한 줄로 가능합니다. 커뮤니티의 성격이 실시간 채팅보다는 게시글과 댓글에 가깝다면, 자체 호스팅 포럼 소프트웨어를 먼저 비교해보십시오. 포럼은 검색 엔진 최적화에 더 유리하며 푸시 인프라가 전혀 필요하지 않기 때문입니다. 음성, 영상 및 옴니채널 기능이 필요하고 공식 문서에서 요구하는 8 GB의 메모리를 할당할 수 있다면 Rocket.Chat을 선택하십시오.

상호 운용이 필수적인 네트워크. Synapse와 Element를 포함한 Matrix를 선택하십시오. 미디어 데이터 증가를 수용하고 첫날부터 보존 정책을 설정하며, PostgreSQL을 연결하고 예상보다 더 많은 디스크 공간을 할당하십시오. 직접 제어하지 않는 서버와 통신함으로써 실질적인 가치를 얻을 수 있습니다. 연합(federation)을 전혀 사용하지 않는 팀이 Synapse를 선택하는 것은 불필요한 비용을 지불하는 것과 같습니다.

FAQ

소규모 팀을 위한 최고의 자가 호스팅 Slack 대안은 무엇입니까?

대부분의 내부 팀에는 Mattermost가 적합합니다. Mattermost 문서는 1 vCPU와 2 GB RAM을 갖춘 단일 머신에서 PostgreSQL과 함께 1명부터 1,000명까지의 사용자를 지원한다고 명시하고 있으므로, 대부분의 제공업체가 판매하는 보급형 VPS 요금제에 적합합니다. 단점은 싱글 사인온(SSO)입니다. 무료 Team Edition은 GitLab OAuth만 지원하며, SAML, AD/LDAP, OpenID Connect는 모두 유료 플랜이 필요합니다. Slack과 유사한 인터페이스보다 무료 SSO가 더 중요하다면 대신 Zulip을 운영하십시오.

2 GB VPS에서 자가 호스팅 채팅 서버를 운영할 수 있습니까?

Mattermost는 가능하며, Zulip은 Zulip 자체 문서에서 5 GB 미만 환경에서 권장하는 스왑(swap)을 추가하면 가능합니다. Rocket.Chat은 실망스러울 수 있습니다. MongoDB의 WiredTiger 엔진이 캐시로 (RAM - 1 GB)의 50% 또는 256 MB 중 더 큰 값을 점유하기 때문에, 애플리케이션이 시작되기도 전에 2 GB 서버의 약 512 MB가 사라집니다. 설치는 되지만 대화 기록이 쌓일수록 성능이 저하되어 결국 메모리 부족(OOM)으로 종료됩니다. Rocket.Chat이 공식적으로 권장하는 최소 사양은 애플리케이션용 4 GiB와 MongoDB용 4 GiB입니다.

자가 호스팅 채팅 서버는 자체 모바일 푸시 알림 서버가 필요합니까?

대개는 필요하지 않습니다. Apple의 APNs와 Google의 FCM은 앱을 서명한 주체로부터만 알림을 수락하므로, 벤더의 앱은 벤더의 게이트웨이를 사용합니다. 조건은 각기 다릅니다. Mattermost는 SLA가 없는 무료 테스트 서비스와 유료 호스팅 서비스를 제공합니다. Rocket.Chat은 커뮤니티 워크스페이스의 푸시 알림을 월 10,000건으로 제한하며, 이를 초과하면 다음 달로 초기화될 때까지 알림이 중단됩니다. Zulip은 최대 10명의 사용자까지 푸시를 무료로 포함하며 그 이상은 플랜이 필요합니다. Matrix 홈 서버는 Element 앱에서 사용하는 게이트웨이를 통해 무료로 푸시를 보냅니다. 자체 앱 빌드를 배포하는 경우에만 자체 게이트웨이가 필요합니다.

다른 서버와 대화할 일이 없는 팀도 Matrix와 Synapse를 자가 호스팅해야 합니까?

아니요. 페더레이션(Federation)은 Synapse의 핵심 기능이며, 동시에 Synapse를 무겁게 만드는 원인이기도 합니다. 다른 서버의 방에 참여하면 해당 서버의 상태를 가져오고 미디어를 디스크에 캐시하므로, 우리 팀 사용자와 관계없이 저장 공간이 증가합니다. 그런 일이 발생하기 전에 media_retention를 짧은 remote_media_lifetime로 설정하십시오. 내부 대화만 하는 팀은 페더레이션의 이점은 누리지 못한 채 운영 비용만 부담하게 되며, Mattermost나 Zulip이 더 적은 하드웨어 자원으로 동일한 역할을 수행할 것입니다.

무료 싱글 사인온(SSO)을 지원하는 자가 호스팅 Slack 대안은 무엇입니까?

Zulip과 Synapse입니다. Zulip은 자가 호스팅 서버에 SAML과 LDAP을 무료로 포함하며, Synapse는 설정 파일에서 OpenID Connect, SAML, CAS를 지원하고 최신 설치 버전은 별도의 Matrix Authentication Service로 전환하고 있습니다. Rocket.Chat의 커뮤니티 에디션은 기본적인 LDAP 및 SAML 로그인을 지원하지만, 속성 동기화, 그룹 매핑, 백그라운드 동기화는 엔터프라이즈 라이선스가 필요합니다. Mattermost의 무료 Team Edition은 GitLab OAuth만 지원합니다.