Zulip에서 메신저 기능을 쓸 때 공식 문서에 적힌 설정·요금제·한계는 무엇인가?

Zulip의 메신저 기능 중 공식 문서로 확인된 항목은 25개이며, 나머지는 「확인된 바 없음」으로 남는다. 이 글은 Zulip 한 서비스만 깊이 읽는 글이라서, 대화 기록 보관, 시스템 알림 연동, 쓰던 메신저에서 옮겨 오기라는 세 가지 질문에 걸린 조건을 공식 문서 문장 단위로 나누어 적는다. Zulip 공식 문서에 있는 문장은 출처와 함께 옮기고, 문서에서 보이지 않은 부분은 기능이 없다는 주장 대신 「공식 문서에서 확인하지 못함」이라고만 적는다.

누구를 위한 글인가

이미 Zulip을 쓰고 있거나, 메신저를 바꾸는 중에 Zulip을 후보로 올려 둔 팀장을 위한 글이다. 팀장은 도구를 직접 만드는 사람은 아니지만 팀이 쓰는 대화 도구의 규칙을 정하고, 담당자에게 무엇을 확인해 달라고 해야 하는지 알아야 하는 자리에 있다. 이어지는 A·B·C 세 장면은 Zulip을 쓴 실제 고객 사례가 아니며, 팀장이 던질 법한 질문의 모양을 보이려고 꾸민 「예시 상황」이다.

예시 상황 A. 몇 달 전에 오간 협의 내용을 찾아야 하는데 어디에 남아 있는지 모르는 팀. 분쟁이나 인수인계 때 옛 대화가 없어서 곤란했던 일이 계기가 되어, 보관 정책을 정하고 검색과 내보내기가 되는지 확인하려 한다.

예시 상황 B. 주문, 장애, 결제 알림이 메일로만 오다가 묻혀 대응이 늦어진 팀. 알림을 채팅 채널로 받으려면 외부 시스템이 채널에 메시지를 보낼 길이 있어야 하고, 직접 연동을 만들 일이 생기면 개발자 문서가 있어야 한다.

예시 상황 C. 쓰던 메신저를 바꾸기로 결정하고 대화 기록과 구성원 정보를 새 서비스로 옮겨야 하는 팀. 출발 서비스가 무엇인지에 따라 공식 이전 안내가 있는지가 갈린다.

세 상황은 서로 이어지기도 한다. 옛 대화를 찾으려는 팀은 대개 대화가 어디에 쌓이는지, 얼마나 오래 남는지, 필요하면 밖으로 꺼낼 수 있는지를 한꺼번에 묻고, 메신저를 바꾸려는 팀은 같은 질문을 떠나는 서비스와 들어오는 서비스 양쪽에 던진다. 이런 겹침 때문에 Zulip 문서 하나를 세 질문에 나란히 대 보았고, 칸마다 근거 문장과 확인 날짜를 따로 달아 두었다.

팀 크기나 근무 형태별 구분은 두지 않았다. 인원이 늘면 계정 연동이나 권한 관리처럼 다시 볼 조건이 생기는데, 그 부분은 뒤의 「상황별로 확인할 조건」에서 질문으로만 적는다.

기능 한눈에

아래 표는 세 인텐트가 요구하는 조건을 Zulip 공식 문서에서 어떻게 확인했는지 정리한 것이다. 줄 순서에는 뜻이 없다.

대화 내보내기는 이전 인텐트에서도 선호 조건으로 걸려 있으므로, 같은 근거가 두 상황에서 함께 쓰인다.

설정·관리 순서

공식 문서는 기능 소개, 보안 안내, 요금제, 개발자 문서, 도움말 페이지로 나뉘어 있고, 같은 기능도 페이지마다 표현의 깊이가 다르다. 기능 소개 페이지는 항목 이름을 짧게 올려 두는 성격이고, 도움말 페이지는 절차를 풀어 쓰는 성격이라고 근거 행의 표현에서 읽힌다. 팀장이 담당자에게 확인을 맡길 때는 이 순서로 문서를 열어 보게 하면, 어느 칸이 이름만 적힌 칸이고 어느 칸이 절차까지 적힌 칸인지 구분된다.

근거 행에 적힌 문서 위치만 따라, 공식 문서를 읽는 순서로 적는다. Zulip 근거 행에는 화면 메뉴 이름이나 클릭 순서가 담겨 있지 않아 쓰지 않았다.

1. 보관 정책이 필요하면 보안 안내 페이지에서 전체 단위와 채널 단위로 보관 정책을 둘 수 있다고 적힌 부분을 먼저 읽는다 [출처: https://zulip.com/security/(새 창, 공식 원문)].
2. 검색과 대화 내보내기는 기능 소개 페이지에 각각 메시지 기록 검색, 전체 데이터 내보내기로 올라 있으므로, 같은 페이지에서 두 항목의 표현을 확인한다 [출처: https://zulip.com/features/(새 창, 공식 원문)].
3. 알림 연동은 기능 소개 페이지의 맞춤 웹훅 항목과 API 문서를 함께 본다 [출처: https://zulip.com/api/(새 창, 공식 원문)].
4. 쓰던 메신저가 Slack이라면 Slack 조직을 Zulip으로 가져오는 안내 페이지를 읽는다 [출처: https://zulip.com/help/import-from-slack(새 창, 공식 원문)].
5. 구성원 정보를 자동으로 맞추는 일은 SCIM 도움말 페이지에서 시작한다 [출처: https://zulip.com/help/scim(새 창, 공식 원문)].

요금제에 따라 달라지는 것

Zulip을 정하기 직전에는 요금 얘기가 가장 먼저 나온다. 팀장 입장에서는 무료 요금제로 시작해도 충분한지, 검색 가능한 기록에 한도가 있다면 그것이 언제 걸림돌이 되는지가 예산 보고의 중심 질문이다. 아래는 근거 행에 적힌 범위까지만 옮긴다.

요금제별로 갈리는 내용은 이번 근거에서 많지 않다. 요금제 페이지에는 무료 요금제 항목이 올라 있고, 그 항목에 검색 가능한 대화 기록이 10,000건으로 적혀 있다 [출처: https://zulip.com/plans/(새 창, 공식 원문)]. 같은 근거 행에는 기간 만료가 따로 적히지 않았다는 점이 함께 기록되어 있으며, 만료가 없다는 뜻으로 읽기 전에 요금제 페이지에서 직접 확인해야 한다.

보관 정책이 어느 요금제부터 쓸 수 있는지, 웹훅이나 내보내기에 요금제 제한이 있는지는 근거 행에 적혀 있지 않다. 요금제마다 열리는 기능이 무엇인지는 이 글에서 가리지 않는다. 팀장이 공급사에 물어볼 질문으로 아래에 남긴다.

공식 문서에 적힌 한계

Zulip 근거 행 가운데 요건 미충족(not_met)으로 판정된 것은 없다. 그래도 문장이 좁게 적힌 곳에서는 범위가 그대로 보인다.

• 가져오기 안내 페이지의 제목은 Slack 조직을 Zulip으로 가져오는 것으로, 출발 서비스가 Slack으로 명시되어 있다 [출처: https://zulip.com/help/import-from-slack(새 창, 공식 원문)]. Slack이 아닌 다른 메신저에서 가져오는 방법은 이번 근거 행에 없다.
• 조직도 연동은 기능 소개 페이지에 AD/LDAP와 SCIM 사용자 동기화로 올라 있고 [출처: https://zulip.com/features/(새 창, 공식 원문)], SCIM 도움말 페이지는 SCIM을 표준으로 소개한다 [출처: https://zulip.com/help/scim(새 창, 공식 원문)]. 다만 국내 조직도 솔루션과 맞는지는 이 문서들만으로는 알 수 없다.
• 무료 요금제에서 검색할 수 있는 대화 기록은 10,000건으로 적혀 있어, 오래된 대화를 모두 검색해야 하는 팀에는 한도가 될 수 있다 [출처: https://zulip.com/plans/(새 창, 공식 원문)].

확인된 바 없음 · 조사 중

이 절은 Zulip 문서에서 근거를 얻지 못한 항목과 아직 열어 보지 못한 항목을 따로 구분한다. 「확인된 바 없음」은 Zulip에 그 기능이 없다는 단정이 아니라, 열어 본 공식 문서에서 근거 문장을 건지지 못했다는 메모다. 「조사 중」은 해당 쪽을 열기 전의 상태이므로, 이 둘은 어느 것도 Zulip 도입을 가르는 이유로 삼지 않는다.

세 인텐트가 요구하는 조건은 모두 공식 문서에서 확인되었다. 그래도 다음은 Zulip 공식 문서에서 확인된 바 없음으로 남는다. 이 칸들은 같은 서비스의 다른 상황 글에서 다루는 조건이지만, 팀장이 같이 물을 수 있어서 적는다.

• 전체 구성원 수 상한, 공유 채널, 조직 단위 멘션, 공지 기능은 공식 문서에서 확인하지 못함.
• 통화 참여 인원과 화면 공유는 공식 문서에서 확인하지 못함. 그룹 음성·영상 통화가 기능 소개에 올라 있다는 것만 확인되었다 [출처: https://zulip.com/features/(새 창, 공식 원문)].
• 정보 유출 방지, 관리자 삭제 기능, 퇴사자 계정 처리 절차는 공식 문서에서 확인하지 못함.
• 한국어 화면 지원은 공식 문서에서 한국어가 이름으로 적힌 곳을 확인하지 못함. 번역 기능, 파일 한 개당 크기 제한, 파일 보관 기간, 방해 금지 시간대 예약도 확인하지 못함.

조사 중인 것은 다음과 같다. 아래는 이번 조사에서 Zulip 문서의 해당 쪽을 아직 열지 않았다는 표시이고, 기능이 없다는 표시가 아니다.

• 보관 정책을 설정하는 구체적인 화면과 보관 기간의 선택 범위.
• 웹훅으로 알림을 보낼 때 쓰는 연동 목록과 설정 절차.
• Slack 외 출발 서비스에 대한 가져오기 방법.

상황별로 확인할 조건

표는 팀장이 부딪힐 만한 장면을 왼쪽에 두고, 그때 살필 조건과 Zulip 문서에서의 상태를 오른쪽에 붙였다. 「확인」은 Zulip 공식 문서에 그 항목이 적혀 있다는 표시일 뿐이고, 팀이 바라는 수준을 채운다는 보증이 아니다. 팀에 필요한 기준선은 사내에서 먼저 그어 두고, Zulip 공급사가 주는 답과 견주어 본다.

보관 정책은 보안 안내 페이지에 전체 단위와 채널 단위로 올라 있다 [출처: https://zulip.com/security/(새 창, 공식 원문)]. 관리 작업의 상세 기록은 같은 페이지에 감사 로그로 적혀 있다 [출처: https://zulip.com/security/(새 창, 공식 원문)]. 검색과 내보내기, 웹훅은 기능 소개 페이지 쪽 근거다 [출처: https://zulip.com/features/(새 창, 공식 원문)].

공급사에 물어볼 질문

Zulip 문서의 항목 이름만으로는 어디까지인지 보이지 않는 대목을 물음으로 옮겼다. 돌아온 답변을 메일이나 문서로 간직하면 맡은 사람이 달라져도 같은 근거를 계속 쓸 수 있다.

1. 전체 단위와 채널 단위 보관 정책은 어느 요금제부터 설정할 수 있고, 정책을 바꾸면 이미 쌓인 대화에도 적용되는가?
2. 무료 요금제에서 검색할 수 있는 대화 기록 10,000건을 넘으면 오래된 대화는 어떻게 되는가?
3. 전체 데이터 내보내기는 누가 실행할 수 있으며, 내려받은 데이터를 다른 서비스로 다시 가져올 수 있는 형식인가?
4. 맞춤 웹훅으로 보낼 수 있는 알림의 종류와, 한 채널에 보낼 수 있는 빈도에 제한이 있는가?
5. Slack이 아닌 메신저에서 대화를 가져오는 공식 방법이 따로 있는가, 없다면 어떤 길이 안내되는가?
6. SCIM 연동은 어느 요금제에서 쓸 수 있고, 연동할 수 있는 인증 솔루션의 범위는 어디까지인가?
7. 한국어 화면 지원 계획과 한국어 문서 제공 여부는 어떻게 되는가?

규모·역할에 따라 더 볼 것

• 인원이 늘어 자체 계정 관리 체계가 있다면, 사용자 동기화가 그 체계와 맞는지 다시 물어볼 필요가 있는가?
• 감사나 분쟁 대비가 주된 목적이라면, 보관 정책과 감사 로그가 사내 규정이 요구하는 기간과 범위를 덮는가?
• 담당자가 따로 없는 소규모 팀이라면, 웹훅 연동을 누가 설정하고 유지하는가?
• 팀장이 아닌 대표나 IT 담당자가 결정한다면, 다시 확인할 조건이 개발자 문서 쪽으로 옮겨 가는가?
• 외부 협력사가 같은 대화에 들어와야 한다면, 게스트 계정과 공유 채널 조건을 별도로 확인해야 하는가?

이웃 글

• /products/zulip — Zulip 서비스 쪽 정리
• /guides/chat-history-keep — 대화 기록 보관 조건을 서비스 가로질러 읽는 글
• /guides/chat-import-from-messenger — 쓰던 메신저 대화를 옮길 때 보는 조건

출처 목록

• https://zulip.com/plans/(새 창, 공식 원문)
• https://zulip.com/security/(새 창, 공식 원문)
• https://zulip.com/features/(새 창, 공식 원문)
• https://zulip.com/api/(새 창, 공식 원문)
• https://zulip.com/help/import-from-slack(새 창, 공식 원문)
• https://zulip.com/help/scim(새 창, 공식 원문)