Clash 원격근무 설정법: Zoom·Slack 연결 최적화와 분할 라우팅

이 글이 맞는 원격근무 증상

Zoom 회의에 들어가면 음성은 들리지만 화면 공유가 늦게 나타나거나, Slack 알림이 몇 분 뒤에 몰아서 도착하는 경우가 있습니다. Google Meet에서는 카메라가 켜진 뒤 영상 품질이 급격히 낮아지고, 회의 중간에 “네트워크가 불안정합니다”라는 메시지가 반복되기도 합니다. 이런 현상은 단순히 인터넷 속도가 느려서만 발생하지 않습니다. 화상회의는 짧은 지연 시간과 일정한 업로드 품질이 중요하고, Slack은 웹소켓 연결과 여러 알림 도메인을 동시에 사용하기 때문입니다.

이 문서는 원격근무자가 Clash Verge Rev 또는 Mihomo 기반 클라이언트에서 업무 트래픽과 해외 서비스 트래픽을 분리하는 방법을 설명합니다. 모든 연결을 무조건 프록시로 보내는 글로벌 모드 대신, 회의·협업 서비스에는 안정적인 노드를 지정하고 국내 포털·사내 시스템·파일 서버는 DIRECT로 남기는 구성을 기준으로 합니다. 특정 구독 서비스나 노드 이름을 전제로 하지 않으므로, 현재 사용하는 프로필의 그룹명에 맞춰 규칙만 바꾸면 됩니다.

먼저 문제가 발생하는 시간을 기록하세요. 회의 시작 직후인지, 화면 공유를 시작할 때인지, 동료가 보낸 Slack 파일을 열 때인지에 따라 원인이 달라집니다. Clash의 연결 로그에서 실제 호스트와 선택된策略를 함께 확인하면 막연히 “노드가 느리다”고 판단하는 실수를 줄일 수 있습니다.

원격근무 서비스의 연결 구조 이해하기

Zoom·Slack·Google Meet는 하나의 도메인만 사용하는 서비스가 아닙니다. 로그인, API 요청, 정적 파일, 이미지·파일 저장소, 실시간 메시지와 회의 미디어가 서로 다른 호스트로 분리될 수 있습니다. 따라서 메인 웹사이트 하나만 프록시로 지정하고 나머지를 놓치면 로그인은 되지만 회의나 알림만 실패하는 상황이 생깁니다.

• Zoom: 계정 로그인과 회의 제어 외에 회의 미디어 서버, 화면 공유, 업데이트 요청이 별도 연결을 사용할 수 있습니다.
• Slack: 워크스페이스 웹 주소, API, 웹소켓 기반 실시간 이벤트, 파일 미리보기와 업로드 경로가 나뉘어 동작합니다.
• Google Meet: Google 계정 인증, Meet 웹 애플리케이션, 실시간 음성·영상 미디어가 서로 다른 경로를 사용할 수 있습니다.
• 국내 업무 서비스: 사내 VPN, 그룹웨어, 국내 클라우드 저장소는 프록시를 거치면 인증 지연이나 접근 제한이 생길 수 있습니다.

이 때문에 처음부터 모든 Google 또는 Microsoft 관련 도메인을 넓게 묶는 방식은 권장하지 않습니다. 너무 넓은 DOMAIN-SUFFIX 규칙은 업무용 국내 서비스와 개인 트래픽까지 같은 노드로 보내고, 노드 장애가 발생했을 때 문제 범위를 불필요하게 키울 수 있습니다. 실제 연결 로그에서 확인한 호스트를 우선 등록하고, 프로필 업데이트 후 규칙이 여전히 원하는 그룹을 가리키는지 다시 확인하는 편이 안전합니다.

1단계: Clash 기본 설정과 노드 그룹 정리

Clash를 설정하기 전에 활성 프로필, 코어 상태, 시스템 프록시 또는 TUN 상태를 확인합니다. 구독을 갱신한 직후라면 프록시 그룹 이름이나 규칙 프로바이더가 바뀌었을 수 있으므로, 예전에 사용하던 그룹명을 그대로 YAML에 입력하지 마세요. CVR에서는 현재 활성 프로필의 규칙과 연결 로그가 같은 설정을 바라보는지 먼저 확인해야 합니다.

화상회의용 그룹은 이름보다 실제 성능을 기준으로 선택합니다. 가까운 지역의 노드가 항상 최선인 것은 아니며, 회의 서버와의 경로, 업로드 지연, 패킷 손실률, 노드의 동시 사용자 수가 더 큰 영향을 줍니다. 다음처럼 역할을 분리하면 운영이 쉬워집니다.

• WORK-VIDEO: Zoom·Google Meet처럼 지연과 업로드 안정성이 중요한 서비스용 그룹
• WORK-CHAT: Slack 메시지·웹소켓·파일 미리보기용 그룹
• GLOBAL-FALLBACK: 특정 지역 노드가 실패했을 때 사용할 보조 그룹
• DIRECT: 국내 웹사이트, 사내망, 프린터, NAS와 같은 로컬 자원

그룹을 나눈다고 해서 반드시 서로 다른 노드를 써야 하는 것은 아닙니다. 업무 시간에는 동일한 안정 노드를 두 그룹이 함께 사용하고, 회의가 시작되면 WORK-VIDEO만 수동으로 더 안정적인 노드로 바꾸는 방식도 실용적입니다. 반대로 Slack 메시지까지 매번 다른 노드로 바뀌면 웹소켓 세션이 재연결되면서 알림이 늦어질 수 있으므로, 채팅 그룹에는 자동 선택보다 짧은 시간 동안 고정되는 정책이 유리합니다.

2단계: 업무 서비스와 국내 트래픽 분할 라우팅

핵심은 글로벌 모드가 아니라 규칙 모드입니다. 글로벌 모드는 원인 파악이 단순하다는 장점이 있지만, 국내 그룹웨어와 사내 시스템까지 해외 노드로 보내 속도를 떨어뜨릴 수 있습니다. 규칙 모드에서는 업무에 필요한 서비스만 프록시로 지정하고, 로컬 자원은 명시적으로 직접 연결해 경로를 예측 가능하게 만듭니다.

개념적으로는 다음과 같은 순서를 생각할 수 있습니다. 실제 규칙 문법과 그룹명은 사용하는 코어와 구독 제공자의 형식에 맞춰 조정해야 합니다.

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK-VIDEO
  - DOMAIN-SUFFIX,zoom.com,WORK-VIDEO
  - DOMAIN-SUFFIX,slack.com,WORK-CHAT
  - DOMAIN-SUFFIX,slack-edge.com,WORK-CHAT
  - DOMAIN-SUFFIX,meet.google.com,WORK-VIDEO
  - DOMAIN-SUFFIX,googleapis.com,WORK-VIDEO
  - DOMAIN-SUFFIX,회사내부도메인.kr,DIRECT
  - GEOIP,KR,DIRECT
  - MATCH,GLOBAL-FALLBACK

위 예시는 출발점일 뿐입니다. googleapis.com처럼 범위가 넓은 도메인을 추가하면 Google Drive, 문서, 사내 계정 서비스까지 같은 그룹으로 이동할 수 있으므로 반드시 로그를 확인해야 합니다. 회의 중 화면 공유만 실패한다면 Zoom 메인 도메인을 추가하는 것보다 실제 실패 요청의 호스트를 확인하는 편이 정확합니다. Slack 파일이 열리지 않을 때도 slack.com만 추가하지 말고 파일 저장소와 CDN 호스트가 어디였는지 살펴보세요.

규칙의 순서도 중요합니다. 너무 넓은 국내 직접 연결 규칙이 업무 서비스 규칙보다 위에 있으면 Zoom이나 Slack이 DIRECT로 빠질 수 있습니다. 반대로 GEOSITE 기반의 광범위한 프록시 규칙이 먼저 오면 사내 시스템까지 프록시로 이동할 수 있습니다. 위에서 아래로 첫 번째로 일치하는 규칙이 적용된다는 점을 기억하고, 수정할 때마다 로그의 정책 결과를 확인하세요.

3단계: 회의용 노드와 연결 품질 테스트

노드 선택은 다운로드 속도 하나만으로 결정하면 안 됩니다. 화상회의에서는 지연 시간, 지터, 업로드 안정성, 패킷 손실, 장시간 연결 유지가 함께 중요합니다. 속도 측정 사이트에서 높은 수치가 나오더라도 40분 뒤 연결이 재협상되거나 업로드가 흔들리면 실제 회의 품질은 나쁠 수 있습니다.

업무 시작 전에 같은 테스트를 두세 개 노드에서 반복하세요. 먼저 Zoom 테스트 회의나 Google Meet 미리보기 화면에서 마이크와 카메라를 켜고, 짧은 시간 동안 영상 품질이 유지되는지 확인합니다. 다음으로 화면 공유를 시작해 업로드가 급격히 낮아지는지 봅니다. 마지막으로 Slack에서 새 메시지를 보내고 다른 기기에서 답장을 받은 뒤, 실시간 알림이 즉시 도착하는지 확인합니다. 테스트 결과를 아래처럼 간단히 기록하면 자동 선택 그룹의 기준을 정하기 쉽습니다.

회의 중에는 자동 선택이 노드를 자주 바꾸지 않도록 주의하세요. 짧은 테스트에서는 빠른 노드가 선택되더라도, 실제 회의 도중 그룹 평가가 실행되면 세션이 재연결되어 음성이나 화면 공유가 끊길 수 있습니다. 회의 직전 안정적인 노드를 수동 선택하고, 회의가 끝난 뒤에만 지연 시간과 연결 로그를 기준으로 다시 평가하는 운영 방식이 더 안전합니다.

회의 끊김과 Slack 지연을 진단하는 순서

Zoom이나 Google Meet가 끊겼을 때 곧바로 노드를 바꾸기보다, 먼저 Clash 로그에서 연결이 어떻게 종료됐는지 봅니다. DNS 실패라면 DNS 모드와 리졸버 경로를 확인하고, TLS handshake timeout이라면 노드의 혼잡도와 회의 호스트 규칙을 점검합니다. 연결은 유지되지만 음성과 영상만 불안정하다면 노드의 업로드 품질이나 패킷 손실, MTU 문제를 의심할 수 있습니다.

Slack 알림이 늦는 경우에는 브라우저 탭을 새로 고치는 것보다 웹소켓 연결이 유지되는지 확인하는 것이 먼저입니다. 네트워크가 잠시 바뀌면서 웹소켓이 재연결되는 상황, 배터리 절약 기능이 브라우저를 중지하는 상황, Slack 관련 호스트 일부가 DIRECT로 빠지는 상황이 대표적입니다. 모바일 핫스팟과 사무실 Wi-Fi에서 각각 같은 테스트를 해 보면 회선 문제인지 Clash 규칙 문제인지도 구분할 수 있습니다.

국내 업무 서비스가 느려졌다면 프록시를 전체적으로 끄기보다 해당 도메인의 정책을 확인하세요. 사내 VPN 주소, 내부 DNS 이름, 국내 그룹웨어를 DIRECT 또는 사내 VPN 규칙으로 분리하면 해외 업무 트래픽은 유지하면서 국내 서비스 응답 속도를 회복할 수 있습니다. 다만 조직의 보안 정책이 정한 VPN과 인증 방식을 임의로 우회해서는 안 되며, 회사 장비에서는 IT 관리자의 규칙을 우선해야 합니다.

일반적인 무료 프록시 확장 프로그램은 브라우저 탭 하나에는 편하지만, Zoom 데스크톱 앱·Slack 알림·Google Meet 미디어처럼 여러 애플리케이션의 연결을 함께 관리하기 어렵고, 예외 규칙이나 장시간 연결 상태를 확인하기도 제한적입니다. 반면 Clash는 규칙별 로그, 업무 서비스와 국내 트래픽의 분할 라우팅, 노드 그룹 고정, TUN과 시스템 프록시 선택을 한 곳에서 조정할 수 있어 원격근무 환경을 재현 가능하게 관리하기 좋습니다. 여러 앱을 일일이 설정하지 않고 회의 품질과 국내 업무 접근성을 함께 조정하고 싶다면, 사용하는 플랫폼에 맞는 Clash 클라이언트를 내려받아 이 글의 분할 라우팅 흐름부터 적용해 보세요.

지금 Clash를 무료로 다운로드하고 자유로운 인터넷 경험을 →