Mac에서 mDNSResponder가 무엇인가요? Bonjour, DNS, 그리고 높은 네트워크 사용량 설명

mDNSResponder는 macOS에 내장된 시스템 데몬으로, Apple이 서명한 것이다. 이건 악성코드도 아니고, 애드온도 아니며, 사용자가 설치한 것도 아니다 — 운영체제와 함께 제공되며 자동으로 시작된다.

이 데몬은 두 가지 별개의 역할을 수행하는데, 이들을 혼동하는 것이 대부분의 오해의 원인이다. 첫 번째는 멀티캐스트 DNS와 서비스 검색 — 이것이 바로 Apple의 Bonjour로, Mac이 프린터, AirPlay 수신기, Chromecasts, 공유 드라이브, HomeKit 액세서리, 그리고 기타 Mac을 수동 설정 없이 찾을 수 있게 하는 기술이다. 이 트래픽은 UDP 포트 5353의 멀티캐스트 주소로 보내지며, 이것이 표준 mDNS 포트다.

두 번째 역할은 대부분의 설명이 생략하는 부분인데: macOS에서 mDNSResponder는 또한 시스템 전체 DNS 해결기다. Mac의 어떤 애플리케이션이든 호스트명을 IP 주소로 바꿔야 할 때, 요청은 보통 그 애플리케이션 자체가 아니라 mDNSResponder가 대신 처리한다.

이 두 역할은 같은 프로세스 내에서 실행된다. 그래서 mDNSResponder가 바쁘게 보인다면, 이는 로컬 네트워크 검색과 Mac이 수행하는 모든 이름 조회의 결합된 결과를 보고 있는 것이다.

이것이 사람들을 놀라게 하는 부분이며, 평범한 설명이 있습니다. mDNSResponder가 이름을 해결하는 역할을 다른 프로세스를 대신하여 수행하기 때문에, 본질적으로 Mac의 모든 DNS 조회는 실제 주소를 원했던 앱이 아니라 mDNSResponder에서 비롯된 것처럼 보입니다.

브라우저가 수십 개의 타사 리소스를 포함하는 페이지를 로드하거나, 이메일 클라이언트가 계정을 확인하거나, 백그라운드 업데이트, 채팅 앱이 재연결하는 것 — 이들 모두가 DNS 보기에서 자신으로 나타나지 않습니다. 대신, mDNSResponder가 구성된 DNS 서버와 통신하는 모습으로 나타납니다. 외부에서는 하나의 프로세스가 방대한 도메인 목록에 관심이 있는 것처럼 보입니다.

이 단일 사실이 대부분의 의심을 해소합니다. mDNSResponder가 많은 호스트에 접촉하는 것을 보는 것이 mDNSResponder가 의심스러운 행동을 하고 있다는 의미는 아닙니다. 이것은 프록시입니다. 활동은 조회를 요청한 소프트웨어에 속하며, mDNSResponder는 그것을 수행하는 구성요소일 뿐입니다.

이것은 또한 프로세스가 드물게 조용해지는 이유를 설명합니다. 현대 Mac은 지속적인 배경 소음처럼 소프트웨어가 체크인하는 소리를 냅니다 — 동기화 서비스, 푸시 알림, 업데이트 체크, 설치한 앱의 텔레메트리. 이 모든 것들은 먼저 이름 해석이 필요하며, 모두 같은 데몬을 통해 전달됩니다.

mDNSResponder는 macOS의 정당한 일부입니다. 이것이 악의적인 것으로 위장된 사례는 의미 있는 기록이 없으며, 정상적으로 작동하는 Mac에서는 정확히 하나의 인스턴스만 실행되고 있어야 합니다.

그것을 믿을 필요는 없습니다. Activity Monitor에서 프로세스를 선택하고 검사기를 열어 세부 정보를 확인하세요. 여기에는 실행 파일의 경로도 포함됩니다. Apple의 시스템 데몬은 보호된 시스템 디렉터리 내에 있으며, 홈 폴더, 다운로드 또는 애플리케이션 내에 있지 않습니다. 이름이 mDNSResponder이지만 비정상적인 위치에서 실행되는 프로세스는 조사할 가치가 있으며, 이름 자체는 아무것도 증명하지 않습니다.

더 강력한 검증 방법은 코드 서명입니다. macOS는 codesign 도구를 제공하며, 실행 중인 바이너리의 경로에 대해 검증을 수행하면 서명 권한을 확인할 수 있습니다. Apple의 자체 시스템 구성요소는 Apple이 서명하며, 최신 macOS 버전에서는 시스템 파일이 봉인된 읽기 전용 시스템 볼륨에 위치하여, 실제 바이너리를 조작하는 것이 훨씬 더 어려워졌습니다.

또 하나의 정상 여부 확인 방법은: mDNSResponder의 높은 활동은 정상입니다. 그러나 몇 시간 동안 지속되는 높은 CPU 사용량은 그렇지 않습니다. 이는 보통 네트워크 또는 Mac의 다른 문제의 증상이며, 다음 섹션에서 다루겠습니다.

mDNSResponder가 실제로 오작동할 때 원인은 거의 항상 그 외부에 있다. 흔한 원인: Bonjour 트래픽이 많은 바쁜 로컬 네트워크, 자신을 적극적으로 광고하는 프린터 또는 NAS, 시스템 해석기(resolver)와 충돌하는 VPN 또는 타사 DNS 소프트웨어, 호텔이나 카페 네트워크의 캡티브 포털 프로빙, 또는 Mac에서 한 앱이 반복적으로 조회를 수행하는 경우.

노력 순서대로 해결해 보자. 먼저 Wi‑Fi를 끄고 다시 켜거나 잠시 네트워크 연결을 끊어보라 — 이 방법으로 놀라울 정도로 많은 일시적 상태가 해소된다. 그래도 도움이 되지 않으면 재부팅하라; 재시작은 데몬과 그에 연결된 모든 것을 재설정한다. 문제가 특정 네트워크에서만 발생한다면 네트워크가 변수이며 Mac이 원인은 아니다: 다른 네트워크를 시도해 확인하고, 해당 네트워크에서 무엇이 자신을 광고하는지 살펴보라. 최근에 VPN 클라이언트, DNS 필터링 도구 또는 네트워크 확장 기능을 설치했다면 일시적으로 비활성화해 보면 그것이 원인인지 빠르게 알 수 있다. 문제가 네트워크를 넘나들며 재부팅 후에도 계속된다면 특정 애플리케이션을 의심하고, 최근에 설치했거나 업데이트한 앱을 하나씩 종료해 보라.

하지 말아야 할 일은 차단하는 것이다. 절대 방화벽에서 mDNSResponder를 차단하지 마라. 시스템 전체의 해석기이기 때문에 이를 차단하면 Mac 전체의 이름 해석이 중단된다 — 브라우저, Mail, App Store, 소프트웨어 업데이트 등 네트워크를 사용하는 거의 모든 것이 실패하고, 보통 추가한 방화벽 규칙을 가리키지 않는 혼란스러운 오류가 발생한다. 이는 차단이 의도한 트래픽보다 훨씬 더 많은 피해를 초래하는 몇 안 되는 프로세스 중 하나다.

만약 실제 목표가 로컬 네트워크의 불필요한 트래픽을 줄이는 것이라면 해결기(resolver) 자체보다 기능을 대상으로 하라. AirPlay 수신기, 프린터 공유, 파일 공유 및 사용하지 않는 기타 Bonjour 의존 서비스를 끄면 DNS를 망가뜨리지 않으면서 Mac이 광고하고 수신하는 것을 줄일 수 있다. 이것이 올바른 방법이다.

중앙화된 해석의 결과는 귀속 문제다. 시스템 수준에서 연결을 관찰하면 흥미로운 DNS 활동의 많은 부분이 mDNSResponder로 표시되고, 그 라벨만으로는 도메인이 브라우저, 백그라운드 업데이트, 혹은 조용히 원격으로 통신하는 앱 중 어느 쪽에 의해 요청되었는지 알 수 없다.

이를 확인하려면 프로세스별로 연결을 감시하고 활동을 조회를 수행한 데몬이 아니라 요청을 시작한 앱에 매핑하는 도구가 필요하다. 이것이 바로 NetMute가 메우려는 격차다: 앱별·프로세스별 실시간 트래픽을 보여주고, 앱별 도메인 수준 로그(어떤 도메인에 접속했는지, 언제, 얼마나 많은 데이터가 이동했는지)를 유지한다. 바쁜 하나의 데몬 대신 Mac이 실제로 누구와 통신하는지에 대한 앱별 그림을 제공한다.

그다음에는 대응이 목표 지향적이다. NetMute의 앱별 방화벽은 한 번의 클릭으로 특정 앱을 차단하거나, 일시적으로만 차단하고 싶을 때 자체 만료되는 임시 규칙을 적용할 수 있다. 네트워크 프로필은 집, 사무실, 신뢰할 수 없는 네트워크 간 규칙을 다르게 설정할 수 있게 하며, Tracker Shield는 1,100개 이상의 알려진 트래커 도메인 목록을 커버한다. 이 모든 것은 mDNSResponder 자체를 방해하지 않는다 — 해결기는 그대로 두고 요청을 생성한 앱에 대해 조치하는 것이 나머지 Mac을 망가뜨리지 않는 유일한 해결책이다.