cloudd가 실제로 하는 일
cloudd는 CloudKit 데몬이야: macOS가 앱을 대신하여 Apple의 iCloud 서버와 통신하는 데 사용하는 프로세스야. 이것은 macOS의 표준 부분으로, Apple이 배포하고 코드 서명했으며, 악성코드가 아니야.
CloudKit은 iCloud에 앱 데이터를 저장하고, 사용자 기기 간에 일관성을 유지하는 Apple의 프레임워크야. 앱들은 자체적으로 연결을 열지 않고 데이터를 CloudKit에 넘기며, cloudd는 변경 사항 업로드, 다른 기기에서의 변경 사항 가져오기, 실패 요청 재시도를 담당해.
이것이 기대하는 것보다 더 많은 역할을 해. iCloud Drive 문서 동기화도 그것을 통해 이루어지고, Notes와 Photos도 그것을 사용하며, 라이브러리 메타데이터도 포함돼. Apple의 많은 앱들이 Mac, iPhone, iPad 간의 일관성을 유지하기 위해 의존하고 있으며, 많은 서드파티 앱들도 마찬가지야: CloudKit은 개발자가 자체 서버 없이도 동기화를 할 수 있게 해주는 인기 있는 백엔드야.
그래서 cloudd가 활성화되어 있다면, 거의 항상 iCloud 동기화가 진행 중인 상태야 — 시스템, Apple 앱, 또는 설치한 어떤 것에 대해서든.
왜 cloudd의 트래픽이 사실 다른 앱들의 트래픽인지
이것이 cloudd에 대해 이해하는 데 가장 유용한 점이자, 거의 모든 혼란의 원천이야.
cloudd는 공유 택배원이야. 의미 있는 방식으로 자체 트래픽을 생성하지 않고, 다른 앱들의 데이터를 전달하는 역할을 해. 노트가 변경되거나, 문서가 iCloud Drive에 저장되거나, 서드파티 작업 관리자가 항목을 동기화할 때, 그 바이트들은 네 Mac을 떠나면서 cloudd의 이름으로 가게 되고, 그 데이터를 만든 앱의 이름으로 가지 않아. 네트워크 활동을 프로세스별로 구분하는 도구, Activity Monitor도 마찬가지로, cloudd에 큰 수치를 보여주고, 실제 책임이 있는 앱에는 적은 수치를 보여줄 거야.
그래서 cloudd가 많은 데이터를 사용하는 것은 거의 항상 cloudd 자체에 대한 진술이 아니야. 네 앱들이 얼마나 동기화하는지에 대한 진술이고, 하나의 라인으로 집계된 거지. 동일한 macOS 복사본을 실행하는 두 Mac이 완전히 다른 cloudd 수치를 보여줄 수 있는데, 그 이유는 한 쪽은 큰 Photos 라이브러리와 CloudKit-backed 앱 몇 개를 가지고 있기 때문이야.
macOS는 이 밖에도 nsurlsessiond가 다른 앱들의 백그라운드 다운로드와 업로드를 담당하며, 같은 이유로 무겁게 보여. 패턴을 인지하면, 이름이 일반적인 데몬도 더 이상 경고로 느껴지지 않아. 그것은 보통 파이프이고, 흥미로운 질문은 그 안을 통해 무엇이 전달되고 있는지야.
cloudd는 안전한가요, 그리고 직접 확인하는 방법
cloudd는 안전합니다. 이것은 애플의 1차 파트 데몬이며, 수년간 macOS의 일부였고, 그 행동은 수행하는 작업에 의해 완전히 설명됩니다. 걱정의 합리적인 버전은 실제 cloudd가 위험한지 여부가 아니라, 그 이름으로 실행되는 프로세스가 진짜인지 여부입니다 — 공정한 질문입니다, 왜냐하면 지루한 시스템 사운드 이름을 사용하는 것은 오래된 속임수이기 때문입니다.
특별한 도구 없이도 해결할 수 있습니다. Activity Monitor에서 cloudd를 찾아 더블 클릭하여 검사기를 열어보세요. 진짜 데몬은 홈 폴더, Applications 또는 Downloads가 아닌 읽기 전용 시스템 볼륨 내부에 있으며, launchd에 의해 시작됩니다. 사용자 디렉터리에서 실행되는 cloudd라는 프로세스는 이상 현상일 수 있으며, 추적할 가치가 있습니다.
더 강력한 검사는 코드 서명입니다. 애플의 시스템 바이너리는 애플이 서명하며, 최신 macOS에서는 시스템 볼륨이 암호화되어 있기 때문에 교체된 시스템 데몬은 일반 소프트웨어가 조용히 조작할 수 없는 것입니다. macOS는 어떤 바이너리의 서명 권한을 보고하는 명령줄 도구를 제공하며, cloudd의 경우 애플로 표시되어야 합니다.
또한 cloudd가 아닌 것이 무엇인지도 말할 가치가 있습니다. 이것은 분석 또는 원격 측정 프로세스가 아니며, 이미 활성화된 서비스에 대해 앱의 데이터를 iCloud로 이동시키는 역할을 합니다.
왜 cloudd가 많은 CPU 또는 네트워크를 사용하는가요
무거운 cloudd 활동은 거의 항상 큰 동기화가 진행 중임을 의미하며, 가장 흔한 경우는 초기입니다. 새로 로그인한 iCloud 계정, 새로 설치했거나 방금 켠 서비스는 처음부터 모든 것을 조정해야 하며, 이는 몇 시간 동안 계속될 수 있고 많은 데이터를 이동시킵니다. 대표적인 예는 큰 Photos 라이브러리 또는 방금 추가하거나 복원한 큰 iCloud Drive 폴더입니다. 적절한 대응은 보통 인내심을 갖는 것인데, 데이터가 중요하지 않은 연결에서 완료되도록 하고, 활동은 자연스럽게 줄어듭니다.
두 번째 원인은 계속 실패하고 재시도하는 동기화입니다. 업로드할 수 없는 항목이 있으면, cloudd는 루프 내에서 재시도할 수 있으며, 이는 지속적인 CPU 사용처럼 보이지만 아무것도 보여주지 않습니다. 징후는 며칠 동안 계속되는 활동이며, 큰 전송이 없는 상태입니다. 재시작은 이러한 문제를 상당수 해결할 수 있으며, 그렇지 않으면 iCloud 설정에서 해당 서비스를 끄거나 다시 켜거나, iCloud에서 로그아웃 후 다시 로그인하는 것이 일반적입니다.
세 번째로, 실제로 활성화된 것이 무엇인지 확인하세요. iCloud 설정은 어떤 서비스와 앱이 동기화되는지 보여주며, 타사 앱도 포함됩니다. 거의 사용하지 않는 앱의 동기화를 끄면 그 부하를 완전히 제거할 수 있습니다.
요금제 연결에서는 문제가 cloudd가 바쁜 것이 아니라, 바쁨이 비용이 든다는 점입니다. 답은 여전히 차단하는 것이 아니며, iCloud 동기화를 일시 중지하거나, 해당 네트워크에 Low Data Mode를 켜거나, 가장 무거운 서비스를 비활성화하거나, 트래픽을 제한하는 것입니다.
차단하는 것과 더 큰 그림
방화벽으로 cloudd를 차단하는 것은 가능하며, 한 가지 특정 이유로 인해 나쁜 아이디어입니다: 시스템 전체의 iCloud 동기화가 조용히 깨지기 때문입니다. 아무런 오류 메시지도 표시되지 않습니다. 노트는 다른 기기에서 나타나지 않고, 문서는 업데이트를 멈추며, 서드파티 앱은 조용히 오래되어 가고, 몇 주 후에는 Mac에서 한 변경 사항이 iPhone에 도달하지 않은 이유를 알아내야 합니다. 메커니즘 자체를 공격하는 것이 아니라, 볼륨이 문제입니다.
이로 인해 진짜 문제는 가시성입니다. macOS는 묻지 않고 네트워크와 통신하는 많은 데몬을 실행하며, 대부분 이름이 아무것도 드러내지 않으며, 어느 곳에 연결되고 얼마나 많은 데이터를 이동하는지 볼 수 있는 방법이 거의 없습니다. 대역폭 목록 상단에 하나가 나타났을 때, 그것이 정상인지 판단할 수 있는 내장 방법이 없습니다.
그 격차를 NetMute가 메웁니다. 실시간으로 앱별 및 프로세스별 트래픽을 보여주며, 도메인 수준의 로그는 각 프로세스가 어떤 도메인에 접속했는지와 얼마나 많은 데이터가 이동했는지 기록합니다. 계량된 경우, 앱별 데이터 제한은 실용적인 도구입니다: 하루 또는 한 달 동안 프로세스별 제한, 선택한 임계값에서의 경고, 100%에 도달했을 때의 자동 차단, 글로벌 제한이 상단에 있으며 네트워크 프로필별로 저장된 제한으로, 핫스팟 규칙이 집 규칙과 다르도록 합니다. 프로필은 연결하는 Wi-Fi 네트워크에 따라 자동으로 전환되며, 앱별 방화벽은 한 번 클릭으로 통신해서는 안 되는 것을 차단하고, 테스트를 위한 임시 규칙도 만료됩니다.
목표는 더 차단하는 것이 아닙니다. cloudd가 보여주듯, Mac의 대부분 백그라운드 트래픽은 정당합니다. 목표는 차이를 구별할 수 있는 능력을 갖추고, 연결이 제한된 경우 그 안에서 유지하는 것입니다.