윈도우 및 맥 다운됐을 때 AI 에이전트로 원인 해결 방법 | 이벤트 로그·블루스크린 덤프·맥 패닉 리포트 분석부터 해결까지

컴퓨터가 작업 중에 갑자기 꺼지거나 파란 화면을 띄우고 재시작하면, 대부분은 전원 버튼을 다시 누르고 하던 일을 이어 간다. 그런데 같은 일이 하루에 두세 번 반복되면 이야기가 달라진다. 큐레이터 단비가 보기에 이때 가장 흔한 실수는 원인을 모르는 채로 드라이버 업데이트, 윈도우 재설치, 부품 교체부터 손대는 것이다. 다운에는 거의 항상 흔적이 남는다. 윈도우는 이벤트 로그와 미니덤프(.dmp)에, 맥은 패닉 리포트(.panic·.ips)와 통합 로그에 마지막 순간을 기록한다.

문제는 이 기록이 초보자에게 너무 어렵다는 점이다. 이벤트 ID는 숫자뿐이고, 덤프 분석 결과는 16진수 주소와 함수 이름으로 가득하다. 여기서 Cursor, Claude Code, Codex, Grok 같은 AI 에이전트가 힘을 발휘한다. 로그를 읽기 전용으로 모아서 넘기면, 에이전트는 수백 줄의 이벤트에서 다운 시각을 맞춰 보고, 덤프 스택에서 반복되는 드라이버 이름을 골라내고, 공식 문서의 스톱 코드 설명과 연결해 원인 후보를 좁혀 준다. 2026년 10월에는 Microsoft가 WinDbg 안에 AI 연결용 WinDbg MCP를 넣으면서, 자연어로 덤프를 분석하는 방식이 공식 도구에도 들어왔다.

이 문서는 윈도우와 맥에서 다운 유형을 먼저 구분하는 법, 이벤트 뷰어·신뢰성 모니터·미니덤프·WinDbg로 원인을 찾는 법, 맥 패닉 리포트에서 panicked task와 커널 확장 줄을 읽는 법, 그리고 이 과정을 AI 에이전트에게 맡길 때 무엇을 넘기고 무엇을 막아야 하는지를 순서대로 묶었다. 명령어는 모두 복사해서 붙여 넣을 수 있는 읽기 전용 위주로 골랐다.

핵심 포인트: 다운 원인 찾기는 증상 구분 → 로그 수집 → 덤프·패닉 분석 → 원인 후보 한 개씩 제거 순서로 간다. AI 에이전트는 로그를 읽고 패턴을 찾는 데 강하지만, 레지스트리 수정·드라이버 삭제 같은 변경은 사람이 확인한 뒤에만 실행해야 한다.

1. 다운 유형 네 가지 구분하기

「컴퓨터가 다운됐다」는 말에는 성격이 전혀 다른 네 가지 상황이 섞여 있다. 유형마다 남는 로그가 다르고, 의심할 원인도 다르다. 그래서 첫 단계는 어떤 다운이었는지 로그로 판정하는 것이다.

그림 1. 전원 꺼짐·블루스크린·멈춤·계획 재시작을 이벤트 ID와 패닉 리포트로 가르는 기준.

판정 순서는 간단하다.

• 1074가 다운 직전에 있으면 윈도우 업데이트나 프로그램이 정상적으로 재시작을 요청한 것이다. 1074 메시지 안에 재시작을 요청한 프로세스 이름이 들어 있다.
• 41과 6008이 함께 있으면 깨끗하게 종료되지 않은 비정상 종료다. 여기서 41의 BugcheckCode가 0인지 아닌지로 블루스크린과 전원 꺼짐이 갈린다.
• 1001(BugCheck)이 있으면 블루스크린이 확정이다. 메시지에 스톱 코드와 덤프 저장 위치가 같이 적힌다.
• 맥은 패닉 리포트가 생겼는지가 첫 갈림길이다. 리포트가 있으면 커널 패닉, 없으면 전원·강제 종료 쪽을 본다.

2. 윈도우 이벤트 뷰어에서 먼저 볼 이벤트 ID

이벤트 뷰어는 시작 메뉴에서 eventvwr.msc로 연다. Windows 로그 → 시스템에서 다운 시각 앞뒤 10분만 보면 대부분의 단서가 나온다. 아래 표의 ID는 Microsoft Learn 문서가 예기치 않은 재부팅을 판정할 때 쓰는 번호들이다.

2.1. Kernel-Power 41을 읽는 세 가지 경우

Microsoft Learn은 41을 세 가지 상황으로 나눈다. 41 이벤트를 열고 세부 정보 탭을 보면 된다.

1. BugcheckCode에 0이 아닌 숫자가 있다 — 블루스크린으로 재부팅된 경우다. 이 값은 10진수라서 16진수로 바꿔야 스톱 코드가 된다. 예를 들어 209는 0xD1, 80은 0x50, 292는 0x124다. 윈도우 계산기의 프로그래머 모드나 AI 에이전트에게 바꿔 달라고 하면 된다.
2. PowerButtonTimestamp에 값이 있다 — 사용자가 전원 버튼을 길게 눌러 끈 경우다. 즉 화면이 멈춰서 강제로 껐다는 뜻이고, 원인은 멈춤 쪽에서 찾는다.
3. 두 값이 모두 0이다 — 전원이 순간적으로 끊겼거나(정전·파워 불량·케이블), 시스템이 완전히 굳어 기록할 틈이 없었던 경우다. 과열, 파워 용량 부족, 오버클럭, 메모리 불량이 대표 원인이다. 이때 volmgr 46이 같이 있으면 블루스크린이었는데 덤프를 못 남긴 것일 수도 있다.

2.2. 신뢰성 모니터로 한 장에 보기

이벤트 뷰어가 부담스럽다면 신뢰성 모니터가 더 쉽다. 실행 창(Win+R)에 perfmon /rel을 넣으면 날짜별 안정성 그래프가 나온다.

• 빨간 X는 「Windows가 올바르게 종료되지 않았습니다」, 「하드웨어 오류」, 앱 충돌이다.
• 파란 i는 업데이트·드라이버 설치 기록이다. 다운이 시작된 날 직전에 무엇이 설치됐는지가 한눈에 보인다.
• 항목을 누르면 「기술 세부 정보」에 스톱 코드(BugcheckCode)와 매개변수가 나온다. 이 화면을 캡처해 AI 에이전트에게 넘겨도 좋은 출발점이 된다.

3. 미니덤프 위치와 관리자 권한으로 복사하기

블루스크린이 나면 윈도우는 메모리 상태를 덤프 파일로 남긴다. 설정에 따라 저장 위치가 다르다.

덤프 설정은 시스템 속성 → 고급 → 시작 및 복구 → 설정에서 확인한다. 「자동으로 다시 시작」 아래 디버깅 정보 쓰기가 「없음」이면 덤프가 남지 않으니 「작은 메모리 덤프」나 「자동 메모리 덤프」로 둔다.

3.1. 관리자 권한으로 덤프 복사

C:\Windows\Minidump 폴더는 일반 권한으로 열면 막힌다. AI 에이전트도 보통 일반 사용자 권한으로 동작하기 때문에, 사람이 관리자 PowerShell로 한 번 복사해 주는 것이 가장 깔끔하다.

1. 시작 메뉴에서 PowerShell을 오른쪽 클릭하고 관리자 권한으로 실행을 고른다.
2. 작업 폴더를 만든다: New-Item -ItemType Directory -Force $env:USERPROFILE\crashdiag\dump
3. 덤프를 복사한다: Copy-Item C:\Windows\Minidump\*.dmp $env:USERPROFILE\crashdiag\dump\
4. 일반 사용자도 읽을 수 있게 권한을 준다: icacls $env:USERPROFILE\crashdiag\dump /grant ${env:USERNAME}:F /T
5. 이제 에이전트에게는 원본 폴더가 아니라 복사본 폴더 경로만 알려 준다.

복사본으로 작업하면 원본 덤프를 실수로 지우거나 고칠 일이 없고, 에이전트에게 관리자 권한을 줄 필요도 없다.

4. WinDbg !analyze -v 결과 읽는 법

덤프는 Microsoft Store의 WinDbg로 연다. File → Open dump file로 .dmp를 열고, 심볼 경로가 Microsoft 공개 심볼 서버(`https://msdl.microsoft.com/download/symbols`)로 잡혀 있는지 확인한 다음, 명령 창에 !analyze -v를 입력한다. Microsoft Learn은 이 결과의 STACK_TEXT 부분에서 크래시를 일으킨 모듈을 찾으라고 안내한다.

명령줄로 돌리고 싶다면 WinDbg와 함께 설치되는 kd.exe를 쓸 수 있다. 예시는 kd -z 덤프파일.dmp -c '!analyze -v; lm t n; q' 형태이고, 결과를 텍스트로 저장해 에이전트에게 넘기면 된다. 여기서 lm t n은 로드된 모듈 목록과 타임스탬프를 보여 줘서, 문제 드라이버의 빌드 날짜와 버전을 확인하는 데 쓰인다. 특정 모듈을 자세히 보려면 lmvm 모듈이름을 쓴다.

4.1. 덤프 여러 개를 함께 봐야 하는 이유

덤프 하나만 보면 우연일 수 있다. 같은 스톱 코드, 같은 함수, 같은 서드파티 드라이버가 덤프 세 개에서 반복되면 원인 후보로서 신뢰도가 크게 올라간다. 반대로 덤프마다 스톱 코드도 모듈도 제각각이면 특정 드라이버보다는 메모리·전원·과열 같은 하드웨어 쪽을 먼저 의심한다.

4.2. WinDbg MCP와 커뮤니티 MCP

Microsoft는 2026년 10월 6일 WinDbg MCP를 발표했다. WinDbg 1.2610.1001.0부터 들어 있고, AI 클라이언트가 열려 있는 WinDbg 세션에 연결해 자연어로 「이 덤프의 근본 원인과 근거, 남은 가정을 알려 달라」고 요청할 수 있다.

• 공식 지원 클라이언트는 VS Code의 GitHub Copilot과 GitHub Copilot CLI다. Codex·Claude Code는 별도 설정으로 쓸 수는 있지만, 프롬프트 주입 방어(XPIA)를 꺼야 해서 권장되지 않는다.
• 보안 모드(Secure mode)가 기본으로 켜져 .shell 같은 위험 명령을 막는다.
• Microsoft도 AI 분석 결과는 확정이 아니라 조사할 가설로 다루고, WinDbg 화면의 출력과 맞춰 본 뒤 조치하라고 안내한다.
• 커뮤니티 도구로는 cdb.exe·kd.exe를 감싸 덤프를 여는 오픈소스 mcp-windbg도 있다. 커널 덤프용 openkddump, 명령 실행용 runkdcommand 같은 도구를 제공한다.

5. 자주 보는 스톱 코드와 원인 범주

스톱 코드는 원인을 확정하지 않는다. 대신 어느 방향부터 볼지를 알려 준다. Microsoft는 스톱 오류의 약 75%가 잘못된 드라이버 때문이라고 본다.

0xD1·0x133처럼 NETIO.SYS나 tcpip.sys가 스택에 보이는 경우는 윈도우 네트워크 모듈 자체보다, 그 위에 끼어드는 서드파티 네트워크 필터 드라이버(VPN, 방화벽, 광고 차단, 백신·보안 프로그램, 은행 보안 모듈 등)가 원인인 경우가 많다. 스택에서 윈도우 기본 모듈 바로 옆에 있는 낯선 .sys 이름을 찾는 것이 요령이다.

6. 윈도우는 드라이버부터 하드웨어 순으로 해결

원인 후보를 찾았다면 한 번에 하나씩 바꾸고, 바꾼 뒤 며칠 지켜보는 것이 원칙이다. 여러 개를 한꺼번에 바꾸면 무엇이 효과였는지 알 수 없다.

6.1. 드라이버와 소프트웨어 쪽

1. 덤프가 지목한 드라이버의 제조사 최신 버전을 설치한다. 그래픽은 제조사 사이트, 메인보드 칩셋·랜·무선은 메인보드 제조사 지원 페이지가 기준이다.
2. 업데이트 직후 문제가 시작됐다면 장치 관리자에서 드라이버 롤백을 쓴다.
3. 네트워크 필터·보안 프로그램이 지목되면, 해당 프로그램 설정에서 필터링 드라이버 방식을 바꾸거나 기능을 끄고, 그래도 반복되면 제거 후 며칠 관찰한다.
4. 원인을 좁히기 어려우면 클린 부팅(서드파티 서비스·시작 프로그램 끄기)으로 소프트웨어 충돌 여부를 가른다.
5. 고급 단계로 verifier(드라이버 검증 도구)가 있지만, 일부러 블루스크린을 유발하는 도구라서 복원 지점을 만든 뒤에만 쓴다.

6.2. 시스템 파일·메모리·저장장치 점검

6.3. 온도·전원·BIOS

• 41 값이 0인 전원 꺼짐이 반복되면 파워 용량과 케이블, 멀티탭부터 본다. 고사양 그래픽카드는 순간 전력 소모가 커서 파워가 버티지 못하면 경고 없이 꺼진다.
• 렌더링·게임처럼 부하가 클 때만 꺼진다면 CPU·GPU 온도를 모니터링하고, 쿨러·먼지·서멀 상태를 확인한다.
• 오버클럭, XMP·EXPO 메모리 프로필, 언더볼트는 진단 기간 동안 기본값으로 돌린다. 0x124와 WHEA 18의 단골 원인이다.
• Microsoft 체크리스트는 BIOS·펌웨어 최신화와 디스크 여유 공간 10~15% 확보도 권한다. C 드라이브가 꽉 차면 덤프 저장과 업데이트가 실패할 수 있다.

7. 맥 패닉 리포트 찾는 곳과 읽는 법

맥이 예기치 않게 재시작하면 Apple은 이를 커널 패닉이라고 부르고, 다음 부팅 때 「문제가 발생하여 컴퓨터가 재시동되었습니다」 안내를 띄운다. Apple은 가장 흔한 원인을 잘못된 소프트웨어로 보고, 손상되거나 호환되지 않는 하드웨어(외부 장치 포함)도 원인이 될 수 있다고 설명한다.

콘솔 앱에서 시스템 보고서는 관리자 계정으로 로그인해야 보인다. 패닉 리포트가 콘솔에 바로 안 보일 때는 Finder로 폴더를 직접 여는 편이 확실하다.

7.1. 패닉 리포트에서 볼 줄

1. panic(cpu N caller ...) 첫 줄 — 패닉의 종류가 나온다. watchdog timeout, Kernel data abort 같은 문구가 원인 방향을 알려 준다.
2. panicked task — 패닉 순간 돌던 프로세스다. 특정 앱 이름이 반복되면 그 앱이나 그 앱이 쓰는 확장을 의심한다. kernel_task면 커널 내부 작업 중이다.
3. Kernel Extensions in backtrace — 역추적에 등장한 커널 확장(kext) 목록이다. com.apple로 시작하지 않는 이름이 있으면 서드파티 확장이 가장 유력한 후보다.
4. macOS 버전과 모델 정보 — 업데이트 직후부터 시작됐는지 판단하는 데 쓴다.
5. Compressor Info, 메모리 관련 줄 — 압축 메모리 한도가 100%에 가까우면 메모리 부족이 패닉으로 이어진 경우일 수 있다. 실제로 X에는 브라우저를 많이 쓰는 장시간 AI 에이전트 작업 중 맥이 두 번 패닉했고, 두 로그 모두 압축 메모리 한도 100%(BAD)가 찍혔다는 사용 사례가 올라왔다.

7.2. 통합 로그와 종료 원인

• 패닉 직전 상황은 터미널의 log show로 본다. 예: log show --last 30m --style compact | grep -i -E 'panic|watchdog|thermal'
• 다운 시각을 알면 범위를 정해서 본다. 예: log show --start '2026-10-17 20:00:00' --end '2026-10-17 20:10:00' --style compact
• 전원 관련 기록은 pmset -g log | grep -i -E 'shutdown cause|sleep cause'로 확인한다. Shutdown Cause 값이 정상 종료(5로 알려짐)가 아니면 강제 종료·전원 문제 쪽을 본다.

8. 맥은 안전 모드와 Apple 진단으로 가르기

Apple 공식 절차는 업데이트 → 안전 모드 → 서드파티 플러그인 제거 → 외부 장치 분리 → Apple 진단 → macOS 재설치 순서다. 칩 종류에 따라 키 조작이 다르다.

8.1. 커널 확장·시스템 확장 정리

1. 현재 로드된 서드파티 커널 확장은 kmutil showloaded --list-only | grep -v com.apple로 본다.
2. 최신 방식인 시스템 확장(네트워크 확장·엔드포인트 보안 등)은 systemextensionsctl list로 목록과 활성 상태를 본다.
3. 패닉 리포트의 Kernel Extensions in backtrace에 나온 이름과 위 목록을 맞춰 보면, 어떤 앱이 설치한 확장인지 대부분 알 수 있다.
4. 확장은 파일을 직접 지우지 말고, 그 앱의 제거 프로그램이나 시스템 설정 → 일반 → 로그인 항목 및 확장 프로그램에서 끈다.
5. VPN·방화벽·광고 차단·보안 프로그램의 네트워크 확장은 맥에서도 패닉의 단골 후보다. 하나씩 끄고 같은 작업을 반복해 재현 여부를 본다.

8.2. 활동 모니터로 재현 조건 찾기

• 메모리 탭의 메모리 압력 그래프가 빨간색으로 오래 머무르면 메모리 부족이 다운의 배경일 수 있다.
• CPU 탭에서 특정 프로세스가 오래 100% 가까이 점유하는지, 에너지 탭에서 앱별 부하를 본다.
• 외장 디스크·도크·허브를 연결했을 때만 패닉이 나면, Apple 안내대로 장치를 모두 분리했다가 하나씩 다시 연결해 범인을 찾는다.

9. AI 에이전트에게 맡기는 방법

AI 에이전트에게 다운 원인 분석을 맡길 때 핵심은 에이전트에게 읽기 좋은 형태로 증거를 모아 주는 것이다. 에이전트는 로그 수백 줄에서 시간을 맞추고, 스택에서 반복 모듈을 골라내고, 공식 문서의 스톱 코드 설명과 연결하는 일을 빠르게 한다.

9.1. 윈도우 읽기 전용 수집 명령

일반 PowerShell에서 실행해도 되는 명령들이다. 결과를 텍스트 파일로 저장해 에이전트에게 넘기면 된다.

1. 다운 관련 핵심 이벤트: Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,6008,1001,1074,46} -MaxEvents 60 | Format-List TimeCreated,Id,ProviderName,Message | Out-File $env:USERPROFILE\crashdiag\events.txt
2. 하드웨어 오류(WHEA): Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 50 | Format-List TimeCreated,Id,Message | Out-File $env:USERPROFILE\crashdiag\whea.txt
3. 그래픽·디스크 경고: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4101,7,51,129,153} -MaxEvents 80 | Format-List TimeCreated,Id,ProviderName,Message | Out-File $env:USERPROFILE\crashdiag\disk-gpu.txt
4. 설치된 드라이버 패키지: pnputil /enum-drivers > $env:USERPROFILE\crashdiag\drivers.txt
5. 시스템 기본 정보: systeminfo > $env:USERPROFILE\crashdiag\systeminfo.txt (호스트 이름·사용자 이름이 들어가니 공유 전 지운다)
6. 덤프는 앞의 「관리자 권한으로 덤프 복사」 절차로 만든 복사본 폴더를 쓴다.

9.2. 맥 읽기 전용 수집 명령

1. 패닉 리포트 목록: ls -lt /Library/Logs/DiagnosticReports | head -20
2. 최신 패닉 리포트 사본 만들기: mkdir -p ~/crashdiag 후 Finder에서 해당 파일을 ~/crashdiag로 복사
3. 서드파티 커널 확장: kmutil showloaded --list-only | grep -v com.apple > ~/crashdiag/kexts.txt
4. 시스템 확장: systemextensionsctl list > ~/crashdiag/sysext.txt
5. 전원 기록: pmset -g log | grep -i -E 'shutdown cause|sleep cause' > ~/crashdiag/power.txt
6. OS 버전: swvers > ~/crashdiag/os.txt (systemprofiler 출력에는 일련번호가 들어가니 공유 전 지운다)

9.3. 바로 쓰는 프롬프트

1. 수집 단계 — 「이 PC가 오늘 세 번 다운됐다. 아무것도 바꾸지 말고 읽기 전용 명령만 써서 이벤트 41·6008·1001·1074와 WHEA 기록을 모아 시간순 표로 정리해 줘. 명령은 실행 전에 보여 줘.」
2. 판정 단계 — 「각 다운이 전원 꺼짐, 블루스크린, 강제 종료, 계획 재시작 중 무엇인지 이벤트 근거와 함께 판정해 줘. BugcheckCode는 16진수로 바꿔 줘.」
3. 덤프 단계 — 「crashdiag\dump 폴더의 덤프를 모두 분석해서 스톱 코드, 프로세스 이름, 스택에 나온 서드파티 드라이버, 드라이버 버전과 날짜를 덤프별 표로 만들어 줘. 덤프 사이에 공통점이 있는지 따로 적어 줘.」
4. 원인 후보 단계 — 「원인 후보를 가능성 높은 순으로 3개까지 제시하고, 각각의 근거와 반대 근거, 확신도를 적어 줘. 확정할 수 없는 부분은 무엇을 더 모으면 되는지 알려 줘.」
5. 조치 단계 — 「후보 1을 확인하려면 무엇을 바꾸면 되는지 단계별로 제시해 줘. 레지스트리·드라이버·설정 변경은 실행하지 말고, 되돌리는 방법을 같이 적어 줘.」
6. 맥 — 「이 패닉 리포트에서 panic 첫 줄, panicked task, Kernel Extensions in backtrace를 뽑고, kexts.txt·sysext.txt 목록과 맞춰서 어떤 앱이 설치한 확장인지 알려 줘.」

10. 에이전트는 덤프와 스택을 어떻게 드라이버로 연결하나

에이전트는 덤프에서 원인을 찾을 때 사람이 WinDbg로 하는 방식을 그대로 따른다. 다만 반복 작업을 훨씬 빨리 한다.

실제 사례도 쌓이고 있다. 게임 모드를 배포하는 한 개발자는 사용자의 크래시 로그가 kernelbase의 DebugBreak만 가리켜 원인을 알 수 없었는데, 미니덤프를 받아 Claude에게 넘기자 Discord가 원인이라는 결론이 나왔다고 X에 공유했다. GitHub에는 반대로 AI 코딩 도구를 쓰는 동안 생긴 블루스크린을 WinDbg로 추적한 이슈도 있다. Windows용 Codex Desktop 환경에서 SysmonDrv.sys가 반복 지목된 사례, Claude Code가 디렉터리를 나열할 때 Wof.sys 경로에서 0x139·0x3B·0x1E·0x50이 났다는 사례가 보고됐다.

에이전트 결과를 믿기 전에 확인할 점도 있다.

• ntoskrnl.exe만 지목됐다면 그 자체가 원인인 경우는 드물다. 스택 아래쪽의 다른 모듈이나 하드웨어 쪽을 더 봐야 한다.
• 확신도를 숫자로 말해 달라고 하면, 에이전트 스스로 근거가 약한 부분을 스스로 구분하는 데 도움이 된다.
• 덤프마다 원인이 다르게 나오면 드라이버 하나보다 램·전원·과열을 의심하라는 신호다.

11. 읽기 전용부터 지키는 안전 수칙

AI 에이전트는 명령을 실제로 실행할 수 있다. 다운 진단은 시스템 깊은 곳을 다루기 때문에, 처음부터 규칙을 정해 두는 편이 안전하다.

덤프와 로그 안의 텍스트도 외부 입력이라는 점을 기억해야 한다. X에서는 고객 PC의 덤프를 분석할 때 프로세스 메모리에 있는 문자열은 공격자가 넣은 텍스트일 수 있으니 셸 승인 기능을 켜 두라는 조언이 나왔다. Microsoft의 WinDbg MCP가 보안 모드와 프롬프트 주입 방어를 기본으로 켜 두는 것도 같은 이유다. 또 일부 AI 코딩 도구는 디버깅 작업을 보안 위험 요청으로 분류해 막기도 하므로, 그럴 때는 요청 목적을 「내 PC의 크래시 원인 분석」처럼 분명히 적는 편이 낫다.

크래시 리포트 자체가 디스크를 채우는 경우도 있다. X에는 맥에서 AI 코딩 앱의 크래시 리포트 대기 폴더가 230GB 가까이 쌓였다는 사례가 공유됐다. 다운이 잦은 기간에는 디스크 여유 공간도 같이 본다.

12. 단계별 진단 순서

아래 순서를 그대로 에이전트에게 주고 「이 순서대로 진행하되 4단계 전까지는 아무것도 바꾸지 말 것」이라고 지시하면 된다.

그림 2. AI 에이전트에게 맡기는 다운 분석 5단계. 바꾸는 작업은 사람이 승인한다.

13. 흔한 원인과 해결

14. 출처

• Microsoft Learn — Event ID 41 문제 해결: Event ID 41 The system has rebooted without cleanly shutting down first
• Microsoft Learn — 예기치 않은 재부팅과 시스템 이벤트 로그: Troubleshoot unexpected reboots using system event logs
• Microsoft Learn — 스톱 코드 고급 문제 해결: Stop code error or bug check troubleshooting
• Microsoft Learn — 스톱 오류 체크리스트: Troubleshoot stop errors guidance
• Microsoft Learn — 버그 체크 코드 목록: Bug Check Code Reference
• Microsoft Learn — TDR: Timeout Detection and Recovery
• Microsoft Learn — WHEA 이벤트: WHEA Hardware Error Events
• Microsoft Learn — 디스크 오류: Troubleshoot data corruption and disk errors
• Microsoft Learn — WinDbg MCP 개요: WinDbg MCP overview
• Microsoft DevBlogs — WinDbg MCP 발표: Introducing WinDbg MCP
• Apple 지원 — 커널 패닉 안내: If your Mac restarts and a message appears
• Apple 지원 — 예기치 않은 재시동: https://support.apple.com/en-us/102382
• Apple 지원 — 콘솔 보고서: https://support.apple.com/guide/console/reports-cnsl664be99a/mac
• Apple 지원 — 안전 모드: Start up your Mac in safe mode
• Apple 지원 — Apple 진단: https://support.apple.com/en-us/102550
• Apple 지원 — SMC 재설정: https://support.apple.com/en-us/102605
• GitHub — mcp-windbg: https://github.com/svnscha/mcp-windbg
• GitHub — Codex Desktop SysmonDrv 블루스크린 이슈: https://github.com/openai/codex/issues/31035
• GitHub — Claude Code Wof.sys 블루스크린 이슈: https://github.com/anthropics/claude-code/issues/32870

15. 마무리

앞에서 다룬 윈도우·맥 다운 원인 찾기와 AI 에이전트 활용의 핵심만 짧게 정리한다.

• 다운은 전원 꺼짐, 블루스크린·커널 패닉, 멈춤, 계획 재시작 네 가지로 나누고, 이벤트 41·6008·1001·1074나 패닉 리포트 유무로 먼저 판정한다.
• Kernel-Power 41은 결과일 뿐이다. BugcheckCode가 있으면 블루스크린, PowerButtonTimestamp가 있으면 강제 종료, 둘 다 0이면 전원·과열 쪽이다.
• 윈도우는 미니덤프를 관리자 권한으로 복사한 뒤 WinDbg !analyze -v로 STACK_TEXT의 서드파티 .sys를 찾고, 덤프 여러 개에서 반복되는지 본다.
• 맥은 /Library/Logs/DiagnosticReports의 패닉 리포트에서 panicked task와 Kernel Extensions in backtrace를 읽고, 안전 모드·Apple 진단으로 소프트웨어와 하드웨어를 가른다.
• AI 에이전트에게는 읽기 전용 수집 결과와 복사본 덤프만 넘기고, 판정·원인 후보·확신도를 표로 받는다.
• 레지스트리·드라이버·BIOS 변경은 사람이 확인한 뒤 한 번에 하나씩 하고, 변경 전 복원 지점과 백업을 만든다.
• 로그에는 사용자 이름·일련번호·경로가 들어 있으니 외부에 붙이기 전에 지우고, AI 분석 결과는 공식 문서와 실제 출력으로 다시 확인한다.

「다운은 기록을 남기고, AI 에이전트는 그 기록을 빨리 읽어 줄 뿐이다.」 증거를 먼저 모으고, 원인 후보를 하나씩 지워 가는 순서만 지키면 재설치나 부품 교체 없이 해결되는 경우가 많다. 하드웨어 이상이 의심되거나 데이터가 중요한 PC라면 조치 전에 백업을 하고 제조사 서비스 센터 진단도 함께 받는 편이 안전하다.

자주 묻는 질문

• 윈도우가 블루스크린 없이 갑자기 꺼졌는데 원인을 어디서 보나요?

  이벤트 뷰어의 Windows 로그 → 시스템에서 다운 시각 앞뒤의 Kernel-Power 41과 EventLog 6008을 찾습니다. 41의 세부 정보에서 BugcheckCode와 PowerButtonTimestamp가 모두 0이면 정전, 파워 용량 부족, 과열처럼 전원 쪽 원인을 먼저 의심합니다.

• 이벤트 41의 BugcheckCode 숫자는 어떻게 스톱 코드로 바꾸나요?

  BugcheckCode는 10진수로 기록되므로 16진수로 바꾸면 스톱 코드가 됩니다. 209는 0xD1, 80은 0x50, 292는 0x124입니다. 윈도우 계산기의 프로그래머 모드를 쓰거나 AI 에이전트에게 변환을 맡기면 됩니다.

• 미니덤프 파일은 어디에 있고 왜 열리지 않나요?

  작은 메모리 덤프는 C:\Windows\Minidump, 커널·자동 덤프는 C:\Windows\MEMORY.DMP에 저장됩니다. 이 폴더는 관리자 권한이 필요하므로 관리자 PowerShell로 사용자 폴더에 복사하고 icacls로 읽기 권한을 준 뒤 그 복사본을 분석합니다.

• WinDbg에서 !analyze -v 결과 중 무엇을 보면 되나요?

  BUGCHECKCODE로 스톱 코드를 확인하고, STACKTEXT에서 ntoskrnl이나 hal 같은 윈도우 기본 모듈이 아닌 서드파티 .sys 이름을 찾습니다. 같은 드라이버가 덤프 여러 개에서 반복되면 원인 후보로서 신뢰도가 크게 올라갑니다.

• 0xD1 블루스크린에 NETIO.SYS가 나오면 윈도우 문제인가요?

  NETIO.SYS와 tcpip.sys는 윈도우 네트워크 모듈이라 그 자체보다 위에 끼어드는 서드파티 네트워크 필터 드라이버가 원인인 경우가 많습니다. VPN, 방화벽, 광고 차단, 백신·보안 프로그램, 은행 보안 모듈을 하나씩 업데이트하거나 꺼 보며 재발 여부를 봅니다.

• 맥 커널 패닉 리포트는 어디서 찾나요?

  콘솔 앱의 보고서 항목에서 볼 수 있고, 시스템 패닉 리포트는 /Library/Logs/DiagnosticReports 폴더에 panic 관련 파일로 남습니다. 콘솔에서 시스템 보고서는 관리자 계정으로만 보이니, 안 보이면 Finder의 폴더로 이동 기능으로 직접 엽니다.

• 맥 패닉 리포트에서 가장 먼저 볼 줄은 무엇인가요?

  panic 첫 줄로 패닉 종류를 보고, panicked task로 그 순간 돌던 프로세스를 확인합니다. 그다음 Kernel Extensions in backtrace에 com.apple로 시작하지 않는 확장이 있는지 봅니다. 서드파티 확장이 반복해서 나오면 그 앱이 가장 유력한 후보입니다.

• Apple 실리콘 맥도 SMC나 NVRAM을 재설정해야 하나요?

  Apple 실리콘 맥은 SMC 재설정이 필요 없고 종료 후 다시 켜면 관련 상태가 초기화됩니다. NVRAM도 시동 과정에서 필요할 때 자동으로 점검됩니다. Option-Command-P-R 같은 키 조합은 인텔 맥에서만 쓰는 방법입니다.

• AI 에이전트에게 다운 원인 분석을 맡겨도 안전한가요?

  읽기 전용 명령만 실행하게 하고, 명령 실행 전 승인 기능을 켜 두면 비교적 안전합니다. 레지스트리 수정, 드라이버 삭제, BIOS 변경은 사람이 확인한 뒤 한 번에 하나씩 하고, 덤프 복사처럼 관리자 권한이 필요한 일은 사람이 직접 해 줍니다.

• WinDbg MCP는 무엇이고 어떤 AI 도구에서 쓰나요?

  Microsoft가 2026년 10월 공개한 기능으로, WinDbg 1.2610.1001.0부터 AI 클라이언트가 열린 WinDbg 세션에 연결해 자연어로 덤프를 분석합니다. 공식 지원은 VS Code의 GitHub Copilot과 Copilot CLI이고, 보안 모드가 기본으로 켜집니다.

• 로그를 AI 채팅에 붙여 넣을 때 무엇을 지워야 하나요?

  이벤트 로그와 systeminfo, system_profiler 출력에는 사용자 이름, 컴퓨터 이름, 일련번호, 이메일, 파일 경로, 사내 서버 주소가 들어갈 수 있습니다. 외부 서비스에 붙이기 전에 이런 값을 지우고, 커널 덤프 원본은 함부로 업로드하지 않습니다.

• 덤프마다 스톱 코드가 다르게 나오면 무엇을 의심하나요?

  스톱 코드와 지목 모듈이 덤프마다 제각각이면 특정 드라이버보다 메모리 불량, 오버클럭, XMP·EXPO 프로필, 파워나 과열 같은 하드웨어 쪽 가능성이 큽니다. mdsched.exe 메모리 진단을 돌리고 오버클럭을 해제한 뒤 온도와 전원을 점검합니다.