개발 환경에서 VPN이 필요한 이유부터 구분하기

개발자가 VPN을 사용할 때 기대하는 것은 단순히 웹페이지를 빠르게 여는 일이 아닙니다. GitHub 저장소를 clone하거나 fetch할 때 연결이 반복해서 끊기지 않아야 하고, Docker 이미지 레이어가 중간에 멈추지 않아야 하며, npm·pip 패키지 설치가 의존성 확인 단계에서 오래 대기하지 않아야 합니다. CI에서는 짧은 네트워크 지연보다 모든 의존성과 이미지가 동일한 조건에서 재현성 있게 내려받아지는지가 더 중요합니다.

다만 VPN은 모든 개발 네트워크 문제를 자동으로 해결하지 않습니다. 로컬 DNS가 잘못 설정되어 있거나, 회사 방화벽이 특정 포트를 차단하거나, Docker 데몬이 호스트 운영체제와 별도의 네트워크를 사용하는 경우에는 클라이언트에 연결했어도 명령줄 도구가 같은 경로를 사용하지 않을 수 있습니다. 먼저 문제가 발생하는 계층을 나누어야 합니다. 브라우저만 느린지, 터미널의 Git도 느린지, 컨테이너 내부에서만 실패하는지, CI 러너에서만 재현되는지를 각각 확인하세요.

90+

지원 국가

200+

지원 회선

5

지원 플랫폼

14일

환불 보장

문제가 보이는 위치 먼저 확인할 항목 VPN 적용 범위
브라우저와 Git 모두 느림 시스템 라우팅, DNS, 회선 혼잡 전체 장치 또는 규칙 기반 라우팅
Git만 clone 실패 HTTPS·SSH 포트, Git 프록시 설정 Git 프로세스에만 프록시 적용 가능
Docker pull만 멈춤 Docker 데몬의 프록시와 레지스트리 경로 호스트 클라이언트와 별도로 설정 필요
CI에서만 의존성 설치 실패 러너의 환경 변수, 캐시, 허용된 외부 연결 러너 정책과 네트워크 구성을 함께 검토

GitHub clone과 fetch에는 Git 전용 프록시를 적용하기

GitHub 작업이 느릴 때는 저장소의 크기만 보지 말고 연결 방식부터 구분해야 합니다. HTTPS 저장소는 일반적으로 웹 프록시 설정의 영향을 받을 수 있고, SSH 저장소는 별도의 SSH 연결과 포트를 사용합니다. 브라우저가 GitHub 페이지를 잘 연다고 해서 Git 명령도 같은 경로를 이용한다는 뜻은 아닙니다. 반대로 시스템 전체 프록시를 켜면 사내 Git 서버나 로컬 개발 도구까지 외부 회선으로 보내져 예상하지 못한 문제가 생길 수 있습니다.

HTTPS를 사용하는 경우 Git의 전역 설정 또는 특정 저장소 설정에 프록시를 지정할 수 있습니다. 전역 설정은 모든 저장소에 영향을 주므로 개인 저장소와 회사 저장소의 정책이 다르다면 저장소별 설정이 더 안전합니다. 설정 후에는 공개 저장소가 아니라 실제로 작업하는 저장소에서 fetch, push, 큰 파일이 포함된 clone을 순서대로 확인하세요.

git config --global http.proxy http://127.0.0.1:PORT
git config --global https.proxy http://127.0.0.1:PORT
git config --global --get-regexp 'http.*proxy'

# 더 이상 사용하지 않을 때
git config --global --unset http.proxy
git config --global --unset https.proxy

위 예시의 PORT는 사용 중인 클라이언트가 실제로 제공하는 로컬 HTTP 프록시 포트로 바꿔야 합니다. SOCKS5 포트만 제공되는 클라이언트라면 Git 버전과 실행 환경이 해당 형식을 지원하는지 확인하고, 지원하지 않을 때는 변환 계층을 무리하게 추가하기보다 클라이언트에서 HTTP 프록시를 제공하는지 살펴보는 편이 낫습니다. 인증 정보가 포함된 프록시 주소를 명령 기록이나 공유 스크립트에 그대로 남기지 마세요.

SSH 저장소를 사용하는 팀이라면 ~/.ssh/config와 서버의 허용 포트를 별도로 확인해야 합니다. SSH 프록시 명령을 임의로 복사하면 키 인증은 성공하지만 연결이 불안정해질 수 있습니다. 가능하다면 HTTPS와 SSH 중 팀의 인증 정책에 맞는 한 가지 방식을 정하고, 문제를 재현할 때 같은 URL 형식을 유지하세요. Git LFS를 사용한다면 일반 Git 객체와 LFS 서버의 요청 경로가 다를 수 있으므로 LFS fetch도 따로 점검해야 합니다.

  • ✅ HTTPS와 SSH 저장소 URL을 섞지 않고 한 가지 방식으로 먼저 재현합니다.
  • ✅ 전역 프록시보다 저장소별 설정이 적합한지 회사 정책을 확인합니다.
  • ✅ Git LFS를 사용하는 저장소는 일반 clone과 LFS 다운로드를 따로 확인합니다.
  • ❌ 토큰이나 프록시 비밀번호를 셸 기록, Dockerfile, CI 로그에 남기지 않습니다.
한 줄 결론: GitHub가 느리다면 VPN을 켜는 것보다 먼저 Git이 실제로 어떤 프록시와 URL 형식을 사용하는지 확인해야 합니다.

Docker 이미지 다운로드는 클라이언트와 데몬을 따로 설정하기

Docker에서 자주 발생하는 오해는 호스트 운영체제의 VPN 클라이언트가 연결되면 docker pull도 자동으로 같은 프록시를 사용한다고 생각하는 것입니다. Docker 명령은 보통 Docker 데몬에 작업을 요청하고, 실제 레지스트리 연결은 데몬 또는 Docker Desktop 내부 구성 요소가 수행합니다. 따라서 브라우저와 터미널이 정상이어도 Docker Hub나 사설 레지스트리에서 이미지 레이어를 받지 못할 수 있습니다.

먼저 docker info로 현재 데몬 상태를 확인하고, 오류가 인증 실패인지 DNS 해석 실패인지 연결 시간 초과인지 구분하세요. 인증 오류라면 VPN보다 레지스트리 자격 증명과 이미지 이름을 확인해야 합니다. DNS 오류라면 호스트의 DNS와 Docker 내부 DNS가 서로 다른 결과를 반환하는지 살펴보세요. 레이어 일부만 반복해서 실패한다면 프록시의 대용량 응답 처리, MTU, 연결 재사용 설정도 점검 대상입니다.

Docker Desktop은 운영체제 네트워크와 자체 엔진 구성이 함께 작동할 수 있습니다. 애플리케이션 설정에서 프록시를 지정하는 방식과, Linux 환경에서 systemd 서비스에 데몬 프록시를 지정하는 방식은 다릅니다. 설정을 변경한 뒤에는 데몬을 재시작해야 할 수 있으며, 현재 실행 중인 컨테이너가 새 설정을 자동으로 상속한다고 가정해서는 안 됩니다. 팀 환경에서는 개인 컴퓨터에서만 통하는 로컬 주소를 Dockerfile이나 compose 파일에 고정하지 마세요.

# 현재 이미지와 데몬 상태 확인
docker version
docker info
docker pull 이미지이름:태그

# 빌드 과정에서 필요한 네트워크를 분리해 확인
docker build --progress=plain -t local-test .

컨테이너 빌드가 실패하면 이미지 pull 단계와 Dockerfile 내부의 RUN 단계도 분리해야 합니다. 베이스 이미지 다운로드는 데몬의 네트워크를 사용하지만, RUN npm install이나 RUN pip install은 빌드 컨테이너의 DNS와 프록시 환경 변수에 영향을 받습니다. 호스트에서 npm이 정상이어도 컨테이너 내부에는 HTTP_PROXY, HTTPS_PROXY, NO_PROXY가 전달되지 않을 수 있습니다. 반대로 프록시 주소를 이미지 레이어에 기록하면 토큰이나 내부 주소가 최종 이미지에 남을 위험이 있으므로 비밀 값은 BuildKit의 시크릿 기능이나 CI의 비밀 변수처럼 별도 방식으로 주입해야 합니다.

직접 설정하기: 로컬 개발 환경에서 단계별로 검증하기

설정을 한꺼번에 바꾸면 어느 단계에서 문제가 해결됐는지 알기 어렵습니다. 아래 순서는 호스트 연결, Git, 패키지 관리자, Docker 순으로 범위를 넓히는 방법입니다. 각 단계에서 성공 여부와 오류 메시지를 기록하고, 다음 단계로 넘어가기 전에 불필요한 프록시 설정을 제거하거나 유지 범위를 명확히 하세요.

  1. 기본 상태 기록: VPN을 연결하지 않은 상태에서 대상 Git 저장소의 주소 확인, 패키지 레지스트리 접근, Docker 데몬 상태를 점검합니다. 이 단계는 VPN 자체의 문제가 아니라 로컬 네트워크 문제를 구분하기 위한 기준입니다.
  2. 클라이언트 연결: Windows, macOS, Linux, Android, iOS 중 사용하는 플랫폼의 공식 클라이언트 또는 호환 클라이언트에서 구독 설정을 가져옵니다. 연결 후 IP와 DNS가 기대한 경로로 바뀌었는지 확인하고, 로컬 서비스는 계속 직결되어야 하는지도 판단합니다.
  3. Git만 적용: 먼저 HTTPS 저장소에서 fetch를 실행하고 Git 프록시 로그를 확인합니다. 회사 Git 서버나 로컬 주소가 있다면 NO_PROXY 또는 저장소별 예외를 사용해 내부 트래픽이 불필요하게 외부 회선으로 나가지 않도록 합니다.
  4. 패키지 관리자 확인: npm은 레지스트리 주소와 npm config의 프록시 값을, pip은 인덱스 주소와 환경 변수를 확인합니다. 셸에서 설정한 변수와 사용자 설정 파일의 값이 충돌하지 않는지 살펴보고, 인증 토큰은 출력 명령으로 노출하지 않습니다.
  5. Docker 분리 점검: 호스트에서 성공한 뒤 Docker 데몬의 pull을 실행하고, 그 다음 테스트 이미지의 빌드 단계에서 패키지 설치를 확인합니다. pull은 되지만 build가 실패하면 데몬과 컨테이너의 프록시 경로가 다르다는 뜻일 수 있습니다.
  6. 예외 규칙 정리: 사내 도메인, 로컬호스트, 사설 레지스트리, 데이터베이스 주소처럼 VPN을 거치면 안 되는 대상은 예외 목록에 넣습니다. 너무 넓은 예외는 문제를 숨길 수 있으므로 도메인과 네트워크 범위를 최소화하세요.

테스트 중에는 여러 클라이언트를 동시에 실행하지 않는 것이 좋습니다. Clash Verge, sing-box, Shadowrocket 같은 호환 클라이언트와 공식 클라이언트를 함께 켜면 가상 네트워크 인터페이스, 시스템 프록시, DNS 규칙이 서로 충돌할 수 있습니다. 하나의 클라이언트로 연결한 뒤 문제가 남으면 연결을 완전히 종료하고 다른 클라이언트에서 동일한 조건으로 재현하세요.

npm·pip와 CI에서는 속도보다 재현성을 우선하기

npm이나 pip 설치가 자주 멈추면 단순히 더 빠른 회선을 찾기보다 레지스트리와 캐시 구조를 먼저 확인하세요. npm은 프로젝트의 lockfile과 설정된 registry가 일치해야 하며, pip은 패키지 인덱스와 추가 인덱스의 우선순위를 명확히 해야 합니다. 여러 미러를 무작정 섞으면 같은 패키지의 메타데이터와 파일이 서로 다른 경로에서 내려와 재현성이 떨어질 수 있습니다.

개발용 노트북에서는 필요한 범위에만 프록시를 적용하는 분할 라우팅이 유용합니다. GitHub, 공개 패키지 레지스트리, 외부 이미지 레지스트리는 프록시로 보내고, 사내 Git, 사설 패키지 저장소, 로컬 데이터베이스는 직결로 유지하는 식입니다. 단, 도메인 기반 규칙은 DNS 결과와 리디렉션에 따라 달라질 수 있으므로 첫 연결 대상뿐 아니라 실제 다운로드 호스트도 확인해야 합니다.

CI 환경에서는 러너가 공유 인프라인지 자체 호스트인지에 따라 접근 방식이 크게 달라집니다. 공유 러너에 임의의 VPN 클라이언트를 설치하는 것은 권한과 보안 정책에 어긋날 수 있습니다. 이 경우에는 조직이 승인한 프록시, 패키지 캐시, 컨테이너 레지스트리 미러를 사용하는 편이 적절합니다. 자체 러너라면 운영체제 서비스, Docker 데몬, 작업 프로세스가 각각 어떤 환경 변수를 상속하는지 문서화하세요.

캐시는 속도 개선뿐 아니라 외부 네트워크 의존성을 줄이는 역할도 합니다. lockfile을 커밋하고, CI가 사용할 Node.js와 Python 버전을 고정하며, 캐시 키에 운영체제와 의존성 파일의 해시를 반영하면 잘못된 캐시를 재사용할 가능성을 낮출 수 있습니다. 캐시가 깨졌을 때 전체 작업이 조용히 멈추지 않도록 제한 시간과 명확한 오류 출력을 설정하고, 캐시가 없어도 깨끗한 환경에서 빌드가 가능한지 정기적으로 확인하세요.

  • ✅ npm과 pip의 레지스트리, lockfile, 인증 설정을 프로젝트 기준으로 고정합니다.
  • ✅ CI에서 프록시·캐시·레지스트리 미러의 책임 주체를 문서화합니다.
  • ✅ 사설 저장소는 NO_PROXY와 인증 경계를 확인한 뒤 별도로 테스트합니다.
  • ❌ 일시적인 설치 성공을 재현 가능한 빌드 성공으로 간주하지 않습니다.
한 줄 결론: 개발 네트워크의 진짜 성능은 최고 다운로드 속도가 아니라 동일한 코드와 의존성으로 빌드를 반복할 수 있는지로 판단하세요.

프로토콜과 회선을 고를 때 개발 작업에 맞추기

호환 클라이언트에서 Shadowsocks, VMess, Trojan, Hysteria2, WireGuard 같은 이름을 볼 수 있지만 프로토콜만으로 GitHub나 Docker의 결과를 예측할 수는 없습니다. 프로토콜은 클라이언트와 서버가 데이터를 캡슐화하고 전송하는 방식이며, 실제 체감은 출구 지역, 중계 경로, DNS 응답, 회선 혼잡, 대상 레지스트리의 상태가 함께 결정합니다.

Git fetch와 패키지 설치처럼 작은 요청이 반복되는 작업은 연결 수립과 DNS 응답의 안정성이 중요합니다. Docker 이미지처럼 큰 레이어를 연속으로 받는 작업은 지속적인 전송과 재연결 처리, 프록시의 대용량 응답 지원을 함께 봐야 합니다. CI는 여기에 여러 작업이 동시에 실행될 수 있으므로 특정 시간대의 혼잡과 공유 러너의 제한까지 고려해야 합니다.

직결 회선은 경로가 단순할 수 있지만 현재 통신사의 국제 연동에 영향을 크게 받을 수 있습니다. 중계 회선은 가까운 진입점에서 다른 출구로 이어지므로 직결 경로가 불안정할 때 대안이 될 수 있습니다. IEPL 전용 회선은 국제 구간의 경로를 보다 명확히 관리하는 방식이지만, 로컬 Wi-Fi 간섭이나 Docker 내부 DNS 문제까지 해결해 주지는 않습니다. 따라서 같은 출구 지역 안에서 직결·중계·전용 회선을 실제 개발 명령으로 비교하는 편이 좋습니다.

문제가 발생했을 때는 프로토콜을 계속 바꾸기보다 하나의 기준을 유지하고 한 요소씩 변경하세요. 먼저 GitHub의 clone 또는 fetch, 그 다음 레지스트리 접근, 마지막으로 Docker build를 확인하면 회선과 애플리케이션 설정의 영향을 분리하기 쉽습니다. 연결이 끊긴 시간대, 명령, 오류 문구, 사용한 회선 유형만 기록해도 지원 문의와 재현 과정이 훨씬 간단해집니다.

개발자 VPN 설정을 마무리하는 점검 목록

최종 설정은 개인 노트북에서 한 번 성공한 상태가 아니라, 문제가 생겼을 때 원인을 다시 찾을 수 있는 상태여야 합니다. 사용하는 운영체제와 클라이언트, 프록시 포트, 적용 대상, 예외 도메인, Docker 데몬 설정을 간단히 기록하세요. 구독 링크는 공개 저장소와 CI 로그에 올리지 말고, 계정 비밀번호와도 구분해 관리해야 합니다.

  • ✅ Git의 HTTPS·SSH 방식과 프록시 적용 범위를 확인했습니다.
  • ✅ Docker 클라이언트와 Docker 데몬의 네트워크 경로를 구분했습니다.
  • ✅ npm·pip 레지스트리와 lockfile을 고정하고 캐시 실패 시 대체 경로를 확인했습니다.
  • ✅ CI 러너의 프록시 정책과 비밀 변수 처리 방식을 검토했습니다.
  • ✅ 사내 도메인과 로컬 서비스가 불필요하게 외부 회선을 통과하지 않습니다.
  • ❌ 여러 VPN 클라이언트를 동시에 실행하거나 인증 정보를 설정 파일에 하드코딩하지 않습니다.

JeVPN은 Windows, macOS, iOS, Android, Linux를 지원하며, 공식 클라이언트 또는 호환 클라이언트에 구독 링크를 가져와 환경에 맞게 사용할 수 있습니다. 월 구독은 ¥9.9/월 60GB, ¥18/월 250GB, ¥28/월 500GB이며, 유량 패키지는 사용량이 소진될 때까지 사용할 수 있습니다. 모든 요금과 회선은 실제 작업 환경에서 필요한 지역과 경로를 확인한 뒤 선택하세요.