VSCode Dev Container를 열 때 Cannot connect to the Docker daemon, Is Docker running?, Docker daemon is not running 같은 메시지가 나오면 먼저 Docker가 실제로 실행 중인지 확인해야 합니다. 이 오류는 Dev Container 설정 문제처럼 보이지만, 대부분은 VSCode가 Docker daemon에 접근하지 못할 때 발생합니다.
아래 순서대로 확인하면 Windows, Mac, Linux 환경에서 원인을 빠르게 좁힐 수 있습니다. 핵심은 Docker 실행 상태 → VSCode 터미널 확인 → 권한 문제 → Docker context → Dev Container 재실행 순서입니다.
VSCode Dev Container에서 Docker daemon 연결 상태를 먼저 확인하면 원인을 빠르게 좁힐 수 있습니다.
오류 메시지 원문
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Docker returned an error. Make sure the Docker daemon is running.
error during connect: open //./pipe/docker_engine: The system cannot find the file specified.
메시지는 조금씩 다르지만 의미는 비슷합니다. VSCode Dev Containers 확장이 Docker 명령을 실행했지만, Docker daemon과 통신하지 못했다는 뜻입니다.
먼저 확인할 빠른 해결 순서
| 순서 | 확인 항목 | 명령어 또는 조치 |
|---|---|---|
| 1 | Docker 실행 상태 | docker version |
| 2 | 컨테이너 목록 확인 | docker ps |
| 3 | VSCode 재시작 | Command Palette → Reload Window |
| 4 | Docker context 확인 | docker context ls |
원인 1. Docker Desktop이 실행되지 않은 경우
Windows와 Mac에서는 Docker Desktop이 켜져 있어야 Dev Container가 Docker daemon에 연결할 수 있습니다. 앱은 열려 있지만 내부 엔진이 아직 시작 중일 수도 있으므로, Docker Desktop 화면에서 상태가 정상인지 확인합니다.
docker version
docker ps
docker version에서 Client 정보만 나오고 Server 정보가 나오지 않으면 Docker daemon 쪽 문제일 가능성이 큽니다. Docker Desktop을 완전히 종료한 뒤 다시 실행하고, 상태가 Running으로 바뀐 뒤 VSCode에서 다시 시도합니다.
원인 2. Windows WSL 2 연결이 꼬인 경우
Windows에서 Dev Container를 사용할 때는 Docker Desktop의 WSL 2 통합 상태가 중요합니다. WSL 배포판 안에서 VSCode를 열었는데 Docker Desktop과 해당 배포판이 연결되어 있지 않으면 Docker 명령이 실패할 수 있습니다.
wsl -l -v
Docker Desktop 설정에서 Settings → Resources → WSL Integration으로 이동한 뒤, 사용하는 Ubuntu 배포판의 통합을 켭니다. 이후 WSL과 Docker Desktop을 다시 시작합니다.
wsl --shutdown
위 명령은 실행 중인 WSL 세션을 종료합니다. 저장하지 않은 터미널 작업이 있다면 먼저 정리한 뒤 실행하는 것이 좋습니다.
원인 3. Linux에서 Docker 권한이 없는 경우
Linux에서는 현재 사용자가 Docker socket에 접근할 권한이 없으면 VSCode에서는 실패하고, 터미널에서 sudo docker ps만 되는 상황이 생길 수 있습니다.
docker ps
권한 오류가 나오면 현재 사용자를 docker 그룹에 추가합니다.
sudo usermod -aG docker $USER
이후 로그아웃 후 다시 로그인하거나 시스템을 재시작해야 적용됩니다. docker 그룹은 높은 권한을 갖기 때문에 개인 개발 장비인지, 회사 보안 정책상 허용되는지 먼저 확인하는 것이 좋습니다.
원인 4. Docker context가 다른 대상으로 잡힌 경우
Docker context가 원격 Docker, Colima, Rancher Desktop, 오래된 Docker Desktop context로 잡혀 있으면 Dev Container가 엉뚱한 daemon에 연결하려고 할 수 있습니다.
docker context ls
일반적인 Docker Desktop 환경이라면 현재 context가 desktop-linux 또는 기본 Docker context로 잡혀 있어야 합니다. 필요하면 아래처럼 변경합니다.
docker context use desktop-linux
환경에 따라 context 이름은 다를 수 있으므로, 먼저 docker context ls 결과에서 별표가 붙은 항목을 확인합니다.
Docker context가 다른 대상으로 연결되어 있으면 Dev Container가 정상 동작하지 않을 수 있습니다.
OS별 해결 체크리스트
Windows
- Docker Desktop이 실행 중인지 확인합니다.
- WSL 2 기반 엔진 사용 여부를 확인합니다.
- 사용 중인 WSL 배포판의 Docker Desktop 통합을 켭니다.
- PowerShell과 WSL 터미널에서 각각
docker ps를 실행해 차이를 확인합니다.
Mac
- Docker Desktop을 실행한 뒤 상태가 Running인지 확인합니다.
- Apple Silicon Mac에서는 이미지 아키텍처 문제와 daemon 연결 문제를 구분합니다.
- VSCode를 완전히 종료한 뒤 다시 열어 Docker 경로를 다시 인식시킵니다.
Linux
systemctl status docker로 Docker 서비스 상태를 확인합니다.- 서비스가 꺼져 있으면
sudo systemctl start docker로 시작합니다. - 현재 사용자가 docker 그룹에 포함되어 있는지 확인합니다.
Dev Container를 다시 여는 순서
docker ps
docker context ls
Docker 명령이 정상 동작하는 것을 확인한 뒤 VSCode에서 아래 순서로 다시 실행합니다.
- Command Palette를 엽니다.
- Dev Containers: Rebuild and Reopen in Container를 실행합니다.
- 계속 실패하면 Dev Containers: Show Container Log를 열어 실제 실패 지점을 확인합니다.
Dev Container 메뉴 자체가 보이지 않는다면 확장 설치나 프로젝트의 .devcontainer 구성을 먼저 확인해야 합니다. 이 경우 VSCode Dev Container에서 Reopen in Container가 안 뜰 때 확인할 항목을 함께 보면 원인을 나누기 쉽습니다.
재발 방지 설정
- Windows에서는 Docker Desktop을 시작 프로그램에 등록합니다.
- WSL을 사용하는 경우 Docker Desktop의 WSL Integration을 사용하는 배포판에만 켭니다.
- Linux에서는 Docker 서비스 자동 시작을 설정합니다.
- 프로젝트별로 Docker context를 바꿨다면 작업 후 기본 context로 되돌립니다.
sudo systemctl enable docker
sudo systemctl start docker
공식 자료로 더 확인하기
자주 묻는 질문
함께 보면 좋은 글
Dev Container Docker daemon 오류는 설정 파일을 고치기 전에 Docker가 현재 터미널에서 정상 연결되는지부터 확인하는 것이 가장 빠릅니다.
댓글