이 글이 필요한 재택근무 환경
재택근무에서 가장 불편한 문제는 인터넷이 완전히 끊기는 상황보다 화상회의는 연결되지만 음성과 화면이 늦게 따라오거나, Slack 알림이 몇 분 뒤에 도착하는 현상입니다. Zoom 회의에 들어간 뒤 상대방 목소리가 로봇처럼 들리고, 화면 공유가 멈추며, Google Meet에서는 카메라가 반복해서 재연결되는 경우가 대표적입니다. 동시에 Slack은 메시지 전송 아이콘만 오래 표시되거나 모바일 알림과 데스크톱 알림의 도착 순서가 달라질 수 있습니다.
이런 증상을 단순히 “노드가 느리다”라고 판단해 모든 트래픽을 글로벌 프록시로 보내면 문제가 더 복잡해질 수 있습니다. 국내 은행, 회사 VPN, 정부 사이트, 가까운 CDN까지 해외 노드를 거치면서 오히려 접속 지연과 인증 오류가 늘어나기 때문입니다. 이 글에서는 Clash Verge Rev 또는 Mihomo 계열 클라이언트를 기준으로, Zoom·Slack·Google Meet처럼 업무에 필요한 서비스만 안정적인 프록시 그룹으로 보내고 국내 사이트와 사내 주소는 DIRECT로 유지하는 분할 라우팅 방식을 설명합니다.
중요한 전제도 있습니다. Clash는 회의 서비스 자체의 서버 장애, 노트북의 오래된 무선 드라이버, 부족한 업로드 대역폭을 자동으로 해결하지 않습니다. 따라서 설정을 바꾸기 전에 공유기와 노트북을 유선 또는 5GHz Wi-Fi에 연결하고, 회의 중 다른 기기의 대용량 업로드가 없는지 먼저 확인해야 합니다. 그 다음 Clash 로그에서 실제로 어떤 호스트가 어느 정책 그룹을 통과하는지 확인해야 설정 효과를 정확히 판단할 수 있습니다.
Zoom·Slack·Meet 트래픽을 한꺼번에 다루면 안 되는 이유
화상회의와 협업 메신저는 모두 “업무용 서비스”로 분류할 수 있지만, 네트워크 사용 방식은 서로 다릅니다. Zoom은 회의 접속 과정에서 계정·인증·설정 서버에 HTTPS로 연결한 뒤, 실제 회의에서는 음성·영상 미디어 스트림을 별도의 서버와 포트로 주고받습니다. Slack은 웹 앱, 데스크톱 앱, 파일 미리보기, 실시간 이벤트 연결을 함께 사용하며, Google Meet은 Google 계정 인증과 회의 제어 트래픽, 오디오·비디오 미디어 경로가 나뉠 수 있습니다.
| 서비스 | 주요 트래픽 | 설정에서 확인할 점 | 권장 방향 |
|---|---|---|---|
| Zoom | 로그인·회의 제어·음성·화면 공유 | 회의 중 연결 로그와 실제 지연 시간 | 검증된 저지연 그룹으로 고정 |
| Slack | 웹소켓 이벤트·메시지·파일·외부 링크 | 알림 지연과 파일 업로드 경로를 따로 확인 | 업무용 프록시 그룹, 사내 도메인은 예외 |
| Google Meet | Google 계정·회의 제어·미디어 스트림 | Google 인증과 회의 연결이 같은 경로인지 확인 | 안정적인 그룹으로 일관되게 라우팅 |
도메인 목록을 너무 넓게 잡는 것도 주의해야 합니다. 예를 들어 모든 googleapis.com 트래픽을 한 그룹으로 보내면 Meet뿐 아니라 문서 동기화나 다른 Google 서비스까지 같은 노드를 사용할 수 있습니다. 반대로 로그인 도메인만 프록시로 보내고 회의 제어 또는 이벤트 도메인을 빠뜨리면 “로그인은 되는데 회의 입장이 실패하는” 상황이 생깁니다. 가장 안전한 순서는 서비스의 공식 도메인 목록을 참고하되, 실제 장애 순간의 Clash 연결 로그를 기준으로 누락된 호스트를 좁혀 가는 것입니다.
또한 Zoom과 Meet의 미디어 트래픽은 일반 웹페이지보다 지속 시간이 길고 업로드와 다운로드가 동시에 발생합니다. 짧은 페이지 로딩 속도만 보고 노드를 선택하면 회의 중에는 결과가 달라질 수 있습니다. 회의 시작 후 5분 정도 음성 지연, 화면 공유, 카메라 전환을 순서대로 확인하고, 해당 시간대에 연결이 재선택되는지까지 살펴보세요.
실전 설정: Clash에서 업무 트래픽만 분할 라우팅하기
먼저 Clash 클라이언트에서 사용할 프로필을 백업합니다. 구독을 갱신하면 제공자가 규칙 순서나 프록시 그룹 이름을 바꿀 수 있으므로, 현재 정상적으로 동작하는 프로필을 별도 파일로 저장해 두는 것이 좋습니다. 그 다음 모드를 Rule로 설정합니다. Global 모드는 원인 확인을 위한 임시 테스트에는 편하지만, 국내 사이트와 사내 서비스까지 같은 노드로 보내므로 재택근무용 기본값으로는 적합하지 않은 경우가 많습니다.
규칙은 일반적으로 위에서 아래로 평가됩니다. 따라서 업무 서비스 규칙을 광범위한 지역 규칙이나 최종 MATCH,DIRECT보다 위에 배치해야 합니다. 제공자마다 프록시 그룹 이름이 다르므로 아래 예시의 WORK-PROXY는 실제 화면에 표시되는 그룹명으로 바꾸어야 합니다.
rules:
- DOMAIN-SUFFIX,zoom.us,WORK-PROXY
- DOMAIN-SUFFIX,zoom.com,WORK-PROXY
- DOMAIN-SUFFIX,slack.com,WORK-PROXY
- DOMAIN-SUFFIX,slack-edge.com,WORK-PROXY
- DOMAIN-SUFFIX,google.com,WORK-PROXY
- DOMAIN-SUFFIX,googleapis.com,WORK-PROXY
- DOMAIN-SUFFIX,meet.google.com,WORK-PROXY
- DOMAIN-SUFFIX,회사내부도메인.example,DIRECT
- GEOIP,PRIVATE,DIRECT
- MATCH,DIRECT위 예시는 출발점일 뿐이며 모든 계정과 리전에 동일하게 적용되는 완성 목록은 아닙니다. 특히 Google 관련 규칙은 범위가 넓으므로, Google Drive나 사내 Google Workspace가 반드시 같은 경로를 사용해야 하는지 먼저 확인하세요. Zoom 역시 로그인 도메인과 미디어 서버가 항상 동일한 suffix를 사용하는 것은 아닙니다. 회의 연결을 시도하면서 로그에 나타나는 실제 호스트를 확인하고, 필요한 경우 개별 DOMAIN 규칙을 추가하는 방식이 더 정확합니다.
로그에서 규칙 매칭 결과 확인하기
설정 저장 후 코어를 재시작하고, 연결 로그를 열어 Zoom·Slack·Meet 앱을 차례로 실행합니다. 로그에서 호스트, 포트, 선택된策略 그룹, 연결 결과를 확인하세요. 한국어 UI에서는 그룹명이 “프록시”, “업무”, “자동 선택”처럼 표시될 수 있지만, 중요한 것은 이름이 아니라 실제로 같은 그룹으로 연결되었는지입니다. Slack 메시지는 도착하지만 파일만 실패한다면 파일 CDN 도메인이 빠졌을 수 있고, Meet 로그인은 되지만 회의 입장이 멈춘다면 인증과 회의 제어 호스트의 규칙이 다를 수 있습니다.
이 단계에서는 한 번에 여러 값을 바꾸지 않는 것이 좋습니다. 먼저 Zoom만 실행해 연결 경로를 기록하고, 다음으로 Slack 메시지·파일 업로드를 테스트한 뒤, 마지막으로 Meet에서 카메라와 화면 공유를 확인합니다. 각 테스트 사이에 로그를 지우거나 시간대를 메모하면 어떤 규칙이 효과가 있었는지 쉽게 비교할 수 있습니다.
노드 선택과 회의 품질을 함께 검증하는 방법
재택근무용 노드는 단순한 다운로드 속도보다 지연 시간, 지속 연결 안정성, 업로드 품질, 혼잡 시간대의 변동 폭을 기준으로 골라야 합니다. 회의 전용으로 사용할 그룹이 있다면 자동 선택 그룹에 맡기기보다 후보 노드 두세 개를 정해 실제 업무 시간에 비교해 보세요. 자동 선택은 짧은 연결 테스트에서는 빠른 노드를 고르지만, 장시간 화상회의에서 패킷 손실이 커지는 노드까지 걸러내지는 못할 수 있습니다.
| 검증 항목 | 테스트 방법 | 판단 기준 |
|---|---|---|
| 초기 연결 | 회의 입장과 계정 인증을 반복 | 재시도 없이 빠르게 입장하는지 |
| 음성 품질 | 10분 이상 대화하며 지연 확인 | 목소리 겹침과 로봇음이 없는지 |
| 화면 공유 | 문서와 동영상을 번갈아 공유 | 프레임 저하와 재연결이 없는지 |
| 업로드 | Slack 파일 전송과 카메라 사용 | 업로드가 멈추거나 속도가 급락하지 않는지 |
가능하면 아침, 오후, 저녁처럼 서로 다른 시간대에 같은 테스트를 반복합니다. 특정 노드가 오전에는 안정적이지만 저녁 회의 시간에만 손실이 증가한다면 노드 자체보다 사용자 집중과 회선 혼잡이 원인일 수 있습니다. 이때는 가장 빠른 단일 노드보다 두세 개의 안정적인 후보를 포함한 선택 그룹을 구성하고, 장애가 발생했을 때 수동으로 다음 노드로 전환할 수 있게 해 두는 편이 실용적입니다.
회의가 자주 끊긴다면 TUN 모드와 시스템 프록시를 동시에 무작정 켜지 마세요. 같은 트래픽이 시스템 프록시와 TUN을 중복으로 통과하면 루프, DNS 불일치, 예기치 않은 DIRECT 우회가 발생할 수 있습니다. 먼저 브라우저와 데스크톱 앱을 시스템 프록시로 테스트하고, 시스템 프록시를 따르지 않는 앱만 TUN으로 보완합니다. TUN을 켠 뒤에는 회사 VPN, 프린터, NAS, 로컬 회의 장비가 계속 접근되는지 확인하고, 필요한 사설망 대역은 예외 처리해야 합니다.
알림 지연과 화상회의 끊김을 분리해서 해결하기
Slack 알림만 늦고 메시지를 수동으로 새로 고치면 바로 보인다면, 실시간 이벤트 연결이나 백그라운드 권한을 먼저 확인합니다. 데스크톱 앱이 절전 모드에서 복귀한 뒤 웹소켓 연결을 재생성하지 못하는 경우도 있으므로, Clash 규칙을 바꾸기 전에 앱을 완전히 종료하고 다시 실행해 비교해야 합니다. 반대로 메시지와 파일 모두 실패하고 Clash 로그에 timeout이 반복되면 프록시 그룹, DNS 응답, 노드 혼잡을 함께 점검합니다.
Zoom이나 Meet에서 음성은 괜찮지만 화면 공유만 끊긴다면 다운로드 속도보다 업로드 대역폭과 패킷 손실을 의심하세요. 가족이 같은 시간에 클라우드 백업이나 고화질 스트리밍을 실행하면 프록시를 바꾸어도 증상이 남습니다. 공유기에서 다른 기기의 업로드를 잠시 중지하고, 노트북을 유선으로 연결한 상태에서 동일한 회의를 다시 테스트하면 네트워크와 Clash 경로를 구분할 수 있습니다.
회사 VPN을 함께 사용하는 환경에서는 VPN이 전체 트래픽을 강제로 터널링하는지 확인해야 합니다. VPN이 먼저 연결된 뒤 Clash가 다시 프록시를 적용하면 이중 터널이 되고, 반대 순서에서는 VPN 인증 도메인이 프록시로 빠져 로그인에 실패할 수 있습니다. 회사 정책상 업무 데이터의 외부 프록시 사용이 금지되어 있다면 임의로 우회하지 말고 IT 부서의 승인된 split tunneling 정책을 사용하세요. 개인적인 회의 계정과 회사 내부 자료의 경계를 규칙과 장치 수준에서 분리하는 것이 안전합니다.
마지막으로 Clash 연결 로그에는 계정 토큰, 내부 호스트, 파일 이름이 기록될 수 있으므로 화면을 캡처해 공유할 때 민감한 정보를 가리세요. 구독 URL과 인증 헤더는 절대 공개 저장소나 팀 채팅에 붙여 넣지 말고, 프로필을 수정할 때도 비밀 값은 별도 환경이나 제공자의 안전한 관리 기능을 이용하는 것이 좋습니다.
일반적인 VPN 앱은 전체 트래픽을 한 번에 전환하는 방식이 단순한 대신, 국내 서비스 지연이나 사내 VPN 충돌을 세밀하게 제어하기 어렵고, 회의 중 노드가 바뀌면 원인을 추적하기도 쉽지 않습니다. 반면 Clash는 Zoom·Slack·Google Meet을 규칙과 로그로 분리하고, 국내 사이트는 직접 연결하며, 필요할 때 업무용 노드만 교체할 수 있다는 장점이 있습니다. 재택근무 환경에서 이런 세밀한 경로 제어가 필요하다면 사용 중인 플랫폼에 맞는 Clash 클라이언트를 내려받아 위의 규칙과 테스트 절차를 자신의 네트워크에 맞게 적용해 보세요.