재택근무용 Clash 설정법: Zoom·Google Meet 연결 최적화

재택근무에서 Clash 분할 라우팅이 필요한 이유

재택근무 환경에서는 화상회의, 메신저, 사내 그룹웨어, 문서 저장소, 일반 웹 서비스가 동시에 실행됩니다. 이때 모든 트래픽을 하나의 프록시 노드로 보내면 접속은 되더라도 지연 시간이 커지고, 회의 음성이 끊기거나 화면 공유가 늦게 반응할 수 있습니다. 반대로 모든 연결을 직접 연결하면 국내 업무 사이트는 빠르지만 Zoom이나 Google Meet 같은 서비스가 현재 네트워크에서 불안정해질 수 있습니다.

Clash의 Rule 모드와 정책 그룹을 사용하면 서비스별로 연결 방식을 나눌 수 있습니다. 국내 업무 사이트와 사내 시스템은 DIRECT로 보내고, 해외 화상회의 도메인이나 회사에서 지정한 원격 업무 서비스는 안정적인 프록시 그룹으로 보낼 수 있습니다. 중요한 점은 무조건 프록시를 많이 사용하는 것이 아니라, 회의 품질에 영향을 주는 도메인만 선별하고 나머지 트래픽은 가능한 한 단순하게 유지하는 것입니다.

이 글에서는 Clash Verge Rev, Mihomo 기반 클라이언트, Clash for Android 등에서 공통으로 적용할 수 있는 원칙을 설명합니다. 메뉴 이름은 클라이언트마다 조금 다를 수 있지만 프로파일, DNS, 프록시 그룹, 규칙, 로그를 확인하는 흐름은 거의 같습니다.

설정 전 확인할 항목

기존에 다른 VPN이나 프록시 프로그램을 사용하고 있다면 설정 전에 잠시 종료하는 편이 좋습니다. 두 프로그램이 동시에 시스템 프록시나 TUN 인터페이스를 제어하면 연결이 무작위로 끊기거나 DNS 응답이 서로 달라질 수 있습니다. 특히 회사 VPN이 사내 주소에 접근하기 위해 별도의 가상 어댑터를 사용하는 경우에는 Clash TUN을 바로 켜기보다, 먼저 시스템 프록시 방식으로 필요한 서비스가 작동하는지 확인하세요.

1단계: 프로파일을 불러오고 Rule 모드 선택

Clash를 실행한 뒤 Profiles 또는 프로파일 메뉴에서 구독 URL을 추가합니다. URL을 붙여 넣고 업데이트를 실행하면 설정 파일과 노드 목록이 내려옵니다. 다운로드가 끝난 뒤에는 해당 프로파일을 활성화하고, 설정 파일이 정상적으로 파싱되었는지 확인하세요. 노드가 하나도 표시되지 않으면 URL 형식, 구독 만료 여부, 현재 네트워크에서 제공업체 도메인에 접근 가능한지를 먼저 점검해야 합니다.

1. 프로파일 화면에서 새 구독 URL을 등록합니다.
2. 업데이트 또는 다운로드를 실행해 설정 파일을 가져옵니다.
3. 새로 받은 프로파일을 활성화합니다.
4. Proxy 화면에서 지연 시간이 낮고 최근 테스트가 성공한 노드를 선택합니다.
5. 작동 모드를 Rule로 바꾼 뒤 시스템 프록시를 켭니다.

Global 모드는 문제를 빠르게 분리할 때 유용하지만 재택근무의 기본 모드로는 적합하지 않은 경우가 많습니다. 모든 연결이 한 노드에 집중되므로 국내 업무 사이트까지 우회하고, 회의 중 백그라운드 업데이트나 클라우드 동기화가 노드의 대역폭을 차지할 수 있습니다. 초기 테스트에서 Global 모드로 회의가 정상 작동한다면 노드 자체는 살아 있다는 뜻이며, 이후 Rule 모드에서 특정 도메인이나 DNS 규칙을 확인하면 됩니다.

2단계: 화상회의용 프록시 그룹 구성

회의용 정책 그룹은 단순히 가장 빠른 노드를 고르는 것보다 안정성, 지연 시간, 업로드 품질을 함께 고려해야 합니다. 영상회의에서는 다운로드 속도만 높다고 좋은 결과가 나오지 않습니다. 음성 데이터가 일정한 간격으로 전달되어야 하고, 화면 공유에서는 업로드가 지속적으로 유지되어야 하기 때문입니다.

일부 구독 설정에는 이미 Proxy, Auto, Global Media와 같은 그룹이 포함되어 있습니다. 이 경우 기존 그룹을 그대로 사용해도 되지만, 회의와 스트리밍을 하나의 그룹으로 묶으면 회의 중 노드가 자동으로 바뀌어 세션이 끊길 수 있습니다. 회의용 그룹은 가능하면 수동 선택으로 두고, 회의 시작 전에 한 번 연결을 테스트하는 방식을 권장합니다.

노드 지연 시간은 참고값일 뿐 절대적인 품질 점수가 아닙니다. 측정 서버와 실제 Zoom 또는 Meet 서버의 경로가 다를 수 있으므로, 20ms 노드가 항상 80ms 노드보다 회의 품질이 좋은 것은 아닙니다. 실제 회의 테스트에서 음성 지연, 화면 공유 반응, 연결 재협상 여부를 함께 확인하세요.

3단계: Zoom과 Google Meet 규칙 작성

규칙은 위에서 아래로 평가되는 경우가 많으므로, 회의 서비스처럼 우선 처리해야 하는 규칙을 일반적인 해외 규칙보다 위에 배치해야 합니다. 구독 설정에 이미 서비스 규칙이 있다면 중복으로 추가하지 말고, 실제 Connections 또는 Logs 화면에서 어떤 정책 그룹으로 매칭되는지 확인하는 편이 안전합니다.

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK-MEETING
  - DOMAIN-SUFFIX,zoom.com,WORK-MEETING
  - DOMAIN-SUFFIX,google.com,WORK-MEETING
  - DOMAIN-SUFFIX,meet.google.com,WORK-MEETING
  - DOMAIN-SUFFIX,googlevideo.com,WORK-MEETING
  - DOMAIN-SUFFIX,회사-그룹웨어.example,DIRECT
  - GEOIP,CN,WORK-DIRECT
  - MATCH,PROXY-AUTO

위 예시는 구조를 이해하기 위한 기본 형태입니다. 실제 설정에서는 제공업체가 관리하는 규칙 제공자와 충돌할 수 있으므로 도메인을 무작정 추가하지 마세요. Google Meet은 회의 페이지뿐 아니라 인증, 정적 리소스, 미디어 전송에 여러 Google 도메인을 사용할 수 있습니다. Zoom도 로그인과 회의 연결에 서로 다른 호스트를 사용할 수 있으므로, 회의가 열리지만 음성이나 화면 공유만 실패한다면 Connections에서 실제 요청 도메인을 확인한 뒤 필요한 항목을 보완해야 합니다.

국내 업무 사이트는 DIRECT로 지정하되, 회사가 해외 클라우드나 별도의 보안 게이트웨이를 사용하는 경우에는 예외가 있습니다. 사내 시스템의 로그인 페이지가 열리지 않는다면 해당 도메인을 곧바로 프록시로 보내기보다 회사 VPN이 요구하는 DNS과 라우팅을 먼저 확인하세요. 잘못된 예외 규칙 하나가 사내 인증 흐름 전체를 망가뜨릴 수 있습니다.

4단계: DNS와 TUN을 회의 환경에 맞게 조정

화상회의 문제를 노드 속도 탓으로만 생각하기 쉽지만 실제로는 DNS 응답이 느리거나, 운영체제와 브라우저가 Clash를 거치지 않고 별도의 DNS를 사용하는 경우도 많습니다. 회의 페이지는 열리는데 음성이 연결되지 않거나, 로그인 화면이 반복해서 나타난다면 DNS와 규칙이 서로 다른 경로를 사용하는지 확인하세요.

Mihomo 계열 설정에서는 fake-ip와 redir-host 중 하나를 선택할 수 있습니다. fake-ip는 도메인 기반 규칙을 일관되게 적용하기 쉽고 많은 앱을 한 흐름으로 관리하는 데 유리합니다. 다만 일부 사내 프로그램, 게임, 보안 솔루션은 실제 IP 응답을 요구할 수 있어 예외 목록이 필요할 수 있습니다. redir-host는 호환성 확인이 쉬운 대신 앱에 따라 DNS 요청이 분리되거나 규칙 적용이 덜 직관적으로 보일 수 있습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fallback:
    - https://dns.google/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'company.internal'

이 설정은 예시일 뿐이며 회사 네트워크 정책에 맞게 조정해야 합니다. 로컬 프린터, NAS, 사내 도메인처럼 내부 DNS가 필요한 주소는 fake-ip-filter나 nameserver-policy로 예외 처리할 수 있습니다. 예외 목록을 무리하게 넓히면 DNS가 외부로 노출되거나 일부 요청이 예상하지 않은 경로로 빠질 수 있으므로, 실제로 필요한 도메인만 추가하세요.

TUN 모드는 시스템 프록시를 무시하는 프로그램까지 Clash가 처리하도록 도와줍니다. 그러나 회사 VPN, 보안 에이전트, 다른 가상 네트워크 어댑터와 동시에 사용하면 충돌 가능성이 높습니다. 먼저 시스템 프록시로 브라우저와 회의 앱을 테스트하고, 프록시를 지원하지 않는 앱이 꼭 필요할 때만 TUN을 켜는 순서가 안전합니다.

5단계: 회의 전 품질 테스트와 장애 점검

설정을 마친 뒤에는 실제 회의 직전에 한 번 테스트하세요. 브라우저에서 Google Meet의 미리보기 화면을 열고 카메라와 마이크 권한을 확인한 다음, 화면 공유를 시작해 보세요. Zoom도 테스트 회의나 오디오 설정 화면에서 스피커, 마이크, 카메라를 차례로 확인합니다. 이때 연결이 되는지만 보지 말고 음성의 끊김, 화면 공유의 지연, 카메라 해상도 자동 하락 여부를 관찰해야 합니다.

1. Clash의 시스템 프록시 또는 필요한 경우 TUN을 활성화합니다.
2. 회의용 정책 그룹에서 테스트에 성공한 노드를 수동으로 선택합니다.
3. 브라우저와 회의 앱을 완전히 종료한 뒤 다시 실행합니다.
4. Connections에서 로그인, 신호, 미디어 관련 연결이 차단되지 않는지 확인합니다.
5. 5분 이상 음성 및 화면 공유를 유지하면서 지연과 끊김을 기록합니다.

회의 중 갑자기 소리가 끊겼다면 노드를 연속으로 여러 번 바꾸지 마세요. 노드 전환 과정에서 세션이 다시 협상되므로 오히려 복구가 늦어질 수 있습니다. 먼저 현재 노드의 로그에 timeout, connection reset, handshake failed가 반복되는지 확인하고, 문제가 노드에 있다면 회의가 잠시 멈추는 것을 감수하고 안정성이 검증된 다른 노드로 한 번만 전환하세요.

안정적인 재택근무 운영 방법

한 번 작동한 설정도 구독 업데이트, 노드 만료, 회사 네트워크 변경에 따라 결과가 달라질 수 있습니다. 그래서 회의가 있는 날에는 구독을 바로 업데이트하기보다, 평소에 노드와 규칙을 점검하고 업무 시작 전에 현재 선택된 정책 그룹을 확인하는 습관이 좋습니다. 구독 업데이트 직후에는 기존에 잘 되던 노드 이름이 바뀌거나 규칙 제공자의 우선순위가 변경될 수 있으므로, 중요한 회의 직전에 자동 업데이트를 실행하지 않는 편이 안전합니다.

회의용 규칙과 일반 웹 규칙을 분리하면 원인 분석도 쉬워집니다. Zoom과 Google Meet만 문제가 있다면 WORK-MEETING 그룹과 관련 도메인을 확인하고, 사내 사이트만 실패한다면 WORK-DIRECT 및 회사 DNS를 확인하면 됩니다. 모든 사이트가 동시에 실패하면 먼저 시스템 프록시, 포트, TUN, 현재 노드의 생존 여부를 확인하세요. 문제 범위를 작게 나누면 불필요하게 전체 설정을 다시 작성할 필요가 없습니다.

또한 업무용 계정과 개인용 트래픽을 같은 규칙으로 처리하지 않도록 주의해야 합니다. 회사 정책상 특정 서비스는 반드시 회사 VPN을 사용해야 할 수 있고, 개인 회의는 별도 노드를 요구할 수 있습니다. Clash는 세밀한 라우팅을 제공하지만 규칙을 추가한다고 자동으로 보안 정책이 완성되는 것은 아닙니다. 인증서, 접근 권한, 회사의 로그 정책을 확인한 뒤 필요한 범위에서만 적용하세요.

다른 프록시 도구는 빠르게 켜고 끄는 데는 편리하지만, 회의 서비스와 국내 업무 사이트를 세밀하게 나누거나 DNS와 규칙 매칭 과정을 확인하기 어려운 경우가 있습니다. 반면 Clash는 정책 그룹, 도메인 규칙, 로그, TUN과 DNS 설정을 한 흐름으로 조정할 수 있어 재택근무처럼 여러 서비스가 동시에 연결되는 환경에서 원인을 추적하기 쉽습니다. 모든 트래픽을 무조건 우회하지 않고 필요한 연결만 안정적인 노드로 보낼 수 있다는 점도 장점입니다. Zoom과 Google Meet의 연결 품질을 직접 관리하면서 업무 사이트는 빠르게 유지하고 싶다면, 위 원칙에 맞춰 Clash를 구성한 뒤 지금 Clash 받기로 환경에 맞는 클라이언트를 선택해 보세요.