결론부터 말하면 macOS 설정 순서는 '승인 먼저, 가져오기 다음, 확인 마지막'입니다. 순서를 바꿔도 당장 오류가 나지는 않지만 문제를 찾을 때 방향을 잘못 잡게 됩니다. 노드가 고장 났다고 생각했는데 사실은 시스템 확장이 아직 로드되지 않은 경우가 많습니다. 아래에서 이 순서대로 설명합니다.
시작하기 전: 시스템 버전과 계정 권한 확인
macOS 10.15 Catalina 이후 서드파티 네트워크 클라이언트는 커널 확장에서 시스템 확장(System Extension) 프레임워크로 옮겨 갔고, 승인 창구도 시스템이 통합 관리합니다. macOS 13부터는 설정 앱 이름이 '시스템 설정'으로 바뀌었고 그 이전 버전은 '시스템 환경설정'이라 메뉴 이름은 다르지만 논리는 같습니다. 먼저 확장 로드를 허용해야 클라이언트가 네트워크 트래픽을 가져갈 수 있습니다.
계정 측면에서 클라이언트 설치, 시스템 확장 승인, VPN 설정 기록에는 모두 관리자 권한이 필요합니다. 이 Mac을 가족이 함께 쓰고 평소 표준 사용자로 로그인한다면 관리자 사용자 이름과 비밀번호를 알고 있어야 합니다. 그렇지 않으면 승인 팝업이 떠도 아무것도 할 수 없습니다.
클라이언트 출처도 미리 정해 두는 게 좋습니다. App Store 버전은 샌드박스와 심사 제약을 받아 시스템이 제공하는 네트워크 인터페이스만 쓸 수 있어 기능이 제한적이고, 공식 사이트에서 직접 내려받은 버전은 시스템 확장을 설치해 TUN 모드로 전체 트래픽을 처리할 수 있습니다. 두 출처의 클라이언트를 동시에 설치하면 같은 VPN 설정을 두고 서로 충돌해 '설치는 되는데 연결이 안 되는' 증상이 나타납니다.
- ✅ 시스템 버전이 macOS 10.15 이상이고, 메뉴 경로는 자신의 시스템에 맞게 확인합니다.
- ✅ 현재 계정이 관리자이거나 관리자 비밀번호를 알고 있습니다.
- ✅ 사용 가능한 구독 링크가 있습니다. 보통 https로 시작합니다.
- ❌ 두 출처의 클라이언트를 동시에 설치하지 말고, 기존 클라이언트를 완전히 삭제하지 않은 상태에서 새로 설치하지도 마세요.
클라이언트 설치: 시스템 확장부터 통과하기
설치 패키지를 '응용 프로그램' 폴더로 옮긴 뒤 처음 실행하면 Gatekeeper가 막을 수 있습니다. '시스템 설정 → 개인정보 보호 및 보안'에서 해당 항목 옆의 '그래도 열기'를 누르면 되고, 시스템 보안 기능을 끌 필요는 없습니다.
이제 이 글에서 가장 중요한 부분인 승인 순서입니다. 아래 다섯 단계를 그대로 따르면 '연결이 안 돼서 노드가 고장 난 줄 알았던' 시행착오를 한 번 줄일 수 있습니다.
- 클라이언트를 실행합니다. 처음 연결을 시도하면 macOS가 'VPN 구성을 추가하려고 합니다'라는 시스템 대화상자를 띄웁니다. 로그인 암호를 입력하거나 Touch ID로 확인하면 됩니다. 이 팝업은 클라이언트가 아니라 시스템이 띄우는 것으로, 이 앱이 네트워크 트래픽을 가져가도록 승인하는 절차입니다.
- 클라이언트가 시스템 확장을 사용한다면(TUN 모드를 지원하는 클라이언트는 대부분 그렇습니다) 설치 또는 첫 실행 시 '개발자의 시스템 소프트웨어 로드를 차단했습니다'라는 안내가 뜹니다. '시스템 설정 → 개인정보 보호 및 보안'을 열고 페이지 아래에서 이 항목을 찾아 '허용'을 누른 뒤 암호를 한 번 더 입력합니다.
- macOS 15 이상에서는 이 안내가 '개인정보 보호 및 보안 → 시스템 확장' 영역으로 옮겨졌습니다. 경로는 바뀌었지만 버튼 이름은 여전히 '허용'입니다.
- 승인이 끝나면 시스템이 클라이언트 재시작을 요구하며, 일부 버전은 Mac 재부팅을 요구합니다. 안내를 그대로 따르세요. 확장이 로드되지 않으면 이후 설정은 모두 헛수고입니다.
- 클라이언트로 돌아와 상태를 확인합니다. 확장이 정상 로드되면 연결 버튼이 활성화되고 상태 표시줄에 '연결됨'이 나타납니다. 로드되지 않았다면 버튼이 회색으로 보이거나 눌러도 아무 반응이 없습니다.
승인 팝업은 한 번만 뜹니다
시스템 확장 승인을 거부해도 시스템이 계속 팝업으로 알려 주지는 않습니다. '개인정보 보호 및 보안'에 처리 대기 기록이 하나 남을 뿐입니다. 이 기록을 찾을 수 없다면 클라이언트가 실제로 요청을 보냈는지 먼저 확인하고, 현재 로그인한 계정이 설치 당시의 관리자 계정인지도 점검하세요.
구독 가져오기: 링크, QR 코드, 수동 입력
구독 링크는 클라이언트와 회선을 잇는 유일한 자격 증명으로, 노드 목록과 프로토콜 파라미터, 업데이트 주소가 들어 있습니다. 가져오는 방법은 세 가지이며 편한 순서대로 정리하면 다음과 같습니다.
- 링크 붙여넣기: 클라이언트에서 '구독 추가' 또는 '클립보드에서 가져오기'를 누르고 https로 시작하는 링크 전체를 붙여넣습니다. 이름은 아무렇게나 정해도 되고, 확인을 누르면 클라이언트가 노드 목록을 자동으로 가져옵니다.
- QR 코드 스캔: 구독 페이지에는 보통 QR 코드도 함께 제공됩니다. Mac에서는 클라이언트에 내장된 스캔 기능을 쓰거나, 스마트폰으로 스캔해 링크를 Mac으로 옮기면 됩니다.
- 수동 입력: 서버 주소, 포트, 프로토콜 종류, 비밀번호 또는 UUID를 하나씩 입력합니다. 구독 링크가 없을 때만 사용하세요. 수동 입력은 프로토콜 파라미터를 빠뜨리기 쉬워 연결은 되지만 웹 페이지가 열리지 않는 경우가 생깁니다.
가져오기에 성공하면 클라이언트 왼쪽에 구독 그룹이 생기고, 펼치면 구체적인 노드 이름과 지역을 볼 수 있습니다. 그룹이 비어 있거나 '업데이트 실패'가 뜨면 링크가 줄바꿈으로 잘리지 않았는지 먼저 확인하세요. 채팅 창에서 링크를 복사하면 끝에 공백이 붙거나 몇 글자가 빠지는 일이 흔합니다.
프로토콜은 주요 클라이언트가 Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC를 모두 지원합니다. 이 중 Hysteria2와 TUIC는 QUIC 기반이라 패킷 손실이 큰 회선에서 더 안정적이지만 클라이언트 버전을 요구합니다. 클라이언트 버전이 오래됐다면 이 두 프로토콜이 아예 표시되지 않을 수 있습니다. 링크가 깨진 게 아니라 클라이언트를 업데이트하면 됩니다.
| 가져오기 방식 | 적합한 상황 | 자주 발생하는 문제 | 점검 방향 |
|---|---|---|---|
| 구독 링크 붙여넣기 | 일상 사용, 한 번 가져오면 계속 업데이트 | 형식 오류 또는 빈 목록 | 링크가 온전한지, 불필요한 공백이 없는지 확인 |
| QR 코드 스캔 | 스마트폰 설정을 그대로 옮길 때 | 스캔해도 반응 없음 | QR 코드 출처가 신뢰할 만한지, 화면 밝기가 충분한지 확인 |
| 파라미터 수동 입력 | 구독 링크 없이 단일 노드만 임시로 쓸 때 | 연결은 되는데 웹 페이지가 안 열림 | 프로토콜 종류와 암호화 파라미터가 맞는지 대조 |
| 설정 파일 가져오기 | 대량 이전, 여러 기기 통일 | 설정 파일이 거부됨 | 파일 형식이 클라이언트가 요구하는 버전과 맞는지 확인 |
연결과 검증: 트래픽이 정말 적용됐는지 확인할 세 가지
연결 버튼을 누르고 상태가 '연결됨'으로 바뀌었다고 해서 트래픽이 이미 회선을 타는 것은 아닙니다. macOS에서는 최소 세 가지를 확인해야 합니다. 외부 IP가 바뀌었는지, DNS 조회가 넘어갔는지, IPv6가 새는지입니다.
- 외부 IP 확인: 브라우저를 열어 IP를 보여 주는 아무 페이지나 접속해 연결 전후 결과를 비교합니다. IP가 그대로라면 트래픽이 프록시를 타지 않은 것이며, 보통 분할 규칙이 해당 사이트를 직접 연결로 분류했거나 클라이언트가 '규칙 모드'로 동작 중인데 그 규칙에 걸리지 않은 경우입니다.
- DNS 확인: '터미널'에서
scutil --dns를 실행해 현재 사용하는 DNS 서버를 봅니다. 프록시를 타면 DNS 서버가 보통 로컬 루프백 주소나 회선 측 주소를 가리킵니다. 통신사 DNS가 그대로 보인다면 DNS가 넘어가지 않은 것이고 유출 위험이 있습니다. - IPv6 확인: 아무 IPv6 검사 페이지나 접속합니다. IPv6 주소가 여전히 노출되고 프록시 IP와 다르다면 클라이언트가 IPv4 트래픽만 처리한 것이므로, 설정에서 'IPv6 차단'을 켜거나 듀얼 스택을 지원하는 회선을 선택해야 합니다.
# 현재 DNS 서버 확인
scutil --dns | grep nameserver
# 기본 라우트와 네트워크 인터페이스 확인
netstat -rn | head -n 10
# 현재 외부 IP 확인 (인터넷 연결 필요)
curl -s https://api.ipify.org세 가지를 모두 통과한 뒤에 일상적으로 사용하세요. 이 단계에 2분을 들이면 이후 '될 때도 있고 안 될 때도 있는' 혼란을 크게 줄일 수 있습니다.
분할 규칙과 회선 유형: 이름이 아니라 용도로 고르기
분할 규칙은 어떤 트래픽이 프록시를 타고 어떤 트래픽이 직접 연결되는지를 정합니다. 대표적인 모드는 세 가지입니다. 전역 모드는 모든 트래픽을 회선으로 보내고, 규칙 모드는 내장 규칙표에 따라 국내 사이트는 직접 연결, 해외 사이트는 프록시로 보냅니다. 직접 연결 모드는 프록시를 전혀 쓰지 않습니다. 초보자라면 규칙 모드로 시작하고, 프록시를 타야 할 사이트가 직접 연결될 때 해당 도메인만 따로 규칙을 추가하는 편이 좋습니다.
회선 유형에서 IEPL 전용선은 종단 간 독립 채널로 공용 인터넷을 거치지 않아 지연이 안정적이고 패킷 손실이 적어 화상 회의와 실시간 협업에 적합합니다. 중계 회선은 국내 진입점을 거쳐 해외 출구로 나가는 방식이라 비용이 낮고, 저녁 피크 성능은 진입 대역폭에 좌우됩니다. 직결 회선은 해외 서버에 바로 연결되어 설정이 가장 단순하고 지연에 민감하지 않은 용도에 맞습니다. 셋 중 절대적으로 좋은 것은 없으니 실제로 하는 작업에 맞춰 고르세요.
자주 나오는 권한 오류와 해결 방법
아래 오류들은 macOS에서 가장 자주 나타나는 유형이며 대부분 직접 해결할 수 있습니다.
'시스템 소프트웨어 로드가 차단됨' 안내가 뜰 때
'시스템 설정 → 개인정보 보호 및 보안'으로 가서 아래쪽에서 차단된 항목을 찾아 '허용'을 누르고 암호를 입력합니다. 버튼이 회색이라면 왼쪽 아래 자물쇠 아이콘을 먼저 풀어야 합니다. macOS 15 이후에는 이 기록이 '시스템 확장' 하위 영역에 나타날 수 있는데, 경로만 다를 뿐 조작은 같습니다.
팝업이 반복해서 뜨고 승인 후에도 계속 안내될 때
대부분 구버전 클라이언트의 잔여 파일 때문입니다. 클라이언트를 휴지통으로 옮긴 뒤 '라이브러리 → Application Support' 아래에 같은 이름의 폴더가 남아 있는지 확인하고, 지운 다음 다시 설치하세요. 두 출처의 클라이언트가 동시에 있으면 시스템이 같은 설정에 대해 계속 물어봅니다.
연결은 되는데 웹 페이지가 열리지 않을 때
순서대로 점검하세요. 먼저 DNS가 넘어갔는지 보고, 다음으로 분할 규칙이 해당 도메인을 직접 연결로 분류했는지 확인하고, 마지막으로 클라이언트의 'LAN 직접 연결'이 켜져 있고 대상이 그 대역에 속하는지 봅니다. 세 원인의 증상은 같지만 대처 방법은 전혀 다릅니다.
구독 업데이트 실패
먼저 네트워크 자체가 정상인지 확인하세요. 구독 주소는 보통 해외에 있어 업데이트가 프록시를 타지 않으면 그대로 시간 초과가 날 수 있습니다. 일부 클라이언트는 '업데이트 시 프록시 사용' 스위치를 제공하니 켜면 됩니다. 링크가 만료된 경우일 수도 있으니 새로 발급받으면 됩니다.
'일단 방화벽을 끄자'는 방법은 쓰지 마세요
macOS 기본 방화벽은 정상적인 VPN 연결을 차단하지 않습니다. 연결이 안 될 때 방화벽을 끄는 것은 확장 미승인 문제를 해결하지도 못하고 본체 보안 수준만 낮춥니다. 올바른 점검 순서는 항상 확장 승인 → 구독 가져오기 → DNS와 라우팅 → 분할 규칙입니다.
일상 관리: 업데이트, 백업, 여러 기기
macOS 메이저 버전을 업데이트할 때마다 시스템 확장 승인 상태가 초기화될 수 있습니다. 이때는 클라이언트가 열리긴 하는데 연결이 안 되는 증상이 나타납니다. 시스템 업데이트 후에는 먼저 클라이언트를 열어 상태를 확인하고, 필요하면 승인을 다시 하세요.
구독 링크는 클라이언트 안에만 보관하고 단체 채팅방에 스크린샷으로 올리지 않는 것이 좋습니다. 링크 유출이 의심되면 새로 발급하면 되고, 이전 링크는 즉시 무효가 됩니다. 여러 기기에서 쓸 때는 같은 구독을 Mac, 스마트폰, 태블릿에 각각 가져오면 되며 기기 대수 제한은 없습니다.
개인정보와 관련해 본 서비스의 정책은 로그를 남기지 않는 것입니다. 열람 내용도, 접속 기록도 저장하지 않습니다. 이는 정책 선언이며 절대적인 보장은 아니므로 계정과 링크 관리 책임은 이용자 본인에게 있습니다.