# Windows 앱 업데이트가 실패하면 다시 시도하기 전에 단계를 확인합니다

앱에 업데이트가 있는데 업데이트를 눌러도 끝나지 않는 것처럼 보일 수 있습니다. 다운로드 중인지, 관리자 승인을 기다리는지, 설치 중인지, 설치된 버전을 확인하는 중인지를 봅니다. 결정을 기다리는 설치 프로그램은 반복 클릭으로 진행되지 않습니다.

## 느린 다운로드와 실패한 설치를 나눕니다

Mole의 업데이트 행은 단계를 표시합니다. 전체 크기를 알 수 있으면 다운로드는 퍼센트로 나오고, 아니면 받은 양이 나옵니다. 숫자가 바뀌면 진행 중입니다. 다운로드 중에는 취소할 수 있습니다. 관리자 확인을 포함해 설치 단계에 들어가면 더 이상 취소할 수 없으므로, 설치 프로그램이 중간에 종료되지는 않습니다.

| 멈추는 곳 | 첫 확인 |
| --- | --- |
| 다운로드 진행이 없거나 서버 오류 | 다운로드 주소, 연결, 제조사 서비스. 전체 오류를 유지 |
| 관리자 접근을 요청 | 작업 표시줄과 Windows 승인 확인 |
| 다른 창이 열린 채 설치 중 | 설치 프로그램이 앱 종료, 확인, 다시 시작을 기다리는지 |
| 끝났는데 버전이 그대로 | 앱의 정보 페이지, 설치 범위, 다시 열어야 하는지 |

거부된 다운로드는 설치 프로그램이 실행되지 않았다는 뜻일 수 있습니다. 설치 프로그램이 손상됐다는 뜻도, 동작 중인 버전을 먼저 제거해야 한다는 뜻도 아닙니다.

## 오류를 설치 프로그램 자신의 맥락에서 읽습니다

Windows Installer 결과는 실패마다 동작이 다른 이유를 보여 줍니다.

| MSI 코드 | 의미 | 다음 단계 |
| --- | --- | --- |
| 1603 | 일반적인 설치 실패 | `%TEMP%`의 MSI 로그(`MSI*.log`)를 읽거나 `msiexec /l*v`로 다시 실행. 코드만으로 원인을 알 수 없음 |
| 1618 | 다른 설치가 실행 중 | 그 설치가 끝난 뒤에 다른 설치를 시작 |
| 3010 | 성공. 완료하려면 다시 시작이 필요 | 작업을 저장하고 다시 시작 요청을 따른 뒤 버전을 확인 |

이 의미는 Microsoft의 [Windows Installer 코드 표](https://learn.microsoft.com/en-us/windows/win32/msi/error-codes)에서 옵니다. MSI 결과에 적용되며, 모든 제조사의 EXE 설치 프로그램에 적용되지는 않습니다. 특히 3010은 실패한 다운로드를 다시 설치해야 한다는 뜻이 아닙니다.

## 설치를 반복하지 않고 로그를 찾습니다

이 PowerShell 질의는 앱 업데이트를 시작하지 않고 WinGet의 버전, 환경, 로그 디렉터리를 보여 줍니다.

```powershell
winget --info
```

실패 시각의 로그를 찾은 뒤 앱 이름, 패키지 ID, 타임스탬프를 맞춥니다. 다운로드 응답, 설치 프로그램 종료, 이후 버전 확인을 나눕니다. 로그에는 사용자 이름과 로컬 경로가 들어 있을 수 있습니다. 아카이브 전체를 공개하지 말고, 지원으로 공유하기 전에 원하지 않는 세부를 제거합니다.

시도 시각, 원래 앱 버전, 완전한 코드, 승인이나 다시 시작 요청을 함께 둡니다. 그렇지 않으면 어제 관련 없는 설치의 실패가 오늘 문제의 원인처럼 보일 수 있습니다. [WinGet의 문제 해결 문서](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting)는 강제 재설치 없이 이 로그 찾기를 설명합니다.

<figure class="blog-diagram">
  <picture>
    <source media="(max-width: 900px)" srcset="/img/blog/windows-windows-app-update-failures-en-mobile.webp" type="image/webp" width="768" height="1500">
    <img src="/img/blog/windows-windows-app-update-failures-en.webp" width="1360" height="454" loading="lazy" alt="업데이트에는 뚜렷한 단계가 있습니다">
  </picture>
  <figcaption>영향받은 단계를 찾습니다. 승인은 조건에 따르고, 버전 확인은 설치와 필요한 다시 시작 뒤에 옵니다.</figcaption>
</figure>

## 일부 업데이트는 이전 버전을 먼저 제거합니다

Java 8 같은 설치 프로그램은 이전 버전 제거가 필요할 수 있습니다. 컴퓨터 전체 설치는 관리자 접근이 필요할 수 있으므로, 일반 사용자 업데이트가 끝나지 않을 수 있습니다. Mole은 지원되는 업데이트 경우를 다루고, 필요할 때 승인을 요청합니다. 모든 실패가 권한 문제는 아닙니다.

설치 프로그램마다 종료 코드와 동작이 다릅니다. Microsoft의 [WinGet 문제 해결 안내](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting)는 로그와 오류 조사를 설명합니다. 지원에는 실패라는 단어만보다 코드와 단계가 더 유용합니다.

## 새 버전이 실제로 쓰이는지 확인합니다

앱에 사용자 수준 설치와 컴퓨터 전체 설치가 있거나, 표시 버전이 패키지 등록과 다를 수 있습니다. 이 설치의 정보 페이지를 열고, 설치 프로그램이 끝났는지 확인하며, 요청된 다시 시작을 끝냅니다. 업데이트 목록을 비우려고 설치를 반복하는 것은 믿을 만한 해결이 아닙니다.

Mole은 버전이 바뀌지 않은 결과를 검토할 수 있게 둡니다. 스스로 업데이트하는 앱은 자신의 채널을 유지합니다. [업데이트 안내](/ko/windows/blog/update-windows-apps)가 그 항목을 설명합니다. 열린 채로 업데이트하는 브라우저는 보통 다음 다시 시작 뒤에 새 버전을 씁니다.

## 피드백에는 버전과 정확한 오류를 넣습니다

Windows, Mole, 영향받은 앱의 버전을 적습니다. 다운로드, 승인, 설치가 어디까지 갔는지 설명하고, 오류와 스크린샷은 [Windows 도움말](/ko/windows/help)의 지원 경로로 보냅니다. 로그에서 공유하고 싶지 않은 내용은 먼저 제거합니다.

Mole 자신의 업데이터, 다른 앱 업데이트, Windows 업데이트는 별도 대기열입니다. 시스템 업데이트 오류는 앱 실패 하나를 시스템 전체를 초기화할 이유로 보지 말고, Windows 기록으로 조사합니다. 업데이트 채널 자체는 [Windows에서 어느 업데이트 항목을 쓸지](/ko/windows/blog/update-windows-apps)를, 업데이트 파일과 그것이 포기하는 롤백은 [Windows 업데이트 파일 삭제](/ko/windows/blog/delete-windows-update-files)를 봅니다.


Canonical: https://mole.fit/ko/windows/blog/windows-app-update-failures