Stop Running Docker Desktop: Offload Your Builds to a VPS Instead

활성 상태 보기 또는 작업 관리자를 열고 작은 컨테이너를 시작해도, Docker Desktop은 여전히 머신에서 가장 시끄러운 존재가 될 수 있습니다. 2026년 2월의 Docker Desktop 이슈에서 한 사용자가 com.docker.backend.exe 컨테이너 시작 후 CPU가 100%까지 올라갔고 컨테이너를 멈춘 뒤에도 계속되었다고 보고했습니다.

다른 한 수가 있습니다. 데몬을 노트북에서 완전히 떼어 내는 것입니다. 로컬에는 Docker CLI만 두고, Docker Engine을 Linux VPS에서 돌리고, docker context 을 SSH로 그곳에 가리킵니다. 당신의 docker build 명령은 바뀌지 않습니다. 빌드는 그저 다른 곳에서, VM 계층이 없는 네이티브 Linux 위에서 실행되며, VPS의 대역폭이 당신의 카페 Wi-Fi 대신 베이스 이미지를 당기고, 추적할 Docker Desktop 라이선스도 없습니다.

이것이 그 경로의 완전한 설정입니다. 전제 조건, 정확한 docker context 명령, 원격 buildx 드라이버를 이용한 멀티 아키텍처 빌드, 머신 크기를 정하는 법, 그리고 원격 방식이 잘못된 선택인 지점입니다.

요약

• 문제: Docker Desktop은 로컬 VM을 끌고 다니고, 파일 I/O를 가상화 계층으로 밀어 넣으며, 유료 구독을 요구합니다 더 큰 조직에서의 업무용 사용에 대해, Docker의 무료 등급 한도를 넘는 회사들을 포함해서요.
• 해결: Docker Desktop을 제거하세요. Docker Engine을 Linux VPS에서 돌리고, SSH로 그것을 가리키는 docker context 를 만들면, 당신의 로컬 docker build 은 VPS에서 실행되고 당신의 CLI는 그저 지휘만 합니다.
• 비용 관점: 검소한 VPS 한 대가 좌석당 라이선스를 대체하고 네이티브 Linux 빌드 속도를 줍니다. 팀 전체가 개발자마다 지불하는 대신 단일 빌드 박스를 공유할 수 있습니다.
• 솔직한 유의점: VPS는 도달 가능해야 하고(비행기 안에서는 빌드 불가), 실행마다 수 기가바이트 빌드 컨텍스트를 업로드하지 않도록 .dockerignore 에 대한 규율이 필요합니다.

전제 조건: 필요한 것

첫 명령 전에 이것들을 갖춰 두세요. 이미 Docker를 매일 쓰고 있다면 여기 이색적인 것은 없습니다.

• A Linux VPS root 또는 sudo 접근 권한이 있는. Ubuntu 22.04/24.04 또는 Debian 12/13 모두 잘 작동합니다.
• VPS의 Docker Engine. docker context 은 SSH로 원격 호스트에 Docker Engine 18.09 이상을 필요로 합니다, Docker의 context 문서에 따라..
• 로컬에 Docker CLI 19.03 이상. 그것이 최상위 context 명령을 이해하는 클라이언트입니다.
• An SSH 키 쌍. 키 기반 인증만: 비밀번호 인증은 지원되지 않습니다 에 대해, docker context SSH 연결.
• 원격 docker 그룹의 원격 사용자 docker 그룹. 그래야 호출마다 sudo 없이 데몬 소켓과 대화할 수 있습니다.

Docker Desktop이 실제로 당신에게 치르게 하는 것

비용은 수수께끼가 아닙니다. 세 곳에 내려앉으며, 검색해 여기까지 온 사람은 그중 적어도 하나를 느꼈습니다. 그것들을 정확히 명명하는 것이 요점입니다. 고통은 이미 알고 있습니다.

메모리와 VM 오버헤드. Docker Desktop은 여전히 로컬 Linux VM을 뜻합니다. Docker의 설정 문서 는 Docker Desktop이 Docker Desktop VM이 쓰는 메모리 양을 제한할 수 있다고 말하는데, 이것이 문제의 조용한 부분입니다. 루프 안에는 여전히 VM이 있습니다. 정확한 발자국은 OS와 프로젝트에 따라 다르지만, 실패 모드는 실재합니다. Docker for Windows 이슈 는 컨테이너가 하나도 안 도는 상태에서 Docker Desktop이 수 기가바이트의 RAM을 소비한다고 보고하고, WSL2 이슈 는 컨테이너 종료 후에도 메모리를 해제하지 않은 채 두는 Docker 빌드를 기술합니다. 요점은 모든 머신이 같은 숫자에서 유휴 상태로 있다는 게 아닙니다. 요점은 Docker Desktop이 로컬 VM 오버헤드를 당신의 개발 루프 안에 두고 있다는 것입니다.

빌드 및 파일 I/O 속도. VM 경계를 넘는 바인드 마운트와 파일 작업은 네이티브 Linux 파일 시스템 접근보다 느립니다. Docker의 알려진 문제 문서 는 가상화 파일 시스템 비용을 인정합니다. 커뮤니티 벤치마크는 VM 계층을 통한 바인드 마운트에 대해 대략 3-10x 느린 정도를 일상적으로 보고합니다. 그 두 번째 숫자는 커뮤니티 경험이지 Docker가 발표한 벤치마크는 아니지만, 방향은 Mac에서 빌드가 기어가는 것을 본 누구도 반박하지 않습니다.

라이선싱. 2021년 변경 이후 Docker Desktop은 직원 250명 초과 또는 매출 1,000만 달러 초과 회사에 유료 구독을 요구합니다. Docker의 가격 페이지 의 현재 등급은 Personal($0), Pro($11/mo 또는 연 $9), Team($16/mo 또는 연 $15), Business($24/mo)입니다. Team 등급은 2024년 12월에 연 $9에서 $15로 올랐는데, 조용한 항목을 구매 부서와의 대화로 바꾸는 도약이며, 서른 좌석에 곱할 때 정말로 쓰라린 부분이 바로 이것입니다.

대안들, 그리고 로컬 대 원격의 갈림길

당신이 찾을 거의 모든 Docker Desktop 대안은 하나의 로컬 데몬을 다른 로컬 데몬으로 바꿉니다. 그것이 알아채야 할 진짜 축입니다. 대부분의 사람이 고민하는 선택은 로컬 도구들 사이에 있지만, 더 흥미로운 갈림길은 로컬 대 원격입니다. VM을 당신의 머신에서 없애는 것은 원격 경로뿐입니다.

여기 그 지형을 나란히 놓았습니다.

이 중 몇 가지는 한 문장의 정직함을 받을 만합니다.

• OrbStack 은 단독 개발자에게 Mac 리소스 문제를 정말로 해결합니다. 유휴 시 ~300 MB와 최대 10x 빠른 컨테이너 시작을 주장하지만(OrbStack 사이트), 둘 다 벤더 숫자이지 독립적인 벤치마크는 아닙니다. 원격 인프라를 관리하고 싶지 않은 Mac 전용 개발자라면 OrbStack이 더 나은 선택이고, 그 상업용 등급 $8/mo(OrbStack 가격)는 Docker Desktop의 Team 등급 아래로 내려갑니다. 함정: Mac 전용이고, 상업용 라이선스가 당신이 벗어나려던 바로 그것을 되돌려 놓습니다.
• Colima 은 무료이고 CLI 우선이지만, 그 "직접 대체 아님"의 거친 모서리들은 잘 기록되어 있고, 일부 팀은 마이그레이션이 막힌 뒤 Docker Desktop으로 돌아갑니다.
• Podman Desktop 와 Rancher Desktop 둘 다 무료이고 크로스 플랫폼입니다. 어느 쪽도 조용한 대체는 아니며, Podman의 Compose 호환성은 그 Docker 호환 소켓을 통합니다.
• Docker Offload 은 Docker 자신의 관리형 원격 빌드/실행 서비스지만, Docker Desktop에서의 깔끔한 출구는 아닙니다. 현재 Docker 문서는 그것을 Docker Desktop 4.68 이상, Docker Business 구독, 그리고 Docker Offload 구독을 필요로 하는 것으로 나열합니다. 워크로드를 Docker 관리 클라우드 호스트에서 실행하지만, 각 사용자는 한 번에 하나의 Offload 세션을 받고, 유휴 세션은 5분의 유예 후 종료되며, 환경은 임시적이어서 세션이 끝나면 컨테이너, 이미지, 볼륨이 사라집니다. Docker Desktop 안에서 관리형 원격 용량을 원한다면 그것으로 괜찮습니다. 당신 자신의 캐시, 디스크, root 접근을 갖고 Desktop 의존성이 없는 영속적인 VPS 빌더와 같지는 않습니다.

제자리에 머무는 것이 여전히 합리적인 경우가 하나 있습니다. 무료 임계값 아래이고 빌드 속도의 고통이 없는 개인은 아무것도 바꿀 이유가 없습니다. 나머지 모두에게는 내려야 할 갈림길이 있습니다.

이 섹션의 핵심: 중요한 결정은 어느 로컬 도구를 고르느냐가 아닙니다. 애초에 노트북에 데몬을 두느냐입니다.

docker context가 SSH로 어떻게 작동하는가

원격 서버에서 SSH로 Docker 이미지를 빌드하려면, 그 서버에서 Docker Engine을 돌리고, docker context create name --docker "host=ssh://user@host"으로 그것을 가리키는 docker context를 만든 뒤, docker context use name을 실행합니다. 그 후 당신의 평범한 docker build 은 원격 호스트에서 실행되고, 로컬 CLI는 지시만 보내고 데몬이 일을 합니다.

컨텍스트는 Docker CLI를 위한 이름 붙은 전환 가능한 대상입니다. 매번 환경 변수 DOCKER_HOST 를 저글링하거나 손으로 SSH 터널을 세우는 대신, 원격을 한 번 정의하고 디렉터리를 바꾸듯 그리로 전환합니다. 빌드는 전적으로 원격 호스트에서 실행됩니다. 베이스 이미지 풀은 VPS의 업링크를 쓰고, 레이어는 VPS의 디스크에 캐시되며, CPU 작업은 VPS의 코어에서 일어납니다. 지연에 민감한 유일한 단계는 초기 SSH 핸드셰이크와 당신의 빌드 컨텍스트 업로드입니다. 그 이후는 모두 원격입니다.

당신의 VPS 빌드 박스 설정하기

전체 설정은 짧은 명령 네 개에 SSH 설정 블록입니다. 각 단계가 안착했는지 확인하는 데 도움이 되는 곳에서 예상 출력을 보여 드리겠습니다.

1단계: Docker Engine을 Linux VPS에 올리세요. 머신을 프로비저닝하고 Docker Engine을 설치하세요(원격에서 18.09+가 context SSH의 하한, 로컬 CLI는 19.03+ 필요). 설치를 직접 돌리고 싶지 않다면 그것을 이미 담고 있는 VPS를 배포하세요(아래에서 더). 원격 사용자는 docker 그룹에 있어야 합니다:

sudo usermod -aG docker $USER

# log out and back in for the group change to take effect

2단계: SSH 키 인증과 설정 별칭을 세우세요. 키 기반 인증은 필수입니다. IP와 키 경로를 다시 입력하지 않도록 호스트에 ~/.ssh/config 안에서 짧은 별칭을 주세요:

# ~/.ssh/config
Host my-vps
  HostName 1.2.3.4
  User ubuntu
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

3단계: 컨텍스트를 만드세요. 그것을 SSH로 원격 데몬에 가리키세요. 펼친 형식을 쓰세요:

docker context create my-vps --docker "host=ssh://[email protected]"

또는 2단계의 SSH 설정 별칭을 써서:

docker context create my-vps --docker "host=ssh://my-vps"

4단계: 검증하세요. 당신의 컨텍스트들을 나열하고 원격 엔진이 응답하는지 확인하세요:

docker context ls

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock
my-vps                                                ssh://my-vps

docker --context=my-vps version

그것이 원격 데몬의 서버 버전을 출력하면, 당신의 CLI는 VPS와 대화하고 있는 것입니다.

5단계: 전환하고 빌드하세요. VPS를 활성 대상으로 만든 뒤 평소처럼 빌드하세요:

docker context use my-vps

docker build -t myapp .

그 빌드는 VPS에서 실행됩니다. 전역으로 전환하고 싶지 않나요? 단일 명령을 겨냥하세요:

docker --context=my-vps build -t myapp .

또는 셸 세션용으로 설정하세요:

export DOCKER_CONTEXT=my-vps

노트북의 로컬 데몬을 되찾고 싶을 때(하나 남겨 뒀다면) 집으로 전환하세요:

docker context use default

프로 팁: 당신의 .dockerignore에 유의하세요. 빌드 컨텍스트는 빌드가 시작되기 전에 원격 호스트로 업로드됩니다. 길 잃은 node_modules or .git 디렉터리는 실행마다 기가바이트를 회선으로 보낸다는 뜻이고, 원격 경로는 아무 좋은 이유 없이 로컬보다 느리게 느껴집니다. 빡빡한 .dockerignore 이야말로 원격 경로가 빠르게 느껴지는지에 가장 큰 영향을 주는 한 가지입니다. 의존성, 빌드 산출물, VCS 메타데이터를 제외하면 업로드는 반올림 오차가 됩니다.

원격 buildx 드라이버를 이용한 멀티 아키텍처 빌드

원격 Docker 호스트에서 컨테이너 안에 BuildKit을 돌리는 buildx 빌더를 만든 뒤, 그것에 대해 빌드하세요:

docker buildx create --name remote-builder \
  --driver docker-container \
  --use \
  ssh://ubuntu@your-vps-ip

docker buildx inspect --bootstrap

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64 \
  -t myapp:latest \
  --load .

원격 --load 플래그는 단일 플랫폼 로컬 소비에 중요합니다. docker-container 드라이버에서는, 빌드된 이미지가 당신의 로컬 이미지 목록에 자동으로 나타나지 않습니다. 진짜 멀티 플랫폼 이미지를 빌드한다면, 대신 레지스트리로 푸시하세요:

docker buildx build \
  --builder remote-builder \
  --platform linux/amd64,linux/arm64 \
  -t registry.example.com/myapp:latest \
  --push .

그 구분은 중요합니다. 단일 플랫폼 원격 빌드는 당신의 로컬 이미지 저장소로 다시 로드할 수 있습니다. 멀티 플랫폼 이미지는 보통 레지스트리로 푸시됩니다. 각 대상 아키텍처를 위한 별도 변형이 있는 매니페스트 목록이기 때문입니다. 이 섹션은 선택 사항입니다. 모든 이미지가 단일 아키텍처라면, 위의 컨텍스트 설정이 작업의 전부입니다.

빌드 박스 크기 정하기와 보안

두 질문이 이 박스가 당신을 잘 섬기는지를 결정합니다. 얼마나 크게 만들지, 그리고 데몬을 어떻게 잠가 둘지입니다. Docker 빌드는 CPU 바운드이므로, 크기 정하기 논리는 대부분 코어와 스왑을 피할 만큼의 RAM에 관한 것입니다. 보안 논리는 대부분 데몬을 당신 외 누구에게도 노출하지 않는 것에 관한 것입니다.

어느 크기로 설정할지

일반적인 사양을 주세요. 당신의 제공자가 제공하는 무엇이든 그것들을 매핑할 수 있습니다.

• 하한(개발자 1명, 가벼운 빌드): 2 vCPU / 4 GB RAM / ~120 GB NVMe. This is the minimum that works, not what I'd reach for.
• 제가 실제로 배포할 것(대부분의 팀 대상): 4 vCPU / 8-12 GB RAM / 240-300 GB NVMe. Four vCPUs stop your parallel build steps from serializing, 8-12 GB handles concurrent builds without touching swap, and the NVMe headroom keeps a healthy layer cache.
• 팀 또는 무거운 CI: 8 vCPU / 16-24 GB RAM for several developers sharing one box or big multi-stage Dockerfiles.

빌드는 CPU 바운드이므로, 고주파(CPU 최적화) 코어는 스왑 임계값 너머의 추가 RAM보다 더 빠른 반복을 당신에게 사 줍니다. 이미지 빌드는 GPU를 건드리지 않으므로 GPU 플랜은 여기서 무관합니다. 그리고 데이터센터 선택은 SSH 응답성과 컨텍스트 업로드 시간에만 영향을 주지 빌드 속도에는 영향을 주지 않습니다. 빌드는 당신이 어디에 앉아 있든 VPS에서 실행되니, 날렵한 핸드셰이크를 위해 당신에게 가까운 위치를 고르고 넘어가세요.

원격 데몬 보안

위 설정은 이미 올바른 기본값을 강제합니다. SSH 키 인증, 네트워크에 노출된 데몬 포트 없음. 그렇게 유지하세요. BuildKit이나 데몬을 SSH 너머로(생 TCP 엔드포인트, 열린 BuildKit 포트로) 노출하는 순간, 당신은 표적이 됩니다. Hacker News 스레드 는 원격 VPS 아이디어를 처음 꺼낸 느린 빌드에 관한 것으로, 노출된 BuildKit 엔드포인트에 대한 크립토마이닝 공격도 경고했습니다. 열린 인터넷의 인증되지 않은 빌드 데몬은 공짜 연산 뷔페입니다.

프로 팁: 데몬을 노출하지 마세요. SSH만으로 충분하다면(대부분의 단일 박스 설정에는 충분합니다), 데몬 TCP 포트를 절대 열지 마세요 . 정말로 TCP 접근이 필요하다면, 유효한 인증서를 가진 클라이언트만 연결할 수 있도록 그 앞에 상호 TLS(mTLS)를 두세요. SSH만 또는 mTLS: 인터넷에서 도달 가능한 빌드 박스에 받아들일 수 있는 세 번째 선택지는 없습니다.

박스가 일단 서면, 그것은 범용 Linux 서버이고, 그 위에서 돌릴 가치가 있는 것이 훨씬 많습니다. 저희의 인디 해커를 위한 셀프 호스팅 스택 가이드 는 당신의 VPS에 또 무엇이 자리를 얻을 만한지에 대한 합리적인 다음 읽을거리입니다.

Docker Engine 설치를 건너뛰고 곧장 docker context create로 가고 싶다면, 저희의 Docker 마켓플레이스 앱 이 Docker Engine, Compose V2, buildx가 이미 구성된 VPS를 배포합니다. 원클릭이면 박스가 SSH 준비 상태가 되니, 위 안내는 1단계 대신 2단계에서 시작합니다.

자주 묻는 질문

원격 서버에서 Docker 빌드를 실행하고 로컬 CLI를 쓸 수 있나요?

예. 원격 호스트에서 Docker Engine을 돌리고, SSH로 그것을 가리키는 docker context 를 만든 뒤 그 컨텍스트로 전환하세요. 그러면 당신의 로컬 docker build 은 원격 서버에서 실행되고, 당신의 머신의 CLI는 지휘만 하며 로컬 데몬은 필요 없습니다.

docker context와 DOCKER_HOST의 차이는 무엇인가요?

A docker context 는 한 번 정의하고 다음으로 선택하는, 이름 붙은 전환 가능한 영속적 대상입니다: docker context use. DOCKER_HOST 은 셸마다 손으로 설정하고 해제하는 단일 환경 변수입니다. 컨텍스트는 오래된 "터널 더하기 환경 변수" 방식의 현대적 대체입니다.

docker compose는 원격 컨텍스트로 작동하나요?

예. Compose V2는 활성 Docker 컨텍스트를 존중하므로, docker compose 명령은 컨텍스트가 가리키는 호스트에 대해 실행됩니다. 서비스와 어떤 이미지 빌드든 원격 호스트에서 실행되며, 이는 평범한 docker build.

Docker Offload란 무엇이고 무료인가요?

Docker Offload는 Docker Desktop 워크플로를 유지하면서 컨테이너 작업을 Docker 관리 클라우드 호스트로 옮기는, Docker 자신의 관리형 원격 빌드/실행 서비스입니다. 현재 Docker 문서는 그것을 Docker Desktop 4.68 이상을 요구하는것으로 나열하고, 더해 Docker Business 및 Docker Offload 구독을 나열합니다. 그것은 세션 기반이기도 합니다. 각 사용자가 받는 것은 한 번에 하나의 Offload 세션이고, 유휴 세션은 5분의 유예 후 종료되며, 원격 환경은 임시적입니다.

Docker Desktop이 그렇게 많은 메모리를 쓰는 것을 어떻게 막나요?

Docker Desktop의 리소스 한도를 조정해도 결코 0으로 내려가지 않는 발자국을 줄일 뿐입니다. VM에는 항상 바닥이 있기 때문입니다. 메모리 비용을 정말로 없애는 경로는 로컬 데몬을 완전히 없애는 것입니다. Docker Engine을 VPS에서 돌리고 docker context 를 통해 SSH로 연결하면, 당신의 머신에서는 CLI 외에 아무것도 돌지 않습니다.

이걸 대신 Podman으로 할 수 있나요?

할 수 있습니다. Podman은 Docker 호환 엔진으로 제공되고, docker context 는 원격 Podman 호스트를 가리킬 수 있지만, 그러려면 Podman이 그 Docker 호환 소켓을 SSH로 노출해야 합니다. 명령 흐름은 같습니다. 원격 쪽의 설정은 다릅니다.