Notion·Figma·Miro 업무를 빠르게 만드는 Clash 설정법

Notion·Figma·Miro를 한 번에 우회하지 말아야 하는 이유

Notion, Figma, Miro는 모두 업무용 협업 도구지만 실제 연결 구조와 사용 패턴은 서로 다릅니다. Notion은 페이지 본문과 이미지·파일 저장소를 여러 호스트에서 불러오고, Figma는 웹 편집기와 실시간 파일 동기화, 폰트·플러그인 리소스를 함께 사용합니다. Miro는 보드 데이터, 커서 상태, 댓글, 썸네일을 장시간 유지되는 실시간 연결로 주고받는 경우가 많습니다. 따라서 세 서비스를 단순히 “해외 업무 사이트”라는 하나의 기준으로 묶으면 로그인은 되지만 파일 미리보기만 느리거나, 보드는 열리는데 편집 내용이 늦게 반영되는 식의 문제가 생길 수 있습니다.

이 글에서 말하는 선택적 우회는 모든 트래픽을 프록시로 보내는 방식이 아닙니다. 국내 검색, 사내 메일, 화상회의, 저장소처럼 직접 연결이 더 안정적인 트래픽은 DIRECT로 두고, 실제 사용 중 지연이나 연결 실패가 확인된 협업 도구만 별도 정책 그룹으로 보내는 설계입니다. 이렇게 하면 Clash의 연결 로그에서 어떤 서비스가 어느 노드로 나갔는지 추적하기 쉽고, 업무 중 갑자기 전체 인터넷 속도가 떨어지는 현상도 줄일 수 있습니다.

설정을 시작하기 전에 증상을 서비스별로 나누어 기록해 두세요. Notion에서는 페이지는 열리지만 첨부 파일이나 이미지가 늦게 표시되는지, Figma에서는 캔버스 로딩보다 저장·공동 편집이 문제인지, Miro에서는 보드 진입보다 커서와 댓글 동기화가 지연되는지를 구분해야 합니다. 같은 노드를 무작정 바꾸기보다 Clash의 Connections 또는 라이브 로그에서 도메인과 현재 정책을 확인하는 것이 첫 번째 단계입니다.

정책 그룹 설계: 업무용 서비스와 국내 트래픽 분리하기

기본 구조는 업무용 협업 도구를 위한 정책 그룹 하나와 일반 트래픽을 위한 기본 그룹 하나로 나누는 것입니다. 예를 들어 WORK_COLLAB라는 그룹을 만들고 여기에 안정적인 노드 또는 url-test 그룹을 연결할 수 있습니다. 규칙이 명확하지 않은 상태에서 모든 도메인을 이 그룹에 넣으면 국내 서비스까지 같은 노드를 사용하게 되므로, 처음에는 관찰한 도메인만 좁게 등록하는 편이 안전합니다.

세 서비스를 반드시 하나의 그룹에 넣어야 하는 것은 아닙니다. 업무 중 세 서비스가 비슷한 지역의 출구를 사용해야 실시간 세션이 안정적이라면 WORK_COLLAB 하나로 관리해도 됩니다. 반대로 Figma 파일 업로드는 빠르지만 Miro 보드 연결은 특정 노드에서 자주 끊긴다면 FIGMA_WORK와 MIRO_REALTIME을 따로 만들 수 있습니다. 그룹을 나누면 선택 자유도는 커지지만 노드 상태를 확인할 항목도 늘어나므로, 처음부터 지나치게 세분화하지 않는 것이 좋습니다.

• 기본 그룹: 국내 웹사이트, 사내 시스템, 검색, 일반 업데이트 등은 DIRECT 또는 기존 정책을 사용합니다.
• 업무 그룹: 실제 로그에서 확인한 Notion·Figma·Miro 호스트만 넣고, 사용할 노드와 자동 선택 그룹을 배치합니다.
• 차단 그룹: 광고·추적 도메인은 업무 그룹과 섞지 말고 기존 차단 규칙의 흐름을 유지합니다.
• 최종 규칙: 앞의 특정 도메인 규칙에서 처리하지 못한 나머지만 기본 정책으로 보내도록 둡니다.

노드 선택 기준도 다운로드 속도 하나로 정하지 마세요. Notion 페이지는 짧은 요청이 많고 Figma와 Miro는 연결을 오래 유지할 수 있으므로, 순간적인 지연보다 연결 안정성·패킷 손실·장시간 세션 유지 여부가 더 중요합니다. url-test가 빠른 노드를 골라도 실제 협업 서비스에서 인증이나 웹소켓이 불안정할 수 있습니다. 업무 시간대에 10~15분 정도 실제 페이지 편집을 해 보고, 그 결과를 기준으로 수동 선택과 자동 선택 중 하나를 결정하세요.

Notion·Figma·Miro 규칙 작성과 우선순위

규칙은 서비스 이름만 보고 추측해서 만들기보다 연결 로그를 기준으로 작성해야 합니다. Notion의 주 도메인 하나만 등록하면 페이지 껍데기는 열려도 이미지, 첨부 파일, 로그인 또는 분석 요청이 다른 정책으로 빠질 수 있습니다. Figma도 웹 앱 호스트와 파일·이미지·폰트·플러그인 리소스가 항상 같은 이름을 사용한다고 볼 수 없습니다. Miro는 보드 자체와 실시간 통신 경로가 분리될 수 있어, 보드가 뜬 뒤 편집 상태만 멈추는 증상이 나타나기도 합니다.

첫 번째 관찰에서는 로그에 나온 호스트를 서비스별로 분류해 두고, 확실한 주 도메인에는 DOMAIN-SUFFIX를 적용합니다. 단, 너무 넓은 공통 CDN 접미를 한꺼번에 업무 그룹으로 보내면 다른 사이트의 이미지나 다운로드까지 함께 우회될 수 있습니다. 조직에서 사용하는 파일 저장소나 사내 도구와 이름이 겹칠 가능성이 있는 경우에는 더 구체적인 DOMAIN 규칙을 우선 고려하세요.

# 구조 예시: 실제 호스트와 그룹 이름에 맞게 수정
- DOMAIN-SUFFIX,notion.site,WORK_COLLAB
- DOMAIN-SUFFIX,figma.com,WORK_COLLAB
- DOMAIN-SUFFIX,miro.com,WORK_COLLAB
- MATCH,DIRECT

위 예시는 개념을 보여 주는 뼈대일 뿐이며, 그대로 복사해 모든 환경에서 완성된 규칙이 되는 것은 아닙니다. 공급자 설정에서 이미 같은 도메인을 다른 그룹으로 보내고 있다면 규칙의 위치가 결과를 결정합니다. Clash 계열은 일반적으로 위에서 아래로 규칙을 평가하므로, 업무용 규칙은 넓은 지역 규칙이나 최종 MATCH보다 위에 있어야 합니다. 반대로 광고 차단이나 악성 도메인 규칙보다 업무 규칙을 무조건 앞에 두면 조직의 보안 정책을 우회할 수 있으므로, 기존 규칙의 목적과 순서를 먼저 확인하세요.

적용 후에는 브라우저 캐시와 서비스 세션 때문에 이전 결과가 계속 보일 수 있습니다. Clash의 연결 로그를 지운 다음 Notion 페이지 새로 고침, Figma 파일 열기와 간단한 저장, Miro 보드 진입과 댓글 입력을 각각 실행하세요. 각 동작이 만들어 낸 연결에 예상한 정책명이 표시되는지 확인하고, DIRECT와 WORK_COLLAB가 무작위로 섞이지 않는지 살펴봅니다. 도메인 규칙을 추가할 때는 한 번에 많은 줄을 넣지 말고 한 서비스씩 변경해야 원인을 되돌리기 쉽습니다.

노트북·데스크톱·모바일별 설정 관리

같은 구독을 사용하더라도 기기별로 Clash의 동작 방식은 달라집니다. Windows나 macOS의 브라우저는 시스템 프록시를 상속받을 수 있지만, 모바일 앱과 데스크톱 전용 클라이언트는 자체 네트워크 확장이나 TUN 모드를 사용할 수 있습니다. 따라서 PC에서 Notion이 정상이라고 해서 휴대전화의 Notion 앱까지 같은 규칙을 자동으로 따른다고 가정하면 안 됩니다.

데스크톱에서는 먼저 시스템 프록시가 켜져 있는지 확인하고, TUN을 사용하는 경우에는 DNS와 가상 인터페이스가 실제로 활성화되었는지 확인하세요. 브라우저만 처리하고 Figma 데스크톱 앱은 직접 연결하는 구조라면, 앱의 연결 로그가 보이지 않는 것이 규칙 오류가 아니라 트래픽이 Clash를 거치지 않는 결과일 수 있습니다. 반대로 TUN과 시스템 프록시를 동시에 과하게 구성하면 동일 연결이 두 계층을 지나 지연이 늘거나 인증서 오류가 발생할 수 있습니다.

모바일에서는 배터리 절약 정책과 백그라운드 제한이 실시간 보드나 공동 편집 세션에 영향을 줄 수 있습니다. Miro 앱이 화면을 잠근 뒤 재연결되지 않는다면 우선 노드보다 배터리 최적화, VPN 프로파일 유지, 앱의 백그라운드 데이터 권한을 확인하세요. Android의 Clash 계열 클라이언트에서는 앱별 우회 또는 앱 분할 기능을 제공하는 경우가 있으므로, 업무 앱만 대상으로 지정하고 개인 앱과 국내 금융 앱은 제외하는 방식이 관리에 유리합니다.

여러 기기를 운영한다면 원격 구독 파일을 직접 계속 수정하기보다, 기본 규칙과 업무용 오버레이를 구분해 보관하세요. 구독 갱신 때마다 수동 규칙이 사라지는 구조라면 변경 내용을 별도의 메모에 기록하고, 업데이트 후 업무용 규칙이 남아 있는지 확인해야 합니다. 회사 노트북과 개인 노트북의 정책을 똑같이 복사하지 말고, 장치 이름과 사용 목적을 표시한 프로필을 따로 두면 실수로 모바일에 과도한 TUN 설정을 적용하는 일을 줄일 수 있습니다.

검증 루프와 자주 발생하는 실패 패턴

설정이 끝났다고 판단하려면 세 가지를 순서대로 확인하세요. 첫째, 연결 로그에서 Notion·Figma·Miro의 실제 요청이 업무 그룹에 매칭되는지 봅니다. 둘째, 국내 사이트와 사내 시스템이 의도대로 DIRECT 또는 기존 정책을 유지하는지 확인합니다. 셋째, 업무 동작을 10분 이상 반복하면서 페이지 이동, 파일 저장, 보드 동기화가 계속 안정적인지 관찰합니다. 한 번의 새로 고침 성공보다 세션이 유지되는지가 더 중요한 경우가 많습니다.

가장 흔한 실패는 규칙이 너무 넓은 경우입니다. 업무 도구는 빨라졌지만 뉴스, 동영상, 사내 저장소까지 같은 노드로 이동해 전체 체감 속도가 나빠질 수 있습니다. 두 번째는 규칙이 너무 좁은 경우입니다. 메인 도메인만 처리해 로그인은 성공하지만 첨부 파일이나 실시간 연결이 다른 정책으로 빠집니다. 세 번째는 그룹 이름을 잘못 입력하는 경우입니다. YAML 안의 정책 이름과 실제 proxy-groups 이름이 한 글자라도 다르면 규칙은 저장되어도 기대한 출구로 가지 않습니다.

또 다른 문제는 노드 자체의 지역과 품질을 혼동하는 것입니다. Figma의 파일 미리보기만 느리다고 해서 무조건 더 먼 노드를 선택하면 오히려 TLS 연결과 왕복 시간이 늘어날 수 있습니다. 반대로 Miro의 장시간 연결이 자주 끊기는 노드는 순간 속도 측정에서 좋은 점수를 받아도 업무용으로 적합하지 않습니다. 노드를 비교할 때는 다운로드 수치, 초기 연결 시간, 10분 이상 유지되는지, 재연결 후 같은 정책으로 돌아오는지를 함께 기록하세요.

운영 팁: 설정을 바꿀 때마다 규칙 변경 전후의 연결 로그와 사용한 노드 이름을 짧게 기록하세요. 문제가 재발했을 때 “서비스 장애인지, 규칙 변경인지, 노드 품질인지”를 빠르게 분리할 수 있고, 구독 업데이트 뒤 규칙이 사라졌는지도 쉽게 확인할 수 있습니다.

Notion·Figma·Miro 업무를 위한 Clash 설정은 모든 트래픽을 강제로 우회하는 작업이 아니라, 실제로 필요한 협업 연결만 분류하고 나머지는 직접 연결로 보존하는 작업입니다. Clash for Windows처럼 시스템 프록시 중심인 환경은 앱 적용 범위를 먼저 확인하고, Clash Verge Rev나 Mihomo 계열처럼 TUN을 지원하는 환경은 DNS·라우팅 모드까지 함께 검증해야 합니다. 일부 상용 VPN은 앱별 제외나 세부 규칙이 제한적이고, 단순 시스템 프록시는 Figma·Miro 데스크톱 앱의 모든 연결을 잡지 못할 수 있지만, Clash V.CORE는 규칙·정책 그룹·연결 로그를 한 흐름에서 확인하면서 기기별 프로필을 조정하기 쉽습니다. 업무 도구의 실제 호스트와 사용 패턴을 기록한 뒤 안정적인 분할 라우팅을 적용하고 싶다면 Clash V.CORE를 다운로드해 현재 환경에 맞는 설정을 시작해 보세요.