peopled가 macOS Tahoe에서 Mac CPU를 고정시키나요? 대개 연락처 위젯 때문입니다

Q: peopled는 악성코드인가요?

아닙니다. 봉인된 시스템 볼륨의 /System/Library/PrivateFrameworks/People.framework/peopled에 있는, 서명된 Apple 데몬입니다. 이 이름의 프로세스가 다른 위치에서 실행된다면 조사해 볼 가치가 있겠지만, 이것은 Apple의 것입니다.

Q: 그냥 강제 종료해도 되나요?

sudo killall peopled는 다음 이벤트가 이를 깨울 때까지만 멈추게 하며, 사용량이 많은 Mac에서는 그 시점이 몇 초 뒤일 수 있습니다. 진단 용도로는 유용합니다 — 종료 후에도 CPU가 낮게 유지된다면 촉발 요인이 사라진 것입니다 — 하지만 해결책은 아닙니다.

Q: 위젯을 제거하면 무언가 잃게 되나요?

위젯만 잃습니다. 연락처, 통화 기록, Spotlight와 메시지의 제안 기능은 모두 그대로 작동하며, peopled도 필요할 때는 계속 실행됩니다. 다만 새로고침할 수 없는 대상을 새로고침하라는 요청을 더 이상 받지 않을 뿐입니다.

peopled 또는 contactsd가 Tahoe 업데이트 후 CPU 70–180%에 멈춰 있고 Mac이 뜨거워지며 배터리가 빨리 닳나요? 원인은 통화 기록을 읽지 못하는 연락처 위젯입니다. 효과가 있는 해결법을 소개합니다.

Mac이 아무 작업도 하지 않는데 뜨겁습니다. 배터리 예상 사용 시간은 절반으로 줄었습니다. 활동 모니터를 열어 CPU 기준으로 정렬하면 맨 위에 한 번도 들어본 적 없는 프로세스 — peopled — 가 70~80퍼센트를 차지한 채 내려오지 않습니다. 혹은 contactsd일 수도 있습니다. 가장 심각하게 영향을 받은 기기에서는 accountsd가 180%를 차지하고 그 뒤로 contactsd와 itunescloudd가 따라붙기도 합니다. 종료해도 소용없습니다. 애초에 종료할 수가 없기 때문입니다. 재시동하면 한 시간 정도는 나아집니다.

이 문제는 3월 macOS Tahoe 26.4부터 Mac 사용자들에게 발생해 왔고, 26.5와 26.6에서도 여전히 발생하고 있으며, Apple은 이를 인정하지 않았습니다. 그리고 검색 결과 상위에 오르는 「Mac을 재시동하라 / NVRAM을 재설정하라」류의 글에는 가장 확실한 해결책이 나와 있지 않습니다. 바로 위젯을 제거하는 것입니다.

이 가이드는 peopled가 무엇인지(직접 내부를 들여다보았습니다), 왜 위젯이 이를 루프에 빠뜨리는지, 존재하는 줄도 몰랐던 폴더에 걸린 격리(quarantine) 플래그가 어떻게 또 다른 원인이 되는지, 그리고 어떤 순서로 해결책을 시도해야 하는지를 설명합니다.

핵심 요약

peopled는 연락처 위젯의 배후에 있는 데몬입니다. 바이너리 자체에 WidgetSuggester, WidgetConfigurationReader, CallHistoryFetcher라는 이름의 클래스가 들어 있고, 샌드박스 프로파일은 이 데몬에 통화 기록 데이터베이스 접근 권한을 부여합니다. 이 조합이 바로 루프의 원인입니다.
해결책 1: 모든 연락처 위젯을 제거합니다 — 데스크탑, 알림 센터, 제어 센터 모두에서 — 그런 다음 재시동합니다. Apple 커뮤니티 포럼에 확인된 54건 이상의 사례 중 대다수가 이 방법으로 해결되었습니다.
해결책 2: ~/Library/Application Support/CallHistoryDB의 격리 플래그를 해제하고 peopled를 종료합니다. 제거할 위젯이 없을 때 쓰는 해결책이며, 터미널에 전체 디스크 접근 권한이 필요합니다.
해결책 3: iCloud 연락처를 껐다가 다시 켭니다. 일부 사용자에게만 효과가 있으며, 꺼져 있는 동안에는 동기화가 되지 않는다는 대가가 따릅니다.
Exchange나 Google 계정에서 contactsd가 치솟는 것은 증상은 같지만 별개의, 더 오래된 버그입니다. 해결책도 다릅니다 — 계정을 제거하거나 서드파티 클라이언트를 사용하세요.
Apple은 해결책을 문서화하지 않았습니다. 26.4.1, 26.5, 26.6, 26.6.x 릴리스 노트 어디에도 이 문제는 언급되지 않으며, 26.5 이후에도 관련 보고가 계속되고 있습니다.

정확히 어떤 프로세스인가

이 보고들에는 세 개의 데몬이 등장하며 서로 바꿔 부를 수 있는 것이 아닙니다. 활동 모니터를 % CPU 기준으로 정렬해 자신이 어떤 경우에 해당하는지 확인하세요.

프로세스	소속	전형적인 증상	가장 유력한 원인
`peopled`	People 프레임워크 — 위젯 제안, 가족 공유, 스크린 타임, 상태	26.4부터 70~80%로 지속	연락처 위젯 + 읽을 수 없는 CallHistoryDB
`contactsd`	Contacts 프레임워크 — 주소록 데이터베이스와 동기화	60~90초마다 80%로 치솟거나 지속	iCloud/Exchange/Google 연락처 동기화 루프
`accountsd`	Accounts 프레임워크 — 로그인된 모든 계정	`contactsd`, `itunescloudd`와 함께 180%	계정 인증 루프; 로그아웃 해결책도 잘 안 통함

peopled라면 위젯 섹션부터 시작하세요. contactsd 단독이라면 동기화 계정 섹션으로 바로 넘어가세요. accountsd를 포함해 세 개 모두라면, 가장 이해가 덜 된 변종에 해당하며 해당 섹션에서 알려진 바가 얼마나 적은지 솔직하게 다룹니다.

`peopled`가 실제로 하는 일

이름만 보면 연락처와 관련된 것 같고, 이를 언급하는 몇 안 되는 가이드들도 「연락처 데이터를 관리한다」라고 설명합니다. 대체로 맞지만 구체적으로는 틀린 설명이며, 그 차이가 바로 해결책이 주소록 복구가 아니라 위젯인 이유입니다.

26.5.2를 실행 중인 Mac에서 이 데몬을 직접 들여다보았습니다. /System/Library/PrivateFrameworks/People.framework/peopled에 위치하며, 이 데몬의 launchd 작업(/System/Library/LaunchAgents/com.apple.peopled.plist)을 보면 무엇이 이를 깨우는지 알 수 있습니다. 로그인 시 로드되지 않습니다 — RunAtLoad가 false로 설정되어 있습니다. 대신 다음 이벤트들로 실행됩니다:

missedCall, unreadMessage, readMessage, location, dndAvailability, screenTimeRequest, askToBuyRequest, childState에 대한 Biome 스트림
시스템 알림 두 가지: __ABDataBaseChangedByOtherProcessNotification(주소록이 변경됨)과 _CalDatabaseChangedNotification(캘린더가 변경됨)

즉 부재중 전화 하나, 메시지 하나, 연락처 수정 하나, 캘린더 변경 하나마다 peopled가 깨어납니다. 그렇다면 깨어난 뒤에는 무엇을 할까요? 바이너리 안의 문자열이 이를 직접 알려줍니다. Swift 클래스 이름 중에는 다음이 있습니다:

_TtC7peopled15WidgetSuggester
_TtC7peopled18CallHistoryFetcher
_TtC7peopled25WidgetConfigurationReader

그리고 로그 메시지 템플릿 중에는 다음이 있습니다:

Event triggered widget refresh: %{private}s, %s
Last widget suggestion date is older 24 hours, suggest widgets
Last widget suggestion date is within 24 hours, do not suggest widgets
error reading widgets configurations: %s
Failed to suggest widgets with error: %s

이 데몬은 Contacts 프레임워크, CallHistory 프레임워크, 그리고 두 개의 Biome 프레임워크와 링크되어 있습니다. 코드 자체가 설명하는 바에 따르면, 이 데몬의 목적은 최근 통화와 메시지를 신호로 삼아 연락처 위젯과 사람 관련 제안에 어떤 사람을 노출할지 결정하는 것입니다.

바로 이 점이 장애 양상을 설명해 줍니다. 모든 통화와 메시지에 깨어나고, 위젯을 새로고침하는 것이 임무이며, 그러려면 통화 기록을 읽어야만 하는 데몬이라는 것입니다.

왜 루프에 빠지는가

커뮤니티 스레드에서 나온 조각들을 바이너리가 말해주는 내용과 나란히 놓아 보겠습니다.

peopled는 샌드박스 안에서 실행됩니다. /System/Library/Sandbox/Profiles/com.apple.peopled.sb에 있는 프로파일은 (deny default)로 시작한 다음 특정한 문들을 열어 둡니다. 그중 두 개는 다음과 같습니다:

(home-subpath "/Library/CallHistoryDB/")
(home-subpath "/Library/Logs/CallHistory")

따라서 iPhone에서 Continuity를 통해 주고받은 통화 기록 데이터베이스가 저장되는 ~/Library/Application Support/CallHistoryDB/를 읽을 수 있습니다. 이 폴더는 TCC로도 보호되어 있습니다 — 테스트한 Mac에서는 터미널에 전체 디스크 접근 권한을 부여하기 전까지 이 폴더에 ls를 실행하면 Operation not permitted가 반환되었습니다 — 그래서 아래의 해결책들이 이 권한을 필요로 하는 것입니다.

이제 실제 보고들을 살펴보겠습니다. 4월 21일 Apple 커뮤니티 스레드의 한 사용자는 peopled가 계속 돌아가고 있을 때 콘솔에서 발견한 커널 메시지를 인용했습니다:

Sandbox: peopled … deny(1) file-read-data ~/Library/Application Support/CallHistoryDB

그리고 5월 20일 다른 사용자는 다음을 인용했습니다:

failed to open /Users/[user]/Library/Application Support/CallHistoryDB: 1 (Operation not permitted)

이 모든 것에 부합하는 해석은 다음과 같습니다. 연락처 위젯이 설치되어 있어 peopled가 이를 새로고침하라는 요청을 받습니다. 새로고침하려면 통화 기록을 가져와야 합니다. 그런데 이 요청이 거부됩니다 — 폴더에 com.apple.quarantine 속성이 붙었거나, 보고들이 정확히 짚어내지 못한 다른 권한상의 이유 때문입니다 — 새로고침은 실패하고, 다음 이벤트(혹은 재시도)가 다시 이를 촉발합니다. 부재중 전화 한 통 뒤에 밀리초 단위로 끝나야 할 데몬이 대신 계속 실행되는 것입니다.

여기서 무엇이 확인된 사실이고 무엇이 아닌지는 명확히 하고 싶습니다. 클래스 이름, 샌드박스 규칙, 로그 메시지는 직접 관찰 가능한 것들이며 실제로 확인했습니다. 루프가 「위젯 새로고침 → 읽기 거부 → 재시도」라는 것은 지금까지 본 모든 보고와 실제로 효과가 있는 두 가지 해결책 모두에 들어맞는 추론입니다. Apple은 이 메커니즘을 확인해 준 적이 없으며, 두 번째 촉발 요인이 있을 수도 있습니다 — 한 사용자는 연락처 위젯이 전혀 없는 상태에서 제어 센터를 재구성한 뒤 루프가 시작되었다고 보고했습니다.

아무것도 바꾸기 전에 먼저 확인하기

2분만 살펴보면 한 시간 동안 헤매는 것을 피할 수 있고, CPU 사용 패턴이 어떤 해결책을 써야 할지 알려줍니다.

패턴을 관찰하세요. 활동 모니터에서 해당 프로세스를 선택하고 창 하단의 CPU 사용 내역을 보거나, 터미널에서 다음을 실행합니다:

top -stats pid,command,cpu,time -o cpu -n 5

peopled가 70~80%에서 평평하게 유지된다면 위젯 루프입니다. contactsd가 치솟았다가 0으로 떨어지고 1분 뒤 다시 치솟는다면 동기화 루프입니다. 세 데몬 모두에서 동시에 CPU가 지속된다면 계정 변종입니다.

얼마나 오래 실행 중인지 확인하세요. peopled는 보통 몇 초만 살아 있습니다. 정상인 테스트 Mac에서는 41일째 상주하면서도 CPU 사용량은 0.0%였습니다 — 상주하되 유휴 상태라면 문제없습니다. 찾아야 할 것은 상주하면서 바쁜 상태입니다:

ps -axo pid,etime,pcpu,comm | grep -E "peopled|contactsd|accountsd"

거부 로그를 찾으세요. 이것이 결정적인 테스트입니다. 두 번째 터미널 창을 열고 데몬이 계속 돌아가는 동안 로그를 스트리밍합니다:

log stream --predicate 'process == "peopled"' --info

그리고 첫 번째 창에서는 커뮤니티 보고들이 인용한 샌드박스 로그 줄을 최근 몇 분 동안 검색합니다:

log show --last 10m --predicate 'eventMessage CONTAINS "Sandbox: peopled"'

CallHistoryDB에 대해 deny(1) file-read-data가 보인다면 CallHistoryDB 변종이며 해결책 2가 통할 것입니다. 거부 없이 Event triggered widget refresh가 반복해서 나타난다면 해결책 1부터 시작하세요. 로그는 조용한데 CPU는 높다면, 기본 레벨에서는 로그를 남기지 않는 코드에서 루프가 발생하는 것입니다. 그래도 순서대로 해결책을 시도해 보세요.

확실히 하고 싶다면 파일 시스템을 관찰하세요. fs_usage는 프로세스가 시도하는 모든 파일 작업을 보여주며, 실패한 것들도 포함됩니다:

sudo fs_usage -w -f filesys peopled

CallHistoryDB에 대한 시도가 오류를 반환하며 화면을 가득 채운다면, 그것이 바로 실시간으로 보이는 루프입니다.

해결책 1: 연락처 위젯 제거하기

가장 많이 확인된 해결책이며, 되돌리기 쉽고 터미널이 필요 없기 때문에 가장 먼저 시도해야 할 방법입니다.

까다로운 점은 Tahoe Mac에서 위젯이 존재할 수 있는 위치가 세 곳이라는 것이며, 이 세 곳 모두에서 제거해야 한다는 것입니다.

데스크탑

배경화면을 Control 키를 누른 채 클릭하고 위젯 편집을 선택합니다. 편집 모드에서는 데스크탑의 연락처 위젯에 제거 버튼(모서리의 마이너스 기호)이 나타나며, 이를 클릭합니다. 또는 위젯 자체를 Control 키를 누른 채 클릭하고 위젯 제거를 선택해도 됩니다. 완료를 클릭합니다.

알림 센터

메뉴 막대의 날짜와 시간을 클릭해 알림 센터를 열고, 맨 아래로 스크롤한 다음 위젯 편집을 클릭합니다. 같은 방식으로 연락처 위젯을 제거합니다 — Control 키를 누른 채 클릭하고 위젯 제거를 선택하거나, Option 키를 누른 채 제거 버튼을 클릭합니다.

제어 센터

이 위치는 놓치기 쉽습니다. Tahoe에서 위젯이 제어 센터로 옮겨졌고, 이에 대한 사용자 지정은 시스템 설정에 있지 않기 때문입니다. 메뉴 막대의 제어 센터 아이콘을 클릭하고 제어 편집을 선택한 다음, 연락처 관련 항목을 제어 센터 밖으로 드래그합니다. 완료를 클릭합니다.

그런 다음 재시동하세요 — 로그아웃만으로는 안 됩니다. 스레드에서 확인된 여러 사례들은 완전히 재시동한 뒤에야 CPU가 떨어졌다고 밝히고 있습니다.

같은 스레드에서 7월 31일에 보고된 추가 주의사항이 있습니다. 일부 사용자는 연락처 위젯을 다시 추가하지 않고 위젯 갤러리를 열기만 했는데도 루프가 재발했다고 합니다. 이 문제를 겪은 적이 있다면, Apple이 데몬을 고칠 때까지 위젯 편집기 자체를 피해야 할 대상으로 취급하세요.

해결책 2: CallHistoryDB의 격리 플래그 해제하기

연락처 위젯이 어디에도 없거나, 위젯을 제거해도 효과가 없었던 Mac의 경우, 이 방법은 스레드에서 가장 기술적으로 상세했던 보고가 5월 20일에 도달한 해결책이며, 최소 두 명의 다른 사용자도 이를 확인했습니다(6월 26일 한 사용자는 「peopled 프로세스가 이제 CPU 사용량 0%가 되었다」고 적었습니다).

1단계: 터미널에 전체 디스크 접근 권한 부여하기

시스템 설정 > 개인정보 보호 및 보안 > 전체 디스크 접근 권한으로 이동해 터미널을 추가하고 켭니다. 이 권한이 없으면 아래의 모든 명령이 「Operation not permitted」로 실패합니다 — 공교롭게도 이는 peopled가 맞닥뜨리는 것과 같은 오류입니다. 권한을 부여한 뒤에는 터미널을 재시작하세요.

2단계: 폴더 살펴보기

ls -lan@ "$HOME/Library/Application Support/CallHistoryDB"

@ 플래그는 확장 속성을 보여줍니다. 찾아야 할 것은 이 폴더나 그 안의 CallHistory.storedata 파일들에 붙은 com.apple.quarantine입니다. 격리(quarantine)는 macOS가 다운로드한 파일에 붙이는 플래그로, 시스템 데이터베이스에 붙어 있을 이유가 없으며, 어떻게 거기에 붙게 되는지는 알려져 있지 않습니다 — 백업에서 복원했거나 다른 Mac에서 마이그레이션한 것이 유력한 두 가지 경로입니다.

3단계: 제거하기

xattr -dr com.apple.quarantine "$HOME/Library/Application Support/CallHistoryDB"

-d는 속성을 삭제하고, -r은 폴더 내부까지 재귀적으로 적용합니다.

4단계: 데몬 재시작하기

sudo killall -9 peopled CallHistorySyncHelper

둘 다 필요할 때 다시 실행됩니다. 몇 분간 활동 모니터를 지켜보세요.

플래그가 다시 나타난다면

스레드의 한 사용자는 7월 17일 이 해결책이 통했지만 격리 플래그가 밤사이 「다시 나타났다」고 보고했습니다. 이런 일이 생긴다면 무언가가 폴더를 다시 격리 상태로 만들고 있는 것이며, 후보로는 이를 새 데이터로 취급하는 백업 도구나 동기화 도구가 있습니다. 야간에 무엇이 실행되는지 확인하세요. 아니면 더 직설적으로, 다른 사용자는 데이터베이스를 아예 삭제해서 macOS가 다시 만들도록 하는 방식을 택했습니다:

rm -rf ~/Library/Application\ Support/CallHistoryDB

이렇게 하면 Mac에 있던 통화 기록 사본이 사라집니다. Continuity를 통해 iPhone에서 다시 채워집니다. 이는 속성을 제거하는 것보다 더 강한 조치이므로, 먼저 속성 제거부터 시도하는 것을 권합니다.

해결책 3: iCloud 연락처 껐다 켜기

시스템 설정 > [사용자 이름] > iCloud > iCloud에 저장됨 > 연락처를 끕니다. 1분 정도 기다리며 CPU를 지켜봅니다. 떨어진다면 다시 켜고 그대로 낮게 유지되는지 확인합니다.

이 방법은 일부 사용자에게만 효과가 있으며, 몇 년 전으로 거슬러 올라가는 이전 스레드들에서도 표준적으로 권장되어 온 조치입니다. 한 사용자가 5월 11일에 겪은 실패 사례도 있습니다. 토글 자체가 꺼지지 않았다는 것입니다. 이런 일이 생기면 iCloud에서 완전히 로그아웃하고(물어볼 때 데이터 사본을 남기는 옵션을 선택), 재시동한 다음 다시 로그인하세요. accountsd 변종을 겪은 V2EX 제보자도 정확히 이 방법을 시도했지만, 로그인 직후 CPU가 곧바로 다시 치솟았다는 점은 참고할 만합니다.

`contactsd`이고 Exchange나 Google 계정을 사용 중이라면

이 문제는 Tahoe 이전부터 있었으며 원인 메커니즘이 더 명확합니다.

contactsd는 Contacts 프레임워크의 데몬으로, 주소록 데이터베이스를 소유하고 연락처를 동기화하는 모든 계정과 이를 조정합니다. 일정에 따른 유지보수 작업도 수행합니다 — 이 데몬의 launchd 작업은 외부 전원 연결 상태이고 사용자가 비활성 상태일 때만 실행되는 일일 validate-cache 작업과, 반복되는 accounts.cleanup 활동을 등록합니다. contactsd가 가끔 짧게 CPU를 사용하는 것은 정상입니다.

정상이 아닌 것은 1분 간격 정도로 반복되는 급등입니다. 한 개발자가 2025년 12월 Apple Developer Forums에 정확히 이 현상을 기록했습니다. Tahoe 26.1의 M1 Max에서, 연락처가 활성화된 Office 365 계정이 AddressBookManager를 81%까지, contactsd를 22~~59%까지 60~~90초마다 반복적으로 치솟게 만들었습니다 — 서버 쪽 Exchange 연락처 폴더를 비운 상태에서도, 그리고 클린 설치에서도 재현되었습니다. 같은 계정과 데이터를 M4 Mac이나 iOS에서 사용했을 때는 이런 현상이 없었습니다. Apple 쪽에서는 아무도 답변하지 않았습니다.

그가 찾은, 실제로 통하는 우회책은 시스템 설정 > 인터넷 계정에서 Exchange 계정을 제거하는 것이며, 그 계정이 필요하다면 Contacts 프레임워크를 거치지 않는 Outlook을 사용하는 것입니다. 26.3의 2024년형 MacBook Pro에서 contactsd 문제를 겪은 2월의 커뮤니티 포럼 보고에도 같은 조언이 붙었습니다 — Exchange와 Google에서 연락처 동기화를 중단하고 테스트해 보라는 것입니다 — 그리고 iCloud와 Google 계정 모두 연락처를 동기화하고 있다면 Google부터 끊어 보세요.

`accountsd` 변종

가장 심각한 보고는 — 26.5.2의 M5 MacBook Air에서 accountsd가 180%에 contactsd와 itunescloudd까지 함께 치솟는 사례로, 7월 V2EX에 게시되었습니다 — 아직 확인된 해결책이 없습니다. 제보자는 매일 아침 같은 시각에 시작된다고 언급했는데, 이는 위젯 이벤트보다는 예약된 작업을 가리킵니다. 로그아웃 후 재로그인도 도움이 되지 않았습니다.

덧붙이자면, accountsd는 Accounts 프레임워크 데몬으로 로그인된 계정의 자격 증명이 필요할 때마다 호출되며, itunescloudd는 iTunes Cloud(Apple Music / Store) 라이브러리 데몬입니다. 세 개가 동시에 나타난다는 것은 무언가가 계정 자격 증명을 반복적으로 요청했다가 실패하고 있다는 뜻입니다. 이 변종을 겪고 있다면 위의 해결책들을 순서대로 시도해 볼 가치는 여전히 있으며, 그래도 통하지 않는다면 시스템 설정 > 인터넷 계정에서 오래된 Google이나 Exchange 로그인, 만료된 앱 전용 암호 같은 특정 계정 하나가 인증에 실패하고 있지는 않은지 확인해 볼 만합니다. 경고 배지가 표시된 항목은 모두 제거하세요.

왜 Tahoe에서, 왜 위젯인가

위젯은 Mac에서 수년간 존재해 왔으니, 왜 하필 26.4부터 이 문제가 시작되었는지 물어보는 것은 타당합니다. 두 가지가 동시에 바뀌었습니다.

첫 번째는 위젯이 위치하는 장소입니다. Tahoe는 데스크탑, 알림 센터와 더불어 제어 센터에도 위젯을 넣었고, 제어 센터의 연락처 위젯은 데스크탑에 있는 것과는 다른 주기로 새로고침됩니다 — 데몬 자체의 로그 템플릿을 보면 일일 「위젯 제안」 패스(「Last widget suggestion date is older 24 hours」)와 이벤트로 촉발되는 새로고침(「Event triggered widget refresh」)을 구분하고 있습니다. 표면이 많아질수록 새로고침 요청도 많아지고, 실패한 요청이 재시도될 기회도 늘어납니다.

두 번째는 이 데몬의 오류 처리 방식이 물러서기보다는 재시도하는 것처럼 보인다는 점입니다. 이는 동작을 관찰해서 내린 추론이지 바이너리에서 직접 읽어낸 것은 아니며, 바로 이것이 실제 버그입니다. 읽기가 거부되면 한 번 로그를 남기고 다음 진짜 이벤트가 올 때까지 새로고침을 포기해야 합니다. 그런데 대신 다시 시도되고, 그 사이 이벤트는 계속 들어옵니다.

이 두 가지 모두 사용자가 바꿀 수 있는 것이 아닙니다. 사용자가 바꿀 수 있는 것은 위젯이 존재하는지, 읽기가 거부되는지이며, 이것이 바로 세 가지 해결책이 다루는 부분입니다.

해결한 뒤에

몇 가지를 지키면 재발을 막을 수 있습니다.

해결책 2를 사용했다면 터미널의 전체 디스크 접근 권한을 그대로 두거나, 의도적으로 회수하세요 — 둘 다 괜찮지만, 어느 쪽을 택했는지는 알고 있어야 합니다. 전체 디스크 접근 권한이 있는 터미널은 광범위한 권한이기 때문입니다.

당분간 위젯 갤러리를 피하세요. 스레드의 7월 31일 보고는 무언가를 추가한 것이 아니라 갤러리를 열기만 해도 루프가 재시작되었다고 구체적으로 밝혔습니다. 다른 위젯을 추가하고 싶다면 추가한 뒤 활동 모니터를 확인해 보세요.

다음 macOS 업데이트 후에는 다시 확인하세요. 마이너 업데이트가 일부 사용자에게 제어 센터의 기본 항목을 다시 추가한 사례가 있으며, 연락처 위젯이 조용히 되돌아오는 것이 문제가 재발하는 가장 유력한 이유입니다.

리포트를 제출하세요. Feedback Assistant에서 카테고리를 macOS로 선택하고, CPU가 높을 때 채취한 sysdiagnose(터미널에서 sudo sysdiagnose, 또는 Shift-Control-Option-Command-Period)를 첨부한 다음, 샌드박스 거부 로그 줄을 붙여 넣으세요. 다섯 달에 걸친 포럼 스레드들은 이 문제를 움직이지 못했지만, 같은 로그 줄이 담긴 수백 건의 Feedback 리포트라면 움직일 수도 있습니다.

아직 고쳐지지 않았나요?

현재까지 알려진 바로는 아닙니다. Apple의 Tahoe 업데이트 노트를 확인해 보면, 26.4.1은 「버그 수정을 제공한다」, 26.5는 「기능 개선, 버그 수정, 보안 업데이트를 포함한다」, 26.6은 Spotlight 인덱스를 최적화하며, 26.6.1과 26.6.2는 보안 릴리스입니다. 어디에도 연락처, 위젯, CPU는 언급되지 않습니다. 커뮤니티 스레드에서는 26.5에서도(5월 15일 「Tahoe 26.5에서도 문제가 여전히 있다. Apple은 이를 빨리 고쳐야 한다」) 7월까지 계속 보고가 이어지고 있습니다. 8월 17일에 출시된 26.6.2에 대해서는 문제가 있다거나 없다는 보고를 아직 보지 못했습니다.

macOS 27 베타를 사용 중이며 이 문제를 겪었거나 겪지 않았다면, 베타 알려진 문제 정리 글에서 계속 추적하고 있습니다.

굳이 시도할 필요 없는 것들

NVRAM이나 SMC 재설정. 둘 다 사용자 공간 데몬의 파일 권한과는 아무 관련이 없습니다. 건너뛰세요.

tccutil reset All. 한 사용자가 시도했지만 도움이 되지 않았고, Mac의 모든 앱에서 모든 개인정보 보호 권한이 초기화되어 오후 시간을 들여 하나하나 다시 부여해야 했습니다. TCC가 문제의 원인이라고 볼 근거는 없습니다 — 로그에 나오는 거부는 TCC가 아니라 샌드박스입니다.

안전 모드. 안전 모드로 부팅했다가 돌아오면 일부 캐시가 지워지고 몇몇 사용자에게 일시적인 완화 효과를 주었습니다. 이는 단계가 좀 더 많은 재시동일 뿐 원인을 해결하지는 않습니다.

launchctl로 peopled 비활성화하기. 이 에이전트를 launchctl disable로 끌 수는 있으며, 그러면 아예 실행되지 않으므로 CPU도 사용하지 않습니다. 다만 연락처 위젯, 사람 제안, 스크린 타임의 「구매 요청」 관련 배관, 그 밖에 이 데몬에 의존하는 모든 기능도 함께 멈추며, 시스템 무결성 보호가 적용된 Mac에서는 이 변경이 업데이트 후에도 유지되지 않을 수 있습니다. 최후의 진단 수단이 아니라면 권장하지 않습니다.

자주 겪는 문제 해결하기

활동 모니터에 `contactsd`가 스무 개나 보입니다

이 글을 쓰는 동안 직접 목격했습니다. 연속된 PID를 가진 스무 개의 contactsd 프로세스가 한꺼번에 나타났는데, 모두 launchd의 자식 프로세스였고, 모두 CPU 0%였으며, 1분 안에 사라졌습니다. 이는 launchd가 클라이언트별로 인스턴스를 필요할 때마다 생성하는 것으로, 버그가 아닙니다. 버그는 CPU가 높은 상태로 계속 남아 있는 프로세스 하나입니다.

연락처 위젯을 지웠는데도 `peopled`가 여전히 80%입니다

세 곳 — 데스크탑, 알림 센터, 제어 센터 — 을 모두 확인한 다음 해결책 2로 넘어가세요. 애초에 연락처 위젯을 사용한 적이 없다면 바로 해결책 2로 가세요.

`xattr`이 「No such xattr: com.apple.quarantine」라고 나옵니다

폴더가 격리 상태가 아니므로 그것이 원인은 아닙니다. 해결책 3을 시도하고, Exchange나 Google 계정이 연락처를 동기화하고 있지는 않은지 확인하세요.

`sudo`를 붙여도 CallHistoryDB에 `ls`를 실행하면 「Operation not permitted」가 나옵니다

sudo는 TCC를 우회하지 못합니다. 터미널 자체에 시스템 설정에서 부여한 전체 디스크 접근 권한이 필요하며, 그 후 다시 실행해야 합니다.

macOS 업데이트 후 다시 재발했습니다

업데이트가 제어 센터의 기본 레이아웃에 위젯을 다시 추가할 수 있습니다. 세 위치를 다시 확인하세요.

자주 묻는 질문

`peopled`는 악성코드인가요?

아닙니다. 봉인된 시스템 볼륨의 /System/Library/PrivateFrameworks/People.framework/peopled에 있는, 서명된 Apple 데몬입니다. 이 이름의 프로세스가 다른 위치에서 실행된다면 조사해 볼 가치가 있겠지만, 이것은 Apple의 것입니다.

그냥 강제 종료해도 되나요?

sudo killall peopled는 다음 이벤트가 이를 깨울 때까지만 멈추게 하며, 사용량이 많은 Mac에서는 그 시점이 몇 초 뒤일 수 있습니다. 진단 용도로는 유용합니다 — 종료 후에도 CPU가 낮게 유지된다면 촉발 요인이 사라진 것입니다 — 하지만 해결책은 아닙니다.

위젯을 제거하면 무언가 잃게 되나요?

위젯만 잃습니다. 연락처, 통화 기록, Spotlight와 메시지의 제안 기능은 모두 그대로 작동하며, peopled도 필요할 때는 계속 실행됩니다. 다만 새로고침할 수 없는 대상을 새로고침하라는 요청을 더 이상 받지 않을 뿐입니다.

CallHistoryDB 폴더를 읽으려면 왜 전체 디스크 접근 권한이 필요한가요?

통화 기록이 들어 있기 때문입니다. macOS는 이를 민감한 개인정보로 취급해 메시지, Mail과 마찬가지로 TCC로 보호합니다. 이런 보호 때문에 터미널에 권한 부여가 필요한 것이며, 예기치 않은 격리 플래그가 이렇게 큰 문제를 일으키는 이유이기도 합니다. 데몬은 이 데이터에 접근할 수 있는 좁고 샌드박스로 제한된 경로가 단 하나뿐이며, 그 경로를 막는 것은 무엇이든 접근을 완전히 차단해 버립니다.

macOS 27에서는 고쳐질까요?

알 수 없습니다. Apple은 이 문제를 인정한 적이 없고, 베타 릴리스 노트에도 관련 내용이 전혀 없습니다. 만약 지금까지의 증거가 시사하는 메커니즘이 맞다면, 수정 자체는 작은 것입니다 — 한 번 실패하면 재시도를 멈추는 것 — 그리고 언급 없이 어느 마이너 릴리스에서든 조용히 들어올 수 있습니다.

결론

아무 일도 하지 않는데 뜨거워지는 Mac은 거의 항상 루프에 빠진 프로세스 하나가 원인이며, 그 루프의 원인은 거의 항상 평범한 것입니다. 이번 경우는 위젯을 최신 상태로 유지하는 것이 임무이고, 모든 통화와 메시지에 깨어나며, 필요한 단 하나의 데이터베이스를 읽지 못하는 데몬이 원인이었습니다. 위젯을 제거하면 요청이 멈추고, 폴더 권한을 고치면 읽기가 성공합니다. 둘 중 어느 쪽이든 루프를 끊습니다.

활동 모니터 맨 위에 peopled가 있다면 세 가지 해결책을 순서대로 시도하고 그 사이마다 재시동하세요. Exchange나 Google 계정과 함께 contactsd가 문제라면 해당 계정을 제거하세요. 그리고 accountsd가 맨 앞에서 셋 다 함께 나타난다면, 위의 모든 방법을 시도하고 경고가 표시된 계정을 제거한 다음 — Apple이 다섯 달째 이 문제에 침묵하고 있으니 — 샌드박스 로그 줄을 첨부한 Feedback 리포트를 제출하세요. 그것이 마침내 이 문제를 고치게 만들 수도 있습니다.