사용 가능 플랜: Entry, Professional, Enterprise, Enterprise Advanced

Mattermost 워크스페이스를 구성하는 올바른 방법은 하나가 아닙니다. 적합한 구조는 조직의 규모, 보안 요구 사항, 사람들이 함께 일하는 방식에 따라 달라집니다. 이 가이드는 권장 시작점과 그 이면의 장단점을 제시합니다.

워크스페이스 구성은 세 가지 결정으로 요약됩니다.

1. 팀을 몇 개 만들고 각 팀이 무엇을 나타내는지.
2. 해당 팀 안에서 채널의 이름을 어떻게 짓고 어떻게 그룹화하는지.
3. 팀과 채널을 만들고 관리할 수 있는 사람이 누구인지.

이러한 결정은 서로 영향을 줍니다. 사람들이 실제로 일하는 방식과 일치하는 팀 구조는 채널 구성을 더 쉽게 만들고, 권한 모델은 그 구조가 만들려는 보안 경계를 강제하는 수단이 됩니다.

팀 구조 선택#

팀은 Mattermost에서 조직의 최상위 단위를 이룹니다. 팀은 누가 함께 협업하는지, 어떤 정보에 접근할 수 있는지를 정의하며, 이를 통해 배포 전반에서 데이터 주권, 컴플라이언스, 운영 명확성을 유지합니다.

각 팀은 자체 구성원, 채널, 권한, 연동을 갖춘 독립적인 워크스페이스입니다. 이러한 분리는 협업이 드물거나 데이터 민감도 또는 접근 제어 수준이 서로 다른 그룹 사이에 명확한 경계를 만듭니다. 팀을 안전한 협업 구역으로 생각하세요. 사람들이 업무와 관련된 정보를 자유롭게 공유할 수 있는 격리된 환경입니다.

가장 유용한 질문은 팀을 어떻게 구성할지가 아니라 실제로 몇 개가 필요한지입니다. 답은 대개 예상보다 적습니다. 데이터를 공유하지 않아야 하거나 함께 일하는 경우가 드문 집단을 구분하는 데 팀을 사용하세요.

단일 팀#

단일 보안 경계 아래에 있고 그룹을 서로 격리할 필요가 없는 사용자 약 2,000명 미만의 조직에 가장 적합합니다. 모든 사람이 하나의 워크스페이스를 공유합니다. 채널, 카테고리, 이름 지정 규칙이 모든 구조를 담당합니다. 이 모델은 관리하기가 가장 쉽고 조직 전반에서 사람들에게 가장 넓은 가시성을 제공합니다.

단일 팀이라도 누가 무엇을 볼지 제어할 수 있습니다. 비공개 채널은 구성원을 제한하며, 접근 제어 정책은 워크스페이스를 별도 팀으로 나누지 않고도 사용자 속성에 따라 채널 접근을 제한할 수 있습니다.

다음과 같은 경우 단일 팀을 사용하세요:

• 조직이 통합된 디렉터리(IdP 하나, LDAP/SAML 소스 하나)를 사용하는 경우.
• 모든 사용자가 동일한 분류 수준 또는 민감도 등급에서 일하는 경우.
• 조직 전반에서 최대한의 가시성과 검색 가능성을 원하는 경우.
• 사용자 수가 하나의 채널 목록 안에서 관리 가능한 수준으로 유지되는 경우.

다음과 같은 경우 단일 팀을 피하세요:

• 특정 그룹이 다른 채널이나 사용자의 존재조차 보지 못하게 해야 하는 경우.
• 내부 워크스페이스와 섞이면 안 되는 자회사, 파트너 조직 또는 외부 사용자가 있는 경우.
• 조직 전체의 알림 양이 개별 사용자에게 과도한 부담이 되는 경우.

보안 경계별 다중 팀#

분류 수준, 역할 또는 데이터 민감도에 따라 서로 다른 집단을 분리해야 하는 조직에 가장 적합하며, 이는 조직의 명확성뿐 아니라 보안 통제 수단이기도 합니다. 별도 팀에 속한 집단은 공개 채널을 포함해 서로의 채널을 볼 수 없습니다. 예를 들어 레드 팀과 블루 팀은 서로 완전히 숨겨진 상태를 유지합니다. 한쪽에는 계획된 공격 방법이, 다른 쪽에는 탐지 규칙과 알림 임계값이 있습니다.

이 경계는 채널에 그치지 않습니다. 웹훅과 슬래시 명령어 같은 연동은 팀 안에서 만들어지며 해당 팀 범위에 머물고, 팀 재정의 스킴를 사용하면 각 집단이 자신의 컴플라이언스 의무에 맞는 권한 집합으로 운영될 수 있습니다.

사람들이 자신의 팀 밖에 있는 사용자를 발견하지 못하게 하려면 다음을 모두 수행하세요.

1. System Console > Site Configuration > Users and Teams 에서 사용자가 다이렉트 메시지 채널을 열 수 있는 대상을 팀의 모든 구성원 으로 설정합니다. 이렇게 하면 다이렉트 메시지 메뉴와 채널 찾기가 현재 보고 있는 팀의 사용자로 제한됩니다.
2. 각 보안 경계 팀을 비공개 팀으로 설정하여, 아직 구성원이 아닌 사용자가 팀을 찾거나 가입할 수 없게 합니다.

다음과 같은 경우 보안 경계별 다중 팀을 사용하세요:

• 조직이 여러 분류 수준(예: FOUO, CUI 또는 기밀)에서 운영되는 경우.
• 별도로 구획된 프로그램 사무소처럼 두 집단이 서로 보이지 않아야 하는 경우.
• 발표 전에 인수 실사를 진행하는 딜 팀처럼, 규제상의 이유로 소규모 그룹을 조직의 나머지와 차단해야 하는 경우.
• 컴플라이언스 체계가 협업 계층에서 입증 가능한 접근 분리를 요구하는 경우.

이 패턴을 속성 기반 접근 제어와 함께 사용하면 아이덴티티 공급자 속성으로 팀 및 채널 구성원 관리를 자동화할 수 있습니다.

사업 부문별 다중 팀#

독립적으로 운영되지만 하나의 Mattermost 서버를 공유하는 뚜렷한 사업 부문, 그룹 회사 또는 자회사가 있는 대규모 조직에 가장 적합합니다. 주요 부문마다 자체 팀을 갖습니다. 공지 채널이 있는 조직 전체 팀은 선택 사항입니다. 각 팀 안에서 사람들은 채널과 카테고리를 사용해 프로젝트와 기능별로 정리합니다. 일반적인 예로는 자회사마다 팀이 있는 금융 서비스 회사, 그룹 회사가 인프라를 공유하지만 독립적으로 운영되는 대기업 집단이 있습니다.

다음과 같은 경우 사업 부문별 다중 팀을 사용하세요:

• 조직의 각 부분이 의미 있게 다른 채널 구조와 정책을 필요로 하는 경우.
• 자신의 부문만 볼 수 있으면 되는 사람들의 사이드바 노이즈를 줄이려는 경우.
• 성능이 우려되는 경우 — 여러 팀은 데이터베이스 쿼리 부하를 분산합니다.

주의할 점:

• 팀 난립. 채널을 사용하는 대신 모든 프로젝트나 하위 그룹마다 팀을 만들면 팀 수준에서 난립 문제가 되풀이됩니다. 새 팀이 필요한 경우와 새 채널이 필요한 경우를 구분하는 정책을 정하세요.
• 팀 간 협업 공백. 별도 팀의 사용자는 채널을 공유할 수 없습니다. 부문 간 프로젝트에는 두 집단이 모두 가입할 수 있는 공유 팀을 사용하세요.

외부 접근을 위한 다중 팀#

내부 워크스페이스에 대한 전체 접근 권한이 없어야 하는 계약자, 파트너, 고객 또는 연합 파트너와 정기적으로 협업하는 조직에 가장 적합합니다. 한 가지 방법은 외부 협업 전용 팀(또는 여러 팀)을 두는 것입니다. 내부 사용자는 내부용 팀과 외부 대면 팀에 모두 속할 수 있습니다.

별도 팀을 만들지 않는 두 가지 대안이 있습니다.

• 게스트 계정은 외부 사용자를 초대받은 특정 채널과 팀으로 제한합니다. 게스트는 채널 디렉터리를 둘러보거나 스스로 채널에 가입할 수 없습니다. 게스트 계정은 외부 협업자가 직접 Mattermost를 운영하지 않고 협업 범위가 제한적일 때 적합합니다.
• 연결된 워크스페이스를 사용하면 두 조직 중 어느 쪽도 내부 워크스페이스를 노출하지 않고 별도의 Mattermost 서버에 있는 사용자가 채널을 공유할 수 있습니다. 파트너도 Mattermost를 운영하거나 컴플라이언스 체계상 외부 사용자를 내 서버에 프로비저닝해서는 안 되는 경우에 선호되는 모델입니다.

채널 분류 체계 수립#

각 팀 안에서 채널이 조직 구조를 담당합니다. 정의된 채널 유형, 이름 지정 규칙, 사이드바 카테고리 집합으로 이루어진 일관된 분류 체계는 사람들이 별도 교육 없이 대규모 워크스페이스를 탐색할 수 있게 합니다.

채널 이름 지정 규칙#

일관된 채널 이름은 분류 체계를 대규모에서도 탐색 가능하게 만듭니다. 길이 제한과 허용 문자처럼 모든 이름에 적용되는 제품 규칙은 채널 만들기를 참조하세요.

좋은 이름 지정은 팀이 상당한 혼란 없이 수천 개의 채널까지 운영할 수 있게 합니다. 모든 조직은 결국 한계에 도달하며 그때는 팀을 추가하는 것이 더 나은 답이지만, 명확하고 짧은 이름은 그 시점을 상당히 늦춥니다.

넓게 시작하여 좁혀 가기#

광범위하게 정의된 채널로 시작하여 토론이 진행됨에 따라 나누는 것이 자연스럽습니다. 하나의 "Marketing" 채널이 "Marketing-Website", "Marketing-Social-Media", "Marketing-General"로 나뉠 수 있습니다. 조직이 성장하면 분야가 사업 부문, 제품, 지역에 걸쳐 분리되어 "US-Marketing", "UK-Marketing" 같은 이름이 생깁니다.

계층 구조는 [SUB-TEAM]-[TOPIC]-[SUB-TOPIC] 같은 형식으로 결합되어 US-Mrkt-Website, UK-Mrkt-Social-Media 같은 이름이 됩니다.

모음, 어미, 중복되는 글자 소리를 제거하여 단어, 특히 카테고리 이름을 줄입니다. "Marketing"은 "Mrkt"가 되고 "Project"는 "Prjt"가 됩니다. 국가에는 표준 2자리 국가 코드를 사용하세요.

공통 접두사로 관련 채널 그룹화#

함께 속한 채널은 ops-, proj-, inc-, social- 같은 접두사를 공유해야 합니다. 공유 접두사는 검색 결과와 채널 찾기에서 관련 채널을 묶어 주므로, 접두사를 입력하면 전체 집합이 나타납니다.

신규 사용자와 외부 협업자가 접하는 채널에는 약어보다 설명적인 이름을 사용하세요. 약어는 체계를 아는 사람에게는 효율적이지만 그전에는 알아보기 어렵습니다. 약어는 표준적이고 문서화된 규칙에만 사용하세요.

이모지를 이름 접두사로 사용#

이모지 접두사는 긴 채널 목록을 훑어보기 쉽게 만드는 가벼운 방법이며, 텍스트 접두사를 대체하지 않고 함께 사용됩니다. 한 카테고리의 모든 채널에 같은 이모지를 사용하면 그 그룹이 시각적으로 강화되어, 사람들이 사이드바 전체를 읽지 않고도 한눈에 필요한 채널을 찾을 수 있습니다.

대규모 워크스페이스와 온보딩 중에 효과가 가장 큽니다. 신규 구성원은 서면 설명 없이도 접두사로 채널의 용도를 유추하므로, 워크스페이스가 어떻게 구성되어 있는지 가르치는 데 드는 시간이 줄어듭니다.

이모지를 삽입하는 단계는 채널 이름에 이모지 추가를 참조하세요.

일반적인 채널 패턴#

대부분의 워크스페이스는 결국 다음의 일부를 조합하게 됩니다.

• 주제 채널 은 이메일이나 문서의 폴더와 매우 비슷하게 광범위한 주제 영역을 정리합니다. 예시: Recruiting, Interviews, Legal-Reviews, Documentation. 채널 수가 늘어남에 따라 관련 주제가 함께 정렬되도록 주제 이름을 계층 구조로 지정하세요: Legal-Trademarks, Legal-Contracts, Legal-Licensing.
• 공지 채널 은 경영진 또는 운영팀의 공지를 전달합니다. 읽기 전용으로 만들어 게시 권한을 관리자나 지정된 역할로 제한하면, 사람들이 답글로 인한 노이즈 없이 정보를 받습니다. 예시: Town-Square, Announcements, Security-Advisories.
• 회의 채널 은 구성원이 회의 시간 전에 안건 항목을 게시하는 정기 회의를 정리합니다. 예시: Monday-Sales-Update, All-Hands-Meeting. Markdown 서식을 사용하여 안건 항목에 번호를 매기고, 회의 전후에 각 항목을 별도의 스레드에서 논의하며, 참석자가 채널에서 바로 참여할 수 있도록 채널 헤더에 컨퍼런싱 링크를 유지하세요.
• 하위 팀 채널 은 한 분야, 프로젝트 팀 또는 관리자의 직속 팀원을 모읍니다. 예시: Developers, Marketers, Offsite-Organizing-Committee. 이 채널은 하나의 채널로 감당할 수 없을 만큼 커지면 US-Developers, UK-Developers로 세분화됩니다.
• 프로젝트 채널 은 특정 결과에 한정되며 비공개이고 기간이 정해진 경우가 많습니다. 예시: Logo-Design, Localization, Product-Launch. 세부 작업이 여기에서 이루어지고, 요약은 프로젝트가 시작된 더 큰 채널로 다시 전달됩니다.
• 위치 채널 은 같은 건물, 도시 또는 지역에 있는 사람들이 회의와 모임을 조율하는 데 도움이 됩니다. 예시: Loc-Building-10, Loc-Palo-Alto, Loc-Toronto. 위치별 공지가 다른 모든 사람의 사이드바에 나타나지 않도록 합니다.
• 연동 채널 은 봇, 웹훅, 모니터링 시스템, 티켓 시스템, 뉴스 알림에서 보내는 자동 게시물을 받습니다. 예시: Bugs, Support-Tickets, News-Mentions. 일부 사람들은 이 채널을 일간지처럼 읽고, 다른 사람들은 멘션이나 키워드가 있을 때만 알림을 받도록 설정합니다.

체계적이고 자동화된 이름#

일부 조직, 특히 국방, 운영, 인시던트 대응 분야에서는 임무가 활성화되거나, 인시던트가 선언되거나, 추적 시스템에서 프로젝트가 열리는 등 이벤트가 발생할 때 프로그래밍 방식으로 채널을 만듭니다.

자동 생성에는 [type]-[identifier]-[scope] 같은 일관된 형식으로 이름에 구조화된 메타데이터를 포함하세요.

• ops-msl-2047-eglin: 임무 번호와 위치로 구분되는 임무 채널
• inc-p1-20260819-db-outage: 날짜와 구성 요소로 구분되는 우선순위 1 인시던트
• proj-atlas-q3-frontend: 프로젝트 워크스트림

몇 가지 원칙이 생성된 이름을 오래 유지되게 합니다.

• 목록과 검색 결과에서 채널이 의미 있게 정렬되도록 유형 접두사를 맨 앞에 둡니다.
• 임무 번호나 티켓 ID처럼 기준이 되는 시스템에서 사용하는 식별자를 포함하여 채널이 해당 레코드와 명확하게 대응되도록 합니다.
• 채널을 처음 접하는 사람이 열어 보지 않고도 범위를 이해할 수 있도록 충분한 컨텍스트를 포함합니다.
• 날짜는 의미가 있을 때만 추가합니다. 오래 유지할 채널에는 날짜를 붙이지 않습니다.

사이드바 구성#

채널 이름은 채널이 무엇에 관한 것인지 알려 줍니다. 카테고리는 채널을 어디에서 찾을지 알려 줍니다. 잘 구성된 워크스페이스에서 사이드바는 수십 개의 채널이 나열된 목록이 아니라 네 개에서 여섯 개의 카테고리로 이루어집니다.

일반적인 시작 구조는 다음과 같습니다.

카테고리는 각 사용자에게 개인별로 적용되므로 사람들이 직접 조정할 수 있습니다. 채널 카테고리 정렬이 활성화된 경우 채널 관리자는 채널을 만들 때 기본 카테고리를 설정할 수 있습니다. 그러면 신규 구성원은 사이드바를 직접 구성하지 않아도 정리된 사이드바를 보게 됩니다.

사람들이 카테고리를 일상적으로 관리하는 방법은 채널 사이드바 사용자 지정을 참조하세요.

알림 부하 관리#

구조는 알림 양에도 영향을 줍니다. 10개 팀에 걸쳐 50개의 활성 채널에 속한 사람은 채널마다 설정하지 않으면 모든 채널의 알림을 받으며, 대부분의 사람은 그렇게 설정하지 않습니다. 그 결과 모든 것을 음소거하고, 중요한 내용을 놓치며, 참여도가 떨어집니다.

이름 지정과 구조 결정으로 설계 단계에서 이러한 부하를 줄일 수 있습니다.

• 봇 피드와 CI 알림처럼 양이 많고 긴급하지 않은 채널을 하나의 카테고리로 묶고 해당 카테고리를 멘션 전용으로 설정합니다. 전체 알림을 원하는 사람은 직접 선택합니다.
• 공지에는 읽기 전용 공지 채널을 사용하여 답글이 이어지지 않고 메시지만 전달되게 합니다.
• 하위 대화에는 새 채널보다 스레드를 사용합니다. 활발한 스레드가 있는 채널 하나가, 각각 별도의 알림 스트림을 가진 단기 채널 여러 개보다 따라가기 쉽습니다.
• 새 팀과 새 채널 중 무엇을 선택할지 결정할 때 알림 비용을 고려합니다. 사람이 가입하는 팀마다 알림 범위가 넓어지지만, 이미 속한 팀의 채널은 훨씬 적게 늘립니다.

사람들이 직접 제어하는 채널별 설정은 채널 알림 환경설정을 참조하세요.

규칙 문서화#

이름 지정 및 구성 가이드를 Town Square의 고정 메시지나 사내 핸드북처럼 사람들이 찾을 수 있는 곳에 게시하세요. 규칙을 이해하는 사람들은 스스로 정리합니다. 이해하지 못하는 사람들은 체계를 깨뜨리는 채널을 만듭니다.

권한 적용#

권한은 구조를 관례에서 서버가 강제하는 경계로 바꿉니다. 여기에는 팀과 채널을 만들 수 있는 사용자도 포함되며, 이름 지정 규칙은 생성이 관리될 때만 유지됩니다.

엔터프라이즈 배포의 시작점은 다음과 같습니다.

• 팀 생성: 시스템 관리자만. 팀 생성은 신중한 승인이 필요한 구조적 결정입니다.
• 공개 채널 생성: 팀 관리자. 시스템 관리자로 제한하면 병목이 생기고, 모든 사람에게 열어 두면 난립을 초래합니다.
• 비공개 채널 생성: 모든 구성원. 비공개 채널은 다른 사람에게 보이지 않으며 스스로 제한되는 경향이 있습니다.
• 채널 삭제 및 보관: 채널 관리자와 시스템 관리자.

System Console > User Management > Permissions 에서 이를 설정하세요. 전체 권한 모델과 실제 예시는 고급 권한을 참조하세요.

대부분의 조직은 다음 채널 생성 모델 중 하나를 선택합니다.

팀 관리자 생성은 사람들이 시스템 관리자를 기다리지 않으면서 이름 지정 표준을 유지할 수 있어 엔터프라이즈 배포에서 가장 일반적인 선택입니다. 이를 설정하려면 모든 구성원의 채널 만들기 를 끄고 팀 관리자에게는 켜 두세요. 특정 팀에서 채널을 만들 수 있는 사용자 제한을 참조하세요.

Mattermost는 채널 요청 워크플로를 제공하지 않습니다. 많은 조직은 양식, 티켓 시스템 또는 사람들이 이미 사용하는 다른 접수 절차로 요청을 처리한 다음 관리자가 채널을 만듭니다. 플러그인 프레임워크와 채널 생성 API를 사용하여 승인을 자동화할 수도 있으며, 이 경우 승인된 요청이 관리자의 수작업 없이 올바른 이름의 채널을 생성합니다.

대규모 배포에서는 속성 기반 접근 제어가 팀 및 채널 구성원 관리를 아이덴티티 공급자의 속성에 연결합니다. 사람들이 합류하면 올바른 팀에 추가되고, 속성이 바뀌면 접근 권한을 잃습니다. 이를 사용하지 않으면 많은 팀에서 구성원을 올바르게 유지하는 일이 상당한 관리 부담이 됩니다.

확장에 따른 반복 개선#

워크스페이스 구성은 한 번으로 끝나는 결정이 아닙니다. 다음 중 하나가 보이면 구성을 검토하세요.

• 팀 또는 채널 수가 급격히 증가했습니다. 마지막 검토 이후 둘 중 하나라도 두 배 넘게 늘었다면 난립 여부를 점검하고, 비활성 항목을 보관하며, 생성 권한이 여전히 적절한지 확인하세요.
• 사람들이 채널을 찾을 수 없다고 보고합니다. 이름 지정 규칙이 작동하지 않거나 지켜지지 않고 있습니다.
• 알림 관련 불만이 늘어납니다. 보통 카테고리를 사용하지 않거나, 양이 많은 연동 채널을 음소거하지 않았거나, 팀 구조가 알림 스트림을 중복시키고 있다는 신호입니다.
• 보안 요구 사항이 다른 새로운 집단이 합류합니다. 새 자회사, 파트너 조직 또는 분류 수준이 구조 검토의 가장 흔한 계기입니다.
• 속성 기반 접근 제어를 도입하거나 아이덴티티 공급자를 변경합니다. 아이덴티티 인프라의 변경은 이전에 수동이던 구성원 관리를 자동화할 기회입니다.