재택근무에서 Zoom·Slack만 자주 끊기는 이유

재택근무 환경에서 Zoom 회의는 연결되는데 음성이 끊기고, Slack은 알림이 늦게 도착하거나 파일 업로드가 실패하는 문제가 반복된다면 단순히 인터넷 속도만 의심해서는 안 됩니다. 화상회의와 업무 메신저는 브라우저의 일반적인 웹 페이지와 달리 짧은 HTTPS 요청, 장시간 유지되는 연결, 실시간 미디어 스트림, 파일 저장소와 인증 서버를 함께 사용합니다. 따라서 한 서비스가 여러 호스트와 통신하는 중 일부만 다른 경로로 나가면 로그인은 성공해도 회의 입장이나 메시지 동기화 단계에서 문제가 발생할 수 있습니다.

특히 집에서 사용하는 공유기, 회사 VPN, 보안 프로그램, 통신사 DNS가 동시에 개입하면 애플리케이션마다 프록시 적용 여부가 달라집니다. 브라우저에서 Slack 웹 버전은 정상인데 데스크톱 앱의 알림이 멈추거나, Zoom 회의 페이지는 열리지만 회의 클라이언트의 오디오가 불안정한 상황이 대표적입니다. 이때 모든 트래픽을 무조건 프록시로 보내는 방식은 국내 웹사이트와 금융·공공 서비스의 속도를 떨어뜨리고, 반대로 해외 업무 도메인까지 DIRECT로 보내면 연결 안정성이 낮아질 수 있습니다.

Clash의 분할 라우팅은 이 문제를 서비스 단위로 나누어 다루는 방법입니다. 국내 쇼핑몰, 포털, 사내 시스템은 가능한 한 직접 연결하고, 회사 정책상 허용된 범위에서 Zoom·Slack의 업무용 도메인과 관련 자산만 별도 프록시 그룹으로 보냅니다. 중요한 것은 도메인 이름을 넓게 잡는 것이 아니라, 실제 연결 로그를 확인하면서 필요한 호스트를 단계적으로 추가하는 것입니다.

Zoom과 Slack의 트래픽을 먼저 분리해서 이해하기

분할 라우팅을 만들기 전에 두 서비스가 어떤 통신을 사용하는지 대략적인 지도를 그려야 합니다. Zoom은 로그인과 회의 예약에 사용하는 웹 도메인 외에도 회의 연결, 업데이트, 클라우드 녹화, 이미지와 정적 파일을 위해 여러 호스트를 사용할 수 있습니다. 회의 데이터 자체는 참가자의 지역, 회의 유형, 클라이언트 버전에 따라 달라질 수 있으므로 특정 IP 주소만 고정해 두는 방식은 오래 유지하기 어렵습니다.

Slack도 비슷합니다. 워크스페이스 접속에는 보통 워크스페이스별 주소가 사용되고, 실시간 메시지 동기화와 파일 미리보기, 업로드·다운로드, 인증 과정은 서로 다른 엔드포인트를 거칠 수 있습니다. Slack 웹과 Slack 데스크톱 앱이 완전히 같은 연결을 사용한다고 가정하면 안 됩니다. 앱이 시스템 프록시를 따르는지, TUN 모드로 프로세스 트래픽을 포착해야 하는지에 따라 결과가 달라질 수 있습니다.

초기에는 DOMAIN-SUFFIX를 무리하게 확대하기보다 공식 문서와 연결 로그를 함께 참고하세요. 예를 들어 어떤 도메인이 Zoom이나 Slack처럼 보인다고 해서 그 하위 도메인 전체를 프록시로 보내면, 무관한 분석 서버나 대용량 CDN까지 같은 노드로 들어갈 수 있습니다. 반대로 호스트를 지나치게 잘게 나누면 인증은 프록시를 타고 실시간 연결은 직접 연결되는 식의 불일치가 생깁니다. 한 세션에 필요한 호스트는 가능하면 동일한 정책 그룹으로 묶어 경로를 일관되게 유지하는 편이 안정적입니다.

Clash에서 업무용 분할 라우팅 설정하기

아래 절차는 Clash Verge Rev, Mihomo Party, Clash for Android 등 Mihomo 계열 클라이언트에 공통으로 적용할 수 있는 기본 흐름입니다. 메뉴 이름은 클라이언트마다 다르지만, 핵심은 구독 프로필 준비 → 업무용 프록시 그룹 확인 → 규칙 작성 → TUN 또는 시스템 프록시 적용 → 로그 검증의 순서입니다. 이미 사용 중인 구독 설정이 있다면 원본을 직접 덮어쓰지 말고 별도의 오버라이드나 로컬 복사본에서 시험하세요.

1. 프로필을 백업합니다. 현재 사용 중인 YAML 또는 오버라이드 내용을 저장하고, 기존 규칙에서 GEOIP,KR,DIRECT, MATCH처럼 전체 트래픽에 영향을 주는 마지막 규칙을 확인합니다.
2. 업무용 프록시 그룹을 준비합니다. 여러 노드를 직접 흩어 놓기보다 WORK 또는 OVERSEAS-WORK 같은 선택 그룹을 만들고, 회의 전에 지연 시간과 끊김 여부를 비교합니다.
3. 업무 도메인 규칙을 일반 국내 규칙보다 위에 배치합니다. Zoom과 Slack에 필요한 호스트를 확인한 뒤 해당 그룹으로 보내고, 사내 사이트나 국내 서비스 규칙은 그 아래에 둡니다.
4. 클라이언트 적용 범위를 정합니다. 브라우저만 사용할 때는 시스템 프록시로 먼저 시험하고, 데스크톱 앱·터미널·업데이트 프로그램까지 포함해야 한다면 TUN 모드를 검토합니다.
5. 회의와 메시지 동기화를 각각 재현합니다. Zoom 테스트 회의에 입장해 음성·화면 공유를 확인하고, Slack에서는 메시지 전송, 파일 업로드, 알림 수신을 차례로 시험합니다.

규칙의 기본 형태는 다음과 같은 방향으로 생각할 수 있습니다. 실제 도메인은 사용 중인 서비스와 조직 환경에 맞춰 확인해야 하며, 아래 예시는 구조를 설명하기 위한 것입니다.

rules:
  - DOMAIN-SUFFIX,zoom.us,OVERSEAS-WORK
  - DOMAIN-SUFFIX,slack.com,OVERSEAS-WORK
  - DOMAIN-SUFFIX,slack-edge.com,OVERSEAS-WORK
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

slack-edge.com처럼 파일이나 정적 자산에 사용되는 호스트는 모든 환경에서 동일하게 나타난다고 단정하지 마세요. 연결 로그에 실제로 표시되는 경우에만 추가하고, 회사 워크스페이스가 별도 도메인을 사용한다면 그 주소를 우선적으로 확인해야 합니다. Zoom 역시 회의 미디어가 특정 IP 또는 지역별 도메인으로 연결될 수 있으므로, 웹 로그인에 성공했다는 이유만으로 회의 오디오 경로까지 정상이라고 판단하면 안 됩니다.

TUN 모드, DNS, 그리고 연결 로그 점검

시스템 프록시를 켜도 Zoom 데스크톱 앱이나 Slack 알림이 계속 직접 연결된다면 앱이 운영체제의 프록시 설정을 따르지 않는 것일 수 있습니다. 이 경우 TUN 모드는 애플리케이션별 프록시 지원 여부와 관계없이 시스템 네트워크 인터페이스 수준에서 트래픽을 포착하는 데 도움이 됩니다. 다만 TUN은 모든 문제를 자동으로 해결하는 기능이 아니며, 권한 승인, DNS 모드, 다른 VPN과의 충돌을 함께 점검해야 합니다.

TUN을 켜기 전에는 회사 VPN이나 다른 네트워크 필터를 종료할 수 있는지 확인합니다. 둘 이상의 가상 인터페이스가 동시에 DNS와 라우팅을 가로채면 도메인은 올바르게 해석되어도 실제 연결이 다른 인터페이스로 빠질 수 있습니다. Windows에서는 서비스 모드나 관리자 권한이 필요할 수 있고, macOS에서는 네트워크 확장 허용이 요구될 수 있습니다. Android에서는 VPN 프로필을 다른 VPN 앱과 동시에 사용할 수 없으므로 배터리 절전 예외와 VPN 상시 연결 설정도 확인해야 합니다.

DNS는 규칙 매칭의 출발점입니다. fake-ip, redir-host, 시스템 DNS 중 어떤 모드를 선택할지는 네트워크 환경과 서비스 호환성에 따라 달라집니다. Slack 파일 링크가 잘못된 주소로 열리거나 Zoom이 회의 서버를 찾지 못한다면 DNS 캐시를 지우고, Clash 로그에 표시된 실제 요청 호스트와 DNS 응답을 함께 비교하세요. 필요 이상으로 모든 도메인을 fake-ip 예외에 넣으면 관리가 어려워지므로, 문제가 재현되는 호스트만 예외로 추가하는 것이 안전합니다.

재현 직후 확인할 항목

• 요청 호스트: Zoom 또는 Slack 관련 요청이 예상한 FQDN으로 표시되는지 확인합니다.
• 매칭 규칙: 업무용 규칙이 GEOIP나 MATCH보다 먼저 적용되었는지 봅니다.
• 출구 그룹: 인증, 실시간 연결, 파일 요청이 의도한 그룹으로 일관되게 나가는지 확인합니다.
• 연결 상태: 연결이 즉시 끊기는지, 일정 시간 후 끊기는지 구분합니다. 후자의 경우 노드 품질이나 장시간 연결 유지 문제일 수 있습니다.
• 직접 연결 비교: 업무 규칙을 잠시 비활성화해 증상이 같은지 비교하되, 민감한 회사 데이터가 오가는 세션에서는 실험을 피합니다.

Zoom의 경우 회의 입장만 확인하지 말고 10분 이상 음성 통화, 카메라 켜기, 화면 공유, 채팅 전송을 각각 시험해야 합니다. Slack도 메시지 하나만 보내는 것으로 충분하지 않습니다. 새 메시지 알림, 스레드 열기, 파일 업로드와 다운로드, 여러 채널 전환을 확인해야 어떤 호스트가 누락되었는지 찾을 수 있습니다. 로그는 성공한 순간에도 기록해 두면 다음 장애 때 정상 경로와 실패 경로를 비교하기 쉽습니다.

업무 중 안정성을 유지하는 운영 원칙

재택근무용 Clash 설정은 한 번 작성하고 끝나는 규칙보다, 업무 흐름에 맞춰 관리하는 규칙이 더 중요합니다. 첫째, 업무용 그룹과 일반 웹용 그룹을 분리하세요. 같은 노드를 모든 서비스에 사용하면 국내 사이트까지 불필요하게 우회되고, 회의 중 대용량 파일 다운로드가 발생할 때 음성 품질이 떨어질 수 있습니다. 둘째, 회의 직전에 프로필을 갱신하거나 규칙을 대폭 수정하지 마세요. 구독 업데이트로 프록시 그룹의 이름이 바뀌면 기존 규칙이 존재하지 않는 그룹을 가리킬 수 있습니다.

셋째, 자동 선택 그룹을 사용할 때는 지연 시간만 보지 말고 실제 회의 품질을 기록해야 합니다. 핑이 낮은 노드가 반드시 음성 품질이 좋은 것은 아닙니다. 장시간 연결에서 패킷 손실이 적은지, 업로드 속도가 충분한지, 특정 시간대에 혼잡하지 않은지가 더 중요할 때가 많습니다. 넷째, TUN 모드를 켠 뒤 프린터, NAS, 사내 공유기 관리 페이지가 작동하지 않는다면 사설 IP 대역을 직접 연결 예외로 두는 방식을 검토하세요.

또한 회사 자료를 다루는 장치에서는 연결 로그와 구독 URL을 안전하게 관리해야 합니다. 로그에 계정 식별자나 파일 주소가 남을 수 있으므로 공개 커뮤니티에 그대로 올리지 말고, 문제를 문의할 때는 토큰과 개인정보를 삭제하세요. 구독 URL은 비밀번호와 비슷한 민감 정보이며, 유출되면 다른 사람이 사용량을 소진하거나 계정 접근 정보를 추측할 가능성이 있습니다.

일부 범용 VPN이나 단순 프록시 앱은 모든 트래픽을 한 경로로 보내기 때문에 설정은 쉬워도 국내 사이트와 업무 서비스의 경로를 세밀하게 나누기 어렵고, 앱별 예외 관리나 연결 로그가 부족한 경우가 있습니다. 반대로 Clash 공식 사이트는 Clash·Mihomo 클라이언트의 프로필, 규칙 우선순위, TUN 적용 범위를 한 흐름으로 확인할 수 있도록 관련 정보를 정리해 두어 Zoom 회의와 Slack 동기화 문제를 단계적으로 점검하기 좋습니다. 과도한 우회 없이 필요한 업무 트래픽만 안정적으로 분리하고 싶다면, 사용 중인 운영체제에 맞는 클라이언트를 다운로드해 시작해 보세요.