Hacker News, Backblaze의 OneDrive·Dropbox 제외를 조용한 정책 변경이 아닌 신뢰 문제로 본다

왜 Hacker News가 크게 반응했나

이번 글이 Hacker News에서 크게 번진 이유는 OneDrive나 Dropbox 자체보다 backup client에 대한 신뢰 계약이 흔들렸다고 받아들여졌기 때문이다. 크롤링 시점의 토론은 681점, 419개 댓글이었고, 반응의 중심은 “이제 무엇을 백업하지 않는가”보다 “왜 이런 변화가 조용히 들어갔는가”에 있었다. 실제 댓글에서도 Dropbox가 덮어쓴 파일을 Backblaze가 지켜줬을 것이라 믿었다가, 정책 변경을 뒤늦게 알고 복구에 실패했다는 경험담이 나왔다. HN은 이 사건을 설정 화면의 사소한 옵션 조정이 아니라, 백업 서비스가 사용자에게 주는 가장 중요한 약속이 흔들린 사례로 읽었다.

원문 글이 지적한 핵심

링크된 글에서 Robert Reese는 Backblaze가 어느 시점부터 자신의 OneDrive 폴더를 백업하지 않았고, 그보다 앞서 .git 디렉터리도 제외되기 시작했다고 설명한다. 그는 Backblaze release notes에 적힌 문구를 근거로, 백업 클라이언트가 이제 OneDrive, Google Drive, Dropbox, Box 등 주요 cloud-storage provider의 mount point와 cache directory를 제외하며, 이는 local storage와 직접 연결된 storage만 백업한다는 정책과 맞춘 것이라고 짚는다. Reese의 주장은 단순하다. sync는 backup이 아니다. cloud-sync 폴더는 삭제, 덮어쓰기, 계정 정지 같은 사고에서 충분한 복구 수단이 되지 못할 수 있는데, 사용자는 바로 그 마지막 안전망 때문에 backup client를 돈 주고 쓴다는 것이다.

왜 기술적으로는 복잡한가

HN 댓글은 이 문제의 다른 면도 짚었다. files-on-demand가 켜진 OneDrive나 Dropbox는 겉보기에는 거대한 로컬 폴더처럼 보여도, 실제로는 placeholder만 있고 파일이 전부 내려와 있지 않을 수 있다. 이 상태에서 backup client가 폴더 전체를 진짜 로컬 데이터로 간주하면 대량 다운로드를 유발하거나, 작은 SSD를 순식간에 가득 채우거나, 불완전한 상태를 백업하려 들 수 있다. 즉 vendor가 이런 디렉터리를 별도로 다루고 싶어 하는 이유 자체는 이해 가능하다. 하지만 HN의 결론은 다르다. 기술적으로 까다로운 문제일수록 더 큰 경고와 더 명시적인 제어가 필요하지, 사용자가 disaster recovery를 해보는 순간까지 모르도록 두면 안 된다는 것이다.

왜 중요한가

이 사례가 고신호인 이유는 backup, sync, 가상 로컬 저장소의 경계가 흐려진 시대의 사용자 기대를 드러내기 때문이다. 오늘날 중요한 작업 파일은 cloud-managed folder, sparse file, app-owned cache를 거치기 쉽고, 그래서 “내 컴퓨터를 통째로 백업한다”는 문구는 예전보다 훨씬 더 모호해졌다. 하지만 사용자 기대치는 그대로다. 중요한 폴더가 있으면 backup 대상일 것이라 믿는다. HN이 격하게 반응한 이유도 여기에 있다. 서비스가 더 좁은 정의를 쓰고 싶다면, 복구 범위가 어디까지인지 훨씬 더 크게 드러내야 하고, 예외가 생겼을 때는 “아무 일도 없던 것처럼” 넘어가서는 안 된다는 것이다.

출처: Robert Reese 글 · Hacker News 토론