- 공유 링크 만들기
- X
- 이메일
- 기타 앱
- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows 업데이트가 반복 실패하는 환경에서 SSU(Servicing Stack Update) 누락 여부를 진단하고, 올바른 순서로 SSU 및 누적 업데이트를 설치하여 업데이트 체인을 정상화하는 방법을 실무 관점에서 정리하는 것이다.
1. SSU가 누락되면 업데이트가 왜 실패하는지 이해하다
SSU는 Windows 업데이트를 “설치하는 엔진”에 해당하는 구성요소이다.
누적 업데이트(LCU)나 .NET 업데이트는 내부적으로 CBS(Component Based Servicing)와 DISM 기반의 서비스 스택을 통해 설치되며, 이 서비스 스택이 구버전이거나 손상되면 최신 패키지를 해석·적용하지 못해 설치가 실패하다.
현장에서는 “업데이트 파일은 다운로드되는데 설치 단계에서 실패하다” 형태로 나타나는 경우가 많으며, 이때 로그를 보면 서비스 스택 단계에서 처리 실패가 누적되는 패턴이 흔하다.
주의 : SSU는 일반 앱처럼 “부분만 롤백”하는 개념이 약하고, 설치 순서가 틀리면 누적 업데이트가 계속 실패할 수 있으므로, 진단→복구→SSU→LCU 순서를 고정하는 것이 안전하다.
2. SSU 누락 가능성이 높은 전형적인 증상과 오류 코드이다
SSU 누락 또는 서비스 스택 이상에서 자주 관찰되는 증상은 다음과 같다.
| 증상 | 설명 | SSU 관점에서의 의미 |
|---|---|---|
| 다운로드는 완료되나 설치에서 실패하다 | 재부팅 후 “업데이트 구성 실패”가 반복되다 | 서비스 스택이 최신 패키지 처리에 실패할 가능성이 높다 |
| 특정 KB만 반복 실패하다 | 다른 업데이트는 되는데 누적 업데이트만 실패하다 | SSU 선행 필요 또는 구성요소 저장소 손상 가능성이 높다 |
| 오류 코드 0x800f081f | 필요 구성요소를 찾지 못하거나 손상되다 | SSU 선행 설치 또는 CBS/컴포넌트 저장소 복구가 필요하다 |
| 오류 코드 0x80073712 | 구성요소 저장소 일부가 손상되다 | SSU 이전에 DISM 복구가 선행되어야 하는 경우가 많다 |
| 오류 코드 0x800f0988 | 누적 업데이트 적용 중 적합성/구성요소 이슈가 발생하다 | SSU·LCU 조합 불일치 또는 보류 작업(Pending) 잔존 가능성이 있다 |
3. 현재 PC에서 SSU 설치 상태를 확인하는 방법이다
SSU는 “별도 KB로 설치된 내역” 또는 “누적 업데이트에 포함된 형태”로 존재할 수 있다.
따라서 한 가지 명령만으로 단정하기보다, 패키지 목록과 업데이트 이력 두 관점에서 교차 확인하는 방식이 안전하다.
3-1. 설치된 패키지에서 Servicing Stack 관련 항목을 조회하다
REM 관리자 권한 CMD에서 실행하다 dism /online /get-packages | findstr /i "servicing stack ssu" 표시되는 항목명에 “Servicing Stack” 또는 “SSU” 계열이 보이면 서비스 스택 패키지가 존재하다.
다만 최신 누적 업데이트가 SSU를 포함하는 방식으로 제공되는 환경에서는 표시 형태가 다를 수 있으므로, 아래 방식도 함께 확인하는 것이 좋다.
3-2. 핫픽스(KB) 이력에서 업데이트 설치 여부를 조회하다
# 관리자 권한 PowerShell에서 실행하다 Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 30 최근 설치된 KB 목록을 확인하고, 누적 업데이트(LCU)만 반복 실패하는지, 특정 기간부터 설치가 멈췄는지 판단하는 근거로 활용하다.
3-3. Windows 빌드 및 에디션을 먼저 고정하다
SSU는 OS 빌드/버전/아키텍처에 따라 대상이 달라지므로, 설치 전 OS 정보를 확정해야 한다.
REM 관리자 권한 CMD에서 실행하다 winver
REM 또는
systeminfo | findstr /i "OS Name OS Version System Type"
주의 : x64, ARM64, x86를 혼동하면 SSU/LCU가 설치되지 않거나 “이 업데이트는 이 컴퓨터에 적용할 수 없다” 메시지가 발생하다.
4. SSU 누락 문제를 해결하는 표준 절차이다
현장에서 재현성이 높은 절차는 “업데이트 구성요소 복구 → 보류 작업 정리 → SSU 설치 → LCU 설치” 순서이다.
4-1. Windows Update 구성요소를 초기화하다
다운로드 캐시와 서명 카탈로그가 꼬인 상태에서는 SSU를 받아도 적용이 실패할 수 있으므로, 표준 초기화를 먼저 수행하는 것이 안전하다.
REM 관리자 권한 CMD에서 실행하다 net stop wuauserv net stop bits net stop cryptsvc net stop msiserver ren %windir%\SoftwareDistribution SoftwareDistribution.old ren %windir%\System32\catroot2 catroot2.old net start msiserver net start cryptsvc net start bits net start wuauserv 초기화 후 재부팅을 1회 수행하는 것이 안정적이다.
4-2. 시스템 파일과 구성요소 저장소를 복구하다
SSU 설치 실패가 함께 발생하거나 0x800f081f, 0x80073712 계열이 반복되면 복구를 먼저 수행하는 것이 효율적이다.
REM 관리자 권한 CMD에서 실행하다 sfc /scannow DISM /Online /Cleanup-Image /StartComponentCleanup DISM /Online /Cleanup-Image /RestoreHealth 주의 : DISM /RestoreHealth는 소요 시간이 길 수 있으며, 진행 중 강제 종료하면 오히려 구성요소 저장소가 악화될 수 있으므로 완료까지 기다리는 것이 원칙이다.
4-3. SSU를 올바른 경로로 설치하다
SSU는 일반적으로 Windows Update 경로에서 함께 제공되거나, 필요 시 Microsoft Update Catalog에서 OS 버전에 맞는 SSU(.msu)를 받아 수동 설치하다.
현장에서는 다음 두 방식이 실무적으로 많이 사용되다.
| 방식 | 권장 상황 | 장점 | 주의점 |
|---|---|---|---|
| Windows Update로 설치하다 | 일반 PC, 정책 제한이 크지 않다 | 적합한 패키지를 자동 선택하다 | 업데이트 서비스 자체가 깨졌으면 실패할 수 있다 |
| SSU(.msu) 수동 설치하다 | 폐쇄망, WSUS/SCCM 제약, 특정 KB만 실패하다 | 원인 분리를 빠르게 하다 | 버전/아키텍처를 정확히 맞춰야 하다 |
4-4. .msu SSU를 수동으로 설치하는 대표 명령이다
GUI 더블클릭 설치도 가능하지만, 자동화·로그 확인 목적이라면 wusa 또는 DISM을 사용하다.
REM 1) wusa로 설치하다(가장 흔한 방식이다) wusa "C:\Temp\SSU-KBxxxxxxx-x64.msu" /quiet /norestart REM 2) DISM으로 설치하다(일부 환경에서 유리하다) DISM /Online /Add-Package /PackagePath:"C:\Temp\SSU-KBxxxxxxx-x64.msu" SSU 설치 후에는 재부팅이 요구되는 경우가 많으므로, 실제 운영 환경에서는 “SSU 설치 → 재부팅 → LCU 설치” 흐름으로 스케줄을 잡는 것이 안정적이다.
주의 : SSU가 포함된 최신 누적 업데이트를 설치하는 환경에서도, 업데이트 체인이 깨진 상태에서는 SSU가 제대로 반영되지 않을 수 있으므로 “SSU 적용 여부 확인”을 한 번 더 수행하는 것이 실무적으로 유리하다.
4-5. SSU 다음에 누적 업데이트(LCU)를 설치하다
SSU가 정상 반영되면, 그 다음 단계는 최신 누적 업데이트를 설치하는 것이다.
업데이트 실패가 길게 누적된 PC에서는 월별 누적 업데이트가 여러 개 겹치며, 설치 순서가 꼬이면 다시 실패할 수 있으므로, 원칙적으로 “가장 최신 LCU 1개”를 목표로 설치하는 편이 관리가 쉽다.
REM 예시 형태이다 wusa "C:\Temp\LCU-KByyyyyyy-x64.msu" /quiet /norestart 5. “SSU 설치가 안 되는” 특수 케이스를 정리하다
5-1. “이 업데이트는 이 컴퓨터에 적용할 수 없다”가 뜨는 경우이다
대부분 다음 중 하나에 해당하다.
첫째, OS 버전(예: 22H2 vs 23H2) 또는 빌드가 다르다.
둘째, 아키텍처(x64/ARM64/x86)가 다르다.
셋째, 이미 더 최신 서비스 스택이 포함된 누적 업데이트가 부분적으로 적용되어 대상이 아니게 되다.
이 경우 winver로 버전과 빌드를 확정한 뒤, 동일 버전용 패키지인지 다시 확인해야 하다.
5-2. 보류 작업(Pending) 때문에 SSU/LCU가 계속 실패하는 경우이다
업데이트가 중간에 실패한 뒤 재부팅을 반복하면 보류 작업이 남아 설치가 꼬일 수 있다.
이때는 먼저 “재부팅을 2회 이상” 수행하여 보류 작업을 처리하고, 그래도 반복되면 Windows Update 초기화 및 DISM 복구를 선행하는 것이 원칙이다.
5-3. WSUS/SCCM 환경에서 SSU가 배포되지 않는 경우이다
조직 정책으로 특정 분류 업데이트가 승인되지 않으면, 단말은 SSU를 받지 못하고 누적 업데이트만 실패하는 상태가 지속되다.
이때는 중앙에서 SSU를 승인하거나, 단말에 한시적으로 수동 SSU를 적용해 체인을 복구한 뒤 정상 배포 흐름으로 복귀시키는 방식이 실무적으로 사용되다.
주의 : 운영망에서 임의로 Windows Update 온라인 경로를 열기 어렵다면, SSU/LCU 파일을 사내 배포 경로로 통제하여 제공하는 방식이 바람직하다.
6. 로그로 SSU 관련 실패를 빠르게 판별하는 방법이다
원인 분석이 필요한 경우에는 CBS 로그가 가장 핵심이다.
CBS 로그는 업데이트 설치와 구성요소 저장소 처리 내역이 기록되는 파일이며, SSU 관련 문제도 흔히 여기서 단서를 얻다.
REM CBS 로그 위치를 확인하다 C:\Windows\Logs\CBS\CBS.log REM 최근 로그를 바탕화면으로 복사하다(권한 문제를 피하다) copy C:\Windows\Logs\CBS\CBS.log "%USERPROFILE%\Desktop\CBS.log" 로그에서 “servicing stack”, “CSI”, “Cannot repair”, “Failed to resolve package” 같은 키워드가 반복되면 서비스 스택 또는 구성요소 저장소 이슈 가능성이 커지다.
7. 재발 방지를 위한 운영 체크리스트이다
SSU 누락 문제는 “장기간 업데이트 미적용” 또는 “업데이트 경로/정책이 불안정한 환경”에서 재발하기 쉽다.
다음 체크리스트를 기준으로 운영 규칙을 정리하면 재발률이 낮아지다.
| 점검 항목 | 권장 기준 | 현장 적용 팁 |
|---|---|---|
| 업데이트 적용 주기 | 월 1회 이상 적용하다 | 업데이트 누적이 길어질수록 SSU/LCU 체인 실패 가능성이 증가하다 |
| 재부팅 정책 | 업데이트 후 24시간 내 재부팅하다 | 보류 작업이 남으면 다음 업데이트가 연쇄 실패하다 |
| 디스크 여유 공간 | 시스템 드라이브 15GB 이상 권장하다 | LCU 압축 해제/스테이징 단계에서 공간 부족으로 실패하다 |
| 손상 복구 루틴 | SFC/DISM 표준 절차를 문서화하다 | 0x800f081f 계열이 나오면 즉시 복구 루틴으로 전환하다 |
| 정책 환경(WSUS 등) | SSU 분류/승인 정책을 포함하다 | 누적 업데이트만 승인하면 단말이 SSU를 못 받아 실패하다 |
FAQ
SSU를 반드시 따로 설치해야 하다?
항상 그런 것은 아니다.
최근 누적 업데이트는 SSU를 함께 포함하는 형태로 제공되는 경우가 많다.
다만 업데이트 체인이 손상되었거나 정책/배포 문제로 SSU가 제대로 반영되지 않는 환경에서는 SSU를 분리해 적용하는 방식이 문제 해결에 유리하다.
SSU를 설치했는데도 누적 업데이트가 계속 실패하다?
구성요소 저장소 손상, 보류 작업 잔존, 업데이트 구성요소 캐시 꼬임이 동반된 경우가 많다.
Windows Update 초기화 후 SFC와 DISM 복구를 수행하고, SSU 설치 뒤 재부팅을 완료한 다음 최신 누적 업데이트 1개만 목표로 재시도하는 흐름이 재현성이 높다.
오프라인 환경에서 SSU/LCU를 적용하는 표준 순서가 무엇이다?
표준 순서는 “복구(SFC/DISM) → SSU 적용 → 재부팅 → LCU 적용 → 재부팅” 순서이다.
여러 KB를 한 번에 밀어 넣기보다, SSU와 최신 LCU 중심으로 최소화하는 편이 실패 가능성을 낮추다.
업데이트 실패가 너무 오래되어 간단히 끝내고 싶다?
복구와 SSU/LCU 적용이 반복 실패하고 업무 영향이 크다면, 인플레이스 업그레이드(설치 미디어로 “개인 파일 및 앱 유지” 선택) 방식이 현실적인 대안이 되다.
이 방식은 서비스 스택과 구성요소 저장소를 재구성하여 업데이트 체인을 정상화하는 데 도움이 되다.