2026.08.19 (최종 수정일 2026.08.29)

[Apple Mac] NVMe 컨트롤러 패닉 및 복구 모드 진입 트러블슈팅

#macOS#Apple Silicon#NVMe#SSD#Kernel Panic#AppleANS2NVMeController#eccWidgetLLTShadow#Apple Support#Troubleshooting

1. 개요 및 핵심 요약

1-1. 개요

본 문서는 Apple Silicon(M3, t6030) MacBook Pro 환경에서 발생한 잠자기(Sleep) 중 예기치 않은 시스템 재부팅, 덮개 개방 시 하드 프리징(Hard Freeze), 그리고 복구 모드(RecoveryOS) 강제 진입 현상에 대한 커널 로그 분석 및 트러블슈팅 리포트입니다.

분석은 최대한 근거 자료를 통해 객관적인 자료로 제공하고 싶었으나. 애플의 비공개 자료들의 영역이 많아 꽤나 주관적인 자료임을 사전에 명시합니다.

단순한 저장 공간 부족이나 OS 논리 오류로 보였던 증상의 기저에는 **Apple 내장 SSD 컨트롤러(AppleANS2NVMeController)의 전원 제어 실패(PowerStateAction)와 FTL 주소 변환 계층의 무결성 오류(Assert failed: eccWidgetLLTShadow)**라는 스토리지 컨트롤러 레벨의 장애가 존재함을 커널 통합 로그(Unified Log) 및 표준 규격 분석을 통해 확인했습니다.

[분석 대상 하드웨어 정보]

기기 식별자: Apple Silicon MacBook Pro (M3)
스토리지 모델: APPLE SSD AP0512Z (512GB)
펌웨어 빌드: 561.100.7~2101 (AppleStorageFirmwarePreASP3)
주요 증상: 잠자기 복귀 불가, 무한 로딩, 시스템 단절 및 RecoveryOS 강제 진입

1-2. 핵심 요약

지속 원인 (하드웨어): 내장 NVMe 컨트롤러(AppleANS2NVMeController)가 전원 상태 전환 과정에서 FTL 주소 변환 테이블 무결성 검사에 실패(eccWidgetLLTShadow)하고 kIOReturnInternalError(0xe00002c9)를 반환합니다. 오류는 잠자기에 진입할 때마다 예외 없이 1건씩 발생하며(잠자기 133건 : 오류 133건, 비율 1.00), 타임머신 복원 여부와 무관하게 재현됩니다 — 복원하지 않은 클린 설치 상태와 복원을 마친 상태 양쪽 모두에서 확인되었습니다. OS를 세 차례 재설치하는 동안 오류가 사라진 적이 없으며, 발생 빈도는 79회에서 105회로 오히려 증가했습니다.
1회성 사건 (복구 모드 강제 진입): 위 결함이 하필 ① 백그라운드 OS 업데이트로 SSV 봉인이 해제된 상태, ② 타임머신 로컬 스냅샷 누적으로 잔여 용량이 임계치에 도달한 상태와 겹치면서 부팅 서명 검증에 실패해 RecoveryOS로 강제 유도되었습니다. 터미널로 용량을 확보하자 정상 부팅이 회복된 것이 이를 뒷받침합니다.
둘의 관계: 복구 모드 진입은 컨트롤러 결함이 특정 조건과 만났을 때 드러난 결과이고, 컨트롤러 결함은 조건과 무관하게 상시 발생하는 원인입니다. 따라서 용량 확보·자동 업데이트 차단은 재발 조건만 줄일 뿐, 원인 자체를 해결하지 못합니다.
진단 도구와의 괴리: Apple Diagnostics(MRI)는 정상 판정을 반환하지만, 같은 기기에서 커널 로그에는 위 오류가 계속 기록되고 있습니다.

2. 타임라인

2-1. 최초 전조 증상: PCIe 버스 통신 단절 패닉 (08-16 11:53 KST)

맥북 단독 대기 상태 중 스스로 재부팅되었으며, 시스템 패닉 리포트(*.panic)에서 물리적 버스 링크 단절이 확인되었습니다.

panic-full-2026-08-16-115330.0002.panic

panic(cpu 0 caller 0xfffffe0055c2e4bc): ANS2 Recoverable Panic - assert failed: [14510]:apcie0[1]: Unexpected link down linksts=0x83000204 pcielint=0xb0007000, ltssm=0x00(DETECT_QUIET) - Null(4)
assert failed: [14510]:apcie0[1]: Unexpected link down linksts=0x83000204 pcielint=0xb0007000, ltssm=0x00(DETECT_QUIET)
RTKit: RTKit-3255.120.11.release - Client: t6030.release-AppleStorageFirmwarePreASP3-561.100.7~2101~561.100.7~2101
!UUID: ecefac9b-217b-3ff5-a610-ed3c1d98b3e2
ASLR slide: 0x0000000000000000
Time: 0x00001ed9c8bf5539

apcie0[1] : Apple SoC 내장 PCIe 컨트롤러 버스 1번 채널 (내장 NVMe SSD 통신 라인).
ANS2 = Apple NAND Storage 프로세서 (SSD 펌웨어를 관리하는 전용 컨트롤러)
ltssm=0x00(DETECT_QUIET): PCIe 링크 훈련 상태 머신(LTSSM)이 통신 불능 상태로 떨어짐.

분석 : 저장장치 펌웨어(RTKit) 실행 중 PCIe 버스 링크가 하드웨어적으로 끊어지며 복구 가능한 패닉(Recoverable Panic)이 발생한 최초의 하드웨어 전조 증상입니다.

2-2. 전원 제어 실패 및 FTL 주소 매핑 무결성 붕괴 (08-17 22:21 ~ 08-18 새벽)

log show --predicate 'process == "kernel" AND (eventMessage contains[c] "disk" OR eventMessage contains[c] "nvme" OR eventMessage contains[c] "io error")' --last 24h
 
2026-08-17 22:21:31.126480+0900 kernel: (IONVMeFamily) AppleNVMe Assert failed: eccWidgetLLTShadow
2026-08-17 22:21:31.126491+0900 kernel: (IONVMeFamily) file: /AppleInternal/.../AppleANS2NVMeController.cpp
2026-08-17 22:21:31.126501+0900 kernel: (IONVMeFamily) AppleNVMe Assert failed: kIOReturnSuccess == (status)
2026-08-17 22:21:31.126516+0900 kernel: (IONVMeFamily) IOReturn AppleANS2NVMeController::PowerStateAction(unsigned long, unsigned long)::3427: failed with status - 0xe00002c9
...
2026-08-17 23:10:21.097440+0900 kernel: (IONVMeFamily) void IONVMeController::PrintCompletionErrorDetail: Status Code: 0x2
2026-08-17 23:10:23.739986+0900 kernel: (IONVMeFamily) void IONVMeController::PrintCompletionErrorDetail: Status Code: 0xC0

분석:

Assert failed: eccWidgetLLTShadow : SSD 내부 SRAM/DRAM 캐시에 로드된 Logical Location Table(논리-물리 FTL 주소 변환 테이블)의 무결성 검증/ECC 정정 서브모듈(Widget) 검사 실패.
failed with status - 0xe00002c9 :
- Apple XNU 오픈소스 IOKit/IOReturn.h 기준 kIOReturnInternalError (0x38 << 26 | 0x2c9).
- 전원 상태 변경 함수(PowerStateAction) 실행 중 컨트롤러 내부 로직 실패로 인해 정상 상태 복귀 실패.
Status Code: 0x2 / Status Code: 0xC0 :
- NVMe 2.2 Spec 기준 Status Code Type: 0x0 (Generic Command Status) 내에서 표준 파라미터 필드 오류(0x02: Invalid Field in Command) 및 제조사 독자 정의 내부 오류(0xC0: Vendor Specific)가 반복 발생.

상세 로그 분석 → [Apple Mac] 커널 패닉 당시 로그 분석

이 구간의 커널 로그 전문과 항목별 해석을 별도 문서로 정리했습니다. 핵심만 옮기면, 24시간 로그에서 eccWidgetLLTShadow Assert가 79회, 같은 시점의 PowerStateAction ... failed with status - 0xe00002c9가 79회로 정확히 1:1 대응합니다. 잠자기 전원 전환이 시도될 때마다 예외 없이 실패했다는 뜻이며, 발생 간격은 최소 11초에서 최대 105분까지 불규칙하며(중앙값 약 15분), 하루 종일 반복되었습니다.

2-3. 시스템 하드 프리징 및 로깅 단절, 복구 모드 강제 진입 (08-18 16:17:56 ~ 20:45:17 KST)

덮개를 열자 시스템이 완전히 멈췄고(Hard Freeze), 강제 재부팅되면서 복구 모드(RecoveryOS)로 직행했습니다.

단절 원인 추정 : SSD 컨트롤러가 I/O 요청에 더 이상 응답하지 못하면서 커널 통합 로깅 데몬(syslogd, logd)의 디스크 플러시가 차단되었고, 패닉 덤프조차 쓰지 못한 채 전원 강제 차단 후 복구 모드로 진입했습니다

2026-08-18 16:17:56.975985+0900 syslogd[558]: ASL Sender Statistics
--- [약 4시간 27분간 로그 기록 완전 중단: 컨트롤러 무응답으로 인한 Unified Logging 불가 상태] ---
2026-08-18 20:45:17.000000+0900 bootlog[0]: BOOT_TIME 1787053517 869934

os 재설치 문구

디스크 검사 진행 Disk Utility 클릭 후 주 드라이브의 검사/복구(First Aid)를 눌러 디스크 오류를 검사 진행

macOS 재설치 진행 Reinstall macOS Tahoe 클릭 55GB 여유 공간이 있다고 표시되지만 저장 공간 부족: 약 15GB의 공간이 부족하여 재설치 불가.

os 재설치 실패

2-4. 복구 모드 응급 조치 (용량 확보 -> 부팅 성공) (08-18 20:46 KST)

주의: 이 절의 명령은 복구 모드(RecoveryOS) 터미널에서 실행한 것으로, rm -rf는 확인 절차 없이 즉시 삭제합니다. 일반 부팅 상태에서 그대로 실행하면 경로가 달라 의도치 않은 파일이 지워질 수 있습니다. 실행 전 ls로 대상 경로를 반드시 먼저 확인하고, 볼륨 이름(Data, Macintosh HD)이 본인 환경과 같은지 점검하시기 바랍니다.

캐시 비워서 즉시 수 GB 확보하기 계정명을 직접 찾아 지우는 대신, 아래 명령어로 모든 계정의 불필요한 시스템/앱 캐시를 한 번에 날려 여유 공간을 확보합니다:

rm -rf /Volumes/Data/Users/*/Library/Caches/*

01. 휴지통 비우기

rm -rf /Volumes/Data/Users/*/.Trash/*

02. 브라우저 캐시 및 임시 파일 삭제

rm -rf /Volumes/Data/Users/*/Library/Application\ Support/Google/Chrome/Default/Service\ Worker/CacheStorage/*
rm -rf /Volumes/Data/Users/*/Library/Application\ Support/Google/Chrome/Default/Application\ Cache/*

03. 스냅샷 목록 확인 및 삭제

스냅샷 목록 확인

diskutil apfs listSnapshots /Volumes/Data

스냅샷 삭제

diskutil apfs deleteSnapshot /Volumes/Data -name "스냅샷이름"
diskutil apfs deleteSnapshot /Volumes/Data -name com.apple.TimeMachine.2026-08-18-111103.local

04. OS 재설치 실패 : 개인 맞춤화 실패 (TSS 인증 오류)

"소프트웨어 업데이트를 개인 맞춤화하는 데 실패했습니다. 선택한 업데이트를 다운로드하는 동안 오류가 발생했습니다. 인터넷 연결을 확인하고 다시 시도하십시오."

분석: 디스크 용량 고갈 및 마운트 락(Lock)으로 인해 파일 시스템 마운트를 담당하는 커널 에이전트의 디스크 용량 고갈 및 마운트 락으로 인해 마운트가 거부되었습니다. 인터넷 오류 창이 뜬 것은 실제 Wi-Fi 문제가 아니라, 로컬 디스크의 I/O 타임아웃 및 남겨진 미완성 서명 캐시 때문에 보안 티켓 발급 과정이 꼬였기 때문이다.

rm -rf /Volumes/Data/macOS\ Install\ Data
rm -rf /Volumes/Macintosh\ HD/macOS\ Install\ Data
rm -rf /Volumes/Data/private/var/folders/*

디스크 동기화

sync

이 에러(Failed to personalize the software update)는 OS 다운로드는 다 끝났으나, 마지막 단계에서 애플 인증 서버(TSS)와 통신해 기기 고유 암호화 서명(Personalization Ticket)을 받아오는 과정에서 통신이 차단되어 실패

시스템 시간 강제 동기화 시도

sntp -sS time.apple.com

받다 만 잔여 파일 정리

rm -rf /Volumes/Data/macOS\ Install\ Data
rm -rf /Volumes/Macintosh\ HD/macOS\ Install\ Data

재부팅 후 정상 부팅 성공 일시적인 무결성 검증 락일 가능성이 높다 추측했습니다.

05. 애플 진단(Apple Diagnostics) 실행

Mac Resource Inspector (MRI): 메인보드, CPU, RAM, SSD, 전원 컨트롤러 등 핵심 하드웨어 및 시스템 무결성을 종합적으로 빠르게 전수 검사하는 애플 공식 진단 도구입니다.

일반 충전기를 꽂아두고 있었어서 뜨는 배터리 경고와 최신OS가 아니어서 생긴 소프트웨어 경고 문구외에는 모두 정상으로 확인되었습니다.

06. OS 업데이트 진행 불가

부팅 성공 후 소프트웨어 문제인가 하고 OS 업데이트를 진행하려 했으나 업데이트가 진행이 안되었습니다.

2-5. 애플 지니어스바 예약 및 방문 (08-20 11:35 KST)

26.08.20 (목요일), 오전 11:35 Apple 명동

케이스 ID : ~~20000140847830~~

01. OS 클린설치 진행

직원 분께 구체적인 타임라인 설명과 함께 sleep 모드 전환시에 오류 로그가 찍히고 기본 진단MRI를 돌려봤을때 정상으로만 나온다.라고 구체적으로 설명을 한 후 우선 OS 문제일 가능성이 있으니 OS 클린 설치를 진행하기로 안내받고 클린 설치를 진행했습니다.

02. OS 클린 재설치 완료 및 현장 복구 진행

Apple 명동 센터로부터 OS 클린 설치가 완료되었다는 연락(08-20 13:37 KST)을 받고 방문하여 기기를 수령했습니다. 이후 현장에서 외장 SSD에 백업해둔 타임머신 데이터로 환경 복원을 진행했습니다.

03. 현장 로그 확인 및 동일 에러 재발

데이터 복원 직후 현장에서 커널 통합 로그를 조회한 결과, 수리 이전과 동일하게 status - 0xe00002c9 (타임아웃) 및 eccWidgetLLTShadow (하드웨어 무결성 실패) 에러가 계속해서 기록되고 있음을 확인했습니다. (참고: 이 시점의 로그는 이후 소프트웨어 요인을 완벽히 배제하기 위해 개인적으로 진행한 2차 클린 설치 과정에서 보존 기한 만료로 소거되었습니다. 하지만 이후 사용자 데이터가 전혀 없는 '깡통 상태'의 클린 설치 직후에도 동일한 하드웨어 오류가 뿜어져 나오는 것을 확인했으므로, 타임머신 복원이 원인이라는 설명은 성립하지 않습니다.)

04. 현장 대처의 한계

현장에서 해당 커널 패닉 로그를 제시했으나, 담당 엔지니어는 "로그에 대해서는 깊이 알지 못하며, 타임머신 복원 과정에서 기존 시스템의 잘못된 찌꺼기 데이터가 들어와 발생한 문제일 수 있다"는 기술적으로 타당하지 않은 답변을 제시하였습니다.

05. 향후 대응 계획 수립

애플 오프라인 센터의 현장 매뉴얼 상, 기본 하드웨어 진단 툴(MRI)만 통과하면 심층적인 커널 단위의 장애는 자체적인 대처가 불가능하다는 구조적 한계를 느꼈습니다. 현장에서의 더 이상의 무의미한 감정 소모를 피하기 위해 일단 기기를 수령하여 매장을 나왔습니다. 이후 완벽한 클린 설치 상태에서 하드웨어 결함 로그를 다시 추출하여, 오프라인 센터를 우회하고 애플 고객센터의 시니어 어드바이저(Senior Advisor)에게 직접 에스컬레이션하는 것으로 계획을 변경했습니다.

2-6. 타임머신 배제 재검증 (08-21 11:30:19 KST)

지니어스바의 프로덕션 매니저?의 말대로 타임머신 복구로 인해 찌거기 데이터가 다시 들어왔을 가능성을 확인하기 위해 소거법으로 접근하기 위해 다시 초기화를 진행하여 이번에는 타임머신 복구를 진행하지 않고 로그를 찍어보기로 했습니다.

로그 분석 결과로는 설치 절차 자체의 정상 완료되었습니다. 하지만 직후 다시 오류 로그가 발생하였습니다.

상세 로그 분석 → [Apple Mac] 타임머신 제외 초기 상태에서 로그 분석

사용자 데이터가 전혀 없는 상태에서 같은 오류가 나온 이상, "타임머신 복원 과정에서 들어온 데이터가 원인"이라는 현장 설명은 성립하지 않습니다.

2-7. 타임머신 복원 후 7일 경과 지속성 재검증 (08-29)

2-6의 검증(타임머신 미복원)을 마친 뒤, 실제 사용을 위해 같은 날 저녁 OS를 다시 설치하고 타임머신으로 데이터를 복원했습니다(08-21 20:29 완료). 이 상태로 재부팅 없이 일주일을 사용한 시점에 다시 로그를 수집했습니다.

이번 측정의 목적은 두 가지였습니다. 하나는 타임머신을 복원한 환경에서도 오류가 발생하는지 확인하는 것으로, 2-6에서 "복원하지 않은 경우"를 이미 확인했으므로 반대편 조건까지 채우면 복원 여부와 오류가 무관하다는 점이 양쪽에서 확인됩니다. 다른 하나는 시간이 지나면 개선되는지 보는 것이었습니다.

결과적으로 오류는 사라지지 않았고, 24시간 기준 발생 횟수는 79회에서 105회로 늘었습니다. 오류 시퀀스는 최초 관측 시점과 완전히 동일했으며, SSD 펌웨어 리비전(561.100)도 그대로였습니다. 이번에는 커널 로그만이 아니라 전원 관리 로그(pmset)와 장치 상태(system_profiler)를 함께 수집해 서로 다른 계층의 기록을 교차 대조했고, 오류 105건 전부가 전원 전환 이벤트 1초 이내에 발생한다는 사실을 확인했습니다.

상세 로그 분석 → [Apple Mac] 타임머신 복원 후 7일 경과 지속성 재검증

2-8. 고객센터를 연락을 위한 사전준비

sysdiagnose 번들 확보 완료 (08-29 13:12 KST)

sudo sysdiagnose

This tool generates files that allow Apple to investigate issues with your
computer and help improve Apple products. The files might contain personal
information found on your device or associated with your Apple Account(s),
including but not limited to your name, serial numbers of your device,
your device name, your attached peripheral devices, your user name, your
email address and email settings, file paths, file names, Siri suggestions,
your computer's IP addresses, network connection information, and profiles
installed to your device.
 
This information is used by Apple in accordance with its privacy policy
(www.apple.com/privacy) and is not shared with any other company. By using
this tool and sending the results to Apple, you consent to Apple using the
contents of these files to improve Apple products.
 
Press 'Enter' to continue. Ctrl+\ to cancel.
 
Progress:
[|||||||||||||||||||||||||||||||||||||||100%|||||||||||||||||||||||||||||||||||]
 
Output available at '/private/var/tmp/sysdiagnose_2026.08.29_13-12-21+0900_macOS_Mac_25G83.tar.gz'.

sysdiagnose 란?

Apple 기기(iPhone, iPad, Mac 등)에서 시스템 로그, 진단 정보, 상태 파일을 모아 압축 파일로 생성하는 진단 도구

2-9. 선임 상담사와 연결 (08-29 14:48 KST)

상담 일시: 2026-08-29 14:48 KST

담당: 선임 상담사 (Senior Advisor / Tier 2)

접수 경로: Apple 지원 앱 (8월 20일 서비스 센터 방문 이력을 통한 추가 전화 지원 요청)

연락처: 02-6072-0201

약 40분 상담 진행

주요 상담 내용 및 결과

로그 및 외부 자료 전달 불가: 문의 시 외부 포스트나 수집한 오류 로그 파일 전달을 제안했으나, 상담사 측에서 별도로 접수받을 수 있는 경로가 없다고 안내하셨습니다.
추가 지원 제한 사유: 현재 시점에서 해당 문제가 실시간으로 재현/발생하지 않아 원격 또는 시스템상 즉각적인 추가 조치가 어려다는 것을 알게되었습니다.
- 결국에는 로그가 아닌 눈에 보이는 현상이 있어야 된다는 것을 다시 한번 확인하였습니다.
- "사용에 지장이 있는가" 이것이 핵심 문제
해결 및 대응 방안: 구버전 macOS로 다운그레이드한 뒤, 잠자기 상태에서 업데이트를 유도하여 동일 증상을 재현하는 방식으로만 추가 확인 및 지원이 가능함을 안내받았습니다.
상담사가 안내한 구버전 OS 설치 링크 https://support.apple.com/ko-kr/101578

2-10. OS 다운그레이드 재설치 준비

새로운 시나리오

상담사와 상담 진행을 통해 결국 해당 하드 프리징 현상을 재현하는 방법 밖에 없다고 판단.

다운그레이드를 준비중 새로운 시나리오가 떠올랐다.

해당 근거는 다음과 같다.

이번 OS 업데이트 이전에는 해당 이슈가 발생한 적이 없다.
OS 클린 설치 한 이후 오류 로그는 뜨지만 해당 현상은 발생하고 있지 않다.
08-16 패닉(잠자기 중 스스로 재부팅)은 한번만 발생하고 이후 발생된 적이 없다.
그래서 이번 다운그레이드를 통해 2가지 사실을 확인하려 한다
- OS 업데이트 과정에서만 발생하는 오류인지
- OS 버전 문제인지

현재 진행된 소거법

변수	검증 여부
사용자 데이터	배제됨 3번 문서
설치상태	재설치 3회
OS버전	현상은 전버전에서만 로그는 현재와 직전 버전에서만 확인 그 이전은 확인해본적이 없어 확인 불가능
하드웨어	소거법의 마지막 수단

하드웨어 문제임을 입증하려면 결국 OS 변수와 업데이트 과정에서만 발생하는 현상인지 확인해야됨

재현 시나리오

목적은 하드웨어를 고정한 채 macOS 버전만 바꾸는 것입니다. 내장 SSD를 다시 밀면 현재 남아 있는 로그 증거까지 사라지므로(이미 세 차례 재설치로 .panic 파일이 소실된 전례가 있습니다), 외장 SSD에 이전 버전을 설치해 그쪽으로 부팅한 뒤 동일한 오류가 기록되는지 확인합니다.

1) 외장 부팅으로 내장 컨트롤러를 검증할 수 있는 이유

"외장으로 부팅하면 내장 SSD가 검사 대상에서 빠지는 것 아닌가"라는 의문이 들 수 있으나, Apple Silicon에서는 그렇지 않습니다.

컨트롤러가 SoC 안에 있습니다. 문제의 AppleANS2NVMeController는 교체 가능한 부품이 아니라 M3 Pro 다이에 통합된 NAND 컨트롤러입니다. 부팅 볼륨이 어디에 있든 커널이 올라오면 항상 attach됩니다.
외장 부팅에도 내장 스토리지가 필수입니다. Apple Silicon은 부팅 정책(LocalPolicy)과 iBoot, Preboot 자료를 내장 스토리지에서 읽습니다. 내장 드라이브를 거치지 않는 외장 부팅 자체가 성립하지 않습니다.
전원 전환이 동일하게 적용됩니다. 잠자기·기상 시 내장 컨트롤러도 다른 장치와 똑같이 PowerStateAction을 받습니다. 부팅 볼륨이 외장이라고 해서 내장 컨트롤러가 전원 관리 대상에서 빠지지 않습니다.

내장 컨트롤러가 현재도 전원 관리 대상으로 등록되어 있다는 것은 다음으로 확인됩니다.

ioreg -rc AppleANS2NVMeController -d1 | grep IOPowerManagement

"IOPowerManagement" = {"DevicePowerState"=1,"CurrentPowerState"=1,"CapabilityFlags"=32768,"MaxPowerState"=1,"DriverPowerState"=1}

따라서 이 시나리오에서 바뀌는 변수는 macOS 버전 하나뿐이고, 컨트롤러·펌웨어(561.100)·PCIe 링크는 그대로 유지됩니다. 단일 변수 실험이 성립합니다.

2) 대상 버전 선정

softwareupdate --list-full-installers로 확인한 설치 가능한 버전은 다음과 같습니다.

버전	빌드	상태
26.6.2	25G83	현재 — 오류 확인됨
26.6.1	25G76	직전 — 오류 확인됨
26.6	25G72	미확인 → 1차 시험 대상
26.5.2	25F84	미확인 → 2차 시험 대상
26.5.1	25F80	미확인
26.5	25F71	미확인

26.6.2와 26.6.1은 이미 오류가 관측된 버전이므로 제외하고, 아직 확인한 적이 없는 26.6(25G72) 부터 내려갑니다. 여기서도 오류가 남으면 26.5.2로 한 단계 더 내려갑니다.

3) 절차

외장 SSD에 이미 백업 데이터가 들어 있다면 디스크를 지우지 않고 볼륨만 추가합니다. APFS 컨테이너의 미할당 공간을 나눠 쓰므로 기존 볼륨은 그대로 유지됩니다.

# 1. 현재 상태 보존 — 재설치로 증거가 소실된 전례가 있으므로 먼저 확보
sudo sysdiagnose -f ~/Desktop
/usr/bin/log show --last 24h --predicate 'eventMessage CONTAINS "eccWidgetLLTShadow"' \
  --style compact > ~/Desktop/nvme-before.txt
 
# 2. 외장 컨테이너 식별 (diskN 확인)
diskutil list external
 
# 3. 시험용 볼륨 추가 (기존 볼륨은 유지됨)
diskutil apfs addVolume diskN APFS "TahoeTest"
 
# 4. 26.6 전체 설치 프로그램 내려받기
softwareupdate --fetch-full-installer --full-installer-version 26.6

내려받은 설치 프로그램은 /Applications에 생성됩니다. GUI로 실행하고 설치 대상에서 반드시 TahoeTest를 선택합니다. startosinstall --volume 플래그는 대상을 잘못 지정하면 내장 볼륨을 덮어쓸 수 있어 사용하지 않습니다.

설치 후에는 전원 버튼을 길게 눌러 시동 옵션에서 TahoeTest를 선택해 부팅합니다.

4) 판정 기준

외장 볼륨으로 부팅한 상태에서 2~3일간 평소처럼 사용하며 잠자기·기상을 반복시킨 뒤 집계합니다. 현재 확인된 발생 패턴이 잠자기 진입 1회당 정확히 1건이므로, 잠자기 횟수와 오류 횟수를 함께 세어 비율로 판정합니다.

# 오류 건수
/usr/bin/log show --last 3d --predicate 'eventMessage CONTAINS "eccWidgetLLTShadow"' \
  --style compact | grep -c "AppleNVMe Assert failed"
 
# 같은 기간 잠자기 진입 횟수 (분모)
pmset -g log | grep -c "Entering Sleep state"

결과	해석	다음 조치
오류 0건	26.6.1 이후 드라이버 회귀 가능성	Feedback Assistant 리포트, 업데이트 대기
비율이 뚜렷하게 낮아짐	OS 버전 의존성 존재	26.5.2로 한 단계 더 시험해 경계 지점 특정
비율이 그대로 100% 유지	OS 버전과 무관 — 하드웨어 요인	수리·교체 요구의 직접 근거로 사용

5) 이 방법의 한계와 보완

외장 부팅 중에는 내장 드라이브에 파일시스템 I/O가 거의 발생하지 않습니다. FTL 주소 변환 테이블의 갱신 빈도가 평소보다 낮아지므로, 오류가 줄어들더라도 그것이 OS 버전 때문인지 I/O 부하가 낮아졌기 때문인지 구분되지 않을 여지가 있습니다. 따라서 결과는 다음과 같이 비대칭적으로 읽습니다.

오류가 그대로 발생하면 — I/O가 거의 없는 조건에서도 재현된 것이므로 결론이 명확합니다(하드웨어 요인).
오류가 사라지면 — OS 요인이 유력하지만 단정할 수 없으므로, 내장 APFS 컨테이너에 시험용 볼륨을 추가해 같은 버전을 설치하고 재확인합니다. 이 경우 내장 드라이브의 I/O 조건까지 동일해지며, 기존 데이터와 로그는 그대로 보존됩니다.

# 내장 컨테이너의 미할당 공간 확인 후 볼륨 추가
diskutil apfs list disk3 | grep "Capacity Not Allocated"
diskutil apfs addVolume disk3 APFS "TahoeTest"

Apple Silicon은 macOS 설치본마다 페어링된 펌웨어를 함께 관리하므로, 하위 버전으로 부팅하면 관련 펌웨어도 함께 내려갑니다. 기기 출고 버전(Sonoma 14.x) 이상이면 지원되는 시나리오이지만 완전히 매끄럽다고 보장할 수는 없으므로, 위 절차 1번(현재 상태 보존)은 생략하지 않습니다.

3. 문제 발생 원인 종합 분석 결론

3-1. 지속 원인 — 컨트롤러 전원 전환 결함 (하드웨어)

내장 NVMe 컨트롤러가 전원 상태 전환(PowerStateAction) 과정에서 FTL 주소 변환 테이블의 무결성 검사에 실패하는 사례가 반복 관측됩니다.

전원 전환과의 결합: 오류 105건 전부(100%)가 전원 전환 이벤트 1초 이내에 발생했으며, 그중 절반 이상(59건)은 같은 초에 기록되었습니다. 특정 앱이나 디스크 사용량이 아니라 전원 전환 경로에 국한된 결함이라는 뜻입니다. → 04번 문서

실패율은 잠자기 사이클 기준 사실상 100% 입니다. pmset 로그의 Entering Sleep state 이벤트를 분모로 두고 재측정한 결과, 32.6시간 구간(08-28 00:21 ~ 08-29 08:57)에서 잠자기 진입 133건에 오류 133건이 대응해 비율이 정확히 1.00이었습니다. 즉 잠자기에 들어갈 때마다 매번 1건씩 실패합니다. → 04번 문서

앞서 인용하던 "전원 이벤트 1,281건"은 pmset 로그의 Sleep·DarkWake·Wake·어서션 기록을 모두 합산한 값이라 분모로 적절하지 않았습니다. 실제 잠자기 진입 횟수를 분모로 두면 일부가 아니라 전부입니다.

역방향 검증도 성립합니다 — 마지막 잠자기(08-29 08:54) 이후 8시간 30분 동안 시스템이 잠자기에 진입하지 않자 오류도 단 한 건도 기록되지 않았습니다. 잠자기가 없으면 오류도 없습니다.
오류 간 대응: eccWidgetLLTShadow와 0xe00002c9가 1:1로 정확히 대응합니다 (최초 측정 79:79, 재측정 105:105). 무결성 검사 실패가 곧바로 전원 전환 실패로 이어집니다. → 02번 문서
사용자 데이터 요인 배제: 타임머신을 복원하지 않은 클린 설치 상태(03번 문서)와 복원한 상태(04번 문서) 양쪽 모두에서 동일하게 재현됩니다. 현장에서 제기된 "복원 과정에서 유입된 데이터가 원인"이라는 설명은 양쪽 조건에서 성립하지 않습니다.
소프트웨어 요인 배제: OS를 세 차례 재설치하는 동안 오류가 사라진 적이 없고, 발생 빈도는 오히려 79회 → 105회로 증가했습니다. SSD 펌웨어 리비전(561.100) 역시 재설치로 갱신되지 않았습니다.
물리 계층 전조: 최초 증상(08-16)은 PCIe 링크 자체가 끊어진 패닉이었습니다(ltssm=DETECT_QUIET). 드라이버 로직이 아니라 버스·컨트롤러 쪽 문제로 보입니다.

전원 전환이라는 특정 경로에서만, 한 달 넘게, 세 차례의 재설치에도 불구하고 같은 실패가 반복된다는 것은 일시적인 레이스 컨디션으로 보기 어렵습니다. 컨트롤러 또는 낸드가 정상 동작 마진을 벗어난 상태라는 쪽에 훨씬 더 가깝습니다.

eccWidgetLLTShadow의 정확한 의미는 Apple 비공개 영역이라 명명 규칙에 근거한 추정입니다 (상세는 02번 문서). 다만 이름의 해석과 무관하게, 해당 assert가 실패하고 그 결과로 전원 전환 함수가 kIOReturnInternalError를 반환했다는 사실 자체는 로그에 그대로 기록되어 있습니다.

3-2. 1회성 사건 — 하드프리징 & 복구 모드로 간 이유 (3중 충돌)

01. 로그에 명확히 남아있는 '잠자기 중 백그라운드 업데이트' 증거

앞서 확인한 커널 로그를 보면 사용자가 맥북을 쓰지 않고 덮어둔 시간대(새벽/오전)에 macOS 업데이트 관련 시스템 프로세스가 백그라운드에서 반복 실행되고 있었습니다.

아래는 2번 문서의 전체 로그에서 발췌한 실제 기록입니다.

com.apple.MobileSoftwareUpdate의 반복 호출:

2026-08-17 22:18:54.869146 kernel: (apfs) apfs_log_op_with_proc:3227: disk3s1 unmounting volume Macintosh HD, requested by: com.apple.MobileSoftwareUpdate. (pid 47498); parent: launchd (pid 1)

잠자기(Power Nap/DarkWake) 상태에서 시스템이 주기적으로 깨어나 macOS 백그라운드 업데이트 데몬(MobileSoftwareUpdate)을 실행했습니다.

시스템 볼륨의 암호화 봉인 해제 및 롤백:

2026-08-17 22:18:54.825207 kernel: (apfs) authapfs_seal_break:504: disk3s1 integrity protection will be disabled (from xid: 4043662)
2026-08-17 22:18:54.867464 kernel: (apfs) handle_revert_to_snapshot:8149: disk3s1 On next mount, volume will revert to snapshot 'com.apple.os.update-[REDACTED]'

업데이트 패치를 준비하기 위해 메인 디스크 봉인을 일시 해제(authapfs_seal_break: disk3s1 integrity protection will be disabled)하고, 업데이트 스냅샷을 마운트했다가 다시 복원(revert_to_snapshot)하는 작업이 끊임없이 일어났습니다.

타임머신 로컬 스냅샷 생성(backupd):

2026-08-17 22:46:47.193142 kernel: (apfs) apfs_snap_vnop_remove:1106: disk3s5 proc backupd: deleting snapshot name (com.apple.TimeMachine.2026-08-16-204134.local) w/xid 4025179

업데이트 전 롤백 지점을 만들기 위해 시간 단위로 수 기가바이트의 APFS 로컬 스냅샷(com.apple.TimeMachine...)을 디스크에 계속 생성했습니다.

02. 충돌이 일어난 구체적인 인과관계 시나리오

디스크 용량 임계치 도달: 맥북이 덮여 있는 동안 백그라운드에서 대용량 업데이트 파일 다운로드 + 타임머신 로컬 스냅샷이 쌓이면서 디스크 여유 공간이 한계(15GB 미만)까지 떨어짐.

잠자기 진입과 SSD 전원 차단 충돌:

백그라운드 업데이트 데몬이 디스크에 대용량 스냅샷과 패치 데이터를 쓰고 있던 찰나에, 전원 관리자(PMRD)가 맥북을 다시 깊은 잠자기(Deep Sleep) 상태로 전환하려 하였습니다.

내장 NVMe 컨트롤러가 I/O 작업을 미처 다 끝내지 못한 상태에서 전원 차단 명령을 받아 AppleANS2NVMeController PowerStateAction 0xe00002c9 타임아웃이 발생했습니다.

부팅 보안 서명(Seal) 손상:

authapfs_seal_break로 시스템 볼륨 무결성 검증이 일시적으로 풀린 상태에서 SSD가 타임아웃으로 비정상 종료되었습니다.

덮개를 열었을 때 복구 화면 직행:

사용자가 맥북을 열었을 때, 보안 칩(Secure Enclave)이 "시스템 볼륨의 정식 서명 해시가 일치하지 않는다"고 판단하여 일반 부팅을 막고 복구 OS(Recovery)로 강제 우회 부팅시켰습니다.

03. 정리

08-18의 하드 프리징과 복구 모드 강제 진입은, 3-1의 컨트롤러 결함이 ① 백그라운드 자동 업데이트로 SSV 봉인이 해제된 상태, ② 타임머신 로컬 스냅샷 누적으로 잔여 용량이 임계치에 도달한 상태와 겹치면서 발생한 것으로 보입니다. 봉인이 풀린 채 쓰기가 진행되던 중 컨트롤러가 응답 불능에 빠져 부팅 서명 검증이 실패했고, 터미널로 엉킨 설치 데이터(macOS Install Data)를 삭제해 용량을 확보하자 정상 부팅이 회복된 것이 이를 뒷받침합니다.

다만 이는 그날 복구 모드로 진입한 이유를 설명할 뿐, 전원 전환마다 발생하는 컨트롤러 오류 자체를 설명하지는 않습니다. 용량 확보와 자동 업데이트 차단은 재발 조건을 줄일 뿐 원인을 제거하지 못합니다.

4. 재현 절차

전원 어댑터 연결, 덮개 닫음(또는 pmset sleepnow)
5~15분 대기

아래 명령으로 로그 확인

log show --predicate 'eventMessage contains "eccWidgetLLTShadow"' --last 1h

5. 조치 내역

6. 현재 상태 및 향후 계획

2026-08-29 기준 오류는 계속 기록되고 있습니다. 최근 32.6시간 구간에서 잠자기 진입 133건에 오류 133건으로, 잠자기에 들어갈 때마다 빠짐없이 발생하고 있습니다. 일상 사용에 체감되는 지장은 없으나 잠자기 관련 불안정이 재발할 가능성이 남아 있습니다.

2026-08-29

다운그레이드 계획: 당초 macOS Sequoia까지 내려갈 계획이었으나, 문제가 Tahoe 내 업데이트를 기점으로 나타났다는 점과 softwareupdate --list-full-installers로 26.6 · 26.5.x 전체 설치본을 받을 수 있다는 점을 확인해, Tahoe 26.6(25G72) 을 1차 대상으로 조정했습니다. Sequoia보다 훨씬 작은 폭의 변경만으로 OS 버전 변수를 분리할 수 있습니다.

설치 방식: 내장 SSD를 다시 밀면 남아 있는 로그 증거까지 사라지므로, 외장 SSD에 시험용 APFS 볼륨을 추가해 설치하고 그쪽으로 부팅합니다. 내장 컨트롤러는 SoC에 통합되어 있어 외장 부팅 상태에서도 동일하게 전원 전환을 받으므로 검증이 성립합니다. 상세 절차는 2-10 재현 시나리오를 참고해 주세요.

판정 지표: 잠자기 진입 횟수 대비 오류 발생 비율(현재 1.00). 이 비율이 유지되면 OS 버전과 무관한 하드웨어 요인, 뚜렷하게 낮아지면 OS 버전 의존성으로 판단합니다.

7. 참고: 유사 선례 (본 건과 직접 관련 없음)

아래는 Apple SSD 및 저장장치 컨트롤러 계층의 결함이 표준 진단으로 검출되지 않았던 과거 사례입니다. 본 건과 에러 시그니처가 다르므로 동일한 사안으로 볼 수 없으며, 어디까지나 참고용으로 정리합니다.

7-1. T2 칩 / bridgeOS 잠자기 재부팅 (2018 ~ 2020)

iMac Pro와 2018년형 MacBook Pro(Touch Bar)에서 잠자기 중 예고 없는 재부팅이 다수 보고되었습니다. 원인은 SSD 암호화와 보안 부팅을 담당하는 T2 칩 펌웨어(bridgeOS)로 지목되었고, Thunderbolt 기기 연결 여부나 Power Nap 설정에 따라 재현 조건이 달라졌습니다.

보도 시점 기준으로 애플은 이 문제를 공식 인정하지 않았으며, 개별 고객에게 클린 OS 재설치 또는 하드웨어 교체로 대응한 것으로 전해집니다.

Notebookcheck, "Apple T2 chip causing kernel panics in few 2018 MacBook Pros and iMac Pros" (2018-11): https://www.notebookcheck.net/Apple-T2-chip-causing-kernel-panics-in-few-2018-MacBook-Pros-and-iMac-Pros.318532.0.html
MacRumors Forums, "2018 MacBook Pros crashing with 'Bridge OS' error" (장기 스레드): https://forums.macrumors.com/threads/2018-macbook-pros-crashing-with-bridge-os-error.2128976/

본 건과의 차이: 위 사례는 T2 칩 펌웨어(bridgeOS) 패닉이고, 본 건은 AppleANS2NVMeController의 전원 상태 전환 Assert 실패입니다. 다만 잠자기 관련 저장장치 컨트롤러 문제가 표준 진단을 통과한 채 존재했다는 점, 그리고 현장 대응이 클린 설치 → 하드웨어 교체 순서였다는 점이 참고할 만합니다.

7-2. NVMe SSD Standby 모드 전환 시 커널 패닉

저장장치 주변기기 제조사 OWC(MacSales)가 자사 기술문서에 정리해 둔 사례입니다. Mac이 잠자기 상태에서 일정 시간이 지나 Standby 모드로 전환된 뒤 복귀하는 과정에서 커널 패닉이 발생하는 현상으로, 패닉 로그에 IONVMeController::HandleControllerPowerOff가 기록됩니다. 해당 문서는 회피책으로 Standby 모드 자체를 끄는 것을 안내합니다.

sudo pmset -a standby 0

OWC / MacSales Knowledge Base, "NVMe SSDs: Standby Mode Issue": https://eshop.macsales.com/Service/Knowledgebase/Article/26/785/NVMe-SSDs-Standby-Mode-Issue
Apple Community, "Pertaining to standby, autopoweroff, and hibernatemode": https://discussions.apple.com/thread/251462236

본 건과의 차이: 위 사례는 서드파티 NVMe SSD(OWC Aura 계열)를 부팅 볼륨으로 사용하는 Intel Mac 환경이고, 본 건은 애플 정품 내장 SSD를 탑재한 Apple Silicon 환경입니다. 대상 하드웨어가 다르므로 같은 사안으로 볼 수 없습니다.

두 사례에서 실패하는 함수가 모두 NVMe 드라이버의 전원 상태 전환 경로에 있다는 점은 참고할 만합니다. 본 건의 AppleANS2NVMeController::PowerStateAction과 위 사례의 IONVMeController::HandleControllerPowerOff는 각각 전원 상태 변경과 컨트롤러 전원 차단을 담당합니다.

참고로 본 문서의 측정 시점(08-29) 기준, 대상 기기의 전원 관리 설정은 다음과 같았습니다.

standby         1
hibernatemode   3
powernap        1
disksleep       10

Standby와 Power Nap이 모두 활성화된 상태이며, 이는 위 사례가 지목한 조건과 일치합니다. 다만 본 건은 Standby 진입 시점(잠자기 후 약 3시간)에 한정되지 않고 전원 전환이 일어나는 시점마다 불규칙하게(간격 중앙값 약 16분) 발생하므로, Standby 모드만으로 설명되지는 않습니다.

7-3. `eccWidgetLLTShadow` 검색 결과

AppleNVMe Assert failed 검색 결과는 대부분 비공식 macOS 환경(Hackintosh)이나 서드파티 NVMe 교체 사례로, 애플 정품 내장 SSD에서 발생한 본 건과는 조건이 다릅니다.

Apple Community, "Sleep Wake failure - issue with IONVMeFamily": https://discussions.apple.com/thread/250452633

로그 수정 사항

개인정보 및 보안을 위해 민감한 정보는 제거한 자료입니다.

[REDACTED] 로 변경한 내역

사용자명
호스트명
SSD 시리얼 넘버
개인 파일명