월요일 아침, 화면 공유를 켜자 익숙한 권한창이 또 나타납니다. 지난주에 허용했는데 마이크도 다시 묻고, 자동화 도구는 손쉬운 사용 설정을 열라고 해요. 업데이트 직후라면 더 헷갈립니다. 이런 macOS 앱 권한 요청이 반복되는 이유를 찾을 때는 팝업 횟수만 세어서는 답이 나오지 않아요. 어느 앱이 어떤 자원에 접근했는지, 시스템이 같은 앱으로 알아보는지, 어느 사용자 계정에서 생겼는지를 차례로 봐야 합니다. 저는 배포 기록표와 실제 창 캡처를 나란히 놓고 이 세 질문부터 확인합니다.
macOS는 앱과 보호 자원을 한 쌍으로 기억해요
macOS는 마이크, 카메라, 화면과 시스템 오디오, 연락처, 특정 폴더처럼 사생활이나 작업 내용이 담길 수 있는 자원을 보호합니다. 앱이 해당 기능을 처음 쓰려는 시점에 동의를 요청하고, 사용자가 허용하거나 거부한 결과를 저장해요. 이 체계를 TCC(Transparency, Consent, and Control)라고 부릅니다. 이후 같은 앱이 같은 보호 자원에 접근하면 저장된 선택을 확인합니다.
여기서 ‘같은 앱’은 화면에 보이는 제품명만 뜻하지 않아요. 앱의 식별 정보와 코드 서명, 요청 자원, 로그인한 사용자 같은 조건이 함께 작동합니다. 조건이 달라지면 새 요청으로 처리될 수 있어요. 설정에는 허용으로 표시되는데 앱 자체 안내창이 계속 뜨는 사례도 있습니다. 시스템 기록은 유지됐지만 앱이 상태를 잘못 읽었거나 재실행을 기다리는 상황일 수 있어요.
권한은 통합 스위치 하나로 관리되지 않습니다. 마이크를 켜도 화면 기록 권한은 별도예요. 파일 및 폴더도 데스크탑, 문서, 다운로드, 이동식 볼륨처럼 위치별로 나뉠 수 있습니다. 자동화는 한 앱이 다른 앱을 제어하는 관계를 다루고, 손쉬운 사용 권한은 스크립트나 시스템 명령으로 Mac을 제어할 수 있는 강한 접근입니다. 입력 모니터링과 전체 디스크 접근도 각각 독립 항목이에요.
현재는 대체로 시스템 설정 → 개인정보 보호 및 보안에서 항목을 찾습니다. 구버전에는 ‘시스템 환경설정’이나 ‘보안 및 개인 정보 보호’가 보일 수 있어요. 화면 및 시스템 오디오 녹화도 버전에 따라 더 세분됩니다. 메뉴 이름이 다르면 설정 검색창에 ‘마이크’, ‘손쉬운 사용’, ‘화면 기록’을 입력하세요.
권한창에 ‘이번에만’, ‘앱을 사용하는 동안’처럼 범위를 정하는 선택지가 보이면 그 문구도 남겨 두세요. 선택의 유효 기간이나 조건이 권한 종류마다 다를 수 있습니다. 앱이 다음 실행에서 다시 확인하는 현상이 저장 실패라는 뜻은 아닐 수 있어요. 파일 열기 창에서 사용자가 고른 문서만 접근한 경우와 개인정보 보호 설정에서 폴더 접근을 허용한 경우도 체감은 비슷합니다. 어느 버튼으로 무엇을 선택했는지 기록해야 같은 재현 조건을 만들 수 있어요.
같아 보이는 팝업에도 원인은 여러 갈래예요
사용자가 “같은 권한창이 계속 뜬다”고 말하면 먼저 캡처를 비교합니다. 제가 관리하던 도구에서도 첫 창은 화면 기록, 다음 창은 시스템 오디오 캡처였어요. 문구와 시점이 비슷해 하나로 느껴진 사례입니다. 표시된 앱 이름과 버튼을 누른 뒤 열리는 설정 항목을 기록하면 시스템 대화상자와 앱 안내창을 구분하기 쉬워요. 외형만으로 확정하지 말고 동작까지 확인합니다.
| 관찰된 상황 | 가능성이 있는 원인 | 확인할 위치 | 권장 조치 |
|---|---|---|---|
| 앱 업데이트 직후 | 서명 조건 변화 또는 새 기능의 권한 | 버전, 릴리스 노트, 요청 자원 | 공식 최신판과 필요 범위 확인 |
| 개발 빌드 수정 후 | 서명 없음 또는 ad hoc 서명 | Xcode 서명 설정, 실행 빌드 | 일관된 개발 서명 사용 |
| 다른 경로의 같은 앱 이름 | 배포판·베타판·복사본 차이 | 응용 프로그램, 다운로드, Dock | 저장 후 중복 사본 정리 |
| 다른 사용자 계정 | 계정별 동의 상태 차이 | 로그인 계정과 해당 계정 설정 | 각 계정에서 용도 확인 |
| 화면 공유를 처음 사용 | 별도 보호 자원에 최초 접근 | 화면·시스템 오디오, 마이크 | 기능에 필요한 항목만 선택 |
| 앱 안내창만 반복 | 상태 감지 오류, 재실행 대기, 보조 구성 요소 | 버튼 동작, 실제 설정, 앱 로그 | 완전 종료 후 지원 문서 확인 |
| 초기화 명령 실행 후 | 저장된 선택이 삭제됨 | 서비스명, 번들 ID, 계정 | 영향받은 권한을 다시 판단 |
원인이 하나만 존재한다고 가정하면 단서를 놓치기 쉬워요. 업데이트 직후 새 화면 공유 기능을 썼을 수 있고, Dock에는 정식판이 있는데 터미널에서는 개발판을 실행했을 수도 있습니다. 앱 본체의 보조 프로세스가 기능을 수행하면 요청 주체 이름도 달라질 수 있어요. 보조 프로세스를 곧바로 원인으로 확정하지 말고 어떤 실행 요소가 언제 요청했는지 지원 문서와 로그로 확인합니다.
업데이트 뒤의 요청은 코드 정체성과 연결돼요
정상 배포 앱은 버전이 바뀌어도 이전 권한을 이어갈 수 있어야 해요. macOS는 코드 서명의 지정 요구사항(designated requirement)을 이용해 새 버전이 이전 버전과 같은 코드인지 판단합니다. 개발 주체와 식별자가 담긴 이름표를 검사하는 셈이에요. Apple의 코드 서명 요구사항 기술 문서도 마이크 같은 보호 자원의 허용 기록에 이 기준이 쓰인다고 설명합니다.
일관된 인증서와 식별자로 서명된 정식 업데이트는 실행 파일 내용이 달라져도 같은 앱으로 이어질 수 있습니다. 앱 업데이트 후 권한 요청이 나타났다는 사실만으로 모든 설정이 초기화됐다고 결론 내리면 안 돼요. 새 버전이 처음 쓰는 권한이거나 설치 출처와 서명 구성이 달라졌을 수 있습니다. 릴리스 노트, 버전 번호, 내려받은 위치를 함께 확인하세요.
개발 환경은 변수가 더 많아요. 서명되지 않은 코드는 안정적으로 추적할 지정 요구사항이 없습니다. Xcode의 ‘Sign to Run Locally’ 같은 ad hoc 서명은 특정 코드 버전에 묶일 수 있어요. 작은 자동화 도구의 버튼을 고쳐 다시 빌드했더니 손쉬운 사용과 화면 기록을 또 요구한 경험도 이 범주였습니다. 코드 수정과 팝업이 함께 반복되면 서명 방식을 확인할 근거가 됩니다.
같은 제품명에도 Mac App Store판, Developer ID 직접 배포판, Apple Development 개발판이 존재할 수 있습니다. 기본 지정 요구사항이 서로 호환되지 않을 수 있어요. 개발자가 호환되게 구성하는 경우도 있으므로 항상 별도 앱으로 처리된다고 일반화할 수는 없습니다. 일반 사용자는 서명 명령을 외울 필요가 없어요. 공식 배포본인지, 다른 폴더에 같은 이름의 앱이 함께 있는지 확인하면 됩니다.
권한을 넓히지 않고 점검하는 순서
점검 전에는 작업을 저장하세요. 권한 토글 변경과 앱 종료가 녹화·회의·자동화를 끊을 수 있습니다. 전체 디스크 접근을 켜는 조치는 마이크나 화면 기록을 대신하지 않으며 원인 구분도 흐립니다. 한 단계씩 진행해야 변경 지점을 되짚을 수 있어요.
- 창의 정보를 남겨요. 앱 이름, 요청 자원, 문구, 발생 시각을 캡처합니다. 허용 선택은 앱의 안전성을 보증하지 않아요. 목적을 모르면 거부한 상태로 출처부터 확인합니다.
- 정확한 범주를 열어요. 개인정보 보호 및 보안에서 마이크, 화면 및 시스템 오디오 녹화, 손쉬운 사용, 자동화, 파일 및 폴더를 각각 봅니다. 파일 위치가 따로 표시되는지도 확인해요.
- 앱을 완전히 종료해요. 창만 닫으면 메뉴 막대나 백그라운드 프로세스가 남을 수 있습니다. 앱 메뉴에서 종료한 뒤 다시 열고 같은 기능을 재현합니다.
- 실행 중인 사본을 찾아요. 응용 프로그램과 다운로드 폴더, 베타판, Dock 대상을 살핍니다. 저는 배포판과 테스트 빌드가 함께 남아 있던 원인을 이 단계에서 찾았어요.
- 버전과 호환성을 확인해요. 앱과 macOS 버전을 적고 릴리스 노트를 봅니다. 오래된 앱이 세분된 화면 기록 권한을 제대로 안내하지 못하는 상황도 고려합니다.
- 설치 출처를 검증해요. App Store나 공식 사이트에서 받은 앱인지 봅니다. 손쉬운 사용, 입력 모니터링, 전체 디스크 접근은 영향이 커요. 신뢰할 수 있고 기능에 필요한 항목만 허용합니다.
- 토글은 하나씩 시험해요. 현재 설정을 캡처하고 작업을 저장한 뒤 문제인 항목만 껐다 켭니다. 여러 권한을 동시에 바꾸면 효과를 판별하기 어렵습니다.
- 관리 정책을 확인해요. 회사 Mac에서 설정이 잠겼거나 되돌아오면 반복 조작을 멈추고 관리자에게 앱 이름과 권한 항목을 전달합니다.
- 재현 범위를 비교해요. 다른 Mac과 계정에서도 같은지 봅니다. 한 계정에 한정되면 저장 상태를, 같은 빌드로 여러 기기에서 생기면 배포와 앱 동작을 조사할 단서가 됩니다.
tccutil 초기화는 마지막 진단 단계예요
tccutil reset은 저장된 권한 결정을 지워 최초 요청 흐름을 다시 시험하는 도구입니다. 앱을 고치거나 신뢰성을 검사하는 기능은 아니에요. 초기화 뒤 해당 자원에 접근하면 시스템 권한창이 다시 나타나는 것이 정상입니다. Apple의 보호 자원 접근 초기화 문서에 따르면 서비스명만 지정하면 현재 사용자의 해당 서비스를 쓰는 여러 앱에 영향을 줄 수 있고, 서비스명 뒤에 번들 ID를 넣으면 특정 앱으로 범위를 좁힐 수 있습니다.
일반 사용자의 첫 조치로 tccutil reset All을 실행하지 마세요. 정확한 서비스명과 번들 ID, 계정 범위를 이해한 개발·테스트 상황이나 지원팀이 안내한 마지막 진단에서 사용합니다. 실행 전 현재 설정, 명령 전문, 시각, 재현 절차를 기록해요. 권한 데이터 파일을 직접 지우거나 SIP와 Gatekeeper를 끄는 우회는 안전한 해결 절차에 포함되지 않습니다.
배포 기록 한 줄이 다음 장애 시간을 줄여요
운영 현장에서는 재현 조건이 곧 해결 속도입니다. 예전에는 앱 버전만 적어 업데이트 전후 비교가 막혔어요. 이후 앱 이름·버전·설치 출처·실행 경로를 설정표에 추가하자 배포본과 개발판 혼용을 금방 찾을 수 있었습니다. 개발자나 관리자에게 전달할 최소 정보는 다음과 같아요.
- 앱 이름과 정확한 버전, App Store·공식 사이트·사내 빌드 같은 설치 출처
- macOS 버전, 사용자 계정 범위, 조직 관리 기기 여부
- 요청된 권한 이름, 팝업 캡처, 버튼 뒤에 열린 설정 위치
- 업데이트·재설치·기능 실행·초기화 가운데 바로 앞서 한 작업
- 다른 Mac, 다른 계정, 공식 배포본에서 같은 순서로 재현되는지
이 기록을 남긴 뒤 필요한 권한만 유지합니다. 반복 팝업이 곧 악성코드나 감염을 뜻하지는 않아요. 출처가 불분명하거나 요청 목적이 설명되지 않거나 강한 권한을 계속 넓혀 달라고 하면 허용을 멈추고 앱을 종료하세요. 기록한 조건을 공식 지원 채널에 전달하면 사용자 설정, 배포 서명, 앱 안내 로직을 훨씬 짧은 경로로 나눠 조사할 수 있습니다.