재택근무 Zoom·Slack 연결을 안정화하는 Clash 분할 설정법

이 글이 필요한 재택근무 환경

재택근무 중 Zoom 회의가 시작되면 화면은 보이지만 음성이 끊기거나, Slack 메시지가 몇 초 늦게 도착하고 파일 업로드가 반복해서 실패하는 경우가 있습니다. Google Meet에서는 카메라 품질이 자동으로 낮아지고, 회의 초대 링크를 열 때만 브라우저가 오래 멈추기도 합니다. 이런 현상은 단순히 인터넷 속도가 느려서만 발생하지 않습니다. 화상회의는 짧은 지연 시간과 안정적인 업로드가 중요하고, Slack은 웹소켓 연결과 여러 API 요청을 오래 유지하기 때문에 각 서비스에 맞는 네트워크 경로가 필요합니다.

이 글에서는 Clash Verge Rev 또는 Mihomo 코어를 사용하는 Clash 클라이언트를 기준으로 업무 앱별 분할 라우팅을 구성하는 방법을 설명합니다. 목표는 모든 트래픽을 무조건 프록시로 보내는 것이 아닙니다. Zoom·Slack·Google Meet처럼 연결 품질을 확인해야 하는 업무 트래픽은 안정적인 프록시 그룹으로 보내고, 국내 포털·은행·사내 서비스처럼 직접 연결이 더 적합한 트래픽은 DIRECT로 유지하는 방식입니다.

먼저 문제가 회의 서비스 자체인지, 집의 Wi-Fi인지, Clash 규칙인지 구분해야 합니다. Clash를 끈 상태에서 같은 회의에 참여해 보고, 유선 연결이나 5GHz Wi-Fi에서도 증상이 반복되는지 확인하세요. Clash를 켰을 때만 문제가 생긴다면 노드의 지연 시간, DNS 처리, 규칙 매칭, TUN 모드와 시스템 프록시의 중복 적용을 차례로 점검하는 것이 효율적입니다. 반대로 Clash를 꺼도 음성이 끊긴다면 프록시 설정만 수정해서는 해결되지 않으며 공유기 위치, 업로드 대역폭, 다른 가족 기기의 동시 사용량을 먼저 확인해야 합니다.

Zoom·Slack·Google Meet를 분리해야 하는 이유

재택근무 환경에서 글로벌 모드로 모든 연결을 하나의 노드에 몰아넣으면 처음에는 설정이 간단해 보입니다. 그러나 회의 중 국내 웹사이트를 열거나 사내 VPN에 접속할 때 모든 요청이 같은 출구를 타면서 불필요한 지연이 생길 수 있습니다. 반대로 규칙 모드에서 업무 트래픽을 구분하면 회의와 일반 웹 사용이 서로의 품질에 미치는 영향을 줄일 수 있습니다.

서비스 이름만 보고 하나의 도메인만 규칙에 넣는 것은 충분하지 않을 수 있습니다. Zoom은 회의 제어, 인증, 업데이트, 미디어 전송에 서로 다른 호스트를 사용할 수 있고, Slack도 워크스페이스 주소 외에 API와 파일 저장소 도메인을 함께 사용할 수 있습니다. Google Meet 역시 회의 페이지와 Google 계정 인증 흐름이 분리될 수 있습니다. 따라서 규칙을 작성하기 전에 실제로 앱을 실행하면서 Clash의 연결 로그에 어떤 호스트가 나타나는지 확인해야 합니다.

특히 화상회의에서 중요한 것은 다운로드 속도만이 아닙니다. 200Mbps 회선이라도 업로드가 포화되거나 패킷 손실이 반복되면 상대방에게 음성이 끊겨 들립니다. 노드 선택 화면에서 단순한 최고 속도보다 평균 지연 시간, 지연 시간의 변동 폭, 짧은 시간 동안의 연결 실패 횟수를 함께 보세요. 회의가 한 시간 이상 이어지는 환경에서는 순간적인 최고 수치보다 지속성이 더 중요합니다.

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

아래 단계는 Clash Verge Rev를 예로 들지만, 설정 항목이 있는 다른 Mihomo 기반 클라이언트에서도 원리는 같습니다. 메뉴 이름은 버전에 따라 조금 다를 수 있으므로 Profiles, Proxies, Rules, Logs에 해당하는 화면을 찾으면 됩니다. 설정을 변경하기 전에는 현재 프로필을 별도 파일로 백업해 두세요. 구독 업데이트가 실행되면 직접 추가한 규칙이 사라지거나 우선순위가 바뀌는 경우가 있기 때문입니다.

1. 프로필과 코어 상태를 확인합니다.

   Clash에서 사용 중인 프로필이 실제로 활성화되어 있는지 확인하고, 코어가 재시작을 반복하지 않는지 로그에서 살펴봅니다. 프로필을 바꾼 직후에는 기존 연결이 남아 앱이 계속 정상인 것처럼 보일 수 있으므로, 테스트 전에 Zoom·Slack·브라우저를 완전히 종료한 뒤 다시 실행하는 편이 좋습니다.

2. 업무용 프록시 그룹을 준비합니다.

   노드 목록에서 가까운 지역의 후보를 몇 개 선택하고 지연 시간만으로 결정하지 마세요. 같은 노드라도 저녁 시간대에 혼잡해질 수 있습니다. 자동 선택 그룹을 사용한다면 URL 테스트가 실제 업무 서비스의 품질을 충분히 반영하는지 확인하고, 가능하면 회의 전에 두세 개 후보를 수동으로 비교합니다.

3. 로그에서 실제 호스트를 수집합니다.

   Clash의 연결 로그를 열고 Zoom 회의 참여, Slack 메시지 전송과 파일 업로드, Google Meet 로그인과 회의 참여를 각각 수행합니다. 기록된 호스트를 서비스별로 메모하되, 모르는 도메인을 넓은 키워드 규칙으로 한꺼번에 묶지는 마세요. 업무와 무관한 CDN까지 프록시로 보내면 오히려 웹 로딩이 느려질 수 있습니다.

4. 규칙을 구체적인 순서로 배치합니다.

   직접 지정한 업무 서비스 규칙은 일반적인 국가 규칙이나 대형 규칙 세트보다 위에 있어야 합니다. 규칙은 위에서 아래로 평가되는 경우가 많으므로, 세부적인 DOMAIN-SUFFIX 또는 DOMAIN 규칙을 먼저 두고 마지막에 지역별 GEOIP, GEOSITE, MATCH를 배치합니다.

5. 설정을 적용하고 앱을 새로 연결합니다.

   규칙 저장 후 코어를 재시작하거나 프로필을 다시 적용합니다. 이미 열린 Slack 웹소켓이나 브라우저의 HTTP/2 세션은 새 규칙을 즉시 반영하지 않을 수 있습니다. 따라서 앱에서 로그아웃할 필요까지는 없지만, 브라우저 탭과 데스크톱 앱을 닫았다가 다시 열어 새 연결이 어느 정책 그룹을 타는지 확인하세요.

예시 형태는 다음과 같습니다. 실제 호스트는 사용 중인 버전과 지역에 따라 달라질 수 있으므로, 아래 항목을 그대로 복사하기보다 연결 로그에서 확인한 도메인으로 교체해야 합니다.

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK
  - DOMAIN-SUFFIX,zoom.com,WORK
  - DOMAIN-SUFFIX,slack.com,WORK
  - DOMAIN-SUFFIX,googlemeet.com,WORK
  - DOMAIN-SUFFIX,google.com,WORK
  - DOMAIN-SUFFIX,googleapis.com,WORK
  - DOMAIN-SUFFIX,example.co.kr,DIRECT
  - MATCH,FINAL

위 예시에서 WORK는 실제 프로필에 존재하는 프록시 그룹 이름으로 바꿔야 합니다. 그룹 이름이 다르거나 오타가 있으면 설정이 로드되지 않거나 예상과 다른 기본 정책으로 빠질 수 있습니다. 또한 google.com 전체를 프록시로 지정하면 업무와 무관한 검색, YouTube, 개인 계정 서비스까지 같은 그룹을 사용할 수 있으므로, Google Meet 인증에 필요한 범위를 확인한 뒤 더 좁은 규칙을 사용하는 것이 안전합니다.

지연 시간과 연결 품질을 검증하는 방법

설정이 끝났다면 먼저 국내 웹사이트가 여전히 직접 연결되는지 확인합니다. 뉴스 사이트나 회사의 허가된 내부 서비스가 갑자기 해외 출구 IP로 표시된다면 규칙 순서가 너무 넓거나 최종 매칭 규칙이 예상과 다를 수 있습니다. 업무 트래픽은 프록시로 가고 국내 트래픽은 직접 연결되는지 로그에서 각각 한 번씩 확인해야 합니다. 단순히 브라우저가 열린다는 사실만으로는 분할 라우팅이 제대로 적용되었다고 볼 수 없습니다.

Zoom에서는 회의 중 통계 화면을 열어 지연 시간, 수신·송신 손실, 지터를 확인합니다. 수치의 절대 기준은 회의 참가자와 코덱, 회의 서버 위치에 따라 달라지지만, 노드를 바꿨을 때 지연과 손실이 함께 안정되는지를 비교하는 것이 핵심입니다. 지연 시간이 낮아도 지터가 크게 흔들리면 음성이 겹쳐 들리거나 화면이 순간적으로 흐려질 수 있습니다. 회의 전 카메라를 고해상도로 고정하기보다 네트워크 상태가 불안정할 때 자동 품질 조절을 허용하는 편이 실무적으로 나을 때도 있습니다.

Slack은 메시지를 보낸 뒤 다른 기기나 웹 클라이언트에 도착하는 시간을 비교하고, 작은 파일과 큰 파일을 각각 업로드해 보세요. 메시지는 빠른데 파일만 실패한다면 Slack 전체가 아니라 파일 저장소 또는 업로드 관련 호스트가 다른 규칙을 타고 있을 가능성이 있습니다. 이때는 모든 Slack 관련 도메인을 무작정 추가하기보다 실패 시각의 로그에서 해당 연결을 찾아 같은 업무 그룹에 넣는 방식이 안전합니다.

Google Meet에서는 회의 링크를 직접 열 때와 Google 계정 로그인 직후를 나누어 확인하세요. 회의 화면은 열리는데 로그인만 반복된다면 인증 호스트가 다른 경로를 타고 있을 수 있습니다. 반대로 로그인은 되지만 회의 미디어만 불안정하다면 브라우저 권한, Wi-Fi 간섭, 업로드 포화, UDP 처리 여부를 함께 살펴야 합니다. TUN 모드와 시스템 프록시를 동시에 켠 상태에서 특정 브라우저만 실패한다면 먼저 한 가지 방식만 남겨 경로를 단순화하세요.

문제가 발생했을 때는 다음 정보를 시간과 함께 기록하면 재현과 수정이 쉬워집니다.

• 사용한 Clash 클라이언트와 Mihomo 코어 버전
• 활성 프로필과 실제 선택된 프록시 노드
• 실패한 앱, 시각, 연결한 Wi-Fi 또는 유선 환경
• Clash 로그에 표시된 호스트와 정책 결과
• Zoom 통계의 지연·지터·손실 또는 Slack의 오류 메시지
• TUN, 시스템 프록시, VPN, 회사 보안 프로그램의 활성 상태

보안 측면도 잊지 마세요. 회의 링크, 워크스페이스 이름, 회사 내부 도메인, 인증 토큰이 포함된 로그를 공개 채널에 그대로 올리면 안 됩니다. 문제를 공유해야 한다면 계정명과 URL의 식별 부분을 지우고, 규칙 파일에 API 키나 구독 URL을 직접 작성하지 마세요. 또한 회사 정책상 승인되지 않은 프록시를 업무 데이터에 사용하는 것이 금지되어 있을 수 있으므로, 조직의 보안 규정과 화상회의 녹화·파일 전송 정책을 먼저 확인해야 합니다.

일반적인 VPN 클라이언트는 전체 트래픽을 한 경로로 보내기 때문에 빠르게 켜고 끄기에는 편하지만, 국내 업무 사이트와 글로벌 협업 도구를 동시에 사용하는 재택근무에서는 인증 경로가 꼬이거나 불필요한 트래픽까지 우회되는 단점이 있습니다. 반면 Clash는 Zoom·Slack·Google Meet를 실제 로그에 맞춰 업무 그룹으로 묶고 국내 사이트는 DIRECT로 남기는 세밀한 분기, 노드별 비교, 연결 로그 확인을 한 화면에서 수행할 수 있어 원인 추적과 장시간 회의 안정화에 유리합니다. 이런 방식으로 자신의 업무 환경에 맞는 규칙을 구성하고 싶다면 아래에서 사용 중인 플랫폼에 맞는 Clash 클라이언트를 확인해 보세요.

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