왜 macOS만 시스템 확장 이야기가 나오는가

Windows나 Linux에서 TUN은 종종 “관리자 권한 + 드라이버/모듈” 조합으로 설명되지만, macOS는 사용자 공간에서 동작하는 네트워크 확장과 시스템 확장의 조합을 엄격히 관리합니다. Clash 계열 GUI가 TUN을 켤 때 내부적으로는 utun 인터페이스 생성, 라우팅 테이블 조정, DNS 가로채기 같은 작업을 하게 되는데, 이는 단순히 “앱 샌드박스 안에서 소켓만 여는 것”과 수준이 다릅니다. 그래서 설치 직후나 업데이트 직후에 시스템 확장을 로드할 수 없음, 개발자를 신뢰하거나 보안에서 허용하라 같은 문구가 뜨는 것이 흔합니다.

또한 Apple은 보안 정책을 버전마다 조정하므로, 메뉴 이름은 시스템 설정 / 시스템 환경설정 등으로 조금씩 달라질 수 있습니다. 중요한 것은 “어디를 눌러야 승인되는지”보다 승인이 시스템 전체에 한 번 기록되는 이벤트라는 점입니다. 한 번 막히면 TUN은 커널 쪽이 아니라 “정책”에서 막힌 것과 비슷한 증상이 납니다. 개념적 배경은 TUN 모드 심화에서 스택·라우팅 관점을 보강하고, 이 글은 macOS 권한 UI에 초점을 둡니다.

ℹ 핵심: 로그에 permission denied류가 보이면 “YAML만 고치는 문제”가 아니라 확장 승인·전체 디스크 접근·관리자 권한 같은 OS 레벨을 먼저 의심하세요. 같은 설정이라도 승인 전후로 동작이 갈립니다.

「시스템 확장이 차단됨」 이후 승인 절차

클라이언트가 TUN을 켜려 할 때 시스템이 확장 로드를 거부하면, 보통 알림 영역이나 로그에 차단 사실이 표시됩니다. 이때 흔한 흐름은 다음과 같습니다. 첫째, 클라이언트를 완전히 종료했다가 다시 실행해 확장 로드를 재시도합니다. 둘째, 시스템 설정을 열고 개인정보 보호 및 보안(또는 이에 준하는 보안 섹션)으로 이동합니다. 셋째, 하단 근처에 차단된 시스템 확장을 허용 같은 항목이 나타나면 관리자 비밀번호로 잠금을 해제하고 허용합니다. 넷째, 필요하면 Mac을 재부팅합니다. 일부 환경에서는 재부팅 후에야 확장이 안정적으로 붙습니다.

여기서 자주 생기는 실수는 “허용 버튼이 안 보인다”고 설정만 헤매다가 시간이 지나 항목이 사라지는 경우입니다. 차단 직후 수 분 안에 승인하는 편이 안전합니다. 또 다른 실수는 회사나 학교의 MDM(모바일 기기 관리) 정책이 사용자 확장을 막는 경우인데, 이 경우 개인 설정만으로는 풀리지 않을 수 있습니다. IT 정책이 있는지 먼저 확인하세요.

⚠ 주의: 출처를 알 수 없는 서명의 확장을 무조건 허용하지 마세요. 공식 빌드·검증된 채널에서 받은 클라이언트인지 확인한 뒤 진행하는 것이 안전합니다.

Network Extension과 GUI 클라이언트

많은 Clash GUI는 “메뉴에서 TUN 스위치만 켜면 된다”고 보이지만, 그 배경에는 Network Extension이나 패킷 터널 관련 권한이 있습니다. 제품마다 표현이 다르지만 공통적으로는 필터·VPN·네트워크 확장 같은 문구가 개인정보 보호 목록에 추가됩니다. 여기서 스위치가 꺼져 있으면 앱 UI상으로는 TUN이 켜진 것처럼 보여도 실제 utun이 안 뜨는 일이 생깁니다. 클라이언트별 설정 화면에서 “시스템 권한 열기” 같은 단축이 있다면 그 순서를 따르는 것이 빠릅니다.

어떤 제품을 쓸지 아직이라면 유지보수 리듬과 플랫폼 지원을 먼저 맞추는 편이 좋습니다. Clash 클라이언트 선택 가이드에서 업데이트 주기와 macOS 대응을 함께 보면, “확장은 있는데 코어가 옛날” 같은 불일치를 줄일 수 있습니다.

TUN과 시스템 프록시를 동시에 켜면 생기는 일

시스템 프록시는 macOS가 제공하는 HTTP/HTTPS/SOCKS 설정으로, 프록시를 존중하는 앱은 여기를 따릅니다. 반면 TUN은 라우팅 계층에서 트래픽을 끌어가는 방식에 가깝습니다. 둘 다 “전체 트래픽을 다룬다”는 목표가 비슷해 보여 동시에 켜 두고 싶지만, 실제로는 이중 경로가 되어 지연·루프·예기치 않은 분기가 생길 수 있습니다. 예를 들어 브라우저 확장이 자체 프록시를 쓰는데 시스템 프록시도 켜져 있고, 동시에 TUN이 전역 라우트를 바꾸면 “어디로 나갔는지” 추적이 어려워집니다.

증상으로는 속도가 불안정하다, 특정 사이트만 간헐적으로 실패한다, 측정 사이트마다 출구 IP가 다르게 보인다 등이 나올 수 있습니다. 이때는 규칙 YAML을 늘리기 전에 시스템 프록시 끄기 vs TUN만 또는 시스템 프록시만 vs TUN 끄기 같은 단순 대조부터 하는 것이 비용 대비 효과가 큽니다.

설정 정렬: 한 가지 ‘주 출구’ 고르기

실무에서는 다음 원칙이 잘 맞습니다. 전역 투명 프록시가 목표면 TUN을 주력으로 두고, 시스템 프록시는 끄거나 “필요한 앱만” 남깁니다. 반대로 브라우저 위주이고 터미널 도구는 별도라면 시스템 프록시만으로도 충분한 경우가 있습니다. Clash 쪽에서는 GUI에서 “시스템 프록시 설정” 토글과 “TUN 모드” 토글이 동시에 켜져 있지 않은지 확인하세요. 한쪽만 켜도 규칙·DNS는 규칙 라우팅 모범 사례와 FAQ의 DNS 설명과 맞물려야 합니다.

예시: Mihomo 계열 config.yaml의 tun 블록(버전에 맞게 조정) 
tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route는 편하지만 다른 VPN·Docker Desktop·회사 가상화와 충돌할 수 있습니다. “TUN만의 문제인지”를 가리려면 해당 소프트웨어를 잠시 끄고 재현 여부를 보는 것이 좋습니다.

일부 앱만 프록시를 안 탈 때

TUN을 켰는데도 특정 앱만 직접 연결하는 것처럼 보이면, 원인은 크게 세 가지로 나눌 수 있습니다. 첫째, 앱이 시스템 프록시를 무시하고 자체 TLS·QUIC·커스텀 스택을 쓰는 경우입니다. 둘째, 앱이 로컬 네트워크나 고정 IP 대역만 쓰는 경우로, 규칙에서 DIRECT로 빠지도록 잡혀 있는 경우입니다. 셋째, Split Tunneling이나 Per-App 설정이 다른 VPN/보안 제품에 의해 먼저 가로채지는 경우입니다.

macOS는 앱별로 네트워크 권한·로컬 네트워크 접근을 묻기도 하므로, 로컬 네트워크 항목에서 해당 앱이 거부되어 있지 않은지도 확인합니다. 여기까지 맞는데도 이상하면 로그에서 해당 앱의 목적지 도메인·IP가 어떤 규칙에 걸렸는지 추적하는 편이 빠릅니다. 연결 로그 해석은 timeout·TLS 로그 가이드와 접점이 많습니다.

DNS·tun 스택과의 연동

TUN이 켜져도 DNS가 Clash 쪽으로 오지 않으면 “터널은 있는데 이름만 실패” 패턴이 납니다. dns-hijack, enhanced-mode, 그리고 macOS의 DNS 프로필·VPN DNS 우선순위가 엮이면 혼란이 커집니다. 가능하면 한 번에 한 계층씩 검증하세요. 예를 들어 터미널에서 조회 결과가 Clash의 fake-ip 대역인지, 실제 업스트림 DNS로 나가는지부터 확인합니다.

Linux 서버에서 같은 설정을 검증한 경험이 있다면 Ubuntu TUN·systemd 가이드와 대조해 보면 “OS만 다르고 DNS·라우팅 논리는 같다”는 점을 활용할 수 있습니다. 다만 macOS는 승인 UI가 추가된다는 차이를 잊지 마세요.

현장 점검 체크리스트

  1. 확장 승인: 개인정보 보호에서 시스템 확장·네트워크 관련 항목이 허용인가. 차단 직후 재시도했는가.
  2. 다른 VPN: Apple VPN 슬롯이나 타사 VPN이 먼저 잡고 있지 않은가.
  3. 시스템 프록시: TUN 단독 운용 시 불필요한 중복이 꺼졌는가.
  4. 클라이언트 단일화: 동일 포트·동일 utun을 두 프로세스가 놓고 다투지 않는가.
  5. 규칙/DNS: MATCH 이전에 DIRECT/REJECT가 의도치 않게 먼저 걸리지 않는가.
  6. 재부팅: 승인 직후 한 번 재부팅으로 재현성이 좋아지는지.

오픈소스·배포 채널은 분리해서 보기

Mihomo/Clash Meta 계열은 오픈소스로 이슈·릴리스 노트를 확인할 수 있습니다. 다만 일반 사용자에게 “설치 파일을 어디서 받을지”는 사이트 다운로드 페이지를 기본으로 두고, GitHub는 변경 기록·소스 확인용으로 분리하면 혼동이 적습니다. 이는 다운로드 페이지를 통한 배포 정책과도 맞닿아 있습니다.

맺음말

macOS에서 Clash TUN을 안정적으로 쓰려면 YAML 한 줄보다 먼저 시스템 확장 승인과 프록시/TUN 역할 분담이 맞는지 살펴보는 것이 중요합니다. 같은 증상이라도 “확장이 막힌 상태”와 “규칙이 잘못된 상태”는 완전히 다른 처방이 필요합니다. 한 번 정렬이 끝나면 이후에는 규칙·노드 쪽 트러블슈팅에 집중할 수 있습니다.

→ Clash를 무료로 내려받고 macOS에서도 일관된 클라이언트 경험을 시작해 보세요. TUN과 권한, 규칙을 같은 화면에서 다룰 수 있으면 운영 부담이 크게 줄어듭니다.