Mac에서 Slack이 대역폭을 그토록 많이 쓰는 이유 (그리고 확인 방법)

메뉴 바를 흘끗 보면 Slack이 입력하지도 않는 동안 2MB/s를 끌어오고 있습니다. 활성 상태 보기는 다른 합계를 가진 네 개의 다른 "Slack Helper" 항목을 보여주는데, 그중 어느 것도 네트워크 모니터에서 보는 것과 합쳐지지 않습니다. Slack 대역폭 사용이 그것이 하는 일에 비해 균형이 맞지 않게 느껴지는 이유를 궁금해한 적이 있다면, 답은 그 아키텍처에 있습니다 — Electron, 웹소켓, 도우미 프로세스, 그리고 사람들이 깨닫는 것보다 더 무거운 기본 A/V 스택.

이는 Slack 비방 글이 아닙니다. Slack은 정말로 유용하고 네트워크를 사용하는 방식은 대부분 말이 됩니다. 하지만 macOS에서 프로세스별 숫자는 혼란스러울 수 있고, 알아둘 만한 몇 가지 설정이 있습니다.

Slack 대역폭 사용이 높게 실행되는 이유(아키텍처적 답)

Mac의 Slack은 Electron 앱입니다. 이는 그것이 내부에 Chromium을 번들링한다는 것을 의미하며, Chrome처럼 작업을 여러 프로세스에 나눕니다.

• Slack — 메인 프로세스, UI, 조정.
• Slack Helper — 유틸리티 렌더러와 백그라운드 작업.
• Slack Helper (GPU) — 합성을 위한 GPU 프로세스.
• Slack Helper (Renderer) — UI를 위한 하나 이상의 렌더러 프로세스.
• Slack Helper (Plugin) — 플러그인 호스트(현재 버전에서는 드뭄).

각 도우미는 자체 PID를 가집니다. 각각이 자체 네트워크 소켓을 가질 수 있습니다. "Mac에서 Slack이 얼마나 대역폭을 사용하는가"를 물을 때, 부모와 모든 도우미에 걸쳐 합산해야 합니다 — 또는 그것을 접어 주는 도구를 사용해야 합니다.

선상에 실제로 무엇이 있는가

대략 기여하는 양의 순서로 몇 가지 트래픽 범주.

1. 웹소켓

Slack은 Slack의 서버에 지속적인 웹소켓을 열어 둡니다. 이는 프레즌스 업데이트, 새 메시지, 입력 표시기, 반응, 파일 업로드 알림, 채널 상태 변경, 핑을 운반합니다. 유휴 상태에서, 웹소켓은 작습니다 — 몇 KB/s — 하지만 UI에서 "즉시"라고 느낄 모든 이벤트는 이 연결을 통한 하나 이상의 프레임입니다.

많은 바쁜 채널이 있다면, 웹소켓만으로 업무 시간 동안 50~150KB/s에 앉을 수 있습니다.

2. HTTP 가져오기

UI 로드, 아바타 이미지, 채널 기록, 검색 결과, 링크 미리보기, 이모지. 이는 짧은 폭발입니다 — 오늘 처음으로 채널을 여는 것은 몇 MB를 가져옵니다. 두 번째로 여는 것은 캐시에 닿습니다.

3. 파일 전송

채널에 30MB 이미지를 끌어다 놓으면 업링크에 깨끗한 급증을 볼 것입니다. Slack은 파일 저장소에 업로드하고, 파일에 대해 채널에 알리기 위해 웹소켓에 핑합니다. 클라이언트는 차례로 다른 사람이 공유하는 파일의 미리보기를 다운로드합니다. 많은 디자인 파일을 공유하는 팀은 미리보기만으로 하루에 수백 MB를 옮길 수 있습니다.

4. 오디오 및 비디오 통화

이것이 큰 것입니다. Slack 허들(오디오만)은 방향당 몇백 Kbps입니다. 비디오 허들은 몇 Mbps입니다. 비디오 위의 화면 공유는 5+ Mbps를 밀 수 있습니다. 비디오를 디코딩하는 참가자 수로 곱하세요.

5. 백그라운드 업데이트와 분석

Slack 자동 업데이트기는 백그라운드에서 실행되며 주기적으로 새 버전을 끌어옵니다. 더불어 텔레메트리 — 기능 사용, 충돌 보고서 — 일일 KB로 측정되며, 대부분 무시할 만합니다.

일반적인 하루의 실제 숫자

약 25개 채널이 있는 Slack을 실행하는 단일 Mac의 숫자, 낮 동안 서너 개 활성, 총 45분의 두 허들:

• 유휴(앱 열림, 상호작용하지 않음): 정상 상태 5~30KB/s. 여러 바쁜 채널과 함께 더 높음.
• 바쁜 채널에 입력: 프레즌스와 읽기 영수증이 흐르면서 50~100KB/s로의 짧은 급증.
• 콜드 채널 열기: 기록 깊이와 아바타 수에 따라 1~5MB.
• 45분 허들(1:1, 비디오 켜짐): 총 ~600~900MB.
• 일반적인 완전한 근무일, 허들 없음, 적당한 활동: 100~300MB.
• 두 비디오 허들이 있는 하루: 쉽게 1~2GB.

이는 대략적인 수치입니다. 팀의 이모지 습관이 생각보다 더 중요합니다.

Mac에서 실제로 보는 방법

세 옵션, 유용성이 증가합니다.

활성 상태 보기

활성 상태 보기 → 네트워크 탭을 엽니다. "보낸 바이트" 또는 "받은 바이트"로 정렬합니다. 부모와 도우미를 별도 행으로, 프로세스 시작 이후 누적 합계와 함께 볼 것입니다. 점검에 유용하고, "Slack이 지금 무엇을 하고 있는가"에 덜 유용합니다.

nettop

터미널에서:

nettop -P -m route

라이브 업데이트 프로세스별 뷰. 같은 문제 — Slack과 그 도우미가 별도 행으로 나타납니다.

도우미 접기가 있는 메뉴 바 모니터

ova는 정확히 이 패턴을 중심으로 만들어졌습니다. 모든 도우미에 걸쳐 결합된 속도가 있는 단일 "Slack" 행, 최근 활동의 스파크라인, 그리고 급증이 언제 일어났는지 볼 수 있는 스크럽 가능한 타임라인을 보여줍니다. "Slack"으로 클릭해 들어가면 원하면 도우미별 세부사항으로 파고들 수 있습니다.

Slack이 실제로 무엇을 사용하는지 보세요

ova는 Slack Helper PID를 상위 앱 아래로 접고 라이브 + 과거 앱별 대역폭을 보여줍니다. 로컬, 서명, 약 3MB.

macOS용 다운로드

Slack 대역폭 사용 줄이기 — 실제로 중요한 설정

대부분의 "Slack에서 대역폭 절약" 조언은 재활용되고 잘못되었습니다. 실제로 작동하는 것은 다음과 같습니다.

1. 이모지 애니메이션: 끄기

Slack → 환경설정 → 애니메이션 및 이미지 미리보기 → 스크롤하면서 이모지 애니메이션. 끄기. 대역폭(애니메이션 GIF는 큼)과 CPU를 모두 줄입니다.

2. 미디어 인라인 표시: 필요에 따라

같은 환경설정 패널. "이미지 및 파일 표시"를 수동으로 설정하면 확장하기 위해 클릭하게 되며, 모든 공유 이미지의 자동 다운로드를 피합니다. 트레이드오프는 약간 덜 풍부한 UI입니다. 대역폭 제약 연결의 경우 쉬운 승리입니다.

3. 음성 및 비디오 기본값

허들에서 다음을 할 수 있습니다.

• 비디오 끄기 — 그 부분에서 업로드를 ~80% 떨어뜨림.
• 다른 참가자의 비디오 숨기기(갤러리 → 발화자 뷰) — 디코딩 부하 감소.
• Slack이 노출한다면 비디오 품질 낮추기.

핫스팟의 긴 회의의 경우, 비디오 끄기가 적절한 기본값입니다.

4. 필요하지 않을 때 Slack 종료

명백하게 들립니다. Slack은 최소화되었을 때 웹소켓을 닫는 데 어려움이 있습니다 — 창을 닫는 것이 macOS에서 앱을 종료하지 않습니다. Cmd-Q가 합니다. 종량제 연결에 있고 실시간 메시징이 필요하지 않다면 종료하세요.

5. 자동 실행하는 워크스페이스 제한

각 워크스페이스는 대략 한 세트의 도우미와 한 웹소켓을 실행합니다. 세 워크스페이스는 모든 것의 세 배입니다. 적극적으로 사용하지 않는 워크스페이스를 제거하면 그것의 대역폭 점유를 제거합니다.

도구 간에 숫자가 일치하지 않는 이유

자주 있는 혼란: 활성 상태 보기는 Slack이 오늘 240MB를 사용했다고 말하고, 메뉴 바 모니터는 380MB라고 하고, nettop은 또 다른 숫자를 보여줍니다. 이유:

• 다른 측정 창. 활성 상태 보기는 프로세스 시작 이후 셉니다. 메뉴 바 모니터는 오늘, 이번 주, 또는 회전을 셀 수 있습니다.
• 도우미 포함. 한 도구의 부모 프로세스 행이 도우미를 제외한다면, 그것들을 접는 도구보다 적게 볼 것입니다.
• 샘플링 대 총 카운터. nettop은 폴링합니다. 활성 상태 보기는 커널 카운터를 읽습니다. 좋은 모니터도 같은 일을 합니다. 같은 범위로 같은 창에 걸쳐 측정되면 숫자가 가깝게 일치해야 합니다.

수정은 한 도구를 고르고 비교에 일관되게 사용하는 것입니다. ova의 앱별 행은 한 숫자입니다 — 모든 Slack 도우미에 걸쳐 결합, 선택한 창에 걸쳐 — 이는 사과 대 사과 비교를 더 쉽게 만듭니다.

핫스팟이나 한도 연결의 Slack

폰에 테더링하거나 데이터 한도가 있는 곳에서 일한다면, Slack은 빠르게 쌓입니다. 실용 규칙:

1. 셀룰러에서 비디오 허들 없음. 오디오 전용 허들은 견딜 만합니다. 비디오는 그렇지 않습니다.
2. 미디어 자동 다운로드: 끄기. 누군가가 훑어보는 채널에 200MB 디자인 파일을 공유하는 것에서 구해줍니다.
3. 오래된 채널을 열지 마세요. 콜드 열기는 기록을 가져옵니다. 스크롤할 필요가 없다면, 그러지 마세요.
4. 집중된 세션 사이에 Slack 종료. "프레즌스"를 위해 실행되게 두는 대신, 이메일이나 DM에 의존하고 블록의 시작과 끝에 Slack을 확인하세요.
5. 잠시 웹 클라이언트 사용. 단일 탭의 브라우저 버전은 Electron 앱보다 가벼울 수 있습니다 — 더 적은 도우미, 자동 업데이트 백그라운드 작업 없음.

Slack과 대안 비교

대역폭 면에서 대략적인 순서:

• iMessage / 메일 — 푸시 기반, 거의 0의 유휴.
• Telegram, WhatsApp — 작은 유휴 발자국, 적당한 메시지 트래픽.
• Discord — Electron, Slack과 비슷한 아키텍처, 비슷한 유휴 프로필.
• Microsoft Teams — 유휴에서 Slack보다 무거움, 통화에서 비슷.
• Slack — 유휴에서 적당히 무거움, 통화에서 무거움.
• Zoom — 유휴에서 가벼움, 통화에서 무거움(다른 곳의 메모 참조).

이는 전환하라는 권장이 아닙니다 — Slack의 대역폭 프로필은 그것이 하는 일에 비해 합리적입니다. 하지만 "네트워크"를 탓해 왔는데 실제로는 일일 4GB의 메시징 클라이언트라면, 그것은 알 만합니다.

마무리

Mac의 Slack 대역폭 사용은 지속적인 웹소켓, 여러 도우미 프로세스, 인라인 미디어와 화상 통화를 포함하는 기능 세트가 있는 Electron 앱이기 때문에 높습니다. 보는 것의 대부분은 정상입니다. 일부는 구성 가능합니다. 모니터가 도우미를 한 "Slack" 행 아래로 접을 때 모든 것이 추론하기 더 쉽습니다.

ova를 하루 동안 실행하고, 합계에 대한 Slack의 기여를 지켜보고, 비용이 얻는 가치와 일치하는지 결정하세요. 대부분의 사람에게 Slack은 그 값을 합니다. 종량제 연결의 사람에게는 몇 가지 설정 조정이 많이 절약합니다.