iCloud 동기화가 멈췄는데 진단은 전부 "정상"이었습니다 — 사내망이 업로드만 막을 때

안녕하세요. Jay입니다!

노트북 두 대에서 같은 옵시디언 볼트를 씁니다. 동기화는 iCloud Drive에 맡겨두고 몇 달째 잘 쓰고 있었죠. 그런데 아침에 한쪽에서 정리한 내용이 다른 쪽에 나타나지 않았습니다.

파일이 안 오는 것보다 답답했던 건, 양쪽에서 진단할 때마다 "정상"이라는 답만 돌아왔다는 점이었습니다. 원인을 찾는 데 4시간이 걸렸습니다.

🔍 증상 — 나중에 만든 파일은 오는데, 먼저 만든 파일이 안 온다

처음엔 단순 지연이라고 생각했습니다. 그런데 시각을 맞춰보니 이상했습니다.

시각	무엇	도착
07:51	A 노트북에서 문서 5개 편집	❌
08:19	A 노트북의 앱 설정 파일 변경	✅

나중에 바뀐 08:19 파일은 왔는데, 먼저 바뀐 07:51 파일은 안 왔습니다. 큐가 밀렸다면 순서대로 오거나 늦게라도 따라잡아야 하는데 그렇지 않았죠. 단순 지연이 아니라는 첫 단서였습니다.

🩺 진단 — 지표가 전부 "정상"이라고 답했다

macOS에서 iCloud Drive 상태를 보는 방법은 몇 가지가 있습니다. 전부 돌려봤습니다.

점검	결과	실제로는
brctl status	caught-up ✅	밀려 있었음
bird 프로세스 CPU	0.0% ✅	할 일이 없어서 조용했던 것
미다운로드 placeholder	0건 ✅	애초에 안 온 파일은 placeholder도 안 생김
충돌 사본	없음 ✅	충돌할 파일 자체가 없었으니
디스크 여유	362GB ✅	무관

bird CPU가 0%인 걸 보고 저는 "큐가 비었으니 정상"이라고 읽었습니다. 정반대였습니다. 받을 게 없어서 조용했던 거지, 조용해서 정상인 게 아니었죠.

노트북 재시동도 해봤지만 그대로였습니다. 데이터를 옮기는 통로가 막힌 상황에서, 통로 양쪽 끝에 있는 계기판만 들여다본 셈입니다.

🎯 결정적 단서 — 계기판 말고 파일을 직접 본다

방향을 바꿔서 양쪽 노트북의 같은 파일을 직접 대조했습니다.

stat -f "%Sm %N" -t "%m/%d %H:%M:%S" "문서.md"

A 노트북은 오늘 07:51, B 노트북은 8월 31일. 바이트가 한 번도 건너온 적이 없다는 뜻입니다. 대시보드가 뭐라고 하든 이건 반박이 안 되는 사실이죠.

여기에 하나가 더 겹쳤습니다. 8월 25일자 옛 파일 사본이 그날 아침에야 뒤늦게 올라와 충돌 사본을 만들었습니다. 오래된 건 올라오는데 오늘 것은 안 온다 — 업로드 큐가 특정 지점에서 막혀 있다는 신호였습니다.

🕵️ 원인 — 사내망이 업로드만 차단하고 있었다

결정타는 우연히 나왔습니다. 네트워크를 의심해 휴대폰 핫스팟으로 바꿨더니, 밀려 있던 파일이 1분 만에 전부 올라왔습니다.

원인은 회사 네트워크였습니다. 정확히는 이렇게 동작하고 있었죠.

• 다운로드는 정상 — 그래서 남이 올린 파일은 잘 받았고, 겉보기에 iCloud가 살아 있었습니다
• 업로드만 차단 — 내가 만든 변경은 나가지 못하고 큐에 쌓였습니다

이게 모든 진단이 "정상"이었던 이유입니다. 로컬 데몬 입장에서는 아무 문제가 없습니다. 연결도 되고, 받기도 하고, 에러도 없죠. 막힌 건 로컬이 아니라 그 바깥이었으니까요.

기업 네트워크가 개인 클라우드 스토리지 업로드를 막는 건 드문 일이 아닙니다. 자료 유출 방지 목적이죠. 문제는 그게 조용히 막힌다는 점입니다. 차단 안내 페이지도, 에러 코드도 없습니다.

🔧 해결 — 통로를 바꿨습니다

핫스팟으로 그때그때 밀어내는 건 임시방편입니다. 핫스팟을 끄는 순간 다시 막히니까요. 실제로 창이 열린 1분 동안만 파일이 오갔고, 그 뒤에 만든 파일은 또 안 왔습니다.

그래서 동기화 통로 자체를 git으로 옮겼습니다.

	iCloud	git
사내망	❌ 업로드 차단	✅ HTTPS(443)는 열림
실패 인지	조용히 멈춤	명령이 즉시 실패
이력	없음	전부 복구 가능

사내망에서 개인 클라우드는 막혀도 GitHub는 열려 있는 경우가 많습니다. 개발 업무에 필요하니까요. 볼트를 저장소로 만들고 양쪽에서 pull·push 하도록 바꾸니, 4시간 걸리던 왕복이 몇 초로 끝났습니다.

무엇보다 실패했을 때 실패한 걸 알 수 있게 됐습니다. git push가 막히면 그 자리에서 에러가 뜹니다. 조용히 4시간을 흘려보낼 일이 없죠.

💡 Jay의 정리 — 계기판을 의심해야 할 때

이번에 제가 배운 건 진단 도구를 읽는 순서였습니다.

믿기 어려운 신호 — 상태 요약(caught-up), 프로세스 CPU 사용률, 에러 로그 없음. 이것들은 "내가 아는 한 문제없다"는 뜻이지 "문제없다"가 아닙니다. 시스템의 시야 밖에서 막히면 전부 정상으로 보입니다.

믿을 수 있는 신호 — 실제 결과물의 상태. 파일 수정 시각, 내용 해시, 목적지에 실제로 있는지 여부. 중간 과정이 뭐라고 하든 최종 산출물은 거짓말을 못 합니다.

그래서 같은 증상을 만나면 이제 30초 만에 판별합니다. 한쪽에서 테스트 파일을 하나 만들고, 1~2분 안에 반대쪽에 오는지 봅니다. 안 오면 확정이고, 그때부터 네트워크를 의심하면 됩니다. 계기판은 그다음에 봐도 늦지 않습니다.

결론

동기화가 멈췄는데 모든 진단이 정상이라면, 진단 도구의 시야 밖을 의심할 차례입니다. 특히 회사 네트워크에서는 개인 클라우드 업로드가 조용히 막혀 있을 수 있습니다.

확인은 간단합니다. 테스트 파일 하나를 만들어 반대쪽에서 기다려보세요. 그리고 네트워크를 바꿔서 다시 해보면 답이 나옵니다. 저는 이 두 가지를 먼저 하지 않아서 4시간을 썼습니다.

다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!