전체 스캔 동기화는 변경 추적 없이 매 실행마다 전체 파일 상태를 비교해 미러링하는 동기화 방식입니다. 구현이 단순하고 상태 관리가 필요 없어 주기적 배치 작업에 적합하며, 파일 수가 많지 않고 빈도가 낮은 경우 안정성을 보장합니다.
이 방식은 원본의 전체 파일 트리를 매번 읽어 대상의 상태를 그에 맞춰 일치시킵니다. 증분 동기화와 달리 마지막 동기화 시점이나 변경 토큰을 유지할 필요가 없습니다. 대신 각 실행에서 원본의 현재 전체 목록을 기준으로 대상의 파일을 추가, 수정, 삭제하여 최종 상태를 동기화합니다.
핵심 메커니즘은 상태 비교에 있습니다. 원본 파일 시스템의 계층 구조를 재귀적으로 탐색해 파일 메타데이터와 내용을 수집합니다. 그 후 대상 파일 시스템의 기존 상태와 비교하여 추가되거나 변경된 파일은 복사하고, 원본에 존재하지 않는 파일은 대상에서 제거합니다. 이는 rsync --delete나 미러링 도구의 기본 동작과 유사합니다.
Google Drive API를 이용한 문서 동기화 작업에서 이 방식을 선택한 이유는 실행 빈도(하루 1회)와 규모(문서 수가 수백 개 수준)에서 전체 스캔의 오버헤드가 허용 가능했기 때문입니다. 구현 복잡도를 낮추고 안정성을 높이는 트레이드오프로, 증분 동기화가 제공하는 실시간성이나 효율성 대신 운영 단순성을 취한 것입니다.
전체 스캔 동기화가 적합한 조건은 동기화 주기가 비교적 길고(예: 매일, 매주), 원본의 파일 총량이 많지 않아 스캔 시간과 API 호출 횟수가 부담되지 않으며, 삭제 작업도 정확히 반영되어야 하는 미러링 시나리오입니다. 또한 변경 토큰 관리나 증분 쿼리 API의 복잡성을 피하고 싶을 때 유용합니다.
반면 증분 동기화가 더 나은 조건은 실시간에 가까운 빈도로 동기화해야 하거나, 파일 트리가 매우 크거나 깊어 전체 스캔 비용이 높을 때입니다. 또한 원본 시스템이 안정적인 변경 히스토리 API를 제공하고, 동기화 클라이언트가 상태를 지속적으로 저장할 수 있을 때 적합합니다.
전체 스캔 방식의 주요 위험은 원본 시스템의 부하 증가와 대량 삭제의 오작동입니다. 매번 전체 목록을 요청하면 원본 서버에 부하를 줄 수 있으며, 비교 로직에 오류가 있거나 원본 접근 실패 시 대상 파일이 잘못 삭제될 수 있습니다. 따라서 삭제 전 이중 확인이나 dry-run 모드 지원이 권장됩니다. Google Drive 동기화에서는 .pending 같은 시스템 예외 파일을 명시적으로 보존하는 안전장치를 추가했습니다.
이 방식을 일반화하면, 주기성과 규모가 낮을 때 구현 복잡도를 줄이는 유효한 전략입니다. 시스템 설계에서 '단순함'과 '효율성' 사이의 선택은 실행 빈도와 데이터 규모에 따라 결정됩니다. 하루 한 번 실행되는 cron job은 효율보다는 오류 가능성을 낮추는 구현이 더 가치 있을 수 있습니다.
이 주제와 관련하여 Google Drive API, 상태 기반 동기화와 연산 기반 동기화, Cron 작업 설계 등을 참고할 수 있습니다.
아직 해결되지 않은 질문으로는 Google Drive의 changes.list와 전체 files.list의 실제 성능 차이가 어느 정도인지, 그리고 파일 수가 수천 개를 넘어갈 때 전체 스캔의 실행 시간 한계는 어디쯤인지 등이 있습니다.