Mattermost Calls 배포 가이드

이 가이드는 시스템 관리자가 Mattermost Calls를 배포하는 과정을 준비와 네트워크 점검부터 파일럿 테스트와 프로덕션 롤아웃까지 단계별로 안내합니다. 각 단계가 제대로 동작하는지 확인한 뒤 다음으로 넘어갈 수 있도록 명확한 의사 결정 지점, 검증 항목, 문제 해결 팁을 제공합니다.

Mattermost Calls를 다뤄 본 경험은 필요하지 않습니다. 이 가이드는 처음 시작한다는 전제로 필수 개념과 모범 사례를 함께 소개합니다.

Calls 개요

Mattermost Calls는 자체 호스팅 음성 통화와 화면 공유를 제공하여, 조직의 인프라 안에서 완전히 완결되는 주권형 실시간 협업을 가능하게 합니다. 통화 미디어나 메타데이터가 서드파티 시스템을 거치지 않는다는 뜻입니다.

Calls는 데이터 주권, 통제, 컴플라이언스가 타협 대상이 아닌 국방, 정보, 보안, 핵심 인프라 분야의 미션 크리티컬 운영에 특히 적합합니다. 인터넷 접속이 없는 격리망에서도 동작하도록 설계되어, 완전한 에어갭 요건을 요구하는 배포도 지원합니다.

제공 기능은 다음과 같습니다.

• 1:1 및 그룹 통화: 두 명 이상의 참가자 사이에서 실시간 음성 통신을 시작합니다.
• 화면 공유: 통화 중 화면을 공유해 작업을 함께 진행하고, 문서를 검토하며, 문제를 실시간으로 해결합니다.
• 통화 녹화와 전사: 나중에 검토할 수 있도록 음성 세션을 녹화합니다. (Enterprise, Enterprise Advanced)
• 실시간 자막: 접근성을 위해 실시간 자막을 생성합니다. (Enterprise, Enterprise Advanced)

배포 개요

이 가이드는 번호가 매겨진 단계로 구성된 순차적 배포 페이즈로 정리되어 있습니다. 각 페이즈는 사전 요구 사항으로 시작해 검증 항목으로 끝납니다. 어떤 페이즈든 시작하기 전에 나열된 사전 요구 사항을 충족했는지 확인하고, 검증 항목을 모두 통과한 뒤에만 다음 페이즈로 넘어가세요. 이런 구조는 문제를 가장 분리하기 쉬운 이른 시점에 발견하고 고치는 데 도움이 됩니다.

배포 페이즈:

1. 준비와 네트워킹

   배포 아키텍처를 선택하고, 네트워킹 관련 결정을 내리고, 필요한 서버를 프로비저닝한 다음, 배포 전에 필요한 네트워크 포트와 경로가 열려 있는지 확인합니다.

2. Calls 설치와 설정

   1단계에서 선택한 배포 아키텍처에 맞춰 설치와 설정을 완료합니다. 둘 중 한 가지 경로만 따릅니다.

   • 경로 A: 통합형 Calls 설정

     소규모 환경에서 더 간단하게 배포하려면 Mattermost 서버에 내장된 Calls 서비스를 사용합니다.

   • 경로 B: RTCD 설치와 설정 (선택)

     대규모 프로덕션 배포에는 RTCD(Real-Time Communication Daemon, 실시간 통신 데몬) 서비스를 사용합니다. RTCD는 미디어 처리 작업을 Mattermost 서버에서 분리해 성능과 확장성을 최적화합니다.

3. 녹화 설치와 설정 (선택)

   Calls Offloader는 녹화, 전사, 실시간 자막을 제공하는 데 필요한 서비스입니다.

4. 파일럿 롤아웃

   소규모 파일럿 사용자 그룹으로 테스트를 확대해, 실제 사용 환경에서 클라이언트·네트워크·환경별 문제를 관찰합니다.

5. 프로덕션 롤아웃

   적절한 공지와 모니터링을 병행하며 통제된 단계로 전체 사용자에게 배포하고, 필요하면 언제든 중단하거나 롤백할 수 있도록 대비합니다.

배포 사전 요구 사항

Calls 배포를 시작하기 전에 필요한 인프라, 역량, 접근 권한을 갖추었는지 이 체크리스트로 확인하세요. 지금 사전 요구 사항을 충족해 두면 배포 후반에 의존성이 없어 지연되는 일을 예방할 수 있습니다.

배포 인프라 요구 사항

• ☐ v10.0 이상의 Mattermost 서버가 실행 중입니다.

  Mattermost 에디션과 버전을 확인하려면 시스템 정보를 참고하세요.

• ☐ Mattermost 서버가 HTTPS를 사용하도록 설정되어 있습니다.

  HTTPS를 설정해야 한다면 TLS 설정을 참고하세요.

• ☐ 현재 Mattermost 배포의 활성 사용자 수를 알고 있습니다.

  사용량 지표를 확인하려면 사이트 통계를 참고하세요.

• ☐ RTCD 서비스를 사용할 계획이라면 전용 Linux 서버나 VM을 최소 한 대 프로비저닝할 수 있습니다.

  RTCD가 필요한지 확실하지 않다면 인프라 결정(1.2단계)을 참고하세요.

• ☐ 녹화, 전사, 실시간 자막이 필요하다면 calls-offloader 서비스용 전용 Linux 서버나 VM을 프로비저닝할 수 있습니다.

• ☐ 사용자가 UDP 또는 TCP 8443으로 미디어 서비스에 안정적으로 접근할 수 없다면 TURN 서버를 배포할 준비가 되어 있습니다.

  TURN 서버가 필요한지 확실하지 않다면 네트워킹 결정(1.3단계)을 참고하세요.

• ☐ 필요한 기능에 맞는 Mattermost 에디션과 라이선스를 보유하고 있습니다.

  • Mattermost Entry 또는 Team Edition: 1:1 통화와 화면 공유(최대 40분)
  • Mattermost Professional: 그룹 통화와 화면 공유(시간 제한 없음)
  • Mattermost Enterprise 또는 Enterprise Advanced: 다음 기능에 필요합니다.
    • 확장(50명 이상)과 프로덕션 안정성을 위한 RTCD 서비스
    • 녹화, 전사, 실시간 자막

역량과 접근 권한 요구 사항

• ☐ 기본적인 Linux 관리에 익숙하거나, 도와줄 수 있는 담당자가 있습니다. SSH로 서버에 접속하고, 설정 파일을 편집하고, systemd 서비스를 관리하고, 로그를 확인하고, 셸 명령을 실행해야 합니다.

• ☐ Mattermost 서버의 시스템 관리자 권한이 있습니다.

  역할과 권한에 관해서는 Mattermost 역할을 참고하세요.

네트워킹 요구 사항

• ☐ 최종 사용자가 Calls에 어떻게 접속하는지 알고 있습니다(사설 네트워크, VPN, 또는 공용 인터넷).

  이는 네트워킹 결정(1.3단계)에 영향을 미칩니다.

• ☐ 필요한 인바운드·아웃바운드 방화벽 규칙을 열 수 있거나, 이를 관리하는 네트워크·보안 팀과 협업할 수 있습니다.

검증 리소스

• ☐ Calls 설치·설정 중 스모크 테스트에 사용할 테스트 계정 두 개가 있습니다.
• ☐ 검증하려는 클라이언트 유형과 네트워크 전반을 확인할 소규모 파일럿 그룹(5~10명)이 있습니다.

지원 문의

• ☐ 문제가 발생했을 때 Mattermost 지원팀에 요청을 접수하는 방법을 알고 있습니다.

  실패한 단계 번호(예: 2A.2.1)와 함께 Mattermost 지원 패킷과 Calls 로그를 함께 첨부해 주세요.

1단계: 준비와 네트워킹

1.1 사전 요구 사항

시작하기 전에 다음을 확인하세요.

• ☐ 현재 Mattermost 배포의 활성 사용자 수를 알고 있습니다.
• ☐ 이번 배포에 녹화, 전사, 실시간 자막이 필요한지 파악하고 있습니다.
• ☐ 선택한 아키텍처에 RTCD나 녹화 서비스가 필요하다면 서버를 추가로 프로비저닝할 수 있습니다.

• ☐ 배포에 관여하는 서버에서 인바운드·아웃바운드 네트워크 포트를 열 수 있습니다.

  네트워크나 보안 팀이 방화벽을 관리한다면 계속 진행하기 전에 해당 팀과 협의해야 합니다.

1.2 인프라 결정

여기서는 두 가지 중요한 인프라 결정을 내립니다. 먼저 미디어 처리 아키텍처를 선택하고, 그다음 녹화가 필요한지 결정합니다. 각 아키텍처의 참조 토폴로지도 함께 제공합니다.

미디어 서비스: RTCD 또는 Integrated

Integrated

미디어 처리를 담당할 별도 서비스를 프로비저닝할 필요가 없으므로 가장 단순한 배포 모델입니다. Integrated 모드에서는 Calls 플러그인이 내장 미디어 서비스를 Mattermost 서버에서 직접 실행합니다.

RTCD

RTCD는 Mattermost Calls를 위한 전용 실시간 통신 서비스로, 메인 Mattermost 서버 바깥에서 통화 미디어를 처리합니다. 통화 트래픽을 분리해 Mattermost 서버의 부하를 줄임으로써 성능, 확장성, 안정성을 높이기 때문에, 대부분의 프로덕션 배포에서 RTCD가 권장 배포 모델입니다.

RTCD가 필요한지 판단하려면 배포 환경에 관한 다음 질문에 먼저 답해 보세요.

• Kubernetes에 Calls를 배포하나요?
  • 예: RTCD를 배포해야 합니다. Kubernetes에서 Calls를 실행하는 유일한 지원 방식입니다. 자세한 내용은 Kubernetes Calls 배포 가이드를 참고하세요.
  • 아니요: 다음 질문으로 넘어갑니다.
• 기존 Mattermost 배포의 전체 사용자 수는 얼마인가요? (사이트 통계를 확인하세요)
  • 50명 이하: Integrated 배포 모델을 사용할 수 있습니다.
  • 50명 초과: Mattermost 서버의 메시징 성능에 영향을 주지 않도록 RTCD를 배포해야 합니다.

각 배포 모델의 참조 아키텍처는 다음과 같습니다.

참조 아키텍처: Integrated

Integrated 배포에는 추가 인프라가 전혀 필요하지 않습니다.

사용 시점

• Calls를 처음 평가하는 경우
• Calls 사용자가 50명 미만일 것으로 예상되는 경우
• 가능한 한 단순한 배포를 원하는 경우

구성 요소

• Mattermost 서버: Calls 플러그인이 기본 탑재되어 있으며 추가 인프라가 필요하지 않습니다.

라이선스

• Mattermost Entry: 1:1 통화와 화면 공유(최대 40분)
• Mattermost Professional, Enterprise, Enterprise Advanced: 그룹 통화와 화면 공유(시간 제한 없음)

녹화

녹화, 전사, 실시간 자막을 사용해야 한다면 Integrated Calls 배포에 녹화 서비스(calls-offloader)를 선택적으로 추가할 수 있습니다.

Integrated Calls와 녹화 서비스를 함께 사용할 때의 참조 아키텍처입니다.

구성 요소

• Mattermost 서버: Calls 플러그인이 기본 탑재되어 있습니다.
• Calls Offloader: 녹화, 전사, 실시간 자막을 관리하는 잡 서비스입니다.

라이선스

• Mattermost Enterprise 또는 Enterprise Advanced

참조 아키텍처: RTCD

모든 통화 오디오와 화면 공유 미디어를 처리하는 전용 미디어 서비스로 RTCD 서버가 추가됩니다.

Mattermost 서버는 여전히 시그널링(통화 설정, 관리, 종료)과 채널 상태(누가 참여하거나 나갔는지, 누가 음소거했는지, 전체 통화 상태)를 담당하지만, 통화 미디어 자체는 Mattermost 서버를 완전히 우회해 클라이언트와 RTCD 서버 사이에서 직접 오갑니다.

사용 시점

Mattermost Calls에서 최적의 성능, 확장성, 최상의 사용자 경험이 필요하다면 RTCD를 사용하세요. 구체적으로는 다음과 같은 경우입니다.

• 서버 전체 성능을 개선하고 CPU 사용률 급등을 줄이기 위해 통화 미디어 트래픽을 메인 Mattermost 서버에서 분리하고 싶은 경우
• 통화량이 증가할 때 손쉽게 확장할 수 있어야 하는 경우(부하 분산을 위해 RTCD 서버를 추가할 수 있습니다)
• Calls의 미디어 지연을 최소화하고 신뢰성을 최대화하고 싶은 경우
• RTCD가 필수인 Kubernetes에 Mattermost를 배포하는 경우

구성 요소

• Mattermost 서버: Calls 플러그인이 기본 탑재되어 있습니다.
• RTCD 서버: 전용 미디어 서비스입니다. 클라이언트는 미디어 트래픽을 위해 여기에 직접 연결합니다.

라이선스

• Mattermost Enterprise 또는 Enterprise Advanced

녹화

녹화, 전사, 실시간 자막을 사용해야 한다면 RTCD Calls 배포에 녹화 서비스(calls-offloader)를 선택적으로 추가할 수 있습니다.

RTCD와 녹화 서비스를 함께 사용할 때의 참조 아키텍처입니다.

구성 요소

• Mattermost 서버: Calls 플러그인이 기본 탑재되어 있습니다.
• RTCD 서버: 전용 미디어 서비스입니다. 클라이언트는 미디어 트래픽을 위해 여기에 직접 연결합니다.
• Calls Offloader: 녹화, 전사, 실시간 자막을 관리하는 잡 서비스입니다.

라이선스

• Mattermost Enterprise 또는 Enterprise Advanced

1.3 네트워킹 결정

1.3.1 공인 IP 검색을 위한 STUN

STUN은 미디어 서버가 자신의 공인 IP 주소를 자동으로 찾아 원격 클라이언트가 Calls에 접속할 수 있도록 돕는 프로토콜입니다.

Mattermost는 기본 STUN 서버(stun.global.calls.mattermost.com)를 제공합니다. 이 서비스로는 통화 미디어나 시그널링 트래픽이 전송되지 않으며 STUN 조회에만 사용됩니다. 공인 IP 검색을 위해 미디어 서버에서 Mattermost 글로벌 STUN 서비스로의 아웃바운드 접근을 허용해야 하는지 다음 결정 트리로 판단하세요.

STUN 결정 트리

1. 모든 사용자와 미디어 서버가 같은 사설 네트워크, VPN, 또는 에어갭 환경에 있고 외부 클라이언트는 없나요?

   • 예: 공인 IP 검색을 위한 STUN이 필요하지 않습니다. 2단계 설정에서 미디어 서버의 사설 주소를 사용하게 됩니다.
   • 아니요: 다음 질문으로 넘어갑니다.

2. 미디어 서버에 공용 인터넷의 클라이언트가 접근할 수 있는 고정 공인 IP 주소나 DNS 이름이 있나요?

   • 예: 공인 IP 검색을 위한 STUN이 필요하지 않습니다. 2단계 설정에서 미디어 서버의 고정 공인 주소를 사용하게 됩니다.
   • 아니요: STUN이 필요합니다. 미디어 서버에서 stun.global.calls.mattermost.com으로 향하는 아웃바운드 UDP 3478을 열어야 합니다.

배포 환경에 공인 IP 검색용 STUN이 필요하다면, 1.5단계에서 포트를 열 때 포함할 수 있도록 지금 기록해 두세요.

1.3.2 TURN 서버

TURN은 클라이언트가 Calls 미디어 서비스에 직접 도달할 수 없을 때만 사용되는 릴레이 서비스입니다. STUN이 클라이언트가 어디로 연결해야 할지 찾도록 돕는다면, TURN은 직접 연결이 불가능할 때의 예비 경로 역할을 합니다.

다음 두 조건이 모두 참일 때 TURN 서버 프로비저닝이 필요합니다.

• 클라이언트가 미디어 트래픽을 위해 포트 8443의 UDP(선호)로 RTCD 서버나 Calls 플러그인에 직접 도달할 수 없는 네트워크에 있습니다.
• 클라이언트가 미디어 트래픽을 위해 포트 8443의 TCP(폴백)로 RTCD 서버나 Calls 플러그인에 직접 도달할 수 없는 네트워크에 있습니다.

TURN은 지연과 인프라 복잡도를 더하므로 일반적으로 최후의 수단입니다. 미디어에 UDP나 TCP를 사용할 수 없고 사용자에게 대체 경로가 필요하다는 결론이 나온 경우에만 TURN 배포를 계획하세요.

1.4 인프라 프로비저닝

이제 Calls 배포에 필요한 서버나 VM을 프로비저닝합니다. 여기서는 인프라를 준비하기만 하며, 소프트웨어 설치와 서비스 설정은 이후 페이즈에서 진행합니다. 다음 단계에서 네트워크 설정을 마치려면 이 서버들의 IP 주소나 DNS 이름이 필요하기 때문에 이 단계가 중요합니다.

인프라 요구 사항은 1.2단계에서 선택한 배포 인프라에 따라 달라집니다. 하드웨어를 추가로 프로비저닝한다면 1.5단계에서 사용할 IP 주소나 DNS 이름을 지금 기록해 두세요.

Integrated

Mattermost 서버가 모든 미디어 처리를 담당하므로 이 단계를 건너뛰고 1.5단계의 네트워크 설정으로 넘어가면 됩니다.

RTCD

RTCD용 서버를 새로 프로비저닝해야 합니다. 하드웨어 사이징 예시는 성능 기준치를 참고하세요. RTCD 서비스는 수평 확장을 지원하지만, 서버 한 대로 시작한 뒤 예상 워크로드에 따라 확장하기를 권장합니다.

녹화

calls-offloader 서비스용 서버를 새로 프로비저닝해야 합니다. 권장 출발점은 8 vCPU / 16 GB RAM이며, 성능 벤치마크를 사용해 녹화 용량과 전사 부하를 추정할 수도 있습니다.

TURN 서버

1.3.2단계에서 사용자가 UDP나 TCP 8443으로 미디어 서버에 안정적으로 도달할 수 없다고 판단했다면 지금 TURN 서버를 프로비저닝해야 합니다.

Mattermost는 coturn 설치를 권장합니다.

1.5단계로 넘어가기 전에 다음을 확인하세요.

• ☐ 필요한 모든 서버나 VM이 생성되었습니다.
• ☐ 필요한 모든 서버에 대해, 이후 설정에서 사용할 IP 주소나 DNS 이름을 확보했습니다.
• ☐ 필요한 모든 서버에 관리자 권한으로 접근할 수 있습니다(ssh <user>@<SERVER_IP>로 확인하세요).

1.5 네트워크 설정

이 섹션은 Calls 배포에 관여하는 각 서버에서 열어야 하는 네트워크 포트를 정리합니다. 이 규칙을 설정하려면 서버 인스턴스가 먼저 존재해야 하므로, 1.4단계의 프로비저닝이 앞에 오는 것입니다.

포트를 여는 방법은 환경에 따라 다릅니다.

• 클라우드 배포(AWS, Azure, GCP): 각 인스턴스의 클라우드 콘솔 보안 그룹이나 네트워크 ACL에서 인바운드·아웃바운드 규칙을 설정합니다.
• 온프레미스 또는 자체 관리 VM: 각 서버에서 firewalld(RHEL, Rocky Linux, AlmaLinux)나 ufw(Ubuntu/Debian) 명령을 직접 사용합니다.
• 중앙 관리 방화벽: 네트워크 팀이 방화벽을 관리한다면 아래 표를 공유하고 규칙 적용을 요청한 뒤 진행하세요.

빠뜨린 것이 없는지 확인하며 넘어갈 수 있도록 서버를 한 대씩 처리하세요.

선택한 배포 아키텍처(Integrated 또는 RTCD)에 해당하는 포트만 여세요.

포트 설정: Integrated

Mattermost 서버 포트

녹화 서버 포트

1.4단계에서 calls-offloader 서버를 배포했다면 다음 포트를 여세요.

TURN 서버 포트

1.4단계에서 TURN 서버를 배포했다면, 실제로 설정한 전송 방식에 필요한 포트만 여세요. coturn을 사용하는 경우 일반적인 기본값은 다음과 같습니다.

포트 설정: RTCD

Mattermost 서버 포트

RTCD 서버 포트

녹화 서버 포트

1.4단계에서 calls-offloader 서버를 배포했다면 다음 포트를 여세요.

TURN 서버 포트

1.4단계에서 TURN 서버를 배포했다면 다음 포트를 여세요. coturn을 사용하는 경우 일반적인 기본값은 다음과 같습니다.

1.6 네트워킹 점검

다음 점검은 방화벽 규칙과 네트워크 도달 가능성을 검증합니다. 프로덕션 Calls, RTCD, calls-offloader 서비스가 아직 설치되어 있지 않아도 됩니다. 이 서비스들이 존재하기 전에 신뢰할 수 있는 결과를 얻으려면, 아래의 해당 스캔을 실행하기 전에 대상 호스트에서 임시 리스너를 먼저 띄우세요. 차단된 포트와 허용되었지만 유휴 상태인 포트를 구분하기 어려운 UDP 점검에서 특히 중요합니다.

먼저 점검을 실행할 각 출발지 머신이나 클라이언트에 nmap을, 임시 리스너를 띄울 각 대상 호스트에 ncat을 설치하세요. 예를 들면 다음과 같습니다.

• Ubuntu 또는 Debian: sudo apt install nmap ncat
• RHEL, Rocky Linux, AlmaLinux: sudo dnf install nmap nmap-ncat

아래 각 점검을 실행하면 nmap이 open, closed, filtered 중 하나를 반환합니다.

통과:

• open: 포트에 도달할 수 있고, 대상 호스트가 해당 포트에 임시 리스너를 바인딩할 수 있었습니다.

실패:

• closed: 트래픽이 대상 호스트에 도달했지만 해당 포트에서 수신 대기 중인 것이 없습니다. 임시 리스너가 여전히 실행 중인지, 포트가 맞는지, 다른 프로세스가 이미 그 포트를 사용하고 있지는 않은지 확인하세요.
• filtered: 방화벽이 포트를 차단하고 있습니다. 계속하기 전에 1.5단계의 네트워크 설정을 다시 확인하세요.

Integrated 배포

Mattermost 서버에서 임시 리스너를 띄운 다음, 사용자와 같은 네트워크에 있는 아무 클라이언트 머신에서 nmap을 실행하세요.

RTCD 배포

RTCD 서버에서 임시 리스너를 띄운 다음, 사용자와 같은 네트워크에 있는 아무 클라이언트 머신에서 nmap을 실행하세요.

RTCD 서버에서 임시 리스너를 띄운 다음, Mattermost 서버에서 nmap을 실행하세요.

녹화 배포

녹화 서버(calls-offloader)에서 임시 리스너를 띄운 다음, Mattermost 서버에서 nmap을 실행하세요.

미디어 서버(RTCD 또는 Integrated 모드를 사용하는 경우 Mattermost 서버)에서 임시 리스너를 띄운 다음, 녹화 서버(calls-offloader)에서 nmap을 실행하세요.

다음 점검에서는 임시 ncat 리스너를 띄우는 대신, 실행 중인 Mattermost 서버의 기존 HTTPS 리스너를 사용하세요.

TURN 배포

TURN 서버에서 임시 리스너를 띄운 다음, 사용자와 같은 네트워크에 있는 아무 클라이언트 머신에서 nmap을 실행하세요.

1.7 검증 항목

2단계로 넘어가기 전에 다음을 모두 확인하세요.

• ☐ 배포 아키텍처를 선택하고 필요한 서버를 프로비저닝했습니다.
• ☐ 배포하려는 아키텍처와 기능을 Mattermost 라이선스가 지원하는지 확인했습니다.
• ☐ 선택한 아키텍처에 필요한 방화벽 규칙과 네트워크 경로를 모두 열었습니다.
• ☐ 1.6단계의 해당 네트워크 점검이 모두 기대한 결과(closed나 filtered가 아닌 open)를 반환했습니다.
• ☐ STUN이 필요하다면 stun.global.calls.mattermost.com으로의 아웃바운드 UDP 3478이 허용되어 있습니다.

2단계: Calls 설치와 설정

이제 배포 아키텍처에 해당하는 경로를 따라 Calls를 설정합니다. 하나의 배포에 두 경로를 모두 수행하지 마세요.

• Integrated Calls 배포 모델을 사용한다면 경로 A를 따릅니다.
• RTCD Calls 배포 모델을 사용한다면 경로 B를 따릅니다.

경로 A: 통합형 Calls 설정

2A.1 사전 요구 사항

• ☐ 1단계 검증 항목을 모두 통과했습니다
• ☐ 1.2단계에서 선택한 기본 아키텍처가 Integrated입니다
• ☐ Mattermost 서버에 테스트 계정 두 개가 있습니다
• ☐ Mattermost 서버의 시스템 관리자 권한이 있습니다

2A.2 Calls 플러그인 설정

Calls 플러그인은 Mattermost 자체 호스팅 배포에 기본 패키징되어 있습니다. System Console > Plugins > Calls > Settings로 이동해 다음 단계를 진행하세요.

2A.2.1: 플러그인 활성화

Enable Plugin을 true로 설정합니다. 이렇게 하면 페이지의 나머지 설정 항목을 편집할 수 있게 됩니다.

2A.2.2: 테스트 모드 활성화

초기 검증 중에는 Calls 사용 범위를 제한할 수 있도록 Test mode를 on으로 설정합니다. 이 모드에서는 시스템 관리자가 Calls를 사용할 위치를 통제하며, 테스트를 위해 특정 채널에서만 활성화할 수 있습니다.

2A.2.3: 호스트 미디어 주소 설정

ICE Host Override를 클라이언트가 미디어 서비스에 도달할 때 사용할 IP 주소나 DNS 이름으로 설정합니다. ICE(Interactive Connectivity Establishment)는 사용자의 기기가 미디어 서버로 가는 경로를 찾을 때 사용하는 프로토콜입니다. ICE Host Override는 클라이언트에 어떤 주소를 알릴지 Calls에 지정합니다. 이 값은 1.3.1단계의 STUN 결정 트리를 기준으로 정하세요.

• 사용자가 사설 네트워크, VPN, 또는 에어갭 환경에 있다면 그들이 접근할 수 있는 Mattermost 서버의 사설 주소로 설정합니다.
• Mattermost 서버에 고정 공인 IP가 있다면 그 IP로 설정합니다.
• 그 외의 경우에는 STUN을 사용한 공인 주소 자동 검색을 위해 비워 둡니다.

2A.2.4: TURN 서버 설정

TURN을 사용한다면 ICE server configurations 배열을 TURN 서버 정보로 교체하거나 확장합니다.

[
  {
    "urls": ["turn:turn.example.com:3478"],
    "username": "<USERNAME>",
    "credential": "<PASSWORD>"
  }
]

TURN 배포가 단기 생성 자격 증명을 사용한다면 TURN Static Auth Secret과 TURN Credentials Expiration도 설정하세요.

2A.2.5: 설정 저장

Calls 설정 페이지에서 Save를 클릭합니다. 미디어 서버 설정을 변경한 뒤에는 플러그인을 재시작하는 것도 권장합니다.

1. System Console > Plugins > Plugin Management로 이동합니다.
2. Calls를 비활성화하고 몇 초 기다립니다.
3. Calls를 다시 활성화합니다.

2A.3 검증 항목

이제 테스트 계정으로 Calls 배포를 스모크 테스트합니다.

• calls-test 같은 테스트 채널을 만듭니다.
• Channel menu를 열고 Enable calls를 선택합니다.
• 실제 통화를 검증할 수 있도록 테스트 사용자를 채널에 초대합니다.

경로 B: RTCD 설치와 설정

2B.1 사전 요구 사항

• ☐ 1단계 검증 항목을 모두 통과했습니다
• ☐ 1.2단계에서 선택한 기본 아키텍처가 RTCD입니다
• ☐ RTCD 서버를 프로비저닝했고(1.4) RTCD 네트워킹 점검을 통과했습니다(1.6.3~1.6.5)
• ☐ 서버에 Mattermost Enterprise 또는 Enterprise Advanced 라이선스가 활성화되어 있습니다
• ☐ Mattermost 서버에 테스트 계정 두 개가 있습니다
• ☐ Mattermost 서버의 시스템 관리자 권한이 있습니다

2B.2 RTCD 설치

실제 설치는 RTCD 설정과 구성 가이드를 따르세요. 이 가이드는 다음을 다룹니다.

• 바이너리 설치
• rtcd.toml 설정
• 서비스 설정
• TURN 설정(해당하는 경우)

계속 진행하기 전에 Mattermost 서버에서 다음 점검을 실행해 RTCD가 실행 중이고 접근 가능한지 확인하세요.

2B.3 Mattermost와 RTCD 연결

RTCD를 설치·설정하고 접근 가능한 상태로 만들었다면, Calls 플러그인이 이를 사용하도록 갱신합니다.

1. System Console > Plugins > Calls > Settings로 이동합니다.

2. Enable Plugin을 true로 설정합니다. 이렇게 하면 페이지의 나머지 Calls 설정을 편집할 수 있게 됩니다.

3. 초기 검증 중에는 Calls 사용 범위를 제한할 수 있도록 Test mode를 on으로 설정합니다. 이 모드에서는 시스템 관리자가 Calls를 사용할 위치를 통제하며, 테스트를 위해 특정 채널에서만 활성화할 수 있습니다.

4. RTCD Service URL을 RTCD 주소로 설정합니다. 설정 과정에서 RTCD 자격 증명이 생성되었다면 URL에 직접 포함하세요.

   http://clientID:authKey@rtcd.internal:8045
   

   clientID와 authKey를 RTCD 설정 중 생성된 값으로 바꾸세요. RTCD로의 첫 연결에서 클라이언트가 자체 등록되고 인증 키가 데이터베이스에 저장됩니다.

   또는 Mattermost 서버에 환경 변수 MM_CALLS_RTCD_CLIENT_ID와 MM_CALLS_RTCD_AUTH_KEY로 자격 증명을 설정할 수도 있습니다.

5. Save를 클릭한 뒤 변경 사항이 적용되도록 Calls 플러그인을 재시작합니다.

2B.4 Calls 모니터링 설정

파일럿에 앞서, 실제 사용자가 테스트하는 동안 세션, 오류, CPU, 메모리를 확인할 수 있도록 Calls 모니터링을 설정하세요.

Calls 모니터링은 Prometheus(서버에서 지표를 수집하는 도구)와 Grafana(그 지표를 시각화하는 대시보드)를 사용합니다. 아직 설정하지 않았다면 계속하기 전에 Mattermost 모니터링 설정을 참고하세요. Prometheus와 Grafana가 이미 실행 중이라면 다음 스크레이프 대상을 추가하고 대시보드를 가져오세요.

• RTCD 지표: http://YOUR_RTCD_SERVER:8045/metrics
• Calls 플러그인 지표: http://YOUR_MATTERMOST_SERVER:8067/plugins/com.mattermost.calls/metrics
• Grafana 대시보드: 대시보드 ID 23225를 가져옵니다

전체 설정 내용은 Calls 지표와 모니터링을 참고하세요.

2B.5 검증 항목

이제 테스트 계정으로 RTCD 배포를 스모크 테스트합니다.

• calls-test 같은 테스트 채널을 만듭니다.
• Channel menu를 열고 Enable calls를 선택합니다.
• 실제 통화를 검증할 수 있도록 테스트 사용자를 채널에 초대합니다.

이 점검이 실패한다면 먼저 다음 문제 해결 방법을 시도해 보세요.

• 2B.2.1과 2B.2.2 점검을 다시 실행해 RTCD가 수신 대기 중이고 응답하는지 확인합니다.
• RTCD Service URL이 올바른지, RTCD 설정에 자격 증명이 필요하다면 그것이 포함되어 있는지 확인합니다.
• 다른 설정을 변경하기 전에, Mattermost 서버가 포트 8045로 RTCD에 도달할 수 있는지 확인하고 RTCD 로그를 검토합니다.

3단계: 녹화 설치와 설정

이제 통화 녹화, 전사, 실시간 자막을 처리하는 calls-offloader 잡 서비스를 설치하고 설정합니다.

녹화, 전사, 실시간 자막이 필요하지 않다면 이 페이즈를 건너뛰어도 됩니다.

3.1 사전 요구 사항

• ☐ calls-offloader 서버를 프로비저닝했고(1.4) 관련 네트워킹 점검을 통과했습니다(1.6.6~1.6.9)
• ☐ Integrated 모드를 사용한다면 2A 페이즈 검증 항목을 통과했습니다(2A.3.1~2A.3.4).
• ☐ RTCD를 사용한다면 2B 페이즈 검증 항목을 통과했습니다(2B.5.1~2B.5.4).
• ☐ 서버에 Mattermost Enterprise 또는 Enterprise Advanced 라이선스가 활성화되어 있습니다
• ☐ Mattermost 서버의 시스템 관리자 권한이 있습니다

3.2 calls-offloader 설치

설치는 Calls Offloader 설정과 구성 가이드를 따르세요. 이 가이드는 다음을 다룹니다.

• 바이너리 설치
• config.toml 설정
• systemd 서비스 설정
• Docker 기반 잡
• 사설 네트워크 재정의
• 에어갭 설치

계속 진행하기 전에 Mattermost 서버에서 다음 점검을 실행해 calls-offloader가 실행 중이고 접근 가능한지 확인하세요.

3.3 calls-offloader를 Mattermost에 연결

1. System Console > Plugins > Calls > Settings로 이동합니다.
2. Job Service URL을 calls-offloader 주소로 설정합니다. 신뢰할 수 있는 내부 네트워크라면 예를 들어 http://calls-offloader.internal:4545와 같이 지정합니다.
3. 필요하다면 Call Recordings를 활성화합니다.
4. 필요하다면 Call Transcriptions를 활성화합니다. 전사를 사용하려면 녹화가 활성화되어 있어야 합니다.
5. 필요하다면 Live Captions를 활성화합니다. 실시간 자막을 사용하려면 녹화와 전사가 모두 활성화되어 있어야 합니다.
6. Save를 클릭한 뒤 변경 사항이 적용되도록 Calls 플러그인을 재시작합니다.

3.4 검증 항목

이제 테스트 계정으로 녹화 관련 기능을 스모크 테스트합니다.

녹화 관련 점검이 실패한다면 다시 시도하기 전에 문제를 분리하세요.

• 3.4.1 또는 3.4.2 실패: Job Service URL이 올바른지, calls-offloader 서비스가 실행 중인지, Mattermost 서버가 포트 4545에 도달할 수 있는지 확인하세요.
• 3.4.3 실패: 먼저 녹화가 활성화되어 있는지 확인한 다음 전사가 활성화되어 있는지 확인하세요.
• 3.4.4 실패: 실시간 자막을 테스트하기 전에 녹화와 전사가 모두 활성화되어 있는지 확인하세요.

4단계: 파일럿 롤아웃

기술적인 설정을 마치고 검증했다면, 광범위한 롤아웃에 앞서 실제 사용자와 함께 소규모 파일럿을 진행합니다. 목표는 조직에서 사용하는 클라이언트와 위치 전반에서 Calls가 안정적으로 동작하는지, 그리고 일반적인 사용 부하에서 서버가 정상 상태를 유지하는지 확인하는 것입니다.

4.1 사전 요구 사항

• ☐ Integrated 모드를 사용한다면 2A 페이즈 검증 항목을 통과했습니다(2A.3.1~2A.3.4)
• ☐ RTCD를 사용한다면 2B 페이즈 검증 항목을 통과했습니다(2B.5.1~2B.5.4)
• ☐ 녹화를 사용한다면 3단계 검증 항목을 통과했습니다(3.4.1~3.4.4)
• ☐ 서로 다른 위치의 자원 파일럿 사용자 5~10명이 있습니다
• ☐ Calls 인프라의 지표 대시보드와 로그에 접근할 수 있습니다
• ☐ 파일럿 사용자가 최신 Mattermost 데스크톱·모바일 앱을 사용하고 있습니다

4.2 준비와 공지

파일럿을 성공적으로 진행하려면 파일럿 사용자가 무엇을 테스트해야 하는지, 통화를 어떻게 시작하는지, 문제를 어떻게 보고하는지 알고 있어야 합니다.

파일럿 사용자를 calls-test 채널에 초대한 뒤, 모두가 같은 항목을 테스트하도록 짧은 메시지를 게시하세요. 아래에 템플릿을 제공합니다.

## Mattermost Calls 파일럿

더 넓은 롤아웃에 앞서 Mattermost Calls를 테스트해 주시기로 해 주셔서 감사합니다. 3~5일간의 파일럿 테스트가 끝나면 모든 분께 확인하신 내용과 경험을 공유해 달라고 요청드릴 예정입니다. 나중에 정리해 주실 수 있도록 문제나 의견을 기록해 두세요.

**시작 방법**

파일럿 테스트를 위해 이 채널에서 Calls가 활성화되어 있습니다. 채널 헤더에서 **Start call**을 선택해 시작하거나, 이미 진행 중인 통화가 있다면 참여할 수 있습니다.

Mattermost Calls에 관한 자세한 내용은 [문서](https://docs.mattermost.com/end-user-guide/collaborate/make-calls.html)에서 확인하세요.

**테스트 케이스**

| 테스트 | 동작 | 통과 기준 | 클라이언트 유형 |
|---|---|---|---|
| T1 | 참가자 3~5명이 참여하는 그룹 통화 | 모든 참가자가 서로의 음성을 또렷하게 들을 수 있음 | 웹, 데스크톱, 모바일 |
| T2 | 15분 이상 지속되는 그룹 통화 | 예기치 않은 끊김이나 음질 저하가 없음 | 웹, 데스크톱, 모바일 |
| T3 | 본사 네트워크 외부에서 통화에 참여 | 해당 네트워크에서 통화 품질이 수용 가능함 | 웹, 데스크톱, 모바일 |
| T4 | 통화 중 화면 공유 | 화면 공유가 동작하고 모든 참가자에게 보임 | 데스크톱, 웹 |
| T5 | 녹화가 활성화되어 있다면 그룹 통화를 녹화 | 처리가 완료되면 통화 스레드에 MP4와 전사 파일이 나타남 | 웹, 데스크톱, 모바일 |
| T6 | 자막이 활성화되어 있다면 그룹 통화 중 실시간 자막을 켬 | 참가자가 말한 뒤 1~3초 이내에 통화 중 자막이 나타남 | 웹, 데스크톱 |

**문제 보고**

문제가 발생하면 이 채널에 다음 내용을 포함해 게시하여 보고해 주세요.

- 테스트 번호
- 재현 절차
- 예상했던 동작
- 실제로 일어난 일(스크린샷 포함)
- 사용 중인 클라이언트 유형(데스크톱, 브라우저, 모바일)

4.3 검증 항목

모니터링

프로덕션 준비 상태

영업일 기준 3~5일 후 파일럿 사용자로부터 의견을 수집해 프로덕션 준비 상태를 평가하세요.

파일럿 사용자가 문제를 발견했다면 아직 롤아웃을 확대하지 마세요.

• 가능한 한 좁은 범위에서 문제를 수정합니다.
• 영향을 받은 파일럿 테스트 케이스를 다시 수행합니다.
• 실패했던 시나리오가 일관되게 통과할 때까지 파일럿 단계에 머무릅니다.

테스트가 실패한 뒤 Mattermost 메시지 입력창에서 /call stats를 실행하면 추가 진단 단서를 얻을 수도 있습니다.

5단계: 프로덕션 롤아웃

이제 프로덕션에서 전체 사용자를 대상으로 롤아웃을 진행합니다.

5.1 사전 요구 사항

• ☐ 4단계 프로덕션 준비 상태 점검을 통과했습니다(4.3.1~4.3.7)
• ☐ 롤백 계획이 문서화되어 있고 관계자가 이를 이해하고 있습니다
• ☐ Mattermost 서버의 시스템 관리자 권한이 있습니다
• ☐ Calls 인프라의 지표 대시보드와 로그에 접근할 수 있습니다

5.2 롤백 계획

단계적 프로덕션 롤아웃을 시작하기 전에 롤백 선택지를 숙지해 두어야 합니다. 문제가 발생하면 그 문제를 해결하는 가장 작은 범위의 롤백을 선택하세요.

채널 단위 롤백

특정 채널에서 Calls를 비활성화합니다.

1. 영향을 받은 채널로 이동합니다.
2. Channel menu를 선택한 다음 Disable calls를 선택합니다.

테스트 모드 롤백

시스템 관리자가 활성화한 채널로만 Calls를 제한합니다.

1. System Console > Plugins > Calls > Settings로 이동합니다.
2. Test Mode를 on으로 설정합니다.

전체 롤백

모든 사용자에 대해 Calls를 완전히 비활성화합니다.

1. System Console > Plugins > Plugin Management로 이동합니다.
2. Calls 플러그인을 Disable합니다.

기존에 사용하던 콘퍼런스 도구가 있다면 Calls가 프로덕션에서 안정될 때까지 함께 유지하세요.

5.3 준비와 공지

사용자에게 Calls를 공지하기 전에 calls-support 공개 채널을 만드세요. 이렇게 하면 사용자가 문제를 보고할 명확한 창구가 생기고, 관리자도 롤아웃 문제를 한곳에서 추적할 수 있습니다.

전사 채널처럼 눈에 잘 띄는 위치에 공유할 짧은 공지도 준비하세요. 아래에 템플릿을 제공합니다.

## Mattermost Calls 롤아웃

이 서버 전반에 Mattermost Calls를 활성화합니다. 오늘부터 별도 도구로 전환할 필요 없이 Mattermost 안에서 바로 일부 채널에서 음성 통화를 시작할 수 있습니다.

전체로 확대하기에 앞서 일부 채널부터 시작해 점진적으로 롤아웃할 예정입니다.

**Calls 기능**

- 1:1 및 그룹 음성 통화 시작 또는 참여
- 데스크톱 앱이나 브라우저에서 화면 공유
- 활성화된 경우 통화 녹화 및 전사본 생성
- 활성화된 경우 녹화되는 통화에서 실시간 자막 사용

Mattermost Calls에 관한 자세한 내용은 [문서](https://docs.mattermost.com/end-user-guide/collaborate/make-calls.html)에서 확인하세요.

**통화 시작 방법**

채널 헤더에서 **Start call**을 선택하세요. 채널에 있는 누구나 참여할 수 있습니다.

**알아 두면 좋은 점**

- [데스크톱 및 모바일 앱](https://mattermost.com/apps/)을 최신 버전으로 업데이트하시기를 권장합니다
- 통화에 처음 참여할 때 브라우저나 데스크톱 앱이 마이크 권한을 요청할 수 있습니다.
- 화면 공유 시에도 화면 캡처 권한 요청이 나타날 수 있습니다.

**도움이 필요하신가요?**

`~calls-support`에 게시하시고, 무엇을 하려고 했는지, 어떤 일이 일어났는지, 가능하다면 스크린샷도 함께 포함해 주세요.

5.4 롤아웃 단계

한 번에 모든 곳에 활성화하기보다는 단계적으로 Calls를 활성화하기를 권장합니다. 이렇게 하면 실제 사용 상황을 관찰하고, 문제를 조기에 발견하며, 필요할 때 깔끔하게 롤백할 수 있습니다.

어떤 롤아웃 단계에서 문제가 발생하면 롤아웃을 중단하고, 해당 단계에 명시된 롤백 방식을 사용해 문제를 수정한 뒤, 다음 단계로 넘어가기 전에 같은 단계를 다시 수행하세요.

5.5 모니터링과 최적화

Calls가 서비스에 투입되면 처음 2주 동안은 적극적으로 모니터링하면서 관찰 결과에 따라 조정하세요.

5.5.1: 통화가 몰리는 시간대에 서버 상태 관찰

사용량이 많은 시간대에 미디어 서버(RTCD 또는 Mattermost 서버)의 CPU와 메모리를 매일 모니터링하세요. CPU 사용률이 지속적으로 70%를 넘는다면 다음 롤아웃 단계 전에 하드웨어 사양을 높이거나 RTCD 노드를 추가하는 것을 고려하세요.

5.5.2: 로그 매일 검토

Mattermost, RTCD, calls-offloader 로그를 매일 확인해 반복되는 ERROR나 WARN 항목이 있는지 살펴보세요. 사용자에게 드러나는 문제로 번지기 전에 패턴을 해결하세요.

5.5.3: Max Call Participants 조정

대규모 통화에서 리소스 부담이 관찰된다면 System Console > Plugins > Calls에서 Max Call Participants 값을 낮추세요. 기본적으로는 참가자 제한이 없습니다(0으로 설정되어 있으며 무제한을 의미합니다). 대부분의 배포에서 현실적인 상한선은 50입니다.

5.5.4: 사용자 보고 문제 추적

~calls-support에서 반복되는 불만 사항을 모니터링하세요.

자주 발생하는 문제와 해결 방법은 부록 A: 문제 해결을 확인하세요.

부록 A: 문제 해결

A.1 통화 버튼이 보이지 않음

A.2 통화는 시작되지만 오디오가 동작하지 않음

A.3 원격 사용자가 네트워크 외부에서 참여할 수 없음

A.4 녹화, 전사, 자막이 실패함