Windows 11에서 Docker Desktop이 실행되지 않을 때 — WSL2·가상화·Docker Engine 상태 점검

작성자:
Windows 11에서 Docker Desktop이 실행되지 않을 때 대표 이미지

Windows 11에서 Docker Desktop을 실행했는데 시작 화면에서 멈추거나 Docker 명령어가 정상적으로 동작하지 않는 경우가 있습니다.

특히 다음과 같은 오류가 발생하면 Docker Desktop 자체를 반복해서 재설치하기 쉽습니다.

Docker Desktop starting...

상태가 계속 유지되거나:

Cannot connect to the Docker daemon

과 같은 메시지가 나타나는 경우입니다.

하지만 Windows에서 WSL2 백엔드를 사용하는 Docker Desktop은 단순한 Windows 프로그램 하나로 동작하는 것이 아닙니다.

Windows 하드웨어 가상화 → WSL2 → Docker Desktop 백엔드 → Docker Engine → Docker CLI

여러 단계가 연결되어 있기 때문에 어느 단계에서 문제가 발생했는지를 먼저 구분하는 것이 중요합니다.

이 글에서는 Docker Desktop을 바로 재설치하기보다 WSL2와 Windows 가상화 상태부터 확인하고, 이후 Docker Engine과 실제 컨테이너 실행까지 단계적으로 점검합니다.

먼저 확인할 내용

확인 기준 환경

  • OS: Windows 11 25H2
  • Docker Desktop: 설치된 버전 확인 필요
  • Backend: WSL2 기준
  • Linux Container 사용 환경 기준

Windows 11 25H2는 이 글의 확인 기준 OS이며, 아래의 모든 Docker Desktop 오류를 동일 환경에서 직접 재현했다는 의미는 아닙니다.

공식 문서 확인일: 2026-08-25

대표 증상

다음과 같은 상황을 대상으로 합니다.

  • Docker Desktop이 시작되지 않음
  • Docker Desktop이 Starting 상태에서 멈춤
  • Docker Engine이 실행되지 않음
  • docker 명령은 있지만 Server에 연결되지 않음
  • Cannot connect to the Docker daemon 오류 발생
  • Docker Desktop 업데이트 후 실행되지 않음
  • WSL 업데이트 이후 Docker가 동작하지 않음
  • Ubuntu에서는 docker 명령을 찾을 수 없음
  • Docker Desktop에서는 정상인데 WSL Ubuntu에서 Docker 명령이 동작하지 않음
  • docker version에서 Client만 표시되고 Server 정보가 나오지 않음

결론

Docker Desktop이 실행되지 않을 때는 다음 순서로 확인하는 것이 좋습니다.

Docker Desktop 상태 확인
↓
WSL 버전 및 상태 확인
↓
CPU 가상화 확인
↓
Virtual Machine Platform 확인
↓
Docker Desktop WSL2 Backend 확인
↓
WSL Integration 확인
↓
docker version / docker info 확인
↓
Docker Context 확인
↓
실제 컨테이너 실행
↓
필요하면 Docker Desktop 진단 정보 확인

Docker Desktop 재설치는 이 과정에서 가장 먼저 할 작업이 아니라 마지막 단계에 가까운 작업으로 두는 편이 좋습니다.

1. Docker Desktop이 실제로 실행 중인지 확인

가장 먼저 Windows 작업 표시줄의 시스템 트레이를 확인합니다.

Docker Desktop이 정상적으로 시작되면 Docker 아이콘을 확인할 수 있습니다.

Docker Desktop Dashboard가 열린다면 현재 상태도 확인합니다.

예를 들어 계속:

Starting

상태에 머물러 있다면 Docker CLI보다 먼저 Docker Desktop 백엔드가 정상적으로 시작되지 않은 원인을 확인해야 합니다.

반대로 Docker Desktop Dashboard가 정상적으로 열리고 Engine도 실행 중인데 명령어만 실패한다면 Docker CLI 또는 Context 문제로 범위를 좁힐 수 있습니다.

2. Docker CLI 설치 상태 확인

PowerShell 또는 Windows Terminal을 실행하고 다음 명령을 입력합니다.

docker --version

정상적으로 설치되어 있다면 Docker CLI 버전이 표시됩니다.

다만 이 명령만 성공했다고 해서 Docker Engine까지 정상인 것은 아닙니다.

docker --version은 기본적으로 Docker CLI 버전 확인에 가깝습니다.

Docker Engine 연결 상태까지 확인하려면 다음 단계의 docker version을 사용합니다.

3. docker version으로 Client와 Server를 함께 확인

다음 명령을 실행합니다.

docker version

Docker 공식 문서에 따르면 docker version은 Docker 구성 요소의 버전을 확인하며 결과가 크게:

Client

와:

Server

영역으로 나뉩니다.

Client와 Server가 모두 표시되는 경우

Docker CLI가 Docker Engine과 정상적으로 통신하고 있을 가능성이 높습니다.

Client만 표시되고 Server 오류가 발생하는 경우

Docker CLI 자체는 설치되어 있지만 Docker Engine과 연결하지 못하는 상태일 가능성이 있습니다.

예를 들어 이런 구조입니다.

Docker CLI 정상
↓
Docker Engine 연결 실패

따라서 Docker Desktop 문제를 확인할 때 docker --version과 docker version을 같은 의미로 사용하지 않는 것이 중요합니다.

4. docker info로 Docker Engine 상태 확인

다음 명령을 실행합니다.

docker info

docker info는 Docker 설치 환경과 Engine의 시스템 정보를 확인할 수 있는 대표적인 명령입니다.

정상 상태에서는 환경에 따라 다음과 같은 정보를 확인할 수 있습니다.

  • Client 정보
  • Server 정보
  • Container 개수
  • Image 개수
  • Server Version
  • Storage Driver
  • Kernel Version
  • Operating System
  • CPU
  • Memory
  • Docker Root Directory

특히 Server 영역이 정상적으로 출력되는지 확인합니다.

docker version과 docker info 모두 Server와 통신하지 못한다면 Docker CLI 사용법보다는 Docker Desktop Engine과 WSL2 상태를 확인하는 편이 좋습니다.

5. WSL 버전 확인

Docker Desktop에서 WSL2 백엔드를 사용한다면 WSL 상태가 중요합니다.

PowerShell에서 다음 명령을 실행합니다.

wsl --version

Docker 공식 문서에서는 현재 WSL2 백엔드 사용 시 최소 WSL 2.1.5 이상을 요구하며 최신 WSL 사용을 권장하고 있습니다.

오래된 WSL 버전에서는 Docker Desktop이 예상대로 동작하지 않거나 업데이트 이후 문제가 발생할 수 있습니다.

WSL 버전 정보가 정상적으로 표시되는지 먼저 확인합니다.

6. WSL 전체 상태 확인

다음 명령을 실행합니다.

wsl --status

이 명령에서는 WSL의 기본 구성과 Kernel 관련 상태를 확인할 수 있습니다.

그다음 설치된 WSL 배포판과 버전을 확인합니다.

wsl -l -v

또는:

wsl --list --verbose

를 사용할 수 있습니다.

여기에서 사용자 Ubuntu가 WSL2로 실행되고 있는지도 확인합니다.

예를 들어:

Ubuntu Stopped 2

처럼 VERSION이 2라면 WSL2 배포판입니다.

Stopped 자체는 오류가 아닙니다.

현재 사용하지 않는 배포판은 정상적으로 Stopped 상태일 수 있습니다.

7. docker-desktop WSL 배포판 확인

WSL2 백엔드를 사용하는 Docker Desktop은 Docker Desktop 전용 WSL 환경을 사용합니다.

다시 다음 명령을 확인합니다.

wsl -l -v

환경에 따라 목록에서 docker-desktop을 확인할 수 있습니다.

여기서 한 가지 주의할 점이 있습니다.

과거 Docker Desktop에서는 docker-desktop-data라는 별도의 배포판도 흔히 볼 수 있었지만, 최신 Docker Desktop은 WSL 데이터 저장 구조가 변경됐기 때문에 docker-desktop-data가 없다는 사실만으로 오류라고 판단하면 안 됩니다.

Docker Desktop은 2024년 이후 WSL2의 단일 배포판 구조로 전환해왔기 때문에 현재 설치 버전에 따라 목록 구성이 다를 수 있습니다.

따라서 특정 배포판 이름 하나의 존재 여부보다 Docker Desktop과 WSL 전체가 정상적으로 시작되는지를 중심으로 판단하는 것이 좋습니다.

8. WSL이 오래된 경우 업데이트

WSL 버전이 오래됐거나 Docker Desktop 업데이트 후 WSL 관련 문제가 의심된다면 다음 명령을 실행합니다.

wsl --update

업데이트가 끝나면 다시 버전을 확인합니다.

wsl --version

Docker 공식 문서도 WSL2 백엔드 환경에서는 최신 WSL 사용을 권장합니다.

WSL을 업데이트했다면 Docker Desktop을 바로 반복 실행하기보다 필요에 따라 WSL 환경을 완전히 종료한 뒤 다시 시작하는 것도 좋습니다.

9. WSL 환경 완전히 종료 후 다시 시작

다음 명령을 실행합니다.

wsl --shutdown

이 명령은 실행 중인 WSL 배포판과 WSL2 경량 가상 머신을 종료합니다.

Microsoft 공식 문서에서도 wsl --shutdown은 실행 중인 WSL 배포판과 WSL2 Utility VM을 즉시 종료하는 명령으로 설명합니다.

명령을 실행한 뒤 Docker Desktop을 다시 시작합니다.

이 방법은 다음과 같은 경우에 유용할 수 있습니다.

  • Docker Desktop이 Starting 상태에서 멈춘 경우
  • WSL 업데이트 이후 Docker가 이상한 경우
  • Docker Desktop 종료 후에도 WSL 상태가 꼬인 것으로 의심되는 경우
  • 시스템 절전 또는 재개 이후 Docker가 정상적으로 연결되지 않는 경우

다만 Windows 선택적 기능이나 BIOS 가상화 설정을 변경했다면 wsl --shutdown만 하지 말고 Windows를 재부팅하는 편이 좋습니다.

10. CPU 하드웨어 가상화 확인

WSL2 백엔드는 하드웨어 가상화 기능이 필요합니다.

Windows에서:

Ctrl + Shift + Esc

를 눌러 작업 관리자를 실행합니다.

다음으로 이동합니다.

성능 → CPU

여기에서 다음 상태를 확인합니다.

가상화: 사용

또는:

Virtualization: Enabled

Enabled인 경우

BIOS/UEFI 수준의 CPU 가상화 기능은 활성화된 상태입니다.

Disabled인 경우

BIOS 또는 UEFI 설정을 확인해야 합니다.

Intel 환경에서는 보통:

  • Intel Virtualization Technology
  • Intel VT-x
  • Virtualization Technology

AMD 환경에서는:

  • AMD-V
  • SVM
  • SVM Mode

등의 이름을 사용합니다.

정확한 메뉴 이름은 PC 또는 메인보드 제조사마다 다르므로 제조사 공식 문서를 참고하는 것이 좋습니다.

11. Virtual Machine Platform 확인

하드웨어 가상화가 활성화되어 있어도 Windows의 Virtual Machine Platform 기능이 비활성화되어 있다면 WSL2가 정상적으로 동작하지 않을 수 있습니다.

관리자 권한 PowerShell에서 다음 명령을 실행합니다.

Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

다음 부분을 확인합니다.

State : Enabled

비활성화되어 있다면 관리자 권한 PowerShell 또는 CMD에서 다음 명령으로 활성화할 수 있습니다.

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

설정을 변경했다면 Windows를 재부팅합니다.

Microsoft 공식 WSL 문서에서도 WSL2를 사용하려면 Virtual Machine Platform 기능과 하드웨어 가상화가 필요하다고 설명합니다.

12. Windows Subsystem for Linux 기능도 확인

WSL 선택적 구성 요소 상태도 함께 확인할 수 있습니다.

관리자 PowerShell에서:

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

상태가:

Enabled

인지 확인합니다.

WSL 자체 상태와 Virtual Machine Platform을 함께 확인하면 다음 구조를 구분할 수 있습니다.

하드웨어 가상화
↓
Virtual Machine Platform
↓
WSL2
↓
Docker Desktop

따라서 Docker Desktop 실행 오류에서 Docker 프로그램만 계속 재설치하는 것보다 이 하위 계층부터 확인하는 편이 효율적입니다.

13. Docker Desktop이 WSL2 Backend를 사용하는지 확인

Docker Desktop을 실행할 수 있다면 다음으로 이동합니다.

Settings → General

WSL2 기반 Engine 설정을 확인합니다.

Docker 공식 문서에서는 지원되는 Windows 환경에서 Docker Desktop의 WSL2 백엔드를 사용할 수 있으며, 현재 WSL2는 Windows에서 기본 백엔드로 사용됩니다.

환경에 따라 해당 설정은 기본으로 활성화되어 있고 별도의 옵션이 표시되지 않을 수도 있습니다.

따라서 메뉴가 보이지 않는다는 이유만으로 바로 오류라고 판단하지 않습니다.

14. Ubuntu에서 Docker가 실행되지 않으면 WSL Integration 확인

Windows PowerShell에서는 docker 명령이 정상인데 Ubuntu 터미널에서는:

docker: command not found

또는 Docker Engine 연결 오류가 발생한다면 WSL Integration을 확인합니다.

Docker Desktop에서:

Settings → Resources → WSL Integration

으로 이동합니다.

사용할 WSL2 배포판이 활성화되어 있는지 확인합니다.

예를 들어 Ubuntu를 사용한다면 Ubuntu에 대한 Integration을 활성화합니다.

변경한 뒤 Apply를 선택합니다.

Docker 공식 문서에 따르면 WSL Integration을 활성화하면 해당 Linux 배포판 내부에서도 Docker CLI를 사용할 수 있습니다.

15. WSL Integration 메뉴가 보이지 않는 경우

Docker Desktop의:

Settings → Resources

에서 WSL Integration 항목이 보이지 않는 경우에는 현재 Docker Desktop이 Windows Container Mode인지 확인합니다.

Docker 공식 문서에서도 WSL Integration 메뉴가 나타나지 않는 경우 Docker가 Windows Container Mode일 수 있다고 안내합니다.

Linux Container를 사용할 목적이라면 Docker Desktop 메뉴에서 Linux Container 모드로 전환되어 있는지 확인합니다.

Linux Container와 Windows Container는 실행 방식과 지원 환경이 다르므로 현재 어떤 Engine을 사용하는지 구분하는 것이 중요합니다.

16. Ubuntu에 Docker Engine을 별도로 설치했는지 확인

Docker Desktop과 WSL Integration을 사용하는 환경에서는 주의할 부분이 있습니다.

Docker 공식 문서는 Docker Desktop의 WSL2 기능을 사용하기 전에 WSL Linux 배포판 내부에 별도로 설치했던 Docker Engine이나 Docker CLI가 있다면 충돌 가능성을 확인하도록 안내합니다.

구조가 다음처럼 되어 있으면 문제가 복잡해질 수 있습니다.

Windows Docker Desktop

Ubuntu 내부에 별도로 설치한 Docker Engine

이 두 구성을 의도적으로 분리해서 운영하는 것이 아니라면 어떤 Docker Engine에 연결하는지 혼동될 수 있습니다.

따라서 Ubuntu에서 다음과 같이 Docker를 별도 설치한 이력이 있는지도 확인합니다.

  • Docker Engine
  • Docker CLI
  • docker.io
  • docker-ce

무조건 제거하기보다 현재 어떤 구성을 사용하려는지 먼저 확인해야 합니다.

Docker Desktop + WSL Integration을 사용할 것인지, Ubuntu 내부 Docker Engine을 독립적으로 사용할 것인지 목적을 명확히 합니다.

17. Docker Context 확인

Docker Desktop이 실행 중인데도 CLI가 예상하지 않은 Docker Engine에 연결되는 것 같다면 Context를 확인합니다.

docker context show

현재 선택된 Context 이름이 표시됩니다.

전체 Context를 확인하려면:

docker context ls

를 실행합니다.

현재 활성화된 Context에는 일반적으로 * 표시가 나타납니다.

Docker Context는 Docker CLI가 어떤 Docker Engine Endpoint와 통신할지를 결정합니다.

따라서 과거에 원격 Docker Engine이나 별도의 Docker 환경을 사용했다면 현재 Context가 예상과 다르게 설정돼 있을 수 있습니다.

문제가 발생했다고 Context를 임의로 삭제하지 말고 먼저 현재 상태를 기록합니다.

18. DOCKER_HOST와 DOCKER_CONTEXT 환경 변수 확인

Context 설정이 정상적으로 보이는데도 예상하지 않은 Docker Engine에 연결된다면 환경 변수도 확인합니다.

PowerShell에서:

Get-ChildItem Env:DOCKER_HOST, Env:DOCKER_CONTEXT -ErrorAction SilentlyContinue

값이 설정되어 있다면 Docker CLI가 기본 설정과 다른 Endpoint 또는 Context를 사용할 가능성을 확인해야 합니다.

Docker 공식 CLI 문서에 따르면 DOCKER_CONTEXT 환경 변수는 현재 Docker Context 설정을 재정의할 수 있으며, DOCKER_HOST도 Docker daemon Endpoint 지정에 영향을 줄 수 있습니다.

과거 개발 환경이나 스크립트에서 설정한 값이 남아 있는지도 확인합니다.

19. 실제 컨테이너 실행으로 최종 확인

Docker Engine이 정상적으로 연결됐다면 단순히 docker info까지만 확인하지 말고 실제 Container 실행도 테스트합니다.

다음 명령을 사용합니다.

docker run --rm hello-world

처음 실행하는 환경이라면 Docker가 hello-world 이미지를 내려받은 뒤 테스트 Container를 실행합니다.

정상적으로 실행된다면 최소한 다음 과정이 동작한 것입니다.

Docker CLI
↓
Docker Engine
↓
Image Pull
↓
Container 생성
↓
Container 실행

따라서 Docker Desktop 정상 여부를 확인할 때 상당히 유용한 최종 테스트입니다.

20. hello-world가 실패하면 오류 단계를 구분

docker run --rm hello-world가 실패했다고 해서 모두 Docker Engine 문제는 아닙니다.

Docker daemon 연결 오류

Cannot connect to the Docker daemon

등이 나타난다면 Docker Engine 또는 Context 연결 상태를 다시 확인합니다.

Image 다운로드 오류

Docker Hub에서 이미지를 내려받는 단계에서 실패한다면 다음 영역을 확인합니다.

  • DNS
  • Internet 연결
  • Proxy
  • Firewall
  • 인증서
  • Docker Hub 접근 정책

Container 생성 이후 오류

이미지는 정상적으로 내려받았지만 Container 시작이 실패한다면 Docker Engine Runtime과 관련된 오류 메시지를 확인합니다.

즉 hello-world 테스트에서도 어느 단계까지 성공했는지를 확인하는 것이 중요합니다.

21. 실행 중인 Container 상태 확인

Docker Engine이 정상적으로 동작한다면 다음 명령을 실행합니다.

docker ps

현재 실행 중인 Container를 확인합니다.

중지된 Container까지 포함해서 확인하려면:

docker ps -a

를 사용합니다.

Docker Desktop 문제와 특정 Container 문제도 구분해야 합니다.

예를 들어 Docker Engine 자체는 정상인데 특정 Container만 종료된다면 Docker Desktop을 재설치할 문제가 아닐 가능성이 높습니다.

이 경우에는 해당 Container 로그와 설정을 확인하는 단계로 넘어가야 합니다.

22. Docker Desktop 자체 재시작

WSL과 Docker Engine 상태를 확인했지만 Docker Desktop 상태가 이상하다면 Dashboard의 Troubleshoot 기능을 사용할 수 있습니다.

Docker Desktop에서:

Troubleshoot → Restart Docker Desktop

을 실행합니다.

단순 Backend 상태 문제라면 전체 설정을 삭제하지 않고 Docker Desktop만 다시 시작하는 방법부터 시도하는 것이 좋습니다.

Reset to factory defaults와는 완전히 다른 작업입니다.

23. Reset to factory defaults는 처음부터 사용하지 않기

Docker Desktop Troubleshoot 메뉴에는 Reset to factory defaults 기능도 있습니다.

하지만 이것을 초기 문제 해결 방법으로 사용하는 것은 권장하지 않습니다.

Factory Reset은 Docker Desktop 설정을 초기 상태로 되돌리는 작업이기 때문에 기존 개발 환경에 영향을 줄 수 있습니다.

특히 Container, Image, Volume 등 기존 Docker 데이터가 중요한 환경에서는 초기화 또는 삭제 기능을 실행하기 전에 반드시 영향 범위를 확인해야 합니다.

먼저:

WSL 상태 → Engine 상태 → Context → 로그

순서로 원인을 확인합니다.

24. Docker Desktop 진단 기능 사용

앞의 확인으로 원인이 명확하지 않다면 Docker Desktop 공식 진단 기능을 사용할 수 있습니다.

Docker Desktop에서:

Troubleshoot → Get support

또는 오류 화면의:

Gather diagnostics

기능을 사용할 수 있습니다.

현재 Docker Desktop CLI가 지원되는 환경에서는 터미널에서 다음 명령도 사용할 수 있습니다.

docker desktop diagnose

Docker 공식 문서에 따르면 이 기능은 Docker Desktop의 진단 정보를 수집하고 문제 분석에 사용할 수 있는 Diagnostic ID와 관련 정보를 제공합니다.

단순 재설치 전에 진단 정보를 확보해두면 문제가 반복될 때 원인을 비교하기도 좋습니다.

25. 로그와 진단 정보 공유 시 주의

Docker Desktop 진단 파일이나 로그를 외부에 공유할 때는 내용을 확인해야 합니다.

환경에 따라 다음 정보가 포함될 가능성이 있습니다.

  • Windows 사용자 경로
  • 내부 Hostname
  • Container 이름
  • Image 이름
  • Registry 주소
  • Proxy 정보
  • 내부 네트워크 정보
  • 개발 프로젝트 관련 정보

회사 또는 기관 환경에서는 로그를 외부 서비스에 Upload하기 전에 보안 정책을 먼저 확인합니다.

26. WSL2 파일 시스템 성능도 구분하기

Docker Desktop은 실행되지만 Volume 또는 Build가 유난히 느린 경우에는 실행 실패와 성능 문제를 구분해야 합니다.

WSL2 기반 Linux Container에서는 Windows 파일 시스템을 WSL을 통해 반복해서 접근하는 것보다 Linux 파일 시스템 내부에 소스 코드를 두는 것이 성능상 유리한 경우가 있습니다.

예를 들어 WSL 내부의:

~/my-project

와 같은 위치를 사용하는 방식입니다.

Docker 공식 WSL2 Best Practices에서도 Linux Container와 Bind Mount를 사용하는 작업에서는 Linux 파일 시스템에 소스 코드를 저장하는 방법을 권장합니다.

따라서 Docker Desktop이 느리다고 해서 무조건 WSL이나 Engine이 고장났다고 판단하지 않고 파일 저장 위치와 I/O 패턴도 구분해야 합니다.

27. WSL2와 VirtualBox를 함께 사용하는 경우

같은 Windows PC에서:

  • Docker Desktop
  • WSL2
  • VirtualBox

를 함께 사용하는 경우에는 Windows 가상화 계층이 서로 연결되어 있다는 점을 이해할 필요가 있습니다.

Docker Desktop의 WSL2 Backend는 WSL2와 Virtual Machine Platform을 사용합니다.

따라서 VirtualBox 문제를 해결하기 위해 Windows 가상화 기능을 변경했다면 Docker Desktop과 WSL2에도 영향을 줄 수 있습니다.

반대로 Docker Desktop 문제를 해결하기 위해 가상화 관련 설정을 무작정 변경하면 VirtualBox 환경에도 영향을 줄 수 있습니다.

VirtualBox와 Hyper-V/VBS 관계는 다음 글에서 별도로 확인할 수 있습니다.

Windows 11에서 VirtualBox 가상 머신이 실행되지 않을 때 — VT-x·AMD-V·Hyper-V·VBS 점검

또한 WSL2 자체 실행 문제가 있다면 앞서 정리한 WSL2 진단 글을 먼저 확인하는 것이 좋습니다.

이렇게 각 프로그램을 개별적으로 재설치하기보다 공통으로 사용하는 Windows 가상화 계층부터 확인하면 원인을 더 빠르게 구분할 수 있습니다.

28. 설정 변경 후 정상 여부 재검증

설정을 변경했다면 처음 확인했던 명령을 동일하게 다시 실행합니다.

WSL 상태 확인

wsl --version

wsl --status

wsl -l -v

Docker Client / Engine 확인

docker version

Docker 전체 상태 확인

docker info

Context 확인

docker context show

실제 Container 실행

docker run --rm hello-world

이 과정을 통해 단순히 Docker Desktop 창이 열리는 것만이 아니라 실제 Docker Engine과 Container 실행까지 정상인지 확인합니다.

해결되지 않는 경우 추가 확인

문제가 계속된다면 다음 정보를 먼저 정리합니다.

  • Windows 버전 및 Build
  • Docker Desktop 버전
  • WSL 버전
  • WSL Kernel 정보
  • wsl -l -v 결과
  • CPU Virtualization 상태
  • Virtual Machine Platform 상태
  • Docker Desktop Backend 종류
  • WSL Integration 상태
  • docker version 결과
  • docker info 결과
  • docker context show 결과
  • 실제 오류 메시지
  • 오류 발생 시점
  • Docker Desktop 업데이트 직후인지 여부

특히 docker version 결과에서 Client는 나오지만 Server가 나오지 않는지 확인하면 문제 범위를 빠르게 좁힐 수 있습니다.

또한 Docker Desktop 자체가 시작되지 않는 경우에는 Troubleshoot의 Diagnostic 기능을 이용해 진단 정보를 확보합니다.

주의사항

Docker Desktop 문제를 해결할 때는 다음 사항을 주의합니다.

  • 처음부터 Docker Desktop을 삭제하고 재설치하지 않기
  • WSL 배포판을 무조건 삭제하지 않기
  • docker-desktop-data가 보이지 않는다고 무조건 오류로 판단하지 않기
  • Virtual Machine Platform을 임의로 비활성화하지 않기
  • VirtualBox 때문에 변경했던 가상화 설정이 Docker Desktop에 영향을 주는지 확인하기
  • Ubuntu 내부 Docker Engine과 Docker Desktop WSL Integration을 혼동하지 않기
  • Docker Context를 확인하지 않고 임의로 삭제하지 않기
  • 중요 Volume과 Image가 있는 환경에서 Factory Reset을 바로 실행하지 않기
  • 진단 파일 외부 공유 전 민감한 시스템 정보 확인하기
  • 변경 후 반드시 같은 명령으로 정상 여부 재검증하기

마무리

Windows 11에서 Docker Desktop이 실행되지 않을 때는 Docker Desktop 프로그램 자체만 확인해서는 원인을 정확하게 구분하기 어렵습니다.

특히 WSL2 Backend를 사용하는 환경에서는 Docker Desktop 아래에 Windows 가상화와 WSL2라는 기반 계층이 존재합니다.

따라서 먼저:

CPU 하드웨어 가상화

↓

Virtual Machine Platform

↓

WSL2

상태를 확인합니다.

그다음 Docker 영역에서는:

Docker Desktop

↓

WSL Integration

↓

Docker Engine

↓

Docker Context

↓

Container 실행

순서로 확인합니다.

명령어 기준으로 정리하면 다음 흐름입니다.

wsl --version → wsl -l -v → docker version → docker info → docker context show → docker run --rm hello-world

여기서 중요한 것은 어느 단계까지 정상적으로 동작하는지 확인하는 것입니다.

예를 들어 docker --version은 정상인데 docker version에서 Server 정보를 확인할 수 없다면 Docker CLI 재설치보다 Docker Engine 연결 상태를 우선 확인해야 합니다.

반대로 docker version과 docker info가 모두 정상이고 특정 Container만 실행되지 않는다면 Docker Desktop 전체의 문제가 아니라 해당 Image나 Container 설정 문제로 범위를 좁힐 수 있습니다.

WSL2 역시 마찬가지입니다.

Docker Desktop이 실행되지 않는다고 WSL을 바로 삭제하는 것이 아니라 wsl --version, wsl --status, wsl -l -v로 현재 상태를 먼저 확인해야 합니다.

결국 Docker Desktop 장애 분석의 핵심은:

현재 상태 확인 → 문제가 발생한 계층 분리 → 필요한 부분만 수정 → 동일 명령으로 재검증

순서를 지키는 것입니다.

이 과정을 따르면 Docker Desktop 전체를 반복해서 재설치하는 방식보다 원인을 훨씬 명확하게 파악할 수 있습니다.

참고 자료

변경 이력

2026-08-25

  • 기존 Docker Desktop 설치 중심 콘텐츠를 실행 장애 진단 중심으로 개편
  • Windows 11 25H2 확인 기준 환경 반영
  • WSL2와 Virtual Machine Platform 확인 절차 추가
  • Docker Desktop WSL2 Backend 및 WSL Integration 확인 추가
  • docker version을 이용한 Client/Server 상태 구분 추가
  • docker info를 이용한 Docker Engine 상태 확인 추가
  • Docker Context 및 환경 변수 확인 방법 추가
  • hello-world Container를 이용한 최종 실행 검증 추가
  • wsl --update, wsl --shutdown 기반 WSL 재시작 절차 추가
  • 최신 Docker Desktop의 WSL 데이터 구조 변경 관련 주의사항 추가
  • Docker Desktop Diagnostics 확인 방법 추가
  • WSL2 파일 시스템 성능 관련 확인 항목 추가
  • VirtualBox·WSL2 게시글과 연결 가능한 내부 문제 해결 흐름 추가

Post Views: 53