OneDrive: Path is too long to sync
안녕하세요, BlueByte입니다. OneDrive 폴더의 어떤 파일이 초록 동기화 체크 대신 빨간 X로 표시되고, OneDrive가 Path is too long to sync라고 알립니다. 파일은 멀쩡하고 잃는 것도 없습니다 — OneDrive가 강제하는 한도보다 전체 경로가 긴 파일의 동기화를 거부한 것뿐입니다. 오늘은 이 메시지가 뜻하는 것, 그것을 결정하는 글자 수 한도, 초과 파일을 찾는 법, 안전하게 줄이는 법, 그리고 폴더를 한도 아래로 유지하는 법까지 하나씩 짚어보겠습니다.
"Path is too long to sync"가 뜻하는 것
OneDrive는 이것을 항목별 동기화 오류로 표시합니다: 파일이 파일 탐색기에서 빨간 X가 되고, OneDrive 작업 센터(Activity Center)에 Path is 32 characters too long 같은 메모로 나타납니다. 이 메시지는 고정 임계값이 아니라 초과량을 알려주고, 충분히 줄이면 초록 체크와 함께 Path is short enough to sync로 바뀝니다. 파일 자체는 그대로입니다 — OneDrive가 업로드를 거절하는 것이지 손상시키는 게 아닙니다. 그래서 아무것도 삭제하지 않고 고칠 수 있습니다.
경로 동기화 여부를 결정하는 숫자 — 400, 120, 520
Microsoft 문서의 세 가지 한도가 이를 좌우합니다:
- 파일 이름을 포함한 디코딩된 전체 경로는 400자를 넘을 수 없습니다 — OneDrive(개인 및 회사·학교)와 SharePoint에서.
- 전체 로컬 경로는 로컬 경로(최대 400자)와 OneDrive 루트 폴더(최대 120자)의 합입니다.
- 520자를 넘는 경로는 동기화 오류를 표시하며, 한도 아래로 되돌리기 전까지 OneDrive는 그 항목을 동기화하지 않습니다.
여기서 "디코딩"이 중요합니다: 공백 같은 문자는 인코딩되면 길어질 수 있고, 그 하나하나가 합계에 들어갑니다. 길고 서술적인 이름의 깊게 중첩된 폴더가, 아무도 눈치채지 못한 사이 파일 하나를 400자 너머로 넘기는 흔한 경로입니다.
어떤 파일이 한도를 넘었는지 확인하기
손으로 찾지 말고 PowerShell로 초과 파일을 나열하세요. PowerShell을 열고 OneDrive 폴더로 이동한 뒤, 400자보다 긴 경로를 모두 출력합니다:
cd "$env:OneDrive"
Get-ChildItem -Recurse -Force | Where-Object { $_.FullName.Length -gt 400 } |
Select-Object @{ n = 'Length'; e = { $_.FullName.Length } }, FullNameLength FullName
------ --------
431 C:\Users\you\OneDrive\Projects\2026\Q3\ClientDeliverables\Draft\final_v3_reviewed.xlsx각 행은 전체 경로가 문제인 파일입니다. Length로 정렬하면 얼마나 초과했는지 보이고, 그만큼 줄이면 됩니다.
이름을 바꾸거나 옮겨 경로 줄이기
Microsoft는 두 가지 해결을 제시하며 둘 다 내용을 보존합니다. 파일이나 그 위 폴더의 이름을 더 짧게 바꾸면, OneDrive 알림이 실시간으로 갱신되어 한도 아래로 내려가는 순간 Path is short enough to sync로 바뀝니다. 또는 항목을 OneDrive 위쪽, 더 얕은 폴더로 옮기세요:
Move-Item "$env:OneDrive\Projects\2026\Q3\ClientDeliverables\Draft\final_v3_reviewed.xlsx" "$env:OneDrive\Projects\final_v3.xlsx"한두 폴더 위로만 올려도 대개 경로가 400자 아래로 내려갑니다. 아무것도 삭제할 필요 없고 내용도 잃지 않습니다 — 파일 자체가 아니라 파일이 놓인 위치만 바꾸는 것입니다.
실제 사례: 동료가 보낸 깊은 export
동료가 프로젝트 아카이브를 공유해 트리 전체를 OneDrive\Projects에 넣습니다. 스프레드시트 하나가 동기화되지 않습니다 — 빨간 X, Path is too long to sync. 위 스캔을 돌리니 길고 자동 생성된 이름으로 다섯 폴더 깊이에 묻힌 경로 하나가 431자로 나옵니다. 파일 이름만 바꿔선 부족해, 부모 폴더를 Projects\2026\Q3\ClientDeliverables\Draft\에서 Projects\Q3-draft\로 올립니다. 스캔은 이제 아무것도 반환하지 않고, 빨간 X가 초록 체크로 바뀌며, 스프레드시트가 업로드됩니다.
파일이 동기화되고 클라이언트가 따라잡는지 확인하기
파일 탐색기에서 파일 아이콘을 보세요: 초록 체크(또는 "클라우드에서 사용 가능" 아이콘)면 동기화된 것입니다. 스캔을 다시 돌려 400자를 넘는 경로가 남지 않았는지 확인하세요:
(Get-ChildItem "$env:OneDrive" -Recurse -Force | Where-Object { $_.FullName.Length -gt 400 }).Count00이 나오고 OneDrive 아이콘이 "동기화 보류"가 아니라 "최신 상태"로 돌아오면, 모든 경로가 한도 아래이고 클라이언트가 따라잡은 것입니다.
경로를 한도 아래로 유지하기
폴더 트리를 얕게, 이름을 짧게 유지하세요. 특히 위쪽은 OneDrive 루트가 이미 예산의 일부를 쓰고 있으니 더 그렇습니다. 깊은 아카이브 전체가 아니라 필요한 부분만 하위 폴더 단위로 동기화하세요. 길고 기계가 붙인 이름의 export나 다운로드를 가져올 땐 OneDrive에 넣기 전에 짧은 폴더로 펼쳐 정리하세요. 긴 경로를 자주 다룬다면 가장 깊은 프로젝트를 루트 가까이 두어, 하위 폴더 몇 개가 더 붙어도 400자를 넘지 않게 하세요.
invalid-character·storage-full 오류와 다른 점
경로 길이 차단은 오직 전체 길이에 관한 것입니다. invalid-character 동기화 오류와는 다릅니다 — 그건 이름에 " * : < > ? / \ | 중 하나, CON이나 NUL 같은 예약 이름, 또는 앞뒤 공백이 들어간 경우이고, 거기선 깊이가 아니라 문자를 고칩니다. storage-full 오류와도 다릅니다: OneDrive가 공간이 없다고 하면 아무리 줄여도 소용없고, 공간을 비우거나 늘려야 합니다. 정확한 메시지를 읽으세요: "too long"이면 경로를 줄이고, "invalid characters"면 이름을 고치고, "full"이면 자리를 만드세요.
관련 질문
왜 폴더의 나머지는 잘 동기화되는데 파일 하나만 실패하나요?
그 파일의 전체 경로만 400자를 넘고 이웃은 아래였기 때문입니다 — 대개 같은 깊이에서 파일 이름이 더 긴 경우입니다. 그 파일 이름을 줄이거나 한 단계 위로 옮기세요.
400자에 무엇이 포함되나요 — 파일 이름만?
디코딩된 전체 경로입니다: 모든 폴더와 파일 이름, 그 위에 OneDrive 루트 폴더(최대 120자)까지. 긴 폴더 트리 깊숙한 짧은 파일 이름도 초과일 수 있습니다.
이름을 바꾸거나 옮기면 데이터나 버전 기록이 사라지나요?
아니요. 파일이 놓인 위치나 이름을 바꾸는 것이지 내용을 바꾸는 게 아닙니다. 경로가 충분히 짧아지면 OneDrive가 파일을 그대로 두고 동기화합니다.
400자 한도를 올릴 수 있나요?
아니요 — OneDrive와 SharePoint의 고정 한도입니다. 해결은 늘 이름을 바꾸거나 옮겨 경로를 줄이는 것이지 한도를 바꾸는 게 아닙니다.
이름을 줄였는데도 동기화가 안 됩니다.
PowerShell 스캔을 다시 돌리세요 — 파일 위 폴더가 여전히 전체 경로를 400자 너머로 밀고 있거나, invalid characters나 storage full 같은 다른 오류일 수 있습니다. 정확한 OneDrive 메시지를 맞춰 보세요.
참고 자료
Haneul Seo
Infrastructure engineer · 10+ years running Linux fleets
같은 카테고리 다른 글
Gmail이 550-5.7.26으로 거부: 도메인의 DMARC 정책 때문에 인증되지 않은 메일이 수신 거부됨
Gmail이 우리 도메인이 직접 게시한 DMARC 정책을 집행한 결과입니다. 메시지가 header From: 도메인 기준으로 SPF·DKIM 정렬을 모두 통과하지 못했고, p=quarantine이나 p=reject 정책이 이를 하드 바운스로 바꿉니다. Authentication-Results 헤더가 어느 검사가 실패했는지 알려주고, SPF·DMARC·DKIM 레코드를 향한 dig 세 번이 원인을 지목합니다. SPF나 DKIM으로 인증하라는 비슷한 문구의 바운스는 정책이 아니라 Gmail의 기본 발신자 요구사항에 걸린 다른 문제입니다.
Microsoft Entra ID: AADSTS50011, 요청에 지정된 redirect URI 가 앱에 등록된 redirect URI 와 일치하지 않음
로그인은 끝까지 성공했는데 마지막 한 단계에서 Entra ID 가 거부합니다. 앱이 보낸 redirect_uri 가 등록된 URI 중 어느 것과도 문자 단위로 같지 않기 때문입니다. 비교는 대소문자를 구분하고 끝의 슬래시를 세며, localhost 를 제외하면 https 를 요구하고 포트도 일치해야 합니다. 목록도 web·spa·publicClient 세 개로 나뉘어 있고, application 객체가 아닌 service principal 에 넣은 URI 는 동기화 과정에서 사라질 수 있습니다. 오류 메시지에서 URI 와 앱 ID 를 꺼내 az ad app show 로 대조하고, az ad app update 나 Graph PATCH 로 정확한 문자열을 넣은 뒤 3~5분 기다리면 됩니다.
Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled
smtp.office365.com 으로 메일을 보내던 스캐너·스크립트·앱이 535 5.7.139 로 멈추는 이유는 SMTP AUTH 프로토콜이 테넌트 전체, 해당 메일박스, 또는 Basic 인증을 막는 인증 정책·보안 기본값 중 어딘가에서 꺼져 있기 때문입니다. 문구(Tenant, Mailbox, 'did not meet the criteria')를 읽고 Get-TransportConfig·Get-CASMailbox·Get-AuthenticationPolicy 로 확인한 뒤, 테넌트 전체가 아니라 필요한 메일박스 하나만 엽니다. Basic SMTP AUTH 는 다리일 뿐입니다. Microsoft 는 2026년 12월 말 기존 테넌트에서 기본 비활성화하므로 발신자를 OAuth·High Volume Email·릴레이 커넥터로 옮겨야 합니다.
Zoom: "Unable to connect" 오류 코드 5003 — 브라우저는 되는데 데스크톱 앱만 Zoom 에 못 붙을 때
오류 5003 은 같은 PC 의 웹 클라이언트는 정상 입장하는데 Zoom 데스크톱 앱이 Zoom 서버와의 연결을 끝내지 못하는 상태입니다. 앱은 브라우저보다 더 많은 것을 필요로 합니다. Zoom 방화벽 문서는 미팅용 TCP 443/8801/8802 와 UDP 3478/3479/8801–8810, 인증서 검증용 CA 호스트 목록을 들고, zoom.us 와 *.zoom.us 를 프록시·SSL 검사에서 제외하라고 권고합니다. 포트 테스트, curl issuer 확인, 앱 내장 Network Connectivity Tool(Ctrl+Alt+Shift+D / Cmd+Option+Shift+D)로 어느 계층이 끊겼는지 보고 그 계층을 고치며, 재설치는 옆자리는 되는데 한 대만 실패할 때 씁니다.
Slack: 회사 프록시 뒤에서 뜨는 "Slack cannot connect"와 회색 "Last updated…" 띠
Slack은 채널을 평범한 HTTPS로 불러오지만 새 메시지는 443 포트로 Slack이 이름을 밝힌 wss-*.slack.com 호스트 셋(primary·backup·mobile)에 붙는 지속 WebSocket으로 받습니다. 프록시나 방화벽이 HTTP 쪽은 통과시키고 upgrade는 막으면 — 대개 wss 호스트에 SSL 복호화가 켜져 있거나 허용 목록이 slack.com에서 끝나기 때문에 — 브라우저는 멀쩡해 보이는데 앱은 회색 "Last updated…" 띠나 "Slack cannot connect."를 띄웁니다. 문제의 PC에서 curl 프로브 두 개로 어느 계층이 막혔는지 보고, wss 호스트 세 개를 복호화에서 예외 처리하고, my.slack.com/help/urls의 도메인을 전부 허용한 뒤 my.slack.com/help/test로 확인합니다.
Word: 문서가 "locked for editing by another user"라며 열리지 않음
Word가 문서의 잠금(owner file)을 발견해 다른 누군가가 열어 두었다고 판단하고 읽기 전용 사본만 제안합니다. 대개는 아무도 열지 않았습니다: 크래시가 잠금을 남겼거나, 숨은 Word 프로세스가 여전히 파일을 쥐고 있는 것입니다. 어느 쪽인지 확인하고 Word 인스턴스를 모두 닫은 뒤 남겨진 ~$ owner file을 삭제하면 문서가 다시 편집 가능하게 열립니다.