재택근무 회의 트래픽을 나눠야 하는 이유
재택근무 중 Zoom 화면이 멈추거나 Google Meet에서 음성이 끊기고, Slack 메시지가 늦게 도착하면 회의 집중도와 업무 흐름이 함께 떨어집니다. 이런 증상은 회선 속도만으로 설명되지 않습니다. 실제로는 무선 신호 간섭, 순간적인 패킷 손실, 국제 구간의 혼잡, 프록시 노드의 부하, UDP 지원 여부가 복합적으로 작용할 수 있습니다.
Clash의 규칙 기반 분기를 사용하면 화상회의와 업무 메신저 트래픽을 지정한 경로로 보내고, 국내 웹사이트나 사내망은 직접 연결하도록 분리할 수 있습니다. 모든 트래픽을 하나의 노드에 몰아넣지 않으므로 노드가 혼잡할 때도 업무 서비스와 일반 웹 이용의 경로를 따로 조정하기 쉽습니다. 다만 프록시를 통한다고 해서 언제나 지연이 줄어드는 것은 아닙니다. 국내 회의 서버에 직접 연결하는 편이 빠를 수도 있으므로 실제 회의 환경에서 비교해야 합니다.
설정 목표
Zoom·Slack·Google Meet은 안정적인 노드 또는 직접 연결로 분기하고, 국내 웹과 사내 서비스는 필요에 따라 DIRECT로 유지합니다. 각 서비스의 경로를 한 번에 바꾸기보다 하나씩 시험하면 원인을 찾기 쉽습니다.
아래 예시는 Mihomo 코어를 사용하는 Clash Verge Rev 등에서 적용할 수 있는 일반적인 YAML 규칙입니다. 클라이언트에 따라 메뉴 이름은 다를 수 있으며, 구독 프로필이 규칙을 자동 생성한다면 기존 프로필을 백업한 뒤 규칙 편집 기능이나 오버라이드 기능을 사용하세요. 규칙을 직접 수정할 수 없다면 아래 내용을 그대로 붙여 넣기보다 클라이언트의 규칙 관리 화면에서 같은 도메인과 프록시 그룹을 지정하는 방식이 안전합니다.
1회의용 노드와 분기 기준 준비
먼저 현재 사용하는 노드 중 회의에 적합한 후보를 두세 개 고릅니다. 이름에 국가나 지역이 표시된다는 이유만으로 결정하지 말고, 실제 근무 장소에서 지연 시간과 패킷 손실을 확인하세요. 회의 상대가 한국에 있다면 가까운 지역의 노드나 DIRECT가 유리할 수 있고, 해외 본사와 장시간 회의한다면 상대 서버에 가까운 노드가 더 안정적일 수 있습니다. 노드 선택은 국가명보다 회의 시간대의 품질과 UDP 지원 여부를 우선합니다.
- 회의 전용 그룹: 지연이 낮고 연결이 안정적인 노드만 넣습니다. 여러 노드를 자동 선택하는 그룹을 쓸 경우, 자동 검사 결과만 믿지 말고 실제 회의 통화도 시험합니다.
- 메신저 경로: Slack은 지속 연결을 사용하므로 회의 중 노드가 자주 바뀌지 않는 고정 노드가 편리할 수 있습니다.
- 국내 서비스: 국내 사이트, 사내 VPN·포털, 프린터나 로컬 장치는 환경에 따라 DIRECT 또는 별도 사내망 규칙으로 둡니다.
- 그룹 이름: 아래 예시의
Work-Proxy는 자리표시자입니다. 설정에 실제로 존재하는 프록시 그룹 이름과 정확히 일치하도록 바꾸세요.
적용 전 확인
규칙의 대상 그룹이 설정에 없으면 프로필 오류가 발생하거나 규칙이 적용되지 않을 수 있습니다. 원본 설정을 백업하고, 기존 규칙보다 위쪽에 추가한 다음 설정 검증을 진행하세요.
회의 서비스 전체를 무조건 프록시로 보내는 것이 정답은 아닙니다. 먼저 기존 연결 상태를 기록한 후 한 서비스만 분기해 비교하면 어느 경로에서 개선 또는 악화가 발생했는지 구분할 수 있습니다. 업무용 네트워크 정책이 있는 회사 기기라면 임의로 우회하지 말고 조직의 보안 담당자와 허용 범위를 확인하세요.
2Zoom·Slack·Google Meet 규칙 추가
다음 예시는 주요 서비스 도메인을 회의용 그룹으로 보내는 기본 형태입니다. rules 목록에서 도메인 규칙은 마지막의 포괄 규칙인 MATCH보다 앞에 있어야 합니다. 이미 프로필에 서비스별 규칙이 있다면 중복으로 추가하지 말고, 기존 대상 그룹을 확인해 필요한 부분만 조정하세요.
Work-Proxy를 현재 설정에 있는 그룹 이름으로 바꾼 뒤, YAML의 rules 목록에 추가합니다.
※ 도메인 목록은 서비스 구성과 업데이트에 따라 달라질 수 있습니다. 필요한 도메인이 누락되면 Clash의 연결 기록에서 실제 요청을 확인하고, 확인한 항목만 추가하세요.
도메인 규칙은 애플리케이션의 모든 통신을 완벽하게 식별하지 못할 수 있습니다. 특히 Google 서비스는 여러 제품이 도메인을 공유할 수 있어 google.com 전체를 회의용 그룹으로 보내면 Gmail이나 다른 서비스까지 같은 경로를 탈 수 있습니다. 위 예시처럼 회의에 필요한 범위부터 적용하고, 기록에서 실제 연결 대상과 매칭된 규칙을 확인하세요. 규칙이 넓어져 국내 Google 서비스의 속도가 떨어진다면 대상 범위를 줄이거나 서비스별 프로필을 검토합니다.
국내 회의에서 DIRECT가 더 빠른 환경이라면 회의 규칙의 대상 그룹을 DIRECT로 바꿔 비교할 수 있습니다. 반대로 해외 상대와의 회의에서 직접 연결이 불안정하면 안정적인 고정 노드 그룹을 사용합니다. 규칙 하나를 변경한 뒤 연결을 새로 맺어 결과를 확인하세요. 기존 회의 세션은 경로 변경 후에도 잠시 유지될 수 있으므로 앱을 재연결하거나 새 테스트 회의를 시작하는 것이 좋습니다.
규칙 순서 점검
서비스별 도메인 규칙을 일반적인 지역 규칙이나 MATCH보다 위에 두세요. 너무 아래에 배치하면 앞선 규칙이 먼저 적용되어 회의용 그룹에 도달하지 못할 수 있습니다.
3TUN·UDP·DNS 설정 확인
브라우저에서는 프록시가 작동하지만 데스크톱 Zoom이나 Meet 앱은 다른 경로로 연결되는 경우가 있습니다. 시스템 프록시만으로 모든 앱 트래픽이 포착되지 않는 환경이라면 Mihomo 기반 클라이언트에서 TUN 모드를 시험할 수 있습니다. TUN은 시스템의 IP 트래픽을 가상 인터페이스로 전달하는 기능이므로, 켠 뒤에는 관리자 권한, 가상 네트워크 어댑터, DNS 동작 및 사내 보안 프로그램과의 충돌 여부를 확인해야 합니다.
- UDP 지원: 화상회의는 실시간 미디어 전송에 UDP를 활용할 수 있습니다. 사용 중인 노드와 코어가 UDP를 지원하는지 확인하고, 지원하지 않거나 불안정하면 다른 노드 또는 DIRECT와 비교합니다.
- TUN 적용 범위: 데스크톱 앱이 Clash 연결 기록에 나타나지 않을 때만 TUN을 점검합니다. 이미 정상적으로 규칙을 따르고 있다면 불필요하게 설정을 바꿀 이유는 없습니다.
- DNS 일관성: 도메인 조회가 프록시 경로와 어긋나거나 실패하면 연결이 지연될 수 있습니다. Clash의 DNS 기능과 현재 프로필의 DNS 정책을 우선 확인하고, 여러 DNS 설정을 동시에 바꿔 원인을 복잡하게 만들지 마세요.
- 회사 네트워크: 회사 보안 프로그램이나 사내 VPN이 TUN, DNS 또는 UDP를 제한할 수 있습니다. 권한을 우회하기보다 조직의 설정 지침을 따릅니다.
TUN을 켠 뒤 인터넷 연결이 끊기면 먼저 TUN을 끄고 시스템 프록시만 사용하는 이전 상태로 복구하세요. 이어서 클라이언트 로그와 시스템 네트워크 어댑터 상태를 확인하고, 문제가 재현되는 조건을 좁힙니다. DNS를 무작정 공개 DNS 주소로 교체하거나 임의의 포트를 열면 사내 서비스 접근 문제가 생길 수 있으므로, 현재 네트워크와 프로필의 요구 사항을 먼저 살펴보세요.
회의 중 설정 변경 주의
노드를 바꾸거나 TUN·DNS 설정을 변경하면 진행 중인 음성·영상 연결이 끊길 수 있습니다. 변경은 회의가 끝난 뒤 적용하고, 중요한 회의 전에는 짧은 테스트 통화로 확인하세요.
4회의 품질 측정과 문제 해결
설정이 올바른지 판단할 때는 단순한 다운로드 속도보다 회의 중의 지연 변동, 음성 끊김, 재접속 빈도를 살펴야 합니다. 같은 기기와 같은 장소에서 먼저 기존 설정으로 테스트하고, 이후 회의용 규칙을 적용해 비슷한 조건으로 비교합니다. 무선 네트워크의 혼잡도는 시간에 따라 달라질 수 있으므로 한 번의 테스트만으로 노드의 품질을 단정하지 않는 것이 좋습니다.
- 기준 상태 기록: 회의 앱의 연결 통계나 품질 표시에서 지연, 패킷 손실, 음성·영상 끊김을 확인합니다. 공유기와 기기 사이의 Wi-Fi 신호도 함께 점검합니다.
- 규칙 매칭 확인: Clash의 연결 또는 트래픽 기록에서 Zoom·Slack·Meet 요청을 찾아 실제로 어떤 규칙과 그룹이 적용됐는지 확인합니다. 예상한 그룹과 다르면 규칙 순서와 도메인 범위를 점검합니다.
- 경로별 비교: 회의용 노드, 다른 안정적인 노드, DIRECT를 한 번에 하나씩 시험합니다. 여러 항목을 동시에 바꾸지 않아야 무엇이 효과를 냈는지 알 수 있습니다.
- 복구 경로 준비: 회의 중 문제가 생기면 마지막으로 안정적이었던 노드나 DIRECT로 되돌리고, 규칙 변경은 회의가 끝난 뒤 기록을 보며 진행합니다.
Slack만 연결 중 상태로 반복되면 Slack 관련 도메인이 의도한 그룹으로 가는지, 노드가 자주 바뀌지는 않는지 살펴보세요. 메시지 전송은 되지만 알림만 늦는다면 Clash 외에도 운영체제의 알림 권한, 절전 모드, 앱 백그라운드 제한이 원인일 수 있습니다. Zoom에서 영상만 불안정하다면 Wi-Fi 혼잡이나 노드의 UDP 품질을 점검하고, Google Meet에서만 문제가 난다면 연결 기록에서 회의 미디어 요청이 어떤 규칙에 매칭됐는지 확인하는 것이 효율적입니다.
마지막으로 규칙을 적용한 뒤 국내 웹사이트, 사내 포털, 프린터 등 평소 사용하는 서비스가 정상 작동하는지 확인합니다. 업무용 규칙은 회의 품질만 높이는 것이 아니라 다른 서비스에 예상치 못한 영향을 주지 않아야 합니다. 수정한 규칙과 사용한 노드, 테스트 결과를 간단히 기록해 두면 다음 업데이트 때 문제를 빠르게 되돌리거나 재현할 수 있습니다.