원격 협업에서 Clash 분할 라우팅이 필요한 이유

Notion, Figma, Miro를 함께 사용하는 원격 근무 환경에서는 모든 트래픽을 무조건 프록시로 보내는 방식이 항상 좋은 결과를 내지 않습니다. 문서 편집과 디자인 파일 동기화는 여러 해외 API와 정적 자산 서버를 연속해서 호출하지만, 사내 메신저·국내 화상회의·은행 인증처럼 국내에서 직접 연결하는 편이 안정적인 서비스도 많습니다. 하나의 출구로 모든 요청을 처리하면 협업 앱은 열리더라도 파일 업로드가 느려지거나, 국내 서비스의 지연 시간이 불필요하게 늘어날 수 있습니다.

특히 Notion은 화면을 표시하는 웹 호스트와 페이지 데이터, 이미지·첨부 파일 저장소가 서로 다른 이름 공간을 사용할 수 있습니다. Figma는 프로젝트 파일과 폰트, 이미지, 실시간 커서 정보를 별도 연결로 처리하며, Miro는 보드 데이터와 협업 이벤트를 장시간 유지합니다. 브라우저 첫 화면만 확인하고 라우팅이 끝났다고 판단하면 “보드는 열리는데 저장이 늦다”, “Figma 파일은 보이지만 썸네일이 비어 있다”, “Miro 커서가 몇 초 뒤에 움직인다” 같은 문제가 남습니다.

따라서 목표는 필요한 협업 서비스만 같은 프록시 정책으로 묶고, 나머지 국내 트래픽은 DIRECT로 남기는 것입니다. Clash Verge Rev, Clash Verge, Mihomo 기반 클라이언트에서는 연결 로그를 기준으로 실제 호출 호스트를 확인한 다음 규칙을 좁혀 가는 방식이 가장 안전합니다. 알려진 도메인을 처음부터 넓게 추가하기보다, 한 서비스의 로그인·파일 동기화·실시간 협업을 각각 재현하면서 정책을 관찰해야 합니다.

ℹ 먼저 확인할 것: Notion·Figma·Miro에서 문제가 발생한 직후 Clash 연결 로그를 열고 서비스 이름, api, static, cdn, socket 문자열을 검색하세요. 같은 작업에서 프록시와 DIRECT가 섞여 있다면 노드 교체보다 규칙 범위와 순서를 먼저 점검하는 편이 빠릅니다.

Notion·Figma·Miro를 서비스별 이름 공간으로 나누기

세 서비스를 하나의 거대한 해외 도메인 목록으로 관리하면 처음에는 편해 보이지만, 나중에 어떤 규칙이 파일 동기화를 살렸는지 추적하기 어렵습니다. 추천하는 출발점은 서비스별로 관찰 그룹을 나누는 것입니다. 예를 들어 REMOTE_NOTION, REMOTE_FIGMA, REMOTE_MIRO라는 정책 그룹을 만들고, 실제 로그에서 확인한 공식 서비스 도메인만 각각 연결합니다. 그룹 이름은 구독 제공자가 자동으로 생성하는 이름과 겹치지 않게 정해야 프로필 업데이트 뒤에도 구분하기 쉽습니다.

도메인 규칙은 가능한 한 DOMAIN-SUFFIX와 정확한 DOMAIN을 목적에 맞게 사용하세요. 무관한 호스트까지 포함하는 와일드카드나 광범위한 국가 도메인을 넣으면 회사 서비스와 개인 트래픽이 같은 출구로 몰릴 수 있습니다. 도메인 목록을 복사할 때는 검색 결과의 비공식 블로그보다 Clash 로그와 해당 서비스의 공식 문서를 우선해야 하며, 서비스가 CDN을 바꾸면 규칙을 다시 관찰해야 합니다.

세 그룹을 실제로 운영할 때는 모든 서비스에 서로 다른 노드를 무작정 배정하지 않는 것이 좋습니다. Notion은 한 노드, Figma는 다른 노드, Miro는 또 다른 노드로 갈라지면 원격 회의 중 세 세션의 지연과 끊김을 동시에 관리해야 합니다. 초기에는 세 그룹을 하나의 안정적인 REMOTE_WORK 선택 그룹 아래에 두고, 특정 서비스만 문제가 확인될 때 별도 그룹으로 분리하는 방식이 운영 부담을 줄입니다.

Clash 규칙 순서와 원격 협업 정책 설계

Clash 규칙은 위에서 아래로 평가되므로, 협업 서비스의 구체적인 규칙을 일반 규칙보다 위에 배치해야 합니다. 예를 들어 국내 IP를 직접 연결하는 GEOIP,KR,DIRECT를 협업 서비스 규칙보다 먼저 두면, 해외 서비스가 국내 CDN이나 국내 리졸버를 사용한다는 이유만으로 DIRECT에 떨어질 수 있습니다. 반대로 MATCH,PROXY를 너무 위에 두면 마지막 규칙이 모든 요청을 차지해 분할 라우팅의 의미가 사라집니다.

다음은 개념을 확인하기 위한 축약 예시입니다. 실제 호스트는 자신의 연결 로그에서 확인한 값으로 바꾸고, 구독 프로필이 갱신될 때 이 변경 사항이 덮어써지는지도 함께 확인해야 합니다. 

proxy-groups:
  - name: REMOTE_WORK
    type: select
    proxies:
      - WORK_STABLE
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.site,REMOTE_WORK
  - DOMAIN-SUFFIX,notion.so,REMOTE_WORK
  - DOMAIN-SUFFIX,figma.com,REMOTE_WORK
  - DOMAIN-SUFFIX,miro.com,REMOTE_WORK
  - GEOIP,KR,DIRECT
  - MATCH,PROXY

위 예시는 모든 하위 호스트를 정확히 해결한다는 뜻이 아니라 정책의 뼈대를 보여 주기 위한 것입니다. 실제 Figma 파일에서 로그에 나타난 이미지 CDN이 figma.com과 무관한 호스트라면 그 호스트를 관찰한 뒤 별도 규칙으로 추가해야 합니다. 그렇다고 로그에 한 번 보인 모든 제3자 CDN을 영구 등록해서는 안 됩니다. 광고, 분석, 비디오, 폰트 제공자가 섞일 수 있으므로 요청의 목적과 반복성을 확인한 뒤 필요한 범위만 유지하세요.

정책 그룹에는 우선 안정성이 확인된 노드를 넣고, 자동 선택 그룹을 바로 중첩하기보다 테스트 방법을 정해 두는 편이 좋습니다. url-test의 짧은 지연만으로 Figma 업로드나 Miro 장시간 연결의 품질을 판단할 수는 없습니다. ICMP 핑이 빠른 노드가 대용량 업로드와 WebSocket 유지에는 불리할 수 있기 때문입니다. 업무 시간 전에는 작은 Notion 첨부 파일 업로드, Figma 파일 열기, Miro 보드 편집을 차례로 시험하고, 세 작업이 모두 통과한 노드를 기본값으로 선택하세요.

시스템 프록시와 TUN 모드를 함께 사용할 때는 중복 계층도 점검해야 합니다. 브라우저만 시스템 프록시를 타고 데스크톱 Figma 앱은 TUN을 타거나, 반대로 앱이 자체 프록시 환경 변수를 우선하면 같은 서비스가 서로 다른 정책으로 나갈 수 있습니다. 먼저 한 가지 전달 경로만 켜고 테스트한 뒤, 필요한 앱이 누락될 때만 TUN을 추가하는 순서가 문제 범위를 좁히기 쉽습니다.

파일 동기화·실시간 보드·온라인 회의 검증

설정을 끝낸 뒤에는 “웹사이트가 열리는가”가 아니라 실제 업무 동작을 기준으로 검증해야 합니다. Notion에서는 새 페이지를 만든 뒤 여러 블록을 입력하고 이미지나 PDF를 첨부해 보세요. 페이지 본문은 저장되는데 첨부 파일만 멈춘다면 메인 도메인과 업로드 저장소가 다른 것입니다. Clash 로그에서 업로드 직전과 완료 시점의 호스트를 비교하고, 누락된 호스트가 확인될 때만 규칙을 보강합니다.

Figma는 작은 파일과 큰 파일을 나누어 시험하는 것이 좋습니다. 작은 파일이 빠르게 열려도 대형 라이브러리, 이미지가 많은 프로젝트, 폰트가 필요한 파일에서만 지연이 발생할 수 있습니다. 파일을 연 다음 페이지를 이동하고, 댓글을 작성하며, 이미지를 하나 가져온 뒤 저장 상태가 정상적으로 갱신되는지 확인하세요. 웹 버전과 데스크톱 앱의 연결 호스트가 다를 수 있으므로 두 환경을 동시에 사용할 팀이라면 각각의 로그를 별도로 기록해야 합니다.

Miro에서는 보드 입장보다 공동 편집 테스트가 중요합니다. 두 개의 계정이나 브라우저 창으로 같은 보드에 들어가 카드 하나를 이동하고, 댓글을 추가하고, 다른 창에 변경 사항이 즉시 나타나는지 확인합니다. 보드는 열리지만 변경 사항이 늦게 반영되면 실시간 연결이나 WebSocket 계열 요청이 다른 규칙에 걸렸을 가능성이 있습니다. 이때 모든 보드 관련 도메인을 무조건 프록시로 보내기보다 연결 로그에서 반복되는 호스트와 실패한 정책을 먼저 비교하세요.

원격 회의까지 함께 사용한다면 협업 앱과 회의 앱을 같은 그룹에 넣을지 신중하게 결정해야 합니다. 국내 회의 서버를 사용하는 서비스는 DIRECT가 더 안정적일 수 있고, 해외 참석자가 많은 회의는 별도 프록시 정책이 필요할 수 있습니다. 회의 중에는 노드를 바꾸거나 자동 테스트 주기를 지나치게 짧게 두지 마세요. 장시간 세션의 출구가 바뀌면 음성은 유지되더라도 화면 공유나 파일 전송이 끊기는 상황이 생길 수 있습니다.

⚠ 회사 네트워크 주의: 조직의 보안 정책과 관리형 DNS, 인증 프록시, 데이터 반출 규정을 먼저 확인하세요. 업무 파일을 개인 노드로 전송하는 것이 금지된 환경도 있으므로, 이 설정은 허가된 장비와 네트워크에서만 테스트해야 합니다.

동기화가 느릴 때의 로그 기반 문제 해결 순서

문제가 생기면 먼저 증상을 세 가지로 분류합니다. 첫째는 로그인 실패, 둘째는 파일이나 이미지 업로드 실패, 셋째는 실시간 변경 사항 지연입니다. 로그인만 실패하면 인증 호스트와 브라우저 리디렉션을 확인하고, 업로드만 실패하면 저장소·CDN·대용량 연결을 확인합니다. 실시간 이벤트만 늦으면 WebSocket 또는 장기 연결이 일반 HTTPS 규칙과 다르게 처리되는지 살펴봅니다. 이 분류를 하지 않고 노드를 계속 교체하면 원인과 결과가 섞입니다.

다음으로 같은 작업을 프록시 사용과 DIRECT에서 각각 한 번씩 재현하되, 회사 정책상 허용된 범위에서만 실행합니다. 프록시에서만 성공한다면 해당 서비스 그룹에 필요한 호스트가 빠졌거나 국내 경로에서 연결 품질이 낮은 경우입니다. DIRECT에서만 성공한다면 선택한 노드의 TLS, MTU, 지역 경로 또는 장시간 연결 유지 문제가 의심됩니다. 두 방식 모두 실패한다면 계정 권한, 서비스 장애, 브라우저 확장 프로그램, 로컬 방화벽을 먼저 확인해야 합니다.

로그에는 시간, 호스트, 사용된策略 그룹, 최종 프록시, 오류 유형을 짧게 기록해 두세요. 예를 들어 “10:20 Figma 업로드 CDN이 DIRECT, 10:22 REMOTE_WORK로 변경 후 성공”처럼 남기면 다음 프로필 갱신 때 규칙이 사라졌는지 빠르게 비교할 수 있습니다. 연결 로그에 보이지 않는 앱이라면 앱 자체 프록시 설정, TUN 권한, 운영체제 방화벽 예외를 확인하고, 모든 트래픽을 한꺼번에 프록시로 보내는 임시 해결은 마지막 진단 단계로 미루는 편이 안전합니다.

구독 프로필을 업데이트한 뒤 문제가 다시 생긴다면 로컬 수정이 덮어써졌는지부터 확인합니다. 가능하면 제공자가 지원하는 로컬 오버라이드나 확장 규칙 기능을 사용하고, 원격 프로필 원문을 직접 수정해야 한다면 백업과 변경 기록을 남기세요. Clash Verge Rev나 Mihomo 계열에서 필드 이름이 다르게 보일 때는 현재 코어가 해당 문법을 지원하는지도 확인해야 합니다. 저장은 성공했지만 코어가 알 수 없는 옵션을 무시하는 경우가 있기 때문입니다.

단순한 시스템 프록시 전환만 제공하는 일부 경량 클라이언트는 앱별 TUN, 세밀한 규칙 로그, 정책 그룹 관찰이 부족해 이런 협업 시나리오를 추적하기 어렵습니다. 반대로 오래된 Clash for Windows 빌드는 최신 코어와 설정 필드를 충분히 지원하지 않을 수 있습니다. Clash V.CORE는 Mihomo 기반의 분할 라우팅, 연결 로그 확인, 서비스별 정책 그룹과 TUN·시스템 프록시 조합을 한 흐름에서 관리하기 쉬워 Notion·Figma·Miro처럼 여러 연결을 동시에 쓰는 원격 업무에 더 적합합니다. 특정 앱만 프록시로 보내고 국내 트래픽은 직접 연결하는 구성을 실제로 운영해 보고 싶다면, 환경에 맞는 Clash V.CORE를 다운로드해 이 글의 검증 순서부터 적용해 보세요.