바이두 넷디스크와 AList로 Zotero 첨부 파일 동기화하기

예전에는 줄곧 Nutstore로 Zotero 첨부 파일을 동기화했다. 한 번 설정해 두면 거의 신경 쓸 일이 없었고, 컴퓨터를 바꿔 가며 쓰기도 편했다. 무료 계정의 전송량이 점점 부족해지기 전까지는 그랬다.

Nutstore 도움말 센터에 따르면 무료 계정의 월간 업로드 한도는 1 GB, 다운로드 한도는 3 GB다. 평소 논문을 몇 편씩 추가할 때는 괜찮지만, 첨부 파일이 많이 쌓이거나 다른 기기에서 다시 내려받아야 할 때는 한도가 금세 빠듯해진다.

얼마 전 MacBook Pro를 새로 샀는데, 새 컴퓨터에서 첨부 파일을 동기화하다 보니 그달 전송량을 금방 다 써 버렸다. 다음 달이 될 때까지 기다렸지만, 새로 받은 한도도 첫날에 다 소진했다. 더는 이렇게 쓸 수 없었다.

그래서 다시 대안을 찾기 시작했다. 아무리 찾아봐도 딱 맞는 방법이 없었고, 논문을 동기화하자고 돈을 더 내고 싶지도 않았다.

그러다 문득 생각났다. 이미 바이두 넷디스크 유료 회원이고 AList도 계속 쓰고 있으니, 둘을 연결해서 Zotero가 계속 WebDAV로 동기화하게 할 수 있지 않을까?

더 의외였던 건 AList의 바이두 넷디스크 연결을 한참 동안 손보지 않았다는 점이다. 몇 달인지, 1년인지, 그보다 더 오래됐는지도 기억이 나지 않는다. 그런데 다시 열어 보니 여전히 접속이 됐다. 연결이 살아 있으니 일단 해 보기로 했다.

‘플러그인 + 폴더 동기화’를 선택하지 않은 이유

Zotero에는 또 다른 흔한 방법이 있다. 첨부 파일을 정해진 폴더로 옮긴 뒤, 클라우드 드라이브 클라이언트로 그 폴더를 동기화하는 방식이다. 예전에 쓰이던 ZotFile이나 요즘 쓰이는 ZotMoov가 이런 첨부 파일 관리를 도와준다. 여기서 필요한 것은 폴더 동기화다. 파일을 단순히 백업해 두는 것만으로는 다른 컴퓨터의 파일까지 자동으로 같은 상태가 되지 않는다.

이런 방식은 보통 첨부 파일을 ‘연결된 파일’로 바꾼다. Zotero는 파일 위치만 기억하고, 실제 파일 관리는 다른 프로그램이 맡는다. 두 컴퓨터 모두 폴더 동기화를 설정하고, Zotero가 각자의 첨부 파일 경로를 찾을 수 있게 해야 한다. 양쪽에서 새 첨부 파일을 외부 폴더로 자동 이동시키려면 플러그인도 각각 설정해야 한다. 이미 연결된 파일을 읽기만 한다면 모든 컴퓨터에 같은 플러그인을 설치할 필요는 없다.

문제를 해결할 수는 있지만, 내게는 신경 써야 할 부분이 좀 많았다. 특히 Zotero 공식 모바일 앱은 연결된 파일을 지원하지 않으며, 이런 파일은 Zotero의 기본 파일 동기화로 업로드되지도 않는다. 컴퓨터의 폴더를 잘 정리해 뒀다고 해서 iPad나 휴대폰의 공식 앱에서도 곧바로 이어서 쓸 수 있는 것은 아니다.

나는 기존 사용 방식을 그대로 유지하고 싶었다. 평소처럼 첨부 파일을 Zotero에 넣고, 다른 기기를 켠 뒤 동기화되기만 기다리면 되는 방식 말이다.

첨부 파일 저장소만 바꾸고 Zotero 기본 동기화는 그대로

먼저 ‘동기화’를 나눠서 짚어 보자. Zotero의 데이터 동기화와 파일 동기화는 별개다.

그러니 예전에 Nutstore를 쓸 때도 Zotero 라이브러리 전체를 Nutstore에 맡긴 것은 아니었다. 문헌 데이터는 여전히 Zotero 계정을 통해 동기화됐고, Nutstore는 주로 첨부 파일을 담당했다. 이제 그 부분만 AList가 제공하는 WebDAV로 바꾸는 것이다.

내장 리더에서 작성한 주석은 Zotero 데이터베이스에 저장되므로, 평소 하이라이트를 하거나 메모를 남길 때마다 PDF 전체를 다시 전송할 필요가 없다. 외부 리더로 PDF 자체를 수정했을 때만 변경 사항을 첨부 파일과 함께 동기화해야 한다.

WebDAV는 원래 Zotero가 지원하는 파일 동기화 방식이어서 별도의 첨부 파일 동기화 플러그인이 필요 없다. 공식 iOS 및 Android 앱에서도 WebDAV를 쓸 수 있다. 다만 Zotero Storage와는 차이가 있다. WebDAV는 개인 라이브러리만 담당하며, 그룹 첨부 파일에는 여전히 Zotero Storage가 필요하다. Zotero 웹 라이브러리에서도 이 WebDAV에 있는 첨부 파일을 직접 열 수 없다. 내가 ‘공식 동기화와 비슷하다’고 하는 것은 주로 클라이언트에서 개인 라이브러리를 일상적으로 사용하는 경험을 뜻한다.

가장 중요한 선택: AList 서버를 거쳐 전송하기

마운트에 성공했다는 것은 AList가 바이두 넷디스크에 접근할 수 있다는 뜻일 뿐, Zotero에서 모든 첨부 파일을 문제없이 내려받을 수 있다는 뜻은 아니다.

AList의 바이두 넷디스크 문서에서는 관련 다운로드 API를 사용할 때 대략 20 MB를 넘는 파일의 요청에 다음 헤더가 필요하다고 안내한다: User-Agent: pan.baidu.com. 여기서 말하는 것은 다운로드 요청이지, ‘큰 파일을 업로드할 때는 모두 UA를 바꿔야 한다’는 뜻이 아니다. 파일 크기 역시 영원히 고정된 규칙이 아니라 문서에 제시된 경험적 기준으로 이해하는 편이 맞다.

WebDAV에서 302 리디렉션을 사용하면 AList는 실제 다운로드 주소를 클라이언트에 넘겨준다. 이후 클라이언트가 바이두 넷디스크에서 직접 파일을 내려받는다. 첨부 파일이 AList 서버를 거치지 않아 서버 대역폭을 아낄 수 있지만, 필요한 요청 헤더도 클라이언트가 직접 갖춰야 한다.

Zotero의 일반 동기화 설정에는 UA를 입력하는 항목이 없다. 첨부 파일을 동기화하려고 Surge 같은 네트워크 도구로 요청을 수정하고, 기기마다 따로 챙겨야 한다니 생각만 해도 번거로웠다.

그래서 WebDAV 로컬 프록시를 선택했다. 여기서 ‘로컬’은 AList가 실행되는 서버를 가리킨다. 클라이언트는 AList에만 연결하고, AList가 바이두 넷디스크에 파일을 요청한 뒤 클라이언트에 전달한다. AList의 바이두 넷디스크 드라이버는 공식 API로 생성한 다운로드 링크에 필요한 UA 정보를 덧붙인다. 프록시 요청이 이 정보를 사용하므로 Zotero에서 직접 요청 헤더를 바꿀 필요가 없다.

두 경로를 나란히 보면 더 이해하기 쉽다.

그림: 위쪽 두 영역은 데이터와 첨부 파일의 전송 경로를 보여 준다. 302 영역은 작업 순서대로 왼쪽에서 오른쪽으로 읽으면 된다. 마지막 단계에서는 AList를 거치지 않고 바이두 넷디스크가 Zotero로 첨부 파일을 직접 전송하므로, 클라이언트가 UA 요건을 충족해야 한다. 302 비교는 다운로드에만 해당하며, 업로드는 여전히 AList를 거친다.

특히 주의할 점은 AList의 ‘웹 프록시’와 ‘WebDAV 정책’이 서로 독립된 설정이라는 것이다. 전자는 웹 미리 보기나 다운로드 등에 영향을 주며, Zotero가 사용하는 것은 후자다. ‘웹 프록시’만 켰다고 Zotero용 중계 설정까지 끝난 것은 아니다. 해당 설정은 공식 WebDAV 정책 안내를 참고하면 된다.

구체적인 설정 방법

아래에서는 AList가 이미 배포되어 있다고 가정하고, 내 도메인인 pan.xxu.do 및 마운트 경로 /Baidu를 예로 들어 설명한다. 실제로 설정할 때는 본인의 도메인과 마운트 경로로 바꿔야 한다. 버전에 따라 화면의 문구가 조금씩 다를 수 있다.

1. 바이두 넷디스크를 마운트한다. AList의 바이두 넷디스크 문서에 따라 접근 권한을 승인하고, 다운로드 API는 다음으로 선택한다: Official. 내가 AList에서 사용하는 마운트 경로는 /Baidu다. 먼저 이 폴더에서 파일 목록이 정상적으로 표시되고 파일을 업로드하고 다운로드할 수 있는지 확인한 뒤 Zotero 설정을 진행한다.
2. 해당 스토리지의 WebDAV 정책을 ‘로컬 프록시’로 설정한다. 화면에 따라 ‘본기기 프록시’처럼 표기되기도 하지만, 모두 AList가 있는 서버에서 중계한다는 뜻이다. 여기서는 302를 선택하지 않으며, 별도의 다운로드 프록시 서버를 입력할 필요도 없다.
3. Zotero용 AList 전용 계정을 만든다. 동기화 폴더의 파일을 읽고, 생성·업로드하고, 수정·삭제할 수 있게 한다. AList 문서에서는 ‘Webdav 읽기’와 ‘Webdav 관리’를 켜고 해당 기본 파일 작업 권한을 설정하도록 안내한다. 읽기 전용 계정으로는 동기화를 완료할 수 없다. 최신 AList에서는 역할 범위에서 작업 가능한 폴더를 제한해야 한다. ‘기본 경로’만 바꾸는 것으로 권한 제한을 대신할 수는 없다. 구체적인 항목 이름은 WebDAV 문서와 사용자 권한 안내를 참고하면 된다.
4. 접속 가능한 HTTPS 주소를 준비한다. 내 AList 주소는 https://pan.xxu.do이며, 동기화할 모든 기기에서 이 주소에 접속할 수 있어야 한다. 공식 모바일 앱은 암호화되지 않은 HTTP 사용을 제한하므로, 유효한 인증서를 사용하는 HTTPS로 접속하는 편이 간편하다. 이유는 Zotero의 안내를 참고하면 된다.
5. Zotero에서 WebDAV를 선택한다. 먼저 자신의 Zotero 계정으로 로그인한다. 그런 다음 ‘설정 → 동기화’에서 ‘내 라이브러리’의 첨부 파일 동기화 방식을 WebDAV로 바꾸고, AList 주소와 앞서 준비한 AList 사용자 이름 및 비밀번호를 입력한다. 여기에 입력하는 것은 바이두 계정도, Zotero 계정의 비밀번호도 아니다.

AList의 WebDAV 접속 경로는 /dav/다. 이 계정의 WebDAV 루트 폴더가 AList의 /에 해당한다면, 내 도메인에 /Baidu를 마운트한 경우 주소는 다음과 같다.

스크린샷을 보면 URL 입력란 오른쪽에 이미 /zotero/가 고정되어 표시된다. Zotero가 자동으로 덧붙이는 부분이다. 프로토콜은 https로 선택하고, 주소란에는 pan.xxu.do/dav/Baidu만 입력한다. 끝에 수동으로 zotero를 다시 붙이면 안 된다.Baidu의 대소문자는 마운트 경로와 일치해야 한다. 계정의 WebDAV 루트 폴더가 이미 /Baidu에 매핑되어 있다면, 주소란에는 pan.xxu.do/dav만 입력하고 마운트 경로를 중복해서 넣지 않는다.

입력이 끝나면 ‘서버 확인’을 누른다. 확인을 통과한 뒤 동기화를 시작한다. 주소가 덧붙는 규칙과 설정 항목은 Zotero 동기화 설정 문서와 대조해 보면 된다.

기존 첨부 파일을 옮길 때는 한 번 더 확인하기

Nutstore에서 옮겨 올 때 WebDAV 주소만 바꾸면 기존 서비스의 첨부 파일이 새 서비스로 자동 이전될 거라고 생각하면 안 된다. 특히 이전에 ‘필요할 때 다운로드’를 선택했다면, 로컬에는 문헌 항목만 있고 PDF는 기존 서비스에 남아 있을 수 있다.

더 안전한 방법은 먼저 컴퓨터 한 대에서 기존 설정을 유지한 채 첨부 파일 다운로드 방식을 ‘동기화할 때 다운로드’로 바꾸는 것이다. 다운로드가 끝날 때까지 기다린 뒤 기존 첨부 파일이 열리는지 확인한다. Zotero를 종료하고 데이터 폴더를 별도로 백업한 다음 WebDAV 주소를 바꿔, 이 컴퓨터의 로컬 첨부 파일을 새 위치로 동기화한다. 기기 간 동기화 확인이 끝나기 전까지는 기존 서비스의 파일을 남겨 둔다.

기존에 연결된 첨부 파일을 사용했다면, ‘도구 → 첨부 파일 관리’에서 저장된 첨부 파일로 변환해야 WebDAV가 이 파일들을 동기화할 수 있다. Zotero 데이터 폴더 전체를 클라우드 드라이브 클라이언트로 실시간 동기화해서는 안 된다. 사용 중인 데이터베이스 파일은 이런 방식으로 다루기에 적합하지 않다.

‘서버 확인 성공’이 모든 첨부 파일을 테스트했다는 뜻도 아니다. 실제로 한 번 더 확인해 보는 것을 권한다. 한 기기에서 작은 PDF 하나와 20 MB를 확실히 넘는 실제 첨부 파일 하나를 추가해 업로드한 뒤, 아직 이 파일들이 저장되어 있지 않은 다른 기기에서 내려받아 열어 본다. 내장 리더로 주석도 하나 추가해 반대쪽에서 확인할 수 있는지 살펴본다. 작은 파일은 정상인데 큰 첨부 파일만 실패한다면, 먼저 WebDAV가 여전히 302 방식으로 동작하고 있지 않은지 확인한다.

문헌 항목은 동기화됐는데 기존 첨부 파일이 보이지 않는다면, 먼저 Zotero 첨부 파일 동기화 문제 해결 문서에 따라 로컬 파일, 업로드 결과, 양쪽 설정을 확인한다. ‘온라인 라이브러리 대체’를 첨부 파일 이전 절차로 생각해서는 안 된다. 그것은 별개의 작업이다.

편리해지는 대신 서버가 트래픽을 감당해야 한다

로컬 프록시는 클라이언트에서 처리할 번거로운 일을 서버로 모아 준다. 그만큼 서버는 첨부 파일 전송 시 반드시 거쳐야 하는 지점이 된다.

다운로드할 때는 파일이 바이두 넷디스크에서 AList 서버로, 다시 서버에서 기기로 이동한다. 업로드는 그 반대다. 둘 중 한 구간이라도 느리거나, 패킷 손실이 많거나, 연결이 불안정하면 전체 사용 경험에 영향을 준다. 바이두 넷디스크 유료 회원이라고 해서 두 구간 모두 자동으로 최대 속도가 나오는 것은 아니다.

대역폭은 대략 계산해 볼 수 있다. 서버에서 기기로 보내는 대역폭이 10 Mbps뿐이라면 이론상 최대 속도는 약 1.25 MB/s이며, 실제로는 여기서 프로토콜 오버헤드도 빼야 한다. 일반적인 논문 파일에서는 크게 신경 쓰이지 않을 수 있지만, 여러 기기를 동시에 동기화하거나 라이브러리 전체를 옮길 때는 차이가 뚜렷하게 느껴진다.

또한 프록시로 다운로드하면 서버가 같은 첨부 파일을 수신한 뒤 다시 송신한다. 클라우드 서버의 트래픽 산정 방식과 아웃바운드 트래픽만 과금하는지 여부는 본인의 요금제에 따라 다르다. 처음에 많은 파일을 옮길 때는 클라우드 드라이브 API의 요청 제한, 리버스 프록시의 업로드 크기 제한, 시간 초과가 발생할 수도 있다. 문제가 생기면 우선 어느 구간에서 오류가 났는지 확인해야 한다. 처음부터 동시 전송 수를 늘릴 필요는 없다.

그래서 이 조합은 이미 바이두 넷디스크 유료 회원이면서, 네트워크 환경이 괜찮고 AList를 계속 실행해 둘 수 있는 기기가 있는 사람에게 잘 맞는다. 이것만을 위해 새로 유료 회원권을 사고 서버까지 빌려야 한다면 비용을 다시 따져 봐야 한다. 내게 매력적이었던 이유는 바로 이것들을 이미 쓰고 있었다는 점이다.

지금까지 써 본 느낌은 좋다

설정을 마치고 나니 오히려 평소 사용은 특별할 것이 없었다. 평소처럼 문헌을 모으고, PDF를 열고, 주석을 단 뒤 Zotero가 알아서 동기화하기를 기다리면 된다. 지금까지는 예전에 Nutstore를 쓸 때와 동기화 속도에 본질적인 차이가 없었다. 저장 방식을 바꿨다고 별도의 첨부 파일 폴더와 동기화 플러그인을 관리할 필요도 없었다.

물론 이것은 현재 내 환경에서의 경험이다. 바이두 넷디스크의 API, 인증 방식, 서버 네트워크 경로가 앞으로도 계속 같으리라는 보장은 없다. 동기화가 별도의 백업을 대신해 주는 것도 아니다.

그래도 적어도 지금은 Nutstore의 월간 무료 전송량을 다 써서 Zotero 옆에 한도 부족을 알리는 빨간 느낌표가 뜨는 일은 없다. 이미 돈을 냈고 이미 돌리고 있던 것들을 활용해, 계속 마음에 걸리던 작은 문제 하나를 해결했다. 꽤 만족스럽다.