맥 권한 오류(EPERM), 권한이 사라진 게 아니었다 — 대량 파일 작업하다 막힌 진짜 원인
맥 권한 오류, 그중에서도 EPERM(Operation not permitted)은 권한이 사라져서 생기는 게 아니더라. 파일 1만 5천 개를 한 번에 만졌다가 폴더 전체가 잠긴 날부터, 원인을 잘못 짚고 6일을 돌아간 기록까지.
AI한테 파일 정리를 시키다 보면 언젠가 한 번은 만나는 화면이 있다. 까만 창에 빨간 글씨로 Operation not permitted. 번역하면 "그 작업 허락 안 됨"인데, 문제는 왜 허락이 안 되는지를 아무도 안 알려준다는 거다. 나는 이걸 두 번 크게 맞고, 한 번은 완전히 헛다리를 짚었다. 그 과정을 그대로 적는다. 코딩 몰라도 읽을 수 있게 썼다.
📑 목차
- 1. 파일 1만 5천 개를 만진 다음 날, 폴더가 통째로 잠겼다
- 2. 1차 진단은 오답이었다
- 3. 권한은 사라지지 않았다 (내가 열어본 범위에선)
- 4. 그럼 왜 막혔나: 세 가지가 겹칠 때
- 5. 지금 막혔다면 이 순서로
- 6. 결국 폴더를 옮겼다, 그리고 4시간이 걸렸다
- 7. 정리: 이 글이 필요한 사람
▲ 파일 1만 5천 개 작업 후 폴더가 잠긴 사건 흐름과 Permission denied 대 Operation not permitted 두 오류의 차이를 비교한 도표 (자체 제작 이미지)
1. 파일 1만 5천 개를 만진 다음 날, 폴더가 통째로 잠겼다
에버노트에서 넘어온 노트 뭉치를 정리하던 중이었다. 15,109개 파일을 한 번에 손보는 작업이었고, 걸린 시간은 2.86초. 빠르다고 좋아했다. 그 직후부터 이상해졌다.
AI가 자기 설정 파일을 못 읽는다고 했다. 내가 직접 터미널에서 열어봐도 Operation not permitted. 파일을 지우려고 해도 안 되고, sudo(관리자 권한으로 강제 실행하는 명령)를 붙여도 똑같이 튕겼다. 폴더 목록 보기, 읽기, 쓰기가 전부 막혔다.
내 컴퓨터, 내 폴더, 내 파일인데 관리자도 못 건드린다고?
여기가 첫 번째 힌트였는데 그땐 몰랐다. 우리가 흔히 아는 "권한 없음"은 Permission denied라고 뜬다. 파일 소유자나 읽기·쓰기 설정이 안 맞을 때 나오는 거고, 이건 sudo로 대개 넘어간다. 근데 Operation not permitted는 다른 놈이다. 관리자 권한 위에서 따로 도는 맥의 개인정보 보호 계층이 막는 거라 sudo가 안 통한다. 나흘 뒤 같은 증상이 또 터졌다. 이번엔 하필 하루 작업을 정리해 저장하려던 순간이라, 기록도 못 남기고 세션이 끊겼다ㅠㅠ
두 번 다 응급처치는 같았다. 시스템 설정에서 터미널 권한을 껐다 켜니 살아났다. 그러니까 자연스럽게 이런 결론이 나왔다. "권한이 자꾸 사라지는구나."
이게 오답이었다.
2. 1차 진단은 오답이었다
두 번째 사고 직후 내가 내린 진단은 이랬다. 터미널에 전체 디스크 접근 권한이 없다.
전체 디스크 접근 권한(Full Disk Access)은 맥에서 앱이 저장 장치 전체를 읽고 쓸 수 있게 열어주는 최상위 허가다. 위치는 시스템 설정 > 개인정보 보호 및 보안 > 전체 디스크 접근 권한이고, 앱을 목록에 직접 추가해줘야 한다. 터미널로 파일을 대량 처리하려면 사실상 필요한 권한이다.
참고로 이 허가 목록을 관리하는 맥 내부 장치에는 TCC라는 이름이 붙어 있다. 애플이 회사용 기기 관리 문서에서 com.apple.TCC.configuration-profile-policy라는 식별자로 언급하는 그거다. 일반 사용자 화면에는 "개인정보 보호 및 보안"이라고만 보인다.
아무튼 나는 권한을 다시 켰고, 문제가 사라졌다. 해결된 것처럼 보였지. 그런데 찜찜했다. 껐다 켜서 나았다는 건 원인을 안 건드리고 증상만 밀어낸 거니까. 그래서 6일 뒤에 다시 파봤다.
3. 권한은 사라지지 않았다 (내가 열어본 범위에선)
맥은 이 허가 기록을 sqlite라는 형식의 파일에 저장해둔다. 엑셀 표를 프로그램이 읽기 좋게 만들어놓은 거라고 보면 얼추 맞다. 내가 직접 열어보니 이 표가 한 군데가 아니라 두 군데에 있었다. 내 사용자 계정 안에 하나, 시스템 쪽에 하나.
1차 진단 때 나는 사용자 계정 쪽만 봤다. 거기엔 전체 디스크 접근 권한 기록이 없었고, 그래서 "권한 없음"이라고 단정했다. 시스템 쪽을 열어보니 터미널도, 셸도, 파이썬도 전부 "허용"으로 들어가 있었다. 부여 날짜는 사고가 나기 전이었다.
권한은 처음부터 있었다. 없어진 적이 없다.
내친김에 하나 더 확인했다. 이 표에 "언제 만료됨" 같은 항목이 있나. 표의 칸 목록을 뽑아보니 시간과 관련된 건 마지막 수정 시각뿐, 유효기간처럼 보이는 칸은 눈에 안 띄었다. 그러니까 "시간이 지나면 권한이 저절로 풀린다"는 내 가설은 최소한 내 눈으로 확인한 범위에서는 근거가 없었다.
다만 여기는 선을 그어두자. 이건 애플이 공식 문서로 설명해주는 구조가 아니다. 맥 한 대(macOS 26.3), 그 시점, 내가 본 것까지가 전부다. OS 버전이 바뀌면 안쪽 생김새는 달라질 수 있고, 나는 그걸 검증할 방법이 없다. 그래서 "맥의 권한은 만료되지 않는다"까지 주장하진 않으련다. 내가 말할 수 있는 건 이거다. 내 사고의 원인은 권한 만료가 아니었다.
그럼 여태 뭘 붙잡고 있었던 거냐 싶더라..
▲ 맥 허가 기록 표를 조회해 시스템 쪽에 권한이 그대로 남아 있고 만료 관련 칼럼은 없음을 확인한 터미널 화면 (자체 제작 이미지)
4. 그럼 왜 막혔나: 세 가지가 겹칠 때
두 번의 사고를 나란히 놓고 공통점을 찾았다. 세 개가 겹쳤을 때만 터졌더라.
첫째, 작업 폴더의 위치. 내 폴더는 '문서(Documents)' 안에 있었다. 맥은 데스크탑·문서·다운로드 이 세 폴더를 따로 떼어 추가로 보호한다. 앱이나 웹사이트가 여기 접근하려면 별도 허가가 필요하고, 사용자가 위치별로 켜고 끌 수 있다. 즉 다른 폴더보다 검문이 한 겹 더 있는 자리다.
둘째, 방아쇠. 평소엔 멀쩡했다. 파일 수만 개를 몇 초 만에 훑는 작업을 돌렸을 때만 터졌다. 슬립에서 깨어나 시계가 껑충 뛴 직후에도 한 번 겹쳤고.
셋째, 동시 충돌. 나는 파일 동기화 프로그램을 상시로 돌린다. 대량 수정이 벌어지면 이 친구가 변경분을 전부 감지해서 같은 파일들을 동시에 붙잡는다. 여기에 죽은 잠금 파일까지 하나 끼어 있었다. 잠금 파일은 "지금 내가 이 작업 하는 중이니 딴 데서 건드리지 마"라는 표식인데, 프로그램이 비정상 종료하면 이게 안 치워진다. 내 경우 4월 29일 사고 때 남은 표식이 열흘 동안 그대로 있었다. 안에 적힌 프로세스 번호는 이미 죽은 지 오래고.
이 세 개가 만나면 맥이 일시적으로 방어 모드에 들어가고, 그때 들어온 파일 요청 일부가 거부된다. 사용자 눈에는 "권한이 갑자기 사라졌다"로 보이고, 권한을 껐다 켜면 재평가가 일어나면서 잠금도 같이 풀리니 "권한 문제였네"라고 오해하게 된다.
이 인과는 내 추정이다. 애플 문서 어디에도 "이 조합이면 이렇게 됩니다"라고 안 적혀 있고, 나는 두 사건의 공통 조건과 재현 결과로 역산했을 뿐이다. 다만 뒤에 나올 조치가 실제로 먹혔다는 점에서, 아주 틀린 그림은 아니라고 본다.
동기화 프로그램과 파일 정리 작업이 부딪히는 얘기, 그리고 대량 작업 전에 백업부터 뜨는 습관은 옵시디언 자동화 정리편에서 이미 한 번 크게 데인 적이 있어 거기 적어뒀다. 여기선 반복 안 하겠다. 문제의 1만 5천 개가 어디서 왔는지 궁금하면 에버노트에서 통째로 갈아탄 후기 쪽이다.
5. 지금 막혔다면 이 순서로
검색해서 이 글에 들어온 사람은 지금 화면에 빨간 글씨가 떠 있을 확률이 높다. 순서대로 해보자.
먼저 어느 쪽 오류인지부터 구분한다. Permission denied면 파일 소유자·읽기쓰기 설정 문제라 sudo나 파일 정보 창에서 해결되는 경우가 많다. Operation not permitted면 이 글의 영역이다. 둘을 헷갈리면 엉뚱한 해결책을 몇 시간씩 붙잡게 된다.
그다음이 껐다 켜기다. 시스템 설정 > 개인정보 보호 및 보안 > 전체 디스크 접근 권한에서 터미널(또는 쓰는 앱)을 찾아 끄고, 다시 켜고, 앱을 완전히 종료했다가 실행한다. 급할 땐 이걸로 대개 넘어간다. 근본 해결은 아니지만 일단 일은 해야 하니까.
그리고 하나 물어보자. 그 폴더, 혹시 '문서'나 '바탕화면' 안에 있나? 그렇다면 위치 자체가 용의자다. 위에서 말한 추가 보호 구역이라서 그렇다. 옮길 수 있으면 옮기는 게 제일 확실한데, 그 얘긴 다음 장에서.
잠금 파일도 한번 뒤져봐라. 나는 열흘 묵은 .lock 파일 하나 때문에 애먼 권한 설정을 세 번이나 만졌다. AI 도구든 동기화 프로그램이든 비정상 종료한 적이 있다면 작업 폴더 안에 .lock으로 끝나는 파일이 남아 있을 수 있다. 안에 적힌 프로세스가 이미 죽었다면 그냥 지워도 된다. 지우기 전에 그 프로그램은 꺼두고.
마지막으로, 대량 작업 들어가기 전엔 동기화를 잠깐 멈춰라. 나는 이 습관 하나로 재발 빈도가 확 줄었다.
한 가지 헷갈리기 쉬운 것. AI 도구가 파일 고치기 전에 "해도 될까요?" 하고 묻는 승인 절차랑, 지금 얘기하는 맥 권한은 완전히 다른 층이다. 앞엣것은 앱이 나한테 묻는 거고, 뒤엣것은 운영체제가 앱한테 묻는 거다. 앱 쪽 승인·자동실행을 어디까지 풀어도 되는지는 권한 자동승인 세팅 편에 따로 정리해뒀다. 거기서 아무리 열어줘도 맥이 막으면 못 지나간다.
▲ 맥 시스템 설정의 전체 디스크 접근 권한 앱 목록 화면과 오류가 났을 때 따라 할 5단계 조치 순서 (자체 제작 이미지)
6. 결국 폴더를 옮겼다, 그리고 4시간이 걸렸다
증상만 계속 밀어내는 게 지겨워서 폴더를 '문서' 밖으로 뺐다. ~/Documents/작업폴더에서 ~/작업폴더로. 검문소가 한 겹 적은 자리로 옮긴 셈이다.
이사 자체는 1분도 안 걸렸다. 문제는 그 뒤였다. 4시간 반이 갔다ㅋㅋ
옛 경로가 박혀 있는 곳이 생각보다 많았다. 설정 파일, 자동 실행 등록, 스크립트 안에 적힌 절대 경로, 심볼릭 링크(바로가기 비슷한 것), 백업 스크립트. 하나 고치면 다음 게 튀어나오는 식이라 순차적으로 계속 발견됐다. 이사할 거면 옮기기 전에 옛 경로가 등장하는 파일을 전부 훑어서 목록부터 만들어라. 이사 스크립트가 알아서 해준다고 믿지 말고. 나는 믿었다가 여섯 군데를 뒤늦게 주웠다.
여기서 제일 값진 걸 하나 배웠다. 내가 터미널에 직접 쳐서 되는 것과, 자동 실행으로 도는 것이 서로 다르게 판정되더라.
주간 백업이 4월 26일 이후로 조용히 실패하고 있었다. 손으로 백업 폴더에 파일을 써보면 잘 됐다. 그래서 두 달 가까이 아무도 몰랐다. 근데 자동 실행 컨텍스트(맥에서는 launchd라고 부르는, 예약 작업을 대신 돌려주는 장치)로 같은 걸 시키면 Operation not permitted가 났다. 나는 이 차이를 알기 전까지 백업이 멀쩡한 줄 알고 있었다. 무서운 종류의 실패다. 이 부분도 애플 문서에서 확인한 게 아니라 내가 겪은 관찰이라, 왜 그런지까지는 설명 못 한다. 다만 검증 방법은 확실히 바뀌었다. 자동으로 돌릴 작업은 자동으로 돌려서 테스트한다. 대화형으로 쳐보고 "되네" 하면 안 된다.
예약 자동화를 실제로 어떻게 걸어 쓰는지는 텔레그램으로 던지면 노트가 되는 편에 사례를 적어뒀다. 그리고 이런 삽질을 줄이려면 애초에 AI한테 계획부터 세우게 시키는 습관이 꽤 도움이 된다. 실행 먼저 시켰으면 파일 1만 5천 개를 2.86초에 갈아엎는 일은 없었을 테니.
옮긴 지 두 달 반, 재발은 없다. 물론 이건 완전한 해결이 아니다. 동기화 폭증이나 잠금 파일은 폴더 위치와 무관하니까. 체감상 방아쇠 대부분이 사라진 정도지 0이 된 건 아니라고 본다.
7. 정리: 이 글이 필요한 사람
솔직히 이 글은 대상이 좁다. 맥에서 문서 파일 몇십 개 다루는 정도면 평생 안 만날 오류다. 문제가 되는 건 AI한테 폴더 단위 작업을 시키기 시작할 때다. 수백, 수천 개 파일을 한 번에 훑는 순간부터 이 벽이 나온다. 엑셀 여러 개를 한꺼번에 취합시키는 작업만 해도 파일 수가 커지면 슬슬 사정권이다.
그리고 이 사고에서 내가 진짜로 배운 건 기술이 아니었다. 증상이 사라졌다고 원인을 안 것은 아니라는 것. 껐다 켜서 나은 걸 "해결"이라고 적어두는 순간, 같은 사고를 다시 만날 때 또 처음부터 시작하게 된다. 6일을 돌아간 이유가 딱 그거였다.
잘 알지도 못하면서 남의 컴퓨터 사정까지 일반화한 것 같긴 한데, 최소한 "권한 껐다 켜세요"만 반복하는 글보다는 나을 거다.
3줄 요약
- Operation not permitted는 파일 권한 문제가 아니라 맥의 개인정보 보호 계층이 막는 것. sudo로 안 뚫린다.
- 내 경우 원인은 권한 만료가 아니라 위치(문서 폴더) + 대량 파일 작업 + 동기화 충돌의 겹침이었다.
- 급하면 권한 껐다 켜기, 근본은 작업 폴더를 문서·바탕화면 밖으로. 자동 실행 작업은 반드시 자동 실행으로 테스트할 것.
같은 화면 보고 있으면 5번 순서대로 한번 해봐라. 대체로 두 번째에서 풀린다. 안 풀리면 폴더 옮길 각오하고, 옮기기 전에 백업부터. 화이팅!
이 글은 정보 제공 목적이며, 작성 시점(2026년 7월) 기준이다. 테스트 환경은 macOS 26.3(Tahoe) 한 대이고, macOS 버전·앱 구성에 따라 화면 이름과 동작은 달라질 수 있다. 본문 3장의 내부 저장 구조 관련 서술은 애플 공식 문서가 다루는 내용이 아니라 내가 직접 조회한 관찰이며, 다른 환경에서 동일하다고 보장할 수 없다. 4장의 인과 설명 역시 두 차례 사고에서 역산한 추정이다. 시스템 설정을 바꾸거나 폴더를 이동하기 전에는 반드시 백업을 먼저 만들기를 권한다.
참고한 공식 자료 - 데스크탑·문서·다운로드 폴더 접근 제어: Mac에서 파일 및 폴더 접근 제어하기 - 전체 디스크 접근 권한 설명: Controlling app access to files in macOS (Apple 플랫폼 보안) - 앱의 사용자 데이터 접근 보호 원리: Protecting app access to user data - 개인정보 보호 및 보안 설정 변경: Mac에서 개인정보 보호 및 보안 설정 변경하기 - TCC 명칭·관리 정책(기업용 배포 문서): Privacy Preferences Policy Control 페이로드 설정