macOS Clash 권한 설정: 네트워크 확장 승인 및 키체인 팝업

팝업부터 구분하기: 실행 확인, 네트워크 승인, 키체인은 서로 다릅니다

팝업 제목과 요청 프로세스를 먼저 확인한 뒤 승인 여부를 결정하세요.Clash는 프록시 코어와 클라이언트 생태계를 통칭하며, macOS 클라이언트마다 권한 처리 방식이 다릅니다. Clash Meta(mihomo) 코어를 사용한다고 해서 반드시 Apple 네트워크 확장을 사용하는 것은 아닙니다. 일부 클라이언트는 특권 보조 프로그램으로 TUN 인터페이스를 만들고, 일부는 Network Extension으로 트래픽을 처리합니다.

이 문서에서는 macOS 13 Ventura, 14 Sonoma, 15 Sequoia의 설정 이름을 기준으로 안내합니다. 먼저 왼쪽 위 Apple 메뉴 → ‘이 Mac에 관하여’에서 시스템 버전을 확인한 다음, 클라이언트의 ‘정보’ 화면에서 클라이언트 버전과 코어 버전을 기록하세요. 화면에 표시되는 문구가 다르면 시스템 팝업에 표시된 경로를 따르세요. 존재하지 않는 스위치를 찾으려고 추가 구성 요소를 설치하지 마세요.

처음 실행할 때 ‘손상됨’이 표시되면 설치 파일부터 다시 확인하세요

먼저 앱을 ‘응용 프로그램’ 폴더로 옮기세요

1. 메뉴 막대의 백그라운드 프로세스를 포함해 실행 중인 이전 버전을 모두 종료하세요.
2. 다운로드한 DMG를 열고 클라이언트를 ‘응용 프로그램’ 폴더로 드래그하세요. 디스크 이미지에서 계속 실행하지 마세요.
3. DMG를 추출한 다음 ‘응용 프로그램’ 폴더에서 클라이언트를 실행하세요. 경로를 고정하면 업데이트 후 권한 기록과 실제 앱이 일치하지 않는 문제를 줄일 수 있습니다.
4. 계속 실행되지 않으면 이 Mac에 맞는 설치 파일을 다시 받으세요. Apple Silicon Mac에서는 arm64, Intel Mac에서는 x64를 우선 선택하세요. Universal 패키지는 해당 아키텍처가 포함되어 있는지 확인해야 합니다.

‘손상되어 열 수 없습니다’라는 메시지가 표시되어도 다운로드한 파일이 실제로 손상된 것은 아닐 수 있습니다. 서명, 격리 속성 또는 패키징 방식이 원인일 수 있으며, 아키텍처가 맞지 않으면 다른 종류의 실행 오류가 나타날 수 있습니다. 팝업 문구만으로는 원인을 단정할 수 없습니다. 출처를 알 수 없는 설치 파일은 사용을 중단하세요. 격리 속성 제거를 모든 실행 문제의 해결책으로 여기지 마세요.

‘그래도 열기’는 출처를 확인한 앱에만 사용하세요

앱 실행이 차단된 뒤 ‘시스템 설정’ → ‘개인정보 보호 및 보안’을 열어 보안 섹션에 ‘그래도 열기’ 버튼이 있는지 확인하세요. 차단 사유에 따라 이 버튼이 표시되지 않을 수 있습니다. 앱 이름과 출처를 확인한 뒤 진행하세요. 시스템에서 악성 소프트웨어, 컴퓨터 손상 가능성 또는 인증서 취소를 명확히 알리면 실행을 중단하고 유지관리자에게 확인하세요.

네트워크 확장 및 TUN 승인: 클라이언트 구현 방식에 맞게 처리하기

시스템 프록시 설정을 따르는 브라우저만 연결하려는 경우에는 보통 ‘시스템 프록시’를 먼저 켜면 됩니다. 처음 설정할 때부터 TUN을 활성화할 필요는 없습니다. 시스템 프록시와 TUN은 서로 다른 기능입니다. 전자는 프록시 설정을 변경하고, 후자는 가상 인터페이스와 관련 라우팅을 통해 트래픽을 처리합니다. TUN을 사용해도 모든 앱과 프로토콜이 자동으로 정상 작동하는 것은 아니며, 실제 동작은 코어 설정과 라우팅 환경에 따라 달라집니다.

네트워크 확장 또는 VPN 구성 요청이 표시될 때

1. 클라이언트에서 ‘TUN 모드’ 또는 이에 해당하는 네트워크 처리 기능을 직접 켠 다음 팝업을 확인하세요. 관련 없는 백그라운드 프로그램에 권한을 부여하지 않도록 주의하세요.
2. VPN 구성을 추가하라는 요청이 표시되면 앱 이름을 확인하세요. 현재 사용하는 클라이언트가 요청한 것이 맞을 때만 ‘허용’을 누르세요.
3. macOS 15에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’ → ‘네트워크 확장’에서 해당 확장을 확인할 수 있습니다. 버전에 따라 항목 옆의 세부 정보 버튼을 눌러야 할 수도 있습니다.
4. macOS 13 및 14에서 시스템 소프트웨어가 차단되었다는 알림이 나타나면 안내에 따라 ‘개인정보 보호 및 보안’에서 ‘허용’을 찾으세요. VPN 또는 필터 항목은 ‘네트워크’ → ‘VPN 및 필터’에 표시될 수도 있습니다. 해당 항목이 없다고 설치가 실패한 것은 아닙니다. 먼저 클라이언트가 이 방식을 사용하는지 확인하세요.

클라이언트에 ‘서비스 설치’, ‘보조 프로그램 설치’ 또는 ‘Service Mode’라고 표시되면 관리자 인증은 대개 특권 보조 서비스를 설치하기 위한 것입니다. 키체인 잠금을 해제하는 절차가 아닙니다. 설치가 끝나면 클라이언트로 돌아가 서비스 상태를 확인한 뒤 TUN을 켜세요. 설치 버튼을 반복해서 누르지 마세요. 시스템이나 클라이언트에서 명확히 요구하는 경우에만 Mac을 재시동하세요.

키체인 팝업: 먼저 어떤 항목에 접근하는지 확인하세요

일반적인 팝업에는 ‘키체인에 저장된 기밀 정보를 사용하려고 합니다’라는 문구와 요청 프로세스 및 항목 이름이 표시됩니다. 이는 서비스 설치 시 필요한 관리자 인증과 다릅니다. 클라이언트는 구독 자격 증명, 액세스 토큰 또는 기타 민감한 설정을 키체인에 저장할 수 있지만 모든 Clash 클라이언트가 그렇게 하는 것은 아닙니다. 키체인 요청을 무조건 정상적인 동작으로 간주해서도 안 됩니다.

‘한 번 허용’과 ‘항상 허용’ 중 무엇을 선택할까요?

• 설치를 막 마쳐 항목의 용도를 확인하지 못했다면: 먼저 ‘거부’를 누르고 어떤 기능에 영향이 있는지 확인한 다음 클라이언트 안내를 살펴보세요. 거부하면 해당 기능을 일시적으로 사용할 수 없을 수 있습니다.
• 프로세스와 항목을 모두 확인했다면: 이번 접근을 완료하려면 먼저 ‘허용’을 누르고 구독 업데이트나 설정 저장이 다시 되는지 확인하세요.
• 계속 사용할 예정이고 신원 확인도 끝났다면: 그때 ‘항상 허용’을 고려하세요. 이 설정은 해당 키체인 항목에 대한 접근을 허용할 뿐, 모든 권한을 일괄 허용하는 것은 아닙니다.

팝업에서 요구하는 암호는 안내 문구를 기준으로 판단하세요. ‘로그인’ 키체인에 접근하려면 보통 해당 키체인의 암호가 필요합니다. 계정 로그인 암호와 같은 경우가 많지만, 다른 방법으로 계정 암호를 재설정했다면 서로 다를 수 있습니다. 구독 암호, Apple 계정 암호, 노드 암호를 차례로 입력하지 마세요.

모든 항목을 삭제하기 전에 ‘키체인 접근’에서 확인하세요

1. Spotlight에서 ‘키체인 접근’을 검색해 여세요. macOS 15의 ‘암호’ 앱은 전체 키체인을 관리하는 도구가 아닙니다.
2. ‘로그인’ 키체인을 선택한 다음 팝업에 표시된 항목 이름으로 검색하세요. ‘Clash’만 검색하지 마세요.
3. 검색된 항목을 열어 이름, 종류, 연결 정보를 확인하세요. 항목에 ‘접근 제어’가 있다면 허용된 앱이 현재 클라이언트를 가리키는지도 확인하세요.
4. 항목 하나의 접근 권한부터 복구하세요. ‘모든 응용 프로그램이 이 항목에 접근하도록 허용’을 선택하거나 기본 키체인 전체를 재설정하지 마세요.

업데이트 후 팝업이 반복된다면 경로, 서명, 로그인 키체인을 확인하세요

클라이언트 업데이트 후 처음 한 번 다시 확인을 요청하는 것은 드문 일이 아닙니다. 앱을 교체하면 서명 ID, 보조 프로세스 또는 키체인 접근 조건이 달라질 수 있습니다. 매번 실행할 때 요청하거나 허용을 누른 직후 팝업이 다시 나타나는 경우를 확인해야 합니다. 이때 암호를 계속 입력하면 문제를 가릴 뿐입니다.

로그인 암호를 변경한 뒤 잠금 해제가 안 되고 이전 키체인 암호를 알고 있다면 ‘키체인 접근’에서 키체인을 잠금 해제한 다음, 가능한 경우 ‘편집’ → ‘키체인 “로그인” 암호 변경’으로 암호를 동기화하세요. 이전 암호를 잊었다면 먼저 Apple 계정 복구 절차를 따르세요. 기본 키체인을 재설정하면 저장된 자격 증명에 영향을 주므로 영향을 먼저 확인해야 합니다.

특정 항목이 더 이상 유효하지 않고 다시 로그인하거나 자격 증명을 입력하는 방법도 알고 있을 때만 해당 항목을 삭제하세요. 삭제 전에 항목 이름을 기록하고 구독 서비스의 복구 경로를 준비하세요. 팝업을 없애려고 인증서, 개인 키 또는 클라이언트 이름이 포함된 항목을 한꺼번에 삭제하지 마세요.

승인 후 시스템 프록시와 포트를 확인해 테스트하세요

권한을 허용했다는 것은 특정 단계가 승인되었다는 뜻일 뿐, 노드가 작동한다는 의미는 아닙니다. ‘구성 활성화 → 코어 실행 → 로컬 포트 대기 → 트래픽 전달’ 순서로 확인하면 권한 설정과 노드 목록 사이에서 원인을 추측하는 일을 줄일 수 있습니다. 아래 명령은 조회 전용이며 시스템 프록시나 라우팅을 변경하지 않습니다.

sw_vers -productVersion
scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN

• sw_vers 명령으로 시스템 버전을 확인해 권한 설정 위치와 대조할 수 있습니다.
• scutil --proxy 명령으로 현재 시스템 프록시 정보를 확인하세요. HTTP/HTTPS 시스템 프록시를 켰다면 해당하는 HTTPEnable 및 HTTPSEnable 값이 1인지, 서버와 포트가 클라이언트 설정과 일치하는지 확인하세요. PAC를 사용한다면 자동 프록시 구성 항목을 확인하세요.
• lsof 명령으로 TCP 7890 포트를 사용하는 프로세스가 있는지 확인하세요. 7890은 흔히 쓰이는 예시 포트입니다. 클라이언트에서 mixed-port: 7897을 사용한다면 명령의 포트를 7897로 바꾸세요. 결과가 없다고 해서 권한이 거부되었다고 단정할 수는 없습니다.

네트워크 처리 기능을 한꺼번에 켜지 말고 두 단계로 테스트하세요

1. 먼저 TUN을 끄고 유효한 구성을 활성화한 뒤 시스템 프록시를 켜세요. 브라우저에서 접속 가능한 것으로 확인된 웹사이트를 열고, 클라이언트의 ‘연결’ 또는 ‘로그’에 요청이 표시되는지 확인하세요.
2. 시스템 프록시 테스트가 통과하면 클라이언트 안내에 따라 TUN을 테스트하세요. 트래픽 처리 방식을 구분하기 쉽도록 시스템 프록시를 잠시 끈 뒤 같은 웹사이트에 다시 접속하고, 실제 연결이 로그에 기록되는지 확인하세요.
3. 로그에 요청이 표시되지만 i/o timeout 오류가 발생하면 노드, 대상, 네트워크를 추가로 확인하세요. no such host 오류라면 DNS 경로부터 점검하세요. 이런 오류만으로 키체인 접근을 다시 승인하지 마세요.
4. 시작할 때 address already in use 오류가 표시되면 다른 클라이언트가 같은 포트를 사용 중인지 확인하세요. 이는 포트 대기 충돌이며 네트워크 확장 승인이 부족해서 발생하는 문제가 아닙니다.

여러 VPN, 기업 보안 소프트웨어, 프록시 클라이언트가 동시에 네트워크를 처리하면 라우팅과 DNS 충돌 가능성이 커집니다. 직접 관리할 권한이 있는 다른 네트워크 처리 기능만 잠시 끈 뒤 다시 테스트하세요. 관리형 기기에서는 기업 필터를 직접 제거하지 마세요. 더 자세한 진단이 필요하면 문제 해결 가이드를 참고하고, 테스트 당시 시스템 프록시와 TUN 중 무엇을 켰는지 기록하세요.

종료하거나 제거하기 전에 네트워크 설정을 복구하세요

먼저 클라이언트에서 TUN과 시스템 프록시를 끈 다음 프로그램을 종료하세요. 이어서 ‘시스템 설정’ → ‘네트워크’ → 현재 사용 중인 Wi-Fi 또는 이더넷 → ‘세부사항’ → ‘프록시’로 이동해 127.0.0.1을 가리키는 프록시 설정이 남아 있지 않은지 확인하세요. 회사나 학교에서 설정한 프록시는 변경하지 마세요.

클라이언트에 ‘서비스 제거’ 기능이 있다면 해당 메뉴를 이용해 보조 서비스를 제거하세요. 네트워크 확장과 VPN 구성도 클라이언트의 제거 안내에 따라 처리해야 합니다. 다른 사람의 터미널 명령을 그대로 따라 이름이 비슷한 시스템 파일을 삭제하지 마세요. 권한 문제를 마무리하려면 클라이언트 실행 중 요청이 의도한 경로로 전달되고, 종료 후 일반 네트워크가 복구되며, 재시동 후 같은 권한을 반복해서 요구하지 않아야 합니다.