macOS VPN 추천에서 어려운 지점은 어떤 클라이언트를 설치하느냐가 아니라, 설치한 뒤 시스템이 권한을 주느냐입니다. M 시리즈 칩 Mac에서 클라이언트는 시스템 확장과 네트워크 확장으로 utun 인터페이스를 점유하거나, 로컬 루프백 주소만 수신하는 애플리케이션 계층 프록시로 물러납니다. 전자는 모든 앱을 커버하고, 후자는 프록시 사용을 받아들이는 앱만 담당합니다. 이 글은 칩 아키텍처와 OS 버전에 따라 두 경로를 나눠 승인 절차와 프로토콜 선택, 그리고 연결은 되는데 통신이 안 될 때의 점검 목록을 제시합니다.
macOS 클라이언트의 세 가지 형태
macOS에서 해외 접속을 구성할 때 시스템 차원의 경로는 세 가지뿐이며, 차이는 누가 트래픽 방향을 결정하느냐에 있습니다.
| 형태 | 필요한 시스템 권한 | 커버 범위 | M 시리즈 Mac에서의 현황 |
|---|---|---|---|
| 네트워크 확장 + 시스템 확장 | 시스템 확장 허용, VPN 구성 승인 | 모든 앱의 TCP / UDP 트래픽 | 주류 방식, 네이티브 arm64 |
| 애플리케이션 계층 프록시 | 없음 | 프록시를 직접 설정한 앱만 | 범용, 앱 지원 여부에 따라 제한 |
| 커널 확장 kext | 시동 보안 수준을 낮춰야 함 | 모든 트래픽 | 퇴출된 방식, 최신 OS에서는 비권장 |
네트워크 확장은 NetworkExtension 프레임워크의 NEPacketTunnelProvider로, 시스템에 utun 가상 네트워크 인터페이스를 만들고 클라이언트가 트래픽을 터널로 끌어들입니다. 이 경로에는 두 단계 승인이 필요합니다. 먼저 시스템이 개발자의 시스템 확장을 받아들이게 하고, 다음으로 클라이언트가 VPN 구성을 추가하도록 허용해야 합니다. 승인은 한 번 하면 장기간 유효하지만, 시스템 메이저 버전을 업그레이드할 때 다시 확인해야 할 수 있습니다.
애플리케이션 계층 프록시는 로컬 루프백 주소에 포트 하나를 여는 방식으로, 흔히 127.0.0.1의 SOCKS5 또는 HTTP 프록시 형태입니다. 프록시를 지원하는 앱이 알아서 연결합니다. 시스템 권한이 전혀 필요 없고 관리 대상 컴퓨터에 설치해도 승인 창이 뜨지 않습니다. 대신 명령줄 도구와 시스템 프록시 설정을 읽지 않는 일부 앱은 따로 설정해야 하고, 백그라운드 업데이트 같은 트래픽은 프록시를 타지 않습니다.
커널 확장은 macOS 10.15 이후 단계적으로 퇴출된 구방식입니다. Apple 칩 기기는 기본적으로 서드파티 kext 로드를 허용하지 않으며, 쓰려면 복구 모드로 부팅해 시동 보안을 낮춰야 합니다. 지금은 정상적인 클라이언트가 이 경로를 쓰지 않으므로, 시스템 무결성 보호를 끄라고 요구하는 설치 패키지는 그냥 건너뛰면 됩니다.
Apple 칩 호환성: 실측에서 확인된 네 가지 걸림돌
M 시리즈 칩은 '설치할 수 있느냐'와 '설치한 뒤 쓸 수 있느냐'를 두 개의 문제로 나눠 놓았습니다. 아래 네 가지 걸림돌이 실측에서 가장 자주 나타났습니다.
- 아키텍처: 네이티브 arm64와 Rosetta 변환.활성 상태 보기의 '종류' 열을 보면 바로 알 수 있습니다. Intel로 표시되면 클라이언트가 Rosetta 2 변환 계층에서 도는 것입니다. 변환 버전도 연결은 되지만, 변환 계층 아래에서는 네트워크 확장 핸드셰이크가 느리거나 상주 메모리가 높아지는 일이 간간이 생깁니다. 네이티브 arm64 설치 패키지를 우선 선택해 불확실성을 한 겹 줄이세요.
- 서명과 공증.서명이나 공증이 없는 패키지는 첫 실행 때 차단되며 개발자를 확인할 수 없다는 안내가 뜹니다. '시스템 설정 → 개인정보 보호 및 보안' 하단에서 '그래도 열기'를 누르면 되지만, 시스템 메이저 업데이트 후에 다시 차단될 수 있습니다. 정상 배포되는 설치 패키지는 공증을 거치므로 이 안내가 반복해서 나오지 않아야 합니다.
- 시스템 확장 승인을 한 단계 빠뜨린 경우.클라이언트는 연결됨으로 표시되는데 utun 인터페이스가 만들어지지 않았다면 시스템 확장 스위치가 꺼져 있을 가능성이 큽니다. 위치는 '시스템 설정 → 일반 → 로그인 항목 및 확장 프로그램 → 네트워크 확장 프로그램'이고, 구버전은 '개인정보 보호 및 보안 → 확장 프로그램'에 있습니다. 켠 뒤 클라이언트로 돌아가 완료를 한 번 눌러야 승인이 마무리됩니다.
- 로컬 네트워크 권한.최신 macOS에서는 앱이 처음으로 LAN 기기에 접근할 때 '로컬 네트워크' 권한을 요청합니다. 거부하면 공유기 관리 페이지, NAS, 프린터 접근이 제한되며 해외 회선 자체에는 영향이 없습니다. 판단이 서지 않으면 일단 허용하고, 나중에 '개인정보 보호 및 보안 → 로컬 네트워크'에서 끄면 됩니다.
결론은 단순합니다. Apple 칩 Mac에서는 네이티브 arm64에 시스템 확장 조합이 기본값으로 삼을 만한 유일한 방식이고, 애플리케이션 계층 프록시는 관리 환경이나 임시 점검, 또는 특정 앱 하나만 해외 회선을 쓰면 되는 상황에 남겨 두면 됩니다.
첫 실행: 권한 부여 절차
순서대로 한 번만 따라 하면 대부분의 재작업을 줄일 수 있습니다.
- 설치 패키지를 '응용 프로그램' 폴더로 끌어다 놓은 뒤 실행하세요. 디스크 이미지 안에서 바로 더블클릭해 실행하면 경로가 읽기 전용이라 이후 자동 업데이트가 실패합니다.
- 첫 실행이 Gatekeeper에 막히면 '개인정보 보호 및 보안'에서 허용하세요. 이때 시스템이 로그인 암호 입력이나 Touch ID 인증을 요구합니다.
- 클라이언트가 VPN 구성 추가를 요청하면 허용을 누르세요. 이 단계는 실제로 네트워크 확장을 VPN 구성 하나로 등록하는 과정이라, 거부하면 시스템 설정에서 직접 추가해야 합니다.
- 안내에 따라 시스템 확장 스위치를 켜고 클라이언트로 돌아와 확인하세요. 이 시점에 '시스템 설정 → VPN' 목록에 클라이언트가 관리하는 구성이 하나 보여야 합니다.
- 사용자 이름과 비밀번호로 로그인하며 이메일 주소는 필요하지 않습니다. 같은 계정으로 대수 제한 없이 Mac, iPhone, Windows를 동시에 온라인 상태로 둘 수 있습니다. 로그인 후 구독 링크를 가져오면 회선 목록이 자동으로 불러와집니다.
- 회선 하나를 골라 연결한 뒤, 뒤에 나오는 명령으로 DNS와 기본 라우트가 실제로 터널로 들어갔는지 확인하세요.
iCloud 서비스와 공존할 때의 주의점
iCloud 비공개 릴레이
비공개 릴레이와 서드파티 클라이언트는 모두 네트워크 확장이라, 시스템은 한 번에 한 경로만 트래픽을 맡깁니다. 흔한 증상은 클라이언트를 켜면 비공개 릴레이가 사용 불가로 바뀌거나, 반대로 비공개 릴레이가 클라이언트 터널을 밀어내는 것입니다. 둘 중 하나를 골라야 합니다. 고정된 출구 지역이 필요하거나 도메인별 분할이 필요하면 '시스템 설정 → Apple 계정 → iCloud → 비공개 릴레이'에서 끄세요.
비공개 릴레이를 꺼도 iCloud 동기화, iMessage, 나의 찾기는 영향을 받지 않습니다. 이들은 일반 HTTPS를 쓰며, 단지 Apple의 2단계 중계를 거치지 않을 뿐입니다.
Handoff, AirDrop, 범용 클립보드
이 기능들은 블루투스와 P2P Wi-Fi를 사용하며 utun 가상 인터페이스를 거치지 않으므로, 보통은 가속을 켜든 끄든 똑같이 동작합니다. 예외는 자동 연결을 전역 점유로 설정하고 사설 네트워크 대역까지 터널에 넣은 경우입니다. 이때는 기기 검색이 느려집니다. 192.168 같은 사설 대역과 .local 도메인을 직접 연결로 빼면 문제가 사라집니다.
iCloud Drive와 지역 판정
iCloud Drive와 사진 동기화는 일반 HTTPS 트래픽이라 터널을 따라갑니다. 회선 대역폭이 제한적이라면 대용량 파일 동기화 시간과 가속 사용 시간을 엇갈리게 하면 됩니다. 또 하나 흔한 오해는 출구를 바꾸면 App Store 지역이 바뀐다는 것입니다. 계정 지역은 Apple 계정의 결제 정보로 정해지며 출구 IP와는 무관하므로, 회선을 바꿔도 스토어 콘텐츠는 달라지지 않습니다.
프로토콜과 회선: macOS에서의 선택
프로토콜은 클라이언트가 트래픽을 터널로 어떻게 넣을지를, 회선은 터널에 들어간 뒤 어느 경로로 갈지를 정합니다. 두 가지는 나눠서 봐야 합니다.
| 프로토콜 | 전송 계층 | macOS에서의 처리 방식 | 설명 |
|---|---|---|---|
| Shadowsocks | TCP / UDP | 네트워크 확장 또는 로컬 프록시 | 구조가 단순해 규칙을 쓰기 쉬움 |
| VMess / VLESS | TCP, TLS 조합 가능 | 네트워크 확장 | TLS와 조합하면 일반 HTTPS와 같은 형태 |
| Trojan | TCP + TLS | 네트워크 확장 | 유효한 인증서 필요, 핸드셰이크가 HTTPS에 가까움 |
| Hysteria2 / TUIC | QUIC(UDP) | 네트워크 확장이 UDP를 포워딩 | 약한 네트워크에서 유리, UDP 품질에 민감 |
TCP 계열 프로토콜은 macOS에서 네트워크 확장이 일괄 처리하므로 모든 앱이 혜택을 받고 호환 문제가 가장 적습니다. Hysteria2와 TUIC는 QUIC 위에서 동작해 UDP 포워딩 경로에 더 민감합니다. 회선의 UDP 품질이 나쁠 때의 전형적인 증상은 웹페이지는 열리는데 영상이 끊기는 것입니다. 이 둘은 기본값이 아니라 대안으로 두는 편이 안정적입니다.
회선 유형에서 IEPL 전용선은 종단 간 전용 링크라 저녁 피크 시간대의 지터가 작고, 중계는 제3지를 경유해 비용이 낮은 대신 경로가 길며, 직결의 지연은 사실상 물리적 거리로 결정됩니다. 어느 것을 고를지는 이름이 아니라 목표 서비스가 어느 지역에 있느냐로 판단하세요. 목표가 미국 서부 해안이면 로스앤젤레스 방향 출구를, 목표가 일본이면 도쿄를 고르면 됩니다. 터널 안에서는 군사급 암호화를 동일하게 사용하며, 프로토콜 간 차이는 암호화 강도가 아니라 전송 방식에 있습니다.
분할 라우팅 규칙은 한 번은 따로 손볼 가치가 있습니다. macOS 클라이언트는 보통 도메인 접미사, IP 대역, 프로세스 이름 세 가지로 경로를 판단합니다. 중국 본토 사이트와 로컬 네트워크는 직접 연결로 두고 필요한 도메인만 터널로 보내면 대역폭도 아끼고 DNS 조회가 바깥으로 새는 일도 줄어듭니다. 규칙을 잘못 쓰는 것이 연결은 되는데 특정 사이트가 안 열리는 첫 번째 원인입니다.
연결은 되는데 통신이 안 될 때: 점검 목록
클라이언트에 '연결됨'이 표시된다고 해서 트래픽이 실제로 터널로 들어간 것은 아닙니다. 아래 순서대로 확인하면 대부분의 문제는 2분 안에 찾을 수 있습니다.
- ❌ 시스템 확장 스위치가 꺼져 utun 인터페이스가 만들어지지 않았고, '연결됨'은 화면 표시일 뿐인 경우.
- ❌ 분할 라우팅 규칙이 대상 도메인을 직접 연결로 판정한 경우. 클라이언트 로그에서 규칙 적중 기록을 확인하세요.
- ❌ DNS가 여전히 공유기나 통신사를 가리키는 경우. 터널은 만들어졌지만 이름 해석이 바깥에서 이뤄져 일부 사이트가 열리지 않습니다.
- ✅ 다른 회선으로 다시 테스트하세요. 같은 지역에서 IEPL 전용선과 중계를 각각 시험하면 회선 문제와 로컬 설정 문제를 구분할 수 있습니다.
- ✅ iCloud 비공개 릴레이나 다른 VPN 구성이 동시에 켜져 있는지 확인하세요. 두 터널이 같은 기본 라우트를 두고 다툽니다.
- ✅ 구독 링크를 다시 가져와 로컬 회선 목록이 만료된 것은 아닌지 배제하세요.
# 1. 현재 적용 중인 DNS 서버
scutil --dns | grep 'nameserver\[[0-9]\]'
# 2. 기본 라우트가 터널 인터페이스에 있는지
route -n get default | grep interface첫 번째 명령은 시스템이 사용 중인 DNS를 나열합니다. 첫 nameserver가 공유기 주소나 통신사 주소라면 이름 해석이 터널로 들어가지 않은 것입니다. 두 번째 명령 출력에서 interface가 utun으로 시작하면 기본 라우트가 점유된 것이고, 여전히 en0이라면 트래픽은 터널을 타지 않은 것입니다.
점검 중에 클라이언트를 반복해서 재설치하지 마세요. 승인, 라우트, DNS 세 구간 중 재설치는 첫 구간만 초기화하므로 뒤 두 구간의 문제는 그대로 재현됩니다.
결론: 실행 가능한 선택 순서
M 시리즈 Mac에서는 선택 순서를 세 단계로 고정할 수 있습니다. 먼저 네이티브 arm64 시스템 확장 클라이언트인지 보고, 다음으로 프로토콜과 회선이 접속하려는 지역을 커버하는지, 마지막으로 분할 라우팅 규칙이 도메인 단위로 세밀하게 제어되는지 확인하세요.세 가지를 모두 만족하면 그때 남는 것이 회선 품질이고, 하나라도 빠지면 아무리 저렴한 요금제도 저녁 피크에 되돌아옵니다.
VPNEH의 macOS 클라이언트는 시스템 확장과 네트워크 확장을 함께 쓰는 방식이며, 프로토콜은 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, TUIC를 지원합니다. 회선은 IEPL 전용선, 중계, 직결 세 가지로 나뉘고 90+ 국가 / 190+ 회선을 제공합니다. 가입에는 사용자 이름과 비밀번호만 쓰며 이메일 주소는 필요하지 않습니다. 같은 계정으로 대수 제한 없이 Mac과 iPhone을 동시에 온라인 상태로 둘 수 있습니다. 첫 결제 후 14일 이내에는 이유를 묻지 않고 전액 환불을 요청할 수 있어 체험 부담이 적습니다.