타호(macOS 26)로 올리고 나서 공유 폴더에 못 보던 게 하나 생겼다. Relocated Items. 안을 열어보면 ssh.system_default 같은 시스템 파일들이 들어있어서, 순간 “내 SSH 설정이 여기로 옮겨진 건가? 그럼 원래 자리는 비었나?” 싶어서 등골이 서늘했다.
결론부터 말하면 그건 오해다. 내 설정은 원래 자리에 그대로 있다. Relocated Items 안에 있는 건 애플이 새로 깐 기본값이지, 내 파일이 뜯겨 나온 게 아니다. 근데 이걸 확신하려고 폴더 안을 실제로 뜯어봤고, 세 가지를 직접 확인하고 나서야 마음 놓고 지웠다. 그 과정을 그대로 적는다.
📑 목차
Relocated Items 폴더는 왜 갑자기 생겼나
짧게: 업데이트가 새 위치로 못 옮긴 파일을 한곳에 모아둔 폴더다. macOS는 큰 버전으로 올라갈 때 디스크의 파일들을 훑어서 제자리에 있는지, 손상되진 않았는지, 유효한지를 확인한다. 이 검사를 통과 못 한 파일은 원래 자리에 두지 않고 Relocated Items로 밀어낸다.
내 맥은 6월 2일에 타호로 올라갔는데, 폴더 생성/수정 시각이 정확히 그날이다.
$ sw_vers
ProductName: macOS
ProductVersion: 26.5.1
BuildVersion: 25F80
$ stat -f "수정: %Sm" "/Users/Shared/Relocated Items"
수정: Jun 2 20:07:16 2026위치도 알아둘 만하다. 데스크톱에 뜨는 건 **알리아스(바로가기)**고, 실물은 /Users/Shared/Relocated Items에 있다. 데스크톱 아이콘을 지워도 실물은 그대로 남는다 — 이건 좀 헷갈리는 포인트라 뒤에서 다시 짚는다.
내 맥의 폴더 안에 실제로 뭐가 있었나
말로만 “시스템 파일”이라고 하면 감이 안 오니까 실제 트리를 그대로 붙인다. 내 경우엔 딱 이만큼이었다.
$ find "/Users/Shared/Relocated Items" -maxdepth 4
/Users/Shared/Relocated Items
/Users/Shared/Relocated Items/Configuration
/Users/Shared/Relocated Items/Configuration/private
/Users/Shared/Relocated Items/Configuration/private/etc
/Users/Shared/Relocated Items/Configuration/private/etc/localtime.system_default
/Users/Shared/Relocated Items/Configuration/private/etc/ssh.system_default
/Users/Shared/Relocated Items/private
/Users/Shared/Relocated Items/private/var
/Users/Shared/Relocated Items/private/var/boot포인트는 두 개다. 첫째, 경로가 전부 private/etc·private/var 아래다. 이건 macOS가 SIP(시스템 무결성 보호)로 잠가둔 시스템 영역이다. 둘째, 파일 이름 끝에 .system_default가 붙어 있다. 이 접미사가 이 폴더를 이해하는 열쇠다.
용량은 웃길 정도로 작다.
$ du -sh "/Users/Shared/Relocated Items"
56K /Users/Shared/Relocated Items56KB. 용량 확보하려고 지우는 폴더는 아니라는 뜻이다. 순전히 “이게 뭐고 지워도 되나”의 문제다.
.system_default가 핵심이다 — 내 설정은 안 옮겨졌다
요점은 이거다. .system_default가 붙은 파일은 애플이 새로 제공한 기본값 견본이지, 내가 쓰던 파일이 아니다. 업데이트는 내 설정 파일을 덮어쓰지 않는 대신, 새 버전의 기본 파일을 이 폴더에 따로 놔둔다. 비교해보라고 두는 참고본인 셈이다.
여기서 많은 글이 멈추는데, 나는 이게 진짜인지 내 맥에서 대조해봤다. 확인한 게 세 가지다.
하나, 활성 SSH 설정엔 내 호스트 키가 그대로 있다. 재배치된 ssh.system_default 안에는 키가 없다 — 순수 기본 파일 세트뿐이다.
# 재배치된 쪽 (애플 새 기본값)
$ ls "/Users/Shared/Relocated Items/Configuration/private/etc/ssh.system_default"
crypto crypto.conf moduli ssh_config
ssh_config.d sshd_config sshd_config.d
# 현재 활성 /etc/ssh (내 실제 설정 — 안 옮겨졌다)
$ ls /etc/ssh
moduli ssh_host_ecdsa_key.pub ssh_host_rsa_key
ssh_config ssh_host_ed25519_key ssh_host_rsa_key.pub
ssh_config.d ssh_host_ed25519_key.pub sshd_config
ssh_host_ecdsa_key sshd_config.dssh_host_*_key 파일들이 활성 쪽에만 있다. 내 SSH 신원은 원래 자리에 멀쩡히 남아있다는 얘기다. GitHub 연동할 때 만든 키가 그대로라 SSH 키 세팅을 다시 할 필요도 없었다.
둘, diff로 두 sshd_config가 실제로 다른지 봤다. 다르다.
$ diff -q "/Users/Shared/Relocated Items/Configuration/private/etc/ssh.system_default/sshd_config" /etc/ssh/sshd_config
Files .../ssh.system_default/sshd_config and /etc/ssh/sshd_config differ내용이 다르니까 애플이 새 기본값을 밀어냈다는 게 앞뒤가 맞는다. 만약 내 파일이 옮겨진 거라면 원래 자리 것과 같아야 하는데, 다르다는 건 활성 쪽이 내가 쓰던 버전 그대로라는 뜻이다.
셋, localtime은 아예 값이 같았다. 타임존은 커스텀한 게 없어서 기본값과 동일했다.
$ readlink "/Users/Shared/Relocated Items/Configuration/private/etc/localtime.system_default"
/var/db/timezone/zoneinfo/Asia/Seoul
$ readlink /etc/localtime
/var/db/timezone/zoneinfo/Asia/Seoul결국 재배치된 건 “네 파일”이 아니라 “새 기본값”이다. 이걸 알고 나니 폴더가 무섭지 않았다. 원래 자리 값과 새 값을 나란히 놓고 뭐가 바뀌었는지부터 보는 이 접근은, 예전에 Mac Node.js 버전 충돌을 잡을 때 styleText 하나 때문에 빌드가 죽었던 걸 추적하던 방식과 똑같았다.
그래서 지워도 되나 (애플은 뭐라고 하나)
한 줄 답: 시스템이 정상이면 지워도 문제없다. 단 애플이 “안전하다”고 못 박은 적은 없다. 여기가 대부분의 블로그가 대충 넘어가는 지점이라 정직하게 적는다.
애플 공식 문서를 직접 읽어보면, “옮기지 못한 파일을 Relocated Items 폴더에 넣는다”는 설명과 “폴더 안의 PDF 문서가 처리 방법을 안내한다”는 말은 있어도, “삭제해도 안전하다”는 문장은 없다. 삭제 가능 여부는 애플이 명시하지 않고 PDF로 미룬다. 그래서 “무조건 지워도 됨”이라고 단정하는 글은 애플 말이 아니라 그 사람 판단이라고 보면 된다.
내가 세운 기준은 이거다.
- 업데이트 직후 며칠은 그냥 둔다. 자주 쓰는 앱들을 한 바퀴 돌려보고 문제 없는 걸 확인한 다음에 지운다.
.system_default만 있으면 마음 편하게 지운다. 내 설정은 원래 자리에 있으니 이 폴더는 참고본일 뿐이다.- 접미사 없는 낯선 파일이 섞여 있으면 멈춘다. 그건 진짜 옮겨진 내 파일일 수 있으니 내용을 확인하고 필요하면 제자리로 되돌린다.
내 경우엔 전부 .system_default였고, 2주쯤 쓰면서 SSH·개발 환경 다 멀쩡한 걸 확인한 뒤에 지웠다. 데스크톱 알리아스는 지워도 실물이 안 지워지니, 실물 폴더(/Users/Shared/Relocated Items)를 직접 휴지통에 넣어야 한다. 혹시 “다른 프로세스가 사용 중”이라 안 지워지면 재부팅하고 다시 하면 풀린다.
한마디로, 이 폴더는 겁줄 이름값을 못 한다. 안을 한 번만 열어서 .system_default인지 확인하면 끝나는 문제였다.