먼저 권한 요청 유형 4가지 구분하기

macOS의 앱 실행 차단, 관리자 권한 요청, 네트워크 확장 허용, 키체인 접근은 서로 다른 보안 기능입니다. 문제를 확인할 때는 안내 문구 전체, 요청한 프로세스 이름, 발생 시각, 직전에 수행한 작업을 기록하세요. 모든 팝업을 ‘TUN 권한 부족’으로 단정하거나 비밀번호를 연달아 입력해 확인하지 마세요.

안내 문구 또는 증상관련 기능우선 확인할 항목
개발자를 확인할 수 없음, 악성 소프트웨어가 포함되어 있는지 확인할 수 없음Gatekeeper 앱 실행 확인설치 경로, 서명, 개인정보 보호 및 보안 설정
보조 도구 설치 중 관리자 암호 요청권한이 필요한 보조 서비스 승인서비스를 직접 설치하거나 복구한 직후인지 확인
시스템 확장 프로그램 차단, VPN 구성 추가 요청확장 프로그램 또는 네트워크 구성 승인요청한 앱이 현재 구성 요소와 일치하는지 확인
‘로그인’ 키체인의 기밀 정보에 접근 요청키체인 항목 접근 제어항목 이름, 요청한 앱, 로그인 암호

설치 경로와 ‘앱을 열 수 없음’ 해결

macOS 버전과 프로세서 확인

  1. Apple 메뉴 → ‘이 Mac에 관하여’를 열고 macOS 버전과 ‘칩’ 또는 ‘프로세서’ 항목을 확인하세요. Apple M 시리즈는 Apple Silicon에 해당하며, Intel Mac에는 x86_64 설치 패키지를 선택합니다.
  2. 다운로드 페이지에서 macOS와 프로세서 아키텍처에 맞는 패키지를 선택하세요. 유니버설 패키지가 제공되더라도 해당 버전의 최소 지원 macOS 버전을 확인해야 합니다. 파일 이름만 보고 호환 여부를 판단하지 마세요.
  3. 디스크 이미지를 열고 앱을 ‘응용 프로그램’ 폴더로 복사하세요. 이미지 안에서 실행 중인 이전 앱을 종료한 다음 이미지를 추출하고, ‘응용 프로그램’ 폴더에서 앱을 실행합니다.
  4. 업데이트 전에 클라이언트를 종료하세요. 기존 설정은 보존하고 현재 버전, 선택한 코어, 수신 대기 포트를 기록해 두세요. 문제 해결의 첫 단계로 설정 폴더 전체를 삭제하지 마세요.

앱을 다운로드 폴더나 디스크 이미지에서 계속 실행하면 경로가 바뀌거나 앱 복사본이 중복될 수 있습니다. 설치 위치를 정한 뒤 Finder에서 ‘응용 프로그램’ 폴더를 열고 사용할 앱 하나만 실행하는지 확인하세요. 앱 아키텍처 불일치, macOS 버전 미지원, 서명 차단은 서로 다른 문제이므로 같은 명령으로 해결할 수 없습니다.

시스템 안내에 따라 앱 실행 허용하기

macOS 13 Ventura, 14 Sonoma, 15 Sequoia에서는 Apple 메뉴 → ‘시스템 설정’ → ‘개인정보 보호 및 보안’에서 보안 안내를 확인할 수 있습니다. 먼저 앱을 한 번 실행한 다음 페이지 아래쪽에 해당 앱의 차단 기록이 표시되는지 살펴보세요. 출처와 앱 이름을 확인한 뒤 시스템에 ‘그래도 열기’가 표시되면 안내에 따라 본인 인증을 하고 다시 실행할 수 있습니다. macOS 15는 서명되지 않았거나 공증되지 않은 일부 앱을 더 엄격하게 처리하므로 Finder에서 마우스 오른쪽 버튼을 눌러 ‘열기’를 선택하는 방법이 항상 통한다고 볼 수 없습니다.

  • 개발자를 확인할 수 없다는 안내: 다운로드 출처와 릴리스 정보를 먼저 확인한 뒤, 시스템에서 제공하는 예외 허용 절차를 사용할지 판단하세요.
  • 앱이 손상되었다는 안내: 실행 중인 앱을 종료하고 아키텍처에 맞는 패키지를 다시 다운로드한 뒤 ‘응용 프로그램’ 폴더에 복사하세요. 이 안내는 서명 문제나 앱 콘텐츠 변경을 뜻할 수도 있으며, 네트워크 다운로드 중단만을 의미하지는 않습니다.
  • 컴퓨터가 손상되거나 악성 소프트웨어가 포함될 수 있다는 안내: 앱 실행을 중단하고 배포 정보를 확인하세요. 격리 속성을 삭제해 강제로 실행하지 마세요.
  • 관리되는 기기에서 허용 버튼이 표시되지 않는 경우: 조직 관리자에게 문의해 기기 관리 정책을 확인하세요. 시스템 보안 정책을 직접 변경하지 마세요.

서명 관련 단서를 유지관리자에게 제공해야 한다면 터미널에서 아래 읽기 전용 명령을 실행할 수 있습니다. 이 경로는 앱이 해당 이름으로 ‘응용 프로그램’ 폴더에 설치된 경우에 해당합니다. 실제 앱 이름이 다르면 먼저 Finder에서 경로를 확인하세요.

sw_vers
uname -m
codesign --verify --deep --strict --verbose=2 "/Applications/Clash Nyanpasu.app"
spctl --assess --type execute --verbose=4 "/Applications/Clash Nyanpasu.app"

uname -m은 Apple Silicon에서 기본으로 실행한 터미널에서는 대개 arm64를 반환하고, Intel Mac이나 Rosetta 변환 환경에서는 x86_64를 반환할 수 있습니다. 따라서 아키텍처는 ‘이 Mac에 관하여’를 기준으로 선택하세요. 서명 확인 결과는 문제를 좁히기 위한 참고 정보일 뿐, 프로그램의 모든 동작을 검증했다는 뜻은 아닙니다. 클라이언트를 설치하려고 Gatekeeper나 시스템 무결성 보호를 끄지 마세요.

시스템 프록시를 먼저 확인한 다음 서비스와 TUN 켜기

최소 구성으로 정상 작동 확인하기

처음 실행할 때는 사용할 수 있는 Clash YAML 구성을 가져온 다음, 해당 구성이 선택되어 있고 코어가 정상적으로 실행되는지 확인하세요. 이어서 일반 시스템 프록시를 테스트합니다. 클라이언트 화면의 메뉴 위치는 버전에 따라 달라질 수 있으므로, 여기서는 ‘시스템 프록시’, ‘서비스 모드’, ‘TUN 모드’라는 기능 이름을 기준으로 설명합니다. 모든 버전의 메뉴 구성이 같다고 가정하지 않습니다.

  1. 프로필 페이지에서 사용할 구성을 선택하고 코어 로그를 확인해 YAML 파싱 오류나 포트 충돌이 없는지 살펴보세요.
  2. 실제 HTTP 또는 혼합 수신 대기 포트를 기록하세요. 구성에 mixed-port: 7890이 있는 경우에만 127.0.0.1:7890을 사용합니다. 7890을 모든 설치에서 공통으로 쓰는 고정값으로 여기지 마세요.
  3. 시스템 프록시를 켜고 브라우저에서 연결을 확인하세요. 이때는 트래픽 진입점, 라우팅, DNS를 동시에 바꾸지 않도록 TUN을 꺼 둡니다.
  4. 일반 프록시가 정상 작동하는 것을 확인한 뒤, 앱이 시스템 프록시 설정을 따르는지에 따라 TUN을 켤지 결정하세요.
# 실제 mixed-port가 7890인 구성에만 적용
lsof -nP -iTCP:7890 -sTCP:LISTEN
scutil --proxy

lsof로 수신 대기 중인 프로세스를 확인하고, scutil --proxy로 현재 시스템 프록시 설정을 확인할 수 있습니다. 포트가 열려 있다고 해서 규칙 그룹, 원격 노드, DNS까지 모두 정상이라는 뜻은 아닙니다. 로그에 address already in use가 표시되면 먼저 포트를 사용 중인 프로세스를 찾고, 중복 실행된 클라이언트를 종료하거나 포트를 변경하세요. 이름이 비슷한 프로세스를 모두 강제 종료하지 마세요.

관리자 암호는 명확한 서비스 작업에만 입력하기

TUN 생성이나 라우팅 변경에는 권한이 필요한 서비스가 필요할 수 있습니다. 현재 버전에 서비스 설치 또는 복구 기능이 있다면 클라이언트에서 직접 실행한 뒤, 시스템 암호 입력 창에 표시된 앱이나 보조 도구 이름을 확인하세요. 정상적인 관리자 권한 승인과 그 뒤에 나타나는 키체인 접근 창은 서로 다릅니다. 전자는 권한이 필요한 작업을 승인하고, 후자는 특정 기밀 항목을 읽도록 허용합니다.

  • 관리자 권한이 있는 계정으로 서비스를 설치하세요. 일반 계정은 관리자에게 도움을 요청해야 합니다.
  • 업데이트 후 서비스와 클라이언트 버전이 서로 맞지 않으면 현재 버전의 관리 기능으로 서비스를 복구한 다음 클라이언트를 다시 실행하세요.
  • 백그라운드 항목이 꺼졌다는 안내가 표시되면 macOS 13 및 14에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목’을 확인하세요. macOS 15에서는 ‘일반’ → ‘로그인 항목 및 확장 프로그램’을 확인합니다. 출처가 확인된 관련 항목만 허용하세요.
  • 서비스 설치에 실패하면 오류 문구 전체를 저장하세요. 앱 폴더 전체의 권한을 재귀적으로 변경하거나, 정상적인 서비스 설치 대신 sudo로 그래픽 클라이언트를 계속 실행하지 마세요.

네트워크 확장 및 VPN 구성 권한의 범위

팝업에 시스템 확장, 네트워크 확장 또는 VPN 구성이 명시된 경우에만 이 절차를 따르세요. 다른 VPN, 보안 소프트웨어, 트래픽 필터에서도 비슷한 안내가 표시될 수 있습니다. 요청한 프로세스를 먼저 확인하고, Clash Nyanpasu를 설치하는 중이라는 이유만으로 동시에 나타난 모든 네트워크 안내를 해당 앱의 요청으로 간주하지 마세요.

시스템 또는 안내확인 경로처리 원칙
macOS 13 / 14에서 확장 프로그램 차단시스템 설정 → 개인정보 보호 및 보안차단 기록에서 개발자와 구성 요소를 확인하고, 해당 허용 메뉴가 표시되는 경우에만 승인
macOS 15에서 확장 프로그램 관리시스템 설정 → 일반 → 로그인 항목 및 확장 프로그램 → 네트워크 확장실제로 표시된 구성 요소를 확인하고, 필요한 경우 해당 분류의 세부 정보 버튼 확인
VPN 또는 필터 구성시스템 설정 → 네트워크 → VPN 및 필터어떤 앱에 속한 항목인지 확인하세요. 시스템 버전과 설치된 구성 요소에 따라 표시되는 항목이 다를 수 있습니다.

확장 프로그램을 허용한 뒤 재시동이 필요한지는 시스템 안내를 따르세요. TUN을 켰는데 네트워크 확장 항목이 보이지 않는다고 해서 설치 실패로 단정할 수는 없습니다. 코어가 TUN 인터페이스를 만들었는지, 라우팅이 갱신됐는지, DNS 로그에 오류가 있는지 확인하세요. 반대로 확장 프로그램을 허용했더라도 구독에 포함된 노드에 연결할 수 있다는 뜻은 아닙니다.

키체인 팝업이 반복될 때 처리 순서

먼저 요청한 앱과 키체인 항목 확인

키체인 대화상자에는 보통 특정 앱이 ‘로그인’ 키체인의 기밀 정보에 접근하려 한다는 안내가 표시됩니다. 앱 이름과 항목 이름을 기록하세요. 구독 인증 정보, 프록시 인증, 다른 VPN에 저장된 암호가 네트워크 작업과 동시에 관련될 수 있습니다. 발생 시각이 겹친다는 이유만으로 Clash Nyanpasu 본체가 요청했다고 단정할 수는 없습니다. 현재 작업에 로그인이나 인증 정보 읽기가 필요하지 않다면 먼저 거부한 뒤 요청한 앱의 출처를 확인하세요.

‘허용’은 일반적으로 이번 접근만 승인합니다. ‘항상 허용’은 해당 항목의 접근 권한을 저장하지만 실제 적용 여부는 항목의 접근 제어 및 앱의 식별 정보에 따라 달라집니다. 팝업을 없애려고 모든 항목의 접근을 허용하지 마세요. 앱 업데이트, 서명 변경, 다른 복사본 실행으로 기존 접근 권한이 더 이상 일치하지 않을 수도 있습니다.

‘로그인’ 키체인 상태 확인

  1. Spotlight에서 ‘키체인 접근’을 검색해 여세요. macOS 15에는 ‘암호’ 앱도 있지만, 키체인 항목의 접근 제어는 ‘키체인 접근’에서 확인해야 합니다.
  2. ‘로그인’ 키체인을 선택하고 잠금 해제되어 있는지 확인하세요. 암호 입력 창에 필요한 것은 키체인 암호이며 구독 암호나 Apple 계정 암호가 아닙니다.
  3. 최근 관리자가 로컬 계정 암호를 재설정했다면 기존 ‘로그인’ 키체인은 이전 암호를 계속 사용할 수 있습니다. 이전 암호를 알고 있다면 키체인 접근에서 암호 변경 기능을 사용해 현재 로그인 암호로 바꾸세요.
  4. 팝업에 표시된 항목 이름을 정확히 검색해 항목 정보를 여세요. ‘접근 제어’ 탭이 있으면 접근이 허용된 앱이 현재 설치된 복사본을 가리키는지 확인하세요.
  5. 다른 위치에 있는 앱 복사본을 종료하고 ‘응용 프로그램’ 폴더에서 다시 실행한 다음, 같은 작업을 한 번 더 수행해 접근 요청이 반복되는지 확인하세요.

이전 키체인 암호를 모르면 계정 암호를 계속 입력해 보지 마세요. 기본 키체인을 재설정하면 새 키체인을 만들 수 있지만, 기존 항목이 자동으로 복호화되지는 않습니다. 저장된 암호, 인증서 또는 기타 인증 정보를 다시 입력해야 할 수 있습니다. 먼저 백업과 복구 방법을 확인하세요. 회사 인증서나 기기 관리 계정이 관련된 경우 관리자에게 도움을 요청하세요.

항목을 한꺼번에 삭제하지 않기

앱이 접근 권한을 저장하지 못하거나, 로그인 키체인이 정기적으로 잠기거나, 매번 다른 경로의 앱이 요청해 팝업이 반복될 수도 있습니다. 먼저 현재 실행 중인 앱 복사본과 항목 접근 제어를 확인하세요. 그런 다음 문제가 명확히 연관되어 있고 다시 가져올 수 있는 인증 정보만 재생성하는 방법을 고려하세요. ‘proxy’나 ‘VPN’이 포함된 항목을 찾았다고 전부 삭제하거나 키체인 폴더 전체를 다른 곳으로 옮기지 마세요.

스크린샷을 공유해야 한다면 항목의 계정 이름, 서버 주소, 토큰을 가리세요. 항목의 암호는 공개하지 마세요. 일반적인 문제 확인에는 요청한 앱, 항목 이름, 오류 문구만 있으면 되며 구독 URL을 공개할 필요는 없습니다.

권한 설정 후 확인 및 문제 발생 시 복구

‘앱 실행 → 코어 실행 → 일반 프록시 → 서비스 → TUN’ 순서로 단계별 확인을 진행하세요. 설정은 한 번에 하나씩만 변경하고 변경 전후 결과를 기록합니다. 아래 확인은 실제 구성에 근거하며 화면 스위치의 색상에는 의존하지 않습니다.

  • 앱 실행: ‘응용 프로그램’ 폴더에서 앱을 실행할 수 있고, 종료 후 다시 열어도 같은 실행 차단 안내가 반복되지 않습니다.
  • 코어: 로그에 구성 파싱 실패, 수신 대기 포트 충돌, 반복적인 종료 및 재시작이 없습니다.
  • 시스템 프록시: scutil --proxy에 표시된 활성화 항목, 주소, 포트가 클라이언트에 기록된 값과 일치합니다.
  • TUN: 로그에 가상 인터페이스가 정상적으로 생성되었다고 표시됩니다. 인터페이스 이름은 utun일 수 있지만, 다른 시스템 서비스도 같은 유형의 인터페이스를 만들 수 있으므로 utun이 있다는 이유만으로 성공을 판단하지 마세요.
  • 인증 정보: 같은 구독 업데이트 또는 인증 작업을 다시 수행했을 때 출처를 알 수 없는 키체인 요청이 반복되지 않습니다.

TUN을 켠 뒤 인터넷이 끊기면 먼저 클라이언트에서 TUN을 끈 다음 시스템 프록시를 끄고 기본 네트워크가 복구되는지 확인하세요. 상태를 확인하기 전에 Wi-Fi를 반복해서 껐다 켜지 마세요. 앱이 비정상 종료된 경우 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 로컬 포트를 가리키는 설정이 남아 있는지 확인할 수 있습니다. 이번 클라이언트가 설정한 프록시만 되돌리고 기존 기업 프록시 설정은 유지하세요.

문제를 제보할 때는 macOS 전체 버전, 칩 아키텍처, 클라이언트와 코어 버전, 설치 경로, 재현 단계, 같은 시간대의 로그를 제공하세요. 로그에 포함된 구독 URL, 액세스 토큰, 인증 암호, 개인 도메인은 먼저 가리세요. 구성 항목의 의미는 YAML 구성 가이드에서 확인할 수 있습니다. 처음으로 작동하는 구성을 만드는 경우 빠른 시작을 참고하세요.