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

mDNSResponder는 macOS에 내장된 시스템 데몬이며 Apple이 코드 서명한 프로세스입니다. 악성코드도 아니고, 추가 구성요소도 아니며, 사용자가 설치한 것도 아닙니다. 운영체제와 함께 제공되고 자동으로 시작됩니다.

이 프로세스는 서로 다른 두 가지 일을 하는데, 이 둘을 혼동하는 것이 주변의 대부분의 혼란을 만듭니다. 첫 번째는 멀티캐스트 DNS와 서비스 검색입니다. 이것이 바로 Apple의 Bonjour로, Mac이 수동 설정 없이도 로컬 네트워크에서 프린터, AirPlay 수신기, Chromecast, 공유 드라이브, HomeKit 액세서리, 다른 Mac을 찾게 해주는 기술입니다. 이 트래픽은 UDP 포트 5353의 멀티캐스트 주소로 전송되며, 이것이 표준 mDNS 포트입니다.

두 번째 작업은 대부분의 설명이 건너뛰는 부분입니다. macOS에서 mDNSResponder는 또한 시스템 전역 DNS 확인기입니다. Mac의 어떤 앱이든 호스트 이름을 IP 주소로 바꿔야 할 때, 보통 그 앱 대신 mDNSResponder가 요청을 처리합니다.

이 두 작업은 같은 프로세스 안에서 실행됩니다. 그래서 mDNSResponder가 바빠 보인다면, 로컬 네트워크 검색과 Mac이 수행하는 모든 이름 조회의 합을 보고 있는 것입니다.

이것이 사람들을 놀라게 하는 부분이지만, 설명은 의외로 평범합니다. mDNSResponder가 다른 프로세스를 대신해 이름을 해석하기 때문에, 사실상 Mac의 모든 DNS 조회는 실제로 주소가 필요했던 앱이 아니라 mDNSResponder에서 시작된 것처럼 보입니다.

브라우저가 수십 개의 타사 리소스가 포함된 페이지를 불러오거나, 메일 앱이 계정을 확인하거나, 백그라운드 업데이트가 실행되거나, 채팅 앱이 다시 연결할 때도, DNS 화면에서는 그 앱들 자체가 보이지 않습니다. 대신 구성된 DNS 서버와 대화하는 mDNSResponder만 보입니다. 겉으로 보면 하나의 프로세스가 끊임없이 바뀌는 엄청난 도메인 목록에 관심을 가진 것처럼 보입니다.

이 한 가지 사실이 대부분의 의심을 설명합니다. mDNSResponder가 여러 호스트에 접속하는 것을 본다고 해서, mDNSResponder가 수상한 일을 하고 있다는 뜻은 아닙니다. 이것은 프록시입니다. 그 활동은 조회를 요청한 소프트웨어의 것이고, mDNSResponder는 그 요청을 대신 수행하는 구성 요소일 뿐입니다.

이 때문에 이 프로세스가 좀처럼 조용해지지 않는 것도 이해할 수 있습니다. 최신 Mac은 동기화 서비스, 푸시 알림, 업데이트 확인, 설치한 앱들의 텔레메트리처럼 소프트웨어가 계속 상태를 확인하는 배경 활동이 끊이지 않습니다. 이 모든 것은 먼저 이름 해석이 필요하고, 결국 같은 데몬으로 모입니다.

mDNSResponder는 macOS의 정상적인 구성 요소입니다. 이것이 악성 코드의 위장이라는 의미 있는 기록은 없고, 정상적으로 작동하는 Mac이라면 보통 정확히 하나의 인스턴스가 실행 중이어야 합니다.

그 말을 그대로 믿을 필요는 없습니다. 활성 상태 보기에서 프로세스를 선택하고 정보 보기 창을 열면, 실행된 실행 파일의 경로를 포함한 세부 정보를 확인할 수 있습니다. Apple의 시스템 데몬은 홈 폴더나 다운로드, 응용 프로그램 폴더가 아니라 보호된 시스템 디렉터리 안에 있습니다. mDNSResponder라는 이름을 쓰지만 비정상적인 위치에서 실행되는 프로세스라면 그때는 조사해 볼 가치가 있습니다. 이름만으로는 아무것도 증명되지 않습니다.

더 확실한 확인 방법은 코드 서명입니다. macOS에는 `codesign` 도구가 포함되어 있고, 실행 중인 바이너리 경로에 대해 검증을 실행하면 서명 주체를 확인할 수 있습니다. Apple의 시스템 구성 요소는 Apple이 서명합니다. 최근 macOS 버전에서는 시스템 파일이 봉인된 읽기 전용 시스템 볼륨에 위치하므로, 실제 바이너리를 손대는 일은 예전보다 훨씬 더 어렵습니다.

마지막으로 하나 더 확인할 점이 있습니다. mDNSResponder의 높은 활동량은 정상입니다. 하지만 몇 시간 동안 지속되는 높은 CPU 사용량은 정상적이지 않습니다. 대개는 네트워크나 Mac 안의 다른 문제를 뜻하며, 다음 섹션에서 그 부분을 다룹니다.

mDNSResponder가 실제로 오작동하는 경우, 원인은 거의 항상 그 밖에 있습니다. 흔한 원인은 이렇습니다. Bonjour 트래픽이 많은 바쁜 로컬 네트워크, 자신을 과하게 광고하는 프린터나 NAS, 시스템 해석기와 충돌하는 VPN이나 타사 DNS 소프트웨어, 호텔이나 카페 네트워크의 캡티브 포털 탐지, 또는 Mac의 특정 앱이 짧은 간격으로 계속 조회를 보내는 경우입니다.

수고가 적은 것부터 순서대로 해보세요. 먼저 Wi-Fi를 껐다가 다시 켜거나, 잠시 네트워크 연결을 끊어보세요. 의외로 많은 일시적 상태가 이렇게 해결됩니다. 그래도 나아지지 않으면 재시동하세요. 재시작은 데몬과 그 데몬에 입력을 주는 모든 것을 초기화합니다. 문제가 특정 네트워크에서만 생긴다면 변수는 네트워크이지 Mac이 아닙니다. 다른 네트워크에서 같은 현상이 재현되는지 확인한 다음, 그 네트워크에서 무엇이 자신을 광고하는지 살펴보세요. 최근에 VPN 클라이언트, DNS 필터링 도구, 또는 네트워크 확장을 설치했다면 잠시 비활성화해 보세요. 그것이 원인인지 빠르게 확인할 수 있습니다. 문제가 네트워크를 바꿔도 따라오고 재시동 후에도 계속된다면 특정 앱을 의심하고, 최근 설치했거나 최근 업데이트한 앱을 하나씩 종료해 보세요.

하지 말아야 할 일은 차단입니다. mDNSResponder는 절대 방화벽에서 차단하지 마세요. 이것은 시스템 전체 해석기이기 때문에 차단하면 Mac 전체의 이름 해석이 멈춥니다. 브라우저, Mail, App Store, 소프트웨어 업데이트, 그리고 네트워크를 건드리는 사실상 모든 것이 실패하며, 보통 추가한 방화벽 규칙과는 연결되지 않는 혼란스러운 오류를 냅니다. 차단하려던 트래픽보다 훨씬 더 큰 피해를 부르는 몇 안 되는 프로세스 중 하나입니다.

실제 목표가 로컬 네트워크의 소음을 줄이는 것이라면, 해석기 자체가 아니라 기능을 대상으로 하세요. 사용하지 않는 AirPlay 수신, 프린터 공유, 파일 공유, 그리고 Bonjour에 의존하는 다른 서비스들을 끄면 DNS를 망가뜨리지 않으면서 Mac이 알리고 듣는 항목을 줄일 수 있습니다. 이것이 올바른 방법입니다.

중앙화된 이름 해석이 낳는 결과는 귀속 문제입니다. 시스템 수준에서 연결을 보고 있다면, 흥미로운 DNS 활동의 상당 부분이 mDNSResponder로 표시됩니다. 그 이름만으로는 도메인이 브라우저에 의해 요청된 것인지, 백그라운드 업데이트인지, 아니면 조용히 집에 통신하는 앱인지 알 수 없습니다.

이를 알려면 프로세스별 연결을 감시하고, 조회를 수행한 데몬이 아니라 실제로 시작한 앱에 활동을 연결해 주는 도구가 필요합니다. 바로 그 간극을 NetMute가 메우도록 만들어졌습니다. 앱별, 프로세스별 실시간 트래픽을 보여주고, 앱별 도메인 로그도 유지합니다. 어떤 앱이 어떤 도메인에 언제 접속했고, 얼마나 많은 데이터가 오갔는지 볼 수 있습니다. 하나의 바쁜 데몬 대신, Mac이 실제로 누구와 대화하는지 앱 단위로 볼 수 있습니다.

그다음 대응은 더 정밀해집니다. NetMute의 앱별 방화벽은 특정 앱을 한 번의 클릭으로 차단할 수 있고, 잠깐만 조용히 두고 싶을 때는 자동 만료되는 임시 규칙도 적용할 수 있습니다. 네트워크 프로필을 쓰면 집, 사무실, 신뢰할 수 없는 네트워크에 따라 규칙을 다르게 둘 수 있고, Tracker Shield는 알려진 트래커 도메인 1,100개 이상을 막아줍니다. 이 모든 기능은 mDNSResponder 자체를 건드리지 않습니다. 해석기는 그대로 두고, 요청을 만든 앱에 조치를 취하는 것, 그게 Mac의 나머지를 망가뜨리지 않는 유일한 해결책입니다.