macOS용 Clash 클라이언트는 앱 실행 확인, 프록시 설정, 권한이 필요한 보조 프로그램, 키체인 접근이 함께 필요할 수 있습니다. 각 권한은 용도가 다르므로 비밀번호를 반복해서 입력한다고 해결되지 않습니다. 먼저 어떤 앱이 어떤 작업을 하려는지, 요청이 언제 표시되는지 확인한 뒤 해당 권한을 처리하면 설치 문제를 구독이나 노드 오류로 오인하는 일을 줄일 수 있습니다.
1. 설치 전 아키텍처, macOS 버전, 앱 위치 확인
Apple Silicon과 Intel 설치 파일은 파일 이름만으로 고르면 안 됩니다
Apple 메뉴 → ‘이 Mac에 관하여’를 열어 ‘칩’ 또는 ‘프로세서’ 항목을 확인하세요. Apple M 시리즈는 Apple Silicon, ARM64 또는 aarch64 빌드를 우선 선택하고, Intel Mac은 x64 또는 x86_64 빌드를 선택합니다. Universal 빌드는 보통 두 아키텍처를 모두 지원하지만, 클라이언트에 명시된 최소 macOS 버전도 충족해야 합니다.
- ‘Mac 시스템’처럼 두루뭉술하게 적지 말고 macOS 14.7처럼 전체 버전을 기록하세요.
- 다운로드 출처와 프로젝트 이름, 설치 파일의 아키텍처를 확인하세요. 출처를 알 수 없는 재패키징 파일은 설치하지 마세요.
- DMG를 연 뒤 앱을 ‘응용 프로그램’으로 옮기고, 디스크 이미지를 추출한 다음 ‘응용 프로그램’에서 실행하세요.
- 처음 실행하기 전에 이전 클라이언트를 종료하세요. 여러 프로그램이 동시에 시스템 프록시를 변경하거나 같은 포트를 사용하려는 상황을 피할 수 있습니다.
DMG나 ‘다운로드’ 폴더에서 앱을 계속 실행하지 마세요. 앱을 한 위치에 설치하면 업데이트 프로그램, 보조 프로그램, 권한 기록이 일관되게 유지됩니다. 여러 위치에 있는 복사본을 실행하면 키체인 접근 권한이 실제 실행 중인 앱과 맞지 않을 수 있습니다. Apple Silicon Mac에서 Intel 빌드를 실행하면 Rosetta 설치 안내가 표시될 수도 있는데, 이는 프록시 권한과는 별개의 문제입니다.
2. Gatekeeper 경고: 계속 진행해도 되는지 먼저 확인
Gatekeeper는 앱을 실행할 때 검사합니다. 이 단계에서는 코어가 아직 실행되지 않았을 수 있으므로 구독, DNS, 규칙을 바꿔도 대개 해결되지 않습니다. macOS 버전에 따라 경고 문구가 조금씩 다르니 경고 유형에 맞게 조치하세요.
| 경고 또는 증상 | 확인할 사항 | 다음 단계 |
|---|---|---|
| 개발자를 확인할 수 없거나 악성 소프트웨어가 포함되었는지 확인할 수 없음 | 출처, 서명, 시스템의 신뢰 여부 | 출처를 확인한 다음 ‘개인정보 보호 및 보안’에서 한 번만 허용하는 옵션이 있는지 확인 |
| 앱이 손상되어 열 수 없음 | 다운로드가 완전한지, 앱이 변경되었는지, 빌드가 호환되는지 | 해당 앱 복사본을 삭제하고 신뢰할 수 있는 배포 경로에서 다시 다운로드 |
| 앱이 컴퓨터를 손상시키거나 악성 소프트웨어로 감지될 수 있음 | 시스템 보안 차단 | 실행을 중단하고 배포처 안내를 확인하세요. 차단을 강제로 우회하지 마세요. |
| 이 버전은 이 Mac에서 사용할 수 없음 | 프로세서 아키텍처와 최소 시스템 버전 | 지원되는 설치 파일을 다시 선택 |
신뢰할 수 있는 앱을 한 번만 허용하는 방법
- ‘응용 프로그램’에서 앱을 한 번 실행해 보고 시스템 안내를 읽으세요.
- Apple 메뉴 → ‘시스템 설정’ → ‘개인정보 보호 및 보안’으로 이동하세요.
- ‘보안’ 영역에서 방금 차단된 앱을 찾으세요. 해당 옵션이 표시되고 출처를 신뢰할 수 있는 경우에만 ‘그래도 열기’를 선택하세요.
- 시스템에서 요구하는 인증을 완료한 다음 앱 이름을 다시 확인하고 여세요.
macOS 13, 14, 15에서는 옵션 위치나 버튼 표시 조건이 다를 수 있습니다. 관리되는 기기에서는 사용자가 직접 허용하지 못할 수도 있습니다. 버튼이 보이지 않으면 서명, 시스템 호환성, 기기 관리 정책을 확인하세요. 앱 실행을 계속 반복하지 마세요.
3. 시스템 프록시, TUN, 네트워크 확장 권한 이해하기
시스템 프록시: 시스템 설정을 따르는 앱을 로컬 포트에 연결
시스템 프록시는 보통 HTTP, HTTPS 또는 SOCKS 요청을 클라이언트의 로컬 수신 주소로 보냅니다. 모든 프로세스의 트래픽을 자동으로 처리하는 것은 아니며 TUN 인터페이스를 만든다는 뜻도 아닙니다. 클라이언트에 따라 프록시 설정을 직접 변경하기도 하고, 보조 프로그램 설치나 네트워크 구성 변경 시 관리자 인증을 요청하기도 합니다.
macOS 13 이상에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 사용하는 Wi-Fi 또는 이더넷 서비스 → ‘세부사항’ → ‘프록시’에서 설정을 확인할 수 있습니다. 시스템 설정에서 ‘프록시’를 검색하면 해당 메뉴를 더 빠르게 찾을 수 있습니다.
- 로컬 주소는 보통
127.0.0.1이지만 포트는 현재 클라이언트 설정을 기준으로 확인하세요. - 설정이
mixed-port: 7890이면 해당 포트에서 HTTP와 SOCKS 연결을 모두 받을 수 있습니다. 이는 예시일 뿐 모든 클라이언트가 7890을 사용하는 것은 아닙니다. - 프록시를 설정했는데 코어가 해당 포트에서 수신 대기하지 않으면 브라우저에서 바로 연결 오류가 발생할 수 있습니다.
TUN: 클라이언트가 어떤 방식으로 구현하는지 확인
TUN 모드는 트래픽을 가상 네트워크 인터페이스로 전달한 뒤 코어가 처리하게 합니다. 인터페이스 생성, 라우팅, DNS 설정에는 더 높은 권한이 필요할 수 있습니다. 흔히 권한이 필요한 보조 프로그램이 코어를 실행하는 방식과 클라이언트에 통합된 Network Extension 방식이 사용됩니다. 설치 및 승인 절차는 서로 다르므로 혼용하지 마세요.
| 권한 대상 | 주요 요청 시점 | 확인 위치 |
|---|---|---|
| 권한이 필요한 보조 프로그램 | 서비스를 처음 설치하거나 TUN을 켜거나 서비스를 복구할 때 | 클라이언트 서비스 상태 및 시스템의 백그라운드 항목 설정 |
| 네트워크 확장 | 클라이언트가 제공하는 네트워크 확장 기능을 처음 켤 때 | 시스템 안내에 지정된 확장 관리 위치 |
| VPN 구성 | 시스템 VPN 인터페이스를 사용하는 연결 구성 추가 | ‘시스템 설정’의 VPN 또는 ‘네트워크’ 관련 화면 |
macOS 15에서는 ‘시스템 설정’ → ‘일반’ → ‘로그인 항목 및 확장 프로그램’에서 ‘네트워크 확장’을 확인할 수 있습니다. 어떤 항목이 표시되는지는 클라이언트가 실제로 설치한 구성요소에 따라 다릅니다. 이전 macOS에서는 ‘개인정보 보호 및 보안’에서 차단된 시스템 소프트웨어를 허용해야 할 수 있습니다. 현재 시스템에 표시된 안내를 우선 따르고 개발자 이름을 확인하세요.
클라이언트가 권한이 필요한 보조 프로그램만 설치했다면 네트워크 확장 스위치가 보이지 않는 것이 정상일 수 있습니다. 일반적인 TUN을 켜기 위해 복구 모드에서 시동 보안을 낮춰야 하는 것도 아닙니다. 클라이언트가 특정 확장을 명시적으로 요구할 때만 관련 문서를 확인하세요. 구형 커널 확장 안내를 모든 mihomo 클라이언트에 적용하지 마세요.
4. 키체인 알림: 접근 암호와 관리자 암호의 차이
키체인은 암호와 토큰 같은 민감한 정보를 저장합니다. 클라이언트가 구독 인증 정보나 계정 정보를 키체인에 저장할 수 있지만, 모든 클라이언트가 그렇게 하는 것은 아닙니다. 알림이 표시되면 암호 입력란부터 보지 말고 접근을 요청한 앱 이름과 키체인 항목 이름을 확인하세요.
먼저 알림 유형 구분하기
- ‘변경하려고 합니다’라며 관리자 인증을 요청: 보조 프로그램 설치나 시스템 설정 변경과 관련된 요청인 경우가 많으며, 키체인 읽기 요청과는 다릅니다.
- ‘키체인에 저장된 기밀 정보’를 사용하려고 함: 특정 항목에 대한 접근 요청이므로 해당 항목의 용도를 확인하세요.
- ‘로그인’ 키체인 잠금 해제 요청: 보통 해당 키체인 자체의 암호가 필요하며, 현재 계정 로그인 암호와 다를 수 있습니다.
계정 복구 등으로 macOS 로그인 암호를 재설정했다면 기존 ‘로그인’ 키체인에는 이전 암호가 그대로 설정되어 있을 수 있습니다. 이 경우 새 암호를 반복 입력해도 잠금이 풀리지 않을 수 있습니다. 구독 서비스 계정 암호를 시스템 키체인의 잠금 해제 창에 입력하지 마세요. 서로 다른 인증 정보입니다.
‘한 번 허용’과 ‘항상 허용’ 선택하기
처음 확인할 때는 한 번만 허용하고 클라이언트가 해당 설정을 다시 읽을 수 있는지 살펴보세요. 앱 출처와 항목 용도, 요청 시점이 모두 맞는지 확인한 뒤에만 지속적으로 허용하는 것을 고려하세요. 업데이트 후 알림이 나타났다면 앱 서명이나 접근 제어 대상이 바뀌었을 수 있습니다. ‘방금 업데이트했다’는 이유만으로 요청을 신뢰해서는 안 됩니다.
- Command + 스페이스를 누르고 ‘키체인 접근’을 검색해 여세요. 최신 macOS의 ‘암호’ 앱은 같은 도구가 아닙니다.
- ‘로그인’ 키체인을 선택한 뒤 클라이언트 이름이나 알림에 표시된 서비스 이름으로 검색하세요.
- 관련 항목을 이중 클릭해 확인하세요. 항목에 ‘접근 제어’ 옵션이 있다면 접근을 허용한 앱이 현재 설치된 복사본을 가리키는지 확인하세요.
- 편의를 위해 항목을 모든 앱에 허용하도록 바꾸지 마세요. 해당 클라이언트의 항목임을 확인할 수 있는 경우에만 처리하세요.
5. 권한 오류를 필요한 부분만 초기화하고 네트워크 복구하기
보조 프로그램이 반복해서 설치된다면 앱 복사본이 여러 개 있는지 확인
같은 종류의 클라이언트를 모두 종료하고 ‘응용 프로그램’에 사용할 복사본만 남긴 뒤 다시 실행하세요. 클라이언트에 ‘서비스 제거’, ‘서비스 설치’, ‘서비스 복구’ 기능이 있다면 해당 클라이언트의 관리 메뉴를 이용하세요. 제품마다 메뉴 이름이 다르므로 다른 클라이언트의 버튼 경로를 그대로 따라 하지 마세요.
서비스 관리가 끝나면 먼저 시작 로그를 한 번 확인하고 필요한 경우 시스템을 재시동하세요. /Library/PrivilegedHelperTools 또는 /Library/LaunchDaemons 안의 파일을 직접 일괄 삭제하지 마세요. 이 폴더에는 다른 소프트웨어의 서비스도 들어 있습니다. 회사에서 관리하는 Mac이 정책으로 제한되어 있다면 관리자에게 허용 범위를 확인하세요.
클라이언트를 종료한 뒤 인터넷이 안 된다면 남아 있는 시스템 프록시 확인
앱이 비정상 종료되면 시스템 프록시가 이미 수신 대기를 중단한 로컬 포트를 계속 가리킬 수 있습니다. 먼저 시스템 설정에서 현재 네트워크 서비스에 해당 클라이언트가 설정한 프록시를 끈 다음 직접 연결을 테스트하세요. 아래 터미널 명령은 확인용입니다. 첫 번째 명령은 네트워크 서비스 이름을 표시하며, 뒤의 두 명령은 이름이 Wi-Fi인 서비스를 예로 듭니다.
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"실제 서비스 이름이 다르면 첫 번째 명령의 출력에 나온 전체 이름을 사용하세요. 결과에서 Enabled, Server, Port를 중점적으로 확인하세요. 로컬 주소가 남아 있다고 해서 프록시가 작동 중인 것은 아니므로 활성화 상태도 확인해야 합니다.
해당 프록시가 종료한 클라이언트에서 설정한 것이며 회사 네트워크 구성에 속하지 않는다고 확인한 경우에만 아래 명령으로 끄세요. 관리자 인증이 필요할 수 있습니다. 자동 프록시 구성과 자동 프록시 검색은 별도 옵션이므로 이 세 명령으로 처리되지 않습니다.
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxystate "Wi-Fi" off키체인에서 계속 거부된다면 확인된 인증 정보 항목만 다시 만들기
먼저 클라이언트를 종료하고 설정을 백업한 뒤 구독 주소와 계정 인증 정보를 다시 확보할 수 있는지 확인하세요. ‘키체인 접근’에서 클라이언트 항목으로 확인된 항목을 찾습니다. 필요한 경우 해당 항목만 삭제한 다음 클라이언트를 실행해 다시 가져오거나 로그인하세요. 키체인 항목을 삭제해도 설정 파일이 자동으로 복구되거나 분실한 구독 주소가 되살아나지는 않습니다.
‘전체 디스크 접근 권한 허용’을 일반적인 해결책으로 사용하지 마세요. 네트워크 문제만으로 정상적인 프록시 전달에 파일 접근 권한을 확대할 필요는 없습니다. 특정 기능에 꼭 필요하고 클라이언트 문서에 용도가 설명되어 있을 때만 허용 여부를 검토하세요.
6. 설치 후 확인 순서와 문제 기록
- 실행 확인: ‘응용 프로그램’에서 클라이언트를 실행하고 코어가 정상적으로 실행되는지, 로그에 반복적인 충돌이나 포트 사용 오류가 없는지 확인하세요.
- 설정 확인: 신뢰할 수 있는 설정을 가져와 정책 그룹과 아웃바운드 항목이 있는지 확인하세요. 창이 열린다고 구독이 성공적으로 불러와진 것은 아닙니다.
- 시스템 프록시 확인: TUN을 끄고 시스템 프록시를 켠 다음 확인할 웹페이지를 열어 연결 기록에서 대상 도메인, 적용된 규칙, 실제 아웃바운드를 확인하세요.
- TUN 확인: 필요한 경우에만 켜고 인터페이스 생성, 라우팅, DNS 관련 로그를 확인하세요. 실패하면 먼저 TUN을 끄고 시스템 프록시 경로가 계속 작동하는지 확인하세요.
- 종료 후 복구 확인: 클라이언트를 정상 종료한 뒤 시스템 프록시 설정이 원래대로 돌아왔는지 확인하세요. 복구되지 않았다면 이전 절차에 따라 현재 네트워크 서비스를 확인하세요.
웹페이지가 열리지 않고 로그에도 해당 연결이 전혀 없다면 먼저 트래픽이 어떤 경로로 전달되는지 확인하세요. 연결과 적용 규칙, 아웃바운드 기록은 있지만 시간 초과가 발생하면 노드, DNS, 대상 서비스 문제를 살펴보세요. 네트워크 확장이 허용됐다는 것은 시스템에서 해당 구성요소를 로드할 수 있다는 뜻일 뿐, 구독이 유효하거나 대상 사이트에 반드시 연결된다는 뜻은 아닙니다.
문의할 때 다음 정보를 함께 제공하세요
- macOS 전체 버전과 Apple Silicon 또는 Intel 아키텍처
- 클라이언트 버전과 코어 버전을 각각 기록하고 혼용하지 마세요.
- 알림의 전체 문구, 알림을 유발한 작업, 당시 시스템 프록시와 TUN 중 무엇을 사용했는지
- 문제 발생 전후 약 30초간의 로그와 VPN, 프록시, 네트워크 필터링 소프트웨어를 함께 실행했는지 여부
스크린샷과 로그를 공유하기 전에 구독 URL, 토큰, 계정 정보, 노드 인증 정보를 가리세요. ‘실행 확인 → 시스템 프록시 → TUN 또는 확장 → 키체인’ 순서로 각각 점검하면 모든 구성요소를 다시 설치하는 것보다 원인을 파악하기 쉽고 기존 네트워크 설정에 미치는 영향도 줄일 수 있습니다.