개발 환경에서 GitHub 웹페이지는 정상적으로 열리는데 git clone, Docker 이미지 다운로드, npm install만 유난히 느려지는 경우가 있습니다. 이 현상은 인터넷 전체가 느리기 때문이라기보다 서비스마다 사용하는 도메인, CDN, DNS 조회, 전송 프로토콜과 연결 경로가 다르기 때문에 발생합니다. GitHub의 코드 페이지와 API는 접속되지만 저장소의 대용량 객체는 별도 저장소로 이동할 수 있고, Docker Hub는 이미지 레이어를 다른 주소에서 내려받으며, npm은 패키지 메타데이터와 압축 파일을 여러 요청으로 가져옵니다.
따라서 개발자용 네트워크 설정은 단순히 “가장 빠른 서버 하나를 고르는 작업”이 아닙니다. 현재 작업에 필요한 서비스와 직접 연결해야 하는 서비스, 프록시를 통과해야 안정적인 서비스를 나누고, 운영체제와 클라이언트가 그 규칙을 실제로 적용하는지 확인해야 합니다. 이 글에서는 GitHub, Docker Hub, npm을 기준으로 서버 선택, 구독 가져오기, 분할 터널링, DNS와 명령줄 도구 점검 순서를 설명합니다.
개발 도구의 다운로드가 느려지는 이유
GitHub 사용에는 여러 단계가 있습니다. 저장소의 HTML 페이지를 여는 요청, GitHub API를 호출하는 요청, SSH 또는 HTTPS로 저장소를 복제하는 요청, 대용량 Git 객체를 가져오는 요청은 모두 같은 방식으로 처리되지 않을 수 있습니다. 특히 저장소가 Git LFS를 사용한다면 일반 Git 객체와 별도의 저장소 주소가 추가됩니다. 웹페이지가 빠르게 표시되어도 복제 과정에서 특정 호스트의 DNS 응답이나 TLS 연결이 지연되면 전체 작업은 느리게 느껴집니다.
Docker도 비슷합니다. Docker 클라이언트는 레지스트리 주소를 확인하고 인증 토큰을 받은 뒤 이미지 매니페스트와 여러 레이어를 병렬 또는 순차적으로 요청합니다. 작은 이미지 하나는 바로 내려받아지는 것처럼 보여도, 운영체제 이미지와 개발 도구가 포함된 이미지는 여러 레이어로 구성될 수 있습니다. 한 레이어의 연결이 반복해서 끊기면 이미 받은 레이어는 캐시에 남더라도 다음 단계가 오래 걸릴 수 있습니다.
npm은 기본 레지스트리에서 패키지 정보와 tarball을 가져옵니다. 패키지 매니저가 의존성 트리를 계산하는 동안 많은 메타데이터 요청이 발생하고, 실제 파일은 다른 CDN 주소로 이동할 수 있습니다. 프로젝트의 package-lock.json 또는 npm-shrinkwrap.json에 기록된 무결성 검증은 유지되어야 하므로, 속도를 높인다는 이유로 검증을 끄거나 출처가 불분명한 패키지 서버로 바꾸는 것은 적절하지 않습니다.
90+
국가 커버리지
200+
지원 회선
5
지원 운영체제
무제한
동시 접속 기기
이처럼 개발자 네트워크에서는 “GitHub가 된다”와 “Git 작업이 빠르다”를 구분해야 합니다. 먼저 어느 명령에서 멈추는지, 어떤 호스트에서 시간이 걸리는지, 동일한 작업이 다른 회선에서 어떻게 달라지는지를 기록하면 서버와 클라이언트 설정을 훨씬 효율적으로 조정할 수 있습니다.
GitHub·Docker·npm에 맞는 서버와 프로토콜 고르기
서버를 선택할 때는 자신의 현재 위치만 보지 말고 목표 서비스의 인프라 위치와 연결 방향을 함께 고려해야 합니다. GitHub와 npm의 주요 요청이 북미 또는 아시아의 CDN으로 연결되는 환경이라면 해당 서비스와 통신 경로가 좋은 지역을 우선 시험합니다. Docker Hub는 인증 서버와 이미지 레이어 서버가 다를 수 있으므로, 한 번의 웹페이지 접속 결과만으로 판단하지 말고 실제 docker pull 작업으로 확인해야 합니다.
클라이언트에 국가, 도시, 회선 유형이 함께 표시된다면 먼저 지역을 좁힌 다음 직접 연결, 중계 회선, IEPL 또는 BGP와 같은 경로 특성을 비교합니다. 직접 연결은 구조가 단순하지만 현지 통신사와 공용 인터넷 라우팅의 영향을 크게 받을 수 있습니다. 중계 회선은 진입점과 출구 사이에 제어된 전달 구간을 추가해 특정 환경에서 경로를 개선할 수 있지만, 항상 더 빠르다고 단정할 수는 없습니다. IEPL은 국제 구간에 전용 또는 제어된 전송 자원을 사용하는 회선 유형을 가리키며, BGP는 네트워크 간 경로 교환과 라우팅 방식에 관한 용어입니다. 두 용어 모두 실제 대상 서비스와 시간대별 결과를 대신 판단해 주지는 않습니다.
프로토콜 호환성을 먼저 확인하기
Shadowsocks, VMess, Trojan, Hysteria2, WireGuard는 이름만으로 우열을 정할 수 없습니다. 클라이언트 코어가 해당 프로토콜을 지원해야 하고, 서버 이름, 포트, TLS, 인증 정보, 전송 계층과 같은 매개변수가 정확히 맞아야 합니다. Hysteria2처럼 UDP와 QUIC의 영향을 받는 방식은 현재 네트워크가 UDP를 제한하는지 확인해야 하며, WireGuard는 운영체제와 클라이언트의 터널 권한 및 라우팅 구성이 중요합니다. Shadowsocks, VMess, Trojan도 플러그인이나 전송 옵션이 포함된 경우 클라이언트별 지원 범위가 달라질 수 있습니다.
서비스가 제공하는 구독 링크를 Clash Verge, sing-box, Shadowrocket 또는 공식 Windows·macOS·Android·iOS·Linux 클라이언트에 가져올 때는 먼저 해당 클라이언트가 구독 형식과 프로토콜을 지원하는지 확인하세요. 구독 링크는 여러 서버 설정을 갱신하는 주소이므로 공개 저장소, 이슈, 팀 채팅이나 터미널 로그에 그대로 남기지 않는 것이 좋습니다.
| 작업 | 우선 확인할 호스트 | 서버 선택 기준 | 주의할 점 |
|---|---|---|---|
| Git clone·fetch | GitHub 웹/API와 Git 전송 주소 | 저장소가 안정적으로 유지되는 지역과 회선 | SSH와 HTTPS의 경로가 다를 수 있음 |
| Git LFS | LFS 저장소 및 객체 다운로드 주소 | 대용량 파일을 오래 유지할 수 있는 회선 | 일반 Git 페이지 결과만으로 판단하지 않기 |
| docker pull | 레지스트리, 인증 서버, 레이어 저장소 | 여러 레이어 요청이 안정적으로 완료되는 지역 | 인증은 되지만 레이어만 실패할 수 있음 |
| npm install | 레지스트리와 패키지 tarball CDN | DNS와 다수의 짧은 요청에 안정적인 회선 | 무결성 검증과 lockfile을 유지하기 |
| API·CI/CD | API 엔드포인트와 러너가 접근하는 호스트 | 긴 연결과 재시도에 안정적인 경로 | 러너와 개발 PC의 네트워크가 다를 수 있음 |
구독을 가져오고 개발 환경에서 테스트하기
설정은 한 번에 여러 값을 바꾸지 말고 기본 연결부터 확인하는 순서가 좋습니다. 먼저 공식 클라이언트 또는 현재 사용하는 호환 클라이언트를 설치한 뒤, 서비스 패널에서 발급한 구독 링크를 관리 화면에 추가합니다. 가져오기가 끝나면 서버 목록에 이름과 프로토콜이 표시되는지 확인하고, 하나의 서버를 선택해 연결합니다. 시스템 프록시 또는 TUN 모드는 클라이언트의 설명을 읽고 필요한 범위에서만 활성화하세요.
- 현재 연결을 끄고 브라우저에서 일반 웹사이트와 GitHub 페이지가 열리는지 확인합니다.
- 클라이언트의 구독 관리 메뉴에서 링크를 추가하고 목록이 최신 상태인지 확인합니다.
- 대상 서비스와 가까운 지역의 서버를 하나 선택한 뒤 연결합니다.
- 작은 공개 저장소를 대상으로
git ls-remote또는 짧은 fetch를 실행합니다. - 테스트용 이미지에 대해
docker pull을 실행하고 인증 단계와 레이어 다운로드 중 어디에서 지연되는지 기록합니다. - 프로젝트 복사본에서
npm ci또는 평소 사용하는 설치 명령을 실행하고 오류 호스트와 재시도 메시지를 확인합니다.
터미널에서 사용할 수 있는 기본 점검 명령은 다음과 같습니다. 명령의 결과에는 내부 호스트명이나 토큰이 포함될 수 있으므로 지원 요청이나 공개 문서에 붙여 넣을 때 인증 정보와 개인 경로를 먼저 가리세요.
git ls-remote https://github.com/조직/저장소.git
docker pull 이미지:태그
npm config get registry
npm cigit ls-remote는 전체 작업 트리를 내려받지 않고 원격 참조에 접근할 수 있는지 확인하는 데 유용합니다. Docker에서는 첫 시도만 보지 말고 인증이 끝난 뒤 실제 레이어가 진행되는지 확인해야 합니다. npm에서는 레지스트리 주소가 회사 정책이나 프로젝트 설정에 의해 덮어쓰이지 않았는지 확인합니다. npm config list를 사용할 때는 토큰이 출력될 수 있으므로 결과를 그대로 공유하지 마세요.
분할 터널링으로 개발 도구와 로컬 서비스를 나누기
모든 트래픽을 하나의 원격 회선으로 보내는 글로벌 모드는 간단하지만 개발 환경에서는 예상하지 못한 부작용이 생길 수 있습니다. 사내 GitLab, 로컬 Docker 레지스트리, 패키지 프록시, 데이터베이스, Kubernetes API가 사설 주소에 있다면 원격 회선으로 보내는 순간 접근이 끊길 수 있습니다. 반대로 해외 GitHub API나 Docker Hub 레이어를 직접 연결하면 특정 네트워크에서 반복 지연이 발생할 수 있습니다. 분할 터널링은 이 두 종류의 트래픽을 규칙으로 나누는 방법입니다.
규칙을 설계하는 순서
먼저 반드시 로컬에 남겨야 하는 대상을 정합니다. localhost, 사설 IP 대역, 회사 내부 도메인, 로컬 Docker 엔진과 개발 중인 서비스는 직접 연결 그룹에 두는 것이 일반적입니다. 그다음 GitHub의 웹·API·Git 전송, Docker Hub의 레지스트리와 인증 관련 주소, npm 레지스트리와 패키지 CDN을 실제 로그에서 확인해 필요한 대상만 프록시 그룹에 추가합니다. 서비스가 사용하는 CDN 호스트는 바뀔 수 있으므로 오래된 블로그 글의 도메인 목록만 복사하기보다 현재 명령의 오류와 DNS 결과를 기준으로 갱신하세요.
도메인 규칙은 너무 넓게 작성하지 않는 것이 좋습니다. 예를 들어 모든 HTTPS 트래픽을 프록시로 보내면 사내 서비스와 운영 도구까지 원격 경로를 사용할 수 있습니다. 반대로 최상위 도메인 전체를 무조건 직접 연결하면 필요한 하위 서비스가 빠질 수 있습니다. Clash 계열 클라이언트에서는 규칙 순서와 마지막 기본 정책이 중요하고, sing-box에서는 route rule, DNS rule과 outbound 선택이 서로 일치해야 합니다. Shadowrocket에서도 도메인, IP와 프로세스 기반 규칙을 혼동하지 말고 iOS의 시스템 VPN 권한이 활성화되어 있는지 확인해야 합니다.
- ✅ 회사 내부 도메인과 로컬 개발 주소는 직접 연결 그룹에 남깁니다.
- ✅ GitHub, Docker, npm은 실제로 요청되는 호스트를 확인한 뒤 필요한 규칙만 추가합니다.
- ✅ DNS 조회 경로와 트래픽 경로가 서로 어긋나지 않는지 확인합니다.
- ✅ CI/CD 러너가 개발 PC와 다른 네트워크를 사용한다는 점을 별도로 검토합니다.
- ❌ 두 개의 프록시 클라이언트를 동시에 TUN 또는 시스템 VPN 모드로 실행하지 않습니다.
- ❌ npm 무결성 검증, TLS 인증서 검증과 Docker 인증 설정을 속도 때문에 끄지 않습니다.
분할 터널링을 적용한 뒤에는 로컬 서비스와 외부 서비스를 각각 테스트해야 합니다. 로컬 Docker 레지스트리에서 이미지를 가져오는 작업이 실패하지 않는지, GitHub에서 코드와 LFS 객체를 모두 내려받을 수 있는지, npm 설치가 예상한 레지스트리와 tarball 주소를 사용하는지 확인합니다. 규칙을 추가할수록 설정은 복잡해지므로 목적과 근거가 불분명한 규칙은 삭제하는 편이 유지 관리에 유리합니다.
속도가 개선되지 않을 때 확인할 항목
서버를 바꿔도 결과가 같다면 먼저 DNS를 점검하세요. 브라우저와 터미널이 서로 다른 DNS 경로를 사용하거나, 오래된 캐시가 잘못된 주소를 계속 반환할 수 있습니다. 다만 DNS 주소를 바꾸는 것만으로 대용량 전송 경로가 항상 개선되는 것은 아닙니다. 도메인 조회는 빠르지만 실제 연결 단계에서 문제가 생길 수 있으므로 DNS 조회 시간과 TLS 연결, 데이터 전송 단계를 나누어 봐야 합니다.
그다음 IPv4와 IPv6 경로를 비교합니다. 일부 네트워크에서는 IPv6 주소가 먼저 선택되지만 해당 경로가 안정적이지 않을 수 있습니다. 운영체제와 클라이언트가 IPv6를 어떻게 처리하는지 확인하고, 임의로 시스템 설정을 영구 변경하기 전에 일시적인 테스트로 원인을 좁히세요. MTU 문제도 놓치기 쉽습니다. 웹페이지는 열리지만 TLS 연결이나 큰 파일 전송이 반복 중단된다면 패킷 단편화와 터널의 MTU 설정이 관련될 수 있습니다.
명령줄 도구의 프록시 설정도 확인해야 합니다. 브라우저에만 시스템 프록시가 적용되고 Git, Docker 데몬 또는 npm에는 적용되지 않는 구성이 흔합니다. Git은 전역 설정과 저장소별 설정을 각각 확인하고, Docker는 CLI와 데몬이 서로 다른 환경에서 실행될 수 있다는 점을 고려해야 합니다. Docker Desktop을 사용한다면 데몬이 실행되는 네트워크 경로와 호스트 운영체제의 프록시 설정이 동일하다고 가정하지 마세요.
CI/CD에서는 로컬 컴퓨터에서 성공한 설정이 그대로 재현되지 않습니다. 러너가 클라우드나 사내 네트워크에 있을 수 있고, 비밀 변수, 인증서, 레지스트리 접근 정책도 별도로 적용됩니다. 파이프라인에서 무조건 모든 요청을 하나의 프록시로 보내기보다, 공식 레지스트리와 사내 저장소의 접근 정책을 확인하고 필요한 단계에만 명시적인 프록시 환경 변수를 적용하는 편이 안전합니다.
마지막으로 속도와 안정성을 분리해 평가하세요. 짧은 요청이 빠른 서버가 장시간 이미지 레이어나 의존성 묶음을 안정적으로 전송한다는 보장은 없습니다. Git clone, Docker pull, npm ci처럼 실제 업무에 가까운 작업을 기준으로 중단, 재시도, 인증 실패, 규칙 누락을 함께 기록하면 서버를 바꿀 때도 판단 근거가 남습니다.