이 글이 필요한 원격근무 상황
원격근무용 Clash 설정을 찾는 분들은 보통 인터넷이 완전히 끊긴 상황보다, 업무 앱마다 연결 품질이 다르게 나타나는 문제를 겪습니다. 예를 들어 웹 브라우저로 국내 포털과 사내 그룹웨어는 잘 열리는데 Zoom 회의에서 음성이 끊기거나, Slack 메시지가 늦게 도착하고 파일 업로드가 반복해서 실패할 수 있습니다. Google Meet은 회의에 들어가도 카메라가 늦게 켜지거나 화면 공유가 검은색으로 표시되는 식의 증상이 나타납니다.
이런 현상은 단순히 노드가 느려서만 발생하지 않습니다. 화상회의는 짧은 지연 시간과 안정적인 UDP·TCP 흐름이 중요하고, 협업 메신저는 로그인·웹소켓·파일 저장소 등 여러 도메인을 동시에 사용합니다. 반면 국내 웹서비스와 사내 시스템은 가까운 회선으로 직접 연결하는 편이 빠르고, 회사 보안 정책상 외부 프록시를 거치면 인증이 실패할 수도 있습니다. 따라서 모든 트래픽을 한 노드로 보내는 글로벌 모드보다 업무 서비스별 분할 라우팅이 원격근무 환경에 더 잘 맞는 경우가 많습니다.
이 글에서는 Clash Verge Rev 또는 Mihomo 계열 클라이언트를 기준으로 Zoom·Slack·Google Meet을 별도 정책 그룹에 연결하고, 국내 서비스와 사내 주소는 직접 연결하는 기본 설계를 설명합니다. 메뉴 이름은 클라이언트와 버전에 따라 조금 다를 수 있지만, 프로필 활성화, 규칙 모드, 연결 로그, TUN 또는 시스템 프록시라는 핵심 개념은 대부분 동일합니다. 회사 네트워크의 이용 약관과 보안 정책을 먼저 확인하고, 업무 데이터가 허가되지 않은 경로로 전송되지 않도록 주의하세요.
화상회의와 협업 도구를 나누어 보내는 원칙
원격근무 구성에서 가장 먼저 정해야 할 것은 “어떤 앱을 프록시로 보낼 것인가”가 아니라 어떤 트래픽에 어떤 품질이 필요한가입니다. 회의 중에는 수십 밀리초의 추가 지연보다 순간적인 패킷 손실과 경로 변경이 더 큰 문제를 만들 수 있습니다. 회의가 시작된 뒤 노드가 자동으로 바뀌면 상대방 목소리가 끊기거나 화면 공유가 멈출 수 있으므로, 회의 서비스에는 자동 선택 그룹보다 안정성을 우선한 고정 그룹을 배정하는 편이 좋습니다.
| 업무 트래픽 | 권장 경로 | 중요하게 볼 지표 | 주의할 점 |
|---|---|---|---|
| Zoom 회의 | 안정성 우선 프록시 그룹 | 지연 시간, 패킷 손실, 장시간 연결 유지 | 회의 중 자동 노드 변경과 과도한 TUN 규칙을 피함 |
| Slack 메시지·웹소켓 | 업무용 프록시 또는 안정적인 기본 그룹 | 로그인, 웹소켓 재연결, 파일 업로드 | 메시지 도메인과 파일 저장소 도메인이 다를 수 있음 |
| Google Meet | 화상회의용 그룹 | 카메라·마이크 연결, 화면 공유, 스트리밍 지속성 | 브라우저와 데스크톱 앱의 프록시 적용 범위가 다를 수 있음 |
| 국내 웹·사내 시스템 | DIRECT 또는 회사가 지정한 경로 |
접속 속도, 사내 인증, 내부 DNS | 사내 도메인과 사설 IP를 프록시로 보내지 않음 |
서비스 도메인을 너무 넓게 묶는 것도 피해야 합니다. 예를 들어 DOMAIN-SUFFIX,google.com 하나로 모든 Google 트래픽을 처리하면 Meet뿐 아니라 개인 Gmail, Drive, 개발 도구까지 같은 그룹으로 이동할 수 있습니다. 반대로 공식 문서나 연결 로그에 나타난 실제 호스트를 확인하지 않고 DOMAIN-KEYWORD,zoom처럼 넓은 키워드만 넣으면 업데이트 서버, 광고 리소스, 다른 서비스가 잘못 매칭될 수 있습니다. 도메인 규칙은 좁게 시작하고 로그를 보며 보완하는 방식이 안전합니다.
또한 화상회의의 모든 패킷이 반드시 하나의 대표 도메인으로만 표시되는 것은 아닙니다. 로그인, 회의 제어, 미디어 릴레이, 업데이트가 서로 다른 호스트를 사용할 수 있고, 지역이나 계정 유형에 따라 엔드포인트가 달라질 수 있습니다. 따라서 규칙을 작성한 뒤 실제 회의에 입장해 Clash의 연결 기록에서 호스트와 최종 정책 그룹을 확인해야 합니다.
Clash에서 원격근무 분할 라우팅 설정하기
이제 실제 설정 순서를 진행해 보겠습니다. 아래 절차는 특정 구독 제공자의 YAML을 그대로 복사하는 방법이 아니라, 현재 사용 중인 프로필에 업무용 정책을 추가하고 검증하는 흐름입니다. 이미 공급자가 규칙을 자동으로 관리하는 구독을 제공한다면, 직접 수정한 값이 다음 업데이트에서 덮어써질 수 있으므로 로컬 오버라이드나 별도 규칙 프로바이더를 지원하는지 먼저 확인하세요.
1단계: 활성 프로필과 프록시 그룹 확인
Clash 클라이언트를 열고 현재 활성화된 프로필을 확인합니다. 프로필이 정상적으로 파싱되었는지, 코어가 재시작을 반복하지 않는지, 프록시 그룹에 실제 노드가 표시되는지를 먼저 봅니다. 회의용으로는 이름만 보고 가장 빠른 노드를 고르기보다, 평소 업무 시간에 연결이 오래 유지되는 노드를 선택해야 합니다. 짧은 속도 측정 결과가 좋아도 장시간 스트리밍이나 웹소켓에서 불안정할 수 있기 때문입니다.
가능하다면 다음과 같이 역할을 나누어 둡니다. WORK-MEETING은 Zoom과 Meet용 안정성 우선 그룹, WORK-CHAT은 Slack과 협업 도구용 그룹, DIRECT는 국내 웹서비스와 사내 시스템용입니다. 두 프록시 그룹을 반드시 서로 다른 노드로 만들 필요는 없지만, 회의 중 노드가 바뀌지 않도록 선택 방식과 장애 전환 옵션을 확인하세요. 자동 선택을 사용한다면 지연 시간뿐 아니라 실패율과 유지 시간을 함께 고려하는 설정이 적절합니다.
2단계: 업무 도메인 규칙 추가
규칙 모드에서 업무 서비스의 도메인을 먼저 배치하고, 그 아래에 국내 서비스와 사내 네트워크 예외를 배치합니다. 정확한 도메인은 클라이언트 로그와 서비스 관리자가 제공한 문서를 기준으로 정해야 합니다. 예시 구조는 다음과 같으며, 실제 호스트와 그룹 이름은 자신의 환경에 맞게 바꾸어야 합니다.
rules:
- DOMAIN-SUFFIX,zoom.us,WORK-MEETING
- DOMAIN-SUFFIX,zoom.com,WORK-MEETING
- DOMAIN-SUFFIX,slack.com,WORK-CHAT
- DOMAIN-SUFFIX,googleapis.com,WORK-MEETING
- DOMAIN-SUFFIX,meet.google.com,WORK-MEETING
- DOMAIN-SUFFIX,company.example,DIRECT
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,KR,DIRECT
- MATCH,PROXY위 예시는 이해를 위한 틀입니다. googleapis.com 전체를 회의용 그룹으로 보내면 Meet 이외의 Google API와 개인 개발 트래픽까지 포함될 수 있으므로, 연결 기록을 보고 범위를 줄이는 것이 좋습니다. 사내 도메인을 DIRECT로 지정할 때도 회사 VPN이나 보안 게이트웨이를 반드시 거쳐야 하는 구조라면 임의로 직접 연결하지 말고 IT 부서의 경로를 따르세요.
3단계: 시스템 프록시·TUN 적용 범위 조정
브라우저에서 Meet이 정상이라고 해서 Slack 데스크톱 앱과 Zoom이 같은 경로를 사용한다고 단정할 수 없습니다. 시스템 프록시는 HTTP·HTTPS를 지원하는 앱에 적용되지만, 일부 데스크톱 앱은 자체 네트워크 설정을 사용하거나 UDP 미디어를 별도로 처리합니다. 이때 Clash의 TUN 모드가 도움이 될 수 있지만, 모든 트래픽을 가상 인터페이스로 밀어 넣으면 사내 VPN, 프린터, NAS, 로컬 개발 서버가 영향을 받을 수 있습니다.
TUN을 켜기 전에는 먼저 시스템 프록시만으로 증상을 재현하고, 적용되지 않는 앱이 있는지 확인합니다. Zoom 회의에서 문제가 계속되면 TUN을 잠시 활성화한 뒤 권한 요청을 승인하고, 연결 로그에서 회의 시작과 화면 공유 시점의 트래픽이 예상 그룹에 도달하는지 확인합니다. TUN을 사용한 뒤 사내 문서나 프린터가 보이지 않으면 localhost, 사설 IP 대역, 사내 DNS 주소를 예외로 두고 회사 VPN과 충돌하는지 점검해야 합니다.
4단계: 앱별 프록시와 환경 변수 확인
Slack이나 Zoom을 터미널에서 실행하거나, 원격근무 중 개발 도구와 협업 자동화를 함께 사용한다면 셸 환경 변수도 확인해야 합니다. 일부 CLI와 SDK는 Clash의 시스템 프록시를 자동으로 읽지 않고 HTTPS_PROXY나 ALL_PROXY를 직접 요구합니다. 반대로 NO_PROXY가 너무 넓게 설정되어 있으면 업무 도메인이 프록시를 우회할 수 있습니다.
- 브라우저: 운영체제 프록시 또는 브라우저 자체 프록시 설정을 확인합니다.
- Zoom·Slack 데스크톱 앱: 앱 재시작 후 연결 로그에서 새 세션이 생성되는지 확인합니다.
- 개발 도구·CLI:
HTTPS_PROXY,HTTP_PROXY,ALL_PROXY,NO_PROXY의 대소문자와 값을 함께 확인합니다. - 사내 VPN: VPN 연결 전후에 라우팅 테이블과 DNS가 바뀌는지 확인하고, 두 터널을 동시에 사용할 때의 회사 정책을 따릅니다.
설정을 바꾼 뒤에는 앱을 완전히 종료했다가 다시 실행해야 합니다. 이미 열린 웹소켓이나 오래된 DNS 캐시는 새로운 규칙을 즉시 반영하지 않을 수 있습니다. 회의 초대 링크를 클릭했을 때 브라우저는 새 경로를 타지만, 백그라운드에서 실행 중인 Slack은 이전 연결을 유지하는 경우도 있으므로 두 앱을 각각 재시작하는 편이 확실합니다.
회의 전 검증과 장애 발생 시 조정 방법
업무 시작 전에 10분 정도의 점검 시간을 확보하면 실제 고객 미팅 중 문제를 발견하는 일을 줄일 수 있습니다. 먼저 Clash에서 규칙 모드가 활성화되어 있는지 확인하고, 테스트용 브라우저 탭에서 국내 웹사이트와 업무 서비스에 각각 접속합니다. 국내 사이트는 직접 연결로 표시되는지, Zoom·Meet 도메인은 의도한 그룹으로 들어가는지, Slack 로그인과 파일 업로드가 모두 성공하는지 순서대로 봅니다. 단순히 첫 화면이 뜨는 것보다 로그인 유지와 파일 전송까지 확인해야 합니다.
화상회의는 음성만 연결한 상태, 카메라를 켠 상태, 화면 공유를 시작한 상태를 각각 테스트하세요. 세 단계에서 사용하는 연결이 다를 수 있기 때문입니다. 회의 중 화면이 멈췄다면 즉시 노드를 여러 번 바꾸기보다, 먼저 연결 로그의 마지막 이벤트를 확인합니다. 특정 호스트가 DIRECT로 빠졌다면 규칙 순서나 도메인 범위를 수정하고, 같은 그룹에서 연결이 반복해서 끊겼다면 다른 노드로 바꾼 뒤 다시 테스트합니다.
노드 선택은 한 번의 속도 측정만으로 결정하지 않는 것이 좋습니다. 원격근무에서는 출근 시간과 점심시간처럼 혼잡한 시간대의 품질이 중요합니다. 5분 정도의 짧은 테스트를 여러 번 진행하면서 지연 시간의 편차, 패킷 손실, 연결 재설정 횟수, 화면 공유 중 음성 지연을 기록하세요. 평균 지연이 조금 높더라도 편차가 작고 연결이 지속되는 노드가 실제 회의에는 더 적합할 수 있습니다.
DNS 설정도 함께 살펴봐야 합니다. 도메인은 프록시로 보내면서 DNS 질의만 지역 회선으로 나가면 잘못된 주소가 반환되거나, 반대로 사내 도메인을 외부 DNS로 질의해 내부 서비스가 열리지 않을 수 있습니다. Clash의 DNS 모드와 fake-IP 또는 redir-host 사용 여부를 확인하고, 회사가 지정한 내부 DNS가 있다면 예외 처리를 적용합니다. DNS를 바꾼 직후에는 브라우저와 운영체제의 캐시를 비우고 앱을 다시 시작해야 결과를 정확히 비교할 수 있습니다.
보안과 유지 관리까지 포함한 운영 기준
원격근무 프로필에는 개인적인 웹 사용과 회사 업무 트래픽이 함께 섞이기 쉽습니다. 따라서 업무용 그룹을 만들 때 회사 계정, 고객 자료, 내부 저장소가 어떤 경로를 거치는지 팀 정책에 맞게 확인해야 합니다. 프록시 제공자가 연결 메타데이터를 어떻게 처리하는지, 회사에서 외부 VPN이나 개인 프록시 사용을 허용하는지, 민감한 문서가 제3자 노드를 통과해도 되는지를 먼저 검토하세요. Clash는 라우팅 도구이지 보안 심사를 대신하는 장치가 아닙니다.
구독 프로필이 자동 갱신될 때는 규칙 우선순위와 프록시 그룹 이름이 바뀔 수 있습니다. 업데이트 후에는 회의 서비스, Slack 파일 전송, 사내 시스템을 다시 확인하고, 직접 작성한 규칙이 사라지지 않았는지 봅니다. 가능하면 원본 구독을 직접 편집하기보다 오버라이드나 규칙 프로바이더를 사용해 변경 내용을 분리하세요. 그래야 구독 갱신으로 기본 설정이 바뀌어도 업무용 예외를 다시 만들 필요가 줄어듭니다.
또한 노드 목록을 지나치게 크게 유지하면 자동 선택이 판단해야 할 후보가 많아지고, 품질이 낮은 노드가 회의 중 선택될 가능성도 커집니다. 실제 업무 시간에 안정적인 후보를 몇 개 남기고, 한 달에 한 번 정도 회의 테스트를 진행해 오래된 노드를 정리하세요. 앱과 Mihomo 코어를 업데이트할 때는 바로 업무용 컴퓨터 전체에 적용하지 말고, 여유가 있는 기기에서 먼저 TUN 권한, DNS 동작, 시스템 프록시 연동을 확인한 뒤 배포하는 편이 안전합니다.
일부 무료 VPN이나 단순 브라우저 확장 프로그램은 특정 웹페이지를 여는 데는 편하지만, Zoom·Slack·Meet처럼 여러 연결과 장시간 세션을 동시에 처리할 때 경로 제어가 제한적이고 앱별 예외를 관리하기 어렵습니다. 반면 Clash는 규칙 로그로 실제 매칭 결과를 확인하고, 국내 서비스는 직접 연결하면서 회의와 협업 트래픽만 별도 그룹으로 보낼 수 있어 원격근무 흐름을 세밀하게 조정할 수 있습니다. 이런 식으로 서비스별 경로와 기기별 적용 범위를 직접 관리하고 싶다면, 사용 중인 운영체제에 맞는 Clash 클라이언트를 내려받아 이 글의 규칙과 검증 절차를 차례로 적용해 보세요.