---
title: "macOS '개인정보 보호 및 보안' 설정, 사실 믿으면 안 됨"
published: 2026-04-10T15:28:24.000Z
canonical: https://jeff.news/article/1665
---
# macOS '개인정보 보호 및 보안' 설정, 사실 믿으면 안 됨

macOS의 Privacy & Security 설정에서 앱의 폴더 접근을 비활성화해도, Open/Save 패널을 통한 의도 기반 접근이 한 번이라도 발생하면 샌드박스 제약이 영구적으로 해제됨. 설정 UI에는 '차단됨'으로 표시되지만 실제로는 풀 액세스 상태가 되어 사용자가 보안 상태를 정확히 파악할 수 없는 문제임.

- **macOS의 Privacy & Security 설정이 실제 앱 접근 권한을 정확히 반영하지 않는 심각한 문제가 발견됨**
  - 설정에서 앱의 폴더 접근을 '비활성화'해도 실제로는 접근이 가능한 상태가 될 수 있음
  - macOS 13.5부터 최신 Tahoe 26.4까지 전부 영향받는 이슈임

- **재현 과정이 꽤 간단함**
  - 앱이 Documents 폴더에 동의(consent) 방식으로 접근 → 사용자가 허용
  - Privacy & Security 설정에서 해당 앱의 Documents 접근을 비활성화
  - 이 상태에서 동의 방식 접근은 차단됨 (정상)
  - 그런데 Open/Save 패널(의도 기반 접근)로 Documents를 한 번 선택하면...
  - **설정에서 비활성화 상태인데도 동의 방식 접근이 다시 작동함**
  - 설정 화면에는 여전히 "비활성화"로 표시되지만 실제로는 풀 액세스 상태

> [!WARNING]
> 한번 의도(intent) 기반으로 접근이 풀리면 **영구적으로 유지됨**. 설정에서 아무리 토글해도 소용없고, 앱을 재시작해도 마찬가지임. 설정 UI가 보여주는 상태와 실제 보안 상태가 완전히 괴리되는 것.

> [!TIP]
> 유일한 해결법: 터미널에서 `tccutil reset All <번들ID>` 실행 후 맥 재시작. 예시: `tccutil reset All co.eclecticlight.Insent`

## 핵심 메커니즘: 동의(Consent) vs 의도(Intent)

- **동의 경로**: 앱이 보호 폴더에 직접 접근 시도 → sandboxd가 가로챔 → TCC에 인가 확인 → 권한 없으면 사용자에게 팝업
- **의도 경로**: Open/Save 패널로 사용자가 직접 폴더 선택 → sandboxd가 가로채지 않음 → TCC 자체가 관여 안 함
  - 사용자가 "직접 골랐으니까 의도가 있다"고 판단하는 구조
  - 이 과정에서 해당 폴더에 대한 샌드박스 제약 자체가 제거됨

- **문제의 핵심**: Privacy & Security 설정은 TCC 상태만 반영하는데, 의도 기반 접근은 sandboxd 레벨에서 처리되므로 TCC를 우회함
  - 설정 UI와 실제 보안 상태 사이에 정보 불일치 발생
  - Apple이 의도한 건지 버그인지 불분명하지만, 사용자 입장에서는 신뢰할 수 없는 상태

```mermaid
sequenceDiagram
    participant App as 앱 (Insent)
    participant SB as sandboxd
    participant TCC as TCC
    participant User as 사용자

    Note over App,User: 동의(Consent) 경로 - 정상 흐름
    App->>SB: Documents 폴더 접근 시도
    SB->>TCC: 인가 확인 요청
    TCC->>User: 접근 허용 팝업
    User->>TCC: 허용/거부
    TCC->>SB: 결과 전달
    SB->>App: 접근 허용/차단

    Note over App,User: 의도(Intent) 경로 - 우회 흐름
    App->>User: Open/Save 패널 표시
    User->>App: Documents 폴더 직접 선택
    Note over SB: sandboxd 개입 안 함
    Note over TCC: TCC 확인 안 함
    App->>App: Documents 직접 접근 (샌드박스 제약 해제)

    Note over App,User: 이후 동의 경로도 우회됨
    App->>SB: Documents 폴더 접근 시도
    Note over SB: 샌드박스 제약 이미 해제됨
    App->>App: 접근 성공 (TCC 비활성화 상태에서도)
```

## 실질적 위험성

- **악용 가능성은 제한적이긴 함**
  - 사용자가 직접 Open/Save 패널에서 보호 폴더를 선택해야 하므로 완전 자동화 공격은 어려움
  - 다만 많은 앱이 초기 설정 과정에서 폴더 선택을 요구하니까 자연스럽게 트리거될 수 있음
- **실제로 많은 사용자가 "앱이 Documents에 접근하는데 Files & Folders 목록에 없다"고 보고하고 있음**
  - 이 메커니즘 때문일 가능성이 높음
- **가장 큰 문제는 사용자가 보안 상태를 확인할 방법이 없다는 것**
  - 설정 화면이 거짓말을 하고 있으니 뭘 믿어야 할지 모르는 상황

---

## 기술 맥락

macOS의 파일 접근 보안은 크게 두 가지 시스템이 협력하는 구조거든요. **TCC**(Transparency, Consent, and Control)는 앱별로 어떤 보호 폴더에 접근할 수 있는지 권한을 관리하는 데이터베이스예요. 시스템 설정의 '개인정보 보호 및 보안'에서 보는 토글이 바로 TCC 상태를 반영하는 거예요. 그리고 **sandboxd**는 실제 파일 접근 시점에 가로채서 TCC한테 "이거 허용된 거 맞아?" 물어보는 역할이에요.

문제는 Open/Save 패널처럼 사용자가 직접 폴더를 선택하는 "의도 기반 접근"은 sandboxd가 아예 개입하지 않는다는 거예요. macOS 설계 철학상 "사용자가 직접 골랐으면 그게 곧 동의"라고 보는 건데, 이게 sandboxd 레벨에서 해당 폴더의 제약을 영구적으로 풀어버려요. TCC는 이 사실을 모르니까 설정 화면에는 "차단됨"이라고 뜨는데 실제로는 열려있는 상태가 되는 거예요.

## 핵심 포인트

- Privacy & Security 설정의 Files & Folders 토글이 실제 접근 권한을 정확히 반영하지 않음
- Open/Save 패널(의도 기반 접근)이 sandboxd 제약을 영구적으로 해제하며, TCC는 이를 인지하지 못함
- macOS 13.5부터 최신 Tahoe 26.4까지 전 버전 영향
- 유일한 복구 방법은 tccutil reset 터미널 명령 + 재시작

## 인사이트

macOS 보안 모델에서 TCC와 sandboxd 간의 상태 불일치가 사용자에게 잘못된 보안 감각을 줄 수 있다는 점이 핵심. 의도 기반 접근이 동의 기반 제약을 영구적으로 무력화하는 설계는 재검토가 필요해 보임.