연구자를 위한 Clash 설정 Zotero·Overleaf 학술 작업 최적화

연구자는 논문 검색, 참고문헌 정리, 원고 작성과 공동 편집을 하루에도 여러 번 반복합니다. 이때 Google Scholar나 출판사 웹사이트는 열리지만 Zotero 동기화가 멈추거나, Overleaf 컴파일이 간헐적으로 실패하면 작은 네트워크 문제가 곧바로 연구 일정 지연으로 이어집니다. Clash 또는 Mihomo를 무조건 전체 프록시로 사용하는 것보다 서비스의 목적에 따라 연결 경로를 나누는 편이 안정적입니다. 이 글에서는 Scholar 검색, Zotero, Overleaf를 프록시 대상으로 구성하고 국내 포털, 학교 시스템, 파일 서버는 직접 연결로 유지하는 실전 워크플로를 설명합니다.

연구용 네트워크를 먼저 설계하는 방법

연구 환경의 핵심은 “모든 트래픽을 프록시로 보낼 것인가”가 아니라 “어떤 서비스에 어떤 경로가 가장 적합한가”입니다. 해외 학술 검색 서비스와 GitHub 기반 자료는 프록시 경로가 더 안정적일 수 있지만, 대학 포털이나 국내 전자결재 시스템은 로컬 네트워크와 직접 통신해야 인증 오류가 줄어듭니다. 따라서 연구용 Clash 설정은 최소한 세 가지 트래픽 그룹으로 나누는 것이 좋습니다.

• 학술 검색 그룹: Google Scholar, Semantic Scholar, PubMed, Crossref 등 논문 검색과 메타데이터 조회 서비스입니다.
• 집필 및 동기화 그룹: Overleaf, GitHub, 원격 Git 저장소, Zotero 동기화에 필요한 서버입니다.
• 국내 직접 연결 그룹: 학교 포털, 도서관 인증 페이지, 국내 학술 데이터베이스, NAS와 프린터 같은 로컬 장치입니다.

이렇게 분리하면 특정 해외 서비스의 상태가 나빠졌을 때 전체 인터넷을 끊었다가 다시 켜는 대신 해당 그룹의 노드만 바꿀 수 있습니다. 또한 Zotero의 로컬 데이터베이스와 PDF 파일은 프록시가 필요하지 않으므로 디스크 작업과 동기화 트래픽을 구분해 생각해야 합니다. Clash는 네트워크 연결을 제어할 뿐, Zotero의 데이터 저장 방식이나 Overleaf 프로젝트 권한을 대신 관리하지 않는다는 점도 기억해야 합니다.

서비스별 권장 라우팅 비교

하나의 도메인만 추가한다고 서비스 전체가 항상 정상적으로 작동하는 것은 아닙니다. 로그인, 정적 리소스, API, 파일 업로드가 서로 다른 호스트에서 제공될 수 있기 때문입니다. 예를 들어 Overleaf 화면은 열리지만 컴파일 결과 다운로드가 실패한다면 웹 페이지 도메인과 별도의 파일 저장소 또는 API 도메인이 규칙에서 빠졌을 가능성이 있습니다.

서비스가 여러 국가의 CDN을 사용하는 경우에는 특정 국가 도메인을 일괄적으로 차단하거나 고정하지 않는 것이 좋습니다. 먼저 도메인 기반 규칙을 적용하고, 실제 연결 로그에서 반복되는 호스트를 확인한 다음 필요한 항목만 추가하세요. IP 주소를 수동으로 등록하는 방식은 CDN 변경에 취약하고, 같은 IP를 여러 서비스가 공유할 수 있어 예상하지 못한 트래픽까지 프록시될 수 있습니다.

Clash 규칙과 프록시 그룹 구성

아래 예시는 Mihomo 계열 클라이언트에서 사용할 수 있는 기본 구조입니다. 구독으로 가져온 프록시 이름은 환경마다 다르므로 Academic-Proxy와 Work-Proxy 부분을 실제 그룹 이름으로 바꿔야 합니다. Clash for Windows, Clash Verge Rev, ClashX 등에서는 YAML 편집 기능이나 확장 설정 파일을 사용해 같은 원리를 적용할 수 있습니다.

proxy-groups:
  - name: Academic-Proxy
    type: select
    proxies:
      - Auto-Select
      - DIRECT

  - name: Research-Work
    type: select
    proxies:
      - Auto-Select
      - DIRECT

rules:
  - DOMAIN-SUFFIX,scholar.google.com,Academic-Proxy
  - DOMAIN-SUFFIX,semanticscholar.org,Academic-Proxy
  - DOMAIN-SUFFIX,pubmed.ncbi.nlm.nih.gov,Academic-Proxy
  - DOMAIN-SUFFIX,overleaf.com,Research-Work
  - DOMAIN-SUFFIX,zotero.org,Research-Work
  - DOMAIN-SUFFIX,github.com,Research-Work
  - DOMAIN-SUFFIX,githubusercontent.com,Research-Work
  - DOMAIN-SUFFIX,ac.kr,DIRECT
  - DOMAIN-SUFFIX,go.kr,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

DOMAIN-SUFFIX는 하위 도메인까지 포함하므로 연구 서비스의 기본 도메인을 관리하기에 편리합니다. 다만 학교나 출판사 사이트가 여러 도메인을 사용하는 경우에는 무리하게 넓은 접미사를 추가하지 마세요. 예를 들어 google.com 전체를 프록시로 보내면 검색과 무관한 서비스까지 같은 경로를 사용하게 됩니다. 가능한 한 scholar.google.com처럼 구체적인 도메인을 우선 사용하고, 로그인 리디렉션이 발생할 때만 필요한 항목을 확장하는 것이 좋습니다.

직접 설정하고 연결을 검증하는 순서

설정 파일을 저장한 뒤 바로 모든 프로그램을 실행하기보다, 서비스별로 한 단계씩 검사하면 원인을 빠르게 좁힐 수 있습니다. 다음 절차는 Clash Verge Rev나 Mihomo 기반 클라이언트에서 공통으로 적용할 수 있습니다.

1. 현재 사용 중인 설정을 별도 파일로 백업합니다. 구독 업데이트로 직접 수정한 규칙이 사라질 수 있으므로 사용자 오버라이드 파일을 따로 보관하는 것이 안전합니다.
2. 프록시 그룹에 학술용과 작업용 그룹을 만들고, 먼저 하나의 정상 작동하는 노드와 DIRECT만 넣습니다.
3. Google Scholar에서 검색한 뒤 논문 상세 페이지, 외부 출판사 링크, PDF 링크가 모두 열리는지 확인합니다.
4. Zotero를 실행해 계정 로그인, 라이브러리 동기화, 새 항목 저장, 첨부 PDF 다운로드를 차례로 테스트합니다.
5. Overleaf에서 프로젝트를 열고 파일 편집, 저장, 컴파일, PDF 미리보기와 다운로드를 순서대로 확인합니다.
6. 대시보드의 연결 목록에서 각 도메인에 적용된 규칙과 실제 프록시 그룹을 확인합니다. 예상과 다르면 해당 연결을 종료하고 규칙을 수정합니다.
7. 마지막으로 대학 포털, 도서관 SSO, NAS 주소를 확인해 국내 서비스가 계속 직접 연결되는지 검증합니다.

연결 로그로 실패 원인 찾기

Scholar는 검색은 되지만 PDF만 실패하는 경우, PDF가 다른 출판사 도메인이나 CDN에서 제공되는지 확인해야 합니다. Zotero는 로그인은 되지만 동기화가 멈춘다면 계정 API와 첨부 파일 저장소가 서로 다른 경로를 쓰는지 살펴보세요. Overleaf에서 컴파일 버튼이 반응하지 않거나 결과 파일이 열리지 않는 경우에는 편집 서버, 컴파일 서버, 다운로드 엔드포인트가 모두 같은 규칙을 받는지 점검해야 합니다.

연결 목록에는 일반적으로 목적지 호스트, 사용한规则, 프록시 그룹과 전송 상태가 표시됩니다. 한국어 환경에서 일부 프로그램이 도메인 대신 IP만 노출한다면 DNS 모드와 TUN 모드의 동작도 확인하세요. 가능하면 도메인 기반 규칙을 유지하고, 특정 IP를 일시적으로 추가한 뒤 문제가 해결되는지 비교하는 방식으로 원인을 분리하는 것이 좋습니다.

Zotero와 Overleaf를 함께 사용할 때의 실전 팁

Zotero와 Overleaf는 서로 다른 작업을 처리합니다. Zotero는 참고문헌 데이터와 첨부 파일을 관리하고, Overleaf는 원고와 .bib 파일을 공동 편집합니다. 따라서 Zotero 라이브러리 전체를 자동으로 Overleaf에 동기화한다고 생각하면 안 됩니다. 일반적으로는 Zotero에서 필요한 컬렉션을 정리한 뒤 BibTeX 또는 Better BibTeX 방식으로 내보내고, Overleaf 프로젝트에 가져오는 흐름이 더 예측 가능합니다.

• 중복 항목 정리: DOI, 제목, 저자와 연도를 기준으로 중복 문헌을 먼저 합칩니다. 중복 상태에서 내보내면 인용 키가 달라질 수 있습니다.
• 인용 키 고정: 이미 원고에서 사용한 키를 변경하지 않도록 자동 키 규칙을 신중하게 설정합니다.
• 첨부 파일 분리: PDF 원본은 Zotero 또는 기관 저장소에 두고, Overleaf에는 원고에 필요한 파일만 올립니다. 큰 파일을 반복 업로드하면 컴파일과 동기화가 느려집니다.
• 버전 관리: Overleaf의 기록 기능이나 Git 연동을 사용해 원고 변경 이력을 남깁니다. Clash 설정 변경과 논문 원고 변경을 하나의 문제로 섞지 않는 것이 좋습니다.
• 동기화 중 충돌 방지: 여러 장치에서 Zotero를 동시에 수정하지 말고, 동기화가 끝난 뒤 다른 장치에서 작업을 이어갑니다.

Overleaf 프로젝트를 GitHub와 연결하는 경우에는 github.com뿐 아니라 저장소 파일을 내려받는 호스트가 별도로 사용될 수 있습니다. Git 작업이 실패하면 브라우저에서 GitHub가 열리는지 확인하는 것만으로 충분하지 않습니다. Clash 연결 로그에서 API 호출, 저장소 원격 주소, 대용량 파일 저장소 요청을 각각 확인해야 합니다.

안정성과 보안을 높이는 운영 원칙

연구 데이터에는 미공개 논문, 연구 참여자 정보, 기관 내부 문서가 포함될 수 있으므로 프록시 노드 선택은 속도보다 신뢰성이 우선입니다. 출처가 불분명한 무료 노드에 기관 계정이나 Zotero 계정으로 로그인하지 말고, 비밀번호는 서비스마다 다르게 사용하세요. Clash의 외부 컨트롤러를 활성화했다면 127.0.0.1에 바인딩하고 강력한 시크릿을 설정해야 합니다. LAN 전체에 관리 API를 노출하면 같은 네트워크의 다른 사용자가 노드를 바꾸거나 연결 정보를 조회할 수 있습니다.

노드 선택은 단순한 핑 수치만으로 결정하지 않는 것이 좋습니다. Scholar 검색, Zotero 파일 동기화, Overleaf 컴파일은 서로 다른 서버와 전송 패턴을 사용하므로 실제 작업을 기준으로 테스트해야 합니다. 한 노드가 검색에는 빠르지만 대용량 PDF 다운로드에 약할 수 있고, 다른 노드는 Overleaf 연결은 안정적이지만 지연 시간이 높을 수 있습니다. 필요하다면 url-test 그룹으로 후보를 자동 측정하되, 최종 판단은 실제 연구 업무의 성공률로 내려야 합니다.

정리하면 연구자에게 적합한 Clash 설정은 전체 트래픽을 무조건 프록시하는 구성이 아니라, 학술 검색과 협업 도구를 목적별 그룹으로 나누고 국내 서비스와 로컬 자원은 직접 연결하는 구조입니다. 연결 로그를 기준으로 도메인을 보완하고, Zotero와 Overleaf의 로그인·동기화·컴파일을 각각 검증하면 불필요한 규칙과 장애를 크게 줄일 수 있습니다. Windows, macOS, Linux, Android, iOS에서 동일한 원칙을 적용할 수 있으므로 자신의 작업 장치에 맞는 클라이언트를 선택해 안정적인 연구 환경을 구성해 보세요.