개발 환경에서 GitHub만 빨라진다고 작업 전체가 원활해지는 것은 아닙니다. 저장소를 복제하거나 릴리스를 내려받는 과정은 정상이어도 Docker Hub에서 이미지를 가져오는 단계가 느리고, npm 패키지 설치가 자주 멈추면 실제 개발 흐름은 계속 끊깁니다. Git, Docker, npm은 서로 다른 프로그램처럼 보이지만 모두 DNS 조회, HTTPS 연결, 인증 요청, 대용량 파일 전송이라는 네트워크 과정을 사용합니다. 따라서 브라우저만 VPN에 연결하는 방식으로는 터미널과 백그라운드 서비스의 속도 문제가 해결되지 않을 수 있습니다.
이 글에서는 개인 PC에서 GitHub·Docker·npm을 사용할 때 어떤 VPN 모드와 프록시 설정을 선택해야 하는지 단계별로 정리합니다. 시스템 전체 VPN, 규칙 기반 분할 라우팅, 터미널 환경 변수, Docker 데몬 프록시, npm의 자체 프록시 설정을 비교하고, 개인 개발 환경·팀 작업·CI 서버에 맞는 운영 방법도 함께 살펴봅니다. 핵심은 무조건 전체 트래픽을 우회하는 것이 아니라, 실제로 느린 요청이 어느 프로세스에서 발생하는지 확인한 뒤 필요한 범위에만 일관된 경로를 적용하는 것입니다.
90+
국가 커버리지
200+
회선 수
5
지원 플랫폼
무제한
동시 온라인 기기
개인 PC에서는 규칙 기반 분할 라우팅과 터미널 프록시를 함께 사용하고, Docker는 데몬이 실제로 참조하는 프록시를 별도로 설정하는 구성이 가장 관리하기 쉽습니다. 팀과 CI 환경에서는 개발자 개인의 VPN 설정을 공유하기보다 재현 가능한 프록시 환경 변수와 사내 캐시 정책을 분리해 관리해야 합니다.
GitHub·Docker·npm 요청이 서로 다른 이유
GitHub는 저장소와 파일 요청이 분리됩니다
GitHub 작업은 하나의 연결만 사용하는 것이 아닙니다. HTTPS 방식으로 저장소를 복제할 때는 GitHub의 웹 엔드포인트와 Git 서비스에 연결하고, 릴리스 파일이나 대용량 아카이브는 별도의 저장소 도메인으로 이동할 수 있습니다. SSH 방식으로 Git 작업을 한다면 HTTPS 프록시 설정만으로는 충분하지 않습니다. SSH는 자체 연결을 사용하므로 시스템 VPN, SOCKS5를 지원하는 프록시 도구, 또는 SSH 전용 프록시 명령 설정을 검토해야 합니다.
또한 GitHub의 웹 페이지가 빠르게 열리는 것과 git clone이 빠르게 끝나는 것은 같은 결과가 아닙니다. 웹 브라우저는 VPN의 규칙을 적용받지만, 터미널의 Git 프로세스는 직접 연결로 남아 있을 수 있습니다. 반대로 Git은 프록시를 사용하지만 Git LFS나 릴리스 다운로드가 다른 경로를 사용하면 일부 파일만 계속 느릴 수 있습니다. 문제를 확인할 때는 웹 접속, 저장소 복제, 릴리스 파일 다운로드를 별개의 테스트로 나누는 편이 정확합니다.
Docker는 클라이언트와 데몬을 구분해야 합니다
Docker에서 가장 자주 발생하는 오해는 터미널에 프록시 환경 변수를 설정하면 이미지 다운로드도 자동으로 프록시를 사용한다고 생각하는 것입니다. docker 명령은 Docker CLI이고, 실제로 Docker Hub 또는 사설 레지스트리에 요청하는 주체는 Docker 데몬인 경우가 많습니다. Linux의 Docker Engine은 별도 서비스로 실행되며, Docker Desktop은 자체 가상화 환경과 네트워크 계층을 사용할 수 있습니다. 그러므로 CLI의 연결 상태와 데몬의 연결 상태는 따로 점검해야 합니다.
이미지의 기본 레이어가 내려받아지는 동안에는 레지스트리 인증 엔드포인트, 이미지 매니페스트, 여러 레이어 저장소가 연속해서 사용됩니다. 로그인 화면은 열리는데 docker pull이 멈춘다면 인증 요청은 통과했지만 실제 레이어 요청이 다른 경로를 사용하거나, 데몬에 프록시가 적용되지 않았을 가능성이 있습니다. Docker Desktop에서는 애플리케이션의 네트워크 설정을 확인하고, Linux 서비스에서는 systemd 환경 설정을 변경한 뒤 데몬을 다시 시작해야 합니다.
npm은 레지스트리와 패키지 의존성을 함께 확인합니다
npm 설치는 지정한 레지스트리에서 패키지 메타데이터를 받고, 의존성에 포함된 여러 패키지의 압축 파일을 순서대로 요청하는 작업입니다. npm install이 시작되지 않는다면 DNS 또는 레지스트리 연결 문제일 수 있고, 진행률이 특정 단계에서 오래 멈춘다면 패키지 tarball 요청이나 인증·캐시 문제가 원인일 수 있습니다. 프로젝트에 package-lock.json이 있으면 잠긴 의존성 주소가 현재 레지스트리 정책과 맞는지도 확인해야 합니다.
npm은 자체적으로 proxy, https-proxy, registry 같은 설정을 가질 수 있습니다. 이 설정이 운영체제의 VPN이나 터미널 환경 변수와 서로 다르면 브라우저, Git, npm이 각기 다른 출구를 사용하게 됩니다. 특히 예전에 사용하던 프록시 주소가 npm 전역 설정에 남아 있으면 VPN을 바꿔도 설치가 계속 실패할 수 있으므로 npm config list로 현재 값을 먼저 확인하는 것이 좋습니다.
개발자 VPN 모드와 프로토콜 선택
개발 PC에서는 먼저 VPN 클라이언트가 제공하는 시스템 모드를 이해해야 합니다. 전체 모드는 운영체제의 폭넓은 트래픽을 가상 인터페이스 또는 시스템 프록시를 통해 처리하므로 Git, Docker Desktop, npm처럼 서로 다른 프로세스를 한 번에 적용하기 쉽습니다. 반면 분할 라우팅은 국내 서비스와 사내 주소는 직접 연결하고, 필요한 해외 개발 서비스만 선택한 경로로 보낼 수 있습니다. 전체 모드가 항상 빠른 것은 아니며, 분할 규칙이 잘못되면 오히려 DNS와 인증 요청이 서로 다른 경로로 나뉘어 오류가 생길 수 있습니다.
호환 클라이언트에서는 Shadowsocks, VMess, Trojan, Hysteria2, WireGuard와 같은 프로토콜 또는 터널 방식을 볼 수 있습니다. Shadowsocks, VMess, Trojan은 일반적으로 프록시 프로토콜 체계로 사용되며, WireGuard는 VPN 터널 프로토콜입니다. Hysteria2는 QUIC 기반 전송을 활용하는 방식으로 제공될 수 있습니다. 이름만 보고 특정 프로토콜이 GitHub나 Docker에 반드시 더 빠르다고 단정할 수는 없습니다. 실제 결과는 사용자 네트워크, 노드 위치, 국제 구간, DNS 처리, 클라이언트 구현과 목적지 서버의 응답 상태에 따라 달라집니다.
Windows와 macOS 공식 클라이언트는 우선 시스템 모드와 분할 모드를 각각 시험하는 것이 좋습니다. Android와 iOS에서는 VPN 프로파일 권한과 백그라운드 동작 제한을 확인해야 하며, Linux에서는 공식 클라이언트 외에도 Clash Verge나 sing-box 같은 호환 클라이언트에서 구독 링크를 가져와 규칙을 구성할 수 있습니다. Shadowrocket은 iOS에서 프록시 규칙을 세밀하게 조정할 때 사용할 수 있지만, 모든 앱의 네트워크 동작을 동일하게 보장하는 것은 아니므로 Docker와 터미널은 별도 검증이 필요합니다.
- ✅ 처음에는 하나의 VPN 클라이언트만 실행하고, 다른 가상 네트워크 도구는 종료합니다.
- ✅ GitHub HTTPS, Docker 레지스트리, npm 레지스트리가 모두 필요한 경로를 통과하는지 프로세스별로 확인합니다.
- ✅ 분할 라우팅을 사용할 때는 사내 도메인과 로컬 개발 서버를 직접 연결 목록에 남깁니다.
- ✅ SSH Git을 사용하는 경우 HTTPS 프록시와 SSH 연결 설정을 별도로 점검합니다.
- ❌ 노드 이름이나 프로토콜 이름만 보고 다운로드 속도를 단정하지 않습니다.
- ❌ VPN, Clash Verge, 시스템 프록시, 다른 가속기를 동시에 켜서 라우팅 충돌을 만들지 않습니다.
개인 PC에서 직접 설정하는 순서
설정은 한 번에 모든 값을 바꾸기보다 기준선을 만든 뒤 한 계층씩 적용해야 합니다. 먼저 현재 VPN과 시스템 프록시를 끄고 일반 웹 접속, GitHub 웹 페이지, npm 레지스트리의 응답 여부를 확인합니다. 이 단계에서 이미 특정 서비스만 실패한다면 VPN보다 로컬 DNS, 방화벽, 회사 네트워크 정책을 먼저 의심해야 합니다.
- 클라이언트 연결. 공식 Windows/macOS/Linux 클라이언트 또는 호환 클라이언트에 구독 링크를 가져옵니다. 처음에는 목적지와 가까운 지역의 일반 노드를 선택하고, 시스템 모드 또는 규칙 모드 중 하나만 활성화합니다.
- Git HTTPS 확인. 기존 저장소에서 원격 주소를 확인한 뒤 작은 변경 사항을 조회합니다. 프록시를 명시적으로 사용해야 한다면 Git의 전역 설정을 적용하기 전에 현재 설정을 확인합니다. 팀 PC에서는 개인 토큰이나 비밀번호가 명령 기록에 남지 않도록 주의합니다.
- 터미널 환경 변수 적용. 셸에서 사용하는
HTTP_PROXY,HTTPS_PROXY,ALL_PROXY값은 사용 중인 클라이언트가 제공하는 로컬 프록시 포트에 맞춰야 합니다. 포트와 프로토콜이 실제 클라이언트 화면과 다르면 연결이 되지 않습니다. 작업이 끝난 뒤에는 현재 셸에 남은 값을 확인하고 필요하면 해제합니다. - npm 설정 점검.
npm config get registry와 프록시 관련 값을 확인합니다. 환경 변수와 npm 설정이 서로 다른 프록시를 가리키지 않도록 하나의 기준을 정하고, 오래된 전역 설정은 정리합니다. 사내 레지스트리를 사용하는 프로젝트라면 공용 레지스트리로 임의 변경하지 말고 프로젝트 정책을 우선합니다. - Docker 연결 확인. CLI가 아니라 Docker 데몬 또는 Docker Desktop의 네트워크 설정을 확인합니다. Linux 서비스 프록시를 수정했다면 데몬을 재시작한 다음 이미지 매니페스트와 레이어 다운로드가 모두 진행되는지 확인합니다. Docker Desktop은 호스트 셸의 프록시와 내부 엔진 설정이 다를 수 있습니다.
- 분할 라우팅 검증. GitHub, Docker Hub, npm 요청이 정상화된 뒤 국내 사이트, 사내 Git 서버, 로컬 개발 서버가 예상대로 직접 연결되는지 확인합니다. 해외 서비스는 빨라졌지만 사내 주소가 열리지 않는다면 전체 모드가 아니라 규칙을 수정해야 합니다.
터미널에서 프록시를 임시로 적용하는 방식은 개인 PC에서 원인을 분리할 때 유용합니다. 예를 들어 셸 세션에만 환경 변수를 넣으면 운영체제 전체 설정을 바꾸지 않고 Git이나 npm의 동작을 비교할 수 있습니다. 다만 명령에 프록시 주소와 인증 정보를 직접 적으면 셸 기록, 프로세스 목록, CI 로그에 노출될 수 있습니다. 인증이 필요한 프록시는 비밀 변수나 운영체제의 안전한 자격 증명 저장소를 사용하고, 공유 문서에는 실제 토큰을 기록하지 마세요.
VPN 클라이언트 연결 → 터미널 프록시 → Git·npm 설정 → Docker 데몬 설정 순서로 적용하면 어느 계층에서 문제가 생겼는지 추적하기 쉽습니다. 네 가지 설정을 동시에 변경하면 속도 개선 여부와 실패 원인을 구분하기 어렵습니다.
팀 작업과 CI 서버에서의 운영 원칙
개인 PC의 VPN 설정을 팀 구성원에게 그대로 복사하는 방식은 장기적으로 적합하지 않습니다. 운영체제, 셸, Docker 실행 방식, 인증 저장소가 서로 다르고, 특정 지역 노드나 개인 계정에 의존하면 재현성이 떨어집니다. 팀에서는 먼저 어떤 목적지에 어떤 경로가 필요한지 문서화하고, 개발자용 설정과 빌드 서버용 설정을 분리하는 것이 안전합니다.
GitHub Actions나 자체 CI 서버에서는 작업 실행 환경에 프록시 환경 변수를 주입할 수 있지만, 모든 빌드 단계가 같은 프록시를 사용한다고 가정해서는 안 됩니다. Docker-in-Docker, 원격 Docker 데몬, Kubernetes 빌드 러너를 사용하면 실제 이미지 pull 주체가 다른 서버에 있을 수 있습니다. 이 경우 CI 작업 컨테이너의 HTTP_PROXY만 바꾸어서는 호스트 데몬의 이미지 다운로드가 바뀌지 않습니다. 러너 호스트, Docker 데몬, 빌드 컨테이너의 네트워크 경계를 먼저 그려야 합니다.
CI에서는 프록시 장애가 곧 배포 실패로 이어질 수 있으므로 단일 노드에 의존하지 않는 운영 계획이 필요합니다. 프록시 주소를 저장소 파일에 하드코딩하지 말고 CI의 비밀 변수나 런너 환경 설정으로 관리하세요. npm 패키지와 Docker 이미지를 반복해서 내려받는 팀이라면 내부 캐시 또는 프록시 레지스트리를 검토하는 편이 개인 VPN에 모든 부하를 맡기는 것보다 안정적입니다. 캐시는 외부 요청을 줄이는 역할을 하지만, 보안 업데이트와 이미지 서명 검증을 생략해도 된다는 뜻은 아닙니다.
| 환경 | 권장 구성 | 우선 점검할 주체 | 주의할 점 |
|---|---|---|---|
| 개인 PC | 분할 라우팅 + 셸 프록시 | VPN 클라이언트, Git, npm | 오래된 전역 프록시 설정과 포트 충돌 |
| Docker Desktop | 클라이언트와 엔진 설정을 분리 | Docker Desktop 네트워크 계층 | 호스트 터미널 설정이 엔진에 자동 적용되지 않을 수 있음 |
| 팀 개발 환경 | 문서화된 규칙과 공유 가능한 환경 변수 | 각 운영체제와 인증 방식 | 개인 노드와 개인 자격 증명에 의존하지 않기 |
| CI 서버 | 비밀 변수, 캐시 레지스트리, 장애 대비 경로 | 러너 호스트와 Docker 데몬 | 작업 컨테이너의 프록시만 바꿔서는 부족할 수 있음 |
속도가 개선되지 않을 때의 점검표
VPN에 연결했는데 GitHub, Docker, npm 모두 여전히 느리다면 먼저 회선보다 DNS와 라우팅 범위를 확인하세요. 도메인 조회가 직접 연결되고 실제 HTTPS 요청만 우회되는 구성에서는 지역에 따라 인증이나 저장소 주소가 다르게 해석될 수 있습니다. 반대로 모든 요청을 전체 모드로 보내면 로컬 레지스트리와 사내 서버까지 외부 경로를 거치면서 불필요한 지연이나 접근 오류가 생길 수 있습니다.
Git만 실패한다면 원격 주소가 SSH인지 HTTPS인지 확인하고, Git LFS를 사용하는 저장소라면 LFS 요청도 같은 경로를 사용하는지 확인합니다. Docker만 실패한다면 CLI보다 데몬 로그와 Docker Desktop의 프록시 화면을 먼저 보세요. docker login은 성공하지만 docker pull이 실패하는 경우에는 레지스트리 인증과 이미지 레이어 요청을 별도로 조사해야 합니다. npm만 실패한다면 레지스트리 주소, 인증 토큰, 전역 프록시 값, 프로젝트의 잠금 파일을 차례로 확인합니다.
속도 비교는 같은 저장소, 같은 이미지, 같은 프로젝트 조건에서 한 번에 한 요소만 바꾸어 진행해야 합니다. 네트워크를 바꾼 직후에는 기존 연결과 DNS 캐시가 남아 있을 수 있으므로 Git 프로세스, Docker 작업, npm 명령을 새로 시작합니다. 특정 노드에서만 문제가 발생하는지, 모든 노드에서 동일한지 기록하면 회선 문제와 로컬 설정 문제를 나누는 데 도움이 됩니다. 측정 결과를 공유할 때는 인증 정보와 사설 주소를 제거하고, 사용한 클라이언트 모드·프로토콜·대상 서비스만 남기는 것이 안전합니다.
- ✅ Git 원격 주소가 HTTPS인지 SSH인지 확인합니다.
- ✅ Docker CLI가 아니라 실제 Docker 데몬의 프록시 적용 여부를 확인합니다.
- ✅ npm 레지스트리와 프록시 설정이 환경 변수와 충돌하지 않는지 봅니다.
- ✅ DNS 조회, 인증, 메타데이터, 대용량 레이어 다운로드를 각각 나누어 확인합니다.
- ✅ 노드를 바꿀 때 기존 프로세스와 연결을 새로 시작합니다.
- ❌ 속도 측정 화면 하나만으로 장기적인 개발 환경의 품질을 결론내리지 않습니다.
개발자 VPN의 목표는 모든 트래픽을 무조건 먼 경로로 보내는 것이 아닙니다. GitHub의 저장소와 릴리스, Docker의 이미지 레이어, npm의 패키지 tarball처럼 실제로 막히거나 느린 요청을 식별하고, 각 요청을 처리하는 프로세스에 일관된 경로를 제공하는 것이 핵심입니다. 개인 PC에서는 분할 라우팅과 임시 셸 프록시로 빠르게 원인을 좁히고, 팀과 CI에서는 비밀 관리·캐시·데몬 경계를 문서화해야 합니다.
GitHub·Docker·npm을 함께 사용하는 개발 환경에서는 브라우저 연결보다 프로세스별 경로가 중요합니다. 먼저 Git과 npm의 터미널 프록시를 정리하고, Docker 데몬의 별도 네트워크 설정을 확인한 뒤, 필요한 목적지만 분할 라우팅에 포함하세요. 이 순서를 지키면 프로토콜이나 노드를 무작정 바꾸지 않고도 병목이 발생한 계층을 더 정확하게 찾을 수 있습니다.