네 가지 권한 안내 구분하기

macOS에서 클라이언트 창이 열려도 프록시에 필요한 서비스가 실행 중이라는 뜻은 아닙니다. 처음 설치할 때 표시되는 안내는 Gatekeeper, 관리자 승인, 네트워크 확장, 키체인 등 서로 다른 기능에서 나올 수 있습니다. 각각 처리하는 문제가 다르며, 거부 후 다시 설정하는 방법도 다릅니다.

Mihomo는 코어이고, 클라이언트는 설정 화면과 시스템 연동, 권한 요청을 담당합니다. 클라이언트마다 TUN 구현 방식도 다릅니다. 일부는 권한이 있는 보조 서비스를 통해 코어를 실행하고, 일부는 Network Extension을 사용합니다. TUN 스위치가 보인다는 이유만으로 시스템 설정에서 네트워크 확장을 찾아야 하는 것은 아닙니다.

안내 내용 실제 용도 확인할 항목
개발자를 확인할 수 없어 앱을 열 수 없음 앱 출처와 서명 상태 확인 설치 출처 및 시스템 보안 경고
보조 도구 설치, 관리자 승인 필요 권한이 필요한 서비스 설치 또는 업데이트 요청한 앱과 관리자 계정
VPN 구성 추가 및 네트워크 확장 허용 시스템 네트워크 트래픽을 처리하는 경로 구성 확장 이름과 클라이언트 구현 방식
로그인 키체인의 항목에 접근 저장된 자격 증명 읽기 요청 프로세스, 항목 이름, 접근 권한 범위

첫 실행: 설치 위치와 보안 확인

프로세서 종류를 확인하고 응용 프로그램 폴더에서 실행

  1. Apple 메뉴 → ‘이 Mac에 관하여’를 여세요. ‘Apple M… 칩’으로 표시되면 보통 Apple Silicon 또는 arm64 설치 파일을 선택하고, Intel 프로세서라면 x64 설치 파일을 선택합니다. 범용 설치 파일은 클라이언트 안내를 따르세요.
  2. DMG로 배포되는 클라이언트는 앱을 ‘응용 프로그램’ 폴더로 드래그한 뒤 디스크 이미지를 추출하세요. DMG 안에서 계속 실행하지 마세요.
  3. 실행 중인 이전 버전을 종료한 뒤 ‘Finder’ → ‘응용 프로그램’에서 실행하세요. 이전 버전과 새 버전을 동시에 실행하면 포트가 충돌하거나 보조 서비스 버전이 맞지 않을 수 있습니다.
  4. 처음에는 설정만 가져와 코어가 실행되는지 확인한 다음, 시스템 프록시나 TUN을 하나씩 켜세요. 어느 단계에서 문제가 발생하는지 파악하기 쉽습니다.

일반 차단과 위험 경고 구분하기

macOS 13 Ventura, 14 Sonoma, 15 Sequoia에서는 보통 ‘시스템 설정’ → ‘개인정보 보호 및 보안’에서 관련 항목을 확인합니다. 앱을 열려고 한 뒤 이 페이지에 차단 기록이 표시될 수 있습니다. 설치 출처를 신뢰할 수 있고 시스템에 해당 옵션이 있을 때만 안내에 따라 ‘그래도 열기’를 선택하세요. 시스템 버전에 따라 버튼 이름과 위치가 조금씩 다를 수 있습니다.

‘앱이 손상되었기 때문에 열 수 없습니다’라는 메시지는 일반적인 첫 실행 확인과 다릅니다. 다운로드가 불완전하거나 서명이 비정상적이거나 앱 패키지가 수정된 경우에도 나타날 수 있습니다. 현재 설치 파일을 삭제하고 클라이언트 개발자가 안내한 배포 경로에서 다시 받은 뒤 시스템 요구 사항을 확인하세요. 시스템에서 컴퓨터를 손상시키거나 악성 소프트웨어가 포함되어 있다고 명확히 경고하면 우회하지 말고 실행을 중단하세요.

  • Gatekeeper를 끄는 것을 일반적인 설치 절차로 삼지 마세요.
  • 다운로드 폴더 전체의 격리 속성을 일괄 제거하지 마세요.
  • 회사에서 관리하는 Mac은 기기 관리 정책의 제한을 받을 수 있습니다. 이 경우 관리자에게 허용된 클라이언트와 확장을 확인하세요.

보조 서비스: 관리자 승인과 거부 후 재시도

일반 시스템 프록시와 TUN은 필요한 권한이 다릅니다. 시스템 프록시는 주로 현재 네트워크 서비스의 프록시 설정을 바꾸지만, TUN은 가상 인터페이스와 라우팅, DNS 조정도 필요할 수 있습니다. 클라이언트가 상시 실행되는 보조 서비스를 통해 이런 작업을 수행한다면 ‘보조 도구 설치’ 또는 ‘서비스 업데이트’를 위한 관리자 인증 창이 나타날 수 있습니다.

승인 전에 세 가지 항목 확인

  • 요청 주체: 방금 조작한 클라이언트 또는 알려진 보조 프로그램이어야 합니다. 출처를 알 수 없는 스크립트 프로세스라면 승인하지 마세요.
  • 작업: 서비스 설치나 업데이트, 네트워크 설정 변경인지 확인하세요. 프록시와 무관한 작업이라면 승인하지 마세요.
  • 계정: 일반 사용자는 보통 관리자 계정 자격 증명을 입력해야 합니다. 관리자 암호는 macOS 시스템 인증 창에 입력하고, 구독 페이지나 채팅 메시지에 붙여 넣지 마세요.

방금 ‘취소’를 눌렀더라도 보통 클라이언트 전체를 다시 설치할 필요는 없습니다. 클라이언트의 서비스 관리 메뉴로 돌아가 설치나 복구를 다시 실행하세요. 메뉴 이름은 ‘서비스 모드’, ‘보조 서비스’, ‘서비스 설치’ 등일 수 있으므로 현재 클라이언트 화면을 기준으로 확인하세요. 작업을 마친 뒤 클라이언트를 종료하고 다시 실행해 로그를 확인하세요.

서비스 설치 후에도 TUN이 시작되지 않는 경우

로그에 permission denied, 보조 서비스 연결 실패, 포트 사용 중 등의 메시지가 있는지 먼저 확인하세요. 클라이언트를 업데이트한 뒤에도 이전 보조 서비스가 실행 중일 수 있습니다. 우선 클라이언트에 내장된 서비스 업데이트 또는 재설치 기능을 사용하세요. 온라인에서 찾은 일반 명령어만 믿고 /Library/LaunchDaemons 안의 파일을 직접 삭제하지 마세요. 클라이언트마다 서비스 식별자가 다릅니다.

macOS 13 이후 버전에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목’ 또는 ‘로그인 항목 및 확장 프로그램’에서 백그라운드 활동 항목도 확인할 수 있습니다. 백그라운드 항목과 네트워크 확장은 서로 다른 설정입니다. 클라이언트 이름이 보이면 해당 기능이 무엇인지 클라이언트 안내와 함께 확인하세요.

네트워크 확장 및 VPN 구성 승인

관련 시스템 기능을 사용하는 클라이언트만 네트워크 확장을 요청하거나 VPN 구성을 추가합니다. 권한이 있는 서비스를 통해 Mihomo TUN을 실행하는 클라이언트는 이런 팝업이 전혀 없을 수도 있습니다. 이 경우 존재하지 않는 확장 항목을 계속 찾기보다 서비스와 코어 로그를 확인하세요.

macOS 버전별 설정 위치

  • macOS 15 Sequoia: ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’으로 이동해 ‘확장 프로그램’ 영역의 ‘네트워크 확장’을 찾고, 세부 정보에서 클라이언트 항목을 확인하세요.
  • macOS 13 Ventura, 14 Sonoma: ‘시스템 설정’에서 ‘VPN’ 또는 ‘필터’를 검색해 네트워크 관련 구성을 확인하세요. 확장이 차단되었다는 안내를 받았다면 ‘개인정보 보호 및 보안’에 관련 기록이 있는지도 확인하세요.
  • 그 밖의 버전: 시스템 설정에서 ‘네트워크 확장’, ‘VPN’ 또는 ‘필터’를 검색하는 것이 좋습니다. 확장 유형에 따라 설정 위치가 다를 수 있으므로 특정 버전의 메뉴 경로를 모든 버전에 동일하게 적용하지 마세요.

‘VPN 구성 추가 허용’은 클라이언트가 시스템 네트워크 구성을 만들도록 승인하는 기능입니다. 구독을 성공적으로 가져왔다는 뜻도, 프록시 노드를 사용할 수 있다는 뜻도 아닙니다. 허용한 뒤 클라이언트로 돌아가 구성을 선택하고 코어를 실행한 다음 연결을 확인하세요. 시스템 메뉴에 VPN 상태가 표시되어도 규칙 적용 여부나 실제 연결 경로를 확인하는 일을 대신할 수는 없습니다.

승인을 거부한 뒤 복구하는 순서

  1. 백그라운드에서 재시도를 반복하지 않도록 클라이언트의 TUN 또는 연결 스위치를 끄세요.
  2. 시스템 설정에서 해당 확장이 비활성화되어 있는지, 차단 기록이 남아 있는지 확인하세요.
  3. 클라이언트로 돌아가 연결을 다시 시도하거나 확장을 설치하고 시스템 안내에 따라 승인하세요. 시스템에서 명확히 요구하는 경우에만 재시동하세요.
  4. 이전 VPN 구성이 여러 개 있다면 먼저 어느 앱의 구성인지 확인한 뒤 원래 클라이언트의 제거 기능으로 정리하세요. 여전히 사용하는 회사 VPN은 삭제하지 마세요.

키체인 팝업: 암호, 허용, 항상 허용

클라이언트는 구독 자격 증명, 액세스 토큰 또는 기타 민감한 설정을 키체인에 저장할 수 있습니다. 저장 항목은 구현 방식에 따라 달라집니다. 코어 실행, 창 열기, 키체인 접근은 각각 별개의 작업입니다. 팝업이 나타나면 클라이언트가 실행 중인지에만 주목하지 말고 ‘어떤 프로세스가 어떤 항목에 접근하려는지’ 확인하세요.

세 가지 버튼의 권한 범위

  • 거부: 이번 접근을 차단합니다. 관련 기능에서 자격 증명을 읽지 못할 수 있지만, 보통 키체인에 저장된 항목을 삭제하지는 않습니다.
  • 허용: 현재 접근 요청을 승인합니다. 기능이 복구되는지 먼저 확인할 때 적합합니다. 다음 접근 때 다시 묻는 경우가 있습니다.
  • 항상 허용: 해당 앱이 항목에 접근할 수 있도록 권한을 저장합니다. 앱의 신원과 항목의 용도를 확인한 경우에만 선택하고, 알 수 없는 프로세스에는 허용하지 마세요.

로그인 키체인 암호는 보통 현재 macOS 로그인 암호와 같지만, 항상 그런 것은 아닙니다. 관리자가 계정 암호를 재설정했거나 이전 키체인을 마이그레이션으로 복원했다면 키체인에 예전 암호가 설정되어 있을 수 있습니다. 현재 암호를 여러 번 입력해도 실패한다면 계속 반복하지 말고 이 가능성을 확인하세요.

키체인 접근에서 해당 항목 찾기

  1. Command + 스페이스를 누르고 ‘키체인 접근’을 검색해 여세요. 최신 시스템의 ‘암호’ 앱으로는 모든 키체인 관리 기능을 사용할 수 없습니다.
  2. ‘로그인’ 키체인을 선택한 뒤 팝업에 표시된 항목 이름을 검색하세요. 해당 항목만 확인하고 모두 선택해 삭제하지 마세요.
  3. 항목 세부 정보를 열어 유형과 접근 제어를 확인하세요. 항목 유형에 따라 수정할 수 있는 옵션이 다를 수 있습니다.
  4. 클라이언트가 저장한 자격 증명이 만료된 것이 확실하다면 클라이언트에서 다시 로그인하거나 자격 증명을 갱신하는 방법을 우선 사용하세요. 항목 하나를 삭제해야 한다면 필요한 계정 정보를 다시 받을 수 있는지 먼저 확인하세요.

클라이언트를 업데이트한 뒤 키체인 권한을 다시 요청한다고 해서 반드시 암호가 틀렸다는 뜻은 아닙니다. 앱 경로, 서명된 앱의 신원, 접근 제어 조건이 바뀌어도 다시 확인을 요청할 수 있습니다. 먼저 업데이트 출처와 팝업에 표시된 프로세스 이름을 확인한 뒤 권한을 다시 승인할지 결정하세요.

권한 설정 후 연결 확인

권한 설정을 마쳤다면 ‘코어 수신 대기 → 시스템 프록시 → TUN’ 순서로 확인하세요. DNS, 규칙, 프록시 포트를 한꺼번에 바꾸면 어떤 변경으로 복구되었는지 판단하기 어렵습니다. 먼저 기존 설정을 저장하고 각 단계의 로그 시간을 기록하세요.

1단계: 코어 포트가 수신 대기 중인지 확인

아래 예시는 클라이언트 설정이 mixed-port: 7890인 경우입니다. 7890은 예시일 뿐 모든 클라이언트의 고정 포트가 아닙니다. 화면에 다른 값이 표시되면 명령어에서도 해당 값으로 바꾸세요. ‘터미널’을 열고 다음을 실행합니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN

출력이 있으면 수신 대기 중인 프로세스가 현재 클라이언트에 속하는지 확인하세요. 출력이 없다면 코어가 실행 중인지, 구성을 정상적으로 읽었는지, 포트가 다른 값으로 지정되어 있지 않은지 먼저 확인하세요. 관리자 승인을 마쳤다고 해서 코어가 반드시 수신 대기 중인 것은 아닙니다.

2단계: 프록시를 별도로 테스트한 뒤 시스템 설정 확인

curl -I --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 https://example.com/

scutil --proxy

첫 번째 명령은 로컬 프록시를 명시적으로 지정하고, 연결 제한 시간은 10초, 전체 제한 시간은 20초로 설정합니다. 이를 통해 프록시 자체의 문제와 시스템 프록시 설정 문제를 구분할 수 있습니다. HTTP 응답을 받았다는 것은 해당 요청에 응답이 왔다는 뜻일 뿐입니다. 상태 코드와 클라이언트 연결 기록, 적용된 정책도 함께 확인해야 합니다.

두 번째 명령은 시스템 프록시 상태를 확인합니다. 일반 HTTP/HTTPS 시스템 프록시를 사용한다면 HTTPEnable, HTTPSEnable, 서버, 포트가 클라이언트 설정과 일치하는지 확인하세요. PAC를 사용한다면 자동 프록시 관련 항목을 확인하세요. TUN은 이 스위치가 1일 필요가 없으므로 이 값만으로 TUN 실패를 판단할 수 없습니다.

3단계: TUN만 켜고 로그 확인

  • 먼저 보조 서비스 또는 필요한 확장이 준비되었는지 확인한 다음 TUN을 켜세요.
  • 스위치 색상만 보지 말고 로그에서 가상 인터페이스, 라우팅 또는 DNS 초기화가 실패했는지 확인하세요.
  • 일반 웹사이트와 프록시가 필요한 대상에 각각 예상한 규칙이 적용되는지 확인하세요. 규칙 모드에서는 요청마다 서로 다른 경로를 사용할 수 있습니다.
  • 클라이언트를 종료한 뒤 네트워크와 시스템 프록시 상태를 다시 확인해, 중지된 포트를 가리키는 프록시 설정이 남아 있지 않은지 점검하세요.

자주 발생하는 문제의 빠른 점검 순서

권한을 거부한 뒤 클라이언트에서 팝업이 다시 표시되지 않음

먼저 어떤 종류의 요청을 거부했는지 확인하세요. 보조 서비스는 클라이언트에서 다시 설치하고, 네트워크 확장은 시스템 설정에서 상태를 확인하고, 키체인은 자격 증명이 필요한 작업을 다시 실행해 팝업을 띄우세요. ‘구독 다시 가져오기’를 모든 권한 문제의 해결책으로 여기지 마세요. 구독 내용은 시스템 권한을 바꾸지 못합니다.

시스템 프록시는 되지만 TUN을 켜면 인터넷이 끊김

먼저 정상 작동하는 시스템 프록시 상태로 되돌린 뒤 TUN 로그, 다른 VPN과의 충돌, DNS 설정을 확인하세요. 시스템 프록시가 작동한다는 것은 연결 경로 일부가 정상이라는 뜻일 뿐, TUN에 필요한 라우팅과 권한까지 준비되었다는 뜻은 아닙니다. 문제를 확인하는 동안 복구 가능한 설정을 유지하고, 네트워크가 끊긴 상태에서 복구 도구를 계속 다운로드하지 마세요.

시작할 때마다 암호 입력을 요구함

먼저 암호 입력창이 시스템 인증인지 키체인 접근인지 확인하세요. 시스템 인증이라면 보조 서비스가 제대로 설치되었는지, 매번 업데이트되는지 확인합니다. 키체인 접근이라면 해당 항목의 접근 제어, 앱을 고정된 경로에서 실행하는지, 클라이언트 사본이 여러 개 남아 있는지 확인하세요. 인증을 우회하려고 관리자 암호를 스크립트에 저장하지 마세요.

유지 관리 담당자에게 문제를 보낼 때 필요한 정보

  • ‘이 Mac에 관하여’에서 확인할 수 있는 macOS 전체 버전 번호와 Apple Silicon 또는 Intel 여부
  • 클라이언트 버전과 코어 버전을 각각 기록하세요. 두 버전을 혼동하지 마세요.
  • 문제를 재현하는 단계, 팝업에 표시된 원문, 문제 발생 전후 몇 초간의 관련 로그
  • 현재 시스템 프록시와 TUN 중 무엇을 사용하는지, 실제 수신 대기 포트, 다른 네트워크 처리 도구를 함께 실행 중인지

스크린샷과 로그를 보내기 전에 구독 전체 주소, 계정 토큰, 노드 암호와 기타 개인 정보를 가리세요. 권한 유형에 맞는 정보를 제공하면 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다. 한 번에 설정 하나만 바꿔야 해결 여부를 정확히 판단할 수 있습니다.