WinGet 소스가 꼬였을 때, 검색·초기화·로그를 나누는 복구 순서

Windows PC에서 앱 패키지 소스와 명령줄 설치를 점검하는 장면

AI를 활용하여 생성한 이미지입니다.

WinGet으로 앱을 설치하다가 검색 결과가 비거나, 같은 패키지가 갑자기 보이지 않거나, 설치 단계에서 원본을 찾지 못했다는 오류가 나올 때가 있어요. 이 문제를 WinGet 자체의 고장으로 단정하면 App Installer를 다시 설치하는 쪽으로 바로 가기 쉽습니다. 먼저 어떤 소스에서 검색했는지, 로컬 소스 데이터가 최신인지, 관리자 권한이 필요한 상황인지 나눠 봐야 해요.

WinGet에서 소스가 하는 일

WinGet은 명령 하나로 모든 앱을 직접 검색하는 도구가 아니에요. 앱 목록과 설치 정보가 들어 있는 소스를 읽어 검색·설치에 사용합니다. Microsoft 문서는 소스를 신뢰할 수 있는 곳으로 제한해야 한다고 안내하고, 기본 소스는 winget과 Microsoft Store 계열로 구분해 설명해요.[1]

증상 먼저 볼 범위 다음 명령
검색 결과가 거의 없음 소스 목록과 업데이트 시각 winget source list
소스 업데이트 실패 네트워크·프록시·캐시 winget source update
특정 앱만 설치 실패 패키지 식별자와 설치 관리자 winget show --id ID
모든 명령이 이상함 App Installer와 사용자 등록 상태 WinGet 버전·로그 확인

1. 소스 목록부터 저장해요

문제가 재현되면 먼저 현재 상태를 남기세요. 관리자 터미널을 열기 전에 일반 PowerShell에서 다음 명령을 실행해도 됩니다.

winget --version
winget source list
winget source update

source list 결과에서 익숙하지 않은 주소가 추가되어 있거나, 기본 소스가 사라졌는지 확인하세요. 소스를 무조건 많이 추가하면 검색 결과가 늘어나는 것처럼 보여도, 같은 앱이 서로 다른 게시자 정보로 나타나거나 설치 선택이 복잡해질 수 있어요. 회사 PC라면 조직 정책이나 프록시가 소스 접근을 제한할 수도 있습니다.

소스의 이름보다 실제 URL과 신뢰 범위를 먼저 보세요. Microsoft 문서도 소스 추가·수정·삭제·초기화 명령을 제공하지만, 신뢰할 수 있는 소스만 사용하라고 명시합니다.[1]

2. 업데이트와 초기화를 구분해요

winget source update는 기존 소스의 데이터를 새로 확인하는 동작이에요. 데이터가 잠시 오래됐거나 네트워크가 끊겼다면 이 단계로 충분할 수 있습니다. 반면 로컬 저장소가 꼬였거나 소스 자체가 잘못 등록됐다면 winget source reset으로 기본값을 복구하는 쪽을 검토합니다.

winget source reset
winget source update
winget source list

초기화는 사용자가 추가한 소스까지 원래 상태로 되돌릴 수 있으므로, 사내 저장소나 테스트 저장소를 쓰고 있다면 먼저 목록을 복사해 두세요. 관리자 권한을 요구하는 환경에서는 명령이 끝난 뒤에도 일반 사용자 세션의 결과가 달라질 수 있습니다. 같은 명령을 무작정 반복하기보다 실행 계정과 오류 문구를 같이 기록하는 편이 낫습니다.

3. 소스 문제와 패키지 문제를 나눠요

검색 결과가 나온다고 설치까지 정상이라는 뜻은 아니에요. 검색·상세 정보·설치 단계를 따로 확인해야 합니다.

  1. winget search 앱이름으로 검색 결과가 있는지 확인합니다.
  2. 결과에서 게시자와 식별자를 고르고 winget show --id 게시자.앱이름으로 설치 정보를 읽습니다.
  3. 식별자가 맞는지 확인한 뒤 winget install --id 게시자.앱이름으로 설치합니다.
  4. 설치 도중 실패하면 패키지 자체의 설치 관리자, 요구 버전, 사용자 동의 화면을 따로 봅니다.

앱이 검색되지 않는다고 해서 곧바로 소스를 추가하지 마세요. 앱이 아직 해당 소스에 등록되지 않았거나, 이름 대신 정확한 식별자가 필요한 경우도 있어요. Microsoft는 WinGet을 앱 검색·설치·업데이트·제거·구성에 쓰는 클라이언트로 설명하고, 문제 진단에는 로그를 확인하라고 안내합니다.[2]

로그와 권한을 확인하는 순서

소스 업데이트가 반복해서 실패하면 회사 프록시, TLS 검사, VPN, DNS 필터가 원인일 수 있어요. 다른 네트워크에서 같은 명령을 실행해 차이를 비교하되, 보안 정책을 우회하려고 인증서 검사를 끄지는 마세요. 설치만 실패한다면 관리자 권한 부족, 설치 중인 앱의 종료 필요, 사용자 범위와 시스템 범위의 차이도 확인해야 합니다.

WinGet은 로그를 통해 검색·소스·설치 단계의 오류를 나눠 볼 수 있어요. 문제를 지원팀에 전달할 때는 앱 이름만 보내지 말고 WinGet 버전, 실행한 명령, 소스 목록, 실패 시각, 오류 코드, 로그 파일을 함께 전달하세요. 토큰이나 사내 URL이 로그에 포함될 수 있다면 외부 공유 전에 가리세요.

복구 뒤 되돌릴 수 있게 만들기

초기화 전에 사용자 소스 목록과 회사 정책을 기록해 두면 복구가 쉬워요. 초기화 후에는 소스가 기본 상태인지 확인하고, 필요한 사내 소스만 다시 추가하세요. 한 번에 여러 소스를 등록하지 말고 하나씩 추가한 뒤 검색과 설치를 시험하면 어느 소스에서 문제가 생기는지 좁힐 수 있습니다.

  • WinGet 버전과 실행 계정을 기록하기
  • winget source list 결과를 초기화 전에 저장하기
  • 소스 업데이트와 초기화를 다른 조치로 구분하기
  • 검색·상세 정보·설치를 각각 시험하기
  • 회사 소스와 공용 소스를 섞기 전에 정책 확인하기

여러 Windows 환경에서 반복 설치를 관리한다면 Windows Dev Drive와 보안 필터를 함께 조정하는 방법도 이어서 확인해 보세요. 저장 장치와 보안 필터가 설치 성능에 영향을 줄 때 WinGet 오류와 실제 설치 지연을 구분하는 데 도움이 됩니다.

Sources

함께 읽을 글