Mac에서 앱의 인터넷 사용을 차단하는 방법
시스템의 다른 부분을 망가뜨리지 않으면서 macOS에서 앱의 인터넷 사용을 차단하는 실용적인 방법들입니다.
- macOS
- Security
- Privacy
- Tutorial
2022년에 구입한 앱이 모든 실행마다 본부에 전화합니다. 핫스팟에 있는 동안 게임이 3GB 업데이트를 다운로드하고 싶어 합니다. 스캐닝 유틸리티가 업데이트 확인을 계속 고집합니다. 앱을 제거하지 않고, 시스템의 나머지를 깨뜨리지 않고 Mac 인터넷에서 앱을 완전히 차단하고 싶습니다.
좋은 소식: macOS는 Mac 사용자가 실제로 필요로 하는 인터넷에서 앱을 차단하는 여러 방법을 제공합니다. 나쁜 소식: 각각 다른 트레이드오프를 가지고 있고, 잘못된 선택은 조용히 실패하거나 의도하지 않은 것을 깨뜨릴 것입니다. 여기 실용 플레이북이 있습니다.
Mac 사용자가 알아야 할 인터넷에서 앱을 차단하는 네 가지 방법
대부분의 사람이 골라야 할 대략적인 순서로:
- Little Snitch — 목적에 맞게 만들어진 외부 방화벽. 앱별 규칙, 첫 연결에 프롬프트, 편집을 위한 GUI.
- LuLu — Objective-See의 무료 오픈소스 외부 방화벽. Little Snitch보다 덜 다듬어졌지만 비슷한 핵심 아이디어.
- macOS 애플리케이션 방화벽 + 네트워크 필터 — 내장 방화벽은 들어오는 것만 처리합니다. 외부 차단을 위해서는 서드파티 네트워크 확장 또는
pf규칙이 필요합니다. /etc/hosts차단 — 무딘 부분적이지만 알려진 텔레메트리 엔드포인트에 유용합니다.
완전히 오프라인으로 만들고 싶은 단일 앱의 경우, 옵션 1 또는 2가 적절한 답입니다. 다른 것은 상황에 따라 다릅니다.
옵션 1: Little Snitch (표준)
Little Snitch는 외부 연결을 가로채는 네트워크 확장을 설치합니다. 이전에 보지 못한 앱이 본부에 전화하려 할 때, Little Snitch는 프롬프트를 보여줍니다: 한 번 허용, 영원히 허용, 한 번 거부, 영원히 거부 — 선택적 범위(이 호스트 이름만, 어떤 포트 등)와 함께.
한 앱을 완전히 차단하려면:
- Little Snitch → 네트워크 모니터 → 규칙을 엽니다.
- 앱 이름을 검색합니다.
- 기존 규칙을 삭제하고 다음번 기본 거부 프롬프트에 의존하거나, 명시적 "거부 — /Applications/YourApp.app의 어떤 프로세스든 — 어떤 연결이든"을 추가합니다.
- 대상 앱을 종료하고 다시 실행합니다.
Little Snitch는 무료 데모(세션당 3시간)가 있는 유료 소프트웨어입니다. 커널 수준에서 의존할 도구의 경우, 한 번 지불하는 것이 적절한 움직임입니다.
중요한 규칙 범위
- 프로세스 경로 — Little Snitch는 디스크의 경로를 키로 하므로, Sparkle을 통해 앱을 업데이트하는 것이 다시 프롬프트를 일으킬 수 있습니다. 다시 승인하거나 규칙을 "어떤 버전이든"으로 설정하세요.
- 도우미 프로세스 — Slack, Discord, Chrome 같은 앱은 자체 규칙이 필요한 도우미 바이너리를 가지고 있습니다. 부모를 허용하고 도우미를 잊으면, 트래픽이 빠져나갈 수 있습니다. ova 같은 모니터는 도우미를 부모 아래로 접어서 이것이 일어날 때 볼 수 있게 합니다.
옵션 2: LuLu (무료)
LuLu는 더 작은 기능 세트로 Little Snitch가 하는 일을 합니다. 같은 네트워크 확장 모델, 같은 프롬프트와 규칙 흐름. 트래픽 그래프나 호스트 이름 기반 필터링을 그렇게 깔끔하게 보여주지는 않지만, "이 한 앱을 차단" 사용 사례에는 완벽하게 적절합니다.
objective-see.org에서 다운로드하고, Applications에 끌어다 놓고, 네트워크 확장 권한을 부여하고, 침묵시키고 싶은 바이너리에 대한 거부 규칙을 추가하세요.
옵션 3: macOS 내장 방화벽 (제한적)
macOS 애플리케이션 방화벽은 시스템 설정 → 네트워크 → 방화벽에 살고 있습니다. 들어오는 연결을 차단합니다. 나가는 것은 차단하지 않습니다. 그래서 "내 앱이 인터넷과 통신하는 것을 멈춤"이라는 질문에 내장 방화벽은 답이 아닙니다.
들어오는 것도 차단하고 싶다면 — 예를 들어, 앱이 노출하고 싶지 않은 로컬 서버를 실행하는 경우 — 방화벽을 켜고, 옵션을 클릭하고, 거부 목록에 앱을 추가하세요.
옵션 4: /etc/hosts 차단 (부분적)
특정 텔레메트리 엔드포인트의 경우, 호스트 이름을 블랙홀할 수 있습니다.
sudo nano /etc/hosts추가:
0.0.0.0 telemetry.example.com
0.0.0.0 analytics.example.comCtrl-O로 저장, Ctrl-X로 종료. 그런 다음 DNS를 비웁니다.
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder이는 실제로 시스템 DNS를 참조하는 앱에 대해서만 작동합니다. IP를 하드코드하거나 자체 DNS를 사용하는 앱은 /etc/hosts를 완전히 우회합니다. DoH를 사용하는 브라우저는 그것을 우회합니다. 그래서 /etc/hosts를 알려진 엔드포인트를 위한 저격용 소총으로 취급하세요. 범용 차단이 아닙니다.
모두가 건너뛰는 검증 단계
차단을 설정하는 것은 일의 절반입니다. 다른 절반은 그것이 작동하는지 확인하는 것입니다. 이것이 별도의 모니터링 도구가 자기 자리를 벌어들이는 곳입니다.
패턴:
- Little Snitch / LuLu / hosts 파일에 차단 설정.
- 메뉴 바에서 ova를 엽니다. 약 1Hz로 앱별 트래픽을 샘플링합니다.
- 대상 앱을 실행하고 사용합니다. 클릭하세요. 본부에 전화하던 동작을 트리거하세요 — 업데이트 확인, 로그인, 동기화.
- 앱별 행을 지켜봅니다. 위와 아래 0KB/s에 머무르면 차단이 유지됩니다. 외부 어떤 것이든 보인다면 누수가 있습니다.
누수가 일어나는 두 가지 이유:
- 도우미 프로세스가 다뤄지지 않음. 부모 앱은 거부되지만,
Slack Helper또는Updater.app이 여전히 허용인 자체 규칙을 가집니다. - 차단 전에 캐시된 연결. 규칙이 존재하기 전에 앱이 장수 연결을 열었습니다. 앱을 완전히 종료(우클릭 → 종료, 또는
Cmd-Q)하고 다시 실행하세요.
특수 사례
LAN 접근을 유지하면서 앱 차단
일부 앱은 AirPlay 스피커나 로컬 프린터와 통신해야 하지만 인터넷에 도달해서는 안 됩니다. Little Snitch에서 "어떤 것이든 거부"를 설정한 다음 LAN과 Multicast/Broadcast에 대한 허용 예외를 추가하세요. macOS 로컬 네트워크 권한도 이를 게이트합니다 — 시스템 설정 → 개인정보 보호 및 보안 → 로컬 네트워크를 확인하고 앱이 LAN을 전혀 필요로 하지 않는다면 취소하세요.
Wi-Fi에서는 앱 차단, 이더넷에서는 허용
Little Snitch는 프로필을 지원합니다. "커피숍"용 하나와 "집"용 하나를 만들고, 다른 규칙을 첨부하고, 메뉴 바를 통해 전환하세요.
업데이트만 차단, 다른 모든 것 허용
대부분의 앱은 업데이트 트래픽을 기능 트래픽과 분리합니다. 업데이트 바이너리(종종 YourApp.app/Contents/Library/LoginItems/ 또는 /Library/LaunchDaemons/ 내부)를 찾고, 그 특정 경로에 대한 거부 규칙을 추가하세요. 앱을 실행하고 ova를 지켜보세요 — 기능은 여전히 작동해야 하고, 업데이트는 로그의 네트워크 오류로 실패해야 합니다.
방화벽 차단이 실제로 유지되는지 검증하세요
ova는 라이브 앱별 트래픽을 보여주므로 Little Snitch 규칙이 일을 했는지 확인할 수 있습니다 — 로컬, 서명, 약 3MB.
작업한 예: 수다스러운 유틸리티 침묵시키기
3년 전에 스크린샷 유틸리티를 구입했다고 가정합시다. 평생 라이선스, 조용했었지만, 이제 모든 실행마다 본부에 전화하고 새 소유권을 신뢰하지 않습니다.
- Little Snitch를 설치합니다. 규칙이 어떻게 느끼는지 보기 위해 첫 시간은 시험판이 괜찮습니다.
- 스크린샷 유틸리티를 실행합니다. Little Snitch가 프롬프트: "Snipster가 api.snipster.app에 연결하고 싶어 합니다". 거부 → 영원히 → 어떤 포트든을 클릭합니다.
- 일주일 동안 앱을 사용합니다. 기능이 작동하면 거부가 유지됩니다. 기능이 깨지면 무엇을 호출하려 했는지 보세요 — Little Snitch의 로그에 있을 것입니다 — 그리고 특정 엔드포인트를 허용할지 결정하세요.
- 나란히 ova를 실행합니다. 정상 사용 동안 앱별 속도가 0KB/s에 머무는지 확인합니다.
이 패턴은 로컬에서 자기 일을 하기 위해 실제로 인터넷이 필요하지 않은 모든 앱에 작동합니다.
차단이 고치지 않을 것
솔직해질 몇 가지:
- APNs를 통한 푸시 알림. macOS는 앱이 아니라
apsd를 통해 Apple Push를 라우팅합니다. 앱을 차단하는 것이 그것의 알림을 차단하지 않습니다. 대신 시스템 설정에서 알림을 비활성화하세요. - 시스템 확장과 데몬. 일부 앱은
/Library/LaunchDaemons/아래 백그라운드 데몬을 설치합니다. 앱을 죽이는 것이 데몬을 죽이지 않습니다. 앱의 공식 제거기를 사용하거나,launchctl list | grep -i appname을 통해 데몬을 나열하세요. - IP를 하드코드하는 앱. 드물지만 존재합니다. Little Snitch에서 호스트 이름이 아니라 IP로 차단하세요.
- XPC 서비스를 사용하는 샌드박스된 App Store 앱. 때때로 사용자가 보는 앱이 침묵하고 XPC 도우미가 통신을 합니다. 도우미 프로세스와 같은 수정 — Little Snitch의 프로세스 트리에서 찾고 규칙을 추가하세요.
"모니터 + 방화벽"이 지속 가능한 설정인 이유
방화벽만 실행할 수 있습니다. 모니터만 실행할 수 있습니다. 대부분의 경험 있는 Mac 사용자는 둘 다 실행합니다.
- 방화벽(Little Snitch / LuLu)은 정책을 설정하고 커널에서 차단합니다.
- 모니터(ova 또는 비슷한 것)는 현실을 보여줍니다 — 무엇이 여전히 통신하고 있고, 얼마나, 언제.
둘은 다른 질문에 답합니다. "내 규칙이 작동했는가?"는 모니터 질문입니다. "어떤 새 앱이 본부에 전화하려 하는가?"는 방화벽 프롬프트 질문입니다. 함께라면 완전한 그림을 줍니다.
마무리
Mac 인터넷에서 앱을 처음부터 끝까지 차단하려면: 차단을 위해 Little Snitch 또는 LuLu 사용, 들어오는 것도 필요한 경우에만 macOS 애플리케이션 방화벽, 그리고 DNS 기반 차단으로 충분할 때 알려진 엔드포인트를 위한 /etc/hosts. 그런 다음 모니터로 검증하세요. 확인하지 않은 규칙은 실제로 가지고 있지 않은 규칙입니다.
대부분의 앱은 네트워크를 자르면 오프라인에서 잘 작동합니다. 그렇지 않은 것은 빠르게 알게 될 것이고 — 어떤 기능이 처음부터 실제로 로컬이었는지에 대해 유용한 무언가를 배우게 될 것입니다.