이 글을 3줄로 요약하면
· 이 창은 악성 팝업이 아니라 프로그램이 요구하는 런타임이 이 PC에 없다는 정상 안내입니다.
· 헷갈리는 지점은 딱 셋입니다. 버전 숫자, Runtime과 Desktop Runtime의 구분, x64와 x86.
· 설치했는데도 같은 창이 뜬다면 이 셋 중 하나가 어긋난 것입니다. 판별표에서 어느 쪽인지 먼저 고르세요.
목차
1. .NET Desktop Runtime이 정확히 무엇인가
3. 원인 A · 요구한 런타임이 아예 설치돼 있지 않다
4. 원인 B · 설치는 했는데 버전이나 종류가 다르다
.NET Desktop Runtime이 정확히 무엇인가
이름이 비슷한 세 가지가 있어서 대부분의 혼동이 여기서 생깁니다.
개발자가 프로그램을 만들 때 화면·버튼·목록 같은 공통 기능을 처음부터 새로 만들지는 않습니다. 마이크로소프트가 미리 만들어 둔 공통 구성 요소 묶음을 가져다 쓰고, 그 묶음이 바로 런타임입니다. 문제는 이 묶음이 윈도우에 기본으로 들어 있지 않다는 점입니다. 그래서 그 묶음을 쓰는 프로그램을 처음 실행하면 없는 부품을 요구하며 안내 창이 뜹니다.
마이크로소프트 문서 기준으로 윈도우용 런타임은 세 종류입니다. 이름이 비슷해서 잘못 받는 경우가 많으니 여기서 한 번 정리하고 넘어갑니다.
| 설치 파일 이름 | 무엇이 들어 있나 | 어떤 프로그램용인가 |
|---|---|---|
| .NET Runtime | 기본 런타임만 | 창 없이 도는 프로그램 |
| .NET Desktop Runtime | 기본 런타임 + 데스크톱(WPF·Windows Forms) | 창이 뜨는 일반 윈도우 프로그램 |
| ASP.NET Core Runtime | 웹용 구성 요소 | 웹 서버·웹 응용 프로그램 |
Desktop Runtime 하나면 기본 런타임까지 함께 들어옵니다
문서의 구성 표를 보면 Desktop Runtime 설치 파일에는 .NET Runtime이 포함돼 있습니다. 반대로 .NET Runtime만 설치하면 데스크톱 구성 요소는 들어오지 않습니다. 그래서 오류창이 Desktop Runtime을 요구하는데 .NET Runtime만 설치하면 같은 창이 계속 뜹니다. 설치했는데도 안 된다는 사례의 상당수가 이 경우입니다.
설치된 실체는 C:\Program Files\dotnet\ 아래에 자리 잡습니다. 데스크톱 런타임은 그중 shared\Microsoft.WindowsDesktop.App\ 폴더에 버전별 하위 폴더로 들어갑니다. 뒤의 진단 섹션에서 이 경로를 그대로 확인합니다.
문서는 ".NET은 .NET Framework와 달리 윈도우 버전에 묶여 있지 않다"고 설명합니다. 또한 설치 파일은 메이저·마이너 릴리스와 아키텍처별로 나란히 설치(side-by-side)되도록 만들어져 있어, 예를 들어 6.0.15(x64)와 6.0.17(x86)을 함께 설치해도 서로 충돌하지 않습니다. 여러 프로그램이 저마다 다른 버전을 요구해도 각각 설치하면 되는 이유가 여기 있습니다.
오류창 문구로 원인 좁히기
창에 적힌 한 줄이 이미 답의 절반을 알려 줍니다.
가장 흔한 문구는 "To run this application, you must install .NET Desktop Runtime"이고, 그 아래에 버전 숫자와 (x64) 또는 (x86) 표기가 함께 적혀 있습니다. 예를 들어 Desktop Runtime 8.0.x (x64)라면 8.0 계열의 64비트용 데스크톱 런타임이 필요하다는 뜻입니다. 이 두 정보를 먼저 메모하거나 캡처해 둡니다.
| 증상 | 유력한 원인 | 먼저 볼 항목 |
|---|---|---|
| 새 PC에서 처음 실행할 때부터 떴다 | 런타임이 아예 없음 | 원인 A → 설치 여부 확인 |
| 설치를 마쳤는데도 같은 창이 그대로 뜬다 | 버전이 다르거나 Desktop이 아닌 쪽을 설치 | 원인 B → 종류·버전 대조 |
| 오류창에 (x86)이라고 적혀 있는데 x64를 설치했다 | 아키텍처 불일치 | 원인 C → 프로그램 비트 확인 |
| 설치 파일을 실행하면 진행되다 조용히 끝난다 | 보안 프로그램·권한에 막힘 | 원인 D → 차단 여부 확인 |
| 어떤 프로그램은 되고 어떤 프로그램만 안 된다 | 프로그램마다 요구 버전이 다름 | 원인 B → 버전별로 추가 설치 |
| 창에 버전 숫자가 아예 안 보인다 | 요구 버전을 모르는 상태 | 7번 섹션 → 로그에서 요구 버전 찾기 |
창 안의 다운로드 버튼보다 공식 페이지로 직접 가는 편이 낫습니다
오류창에는 보통 "Do you want to download it now?"와 함께 버튼이 있습니다. 눌러도 되지만, 브라우저가 열린 뒤 어떤 항목이 Desktop Runtime인지 구분하지 못한 채 다른 파일을 받는 경우가 많습니다. 아래 순서대로 공식 다운로드 페이지에서 항목을 직접 골라 받는 편이 헷갈리지 않습니다.
원인 A요구한 런타임이 아예 설치돼 있지 않다
새 PC나 새로 받은 프로그램이라면 여기서 끝나는 경우가 대부분입니다.
1지금 무엇이 깔려 있는지부터 본다
Win + I → 앱 → 설치된 앱으로 들어가 검색창에 Runtime을 입력합니다. 앱에 등록된 이름이 Microsoft Windows Desktop Runtime이라서 .NET으로 검색하면 하나도 잡히지 않습니다. 목록에 그 항목이 있는지, 있다면 버전 번호와 (x64)·(x86) 표기가 무엇인지 확인합니다. Windows App Runtime만 보인다면 그건 다른 구성 요소이므로 Desktop Runtime은 없는 것이고, 원인 A가 맞습니다.
2공식 다운로드 페이지에서 같은 버전을 찾는다
마이크로소프트의 .NET 다운로드 페이지에서 오류창에 적힌 메이저 버전(예: 8.0)을 고릅니다. 페이지 안에서 Runtime 영역과 Desktop Runtime 영역이 나뉘어 있으니, 반드시 Desktop Runtime 쪽을 봅니다.
3오류창의 표기와 같은 아키텍처를 받는다
Desktop Runtime 아래에 x64 · x86 · Arm64 링크가 나란히 있습니다. 오류창에 적힌 표기를 그대로 고릅니다. 표기가 없다면 대부분의 최신 PC는 x64입니다. 판단이 서지 않으면 원인 C의 방법으로 프로그램 쪽 비트를 먼저 확인합니다.
4설치 후 프로그램을 완전히 껐다 켠다
설치 중 "이 앱이 디바이스를 변경할 수 있도록 허용하시겠습니까?" 창이 뜨면 예를 눌러야 진행됩니다. 설치가 끝나면 문제의 프로그램을 완전히 종료했다가 다시 실행합니다. 실행 중이던 프로세스가 남아 있으면 이전 상태 그대로 다시 뜨는 경우가 있습니다.
이 방법이 안 통하는 경우
설치를 마쳤는데 같은 창이 그대로 뜬다면 설치가 안 된 것이 아니라 다른 것을 설치한 것일 가능성이 큽니다. 원인 B에서 종류와 버전을 대조합니다. 설치 파일이 진행되다 조용히 끝났다면 원인 D를 봅니다.
원인 B설치는 했는데 버전이나 종류가 다르다
"분명히 설치했는데 또 뜬다"는 경우의 대부분이 여기입니다.
어긋날 수 있는 지점은 두 개입니다. 하나는 종류(Runtime과 Desktop Runtime), 다른 하나는 메이저 버전(6.0과 8.0처럼 앞자리가 다른 경우)입니다. 앞서 본 대로 Desktop Runtime에는 .NET Runtime이 포함되지만 그 반대는 아니므로, 창이 Desktop을 요구하는데 기본 런타임만 설치했다면 아무리 다시 깔아도 같은 창이 뜹니다.
메이저 버전은 서로를 대신하지 않습니다. 8.0을 요구하는 프로그램에 9.0을 설치해 두었다고 해결되지 않고, 반대로 8.0이 있다고 6.0을 요구하는 프로그램이 실행되지도 않습니다. 대신 문서가 말하는 나란히 설치가 가능하므로, 필요한 버전을 추가로 설치하면 됩니다. 기존 버전을 지울 필요가 없습니다.
1오류창의 문구와 설치 목록을 한 글자씩 대조한다
설치된 앱 목록의 항목 이름이 Microsoft Windows Desktop Runtime인지, 아니면 Microsoft .NET Runtime인지 확인합니다. 이름에 Windows Desktop이 없으면 종류가 다른 것입니다.
2앞자리 두 숫자만 맞추면 된다
오류창이 8.0.x를 요구하면 설치된 항목도 8.0으로 시작하면 됩니다. 뒤의 세부 번호(8.0.4와 8.0.11 등)까지 같을 필요는 없습니다. 앞자리가 다르면 그 버전을 추가로 설치합니다.
3지원이 끝난 버전을 요구해도 받을 수 있다
다운로드 페이지에는 지원이 종료된 이전 버전도 목록에 남아 있습니다. 오래된 업무용 프로그램이 구버전을 요구하면 그 버전을 그대로 받으면 됩니다. 다만 지원이 끝난 버전은 보안 수정이 더 나오지 않으므로, 가능하면 프로그램 제작사에 최신 버전 지원 계획을 문의해 두는 편이 좋습니다.
이 방법이 안 통하는 경우
종류와 버전이 분명히 맞는데도 창이 뜬다면 남은 것은 아키텍처입니다. 목록의 항목 뒤에 붙은 (x64)·(x86) 표기를 확인하고 원인 C로 넘어갑니다.
원인 C프로그램과 런타임의 아키텍처가 다르다
64비트 윈도우라도 32비트 프로그램은 32비트 런타임을 씁니다.
여기서 흔한 오해가 하나 있습니다. 내 윈도우가 64비트니까 x64를 받으면 된다는 생각입니다. 그러나 기준은 윈도우가 아니라 실행하려는 프로그램입니다. 64비트 윈도우에서도 32비트로 만들어진 프로그램은 x86 런타임을 요구합니다. 문서 역시 설치 파일이 아키텍처별로 나란히 설치된다고 밝히고 있으므로, 필요하면 x64와 x86을 함께 설치해도 됩니다.
1프로그램이 몇 비트인지 확인한다
그 프로그램이 조금이라도 실행됐다가 꺼진다면, Ctrl + Shift + Esc로 작업 관리자를 열고 세부 정보 탭에서 실행 파일 이름 뒤에 (32비트) 표기가 붙는지 봅니다. 아예 실행되지 않는다면 설치 폴더가 Program Files (x86) 아래인지 Program Files 아래인지로 대략 가늠할 수 있습니다.
2내 윈도우의 시스템 종류도 함께 본다
Win + I → 시스템 → 정보에서 시스템 종류 줄을 확인합니다. 64비트 운영 체제, x64 기반 프로세서라면 x64와 x86 둘 다 설치할 수 있고, Arm 기반이면 다운로드 페이지의 Arm64 항목을 씁니다.
3판단이 안 서면 x64와 x86을 모두 설치한다
둘은 서로 다른 경로에 나란히 들어가므로 충돌하지 않습니다. 프로그램이 여러 개이고 어느 쪽이 필요한지 확인하는 데 시간이 더 든다면, 같은 버전의 두 아키텍처를 함께 설치하는 편이 빠릅니다.
명령이 인식되지 않을 때도 아키텍처 문제일 수 있습니다
문서는 x86과 x64 설치가 섞여 생기는 충돌을 진단할 때 where.exe dotnet 명령으로 설치 경로가 여러 개 잡히는지 확인하라고 안내합니다. 경로가 둘 이상 나오면 어느 쪽이 먼저 잡히는지에 따라 결과가 달라질 수 있습니다.
이 방법이 안 통하는 경우
두 아키텍처를 모두 설치했는데도 같다면 설치 자체가 끝나지 않았을 가능성이 남습니다. 목록에 항목이 보이는지 다시 확인하고, 없다면 원인 D로 갑니다.
원인 D설치가 중간에 막혀 끝나지 않았다
설치 파일을 분명히 실행했는데 목록에 항목이 없다면 여기입니다.
설치 관리자가 완료 화면 없이 조용히 닫히는 경우가 있습니다. 실행 파일이 보안 프로그램에 격리됐거나, 관리자 권한을 얻지 못했거나, 회사 PC의 정책으로 설치가 차단된 상황입니다. 이때는 "설치했다"고 생각하지만 실제로는 아무것도 설치되지 않은 상태가 됩니다.
1보안 프로그램이 파일을 치웠는지 확인한다
Win + I → 개인 정보 및 보안 → Windows 보안 → Windows 보안 열기 → 바이러스 및 위협 방지 → 보호 기록을 엽니다. 내려받은 설치 파일 이름이 격리된 항목에 있는지 봅니다. 다른 백신을 쓴다면 그 프로그램의 격리·기록 화면에서 같은 것을 확인합니다.
2다시 받아 관리자 권한으로 실행한다
공식 페이지에서 파일을 다시 내려받고, 파일을 우클릭해 관리자 권한으로 실행을 고릅니다. 사용자 계정 컨트롤 창이 뜨면 예를 누릅니다. 진행률이 잠시 멈춘 것처럼 보여도 1~2분 정도는 기다립니다.
3끝난 뒤 설치 목록에서 결과를 확인한다
완료 화면을 봤더라도 설치된 앱 목록에 항목이 실제로 생겼는지까지 확인합니다. 이 단계를 건너뛰면 다시 원인 A와 B 사이를 오가게 됩니다.
4회사 PC라면 정책부터 확인한다
관리자 권한이 제한된 업무용 PC에서는 사용자가 설치할 수 없도록 정책이 걸려 있는 경우가 많습니다. 이때는 보안 설정을 우회하려 하지 말고 필요한 런타임의 이름·버전·아키텍처를 정리해 담당 부서에 요청하는 것이 정상 절차입니다.
보안 설정을 끄고 설치하지 않습니다
격리됐다고 해서 실시간 보호를 끄고 설치하는 것은 순서가 잘못됐습니다. 공식 페이지에서 다시 받아 같은 일이 반복되는지 먼저 보고, 그래도 막히면 예외를 추가하는 쪽이 안전합니다. 공식 배포처가 아닌 곳에서 받은 파일이라면 격리가 정상 동작한 것일 수 있습니다.
이 방법이 안 통하는 경우
설치가 정상으로 끝났고 목록에도 항목이 있는데 프로그램만 안 열린다면, 이제 프로그램이 요구하는 값을 직접 읽어야 합니다. 다음 섹션에서 설치 상태와 요구 버전을 함께 확인합니다.
무엇이 설치돼 있는지 정확히 확인하는 법
설치 목록보다 정확한 자료가 두 가지 있습니다.
1설치된 런타임 목록을 그대로 뽑는다
시작 버튼을 우클릭해 터미널을 열고 입력합니다. 문서의 예시처럼 한 줄에 이름 · 버전 · 경로가 나옵니다. 여기서 찾아야 할 것은 Microsoft.WindowsDesktop.App으로 시작하는 줄이고, 그 뒤 버전이 오류창이 요구한 앞자리와 같아야 합니다.
세 가지 이름이 섞여 나오는데 구분은 간단합니다. Microsoft.NETCore.App은 기본 런타임, Microsoft.WindowsDesktop.App은 데스크톱 런타임, Microsoft.AspNetCore.App은 웹용입니다. WindowsDesktop 줄이 하나도 없다면 지금까지 설치한 것은 데스크톱 런타임이 아니었다는 뜻입니다.
2명령이 안 되면 폴더를 직접 연다
"dotnet은 내부 또는 외부 명령이 아닙니다"가 나오면 실행 파일 경로가 안 잡힌 상태입니다. 문서도 이럴 때 설치 폴더를 직접 확인하라고 안내합니다. Win + E로 탐색기를 열어 위 경로를 주소창에 붙여 넣으면 버전 번호 이름의 폴더가 보입니다. 그 이름이 곧 설치된 데스크톱 런타임 버전입니다.
3오류창에 버전이 없으면 로그에서 찾는다
Win + R에 입력해 실행하고 Windows 로그 → 응용 프로그램에서 실행을 시도한 시각의 오류 항목을 엽니다. 아래 일반 탭에 어떤 프레임워크의 몇 번 버전을 찾지 못했는지가 적히는 경우가 많습니다. 오류창에 숫자가 없을 때 요구 버전을 알아내는 방법입니다.
4그래도 모르겠으면 제작사에 물어본다
사내 업무 프로그램처럼 배포처가 분명한 경우, 필요한 .NET 버전과 아키텍처를 묻는 것이 가장 빠릅니다. 추측으로 여러 버전을 설치하는 것보다 정확합니다.
자주 묻는 질문
판단이 갈리는 지점만 모았습니다.
Q.이 영어 팝업이 바이러스나 가짜 창은 아닌가요?
A.실행하려는 프로그램이 필요한 런타임을 못 찾았을 때 띄우는 정상 안내입니다. 다만 창 안의 다운로드 버튼을 눌러 열린 페이지가 마이크로소프트 공식 주소인지는 확인하는 편이 좋습니다. 런타임은 항상 공식 다운로드 페이지에서 받습니다.
Q.x64와 x86 중 뭘 받아야 할지 모르겠습니다.
A.오류창에 적힌 표기를 그대로 따르는 것이 가장 정확합니다. 기준은 내 윈도우가 아니라 실행하려는 프로그램이라는 점을 기억하세요. 표기가 없다면 원인 C의 방법으로 프로그램 비트를 확인하고, 그래도 애매하면 두 아키텍처를 함께 설치해도 충돌하지 않습니다.
Q.여러 버전을 같이 설치해도 되나요?
A.됩니다. 문서는 설치 파일이 메이저·마이너 릴리스와 아키텍처별로 나란히 설치되도록 만들어져 있다고 명시하고, 6.0(x64)과 6.0(x86)을 함께 설치하는 예까지 들고 있습니다. 프로그램마다 요구 버전이 달라도 각각 설치해 두면 됩니다.
Q..NET Framework와는 다른 건가요?
A.다릅니다. .NET Framework는 윈도우에 묶여 한 대에 한 버전만 존재하지만, 지금 다루는 .NET은 윈도우와 별개로 설치되고 여러 버전이 공존합니다. 오류창에 .NET Framework 4.x가 적혀 있다면 이 글의 다운로드 페이지가 아니라 .NET Framework 쪽 설치 파일이 필요합니다.
Q.SDK를 설치하면 한 번에 해결되나요?
A.문서의 구성 표상 SDK에는 세 런타임이 모두 포함되므로 실행은 됩니다. 다만 SDK는 개발용이라 용량이 크고 프로그램 실행에는 불필요한 구성 요소까지 들어옵니다. 실행만 하려는 목적이라면 Desktop Runtime만 설치하는 편이 낫습니다.
Q.설치한 런타임을 나중에 지워도 되나요?
A.지울 수는 있지만 권하지 않습니다. 한 버전을 여러 프로그램이 함께 사용하기 때문에, 지우면 지금 잘 돌아가던 다른 프로그램에서 같은 창이 새로 뜹니다. 정리 도구가 "사용하지 않는 항목"으로 제안하더라도 이 계열은 남겨 두는 편이 안전합니다.
함께 보면 좋은 글
같은 "실행에 필요한 구성 요소가 없다" 계열의 오류들입니다.
VCRUNTIME140.dll·MSVCP140.dll 없음 오류 원인 4가지와 증상별 해결 순서 C++ 쪽 런타임이 없을 때 나오는 창으로, 판별 방식이 같습니다 · 눌러서 확인하기 → 이 앱은 사용자의 PC에서 실행할 수 없습니다 오류 해결법 32비트·64비트가 어긋났을 때 나타나는 다른 형태의 메시지입니다 · 눌러서 확인하기 → 지정된 모듈을 찾을 수 없습니다(오류 126), 원인 4가지와 각각의 해결법 구성 요소는 있는데 불러오지 못할 때 나오는 메시지를 정리한 글입니다 · 눌러서 확인하기 →참고 문서 · Microsoft Learn — Windows에 .NET 설치
참고 문서 · Microsoft Learn — 설치된 .NET 버전을 확인하는 방법
참고 문서 · Microsoft — .NET 공식 다운로드
