Mac에서 cloudd가 무엇인가요? iCloud 동기화 데몬 설명

cloudd는 CloudKit 데몬입니다. macOS가 앱을 대신해 Apple의 iCloud 서버와 통신할 때 사용하는 프로세스죠. macOS에 기본 포함된 표준 구성 요소이며, Apple이 배포하고 코드 서명한 것으로, 악성코드가 아닙니다.

CloudKit은 앱 데이터를 iCloud에 저장하고 사용자의 기기들 사이에서 일관성을 유지하는 Apple의 프레임워크입니다. 앱이 동기화를 위해 직접 연결을 여는 것이 아니라 데이터를 CloudKit에 넘기면, cloudd가 변경 내용을 업로드하고 다른 기기에서 바뀐 내용을 가져오며 실패한 요청을 다시 시도합니다.

생각보다 많은 것이 여기에 얹혀 있습니다. iCloud Drive 문서 동기화도 그렇고, Notes도 마찬가지이며, Photos는 라이브러리 메타데이터에 이를 사용합니다. Apple 자체 앱의 상당수는 Mac, iPhone, iPad 사이에서 일관성을 유지하는 데 이것을 활용하고, 많은 서드파티 앱도 마찬가지입니다. CloudKit은 개발자가 자체 서버를 둘 필요가 없어서 인기 있는 동기화 백엔드입니다.

그래서 cloudd가 활성화되어 있다면, 거의 항상 시스템, Apple 앱, 또는 설치한 어떤 것의 iCloud 동기화가 진행 중인 것입니다.

이것이 cloudd에 대해 이해하는 데 가장 유용한 점이자, 거의 모든 혼란의 원천이야.

cloudd는 공유 택배원이야. 의미 있는 방식으로 자체 트래픽을 생성하지 않고, 다른 앱들의 데이터를 전달하는 역할을 해. 노트가 변경되거나, 문서가 iCloud Drive에 저장되거나, 서드파티 작업 관리자가 항목을 동기화할 때, 그 바이트들은 네 Mac을 떠나면서 cloudd의 이름으로 가게 되고, 그 데이터를 만든 앱의 이름으로 가지 않아. 네트워크 활동을 프로세스별로 구분하는 도구, Activity Monitor도 마찬가지로, cloudd에 큰 수치를 보여주고, 실제 책임이 있는 앱에는 적은 수치를 보여줄 거야.

그래서 cloudd가 많은 데이터를 사용하는 것은 거의 항상 cloudd 자체에 대한 진술이 아니야. 네 앱들이 얼마나 동기화하는지에 대한 진술이고, 하나의 라인으로 집계된 거지. 동일한 macOS 복사본을 실행하는 두 Mac이 완전히 다른 cloudd 수치를 보여줄 수 있는데, 그 이유는 한 쪽은 큰 Photos 라이브러리와 CloudKit-backed 앱 몇 개를 가지고 있기 때문이야.

macOS는 이 밖에도 nsurlsessiond가 다른 앱들의 백그라운드 다운로드와 업로드를 담당하며, 같은 이유로 무겁게 보여. 패턴을 인지하면, 이름이 일반적인 데몬도 더 이상 경고로 느껴지지 않아. 그것은 보통 파이프이고, 흥미로운 질문은 그 안을 통해 무엇이 전달되고 있는지야.

cloudd는 안전합니다. Apple의 1차 데몬이고, 수년 동안 macOS의 일부였으며, 그 동작은 하는 일로 완전히 설명됩니다. 실제로 걱정해야 할 부분은 진짜 cloudd가 위험한지 여부가 아니라, Mac에서 그 이름으로 실행 중인 프로세스가 진짜인지 여부입니다. 밋밋한 시스템 이름을 가져다 쓰는 것은 오래된 수법이니까요.

특별한 도구 없이도 확인할 수 있습니다. Activity Monitor에서 cloudd를 찾아 두 번 클릭해 인스펙터를 여세요. 진짜 데몬은 홈 폴더, Applications, Downloads가 아니라 읽기 전용 시스템 볼륨 안에 있으며, 사용자가 연 어떤 것에 의해서가 아니라 launchd에 의해 시작됩니다. 사용자 디렉터리에서 실행되는 cloudd라는 프로세스라면 확인해 볼 만한 이상 징후입니다.

더 강력한 확인 방법은 코드 서명입니다. Apple의 시스템 바이너리는 Apple이 서명하며, 최신 macOS에서는 시스템 볼륨이 암호학적으로 봉인되어 있으므로 교체된 시스템 데몬을 일반 소프트웨어가 조용히 꾸며 내기는 어렵습니다. macOS에는 어떤 바이너리든 서명 주체를 보여 주는 명령줄 도구가 포함되어 있고, cloudd는 Apple로 나와야 합니다.

cloudd가 아닌 것이 무엇인지도 말할 필요가 있습니다. 이것은 분석이나 원격 측정 프로세스가 아닙니다. 이미 활성화한 서비스에 대해 앱의 데이터를 iCloud로 옮기고 받아 오는 역할을 합니다.

무거운 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의 대부분 백그라운드 트래픽은 정당합니다. 목표는 차이를 구별할 수 있는 능력을 갖추고, 연결이 제한된 경우 그 안에서 유지하는 것입니다.