macOS 27에서 밤새 dasd와 appstoreagent CPU 사용량이 높을 때 해결 방법

macOS 27에서 아침에 Mac이 뜨겁고 팬이 시끄럽고 배터리가 방전되어 있나요? dasd와 appstoreagent 루프를 확인하고, 커뮤니티 해결책을 적용하고, 다른 원인을 배제하는 방법을 안내합니다.

배터리 상태가 양호한 Mac의 덮개를 닫고 잠들었는데, 아침에 보니 Mac이 따뜻하고 팬이 한참 돌았던 흔적이 있으며 하룻밤 수면으로는 있을 수 없을 만큼 배터리가 줄어 있습니다. 이런 증상이 macOS 27 Golden Gate로 업그레이드한 직후부터 시작되었다면, 잘 알려진 특정 원인이 있습니다. dasd와 appstoreagent라는 두 백그라운드 프로세스가 촘촘한 루프에 갇혀, 보고에 따르면 매일 밤 자정부터 실행되는 문제입니다. 이 가이드는 두 프로세스가 무엇인지, Apple의 백그라운드 스케줄러가 실행 시점을 어떻게 결정하는지, 이 버그가 실제로 원인인지(밤새 Mac을 뜨겁게 만드는 다른 여섯 가지 원인과 구별하여) 확인하는 방법, 커뮤니티에서 공유된 정확한 해결책과 이를 되돌리는 방법, 그리고 macOS 27.0.1이 이 문제를 고쳤는지에 대해 확인된 사항과 확인되지 않은 사항을 설명합니다. 이 글의 모든 내용은 공개된 보고와 문서에 근거하며, 확인되지 않은 부분은 그렇다고 명시합니다.

핵심 요약

이 버그는 보고되었고 여러 사람이 재현했지만, 아직 Apple이 인정하지 않았습니다. 9월 27일에 시작된 MacRumors 스레드는 MacBook 두 대에서 appstoreagent와 dasd가 자정에 급증한다고 설명하며, 다른 회원들도 Mac Studio와 MacBook Pro에서 같은 현상을 보고합니다. Apple은 이에 대한 알려진 문제를 게시하지 않았습니다.
보고된 원인은 자체 기한을 갱신하지 않는 Apple Arcade 작업입니다. 독립적인 분석 글들에 따르면 com.apple.appstored의 ArcadePayoutResetDate라는 환경설정 값이 과거 시점에 고정되어 있어, 스케줄러가 이 작업을 초당 70~100회씩 계속 다시 실행한다고 합니다.
아무것도 변경하지 않고 2분 안에 확인할 수 있습니다. 프로세스를 CPU 순으로 정렬하고, 환경설정 값을 읽고, 프레디케이트로 통합 로그를 살펴보십시오. 날짜가 과거이고 로그가 넘쳐난다면 이 버그가 맞습니다.
커뮤니티 해결책은 defaults write 한 줄과 killall appstoreagent입니다. 날짜를 미래로 옮기는 방법입니다. 이는 임시 해결책이며 되돌릴 수 있고, 지정한 날짜(예: 7일) 동안은 유지되는 것으로 보고되었습니다.
27.0.1이 이 문제를 고쳤는지는 확인하지 못했습니다. Apple의 27.0.1 업데이트(빌드 26A434)는 명시되지 않은 버그를 수정한다고 설명되어 있습니다. 이 문제에 대한 확인된 결과를 게시한 사람은 아직 없으므로, 단정하지 말고 직접 사용 중인 Mac에서 테스트하십시오.
평범한 원인부터 먼저 배제하십시오. 업그레이드 후의 Spotlight 및 사진 분석, Time Machine, iCloud 동기화, 네트워크 접근 시 깨우기 설정도 모두 밤사이 발열을 일으키며, 아래의 판단 표에서 프로세스 이름별로 어떤 원인을 가리키는지 알려 드립니다.

증상: 오전 9시의 따뜻한 Mac과 사라진 배터리

MacRumors 스레드의 원글 작성자가 이 증상을 가장 깔끔하게 설명합니다. macOS 27을 설치한 뒤 MacBook Pro와 MacBook Air 양쪽에서 CPU 사용량이 "정확히 자정에" 급증했으며 원인은 appstoreagent와 dasd였습니다. 두 번째에는 iStat Menus를 켜 둔 채 두 대를 밤새 켜 두었고, 오전 9시에 부하가 다시 떨어졌습니다. Mac Studio와 MacBook Pro를 가진 회원이 같은 동작을 확인했고, 세 번째 회원은 유용한 관찰을 덧붙였습니다. 시스템 모니터를 실행하지 않으면 CPU 부하를 알아채지 못할 수도 있지만 "배터리가 더 빨리 닳는 것은 분명히 느끼게 될 것"이라는 내용입니다.

정확히 짚어 둘 세부 사항이 있으며, 모두 Apple 문서가 아니라 사용자 관찰입니다.

시점은 현지 시간 자정으로 보고됩니다. 스레드의 한 작성자는 부하가 오전 9시에 끝났다고 말합니다. 다른 분석 글은 멈춘 타임스탬프를 작성자의 시간대 기준 "오늘 00:00:00"으로 설명합니다. 둘 다 Apple 문서가 아니라 사용자 관찰입니다.
최종 릴리스에서 새로 생긴 문제가 아닙니다. 스레드 원글 작성자는 초기 베타에서 이미 이 현상을 본 사람들이 있었다고 언급하며, 6월 24일의 중국어 분석 글은 macOS 27 개발자 베타에서 appstoreagent가 CPU를 100퍼센트 넘게 사용하는 상황을 설명합니다. 즉 릴리스 빌드에서 새로 생긴 회귀가 아니라 오래전부터 있던 버그가 그대로 출시된 것입니다.

이 증상이 사용 중인 Mac과 일치한다면 계속 읽으십시오. 열이 밤이 아니라 낮에 발생하거나 업그레이드 후 며칠간 계속된다면 같은 해결책이 도움이 되지 않으므로, 다른 원인을 다루는 섹션으로 바로 이동하십시오.

dasd와 appstoreagent는 실제로 무엇인가

인터넷에서 낯선 사람이 알려 준 명령을 실행하기 전에, 무엇을 건드리는지 알아 두면 도움이 됩니다.

appstoreagent: App Store의 백그라운드 도우미

appstoreagent는 App Store 구조에 속한 사용자별 백그라운드 에이전트입니다. 앱 업데이트를 확인하고, 자동 다운로드를 처리하고, 라이선스를 검증하고, App Store 상태를 동기화합니다. 평소에는 눈에 띄지 않으며 CPU 사용량도 보통 0퍼센트에 가깝습니다. 이 에이전트가 하는 일 중 여기서 중요한 부분은 Apple Arcade 관련 기록 관리이며, 그래서 Arcade 관련 환경설정이 이 에이전트의 도메인(com.apple.appstored)에 나타납니다.

dasd: Duet Activity Scheduler

dasd는 Duet Activity Scheduler 데몬(줄여서 DAS)이며 Mac에서 가장 중요한 백그라운드 프로세스 중 하나입니다. 이 하위 시스템에 관한 가장 좋은 공개 문서인 The Eclectic Light Company의 Howard Oakley 글은 DAS를 다음과 같이 설명합니다. DAS는 예약된 활동 목록을 유지하면서 어떤 활동을 다음에 실행할지 판단하기 위해 자주 평가합니다. 활동의 종합 점수가 임계값을 넘으면 DAS는 실행하기로 결정하고, Apple의 경량 프로세스 간 통신인 XPC를 통해 Centralized Task Scheduling(CTS)에 시작을 요청합니다.

Time Machine 백업, 소프트웨어 업데이트 정리, 보안 검사, 동기화 작업, 그리고 수십 가지 일상적인 유지 관리 작업이 모두 이 파이프라인을 거칩니다. 2026년 7월의 분석에서 Oakley는 macOS 26.5.2에서 부팅 후 첫 1분 남짓 동안 DAS에 제출된 서로 다른 활동이 최소 701개라고 집계했으며, Apple silicon Mac에서 효율 코어가 수행하는 작업의 상당 부분을 이제 DAS와 CTS가 담당한다고 지적합니다. 다시 말해 dasd는 교환대입니다. dasd가 CPU를 태운다면 대개 누군가 작업을 계속 밀어 넣고 있거나, 같은 작업을 반복해서 밀어 넣고 있다는 뜻입니다.

스케줄러의 판단 방식: 점수, 조건, 임계값

Oakley의 글은 DAS가 점수에 반영하는 요인을 나열합니다. 배터리 잔량, 충전기 연결 여부, 에너지 예산, CPU 사용량, 메모리 압박, 열 상태, 네트워크 품질, Mac이 Power Nap 상태인지 여부, 사용자가 앱을 적극적으로 사용 중인지 여부 등이 포함됩니다. 활동마다 고유한 기준이 있는데, 예를 들어 첫 Time Machine 백업에는 "부팅 후 300초 동안 실행하지 않음"이 있으며, DAS는 자신의 결정을 로그에 기록합니다. 그는 점수 및 임계 점수와 함께 "Decision: Can Proceed"와 "Decision: Must Not Proceed" 형태의 항목을 보여 줍니다.

이 설계의 두 가지 특성이 이번 버그와 관련이 있습니다.

DAS는 조건뿐 아니라 기한에 따라서도 작업을 실행합니다. 활동은 특정 시각까지 실행되도록 표시될 수 있습니다. 기한이 지났고 조건이 충족되면 실행됩니다.
활동은 소유자를 통해 스스로를 다시 등록합니다. 활동이 실행된 뒤 그 활동을 소유한 프로세스(여기서는 appstoreagent)가 다음 실행을 원하는 시점을 스케줄러에 알립니다. 잘못된 날짜가 문제를 일으키는 지점이 바로 여기입니다.

로그에서 활동 식별자는 0:com.apple.softwareupdated.logs-cleanup:A2BBC8처럼 생겼으며, 사용자 ID, 활동 이름, DAS가 부여하는 짧은 16진수 접미사로 구성됩니다. 알아 둘 하위 시스템 이름은 DAS의 com.apple.duetactivityscheduler와 CTS의 com.apple.xpc.activity입니다. 앞의 것은 곧 사용하게 됩니다.

보고된 원인: 앞으로 넘어가지 않는 기한

여러 사람이 독립적으로 같은 지점을 원인으로 추적했습니다. 가장 상세한 공개 분석은 nix-config 저장소의 이슈 82이며, MacRumors 답글이 링크한 블로그 글의 중국인 개발자를 출처로 밝히고 있습니다. 그 내용을 요약하면 다음과 같습니다.

관련된 작업은 com.apple.appstored.ArcadeResetPO이며, 이 분석은 이를 Apple Arcade 개발자 정산 초기화 작업으로 설명합니다.
작업이 실행된 뒤에는 com.apple.appstored 도메인의 환경설정 ArcadePayoutResetDate가 다음 주기로 넘어가야 합니다. 그러나 실제로는 과거 타임스탬프에 고정된 채로 남습니다.
그래서 dasd는 이 작업이 기한을 넘겼다고 보고 즉시 실행합니다. appstoreagent는 만료된 같은 시각으로 다시 등록합니다. 이 사이클이 초당 약 70~100회 반복됩니다.
그 결과 코어 하나가 고정적으로 점유되고, 통합 로깅이 과도하게 발생하며, 발열과 배터리 방전이 일어납니다.

한 MacRumors 회원이 독립적으로 이 버그를 발견했다고 밝히며 작성한 phobox360 스크립트 저장소도 같은 메커니즘을 설명합니다. ArcadeResetPO라는 Apple Arcade 백그라운드 작업이 과거 시점으로 반복해서 스스로를 예약한다는 것입니다. 이는 두 사람이 독립적으로 같은 결론에 도달한 것이므로 단순한 일화 이상이지만, 여전히 Apple의 공식 입장은 아닙니다.

별도의 이전 보고인 6월 글은 베타 시기의 변종을 설명합니다. Arcade 코드의 데이터베이스 오류(SQLite 테이블의 누락된 열, 그리고 이미 실행 중인 작업을 업데이트한다는 로그 줄)와 네트워크 인터페이스 조회의 촘촘한 루프를 원인으로 지목합니다. 이 글은 주로 문제가 릴리스 이전부터 있었다는 증거로서 유용합니다. 이 글의 해결책인 kill -STOP으로 프로세스를 정지시키는 방법은 정지된 동안 App Store 업데이트를 비활성화하므로, 지금 사람들이 권장하는 방법이 아닙니다.

이 문제가 맞는지 확인하는 방법

순서대로 진행하십시오. 이 섹션의 어떤 것도 설정을 변경하지 않습니다. 가능하면 처음 두 단계는 Mac이 이상 동작하는 동안, 즉 자정 직후나 아침에 아무것도 하기 전에 실행하는 것이 좋습니다.

1단계: 활동 모니터 확인

응용 프로그램 > 유틸리티에서 활동 모니터를 열고 CPU 탭을 클릭한 다음 % CPU 열을 기준으로 정렬합니다. dasd와 appstoreagent가 모두 상단 근처에서 지속적으로 CPU를 사용하고, 누적 CPU 시간이 크다면 해당됩니다. 이 버그가 있는 Mac에서는 코어 하나 전체를 사용한다고 보고되므로, 멀티코어 기기에서 단일 프로세스가 100퍼센트 근처를 나타내는 것이 전형적인 패턴입니다. dasd는 root로 실행되므로 본인의 프로세스만 보인다면 보기 > 모든 프로세스를 설정하십시오.

Mac이 밤새 유휴 상태였다면, 급증이 지나간 뒤에도 appstoreagent 옆의 매우 큰 CPU 시간은 강력한 단서입니다. 이 열은 누적되기 때문입니다. 6월 분석 글에는 appstoreagent가 126.7퍼센트이고 실행 시간이 284분을 넘는 top 줄이 나와 있습니다.

이른 아침 주방 식탁에서 30대 여성이 얇은 은색 노트북을 찡그린 채 바라보고 있으며, 옆에는 커피잔에서 김이 오르고, 흐릿한 화면에는 프로세스 목록이 보입니다

2단계: 터미널에서 top으로 확인

활동 모니터도 좋지만, 터미널은 포럼 스레드에 붙여 넣을 수 있는 텍스트를 제공합니다. top이 처음 출력하는 샘플은 부팅 이후의 평균이므로, 샘플을 두 번 요청하고 두 번째 것을 읽으십시오.

top -l 2 -n 10 -o cpu -stats pid,command,cpu,time

-o cpu는 CPU 순으로 정렬하고, -n 10은 목록을 프로세스 10개로 제한하며, -l 2는 샘플을 두 번 취하고, -stats는 열을 선택합니다. 두 번째 블록을 읽으십시오. dasd와 appstoreagent가 모두 상위 몇 개 안에 있고 Mac이 그 외에는 유휴 상태인데도 둘 다 0에 가깝지 않다면 이 버그와 일치합니다. 더 짧은 대안으로 ps -axo pid,pcpu,time,comm -r | head는 현재 사용량 기준으로 CPU를 가장 많이 쓰는 프로세스를 나열합니다.

3단계: Arcade 날짜 읽기

이 테스트는 증상이 아니라 보고된 원인 자체를 확인하므로 결정적입니다. phobox360 프로젝트의 논의는 값을 로케일에 독립적으로 읽는 방법을 알려 줍니다. 키는 com.apple.appstored 도메인에 있으며, plutil로 읽으면 값이 ISO 8601 형식으로 반환됩니다.

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
defaults read com.apple.appstored ArcadePayoutResetDate
date -u +"%Y-%m-%dT%H:%M:%SZ"

첫 번째 명령은 저장된 날짜를 2026-09-26T22:00:00Z 형식으로 출력합니다. 두 번째 명령은 같은 값을 로케일 설정을 거쳐 출력하므로 읽기는 더 쉽지만, 스크립트 작성자들이 발견했듯 12시간제 로케일에서는 다르게 표시될 수 있으니 프로그램으로 비교할 계획이라면 첫 번째를 사용하십시오. 세 번째 명령은 현재 시각을 같은 형식으로 출력하므로 눈으로 비교할 수 있습니다.

해석 방법은 다음과 같습니다.

저장된 날짜가 과거(현재 UTC 시각보다 이전)이고 dasd와 appstoreagent가 바쁜 경우: 보고된 버그와 일치합니다.
저장된 날짜가 미래이고 프로세스가 조용한 경우: 이 버그는 현재 겪고 있는 문제가 아닙니다.
저장된 날짜가 미래인데 프로세스가 여전히 바쁜 경우: 다른 문제가 있거나, 공개되지 않은 원인으로 루프가 발생하고 있는 것입니다. 아래의 프로세스 표를 사용하십시오.
키가 존재하지 않는 경우: 앱이 아직 키를 만들지 않았다는 뜻이며, 어느 쪽의 증거도 아닙니다. App Store나 Apple Arcade를 한 번도 실행하지 않은 Mac에는 키가 없을 수 있습니다.

무언가를 변경하기 전에 이 출력을 저장해 두십시오. 원래 값의 기록이 됩니다.

4단계: 정확한 프레디케이트로 통합 로그 확인

"초당 70~100회"라는 주장은 로그에서 확인할 수 있습니다. macOS의 log 명령은 NSPredicate 필터를 받으며, 축약형 process == "name"은 log 맨페이지에 문서화되어 있습니다. 최근 몇 분간 dasd의 로그를 간결한 한 줄 형식으로 보려면 다음과 같이 합니다.

log show --predicate 'process == "dasd"' --last 5m --style compact | head -50

1분 동안 기록된 줄 수를 세어 대략적인 빈도를 알아보려면 다음과 같이 합니다.

log show --predicate 'process == "dasd"' --last 1m --style compact | wc -l

정상적인 Mac에서는 이 숫자가 크지 않습니다. 이 버그가 활성 상태라면 로그가 넘쳐날 것으로 예상할 수 있는데, 보고에 따르면 이 루프는 과도한 통합 로깅을 일으킵니다. 스케줄러의 하위 시스템으로 필터링하거나 작업 이름을 직접 검색할 수도 있습니다.

log show --predicate 'subsystem == "com.apple.duetactivityscheduler"' --last 2m --style compact | head -50
log show --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --last 2m --style compact | head -50

작업 이름 필터가 가장 구체적입니다. ArcadeResetPO가 1분에 수십 번 나타난다면 보고된 버그를 확인한 것입니다. 사후 확인이 아니라 실시간으로 보려면 같은 프레디케이트로 log stream을 사용하십시오.

log stream --predicate 'eventMessage CONTAINS "ArcadeResetPO"' --style compact

중지하려면 Control-C를 누르십시오. 주의할 점이 두 가지 있습니다. 첫째, 이 버그가 있는 Mac에서 느슨한 프레디케이트로 몇 시간 분량에 log show를 실행하지 마십시오. 로그가 방대해져 명령이 매우 느려질 수 있습니다. 시간 범위를 짧게 유지하십시오. 둘째, 여기서 드리는 것은 문서화된 구문이지 사용자의 로그에 무엇이 담길지에 대한 기록이 아닙니다. 메시지 문구는 빌드마다 다를 수 있으므로, 첫 번째 필터의 결과가 비어 있으면 버그가 없다고 결론짓기 전에 프로세스 필터를 시도해 보십시오.

5단계: 무엇이 Mac을 깨어 있게 했는지 확인

루프가 실행 중이라면, Mac이 그동안 깨어 있었는지 아니면 그 때문에 깨어났는지도 알아야 합니다. 두 가지 pmset 조회가 도움이 됩니다.

pmset -g assertions
pmset -g log | grep -E "DarkWake|Wake "

첫 번째는 현재의 전원 어서션, 즉 백그라운드 작업이나 디스플레이를 켜 두는 프로세스처럼 지금 잠자기를 막고 있는 것을 보여 줍니다. 두 번째는 전원 로그의 깨우기 기록을 출력하며, 각 깨우기 줄에는 "due to" 사유가 있고 DarkWake는 Mac이 어두운 상태로 백그라운드 작업을 수행하는 부분 깨우기입니다. 맨페이지는 -g log를 관리자와 디버깅을 위한 잠자기, 깨우기 및 기타 전원 관리 이벤트의 이력이라고 설명합니다. 밤새 네트워크나 유지 관리 사유로 발생한 DarkWake가 이어진다면 스케줄링 경로를 가리킵니다. 완전한 깨우기가 끊기지 않고 이어진다면 무언가가 Mac을 깨어 있게 붙잡고 있다는 뜻입니다. 이 줄들을 읽는 방법은 Mac 잠자기 문제 가이드에서 자세히 안내합니다.

판단 표: 어떤 프로세스가 어떤 원인을 가리키는가

이 버그가 혼란스러운 이유는 서로 무관한 여러 작업도 밤새 백그라운드 CPU 사용으로 나타나기 때문입니다. 이 표는 활동 모니터에서 보이는 것을 가장 가능성 높은 설명에 대응시킵니다. Apple 문서와 이 글에서 인용한 출처를 바탕으로 만든 진단 보조 자료이며, 보장은 아닙니다.

CPU 상단 근처에 보이는 것	가장 가능성 높은 원인	정상인가 문제인가	먼저 확인할 것
`dasd`와 `appstoreagent`가 모두 바쁨, 대개 자정부터	보고된 Arcade 날짜 루프	문제 (보고된 버그)	3단계: `ArcadePayoutResetDate`가 과거인가?
`mds`, `mds_stores`, `mdworker_shared`	Spotlight 색인	업그레이드 후 몇 시간에서 며칠까지는 정상, 끝나지 않으면 문제	Spotlight 재색인 가이드
`photoanalysisd`, `mediaanalysisd`	사진이 라이브러리를 스캔 중 (얼굴, 장면, 사물)	업그레이드나 대량 가져오기 후, 특히 전원에 연결된 상태에서는 정상	사진 앱을 열고 라이브러리의 분석 상태 확인
`backupd`, `backupd-helper`, `diskarbitrationd`	Time Machine 백업	매시간 정상, 끝나지 않으면 문제	시스템 설정 > 일반 > Time Machine, 그리고 Time Machine 문제 해결 가이드
`bird`, `cloudd`, `fileproviderd`	iCloud Drive 또는 다른 파일 제공자 동기화	대규모 동기화 중에는 정상, 루프에 빠지면 문제	iCloud Drive 상태와 최근 변경 크기 확인
유휴 상태에서 `powerd`, `kernel_task`가 높음	열 관리 또는 전원 어서션	경우에 따라 다름, 원인이라기보다 증상인 경우가 많음	5단계와 어서션 목록
`dasd` 단독, 메모리가 수 GB까지 증가	다른 `dasd` 메모리 문제, 사용자 보고를 인용한 서드파티 블로그가 macOS 27 베타에서 보고함	문제이지만 다른 문제이며 날짜 해결책은 적용되지 않음	활동 모니터의 메모리 탭
`contactsd`, `peopled`	연락처 위젯과 통화 기록 데이터베이스	Tahoe 시기의 알려진 문제	peopled 및 contactsd 가이드
서드파티 앱 또는 그 헬퍼	앱 자체	해당 앱의 문제	앱 종료, 업데이트 확인

이 표에서 두 가지 경험칙을 얻을 수 있습니다. 첫째, 짝이 중요합니다. dasd 단독은 많은 작업을 디스패치하는 스케줄러이며, 실제 CPU는 디스패치된 프로세스가 소모하는 경우가 많습니다. 정해진 시각에 dasd와 appstoreagent가 함께 나타나는 것이 보고된 패턴입니다. 둘째, 시점이 중요합니다. 색인과 사진 분석은 업그레이드 직후에 가장 무겁고 점차 사라지지만, 자정에 묶인 루프는 매일 밤 반복되어야 합니다.

커뮤니티 해결책, 한 줄씩 설명

MacRumors 회원들과 분석 글들이 공통으로 도달한 해결책은 환경설정 변경 하나입니다. 스레드에 게시된 형태 그대로, 스레드에는 없는 설명을 덧붙여 소개합니다.

변경하기 전에: 원래 값 저장

되돌릴 수 있도록 현재 값을 복사해 두십시오. 두 명령 모두 아무것도 수정하지 않습니다.

defaults read com.apple.appstored ArcadePayoutResetDate > ~/Desktop/arcade-date-before.txt
defaults export com.apple.appstored ~/Desktop/appstored-before.plist

첫 번째는 현재 날짜를 텍스트 파일에 기록합니다. 두 번째는 com.apple.appstored 환경설정 도메인 전체를 데스크탑의 속성 목록 파일로 내보냅니다. 첫 번째 명령이 "does not exist"를 출력하면 키가 없는 것이므로 첫 줄은 건너뛰어도 됩니다.

명령

MacRumors에 게시되고 nix-config 이슈에서 반복된 7일 버전은 다음과 같습니다.

defaults write com.apple.appstored ArcadePayoutResetDate -date "$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")" && killall appstoreagent

하나씩 살펴보겠습니다.

defaults write com.apple.appstored ArcadePayoutResetDate -date "..."는 App Store 에이전트 환경설정의 ArcadePayoutResetDate 키에 날짜 값을 씁니다. -date 플래그는 값이 문자열이 아니라 날짜임을 defaults에 알려 줍니다.
$(date -v+7d -u +"%Y-%m-%dT%H:%M:%SZ")는 그 날짜를 계산하는 셸 표현식입니다. date -v+7d는 BSD date(macOS의 것)가 현재 시각을 7일 앞으로 조정하는 것이고, -u는 UTC를 사용하며, 형식 문자열은 Z로 끝나는 ISO 8601 타임스탬프를 만듭니다. Homebrew coreutils의 GNU date는 플래그가 다르므로, 경로에서 시스템 date를 대체했다면 /bin/date로 실행하십시오.
&&는 쓰기가 성공했을 때만 다음 부분을 실행합니다.
killall appstoreagent는 실행 중인 appstoreagent를 종료하여 재시작 시 새 환경설정을 읽게 합니다. 시스템이 필요할 때 다시 실행하므로 영구적인 종료가 아닙니다. App Store에서 다운로드나 업데이트가 진행 중이면 중단되므로, 아무것도 업데이트하지 않을 때 실행하십시오.

sudo 없이 일반 사용자로 실행하십시오. 이 환경설정은 사용자 계정에 속하며, phobox360 프로젝트도 사용자에게 sudo 없이 실행하라고 명시합니다. root로 환경설정을 쓰면 에이전트가 읽지 못할 수 있는 파일이 만들어집니다.

기대되는 결과: 재시작 후 몇 초 안에 활동 모니터에서 dasd와 appstoreagent가 0에 가깝게 떨어져야 합니다. 이 명령을 처음 문서화한 분석 글은 해결이 즉시 적용된다고 말합니다. 이는 한 사용자가 보고한 결과이며, 사용 중인 Mac에서도 그렇다고 약속드릴 수는 없습니다.

이 명령이 바꾸는 것과 바꾸지 않는 것

날짜 하나만 바꿉니다. 삭제되는 것도, 건드리는 시스템 파일도, 비활성화되는 보호 기능도 없습니다. com.apple.appstored는 평범한 사용자별 환경설정 도메인입니다.
날짜를 낡게 만든 버그 자체를 고치지는 않습니다. 스케줄러가 작업을 기한 초과로 보지 않도록 기한을 손이 닿지 않는 곳으로 옮길 뿐입니다. 보고자들은 이것을 Apple이 실제 수정을 내놓을 때까지의 임시 해결책이라고 설명합니다.
Apple Arcade 구독이나 게임에 영향을 준다고 알려져 있지 않습니다. 관련된 작업은 개발자 정산 초기화라고 설명됩니다. 그러나 날짜를 아주 먼 미래로 옮겼을 때 Arcade 기록 관리에 어떤 일이 생기는지를 테스트해 게시한 사람은 없습니다. 스크립트 작성자도 더 공격적인 2035년 옵션에 대해 같은 말을 합니다. Arcade를 많이 사용한다면 짧은 7일 기간을 선택하십시오.

밝은 홈 오피스의 책상에서 한 청년이 안도한 표정으로 얇은 은색 노트북에 명령을 입력하고 있으며, 흐릿한 화면에는 단순한 터미널 창이 보입니다

날짜 선택: 7일 또는 수년

nix-config 분석 글은 작업을 사실상 영원히 유예하는 2099-01-01T00:00:00Z를 사용합니다.

defaults write com.apple.appstored ArcadePayoutResetDate -date "2099-01-01T00:00:00Z"
killall appstoreagent

이렇게 하면 매주 해결책을 반복할 필요가 없고, "App Store 기능을 해치지 않고" 작업을 장기적으로 보류하는 것으로 보고되었지만, 이 설명은 보고자의 것이며 Apple이 확인한 것이 아닙니다. phobox360 스크립트의 선택적 영구 모드는 2035년을 사용하며, Arcade 기록 관리에 미치는 영향이 독립적으로 검증되지 않았다는 명시적 경고가 붙어 있습니다. 저희의 권장 사항은 문서화된 사실이 아니라 판단입니다. 7일로 시작하십시오. 효과가 있다면 낮은 위험으로 진단이 옳았음을 알게 된 것이며, 더 나아갈지는 나중에 결정할 수 있습니다.

되돌리는 방법

되돌리는 방법은 두 가지이며, 필요해지기 전에 둘 다 알아 두는 것이 좋습니다.

저장해 둔 값 복원. 원래 날짜를 저장했고 그것이 유효한 과거 날짜였다면, 그 값을 다시 쓰면 이전 상태로 돌아갑니다. 물론 그 상태는 루프가 있는 상태입니다. 실제로는 테스트하거나 버그 보고서에 깨끗한 상태를 Apple에 전달할 때만 이렇게 합니다. 텍스트 파일에 있는 ISO 문자열을 사용하십시오.

defaults write com.apple.appstored ArcadePayoutResetDate -date "2026-09-26T22:00:00Z"
killall appstoreagent

예시 날짜를 저장해 둔 본인의 값으로 바꾸십시오.

키 삭제. 이렇게 하면 직접 설정한 값이 제거되고 에이전트가 저장된 값 없이 시작합니다.

defaults delete com.apple.appstored ArcadePayoutResetDate
killall appstoreagent

키를 삭제하는 것은 설정을 기본값으로 되돌리는 표준적인 defaults 방식입니다. macOS 27에서 키가 없을 때 App Store 에이전트가 어떻게 동작하는지는 문서화되어 있지 않으며, 새로운 유효한 날짜를 다시 만들 수도 있고 버그가 있는 날짜를 만들 수도 있습니다. 키를 삭제한 뒤 루프가 돌아오면 해결책을 다시 적용하십시오.

스크립트 옵션과 그 신뢰도

dasd-arcade-loop-fix 저장소는 같은 변경을 드라이런, 확인 프롬프트, 원래 값의 자동 백업, 롤백 명령을 갖춘 스크립트로 감쌉니다. 이 글을 쓰는 시점에는 별과 포크가 거의 없는 작은 프로젝트라서 널리 검토되지 않았습니다. 합리적인 접근은 스크립트를 실행하기 전에 읽어 보거나, 같은 일을 전체를 눈으로 볼 수 있는 형태로 수행하는 위의 한 줄 명령을 그냥 사용하는 것입니다. 스크립트를 사용한다면 문서화된 플래그는 드라이런, 기본 1주 연기, --rollback입니다. 풀 리퀘스트 하나는 defaults read가 날짜를 출력하는 방식 때문에 12시간제 로케일에서 중단되던 문제를 고쳤는데, 환경설정 출력을 파싱하는 셸 스크립트가 취약하다는 점을 잘 보여 주는 사례입니다.

하지 말아야 할 것

dasd를 종료하지 마십시오. root 소유이고 launchd가 즉시 다시 시작하며, 스케줄러를 죽여서 고칠 수는 없습니다. 또한 작업이 기한을 넘긴 이유도 해결하지 못합니다.
appstoreagent에 kill -STOP을 하거나 언로드하는 것을 영구적인 조치로 삼지 마십시오. 6월 분석 글은 베타에서 다른 방법이 통하지 않아 kill -STOP을 사용했습니다. 이는 프로세스를 일시 중단하므로, kill -CONT로 재개할 때까지 App Store 업데이트, 다운로드, 라이선스 확인이 멈춥니다.
시스템 무결성 보호를 비활성화하거나 /System 파일을 편집하지 마십시오. 어떤 보고에서도 그럴 필요가 없습니다.
자동 업데이트를 끄는 것만으로 해결되었다고 여기지 마십시오. MacRumors 답글 하나가 이를 제안하며 에이전트가 깨어나는 빈도를 줄일 수는 있지만, 보고된 원인은 해결하지 못합니다. 이 작업은 업데이트 확인이 아니라 Arcade 정산 초기화입니다. 또한 App Store 앱의 자동 보안 업데이트를 받지 못하게 됩니다. 테스트를 위해 껐다면 다시 켜십시오.

다시 발생하는 이유와 대처 방법

7일 명령을 사용했다면 기록한 날짜는 이제 실제로 유효한 날짜이며, 그 날이 지나기 전까지 스케줄러는 만족합니다. 그날이 지나면 낡은 날짜 상태가 다시 발생할 수 있습니다. 보고에 따르면 루프는 약 일주일 뒤에 재발할 수 있습니다. 이 메커니즘은 버그 설명에서 예상할 수 있는 그대로입니다. 해결책은 기한을 옮길 뿐이고, 기한을 제대로 갱신하지 못하는 버그는 그대로 남아 있습니다.

선택지는 두 가지입니다.

명령을 매주 반복합니다. 캘린더에 알림을 설정하십시오. 부담이 적고 Arcade 상태를 정상에 가깝게 유지합니다.
훨씬 먼 날짜를 사용합니다. 2099 형태는 반복 작업을 없애 줍니다. 대신 이미 설명한 것처럼 Arcade 기록 관리에 대해 덜 검증된 영역에 들어서게 됩니다.

macOS 27.0.1이 이 문제를 고쳤는가?

알 수 없으며, 추측하기보다 그렇다고 말씀드리는 편이 낫습니다.

확인할 수 있는 것: Apple은 9월 28일에 macOS 27.0.1을 출시했습니다. The Eclectic Light Company의 보도에 따르면 새 빌드 번호는 26A434이고, 이 업데이트는 "명시되지 않은 버그와 함께 Platform SingleSignOn에 영향을 주던 버그를 수정하는 것으로 보이며", 공개된 보안 릴리스 노트는 없습니다. 이 글은 CPU, 배터리, App Store, Apple Arcade에 대해서는 아무 말도 하지 않습니다.

스레드가 보여 주는 것: 27.0.1이 나온 뒤 원글 작성자는 "macOS 27.0.1에서 이제 고쳐졌는지 궁금하다"고 썼습니다. 이어진 답글은 파일 확장 프로그램의 로컬 네트워크 권한 문제라는 다른 버그에 관한 것이었고, 그 버그는 고쳐지지 않았다고 확인했습니다. 스레드에서 Arcade 루프에 대한 적용 전후 결과를 보고한 사람은 없습니다.

따라서 솔직한 입장은 어느 쪽으로도 확인되지 않았다는 것입니다. 또한 모호한 릴리스 노트는 흔하므로, 목록에 없어도 수정이 포함되어 있을 수 있습니다.

유용한 증거를 남기는 방식으로 직접 Mac에서 확인하는 방법은 다음과 같습니다.

27.0.1로 업데이트합니다(시스템 설정 > 일반 > 소프트웨어 업데이트).
어떤 해결책을 적용하기 전에 3단계를 실행하여 ArcadePayoutResetDate를 읽습니다.
이미 해결책을 적용했다면 설정한 날짜가 지나기를 기다리거나, 위에서 설명한 대로 키를 삭제하고 재시작한 뒤 자정을 넘겨 관찰합니다.
다음 날 아침 top이나 활동 모니터를 확인하고, 작업 이름 프레디케이트로 로그를 읽습니다.
알아낸 내용을 MacRumors 스레드에 게시합니다. 그 스레드를 읽는 사람들이 바로 답이 필요한 사람들입니다.

밤사이 발열과 배터리 방전의 다른 원인 배제하기

dasd가 범인이더라도 혼자가 아닐 수 있습니다. 업그레이드는 여러 밀린 작업을 한꺼번에 일으키며, 한 번에 둘 이상의 문제가 있는 것도 흔합니다. Arcade 루프가 전부라고 결론 내리기 전에 다음을 확인하십시오.

업그레이드 후 Spotlight와 Siri 색인

대규모 업그레이드 후 macOS는 검색 색인의 일부를 다시 만들며, 이는 mds, mds_stores, mdworker_shared로 나타납니다. 예기치 않은 깨우기에 관한 Apple의 자체 안내는 Spotlight가 디스크를 색인하는 중이면 Mac이 잠자기 상태로 들어가지 않는다고 언급하며, 잠들지 못하는 Mac은 따뜻해지고 밤새 배터리를 소모합니다. 색인은 유한합니다. 몇 시간, 큰 드라이브에서는 하루나 이틀 동안 강하게 실행된 뒤 안정됩니다. Arcade 루프는 안정되지 않습니다. macOS 27 이후 Spotlight 재색인 가이드는 "아직 작업 중"인지 "멈춤"인지 구별하는 방법을 다루며, macOS 26.6에 관한 이전 보고는 Siri 색인으로 같은 패턴을 보여 줍니다.

사진 분석

photoanalysisd와 mediaanalysisd는 사진 라이브러리에서 사람, 장면, 사물을 스캔합니다. 업그레이드나 가져오기 직후에 가장 무겁고, 끝이 있으며, 시작하는 정해진 시각은 없습니다. 밤새 Mac을 전원에 연결해 두고 며칠 밤에 걸쳐 부하가 줄어드는지 확인하십시오.

Time Machine

Time Machine 백업은 같은 스케줄러를 통해 실행됩니다. Oakley의 글은 활동에 5분 대기 조건이 있어 시작 직후 몇 초 동안 DAS가 백업을 거부하는 모습을 보여 주는데, 이는 기준이 작동하는 예입니다. 업그레이드 후 첫 백업이나 느린 네트워크 대상으로의 백업은 몇 시간 동안 실행되며 Mac을 뜨겁게 만들 수 있습니다. backupd가 바쁜 프로세스라면 Time Machine 문제 해결 가이드가 알맞은 곳이며, Oakley의 백업 스케줄링과 디스패치에 관한 글은 백업이 엉뚱한 시점에 시작될 수 있는 이유를 설명합니다.

Power Nap과 네트워크 접근 시 깨우기

Apple의 잠자기 및 깨우기 설정 페이지는 Power Nap이 Mac이 잠자는 동안 스스로 업데이트하게 해 주고, "네트워크 접근 시 깨우기"는 다른 사용자가 공유 서비스에 접근할 수 있도록 잠시 깨어나게 한다고 설명합니다. 노트북에서는 둘 다 시스템 설정 > 배터리 > 옵션에 있습니다. Apple의 예기치 않은 깨우기 페이지는 제안 사항으로 네트워크 접근 시 깨우기 해제와 공유 서비스 끄기를 나열합니다. pmset 맨페이지는 womp가 "네트워크 접근 시 깨우기"에 해당하는 터미널 명령이고 powernap은 지원되는 기기에 적용된다고 설명합니다. Power Nap 사용 가능 여부는 모델에 따라 다르므로 보이지 않더라도 놀라지 마십시오.

변경하지 않고 현재 값을 확인하려면 다음과 같이 합니다.

pmset -g | grep -E "powernap|womp"

pmset -g log에 밤새 정기적인 DarkWake가 보인다면 둘 다 끄는 것은 해볼 만한 실험입니다. Mac이 깨어 있거나 유지 관리를 위해 깨어난 상태에서 발생하는 Arcade 루프는 이것으로 고쳐지지 않지만, 진단에서 잡음을 제거해 줍니다. 무엇이 도움이 되었는지 알 수 있도록 한 번에 하나씩만 변경하십시오.

일반적인 문제 해결

명령 실행 후에도 프로세스가 여전히 바쁜 경우

증상: defaults write와 killall을 실행했는데도 dasd와 appstoreagent가 활동 모니터 상단 근처에 있습니다.

원인: 몇 가지 가능성이 있습니다. killall이 일치하지 않아 이전 프로세스가 이전 날짜를 캐시한 채 계속 실행 중일 수 있습니다. 도메인 오타 등으로 쓰기가 조용히 실패했을 수 있습니다. 또는 전혀 다른 원인을 보고 있을 수도 있습니다.

해결 방법:

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist로 값을 다시 읽어 미래인지 확인합니다.
killall appstoreagent를 다시 실행한 뒤, 활동 모니터에서 프로세스가 새 PID로 다시 시작되었는지 확인합니다.
작업 이름 로그 프레디케이트를 1분간 다시 실행합니다. ArcadeResetPO가 더 이상 나타나지 않는데 CPU가 여전히 높다면 원인은 다른 것이며, 위의 프로세스 표가 다음 확인 지점입니다.

plutil -extract ArcadePayoutResetDate raw ~/Library/Preferences/com.apple.appstored.plist
pgrep -l appstoreagent

그래도 해결되지 않는 경우: Mac을 한 번 재시작하십시오. 재시작하면 캐시된 환경설정과 멈춰 있던 스케줄러 상태가 정리됩니다. 재시작 후에도 날짜가 유효하고 부하가 남아 있다면 다른 버그로 보고, 도움을 요청하기 전에 2단계와 4단계의 출력을 수집하십시오.

일주일 뒤 루프가 돌아온 경우

증상: 한 주 동안 조용하다가 자정의 급증이 다시 나타납니다.

원인: 설정한 7일 날짜가 지났고 근본 버그는 그대로 남아 있습니다.

해결 방법: 명령을 다시 실행하거나 위에서 논의한 대로 더 먼 날짜를 선택하십시오. 반복하고 싶지 않다면 더 긴 기간을 알고서 결정하되, Arcade 기록 관리에 미치는 영향이 문서화되어 있지 않다는 점을 기억하십시오.

프로세스는 조용한데 Mac이 여전히 밤새 방전되는 경우

증상: dasd와 appstoreagent가 0인데도 배터리가 계속 줄어듭니다.

원인: 잠자기 중의 발열과 방전은 CPU보다 깨우기와 어서션에서 비롯되는 경우가 많습니다.

해결 방법: 밤사이 구간의 pmset -g log를 읽어 Mac이 얼마나 자주, 왜 깨어났는지 확인하십시오. pmset -g assertions로 잠자기를 막는 것이 있는지 확인하십시오. Mac 잠자기 문제 가이드와 macOS Tahoe 배터리 방전 가이드가 흔한 원인을 다루며, 고급 배터리 진단 가이드는 배터리 데이터를 더 깊이 읽는 방법을 다룹니다.

자주 묻는 질문

macOS 27에서 dasd와 appstoreagent가 왜 이렇게 CPU를 많이 사용하나요?

MacRumors 회원들의 보고와 독립적인 분석 글들에 따르면, Apple Arcade 작업인 ArcadeResetPO가 저장된 날짜를 과거로 유지하기 때문에 스케줄러가 이 작업을 초당 70~100회까지 계속 다시 실행한다고 합니다. Apple은 이를 확인하지 않았습니다. 패턴은 코어 하나가 고정 점유되고, 대개 자정에 시작되며, 발열과 더 빠른 배터리 방전이 동반되는 것입니다.

ArcadePayoutResetDate에 defaults write 명령을 실행해도 안전한가요?

사용자별 환경설정 하나만 변경하고 시스템 파일은 건드리지 않으며, 키를 삭제하거나 저장해 둔 값을 복원하여 되돌릴 수 있습니다. 이는 Apple의 안내가 아니라 커뮤니티 해결책이며, 장기간에 걸친 Arcade 기록 관리에 대한 영향은 문서화되어 있지 않습니다. 원래 값을 먼저 저장하고 짧은 기간을 선호하십시오.

macOS 27.0.1이 dasd와 appstoreagent 루프를 고쳤나요?

확인하지 못했습니다. Apple의 27.0.1 업데이트(빌드 26A434)는 명시되지 않은 버그와 Platform SSO 문제 하나를 수정한다고 보고되었으며, 이 문제에 대한 언급은 없습니다. 이에 관해 물은 MacRumors 게시물 하나에는 다른 버그에 대한 답글이 달렸습니다. 자정을 넘겨 날짜를 읽는 방식으로 직접 Mac에서 테스트하십시오.

이 버그인지 Spotlight나 사진 때문인지 어떻게 알 수 있나요?

plutil로 저장된 날짜를 읽어 현재 UTC 시각과 비교하십시오. dasd와 appstoreagent가 바쁜 동안 날짜가 과거이고 로그에 ArcadeResetPO 작업이 반복해서 보인다면 이 버그입니다. Spotlight는 mds 프로세스로, 사진은 photoanalysisd로 나타나며 정해진 자정 시작 시점이 없습니다.

왜 일주일 뒤에 문제가 다시 생기나요?

해결책은 초기화 날짜를 일주일 뒤로 옮깁니다. 그 날짜가 지나면 이를 갱신하지 못하는 근본 버그가 다시 발생할 수 있어 루프가 돌아옵니다. 보고자들은 약 일주일 뒤에 재발한다고 설명합니다. 명령을 매주 반복하거나 더 먼 날짜를 선택할 수 있으며, 긴 날짜는 덜 검증되었다는 점을 감수해야 합니다.

App Store 자동 업데이트를 끄면 멈추나요?

MacRumors 답글 하나는 프로세스가 조용해진다고 말하지만, 보고된 원인인 Arcade 정산 작업은 해결하지 못하며 그것은 업데이트 확인이 아닙니다. 또한 App Store 앱의 자동 업데이트를 받지 못하게 됩니다. 해결책이 아니라 시험해 볼 절충안으로 취급하고, 도움이 되지 않으면 업데이트를 다시 켜십시오.

그냥 dasd나 appstoreagent를 종료하면 안 되나요?

appstoreagent를 종료하면 급증이 잠시 멈추지만, 시스템이 필요할 때 다시 실행하고 낡은 날짜는 그대로이므로 루프가 재개됩니다. dasd는 launchd가 즉시 다시 시작하는 root 소유 스케줄러입니다. kill -STOP으로 appstoreagent를 정지시키는 방법은 통하지만 재개할 때까지 App Store 업데이트와 라이선스 확인이 멈춥니다.

이 해결책이 Apple Arcade 게임이나 구독에 영향을 주나요?

공개된 보고 중에는 그렇다고 말하는 것이 없습니다. 이 작업은 개발자 정산 초기화로 설명되며, 해결책은 날짜 하나만 바꿉니다. 그러나 수년 뒤로 옮긴 경우를 테스트해 게시한 사람은 없고, 스크립트 작성자는 Arcade 기록 관리에 대한 영향이 확립되지 않았다고 명시적으로 말합니다. Arcade를 플레이한다면 짧은 기간을 사용하십시오.

결론

macOS 27에서 밤새 뜨거워지고 방전되는 Mac의 배경에는, 점점 늘어나는 보고에 따르면 스케줄러 루프가 있습니다. dasd가 디스패치하고 appstoreagent가 다시 등록하는, 날짜가 앞으로 넘어가지 않는 Apple Arcade 작업입니다. 아무것도 변경하지 않고 확인하는 비용도 적습니다. 저장된 날짜를 읽고, UTC와 비교하고, 로그에서 작업 이름을 찾으면 됩니다. 날짜가 과거라면 한 줄짜리 커뮤니티 해결책이 루프를 즉시 멈춘다고 보고되었고, 되돌리기도 쉽습니다.

기대치는 솔직하게 유지하십시오. 더 긴 날짜를 받아들이지 않는 한 반복해야 하는 임시 해결책이며, Apple은 이를 인정하지 않았고, 27.0.1이나 이후 업데이트가 고쳤다고 말씀드릴 수도 없습니다. 날짜 확인 결과가 깨끗하다면 진단을 억지로 끼워 맞추지 마시고, 위의 판단 표를 활용해 Spotlight, 사진, Time Machine, iCloud, 깨우기 설정을 하나씩 확인하십시오.

더 깊이 알아보려면 Spotlight 재색인 가이드가 업그레이드 후 Mac이 뜨거워지는 가장 흔한 정당한 원인을 다루고, Mac 잠자기 문제 가이드는 깨우기와 어서션 문제를 다룹니다. 다른 프로세스가 원인이라면 peopled 및 contactsd 가이드가 맞을 수 있습니다. 그리고 27.0.1이 사용 중인 Mac에서 무언가를 바꿨는지 알게 되시면 MacRumors 스레드의 다른 분들께 알려 주십시오.

질문이나 공유하고 싶은 팁이 있으신가요? 아래 댓글에서 여러분의 경험을 들려주세요.

관련 도구: Mac 호환성 확인 - 내 Mac 모델에서 특정 macOS 버전을 실행할 수 있는지 확인하세요.