재택근무에서 Zoom·Slack 트래픽을 나눠야 하는 이유
집에서 회의할 때 영상은 괜찮은데 Slack 메시지나 파일 업로드가 늦거나, 반대로 웹페이지는 잘 열리지만 Zoom 화면 공유가 끊기는 경우가 있습니다. 이런 증상은 단순히 “인터넷이 느리다”는 문제만은 아닙니다. 앱마다 연결하는 서버와 전송 방식이 다르고, 노트북의 시스템 프록시를 따르는 앱과 따르지 않는 앱도 있기 때문입니다. 모든 트래픽을 한 노드로 보내면 설정은 간단하지만, 국내 서비스나 사내 업무 시스템까지 먼 경로를 타면서 지연이 늘어날 수 있습니다.
Clash 분할 라우팅은 Zoom이나 Slack처럼 필요한 업무 트래픽만 프록시 그룹으로 보내고, 일반 웹사이트와 로컬 네트워크는 직접 연결하도록 정책을 나누는 방식입니다. 업무용 앱의 접속 경로를 명확하게 관리하면서도 전체 인터넷 사용을 하나의 노드에 의존하지 않게 됩니다. 단, 프록시를 사용한다고 회의 품질이 항상 좋아지는 것은 아닙니다. 선택한 노드의 혼잡도, 회사 VPN·보안 에이전트, Wi-Fi 품질, Zoom의 UDP 미디어 경로가 함께 영향을 줍니다.
Zoom은 회의 제어와 로그인에 쓰이는 HTTPS 연결뿐 아니라 실시간 음성·영상 미디어 연결도 사용합니다. 네트워크 정책이나 프록시 유형에 따라 미디어가 TCP 경로로 전환되거나 우회될 수 있어, 웹사이트가 잘 열린다는 사실만으로 회의 품질을 판단하기 어렵습니다. Slack도 메시지와 워크스페이스 연결 외에 파일·이미지 전송, 알림을 위한 연결을 사용할 수 있습니다. 따라서 도메인 목록을 무작정 복사하기보다, 실제 사용 중인 앱 버전과 Clash 연결 로그에 나타난 호스트를 기준으로 규칙을 다듬는 것이 안전합니다.
이 가이드는 Clash Verge Rev와 Mihomo 호환 클라이언트를 중심으로 설명하지만, 규칙 모드를 제공하는 다른 Clash 계열 앱에도 원칙을 적용할 수 있습니다. 메뉴 이름과 설정 위치는 클라이언트 버전에 따라 다를 수 있으므로, 먼저 활성 프로필과 코어 종류를 확인하세요. 또한 회사에서 승인한 네트워크 정책이나 VPN이 있다면 개인 프록시 규칙을 추가하기 전에 해당 정책을 우선 확인해야 합니다.
노드와 라우팅 정책을 업무 방식에 맞추기
노드를 고를 때는 목록에 표시된 지연 시간만 보지 말고, 회의 시간대에 실제로 안정적인지 살펴야 합니다. 노드 검사에서 낮은 지연이 나오더라도 부하가 높은 시간에는 패킷 손실이나 속도 저하가 생길 수 있습니다. 업무용으로 사용할 후보를 두세 개 정한 뒤, 같은 네트워크와 비슷한 시간대에 Zoom 테스트 회의와 Slack 파일 전송을 각각 실행해 비교하세요. 특정 지역 노드가 더 가깝다는 이유만으로 품질을 단정하지 말고, 음성 지연·화면 공유의 부드러움·파일 전송 완료 여부를 함께 기록하는 편이 좋습니다.
| 대상 트래픽 | 권장 출구 | 확인할 점 |
|---|---|---|
| Zoom 회의·로그인 | 안정적인 업무용 프록시 그룹 | 회의 입장, 음성, 화면 공유를 각각 테스트 |
| Slack 메시지·파일 | 업무용 프록시 그룹 또는 정책에 맞는 직접 연결 | 워크스페이스 연결과 파일 업로드가 같은 정책을 타는지 확인 |
| 사내 포털·프린터·NAS | DIRECT | 사설 IP와 내부 도메인이 프록시로 빠지지 않게 설정 |
| 일반 웹사이트 | 현재 사용 중인 기본 규칙 | 업무 규칙이 일반 트래픽까지 과도하게 덮지 않는지 확인 |
규칙을 추가할 때는 먼저 클라이언트의 연결 로그에서 Zoom과 Slack을 실행하며 실제 호스트를 확인합니다. 앱이 사용하는 도메인은 기능, 리전, 버전에 따라 달라질 수 있으므로, 특정 도메인 목록이 모든 환경에 적용된다고 가정하지 마세요. 로그에서 확인한 호스트를 도메인 규칙에 반영하고, 기존 구독 규칙이나 규칙 프로바이더가 같은 호스트를 먼저 처리하고 있지 않은지도 확인합니다. 일반적으로 구체적인 도메인 규칙은 마지막의 포괄적인 기본 규칙보다 앞에 있어야 합니다.
아래 예시는 정책 이름을 설명하기 위한 형태입니다. Work-Proxy는 현재 클라이언트에 존재하는 프록시 그룹 이름으로 바꾸고, 도메인은 연결 로그와 서비스의 최신 네트워크 안내를 확인한 뒤 필요한 항목만 넣으세요. 실제 규칙 파일을 수정할 때는 YAML 들여쓰기와 쉼표, 대소문자도 함께 점검해야 합니다.
rules:
- DOMAIN,zoom.us,Work-Proxy
- DOMAIN-SUFFIX,zoom.us,Work-Proxy
- DOMAIN,slack.com,Work-Proxy
- DOMAIN-SUFFIX,slack.com,Work-Proxy
- DOMAIN,192.168.1.1,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,기존-기본-정책이 예시의 도메인 규칙만으로 Zoom의 모든 미디어 서버나 Slack의 모든 파일 전송 호스트가 포함된다고 보장할 수는 없습니다. 로그에 별도 호스트가 나타나면 그 호스트가 해당 서비스의 공식 연결인지 먼저 검토한 다음 규칙에 추가하세요. DOMAIN-KEYWORD처럼 넓게 일치하는 규칙은 관계없는 서비스까지 프록시로 보낼 수 있으므로, 특별한 이유가 없다면 정확한 도메인이나 확인된 접미사를 우선하는 것이 좋습니다. 업무용 프록시가 회사 정책과 충돌하는 환경에서는 해당 앱을 임의로 우회시키지 말고 관리자에게 허용된 경로를 확인하세요.
Clash에서 서비스별 분할 라우팅 설정하기
다음 순서는 기존 구독 프로필을 유지하면서 Zoom과 Slack의 경로를 확인하는 실습입니다. 화면 명칭은 Clash Verge Rev, Clash Verge 및 다른 Mihomo 기반 클라이언트에서 조금씩 다를 수 있습니다. 구독 YAML을 직접 편집하는 경우에는 제공자가 갱신할 때 로컬 변경 사항이 덮어써질 수 있으므로, 가능하다면 클라이언트의 사용자 규칙 또는 별도 오버라이드 기능을 사용하세요. 변경 전에는 현재 프로필을 내보내거나 복사해 두면 오류가 생겼을 때 빠르게 되돌릴 수 있습니다.
- 활성 프로필을 확인합니다. Clash 클라이언트에서 현재 선택된 프로필과 코어 상태를 살펴봅니다. 구독 갱신 직후라면 노드 그룹 이름이나 규칙 프로바이더가 바뀌었을 수 있으니, 수정하려는 설정이 현재 실행 중인 프로필에 적용되는지 확인하세요.
- 업무용 프록시 그룹을 선택합니다. 기존 그룹 가운데 회의 시간대에 안정적인 노드를 선택하거나, 클라이언트가 지원한다면 업무용 그룹을 만듭니다. 그룹 이름을 규칙에 쓸 때는 대소문자와 띄어쓰기를 설정 파일에 표시된 이름과 정확히 맞춰야 합니다.
- 실제 연결 호스트를 수집합니다. 연결 로그를 열고 Zoom 회의에 입장하거나 Slack에서 메시지와 파일을 보내 봅니다. 이때 나타나는 호스트와 현재 선택된 정책을 기록합니다. 처음부터 많은 도메인을 한꺼번에 추가하면 어느 규칙이 효과가 있었는지 찾기 어려워집니다.
- 구체적인 서비스 규칙을 기본 규칙보다 앞에 둡니다. 확인된 호스트만 업무용 그룹에 연결하고, 사내 IP와 내부 도메인은 DIRECT로 유지합니다. 규칙 순서는 중요합니다. 포괄적인
MATCH나 넓은 규칙이 먼저 일치하면 뒤에 추가한 세부 규칙이 실행되지 않을 수 있습니다. - 설정을 검증하고 기록합니다. 설정 검증 기능이 있으면 먼저 실행하고, 오류가 없다면 프로필을 다시 불러오거나 코어를 재시작합니다. 이후 로그에서 각 호스트가 의도한 그룹을 타는지 확인합니다. 회의 중간에 광범위한 규칙을 수정하기보다, 회의가 끝난 뒤 한 번에 한 항목씩 바꾸는 것이 원인 파악에 유리합니다.
규칙을 저장한 뒤 Zoom을 열었는데도 로그에 연결이 나타나지 않는다면, 앱이 시스템 프록시를 따르지 않거나 TUN 모드·운영체제 네트워크 설정이 별도 경로를 사용하고 있을 수 있습니다. 이때 무조건 도메인을 더 추가하지 말고 클라이언트가 시스템 프록시를 적용 중인지, TUN이 활성화되어 있는지, Zoom이 회사 VPN이나 별도 보안 프로그램을 거치는지 순서대로 점검하세요. 로그에 연결이 있지만 정책이 예상과 다르면 규칙 순서와 그룹 이름을 우선 확인합니다.
회의 전 점검과 끊김 원인 좁히기
중요한 회의 전에는 먼저 Clash 연결 상태와 선택된 프록시 그룹을 확인합니다. 다음으로 Slack 메시지 전송과 작은 파일 업로드를 테스트해 업무용 서비스가 정상적으로 연결되는지 봅니다. Zoom에서는 테스트 회의나 미리보기 기능을 사용해 마이크, 스피커, 카메라를 점검하고, 가능하면 짧게 화면 공유도 실행합니다. 앱 로그인만 성공한 상태는 미디어 전송까지 정상이라는 뜻이 아니므로, 음성과 영상 경로를 따로 확인해야 합니다.
회의 품질이 나빠졌을 때는 모든 문제를 노드 탓으로 돌리지 않는 것이 중요합니다. Wi-Fi 신호가 약하거나 같은 무선망에서 대용량 다운로드가 진행 중이면 프록시를 바꿔도 끊김이 계속될 수 있습니다. 가능하면 공유기 가까이 이동하거나 유선 연결을 사용하고, 백그라운드 동기화와 대용량 업로드를 잠시 멈춘 뒤 비교하세요. 회사 VPN을 함께 사용 중이라면 VPN과 Clash가 중첩되면서 경로가 길어지거나 정책이 충돌할 수 있으므로, 회사에서 승인한 동작 방식을 확인해야 합니다.
증상이 생긴 시각과 앱을 기록하고, 그 시점의 Clash 연결 로그에서 호스트·규칙·노드가 어떻게 표시되는지 확인하면 원인을 좁히기 쉽습니다. Zoom만 끊기고 Slack은 정상이라면 회의 미디어 경로, UDP 처리, 노드의 실시간 부하를 우선 살펴볼 수 있습니다. 반대로 Slack 메시지는 되지만 파일만 실패한다면 파일 전송에 사용되는 별도 호스트가 기존 규칙에 포함되지 않았을 가능성이 있습니다. 두 앱이 동시에 끊긴다면 Wi-Fi, DNS, 공유기, 로컬 방화벽처럼 공통 경로를 먼저 확인하세요.
Clash 로그에는 업무 도메인과 접속 시각이 남을 수 있고, 구독 URL에는 계정 정보가 포함될 수 있습니다. 문제를 공유할 때는 로그 전체를 공개 게시판에 올리지 말고 사용자 이름, 내부 호스트, 토큰, 구독 주소를 가리세요. 업무용 기기에서 회사 데이터가 포함된 연결 정보를 저장하거나 외부로 전달해도 되는지 조직의 보안 기준을 확인하는 것도 필요합니다. 네트워크 정책이 불명확하면 개인 규칙으로 우회하기보다 IT 담당자에게 Zoom·Slack에 허용된 프록시 경로를 문의하는 편이 안전합니다.
모든 트래픽을 글로벌 프록시로 보내는 방식은 처음에는 간단하지만, 사내 포털과 로컬 장치까지 원치 않는 경로로 보낼 수 있고 원인을 구분하기도 어렵습니다. 반대로 프록시 설정을 지원하지 않는 일부 앱은 단순한 시스템 프록시 전환만으로 예상한 경로를 타지 않을 수 있습니다. Clash의 규칙 라우팅을 사용하면 Zoom·Slack과 직접 연결할 내부 트래픽을 나눠 관리하고, 연결 로그로 실제 정책 적용 여부를 확인할 수 있습니다. 여러 앱을 각기 다른 도구로 관리하며 경로를 추측하는 대신, 한 프로필에서 규칙과 노드를 점검하고 싶다면 Clash 클라이언트를 살펴볼 수 있습니다.