연구자를 위한 Clash 설정법: Scholar·Zotero·Overleaf 연구 워크플로

연구용 Clash가 필요한 이유: 검색·동기화·공동 집필을 한 흐름으로 보기

연구자의 네트워크 사용 패턴은 일반적인 웹 브라우징과 다릅니다. Google Scholar에서 논문과 인용 정보를 검색하고, 출판사 페이지에서 원문 PDF를 확인한 뒤, Zotero로 참고문헌과 첨부 파일을 동기화하며, 마지막에는 Overleaf에서 동료와 LaTeX 문서를 공동 편집합니다. 각각의 서비스가 사용하는 도메인, 인증 방식, 파일 크기, 연결 지속 시간이 서로 다르기 때문에 단순히 “프록시를 켠다”는 설정만으로는 안정적인 연구 환경을 만들기 어렵습니다.

예를 들어 Scholar 검색 결과는 열리는데 특정 출판사의 초록 페이지가 계속 로딩되거나, Zotero의 웹 커넥터는 작동하지만 PDF 첨부 파일만 실패하는 경우가 있습니다. Overleaf에서는 로그인까지 성공했지만 컴파일 로그가 늦게 갱신되거나, 공동 편집 중 WebSocket 연결이 끊겨 다른 사람의 수정 사항이 늦게 나타날 수도 있습니다. 이런 현상은 모두 같은 장애처럼 보이지만 실제로는 DNS, 인증, 정적 파일 CDN, API, 장시간 연결이 서로 다른 정책을 통과하면서 생깁니다.

핵심 원칙: 연구 서비스 전체를 무조건 하나의 프록시 그룹에 넣기보다, 검색·참고문헌·문서 공동 편집이라는 사용 목적을 먼저 정하고 연결 로그에서 실제 호스트를 확인한 뒤 규칙을 좁혀 가세요.

Google Scholar 검색과 논문 원문 페이지 라우팅

Google Scholar는 검색 결과 페이지 하나만 확인하면 끝나는 서비스가 아닙니다. 검색 화면, Google 계정 로그인, 학술지 출판사 페이지, DOI 리디렉션, 기관 저장소, PDF 호스트가 연속으로 등장할 수 있습니다. 검색 결과 자체는 빠른데 “모든 버전”, “PDF”, 인용 내보내기 링크만 열리지 않는다면 Scholar의 메인 도메인만 규칙에 추가한 것이 원인일 가능성이 큽니다.

먼저 Clash의 연결 로그를 열고 Scholar 검색을 한 번 실행합니다. 이어서 관심 있는 결과의 초록 페이지를 열고, DOI 링크와 PDF 링크를 차례로 눌러 각 요청의 호스트를 기록하세요. 도메인이 매번 달라질 수 있으므로 검색 결과에 표시된 URL만 보고 전체를 추측하지 않는 편이 안전합니다. 다음 표처럼 기능별로 관찰 결과를 분리하면 규칙을 수정할 때 실수가 줄어듭니다.

Scholar와 일반 Google 서비스를 모두 넓은 규칙으로 묶으면 검색은 편해질 수 있지만, 개인 계정 트래픽과 연구용 트래픽을 구분하기 어려워집니다. 반대로 너무 많은 호스트를 하나씩 등록하면 출판사 개편이나 기관 저장소 변경 때 유지보수가 힘들어집니다. 처음에는 실제 로그에서 반복적으로 나타난 공식 호스트만 DOMAIN-SUFFIX 또는 필요한 경우 DOMAIN으로 등록하고, 범위가 넓은 규칙은 뒤쪽에 배치하세요.

Zotero 동기화: API, 첨부 파일, WebDAV를 구분하기

Zotero의 데이터 동기화와 첨부 파일 동기화는 같은 작업처럼 보이지만 네트워크 관점에서는 분리해서 생각하는 것이 좋습니다. 서지 정보, 태그, 컬렉션 구조는 비교적 작은 API 요청으로 처리되지만 PDF와 스냅샷은 파일 크기가 크고 전송 시간이 길어질 수 있습니다. Zotero 자체 저장소를 쓰는지, 기관 또는 개인 WebDAV를 쓰는지에 따라 연결 대상도 달라집니다.

설정을 바꾼 직후에는 먼저 작은 테스트 라이브러리를 사용하세요. 새 논문 하나를 추가하고 메타데이터가 동기화되는지 확인한 다음, 용량이 큰 PDF를 첨부해 파일 전송을 따로 관찰합니다. 메타데이터만 성공하고 첨부 파일이 멈춘다면 Scholar 문제가 아니라 파일 저장소, WebDAV 인증, 대용량 연결의 타임아웃을 확인해야 합니다. 이때 무작정 재시도하면 동일한 PDF가 중복 업로드되거나 동기화 대기열이 길어질 수 있습니다.

Zotero 전용 정책 그룹을 만들 때의 기준

연구용 프로필에서는 RESEARCH_SYNC처럼 의미가 분명한 정책 그룹을 만들고 Zotero의 API와 첨부 파일 저장소를 우선 같은 출구에 두는 방식이 관리하기 쉽습니다. API와 파일 전송을 서로 다른 국가나 서로 다른 품질의 노드로 나누면 로그인은 성공하지만 업로드 세션이 중간에 끊기는 상황이 생길 수 있습니다. 특히 대용량 PDF를 자주 다루는 연구실에서는 짧은 핑보다 지속 연결 안정성과 업로드 속도의 일관성을 우선해야 합니다.

WebDAV를 사용하는 경우에는 서버 주소의 호스트와 포트, TLS 인증서, 계정 권한을 각각 확인하세요. Clash 규칙이 맞아도 서버가 특정 User-Agent나 인증 방식을 요구하면 동기화가 실패할 수 있습니다. 오류가 발생하면 Zotero의 동기화 상태와 Clash 연결 로그를 같은 시각에 비교하고, DNS 오류인지 HTTP 상태 코드인지 인증 실패인지부터 나눠야 합니다. DIRECT와 프록시를 번갈아 시험할 때는 한 번에 여러 설정을 바꾸지 말고, 변경한 항목과 결과를 연구 노트에 남기는 것이 좋습니다.

Overleaf 공동 편집과 컴파일 연결을 안정화하는 방법

Overleaf는 일반적인 문서 웹사이트와 달리 실시간 공동 편집, 프로젝트 파일 목록, 이미지와 참고문헌 업로드, 컴파일 작업, 로그 스트리밍이 함께 동작합니다. 페이지는 보이는데 공동 편집자의 커서나 수정 사항이 늦게 나타난다면 일반 HTTP 요청보다 장시간 연결이나 WebSocket 계층이 영향을 받았을 수 있습니다. 컴파일 결과만 늦다면 프로젝트 파일 다운로드, 빌드 대기열, 로그 전달 경로를 별도로 살펴봐야 합니다.

우선 작은 프로젝트를 복제해 테스트합니다. 텍스트 한 줄을 수정하고 다른 브라우저 또는 동료 계정에서 변경 사항이 보이는지 확인한 뒤, 이미지 업로드와 참고문헌 컴파일을 순서대로 실행하세요. 이 과정을 한꺼번에 큰 프로젝트에서 진행하면 네트워크 문제와 LaTeX 패키지 오류를 구분하기 어렵습니다. Clash 로그에는 Overleaf 메인 호스트뿐 아니라 로그인, 프로젝트 API, 정적 에셋, 실시간 연결에 해당하는 요청이 차례로 나타날 수 있습니다.

Overleaf용 정책 그룹은 Scholar 검색 그룹과 반드시 같을 필요는 없습니다. 검색은 짧은 요청이 많고, 공동 편집은 연결을 오래 유지해야 하므로 요구하는 노드 특성이 다릅니다. 다만 연구 중인 사용자가 문서 편집 도중 수동으로 노드를 바꾸면 세션이 재설정될 수 있습니다. url-test 그룹을 사용하더라도 테스트 주기를 지나치게 짧게 설정하지 말고, 장시간 작업 중에는 안정적인 select 그룹으로 고정하는 편이 예측 가능합니다.

기관 Overleaf 서버나 자체 호스팅된 인스턴스를 사용한다면 공식 서비스와 규칙을 합치지 말고 별도 그룹으로 관리하세요. 같은 연구실 안에서도 학교 VPN, 사설 Git 저장소, 내부 패키지 미러가 함께 사용될 수 있습니다. 내부 주소를 광범위한 프록시 규칙에 넣으면 오히려 접근이 실패할 수 있으므로 사설 네트워크는 조직의 라우팅 정책에 맞춰 DIRECT 또는 기관 VPN으로 보내야 합니다.

연구 워크플로용 YAML 설계와 검증 순서

아래 예시는 특정 도메인을 무조건 추가하라는 완성본이 아니라, 연구 목적별 정책 그룹을 나누는 구조를 보여 주는 템플릿입니다. 실제 호스트는 Clash 연결 로그와 각 서비스의 공식 문서를 기준으로 교체해야 합니다. 구독 프로필을 새로 고칠 때 로컬 수정이 덮어써지는 클라이언트라면 별도의 오버라이드 기능이나 로컬 패치 방식을 먼저 확인하세요.

proxy-groups:
  - name: RESEARCH_SEARCH
    type: select
    proxies:
      - Research-Auto
      - DIRECT

  - name: RESEARCH_SYNC
    type: select
    proxies:
      - Research-Stable
      - Research-Auto
      - DIRECT

  - name: RESEARCH_COLLAB
    type: select
    proxies:
      - Research-Stable
      - Research-Auto
      - DIRECT

rules:
  - DOMAIN-SUFFIX,observed-scholar-host.example,RESEARCH_SEARCH
  - DOMAIN-SUFFIX,observed-zotero-sync.example,RESEARCH_SYNC
  - DOMAIN-SUFFIX,observed-overleaf-host.example,RESEARCH_COLLAB
  - MATCH,DIRECT

규칙을 저장한 뒤에는 먼저 YAML 파싱 오류가 없는지 확인하고, Clash 대시보드에서 활성 프로필이 실제로 바뀌었는지 확인합니다. 그 다음 Scholar 검색, Zotero 메타데이터 동기화, Zotero PDF 업로드, Overleaf 공동 편집, Overleaf 컴파일을 각각 한 번씩 실행하세요. 모든 테스트를 동시에 돌리면 로그가 섞이므로 한 단계가 끝난 뒤 다음 단계로 넘어가는 방식이 좋습니다.

규칙 순서도 반드시 확인해야 합니다. 앞쪽에 넓은 GEOIP, RULE-SET, 또는 일반적인 MATCH 규칙이 있으면 연구용 도메인 규칙까지 도달하지 못할 수 있습니다. 연결 로그에서 요청의 최종 정책 이름이 기대한 그룹인지 확인하고, 수정 전후의 로그를 비교해 실제 변화가 있었는지 판단하세요. 대시보드의 지연 숫자만으로 성공 여부를 판단하지 말고, 검색 결과 표시, 파일 업로드 완료, 공동 편집 반영, 컴파일 로그 갱신이라는 애플리케이션 단위의 결과를 기준으로 삼아야 합니다.

검색 지연과 동기화 오류를 진단하는 실전 체크리스트

문제가 생겼을 때 가장 먼저 할 일은 “어느 서비스가 안 되는가”를 구체적으로 적는 것입니다. Scholar 검색은 되지만 DOI 페이지만 실패하는지, Zotero의 컬렉션은 동기화되지만 PDF만 대기하는지, Overleaf 페이지는 열리지만 공동 편집만 끊기는지에 따라 확인할 계층이 달라집니다. 증상을 한 문장으로 “인터넷이 느리다”고 기록하면 규칙을 지나치게 넓히게 됩니다.

1. 재현 범위 기록: 한 계정만 실패하는지, 같은 네트워크의 다른 연구자도 실패하는지 확인합니다.
2. 연결 로그 필터링: Scholar, Zotero, WebDAV, Overleaf와 관련된 호스트를 시간순으로 확인합니다.
3. 정책 이름 비교: 같은 기능의 요청이 예상한 그룹으로 갔는지, 중간에 DIRECT로 바뀌었는지 봅니다.
4. 단일 변수 테스트: 노드 변경, DNS 변경, TUN 모드 변경을 동시에 하지 않고 하나씩 시험합니다.
5. 원상 복구: 문제가 해결되지 않으면 백업한 프로필로 돌아가 정상 상태를 확보한 뒤 규칙을 다시 좁힙니다.

DNS 모드와 TUN 모드를 바꿀 때도 목적을 분리하세요. 도메인이 잘못 해석되는 문제라면 DNS 로그와 실제 응답을 먼저 확인하고, 애플리케이션이 시스템 프록시를 무시하는 문제라면 TUN 적용 여부를 점검해야 합니다. 그러나 TUN을 켠다고 모든 서비스가 자동으로 안정화되는 것은 아닙니다. 이미 실행 중인 VPN, 보안 프로그램, 기관 에이전트가 가상 인터페이스의 우선순위를 바꾸면 연결이 더 복잡해질 수 있습니다.

연구 데이터의 기밀성도 함께 고려해야 합니다. 논문 초안, 심사 의견, 연구비 문서, 개인 식별 정보가 포함된 파일은 신뢰할 수 없는 노드나 공개 프록시로 보내지 마세요. 가능하면 연구기관이 승인한 네트워크, 검증된 공급자, 최신 Clash V.CORE 코어를 사용하고, 노드 변경이 필요한 경우에도 문서 업로드 중에는 세션을 유지하는 것이 좋습니다.

일부 VPN 앱은 앱별 분할 터널링을 제공하지만, 복잡한 학술 서비스의 리디렉션과 WebSocket 흐름을 세밀하게 확인하기 어렵고 프로필을 재현하기도 힘듭니다. 반대로 단순 시스템 프록시는 TUN이 필요한 데스크톱 앱이나 파일 동기화 클라이언트에 적용되지 않을 수 있습니다. Clash V.CORE는 규칙 기반 라우팅, 연결 로그, 정책 그룹, TUN과 시스템 프록시 선택지를 한 구성 안에서 관리할 수 있어 Scholar 검색과 Zotero 동기화, Overleaf 공동 집필을 목적별로 검증하기에 유리합니다. 연구 환경을 새로 구성하거나 기존 설정의 원인을 추적하고 있다면, 먼저 허용된 네트워크 정책을 확인한 뒤 Clash V.CORE 다운로드 페이지에서 자신의 운영체제에 맞는 최신 빌드를 받아 이 워크플로를 단계적으로 재현해 보세요.