0x800f0922 오류가 뜨면서 Windows 업데이트가 35~36%쯤에서 멈추고, 다시 이전 상태로 돌아갔나요? 화면에는 ‘변경 내용을 실행 취소합니다’라고 나오는데 정작 무엇 때문에 실패했는지는 알려주지 않습니다. 이때 곧바로 EFI 파티션을 늘리거나 파일을 삭제해서는 안 됩니다. 먼저 실패한 업데이트 번호와 설치 로그를 맞춰봐야 합니다.
Microsoft는 2026년 5월 업데이트 KB5089549에서 바로 이런 진행률과 오류가 나타날 수 있다고 기록했습니다. 당시 일부 PC는 EFI 시스템 파티션의 남은 공간이 부족해 재시작 단계에서 실패했습니다. 하지만 그 사례는 후속 업데이트 KB5089573에서 해결됐습니다. 지금 다른 업데이트에서 같은 코드가 나왔다면 원인도 같다고 가정하지 마세요.
확인 순서는 간단합니다. 업데이트 기록에서 실패한 KB 확인 → 디스크 관리에서 EFI 파티션 위치 확인 → CBS.log에서 실패 원인 확인. 이 세 가지를 모으면 ‘공간 문제인지’, ‘다른 설치 단계에서 실패한 것인지’를 훨씬 정확하게 구분할 수 있습니다.
Table of Contents
0x800f0922와 35~36% 되돌림, 언제 EFI 문제였을까?
2026년 5월 KB5089549 관련 Microsoft 안내에는 꽤 구체적인 조건이 나옵니다. 업데이트가 처음에는 설치된 듯 보이다가 재시작 중 약 35~36%에서 실패하고, 변경 사항을 되돌린 뒤 0x800f0922가 표시될 수 있다는 내용입니다. 특히 EFI 시스템 파티션에 사용 가능한 공간이 10MB 이하인 일부 장치가 영향을 받았습니다.
여기서 ‘35%에서 멈췄으니 EFI 문제’라고 외우면 곤란합니다. 진행률과 오류 코드는 의심할 단서이고, 실패한 KB 번호와 로그가 원인을 가르는 자료입니다. Microsoft의 일반 오류 안내에도 0x800f0922는 디스크 공간 외에 연결이나 Windows 구성 요소 문제와 관련될 수 있다고 나옵니다.
1. 업데이트 기록에서 실패한 KB 번호부터 찾기
시작 → 설정 → Windows 업데이트 → 업데이트 기록으로 들어가세요. 실패한 항목의 KB 번호, 설치 시도 날짜, 표시된 오류 코드를 적어둡니다. 업데이트가 여러 개 보인다면 ‘최근에 실패한 것’부터 찾으세요. 0x800f0922가 떠도 어떤 KB를 설치하다 실패했는지 모르면 Microsoft의 알려진 문제와 대조할 수 없습니다.
실패한 항목이 KB5089549라면 아래의 2026년 5월 사례가 직접 참고 자료가 됩니다. 반대로 다른 KB라면 증상이 비슷해도 원인은 다시 확인해야 합니다. 이미 후속 업데이트가 설치된 PC에서 오래된 5월 문제를 현재 오류의 원인으로 단정하는 것도 피해야겠죠.
2. EFI 시스템 파티션은 C: 드라이브와 별개로 보기
“C: 드라이브에 공간이 많이 남았는데 왜 용량 부족인가요?” 여기서 헷갈리는 분이 많습니다. EFI 시스템 파티션은 Windows가 시작될 때 필요한 파일을 담는 작은 영역으로, 보통 파일 탐색기에 C:처럼 표시되지 않습니다. C: 드라이브의 여유 공간과 EFI 파티션의 여유 공간은 같은 숫자가 아닙니다.
위치를 보려면 시작 버튼 오른쪽 클릭 → 디스크 관리로 들어가세요. 또는 Win + R → diskmgmt.msc를 입력해도 됩니다. Windows가 설치된 디스크에서 ‘EFI 시스템 파티션’으로 표시된 영역이 있는지 살펴보세요. 여기서는 위치와 전체 크기만 확인합니다.
한 가지 함정이 있습니다. 디스크 관리에서 EFI 파티션이 ‘100% 사용 가능’처럼 보이더라도 실제 파일이 비어 있다는 뜻으로 받아들이면 안 됩니다. Microsoft는 이 화면이 EFI와 복구 파티션의 여유 공간을 잘못 이해하게 만들 수 있다고 설명합니다. 따라서 디스크 관리 화면의 숫자만 보고 “공간이 충분하다”거나 “부족하다”고 결론 내리지 마세요.
3. CBS.log에서 공간 부족 기록이 있는지 확인
설치가 왜 되돌아갔는지 확인할 차례입니다. 파일 탐색기 주소창에 C:\Windows\Logs\CBS를 붙여넣고 CBS.log를 여세요. 파일이 열리지 않으면 바탕화면에 복사본을 만든 뒤 그 복사본을 열어보면 됩니다. 원본 로그를 수정할 필요는 없습니다.
실패한 날짜와 시각 근처에서 SpaceCheck, ServicingBootFiles, 0x70을 찾아보세요. Microsoft가 공개한 KB5089549 사례에서는 사용 가능한 공간 부족을 나타내는 SpaceCheck 기록과 부팅 파일 처리 실패를 나타내는 0x70 기록이 단서로 제시됐습니다. 검색 결과가 여러 개라면 업데이트를 시도한 시각과 맞는지도 꼭 확인하세요.
로그에서 0x800f0922만 찾고 멈추지 마세요. 그 코드는 최종 실패 결과일 수 있습니다. 바로 앞에서 어떤 작업이 실패했는지가 중요합니다. SpaceCheck 관련 기록이 없거나 다른 구성 요소의 오류가 먼저 보인다면, EFI 공간 부족으로 단정할 근거가 부족합니다.
확인 결과에 따라 다음 행동이 달라집니다
KB5089549의 2026년 5월 문제와 일치한다면
우선 Windows 업데이트에서 사용 가능한 후속 업데이트를 확인하세요. Microsoft는 당시의 EFI 공간 관련 설치 문제를 KB5089573에서 해결했다고 밝혔습니다. 2026년 5월의 실패 기록을 보고 곧바로 부팅 파티션을 손보는 것보다, 현재 어떤 업데이트가 설치돼 있는지 확인하는 편이 먼저입니다.
다른 KB에서 같은 코드가 나타났다면
0x800f0922라는 코드만으로 5월 문제의 해결법을 그대로 적용하지 마세요. 실패한 KB의 공식 ‘알려진 문제’를 확인하고, Windows의 설정 → 시스템 → 문제 해결 → 기타 문제 해결사 → Windows 업데이트에서 문제 해결사를 실행해 볼 수 있습니다. VPN을 사용한다면 연결 문제 여부도 살펴보세요. 그래도 반복된다면 실패 시각의 CBS.log 기록이 다음 진단 자료가 됩니다.
EFI 공간 부족 기록이 실제로 보인다면
로그가 근거를 보여줘도 EFI 파티션 안의 파일을 임의로 지우거나 파티션 크기를 바로 바꾸지는 마세요. 이곳은 부팅에 필요한 파일이 있는 영역입니다. 어떤 KB에서 발생했는지와 로그의 관련 부분을 확보한 뒤, 해당 업데이트의 공식 해결 안내 또는 PC 제조사·Microsoft 지원 경로에 맞춰 처리해야 합니다.
마지막으로 확인할 것
0x800f0922가 다시 나타나면 실패한 KB 번호 → 실패 시각 → CBS.log의 첫 원인 기록을 한 줄로 적어보세요. 35~36%라는 진행률은 기억하기 쉽지만, 해결 방법을 정하는 것은 그 세 가지 기록입니다. 실제 실패가 없었던 PC에서 찍은 디스크 관리 사진은 화면을 찾는 방법을 보여줄 수 있을 뿐, 오류를 재현했다는 증거는 아닙니다.
공식 자료와 함께 읽을 글
35~36% 되돌림 사례와 해결 시점은 Microsoft의 KB5089549 알려진 문제와 KB5089573 해결 안내에서 확인할 수 있습니다. 로그의 역할은 Microsoft의 Windows 업데이트 로그 설명을 참고하세요.
업데이트 실패를 넘어 Windows가 아예 시작되지 않는다면 Windows 11 Quick Machine Recovery와 WinRE 복구 방법도 함께 읽어보세요.
대표 이미지와 본문의 업데이트 기록·CBS.log 화면은 AI를 활용해 만든 설명용 예시입니다. 실제 PC의 오류 화면이나 로그를 촬영한 자료는 아닙니다.