옵시디언 3기기 동기화, 유료 결제 없이 구글 드라이브로 끝내기
안드로이드 폰과 맥은 이미 동기화되고 있는데 아이패드만 붙지 않는다면, 설정을 잘못한 것이 아닐 가능성이 큽니다. iOS는 다른 앱의 폴더를 볼트로 지정하는 방식 자체를 허용하지 않기 때문입니다.
해결은 두 갈래입니다. 월 구독료를 내고 공식 동기화를 쓰거나, 구글 클라우드 콘솔에서 OAuth 클라이언트를 직접 발급해 커뮤니티 플러그인에 물리는 것입니다. 이 글은 후자를 택했을 때 실제로 어디서 막히는지, 그리고 그 대가가 얼마나 되는지를 순서대로 정리한 기록입니다.
미리 결론부터 말씀드리면, 기술적으로는 완전히 동작합니다. 다만 "무료"의 정의를 금전 비용이 아니라 총 소요 시간으로 바꾸는 순간 판단이 달라질 수 있습니다.
1. 아이패드에서만 막히는 진짜 이유
같은 볼트를 세 기기에서 열려고 할 때, 플랫폼별로 가능한 동작이 다릅니다.
| 항목 | 안드로이드 | macOS | iPadOS |
|---|---|---|---|
| 임의 폴더를 볼트로 지정 | 가능 | 가능 | 불가 |
| 볼트 위치 선택지 | 내부 저장소 어디든 | 어디든 | iCloud Drive 또는 앱 내부 로컬 |
| 백그라운드 동기화 데몬 | 가능 | 가능 | 불가 |
안드로이드에서 서드파티 동기화 앱이 잘 동작하는 이유는 두 가지입니다. 파일 시스템에 자유롭게 접근할 수 있고, 백그라운드 서비스로 상주할 수 있기 때문입니다. macOS도 마찬가지입니다.
iOS와 iPadOS는 둘 다 막혀 있습니다. 앱은 다른 앱의 샌드박스를 읽을 수 없고, 화면에 떠 있지 않으면 대부분 실행되지 않습니다. 파일 앱에 구글 드라이브가 보이는 것은 원격 스트리밍 방식의 File Provider일 뿐이라, 노트 앱이 실시간으로 읽고 쓸 수 있는 로컬 폴더가 아닙니다.
그래서 iPad에서 가능한 모델은 하나뿐입니다.
[다른 플랫폼] 클라우드 폴더 자체를 볼트로 지정
[iPad] 앱 내부 로컬 볼트 + 플러그인이 API로 밀고 당김
이 차이를 모르면 "플러그인 설정을 잘못했나" 하며 며칠을 태우게 됩니다. 설정 문제가 아니라 구조 문제입니다.
2. 선택지 비교 — 무엇을 포기하고 무엇을 얻는가
세 기기 조합에서 현실적인 선택지는 네 가지입니다.
| 방안 | 비용 | 초기 설정 | 유지보수 | 데이터 손실 위험 |
|---|---|---|---|---|
| 공식 유료 동기화 | 월 4~5달러 | 10분 | 거의 없음 | 낮음 |
| 범용 동기화 플러그인 + S3/Dropbox | 무료 | 30분 | 중간 | 중간 |
| 구글 드라이브 전용 플러그인 (자체 OAuth) | 무료 | 1~2시간 | 중간 | 중간 |
| P2P 동기화 (Syncthing 계열) | 무료~일회성 | 1시간+ | 중간 | 중간 |
여기서 반드시 짚어야 할 함정이 하나 있습니다. 대표적인 범용 동기화 플러그인의 경우 S3, Dropbox, OneDrive, WebDAV는 무료로 지원하지만 구글 드라이브는 유료 기능입니다. "구글 드라이브를 쓰면서 무료"라는 조합이 생각보다 좁습니다.
그래서 구글 드라이브를 유지하려면 전용 플러그인을 쓰게 되는데, 여기서 다시 두 갈래가 나뉩니다.
- 개발자가 운영하는 OAuth 앱을 경유하는 방식: 토큰만 복사해 붙이면 5분이면 끝납니다. 대신 제3자 서버에 드라이브 액세스 토큰을 넘기게 됩니다.
- 본인 명의 OAuth 클라이언트를 발급하는 방식: 토큰이 외부로 나가지 않습니다. 대신 구글 클라우드 콘솔 설정을 직접 해야 합니다.
업무 관련 노트가 볼트에 들어간다면 후자가 맞습니다. 이 글은 후자를 기준으로 진행합니다.
절대 하면 안 되는 조합
가장 먼저 확인해야 할 것은 지금 쓰고 있는 방식을 걷어내는 일입니다. 서드파티 동기화 앱과 플러그인을 같은 폴더에 동시에 물리면 반드시 깨집니다.
두 엔진의 상태 모델이 다르기 때문입니다. 플러그인은 파일에 심어둔 메타데이터로 자기 파일을 식별하는데, 외부 동기화 앱이 올린 파일에는 그 표시가 없습니다. 플러그인 입장에서는 존재하지 않는 파일이 되고, 반대로 플러그인이 만든 파일은 외부 앱이 무차별적으로 내려받습니다. 어느 쪽도 상대의 변경을 추적하지 못한 채 서로를 덮어씁니다.
QA 용어로 하면 동일 리소스에 서로 다른 상태 모델을 가진 두 개의 동기화 엔진이 붙은 상태입니다. 설정으로 해결되는 문제가 아니라 설계 충돌입니다.
3. 구글 클라우드 콘솔 설정 — 2026년 개편판
여기가 전체 작업의 대부분을 차지합니다. 인터넷에 도는 대부분의 가이드가 구버전 UI 기준이라 그대로 따라 하면 화면이 다릅니다. 콘솔이 Google Auth Platform으로 재편되면서 순서 자체가 바뀌었습니다.
| 예전 절차 | 현재 절차 |
|---|---|
| OAuth 동의 화면에서 다단계 진행 | 시작하기 마법사 1페이지 4단계 |
| 동의 화면 안에서 범위·게시 상태 설정 | 브랜딩 / 대상 / 데이터 액세스 / 클라이언트 4개 탭으로 분리 |
3-1. 실제 진행 순서
시행착오 끝에 정리한 순서입니다. 이 순서가 되돌아가는 횟수가 가장 적었습니다.
1. 프로젝트 생성
2. Drive API 사용 설정
3. 시작하기 마법사 완료 (앱 이름 / 대상 / 연락처)
4. 데이터 액세스 탭 → 범위 추가
5. 브랜딩 탭 → 홈페이지·약관·개인정보처리방침·로고
6. 대상 탭 → 앱 게시 (프로덕션 전환)
7. 클라이언트 탭 → OAuth 클라이언트 생성
마법사는 중간에 다른 페이지로 이동하면 미완료 상태로 종료되어 처음부터 다시 해야 합니다. 한 번에 끝까지 진행하시는 편이 낫습니다.
또 하나. 대상 선택에서 External과 Internal은 한 번 정하면 바꿀 수 없습니다. 바꾸려면 프로젝트를 새로 만들어야 합니다. 개인 계정이라면 선택지는 External 하나입니다.
3-2. 클라이언트 유형이 첫 번째 함정
애플리케이션 유형 드롭다운에서 TV 및 제한된 입력 장치를 골라야 합니다. 데스크톱 앱이나 웹 애플리케이션을 고르면 인증 시도 시 401 invalid_client가 떨어집니다.
이 유형을 쓰는 이유는 디바이스 인증 플로우 때문입니다. 브라우저 리디렉션 없이 화면에 뜬 코드를 다른 기기에서 입력하는 방식이라, 태블릿이나 폰처럼 리디렉션 처리가 까다로운 환경에서 유일하게 깔끔하게 동작합니다.
제대로 골랐다면 승인된 리디렉션 URI 입력란이 아예 나타나지 않습니다. 그 칸이 보인다면 유형을 잘못 고른 것입니다.
3-3. 게시 상태가 두 번째 함정 — 그리고 가장 비싼 함정
여기를 놓치면 일주일 뒤에 모든 기기에서 로그아웃됩니다.
게시 상태를 기본값인 "테스트"로 두면, 테스트 사용자의 승인이 동의 시점으로부터 7일 후 만료됩니다. 오프라인 액세스로 받은 갱신 토큰도 함께 만료됩니다. 기기 세 대를 매주 재인증해야 한다는 뜻이고, 실사용이 불가능합니다.
따라서 대상 탭에서 앱 게시를 눌러 프로덕션으로 전환해야 합니다. 게시 후에도 7일 만료가 재현된다면 클라이언트를 새로 만들어야 한다는 보고가 있으니, 게시를 먼저 하고 클라이언트를 나중에 만드는 순서를 권합니다.
3-4. 게시하려면 웹사이트가 필요합니다
여기서 예상하지 못한 비용이 발생합니다. 프로덕션 게시를 누르면 브랜딩 정보가 미완료라는 안내가 뜹니다. 요구되는 항목은 다음과 같습니다.
| 항목 | 필수 여부 |
|---|---|
| 앱 이름 / 지원 이메일 / 개발자 연락처 | 필수 |
| 애플리케이션 홈페이지 URL | 게시 시 필수 |
| 개인정보처리방침 URL | 게시 시 필수 |
| 서비스 약관 URL | 게시 시 필수 |
| 승인된 도메인 | 위 URL 입력 시 필수 |
| 로고 (정사각형 PNG) | 브랜딩 인증 시 필요 |
개인 볼트 하나 동기화하려고 웹사이트와 개인정보처리방침을 만들어야 하는 상황입니다. 다행히 정적 페이지 호스팅을 쓰면 무료로 해결됩니다. 저장소 루트에 세 개의 HTML 파일만 두면 됩니다.
저장소 루트/
├── index.html ← 앱 설명 + 나머지 두 링크 포함 (필수)
├── privacy.html ← 개인정보처리방침
└── terms.html ← 서비스 약관
index.html이라는 파일명은 바꿀 수 없습니다. 정적 호스팅이 루트 접속 시 자동으로 찾는 기본 파일이기 때문입니다.
구글이 요구하는 조건도 명확합니다. 홈페이지는 로그인 없이 공개적으로 접근 가능해야 하고, 검토 대상 앱과의 관련성이 분명해야 합니다. 개인정보처리방침은 홈페이지와 같은 도메인에 있어야 하며, 홈페이지에서 링크되어 있어야 합니다. 가장 흔한 반려 사유가 "홈페이지에 개인정보처리방침 링크가 없음"입니다.
개인정보처리방침에는 최소한 이 내용이 들어가야 합니다.
1. 어떤 범위의 구글 사용자 데이터에 접근하는가
2. 그 데이터를 어떤 목적으로 사용하는가
3. 어디에 저장하고 누구에게 전송하는가
4. 사용자가 권한을 철회하는 방법
3-5. 승인된 도메인은 콘솔이 알려줍니다
정적 호스팅 서비스의 공통 도메인을 입력하면 거부됩니다. 공용 접미사 목록에 등록된 도메인은 최상위 사설 도메인으로 취급되지 않기 때문입니다.
이 부분은 고민할 필요가 없습니다. 콘솔이 "누락된 도메인"으로 정확한 값을 직접 제안해 줍니다. 제안된 값을 그대로 추가하시면 됩니다.
잘못된 입력: example.io
콘솔 제안값: <계정명>.example.io ← 이것이 정답
3-6. "앱을 인증해야 합니다"는 오류가 아닙니다
게시 직후 인증(verification)을 요구하는 안내가 뜹니다. 여기서 많이들 당황하는데, 게시 상태와 브랜드 인증은 별개의 절차입니다.
| 구분 | 게시 상태 | 브랜드 인증 |
|---|---|---|
| 목적 | 프로덕션 전환 | 동의 화면에 로고·앱 이름 표시 |
| 갱신 토큰 7일 만료 | 해소됨 | 무관 |
| 개인 사용 시 | 필요 | 면제 대상 |
구글 문서는 면제 사유를 명시하고 있습니다. 본인이 유일한 사용자이거나 개인적으로 아는 소수만 사용하는 경우, 검토를 위해 제출할 필요가 없습니다. "확인되지 않은 앱" 경고 화면을 넘기고 사용하면 됩니다.
오히려 인증을 제출하면 곤란해집니다. 인증 진행 중에는 브랜딩 수정이 차단되고, 검색 콘솔을 통한 도메인 소유권 확인까지 요구됩니다. 개인용이라면 제출하지 않는 편이 낫습니다.
경고 화면은 기기당 최초 1회만 넘기면 되고, 이후에는 갱신 토큰이 유지되므로 다시 나타나지 않습니다.
4. 3기기 마이그레이션과 운영 규칙
콘솔 작업이 끝나면 나머지는 단순합니다. 원칙은 하나입니다. 기준 기기 하나를 정해 클라우드에 올린 뒤, 나머지는 내려받기만 합니다.
데스크톱(기준) → 클라우드 업로드
↓
모바일 내려받기 → 검증
↓
태블릿 내려받기 → 검증
4-1. 데스크톱 — 이동이 아니라 복사
가장 중요한 원칙은 원본을 남기는 것입니다.
# 볼트 경로 확인 후 zip 백업
zip -rq ~/Desktop/vault-backup-$(date +%Y%m%d).zip "볼트경로"
# 이동이 아니라 복사. 원본은 검증 끝날 때까지 유지
cp -R "기존볼트경로" ~/Documents/ObsidianVault
# 숨김 폴더까지 따라왔는지 확인
ls -la ~/Documents/ObsidianVault/.obsidian
기존 볼트를 클라우드 폴더에서 잘라내기로 옮기면, 동기화 클라이언트가 이를 삭제로 해석해 클라우드에서도 지울 수 있습니다. 복사한 뒤 원본은 그대로 두십시오.
볼트를 옮긴 뒤 앱에서 새 위치를 열어야 합니다. 볼트 전환은 좌측 하단 금고 아이콘 또는 파일 메뉴의 볼트 열기에서 할 수 있습니다.
4-2. 세 기기의 볼트 이름을 통일
이 플러그인 계열은 볼트 이름을 식별자로 씁니다. 세 기기의 폴더명이 다르면 서로 다른 볼트로 인식합니다. 기준 기기에서 이름을 정한 뒤 나머지 두 대에서 정확히 같은 이름으로 빈 볼트를 만드십시오.
기존 볼트를 열어놓고 진행하면 충돌이 납니다. 반드시 빈 볼트에서 시작합니다.
4-3. 태블릿에서 반드시 확인할 것
새 볼트를 만들 때 클라우드 저장 옵션을 꺼야 합니다. 켜두면 시스템 클라우드와 플러그인이 같은 볼트를 동시에 건드리는 이중 동기화가 되어, 앞서 설명한 문제가 그대로 재현됩니다.
파일 앱에서 볼트가 기기 내부 저장소 아래에 있는지 확인하시면 됩니다. 클라우드 드라이브 아래에 있다면 삭제하고 다시 만드십시오.
4-4. 모바일 자격증명 입력에서 막힌다면
기기 한 대만 401이 뜬다면 콘솔 설정은 정상이라는 뜻입니다. 원인은 대개 입력 단계에 있습니다.
| 순위 | 원인 | 대응 |
|---|---|---|
| 1 | 붙여넣기 시 앞뒤 공백·줄바꿈 혼입 | 필드를 완전히 비우고 재입력 |
| 2 | 자동 대문자·자동 수정으로 문자 변형 | 시스템 키보드 설정에서 두 옵션 끄기 |
| 3 | 서로 다른 클라이언트의 ID와 시크릿 혼용 | 콘솔에서 클라이언트 개수 확인 |
두 번째가 특히 잘 걸립니다. 시크릿은 대소문자가 섞인 랜덤 문자열이라 자동 대문자가 켜져 있으면 첫 글자가 바뀌는데, 화면상으로는 멀쩡해 보여서 눈으로 찾기 어렵습니다.
세 번째도 흔합니다. 게시 순서 때문에 클라이언트를 두 번 만들었다면, A의 ID와 B의 시크릿을 섞어 쓰게 됩니다. 이미 인증을 마친 기기는 갱신 토큰을 갖고 있어 계속 잘 동작하기 때문에 "한 대만 안 되는" 증상으로 나타납니다.
4-5. 검증 없이 원본을 지우지 마십시오
기기를 추가할 때마다 왕복 테스트를 거치는 것을 권합니다.
□ 노트 총 개수가 기준 기기와 일치하는가
□ 최근 노트 3개의 내용이 온전한가
□ 첨부 이미지가 깨지지 않았는가
□ 새 노트 생성 → 다른 기기에 반영되는가
□ 수정 → 반영되는가
□ 삭제 → 양쪽에서 사라지는가
이 여섯 항목을 통과한 뒤에 기존 동기화 앱을 제거하십시오. 백업 zip은 최소 한 달 보관하시는 편이 안전합니다.
4-6. 동기화 모델을 이해해야 운영이 편합니다
이 방식에는 푸시와 풀 버튼이 따로 없습니다. 방향을 지정하는 대신 매니페스트를 비교합니다.
로컬 파일 목록·수정 시각 ↔ 원격 파일 목록·수정 시각
→ 로컬에만 새 변경 → 업로드
→ 원격에만 새 변경 → 다운로드
→ 양쪽 모두 변경 → 충돌 정책에 따라 처리
한 번의 동기화에서 업로드와 다운로드가 동시에 일어납니다. 그래서 실행 명령이 하나뿐입니다. 방향을 강제하는 명령은 한쪽을 통째로 덮어쓰는 파괴적 동작이므로, 최초 마이그레이션 이후에는 쓸 일이 없습니다.
동기화 명령은 커맨드 팔레트에 등록되므로 설정 화면에 매번 들어갈 필요가 없습니다. 데스크톱은 단축키를 지정하고, 모바일은 툴바에 아이콘을 꺼내두면 두 번의 동작으로 실행됩니다.
4-7. 모바일 자동 동기화의 한계
이것만은 명확히 알고 계셔야 합니다.
모바일에서는 앱이 화면에 떠 있을 때만 자동 동기화가 돕니다. 플러그인은 앱 내부에서 실행되므로, 백그라운드 서비스로 상주하던 기존 방식과 다릅니다.
| 시점 | 행동 |
|---|---|
| 모바일에서 노트 열기 전 | 앱 실행 후 몇 초 대기 |
| 편집 후 앱 나가기 전 | 수동 동기화 1회 실행 |
| 기기 전환 시 | 이전 기기 동기화 완료 확인 후 이동 |
특히 메모하고 바로 화면을 끄는 습관이 있다면 업로드가 잘릴 수 있습니다. 동기화 버튼을 한 번 누르는 것을 루틴으로 만드시는 편이 안전합니다.
안드로이드에서 자주 끊긴다면 배터리 최적화 예외 처리를 확인해 보십시오.
마치며 — 이 방법을 권할 수 있는 조건
동작은 합니다. 세 기기에서 같은 볼트를 문제없이 쓰고 있습니다. 하지만 권할 수 있는 조건은 좁습니다.
권할 만한 경우 - 볼트에 민감한 업무 정보가 있어 제3자 서버 경유를 피하고 싶은 경우 - 클라우드 인증 구조를 직접 이해하고 통제하고 싶은 경우 - 설정 과정 자체를 학습 기회로 볼 수 있는 경우
권하지 않는 경우 - 노트를 쓰는 것이 목적이고 도구 설정에 시간을 쓰고 싶지 않은 경우 - 동기화가 끊겼을 때 원인을 추적할 여유가 없는 경우 - 볼트에 대체 불가능한 자료가 있고 백업 습관이 없는 경우
솔직하게 덧붙이면, 이 경로를 택하는 대가는 금전이 아니라 시간과 유지보수 부담입니다. 커뮤니티 플러그인은 개인 개발자가 유지하는 경우가 많고, 릴리스 빈도가 높다는 것은 아직 안정화 전이라는 신호이기도 합니다. 개발자 본인이 문서에서 백업을 권고하고 데이터 손실에 책임지지 않는다고 밝히는 경우도 흔합니다.
그럼에도 이 글을 정리한 이유는, 막힌 지점이 "내가 뭔가 잘못했다"가 아니라 플랫폼 제약과 콘솔 개편이라는 사실을 아는 것만으로도 시간을 크게 아낄 수 있기 때문입니다.
마지막으로 하나만 남깁니다. 어떤 방식을 택하시든, 주기적인 볼트 백업을 자동화해 두십시오.
#!/bin/bash
# 주간 볼트 백업 — 창 배치 파일은 제외
VAULT="$HOME/Documents/ObsidianVault"
DEST="$HOME/Backups/obsidian"
mkdir -p "$DEST"
zip -rq "$DEST/vault-$(date +%Y%m%d).zip" "$VAULT" -x "*/.obsidian/workspace*"
# 8주 경과분 정리
find "$DEST" -name "vault-*.zip" -mtime +56 -delete
# crontab — 매주 일요일 오전 3시
0 3 * * 0 /bin/bash $HOME/bin/vault-backup.sh
동기화는 백업이 아닙니다. 한쪽에서 지운 파일은 다른 쪽에서도 지워집니다.
댓글
댓글 쓰기