macOS 프록시 클라이언트 설치 권한 설정: 네트워크 확장 승인과 키체인 팝업

먼저 네 가지 알림을 구분하세요: 앱 실행 확인, 백그라운드 서비스, VPN, 키체인

macOS 프록시 클라이언트는 보통 그래픽 인터페이스와 프록시 코어로 구성됩니다. Mihomo는 코어이며 Clash Meta는 과거에 사용된 이름입니다. 클라이언트는 설정 가져오기, 시스템 프록시 전환, 권한 요청을 담당합니다. 코어가 같더라도 클라이언트마다 네트워크 확장이나 보조 서비스를 사용하는 방식은 다를 수 있습니다. 문제를 진단할 때는 먼저 클라이언트 이름과 버전, macOS 버전, 팝업에 표시된 문구를 기록하세요.

“개발자를 확인할 수 없습니다”는 앱 실행 확인에 해당하고, “VPN 구성 추가”는 네트워크 구성 승인에 해당합니다. 보조 도구 설치 요청은 대개 백그라운드 권한 서비스와 관련이 있으며, “키체인에 저장된 기밀 정보에 접근” 요청은 저장된 자격 증명에 관한 것입니다. 각 알림은 해결 방법이 다르므로 같은 조작으로 처리할 수 없습니다. 비밀번호를 반복 입력한다고 설치가 완료되는 것도 아닙니다.

알림 또는 증상	관련 단계	먼저 확인할 항목
개발자를 확인할 수 없음	Gatekeeper 앱 실행 확인	설치 경로, 앱 서명, 개인정보 보호 및 보안
관리자 승인이 필요한 보조 도구 설치	특권 보조 서비스	클라이언트 문서, 백그라운드 서비스 설치 상태
VPN 구성 추가 요청	시스템 네트워크 구성	요청한 앱 이름, VPN 설정
시스템 확장이 차단됨	확장 로드 승인	개발자 이름, 해당 확장 설정
로그인 키체인에 반복해서 접근 요청	자격 증명 접근 또는 키체인 잠금	요청 프로세스, 대상 항목, 로그인 암호 변경 여부

설치 전에 칩 아키텍처와 앱 위치 확인

Apple Silicon 및 Intel용 설치 파일 선택

Apple 메뉴 → “이 Mac에 관하여”를 여세요. “칩 Apple M…”이라고 표시된 기기는 Apple Silicon 또는 arm64 설치 파일을 선택하고, Intel 프로세서가 표시된 기기는 x64 또는 x86_64 설치 파일을 선택하세요. Universal 앱은 대개 두 아키텍처를 모두 포함하지만, 클라이언트가 안내하는 최소 시스템 버전도 확인해야 합니다.

Apple Silicon: Rosetta 2로 많은 Intel 사용자 공간 앱을 실행할 수 있지만, 보조 도구와 네트워크 확장까지 호환된다고 보장할 수는 없습니다. 클라이언트에서 제공하는 네이티브 빌드를 우선 사용하세요.
Intel: arm64만 포함된 실행 파일은 실행할 수 없습니다. “CPU 유형이 올바르지 않음” 오류가 발생하면 보안 설정을 바꾸기 전에 아키텍처부터 확인하세요.
공통 단계: 앱을 “응용 프로그램” 폴더로 옮기고 설치 디스크 이미지를 추출한 뒤, “응용 프로그램”에서 실행하세요. DMG 안의 앱을 계속 직접 실행하지 마세요.

앱을 고정된 위치로 옮기면 여러 앱 사본으로 인한 혼란을 줄일 수 있습니다. Dock에 이전 아이콘이 남아 있다면 아이콘을 마우스 오른쪽 버튼으로 클릭하고 “옵션” → “Finder에서 보기”를 선택해 현재 버전이 열리는지 확인하세요. 앱을 교체하기 전에 이전 프로세스를 종료해야 인터페이스는 업데이트됐지만 백그라운드 코어는 이전 인스턴스로 실행되는 상황을 피할 수 있습니다.

# 현재 터미널 프로세스의 아키텍처 확인; Rosetta 터미널에서는 x86_64로 표시될 수 있음
uname -m

# 시스템 버전 확인
sw_vers -productVersion

하드웨어 정보는 “이 Mac에 관하여”를 기준으로 확인하세요. 터미널이 Rosetta 변환 환경에서 실행 중이면 uname -m 출력만 보고 설치 파일을 선택할 경우 잘못 고를 수 있습니다.

시스템 보안 검사를 유지하면서 “개발자를 확인할 수 없음” 해결

macOS 13 Ventura, 14 Sonoma, 15 Sequoia에서는 “시스템 설정” → “개인정보 보호 및 보안”에서 관련 옵션을 찾을 수 있습니다. 차단된 앱을 열려고 시도한 뒤 페이지 아래쪽에 해당 앱의 차단 기록과 “그래도 열기” 옵션이 표시될 수 있습니다. 먼저 앱의 출처와 이름을 확인한 다음 시스템 안내에 따라 승인하세요. 모든 차단 상황에서 이 버튼이 표시되는 것은 아닙니다.

설치 파일이 프로젝트의 공식 배포 경로에서 제공됐고, 시스템 버전과 아키텍처가 요구 사항을 충족하는지 확인하세요.
앱을 “응용 프로그램” 폴더에 넣고 한 번 실행해 본 다음 전체 오류 메시지를 기록하세요.
“개인정보 보호 및 보안”에서 해당 앱을 허용하는 옵션이 있는지 확인하세요.
앱이 컴퓨터를 손상시킬 수 있다거나 악성 콘텐츠가 포함됐다거나 조직 정책으로 차단됐다는 알림이 표시되면 허용하지 마세요. 출처를 확인하거나 관리자에게 문의하세요.

“앱이 손상되었습니다”라는 메시지가 격리 속성 때문이라고 단정할 수는 없습니다. 다운로드 중단, 서명 만료, 파일 변경도 실행 실패의 원인일 수 있습니다. 격리 속성을 재귀적으로 제거하는 명령을 바로 실행하기보다는 같은 프로젝트에서 현재 시스템과 호환되는 버전을 다시 받는 편이 안전합니다.

클라이언트 구현 방식에 따라 네트워크 확장 또는 보조 서비스 승인

“VPN 구성 추가” 알림이 표시될 때

Network Extension을 사용하는 클라이언트는 네트워크 터널을 처음 시작할 때 VPN 구성 추가를 요청할 수 있습니다. 허용하기 전에 팝업의 앱 이름이 현재 작업과 일치하는지 확인하세요. 승인한 뒤 “시스템 설정”에서 “VPN”을 검색해 해당 구성을 확인할 수 있습니다. 시스템에 VPN 상태가 표시된다는 것은 네트워크 터널의 상태만 알려 줄 뿐, 노드나 DNS, 규칙이 모두 정상이라는 뜻은 아닙니다.

“시스템 확장이 차단됨” 알림이 표시될 때

macOS 13 및 14에서는 먼저 “시스템 설정” → “개인정보 보호 및 보안”에 개발자를 허용하는 옵션이 있는지 확인하세요. macOS 15에서는 일부 확장 관리 메뉴가 “시스템 설정” → “일반” → “로그인 항목 및 확장 프로그램” → “네트워크 확장”에 있습니다. 정확한 위치는 확장 유형과 세부 시스템 버전에 따라 다를 수 있으므로 시스템 설정에서 “확장”을 검색해도 됩니다. 해당 클라이언트의 개발자와 일치하는 항목만 활성화하세요.

“보조 도구 설치” 알림이 표시될 때

일부 클라이언트는 보조 서비스를 사용해 경로 설정과 고권한 코어 실행에 필요한 권한을 얻습니다. 이 알림에는 보통 이 Mac의 관리자 계정 승인이 필요합니다. 구독 계정이나 Apple 계정 암호를 입력하는 것이 아닙니다. 보조 서비스 설치가 끝나면 클라이언트 인터페이스의 서비스 상태도 바뀌어야 합니다. 여전히 설치되지 않은 것으로 표시되면 버튼을 반복해서 클릭하지 말고 서비스 로그를 확인하세요.

시스템에서 재시동을 명시적으로 요구할 때만 작업 내용을 저장한 뒤 재시동하세요. 승인할 때마다 재시동이 필요한 것은 아닙니다.
회사에서 관리하는 Mac은 확장 프로그램, VPN 또는 백그라운드 항목을 제한할 수 있습니다. 사용자가 허용을 눌러도 기기 관리 정책을 우회할 수는 없습니다.
TUN 실행 실패를 이유로 전체 디스크 접근, 손쉬운 사용 또는 화면 기록 권한을 부여하지 마세요. 이 권한들은 Mihomo가 프록시 연결을 구성하는 데 일반적으로 필요하지 않습니다.

업데이트 후 보조 서비스와 본 프로그램 버전이 맞지 않으면 클라이언트의 “서비스 복구” 기능이나 서비스 재설치 기능을 우선 사용하세요. /Library/LaunchDaemons 아래의 낯선 항목을 직접 삭제하면 다른 소프트웨어의 백그라운드 서비스가 손상될 수 있습니다.

먼저 시스템 프록시를 확인한 뒤 TUN을 따로 활성화하세요

처음 설치할 때는 두 단계로 확인하는 것이 좋습니다. 먼저 정상적인 설정을 가져와 시스템 프록시만 켜고 브라우저가 작동하는지 확인한 다음, 필요할 때 TUN을 활성화하세요. 이렇게 하면 노드나 구독 문제와 라우팅 권한 문제를 구분하기 쉽습니다. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되고, TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하므로 두 기능은 서로 다른 설정입니다.

프록시 포트와 시스템 설정 확인

예를 들어 설정에서 아래와 같이 혼합 포트를 사용하면 HTTP와 SOCKS 프록시 모두 로컬 주소의 7890에 연결할 수 있습니다. 이 값은 예시이므로 실제 문제를 진단할 때는 현재 적용 중인 설정을 기준으로 하세요. 일부 클라이언트는 설정에 지정된 포트를 덮어쓸 수 있으므로 클라이언트 인터페이스와 코어 로그를 모두 확인하세요.

mixed-port: 7890
allow-lan: false
mode: rule

macOS 13~15에서는 “시스템 설정” → “네트워크” → 현재 네트워크 연결 → “세부사항” → “프록시”로 이동해 웹 프록시와 보안 웹 프록시의 서버 및 포트를 확인할 수 있습니다. 위 예시를 사용하는 경우 로컬 주소는 127.0.0.1, 포트는 7890이어야 합니다. 노드 서버 주소를 로컬 HTTP 프록시 항목에 입력하지 마세요.

# 시스템 프록시 상태 확인
scutil --proxy

# 예시 포트에서 TCP 연결을 수신 중인지 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# 로컬 HTTP 프록시를 지정해 요청 보내기
curl -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://example.com

이 명령은 원인을 찾기 위한 것이며 특정 결과를 보장하지 않습니다. 포트를 수신 중인 프로세스가 있다는 사실만으로는 충분하지 않으므로 프로세스 이름도 확인해야 합니다. 요청이 실패하면 프록시 연결, 노드 핸드셰이크, 대상 사이트 응답 중 어디에서 문제가 발생했는지 로그를 함께 살펴보세요.

TUN을 켠 뒤 확인할 순서

기본 경로와 DNS 설정이 충돌하지 않도록 다른 VPN이나 프록시 클라이언트를 먼저 종료하세요.
클라이언트에서 TUN 기능을 켜고 실제로 요청되는 서비스 또는 확장 권한을 승인하세요.
로그에서 권한 부족, 경로 추가 실패 또는 장치 생성 실패가 발생했는지 확인하세요.
웹과 TUN이 필요한 앱을 각각 테스트한 다음 규칙 적용 여부와 DNS 동작을 확인하세요.

ifconfig를 실행해 utun 인터페이스가 보이더라도 Mihomo가 정상 동작한다는 증거는 아닙니다. 시스템 서비스나 다른 VPN도 해당 인터페이스를 만들 수 있습니다. 클라이언트 로그와 연결 기록, 라우팅 정보를 함께 확인하세요. 또한 networksetup -setv6off를 일반적인 해결 방법으로 사용하지 마세요. 권한 오류와 IPv6 설정은 반드시 관련이 있는 것은 아닙니다.

키체인 팝업이 반복될 때: 요청 항목을 확인한 뒤 승인 여부를 결정하세요

클라이언트는 구독 자격 증명, 토큰 또는 기타 민감한 설정을 키체인에 저장할 수 있습니다. 팝업에는 대개 요청 프로세스와 대상 항목 이름이 표시됩니다. 현재 사용 중인 클라이언트에서 보낸 요청인지 먼저 확인하세요. 모르는 프로세스이거나 프록시와 관련 없는 항목이면 일단 거부하고 원인을 확인하세요. TUN에 관리자 권한을 부여했다고 해서 앱이 모든 키체인 항목에 접근할 수 있는 것은 아닙니다.

“한 번 허용”과 “항상 허용”의 차이

“한 번 허용”은 보통 현재 접근만 승인하므로 이후에도 팝업이 다시 표시될 수 있습니다. “항상 허용”은 해당 항목에 대한 접근 권한을 저장합니다. 앱의 신원과 항목의 용도를 확인한 경우에만 지속적으로 허용하세요. 앱 사본을 바꾸거나 서명 신원이 변경되거나 다른 빌드 배포 경로로 옮기면 기존 접근 권한이 더 이상 적용되지 않을 수 있습니다. 따라서 업데이트 후 다시 묻는다고 반드시 오류인 것은 아닙니다.

로그인 키체인이 정상적으로 잠금 해제되는지 확인

Spotlight에서 “키체인 접근”을 검색해 열고 “로그인” 키체인을 선택하세요.
키체인이 잠겨 있는지 확인하세요. 잠겨 있다면 키체인에 설정된 암호로 잠금 해제를 시도하세요.
팝업에 표시된 항목 이름을 검색해 세부 정보를 열고 “접근 제어” 등 사용 가능한 옵션을 확인하세요.
접근이 허용된 앱이 현재 설치된 클라이언트를 가리키는지 확인하세요. 모든 앱의 접근을 허용하도록 변경하지 마세요.

복구 절차나 다른 관리자 계정을 통해 Mac 로그인 암호를 재설정했다면 로그인 키체인은 이전 암호를 계속 사용하고 있을 수 있습니다. 이 경우 새 로그인 암호로는 잠금이 풀리지 않을 수 있습니다. 이전 암호를 알고 있다면 시스템에서 제공하는 방법으로 키체인 암호를 업데이트하세요. 이전 암호를 모른다면 기본 키체인 재설정에 관한 시스템 안내를 먼저 읽고, 로컬에 저장된 자격 증명이 사라질 때의 영향을 검토하세요.

앱을 실행할 때마다 똑같은 승인 요청이 표시되면 여러 앱 사본이 동시에 실행 중인지, 앱이 매번 다른 경로에서 실행되는지, 시스템 시간이 정확한지 먼저 확인하세요. 그다음 클라이언트 업데이트 안내와 로그를 살펴보세요. 비밀번호를 반복 입력하는 것만으로 항목 권한과 앱 서명 불일치 문제를 해결할 수는 없습니다.

업데이트, 제거 및 네트워크 복구 순서

클라이언트를 교체하기 전에 설정을 내보내거나 백업하고 현재 포트, 규칙 모드, TUN 사용 여부를 기록하세요. TUN을 끄고 시스템 프록시를 끈 다음 클라이언트를 종료한 뒤 앱을 교체하세요. 보조 서비스나 네트워크 확장을 제거해야 한다면 클라이언트 자체의 제거 기능을 우선 사용하세요. 앱을 휴지통으로 옮기는 것만으로 시스템 구성 요소가 제거되지는 않을 수 있습니다.

앱을 종료한 뒤 웹페이지가 열리지 않음: “네트워크” → 현재 연결 → “세부사항” → “프록시”에서 중지된 포트를 가리키는 설정이 남아 있지 않은지 확인하세요.
직접 연결로 바꿔도 DNS 조회에 실패함: 수동 DNS 설정, 다른 VPN 또는 네트워크 필터가 남아 있는지 확인하세요. 기존 값을 기록한 뒤 복구하고, 여러 항목을 한꺼번에 변경하지 마세요.
업데이트 후 서비스가 작동하지 않음: 앱 아키텍처와 보조 서비스 상태를 확인하고 클라이언트 문서에 따라 서비스를 복구한 뒤 시스템 프록시를 다시 테스트하세요.
확장 프로그램을 계속 허용할 수 없음: 기기가 관리 대상인지 확인하고 시스템 버전, 개발자 이름, 오류 메시지를 기록해 관리자나 프로젝트 유지 관리자에게 문의하세요.

문제를 보고할 때는 클라이언트 버전, macOS 버전, 칩 종류, 시스템 프록시 또는 TUN 사용 여부, 오류가 발생한 시간을 기록하세요. 로그에서 구독 주소, 토큰, 노드 자격 증명, 개인 도메인은 가려야 합니다. “앱 실행 가능 여부 → 로컬 포트 수신 여부 → 시스템 프록시 적용 여부 → TUN 연결 여부 → 키체인 접근 여부” 순서로 확인하면 재설치와 DNS 변경, 키체인 초기화를 한꺼번에 시도하는 것보다 원인을 찾기 쉽습니다.

설정 항목을 자세히 확인하려면 초보자부터 고급 설정까지 안내를 참고하세요. 설치 단계에서 문제가 발생했다면 클라이언트 설치 가이드를 확인하세요. 권한을 설정한 뒤에도 연결되지 않는다면 시스템 권한을 더 추가하기보다 노드 연결 상태, DNS, 규칙을 점검하세요.