Mac에서 ReportCrash CPU 과점유 해결 방법

Mac의 ReportCrash란 무엇인가요?

macOS에서 ReportCrash는 "launchd" 상위 프로세스 하에서 작동하는 내장 충돌 처리기(crash handler)입니다. 앱이나 백그라운드 프로세스가 예기치 않게 종료될 때마다 이 구성 요소가 깨어나 무슨 일이 일어났는지 검사하고 진단 보고서를 디스크에 기록하여 개발자(그리고 때로는 사용자)가 무엇이 잘못되었는지 확인할 수 있게 합니다.

기술적으로 ReportCrash는 두 가지 형태로 실행됩니다:

• 사용자 수준 프로세스를 위한 LaunchAgent: 보고서를
  ~/Library/Logs/DiagnosticReports/ 폴더에 씁니다.
  
• 시스템 및 루트 소유 프로세스를 위한 LaunchDaemon: 보고서를 시스템 전체 진단 로그 디렉터리에 저장합니다.

최신 macOS 버전에서 친숙한 "앱이 예기치 않게 종료되었습니다. Apple로 보내시겠습니까?" 대화 상자는 Problem Reporter를 눈에 보이는 프런트엔드로, ReportCrash가 무대 뒤에서 무거운 작업을 수행하는 더 넓은 보고 스택의 일부입니다.

정상적인 상황에서는 이 활동을 거의 눈치채지 못합니다. 앱이 충돌하고, ReportCrash가 잠시 개입하여 로그를 쓰고 종료합니다. CPU 사용량이 잠시 치솟았다가 다시 0으로 떨어집니다. 이것이 정상적인 작동 방식입니다.

ReportCrash가 CPU를 독점할 수 있는 이유

ReportCrash가 50-300%의 CPU를 소비(멀티코어 시스템에서)하고 활성 상태 보기(Activity Monitor)에 지속적으로 나타난다면, 그것은 거의 결코 실제 범인이 아닙니다. 그것은 메신저일 뿐입니다. 진짜 문제는 빡빡한 루프 안에서 계속 충돌하는 다른 무언가입니다.

일반적인 패턴은 다음과 같습니다:

1. 프로세스가 시작됩니다.
2. 거의 즉시 충돌합니다.
3. launchd가 재시작합니다.
4. ReportCrash가 또 다른 실패를 처리하기 위해 깨어납니다.
5. 이 과정이 쉬지 않고 반복됩니다.

충돌 보고서를 생성하고 압축하는 것은 사소한 작업이 아니기 때문에, 이 루프에 갇힌 프로세스는 ReportCrash를 24시간 내내 바쁘게 만들 수 있습니다. 포럼과 Q&A 사이트의 수많은 사용자 보고서도 같은 이야기를 보여줍니다. 높고 지속적인 ReportCrash CPU 사용량은 거의 항상 멈추지 않고 충돌하고 다시 시작되는 백그라운드 에이전트, 확장 프로그램 또는 프레임워크와 관련이 있습니다.

대표적인 근본 원인들은 다음과 같습니다:

• 손상된 데이터로 인해 질식하는 동기화 및 인덱싱 데몬 (예: 연락처, 제안 또는 검색 관련 서비스)
• macOS 업데이트 후 깨진 타사 메뉴 막대 앱 또는 도우미
• LaunchAgents 또는 LaunchDaemons가 더 이상 존재하지 않는 바이너리를 계속 시작하려고 하는 삭제된 앱의 잔여물
• 테스트 중에 구성 요소가 반복적으로 충돌하는 개발자 도구 또는 시뮬레이터 (Xcode, iOS 시뮬레이터 등)

요컨대, ReportCrash가 시끄러운 이유는 다른 무언가가 아프기 때문입니다. 목표는 그 "무언가"를 찾아 수정하거나 제거하고, 그 후에야 ReportCrash 자체를 건드리는 것을 고려하는 것입니다.

참고로, 이 패턴은 chronod, contactsd, syspolicyd, 그리고 wdavdaemon과 관련된 제가 다룬 다른 높은 CPU 이야기와 매우 유사합니다. 작은 백그라운드 작업자가 탈선하여 시스템 성능을 함께 끌어내리는 경우입니다.

Mac에서 ReportCrash 높은 CPU 사용량을 수정하는 방법

1단계. 루프에서 충돌하는 항목 식별하기

단 한 가지만 해야 한다면 이것을 하십시오. ReportCrash를 과부하 모드로 끌고 가는 프로세스가 무엇인지 알아야 합니다.

1. 콘솔(Console) 열기
   • Command–Space를 누르고 Console을 입력한 후 Return을 누릅니다.
2. 사이드바에서 **충돌 보고서(Crash Reports)**를 찾습니다(또는 "보고서" 아래의 "Crash Reports" 섹션 사용).
3. **날짜(Date)**별로 정렬하고 가장 최근 항목을 확인합니다:
   • 짧은 시간 안에 같은 프로세스 이름이 여러 번 반복되는 것을 볼 수 있을 것입니다.
4. 충돌 보고서가 비어 보이면 다음으로 전환하십세오:
   • system.log 또는 모든 메시지(All Messages), 그리고 crash, Service only와 같은 용어를 검색합니다.

다음 사항을 적어 두십시오:

• 문제가 되는 프로세스 이름 (예: suggestd, 메뉴 막대 앱, 어떤 도우미),
• 보이는 경우 그 경로, 그리고
• 대략 얼마나 자주 충돌하는지.

이것이 당신의 주요 용의자입니다.

2단계. 문제가 되는 앱 또는 구성 요소 제거 또는 복구

무엇이 충돌하는지 알게 되면 가장 좋은 해결책은 일반적으로 해당 항목을 업데이트, 재설정 또는 제거하는 것입니다.

1. 알고 사용하는 일반 앱인 경우:
   • 실행 중이면 종료합니다.
   • 메뉴(보통 앱이름 ▸ 업데이트 확인) 또는 App Store를 통해 업데이트가 있는지 확인합니다.
   • 충돌이 계속되면 깨끗한 재설치를 시도합니다:
     • 앱을 응용 프로그램에서 휴지통으로 드래그합니다.
     • 재부팅합니다.
     • 공식 소스에서 새 복사본을 다운로드하여 다시 설치합니다.
2. 더 이상 신경 쓰지 않는 앱인 경우:
   • 응용 프로그램에서 명백한 보조 도구(제거 프로그램, 업데이터)와 함께 제거합니다.
   • 그런 다음 다음 위치에서 잔여 구성 요소를 확인합니다:
     • ~/Library/Application Support/
     • ~/Library/LaunchAgents/
     • /Library/LaunchDaemons/
   • 해당 앱과 명확하게 관련된 항목(이름 또는 공급업체 일치)만 삭제합니다.

3. 시스템 서비스인 경우 (예: suggestd, 연락처 관련 또는 iCloud 동기화):
   • 관련 기능을 일시적으로 비활성화합니다:
     • 시스템 설정 ▸ 인터넷 계정에서 문제가 있는 계정을 끕니다.
     • iCloud 연락처, Siri 및 Spotlight 제안 또는 유사한 항목과 같은 서비스를 끄고 잠시 기다렸다가 다시 켭니다.
   • 특정 계정이나 기능을 비활성화한 후 CPU 폭풍이 진정된다면, 그곳에 잘못된 데이터가 있을 가능성이 큽니다.

아이디어는 간단합니다. 계속 충돌하는 것이 사라지거나 올바르게 작동하기 시작하면 ReportCrash는 더 이상 쉬지 않고 실행될 이유가 없습니다.

3단계. 비대해진 충돌 로그 및 진단 정리

충돌 루프를 길들인 후에도 시스템에는 수천 개의 오래된 충돌 보고서가 흩어져 있을 수 있습니다. 그들 자체가 일반적으로 CPU 스파이크를 일으키지는 않지만 디스크 공간을 낭비하고 분석을 시끄럽게 만들 수 있습니다.

다음과 같이 안전하게 정리할 수 있습니다:

1. Finder에서 Shift–Command–G를 눌러 **폴더로 이동…**을 엽니다.
2. 다음 위치를 하나씩 방문합니다:
   • ~/Library/Logs/DiagnosticReports/
   • /Library/Logs/DiagnosticReports/ (관리자 권한이 필요할 수 있음)
3. 오래된 .crash 및 .panic 파일을 휴지통으로 이동합니다(백업을 원하면 아카이브 폴더로 이동).
4. 모든 것이 안정적이라고 확신하면 휴지통을 비웁니다.

이것은 근본 원인이 지속되는 경우 ReportCrash CPU 사용을 직접 중지하지는 않지만, Mac을 깔끔하게 유지하고 백그라운드 I/O를 약간 줄일 수 있습니다.

4단계. 문제가 있는 로그인 항목 및 백그라운드 도우미 비활성화

매우 흔한 시나리오는 오랫동안 잊혀진 앱의 로그인 항목 또는 LaunchAgent가 더 이상 존재하지 않는 무언가를 시작하려고 시도하는 것입니다. 그 바이너리는 올바르게 실행되지 않고 즉시 충돌하며 ReportCrash는 스팸을 받습니다.

다음 정리를 수행하십시오:

1. 로그인 항목 확인
   • 시스템 설정 ▸ 일반 ▸ 로그인 항목으로 이동합니다.
   • 로그인 시 열기 및 백그라운드에서 허용 아래에서 인식하지 못하거나 더 이상 사용하지 않는 항목을 비활성화합니다.
2. LaunchAgents 및 LaunchDaemons 검사
   Finder에서 **이동 ▸ 폴더로 이동…**을 사용하고 다음을 살펴봅니다:
   • ~/Library/LaunchAgents/
   • /Library/LaunchAgents/
   • /Library/LaunchDaemons/
   
   
3. 각 폴더에 대해:
   • 이름으로 정렬하고 제거된 앱에 명백히 속하는 항목을 찾습니다.
   • 의심스러운 .plist 파일은 즉시 삭제하는 대신 바탕 화면의 임시 폴더로 이동합니다.
   • 재부팅하고 활성 상태 보기를 관찰하여 ReportCrash가 진정되는지 확인합니다.

며칠 동안 모든 것이 잘 작동하면 격리된 .plist 파일을 안전하게 삭제할 수 있습니다. 중요한 것이 깨지면 다시 이동하십시오.

5단계. 안전 모드에서 테스트

안전 모드는 타사 구성 요소가 관련되어 있는지 확인하는 빠른 방법입니다. 이 진단 모드에서 macOS는 필수 확장 프로그램만 로드하고 대부분의 로그인 항목과 LaunchAgents를 비활성화합니다.

1. Mac을 종료합니다.
2. 켜고 CPU 유형에 맞는 키를 길게 누릅니다:
   • Intel Mac: 시동음 직후 로그인 창이 보일 때까지 Shift를 누르고 있습니다.
   • Apple silicon Mac:
     • "시동 옵션 로드 중"이 나타날 때까지 전원 버튼을 길게 누릅니다.
     • 시동 디스크를 선택하고 Shift를 누른 다음 안전 모드에서 계속을 클릭합니다.
3. 로그인하고 **활성 상태 보기(Activity Monitor)**를 엽니다.

안전 모드에서는 ReportCrash가 조용하지만 일반 재부팅 후 다시 미친 듯이 작동한다면, 타사 소프트웨어(로그인 항목, 커널 확장, 도우미 도구)를 다루고 있을 가능성이 거의 확실합니다. 그 단서를 사용하여 2단계와 4단계를 더 공격적으로 다시 방문하십시오.

6단계. SMC 및 NVRAM 재설정 (고집 센 경우)

ReportCrash와 직접 연결되지는 않지만, 전원 관리나 하드웨어 상태의 낮은 수준의 결함은 때때로 무작위적이고 반복적인 충돌과 시스템 불안정으로 나타납니다. SMC(Intel Mac) 및 NVRAM을 재설정하면 그러한 거미줄을 제거하는 데 도움이 될 수 있습니다.

절차는 Mac 모델에 따라 다르지만 대략적으로는 다음과 같습니다:

• NVRAM 재설정 (Intel Mac):
  1. Mac을 종료합니다.
  2. 켜고 즉시 Option–Command–P–R을 길게 누릅니다.
  3. 약 20초 동안 키를 누르고 있다가 놓습니다.
• SMC 재설정 (Intel Mac):
  배터리 탈착 가능/불가능 MacBook, iMac 및 Mac mini에 따라 단계가 다릅니다. 정확한 모델 및 macOS 버전에 대한 Apple의 지침을 참조하십시오.
  

Apple silicon Mac에는 별도의 SMC 또는 NVRAM 재설정이 없습니다. 깨끗한 종료 및 전원 켜기 순서가 효과적으로 동일한 작업을 수행합니다.

앱 수준 원인을 배제하고 이러한 재설정을 수행한 후에도 ReportCrash의 높은 CPU가 지속되면 "고급 조정" 영역에 있는 것입니다.

7단계. (고급) ReportCrash 일시적 비활성화

이 단계는 선택 사항이며 숙련된 사용자를 대상으로 합니다. 알려져 있고 피할 수 없는 충돌 루프가 존재하는 환경(예: 퍼징, 특정 테스트 설정)에서 일부 관리자는 끝없는 로그를 생성하여 리소스를 낭비하지 않도록 ReportCrash를 비활성화하기로 선택합니다.

일반 가정이나 사무실 Mac의 경우 영구적인 수정이 아니라 진짜 범인을 추적하는 동안 단기적인 해결 방법으로만 권장합니다. 자동 충돌 진단을 잃게 되며 더 깊은 문제의 징후를 숨길 수 있습니다.

그래도 진행하려면 터미널에서 ReportCrash LaunchAgent 및 LaunchDaemon을 언로드할 수 있습니다:

1. 응용 프로그램 ▸ 유틸리티에서 터미널을 엽니다.
2. 다음 명령을 주의 깊게 실행하십시오(두 번째 명령에는 관리자 암호가 필요합니다):

launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

이렇게 하면 사용자 및 시스템 프로세스에 대해 ReportCrash가 자동으로 시작되지 않습니다.

나중에 충돌 보고를 다시 활성화하려면 다음을 실행하십시오:

launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

다시 말하지만, 이것을 첫 번째 조치가 아닌 최후의 수단으로 취급하십시오. ReportCrash를 비활성화하여 문제가 "해결"된 것처럼 보인다면, 실제로는 열병을 치료한 것이 아니라 온도계만 치운 것입니다.

향후 ReportCrash 문제를 예방하는 방법

모든 충돌을 막을 수는 없지만 몇 가지 습관을 지키면 통제 불능의 ReportCrash 사고 확률을 줄일 수 있습니다:

• macOS 및 핵심 앱을 최신 상태로 유지: 안정성 수정은 시스템 및 앱 릴리스 노트의 상수입니다.
• 시작 항목에 까다로워지기: 로그인 항목을 정기적으로 검토하고 부팅할 때마다 로드할 필요가 없는 것은 비활성화하십시오.
• 앱을 깨끗하게 제거: 앱 사용을 중단할 때는 응용 프로그램의 기본 번들뿐만 아니라 지원 파일과 실행 도우미도 제거하십시오.
• 의심스러운 설치 프로그램 및 번들 피하기: 애드웨어와 잘못 작성된 백그라운드 에이전트는 브라우저 하이재커뿐만 아니라 이상한 충돌의 일반적인 원인입니다.
• 활성 상태 보기 주시: 팬이 갑자기 돌아가면 CPU 및 에너지 탭을 빠르게 훑어보아 만성적인 문제가 되기 전에 오작동하는 프로세스를 잡을 수 있습니다.

요약

CPU 영향이 시작될 때 ReportCrash 자체를 탓하는 것은 오해입니다. 프로세스가 몇 시간 동안 CPU를 독점한다면, 어떤 앱, 서비스 또는 잔여 구성 요소가 끊임없는 충돌 및 재시작 루프에 갇혀 있다는 강력한 신호입니다.

해결책은 일반적으로 드라마틱하기보다는 체계적입니다. 무엇이 충돌하는지 확인하고, 수정하거나 제거하고, 로그인 항목과 LaunchAgents를 정리한 다음, ReportCrash를 일시적으로 비활성화하는 것과 같은 고급 조치를 고려하십시오. 근본적인 불안정성이 사라지면 Mac은 평소의 조용하고 시원하며 눈에 띄지 않는 동작으로 돌아올 것입니다.

자주 묻는 질문

1. ReportCrash는 Mac의 바이러스나 맬웨어인가요?

2. 활성 상태 보기에서 ReportCrash 프로세스를 종료해도 안전한가요?

3. 어떤 앱이 ReportCrash의 높은 CPU 사용을 유발하는지 어떻게 알 수 있나요?

4. Mac에서 충돌 보고를 영구적으로 비활성화할 수 있나요?

5. ReportCrash 문제를 해결하기 위해 언제 macOS 재설치를 고려해야 하나요?