macOS에서 Clash 클라이언트 설치: 네트워크 확장 승인, 키체인 팝업 및 ‘앱이 손상됨’ 해결

설치 전 확인: 클라이언트, 코어 및 macOS 권한 구분하기

Mac에서 ‘Clash 설치’를 검색하면 여러 프로젝트의 설치 파일이 나옵니다. Clash for Windows는 macOS 버전도 제공했지만 현재는 유지 관리가 중단되었습니다. Clash 또는 Clash Meta(mihomo) 코어를 사용하는 다른 클라이언트도 승인 절차가 모두 같은 것은 아닙니다. 화면 구성이 비슷하더라도 동일한 네트워크 확장이나 백그라운드 서비스를 사용하는 것은 아닙니다.

먼저 Mac의 프로세서, macOS 버전, 클라이언트 프로젝트명과 버전을 확인하세요. Apple 메뉴 → ‘이 Mac에 관하여’에서 칩 또는 프로세서를 확인하거나, ‘터미널’에서 다음 읽기 전용 명령을 실행할 수 있습니다.

sw_vers -productVersion
uname -m

arm64는 일반적으로 Apple 칩 환경, x86_64는 Intel 환경을 나타냅니다. Rosetta로 변환된 터미널에서 실행하면 출력된 아키텍처가 변환 환경을 반영할 수 있으므로, 설치 파일을 고를 때는 ‘이 Mac에 관하여’를 기준으로 하세요. Apple 칩 Mac에는 ARM64, Intel Mac에는 x64 설치 파일을 권장합니다. Universal 설치 파일에는 보통 두 아키텍처가 모두 포함됩니다.

• 앱 실행 허용: Gatekeeper가 다운로드 출처, 서명 및 공증 정보를 확인하며, 앱을 실행할 수 있는지 판단합니다.
• 네트워크 확장 또는 VPN 승인: 일부 클라이언트에서 트래픽을 처리하는 데 사용하며, 네트워크 터널을 만들 수 있는지와 관련됩니다.
• 보조 프로그램 또는 서비스 모드: 높은 권한이 필요한 백그라운드 구성 요소를 설치할 때 사용합니다. 네트워크 확장과는 별개입니다.
• 키체인 접근: 암호, 토큰 또는 기타 보호된 항목을 읽을 때 사용하며, 네트워크 연결 허용 여부와는 관계가 없습니다.

최초 설치: 앱을 응용 프로그램 폴더로 옮긴 뒤 실행 경고 처리하기

정해진 위치에 설치해 디스크 이미지에서 반복 실행하지 않기

1. 프로젝트 공식 배포 채널 또는 이 사이트의 설치 파일 페이지에서 macOS와 아키텍처에 맞는 버전을 선택하고, 해당 버전의 최소 macOS 요구 사항을 확인하세요.
2. DMG를 열어 앱을 ‘응용 프로그램’ 폴더로 드래그하세요. ZIP 파일은 먼저 압축을 푼 다음 전체 .app 앱을 옮기면 됩니다.
3. 설치용 디스크 이미지를 추출한 뒤 Finder → ‘응용 프로그램’에서 클라이언트를 실행하세요.
4. 처음 실행할 때는 TUN을 켜지 마세요. 먼저 설정을 가져온 다음 일반 프록시 연결을 확인하세요.

앱을 정해진 위치에 설치하면 업데이트, 보조 서비스 등록, 앱 식별 과정에서 혼란을 줄일 수 있습니다. 다운로드 폴더와 ‘응용 프로그램’ 폴더에 있는 앱을 동시에 실행하지 마세요. 메뉴 막대에 같은 아이콘이 두 개 나타나면 두 앱을 모두 종료한 뒤 최종 설치 위치에서 다시 실행하세요.

‘개발자를 확인할 수 없음’과 ‘앱이 손상됨’은 서로 다른 경고입니다

macOS 13 Ventura, macOS 14 Sonoma 또는 macOS 15 Sequoia에서 앱 실행이 차단되면 ‘시스템 설정’ → ‘개인정보 보호 및 보안’으로 이동해 하단의 보안 경고를 확인하세요. 출처를 확인했고 시스템에서 해당 옵션을 제공하는 경우에만 ‘그래도 열기’를 선택하고, 안내에 따라 본인 인증을 완료하세요. 시스템 버전에 따라 버튼 문구와 사용할 수 있는 작업이 다를 수 있습니다.

‘악성 소프트웨어가 있는지 확인할 수 없음’, ‘개발자를 확인할 수 없음’, ‘앱이 손상됨’은 서로 다른 검사 결과를 뜻합니다. 시스템에서 악성 소프트웨어가 포함되었거나 컴퓨터를 손상시킬 수 있다고 명확히 경고하면 실행을 중단하고 출처와 프로젝트 공지를 다시 확인하세요. 일반적인 실행 허용 절차를 무작정 적용해서는 안 됩니다. 최신 macOS에서는 이전 가이드에 나온 마우스 오른쪽 버튼 클릭 후 열기 방식이 제공되지 않을 수도 있습니다.

네트워크 확장, VPN 및 백그라운드 서비스 승인 방법

설정을 가져온 뒤 클라이언트 설정에서 트래픽 처리 방식을 확인하세요. ‘시스템 프록시’만 켜면 클라이언트는 보통 macOS의 HTTP, HTTPS 또는 SOCKS 프록시를 로컬 포트로 연결합니다. 해당 설정을 따르는 앱만 프록시를 사용합니다. TUN으로 전환하면 클라이언트가 VPN 구성 추가, 네트워크 확장 활성화 또는 서비스 모드용 보조 프로그램 설치를 요청할 수 있습니다.

macOS 15에서 확장 설정 확인

macOS 15 Sequoia에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’의 ‘네트워크 확장’에서 해당 클라이언트의 활성화가 허용되어 있는지 확인할 수 있습니다. VPN 구성은 ‘시스템 설정’ → ‘VPN’에서 확인하세요. 일부 버전에서는 ‘네트워크’ 관련 페이지에서도 확인할 수 있습니다. 아이콘만 보고 판단하지 말고 시스템에 표시된 구성 이름을 기준으로 하세요.

macOS 13·14의 시스템 확장 경고

macOS 13 또는 14에서 팝업이 ‘개인정보 보호 및 보안’에서 시스템 소프트웨어를 허용하라고 안내하면, 활성화를 시도한 직후 해당 페이지에서 경고를 확인하세요. 관련 항목이 없다면 클라이언트로 돌아가 활성화 작업이 제대로 실행되었는지 확인하고, 실제로 네트워크 확장 방식인지도 살펴보세요. 확장 항목이 없다고 해서 설치가 실패한 것은 아닙니다.

시스템 안내에 따라 인증한 뒤 클라이언트로 돌아와 다시 연결하세요. 시스템에서 재시동을 요구할 때만 재시동하면 됩니다. 시동 보안 수준 낮추기, SIP 끄기 또는 레거시 커널 확장 설치를 요구하는 가이드는 먼저 작업을 중단하고 검토하세요. 최신 네트워크 확장과 커널 확장은 서로 다른 방식입니다. 일반적인 프록시 설정을 위해 Mac 전체의 보안 정책을 변경해서는 안 됩니다.

키체인 팝업이 반복될 때: 요청 대상을 기준으로 확인하기

‘앱이 로그인 키체인을 사용하려고 합니다’와 ‘앱이 키체인에 저장된 항목에 접근하려고 합니다’는 확인 방법이 다릅니다. 전자는 키체인 잠금이나 암호 동기화 문제일 수 있고, 후자는 항목의 접근 제어와 관련된 경우가 많습니다. 팝업에 표시된 항목은 클라이언트가 저장한 자격 증명일 수도 있고 시스템 프록시 인증이나 다른 관련 프로그램에서 사용 중인 항목일 수도 있습니다. 무조건 ‘항상 허용’을 누르지 마세요.

프로그램명, 항목명 및 암호 종류부터 확인하기

1. 팝업에 표시된 요청 프로그램과 대상 항목의 이름을 기록하고, 방금 설정을 가져오거나 연결 또는 업데이트를 진행했는지 확인하세요.
2. 요청한 프로그램이 설치된 클라이언트 또는 알려진 보조 구성 요소인지 확인하세요. 경로나 이름이 이상하면 먼저 취소하세요.
3. ‘로그인’ 키체인의 잠금을 해제하라는 요청이면 해당 키체인의 암호를 입력하세요. 보통 현재 macOS 로그인 암호와 같지만 항상 그런 것은 아닙니다.
4. 한 번 허용한 뒤에도 팝업이 반복되는지 확인하고, 앱 복사본이 여러 개 실행 중이거나 오래된 백그라운드 프로세스가 남아 있는지 살펴보세요.

관리자 인증 암호, 구독 사이트 암호, 키체인 암호는 서로 대체할 수 없습니다. 특히 복구 절차로 Mac 로그인 암호를 재설정한 경우, 이전 ‘로그인’ 키체인은 기존 암호를 계속 사용할 수 있습니다. 새 로그인 암호를 반복해서 입력해도 기존 키체인이 자동으로 잠금 해제되지는 않습니다.

키체인 접근에서 확인하고 키체인 전체를 먼저 삭제하지 않기

Spotlight에서 ‘키체인 접근’을 검색해 ‘로그인’ 키체인을 선택한 뒤 팝업에 표시된 항목 이름을 검색하세요. macOS 15의 ‘암호’ 앱은 암호와 패스키 관리용이며, 키체인 접근의 모든 항목 및 접근 제어 기능을 대신하지는 않습니다.

• 업데이트 후 팝업이 나타남: 앱 서명 식별 정보나 접근 제어가 변경되었을 수 있습니다. 먼저 업데이트가 원래 프로젝트에서 제공된 것인지 확인한 뒤 다시 승인할지 판단하세요.
• 앱을 옮긴 뒤 팝업이 나타남: 이전 위치의 앱이 실행 중인지 확인하세요. 앱을 종료한 뒤 ‘응용 프로그램’ 폴더에 있는 버전만 실행하세요.
• 실행할 때마다 잠금 해제를 요청함: 로그인 키체인이 잠겨 있는지, 잠자기 또는 유휴 상태 이후 잠기도록 설정되어 있는지 확인하세요.
• 특정 항목만 반복해서 요청함: 먼저 해당 항목의 ‘접근 제어’를 확인하세요. 모든 앱의 접근을 허용하도록 바로 변경하지 마세요.

해당 항목을 클라이언트가 만들었고 자격 증명을 다시 받을 수 있다고 확인된 경우에만 그 항목을 삭제한 뒤 다시 로그인하거나 가져오는 방법을 고려하세요. 기본 키체인을 재설정하면 이 Mac에 저장된 다른 자격 증명에도 영향을 줍니다. 이전 암호를 모른다면 재설정을 설치 절차로 간주하지 말고, 먼저 Apple의 복구 안내를 확인해 영향을 파악하세요.

‘앱이 손상되어 열 수 없음’: 출처와 서명부터 확인하기

이 안내가 표시된다고 해서 반드시 다운로드 과정에서 파일이 손상된 것은 아닙니다. 서명 만료, 앱 콘텐츠 변경, 패키징 방식 또는 시스템 보안 평가와 관련된 문제일 수도 있습니다. 앱을 종료하고 확인된 배포 채널에서 같은 아키텍처의 설치 파일을 다시 다운로드하세요. 압축을 풀어 ‘응용 프로그램’ 폴더에 넣은 뒤 다시 실행합니다. 출처를 모르는 웹사이트의 ‘수정 버전’을 기존 설치 폴더에 덮어쓰지 마세요.

읽기 전용 명령으로 정보 확인하기

아래 명령은 앱 서명과 Gatekeeper 평가 결과를 확인하며 앱을 수정하지 않습니다. 명령 앞부분을 입력한 뒤 Finder에서 클라이언트 앱을 터미널로 드래그해 실제 경로를 입력하세요. 각 명령은 따로 실행해야 합니다. 이 설명까지 터미널에 함께 붙여 넣지 마세요.

codesign --verify --deep --strict --verbose=2

spctl --assess --type execute --verbose=4

xattr -l

각 명령 끝에 공백을 하나 입력한 뒤 확인할 .app을 터미널로 드래그하세요. codesign은 서명 무결성을 확인하고, spctl은 시스템 실행 정책의 평가 결과를 확인하며, xattr -l은 확장 속성을 나열합니다. 서명 검증이 통과해도 그것만으로 소프트웨어의 출처가 신뢰할 만하다고 단정할 수는 없습니다. 개발자와 배포 채널도 확인하세요.

격리 속성 제거를 만능 해결책으로 사용하지 않기

com.apple.quarantine은 다운로드한 파일에 흔히 붙는 격리 속성으로, 존재 자체가 오류는 아닙니다. 확장 속성을 재귀적으로 삭제하거나 Gatekeeper를 전역으로 끄면 시스템의 기본 검사 절차가 바뀌지만, 만료된 서명이나 누락된 파일, 호환되지 않는 실행 환경은 해결되지 않습니다.

원래 프로젝트에서 특정 버전의 배포 문제를 명시적으로 안내한 경우 해당 버전의 문서를 정확히 따르고, 작업 범위를 확인된 앱으로 제한하세요. 서명 리소스가 변경되었거나 파일이 누락되었다는 시스템 경고가 나오면 우선 다시 다운로드하거나 지원되는 버전을 사용하세요. 불분명한 수정 스크립트를 반복 실행하기보다 오류 전체 내용, macOS 버전 및 프로세서 아키텍처를 프로젝트 관리자에게 전달하는 편이 문제 해결에 도움이 됩니다.

승인 후 확인: 시스템 프록시와 TUN을 단계별로 테스트하기

권한 승인은 해당 작업이 허용되었다는 뜻일 뿐, 구독, 노드 및 DNS가 모두 정상이라는 의미는 아닙니다. 먼저 클라이언트에서 구성을 선택해 정상적으로 불러왔는지 확인한 다음 사용할 전략을 선택하세요. 아래에서는 7890을 예시 포트로 사용합니다. 실제 포트는 클라이언트의 HTTP 또는 mixed 리스닝 포트를 확인하세요. 클라이언트마다 기본 포트가 다를 수 있습니다.

1. 먼저 TUN을 끄고 시스템 프록시만 활성화하세요. macOS 13–15에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’로 이동해 활성화된 항목, 주소 및 포트를 확인하세요.
2. 로컬 프록시 주소는 보통 127.0.0.1입니다. 포트가 클라이언트 설정과 일치하는지, 종료된 이전 클라이언트를 가리키지는 않는지 확인하세요.
3. 아래 명시적 프록시 요청을 실행해 로컬 HTTP 프록시 연결을 확인하세요. 이 방법은 터미널이 시스템 프록시 설정을 읽는지 여부와 무관합니다.
4. 일반 프록시가 정상 작동하는 것을 확인한 뒤 필요한 경우 TUN을 켜세요. 클라이언트 로그와 시스템 VPN 상태를 살펴보고, 설정은 한 번에 하나씩만 변경하세요.

scutil --proxy
lsof -nP -iTCP:7890 -sTCP:LISTEN
curl -I --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/

scutil --proxy는 시스템 프록시 상태를 보여 줍니다. lsof는 예시 포트의 리스닝 프로세스를 찾고, curl에는 15초 시간 제한이 설정되어 있습니다. HTTP 응답이 오면 해당 요청에 서버가 응답했다는 뜻이지만, 모든 앱이나 TUN 경로가 정상이라는 의미는 아닙니다. 연결이 거부되면 리스닝 주소와 포트를 확인하세요. 시간 초과가 발생하면 로그를 함께 확인해 노드, 라우팅 및 DNS를 점검하세요.

시스템 프록시는 정상인데 TUN만 작동하지 않으면 확장 프로그램, 보조 서비스 및 다른 VPN과의 충돌부터 확인하세요. 둘 다 작동하지 않으면 구성과 노드를 먼저 살펴보세요. 모든 트래픽을 처리하는 VPN 또는 TUN 클라이언트를 두 개 동시에 켜지 마세요. 라우팅과 DNS 설정이 서로 덮어써져 ‘승인했는데도 인터넷이 안 됨’처럼 보일 수 있습니다.

자주 묻는 질문: 어떤 권한은 당장 허용하지 않아도 될까요?