Docker 미러 속도 테스트 실전: 3가지 방법과 자동 전환 스크립트

이런 상황을 겪어본 적이 있나요? CI/CD 파이프라인이 docker pull의 99% 지점에서 멈추고, 로그에는 “connection timeout”과 “TLS handshake timeout”이 계속 찍히는데 배포는 이미 10분째 멈춰 있는 상황 말입니다.

지난주 제 프로젝트 하나도 딱 이 문제를 만났습니다. 새벽 배포가 완전히 실패한 정도는 아니었지만, 7번 연속 재시도하고, 매번 수동으로 미러를 바꾸고, Docker daemon을 다시 시작하다 보니 거의 30분이 지나 있었습니다. 더 답답한 점은 어떤 미러가 실제로 쓸 만한지 알 수 없다는 것입니다. Alibaba Cloud의 가속기는 Alibaba Cloud 서버가 아니면 제한이 심하고, USTC 미러는 작년 6월에 중단됐고, “고속”이라고 홍보하는 일부 서드파티 미러는 연결성조차 제대로 측정되지 않을 때가 있습니다.

여기서 질문이 하나 나옵니다. 현재 네트워크 환경에서 가장 빠른 Docker 미러를 어떻게 빠르게 측정해서 찾을 수 있을까요?

이 글에서는 단순히 미러 주소 목록을 늘어놓고 하나씩 시도하라고 하지 않겠습니다. 그런 글은 이미 많습니다. 대신 속도 측정 자체의 기술 원리, 세 가지 측정 방법의 장단점, 바로 가져다 쓸 수 있는 자동화 스크립트 두 가지 버전(Shell과 Python)을 설명하겠습니다. 마지막에는 2026년 5월 기준으로 실제 측정한 중국 내 Docker 미러 데이터를 공유해, 지금 어떤 미러가 실제로 쓸 만한지도 정리하겠습니다.

---

속도 측정 방법 비교: ping, HTTP HEAD, 실제 pull

Docker 미러 속도를 측정하는 대표적인 방법은 세 가지입니다. ping 테스트, HTTP HEAD 테스트, 실제 이미지 pull입니다. 각각 장단점이 있으니 먼저 표로 차이를 정리해 보겠습니다.

방법	원리	장점	단점	적합한 상황
Ping 속도 측정	ICMP 응답 시간	간단하고 빠름	실제 다운로드 속도를 반영하지 않으며, 일부 서버는 ping을 막음	1차 선별
HTTP HEAD 측정	Registry API /v2/ 엔드포인트	표준 API이며 V2 지원 여부 확인 가능	연결성만 측정하고 다운로드 속도는 아님	사용 가능 여부 검증
실제 pull 측정	docker pull로 실제 이미지 다운로드	실제 체감 속도를 가장 정확히 반영	시간이 오래 걸리고 대역폭을 사용함	최종 검증

왜 ping만으로는 정확하지 않을까요?

많은 사람이 가장 먼저 떠올리는 방법은 ping입니다. 간단하니까요. 명령어 한 줄이면 지연 시간을 볼 수 있습니다. 하지만 ping이 측정하는 것은 ICMP 응답이고, 실제 이미지 다운로드와는 완전히 다른 문제입니다.

예를 들어 어떤 미러 서버가 보안상의 이유로 ICMP를 비활성화했다고 해보겠습니다. 많은 클라우드 업체가 이렇게 설정합니다. 이 경우 ping은 timeout으로 나오지만, 실제 HTTP 요청은 정상일 수 있습니다. 반대로 어떤 CDN 노드는 ping 지연 시간이 20ms에 불과해도, HTTP 요청에서는 라우팅 전환, TLS 협상, 대역폭 제한 때문에 실제 다운로드 속도가 매우 느릴 수 있습니다.

HTTP HEAD 측정의 표준 방식

Docker Registry API v2 규격에는 상태 확인용 엔드포인트인 /v2/가 정의되어 있습니다. 이 엔드포인트에 HEAD 또는 GET 요청을 보내서 200 OK가 반환되면, 해당 Registry가 V2 API를 지원하고 현재 사용 가능하다는 뜻입니다.

핵심 로직은 다음과 같습니다.

curl -I -m 5 https://docker.xuanyuan.me/v2/

HTTP/2 200이 보이면 이 미러에 현재 연결할 수 있다는 의미입니다. 응답 시간, 즉 요청을 보낸 시점부터 header를 받을 때까지 걸린 시간은 네트워크 지연을 대략적으로 보여줍니다. 다운로드 속도는 아니지만, 적어도 연결 가능 여부와 응답 속도는 판단할 수 있습니다.

실제 pull 측정: 가장 현실적인 검증

가장 믿을 만한 방법은 당연히 실제로 이미지를 docker pull해 보는 것입니다. 저는 테스트할 때 Alpine을 자주 사용합니다. 크기가 약 5MB로 작아서 빠르게 pull할 수 있고, 대역폭도 많이 쓰지 않기 때문입니다.

time docker pull alpine:latest

여기서는 real 시간을 보세요. 요청 시작부터 pull 완료까지 걸린 전체 시간입니다. 이미지 크기를 전체 시간으로 나누면 평균 다운로드 속도를 계산할 수 있습니다. 이것이 실제 배포 시 체감하게 될 속도에 가장 가깝습니다.

다만 이 방법에는 문제가 하나 있습니다. 느립니다. 미러 하나를 측정하는 데 몇 초에서 수십 초가 걸리고, 10개 미러를 측정하면 몇 분이 필요합니다. 또한 미러마다 캐시 상태가 다를 수 있습니다. 어떤 미러는 Alpine을 이미 캐시하고 있고, 어떤 미러는 아직 캐시하지 않았을 수 있어 공정성에도 영향을 줍니다.

---

제 추천은 이렇습니다. 먼저 HTTP HEAD로 연결 가능한 미러를 빠르게 걸러냅니다. 연결되지 않거나 응답이 지나치게 느린 미러를 제외한 뒤, 상위 3-5개만 실제 pull로 최종 검증하세요. 이렇게 하면 효율도 높고 결과도 꽤 믿을 만합니다.

---

Shell 스크립트 구현: 한 번에 속도 측정하고 자동 전환하기

서버 운영을 자주 하거나 터미널 작업에 익숙하다면 Shell 스크립트가 가장 빠르게 적용할 수 있는 방식입니다. 아래 스크립트는 병렬로 속도를 측정하고, 결과를 정렬한 뒤, daemon.json까지 자동으로 업데이트합니다. 그대로 가져다 써도 됩니다.

핵심 로직: 병렬 측정 + 자동 정렬

이 스크립트의 핵심 아이디어는 간단합니다. 미러 목록을 정의하고, curl로 각 미러의 /v2/ 엔드포인트 응답 시간을 측정합니다. 결과를 정렬해 가장 빠른 몇 개를 고른 다음 /etc/docker/daemon.json을 자동으로 수정합니다.

먼저 속도 측정 함수입니다.

#!/bin/bash

# 미러 목록(2026년 5월 실측 기준 사용 가능)
MIRRORS=(
    "https://docker.xuanyuan.me"
    "https://docker.1ms.run"
    "https://docker.m.daocloud.io"
    "https://atomhub.openatom.cn"
)

# 단일 미러의 응답 시간 측정(밀리초)
test_mirror() {
    local mirror=$1
    local start=$(date +%s%N)
    local http_code=$(curl -s -o /dev/null -w "%{http_code}" \
        --connect-timeout 5 \
        --max-time 10 \
        "$mirror/v2/")
    local end=$(date +%s%N)
    local elapsed=$(( (end - start) / 1000000 ))

    if [[ "$http_code" == "200" ]]; then
        echo "$elapsed|$mirror"
    else
        echo "999999|$mirror"  # 실패한 미러는 매우 큰 값으로 표시
    fi
}

여기에는 작은 디테일이 있습니다. date +%s%N으로 나노초 단위 타임스탬프를 얻고, elapsed를 계산할 때 1000000으로 나눠 밀리초로 변환합니다. 실패한 미러, 즉 HTTP 상태 코드가 200이 아닌 경우는 999999ms로 표시합니다. 이렇게 하면 정렬할 때 자연스럽게 맨 뒤로 밀립니다.

병렬 속도 측정: xargs 멀티스레드

미러 10개를 하나씩 측정하면 너무 느립니다. 여기서는 xargs -P로 병렬 실행을 구현합니다.

# 모든 미러를 병렬로 측정
results=$(printf "%s\n" "${MIRRORS[@]}" | \
    xargs -P 4 -I {} bash -c 'test_mirror "$@"' _ {})

# 응답 시간 기준 정렬(오름차순)
sorted=$(echo "$results" | sort -t '|' -k1 -n)

# 정렬 결과 출력
echo "속도 측정 결과(응답 시간이 짧을수록 좋음):"
echo "$sorted" | while IFS='|' read time url; do
    if [[ "$time" != "999999" ]]; then
        echo "  ${time}ms  $url"
    else
        echo "  [실패]  $url"
    fi
done

xargs -P 4는 4개 작업을 병렬로 실행한다는 뜻입니다. 서버 성능에 맞춰 값을 조정할 수 있습니다. 테스트 환경에서는 2-4 정도면 충분하고, 운영 환경에서는 8-10까지 올려도 됩니다.

daemon.json 자동 업데이트

마지막 단계는 가장 빠른 미러 3개를 daemon.json에 쓰는 것입니다.

# 가장 빠른 미러 3개 추출
top3=$(echo "$sorted" | grep -v "999999" | head -n 3 | cut -d '|' -f 2)

# JSON 배열 구성
mirrors_json=$(echo "$top3" | sed 's/.*/"&"/' | tr '\n' ',' | sed 's/,$//')

# ⚠️ 경고: 직접 덮어쓰면 기존 설정이 사라집니다!
# daemon.json에 이미 다른 필드(data-root, log-driver 등)가 있다면 수동으로 병합하세요
cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": [$mirrors_json]
}
EOF

echo "daemon.json을 업데이트했습니다. 가장 빠른 미러:"
echo "$top3"

# Docker 서비스 재시작(root 권한 필요)
if [[ $EUID -eq 0 ]]; then
    systemctl restart docker
    echo "Docker 서비스를 재시작했습니다. 설정이 적용되었습니다"
else
    echo "Docker를 재시작하려면 root 권한이 필요합니다. 수동으로 실행하세요: sudo systemctl restart docker"
fi

---

사용 방법

이 스크립트를 docker-mirror-test.sh로 저장하고, chmod +x로 실행 권한을 추가합니다.

chmod +x docker-mirror-test.sh
sudo ./docker-mirror-test.sh  # daemon.json을 수정하려면 root 권한이 필요합니다

실행 후에는 다음과 비슷한 출력이 보입니다.

속도 측정 결과(응답 시간이 짧을수록 좋음):
  45ms   https://docker.xuanyuan.me
  68ms   https://docker.1ms.run
  120ms  https://docker.m.daocloud.io
  [실패] https://atomhub.openatom.cn

daemon.json을 업데이트했습니다. 가장 빠른 미러:
https://docker.xuanyuan.me
https://docker.1ms.run
https://docker.m.daocloud.io

다만 이 스크립트에는 주의할 점이 있습니다. 서버에 이미 다른 Docker 설정, 예를 들어 data-root나 log-driver가 있다면 daemon.json을 직접 덮어쓰면서 해당 설정이 사라질 수 있습니다. 더 안전한 방법은 기존 설정을 읽고 registry-mirrors 필드만 추가하는 것입니다. 아래 Python 버전은 이 처리를 포함하므로, 가능하면 Python 버전을 우선 사용하는 것을 추천합니다.

---

Python 스크립트 구현: 정밀한 시간 측정과 오류 처리

Shell 스크립트가 익숙하지 않거나 더 정확한 시간 측정과 오류 처리가 필요하다면 Python 버전이 더 편합니다. Python의 requests 라이브러리는 timeout을 정밀하게 제어하고 다양한 예외를 잡을 수 있으며, macOS, Windows, Linux에서 모두 실행할 수 있습니다.

핵심 속도 측정 함수

import requests
import time
import json
from pathlib import Path

# 미러 목록(2026년 5월 실측 기준 사용 가능)
MIRRORS = [
    "https://docker.xuanyuan.me",
    "https://docker.1ms.run",
    "https://docker.m.daocloud.io",
    "https://atomhub.openatom.cn",
]

def test_mirror(url, timeout=5):
    """단일 미러의 응답 시간 측정(밀리초)"""
    start = time.time()
    try:
        r = requests.head(
            f"{url}/v2/",
            timeout=timeout,
            allow_redirects=True,
            headers={"User-Agent": "docker-mirror-test/1.0"}
        )
        elapsed = (time.time() - start) * 1000  # 밀리초로 변환
        if r.status_code == 200:
            return elapsed, url
        else:
            return float('inf'), url
    except requests.exceptions.RequestException:
        return float('inf'), url

여기에도 디테일이 하나 있습니다. allow_redirects=True를 사용했습니다. 일부 미러는 CDN 노드로 redirect하기 때문에 최종 응답 시간을 추적해야 합니다. headers에 User-Agent도 추가했습니다. 일부 CDN이 요청을 crawler로 오인해 차단하는 것을 피하기 위해서입니다.

병렬 속도 측정: ThreadPoolExecutor

Python의 concurrent.futures 모듈은 Shell의 xargs보다 더 유연한 thread pool을 제공합니다.

from concurrent.futures import ThreadPoolExecutor, as_completed

def test_all_mirrors(mirrors, max_workers=4):
    """모든 미러를 병렬로 테스트"""
    results = []
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        future_to_url = {
            executor.submit(test_mirror, url): url
            for url in mirrors
        }
        for future in as_completed(future_to_url):
            elapsed, url = future.result()
            results.append((elapsed, url))
    return sorted(results, key=lambda x: x[0])

as_completed는 완료된 순서대로 결과를 반환하므로 불필요한 대기를 줄일 수 있습니다. 서버 성능과 네트워크 대역폭에 따라 max_workers=8 또는 그 이상으로 조정할 수 있습니다.

daemon.json 자동 업데이트(기존 설정 보존)

이 버전은 기존 daemon.json을 읽고 registry-mirrors 필드만 갱신합니다. 파일 전체를 단순히 덮어쓰지 않습니다.

def update_daemon_json(fastest_mirrors, daemon_path="/etc/docker/daemon.json"):
    """daemon.json을 업데이트하되 기존 설정은 보존"""
    path = Path(daemon_path)

    # 기존 설정 읽기
    if path.exists():
        config = json.loads(path.read_text())
    else:
        config = {}

    # registry-mirrors 업데이트
    config["registry-mirrors"] = fastest_mirrors[:3]

    # 설정 쓰기
    path.write_text(json.dumps(config, indent=2))
    print(f"{daemon_path}을 업데이트했습니다. 가장 빠른 미러:")
    for m in fastest_mirrors[:3]:
        print(f"  {m}")

def main():
    print("미러 속도를 측정하는 중...")
    results = test_all_mirrors(MIRRORS)

    print("\n속도 측정 결과(응답 시간이 짧을수록 좋음):")
    for elapsed, url in results:
        if elapsed != float('inf'):
            print(f"  {elapsed:.0f}ms  {url}")
        else:
            print(f"  [실패]  {url}")

    # 사용 가능한 미러 추출
    valid_mirrors = [url for elapsed, url in results if elapsed != float('inf')]

    if valid_mirrors:
        update_daemon_json(valid_mirrors)
        print("\n설정을 적용하려면 Docker 서비스를 재시작하세요: sudo systemctl restart docker")
    else:
        print("\n모든 미러가 실패했습니다. 네트워크나 미러 목록을 확인하세요")

if __name__ == "__main__":
    main()

사용 방법

스크립트를 docker-mirror-test.py로 저장하고 바로 실행합니다.

python3 docker-mirror-test.py

출력 예시는 다음과 같습니다.

미러 속도를 측정하는 중...

속도 측정 결과(응답 시간이 짧을수록 좋음):
  42ms   https://docker.xuanyuan.me
  71ms   https://docker.1ms.run
  118ms  https://docker.m.daocloud.io
  [실패] https://atomhub.openatom.cn

/etc/docker/daemon.json을 업데이트했습니다. 가장 빠른 미러:
  https://docker.xuanyuan.me
  https://docker.1ms.run
  https://docker.m.daocloud.io

설정을 적용하려면 Docker 서비스를 재시작하세요: sudo systemctl restart docker

솔직히 Python 버전은 Shell 버전보다 아주 조금 느립니다. 대략 10-20ms 정도의 overhead가 있습니다. 하지만 측정 정밀도와 오류 처리가 더 좋습니다. 서버의 Docker 설정이 복잡하다면, 다른 필드를 덮어쓰지 않는 Python 버전이 더 안전합니다.

---

2026년 중국 내 Docker 미러 실측 데이터

미러 상태는 빠르게 바뀝니다. 작년에 잘 되던 미러가 올해는 중단될 수 있고, 지난달 빠르던 미러가 이번 달에는 제한될 수도 있습니다. 참고용으로 2026년 5월에 실제 측정한 데이터를 정리했습니다.

사용 가능한 미러 실측 데이터

미러	주소	평균 속도	안정성	비고
Xuanyuan 미러	https://docker.xuanyuan.me	12.3 MB/s	99.2%	모든 플랫폼 지원, 중국 내 규정 준수 운영
1ms 미러	https://docker.1ms.run	11.8 MB/s	99.5%	금융급 SLA, 기업용 우선 선택지
DaoCloud	https://docker.m.daocloud.io	9.5 MB/s	97.6%	오래된 서비스, 백업 옵션
AtomHub	https://atomhub.openatom.cn	8.2 MB/s	100%	OpenAtom Foundation 공식 공익 프로젝트

이 데이터는 Tencent Cloud 개발자 커뮤니티의 실측 보고서(2026-03)를 바탕으로 했고, 저는 HTTP HEAD 측정으로 다시 검증했습니다. 대체로 실제 상황과 맞았습니다. Xuanyuan 미러와 1ms 미러가 가장 빠르고 안정성도 높아 우선 사용을 추천합니다.

이미 사용할 수 없게 된 미러(2024-2026)

아래 미러들은 한때 사용할 수 있었지만, 지금은 서비스가 중단됐거나 제한이 심합니다.

미러	주소	상태	비고
USTC	https://docker.mirrors.ustc.edu.cn	❌ 중단됨	2024년 6월 외부 서비스 중단
NetEase	http://hub-mirror.c.163.com	❌ 중단됨	동기화 중단, 이미지가 오래됨
Alibaba Cloud 공식 가속기	https://registry.cn-hangzhou.aliyuncs.com	⚠️ 제한 심함	Alibaba Cloud 외 서버에서는 제한이 있어 비추천

솔직히 Alibaba Cloud 가속기 문제는 저도 겪었습니다. Tencent Cloud 서버에서 Alibaba Cloud 가속기를 설정했더니 이미지 pull이 자주 timeout됐고, 나중에야 Alibaba Cloud가 자사 서버가 아닌 환경에 제한을 둔다는 것을 알았습니다. Alibaba Cloud ECS를 쓴다면 해당 가속기가 실제로 빠를 수 있습니다. 하지만 다른 클라우드 사업자와 섞어 쓰는 환경에서는 기대하지 않는 편이 낫습니다.

NAS 사용자와 중국 내 개발자의 현실

Synology나 ZSpace 같은 NAS 사용자라면 미러 선택이 더 까다롭습니다. NAS에서 Docker 설정을 바꾸는 방식은 일반 서버만큼 단순하지 않고, 일부 NAS 시스템은 daemon.json 수정 권한을 제한하기도 합니다.

이런 경우에는 AtomHub(OpenAtom Foundation 공식 프로젝트)를 추천합니다. 공익 성격의 서비스라 제한이나 과금이 없고 안정성이 100%입니다. 속도는 Xuanyuan이나 1ms만큼 빠르지 않지만, 적어도 안정적으로 사용할 수 있습니다. 또한 AtomHub는 특정 클라우드 업체에 의존하지 않기 때문에 플랫폼을 가리지 않고 일관된 경험을 제공합니다.

---

시의성 안내: 미러 상태는 빠르게 바뀝니다. 이 글의 데이터는 2026년 5월 기준입니다. 실제 사용 전에는 앞에서 소개한 속도 측정 스크립트로 주기적으로 검증하거나, 매주 자동으로 속도를 측정해 설정을 갱신하는 예약 작업을 두는 것이 좋습니다.

---

daemon.json 설정 모범 사례

속도 측정이 끝났다면 다음 단계는 Docker daemon 설정입니다. 올바르게 설정하면 Docker가 자동으로 장애를 회피합니다. 첫 번째 미러가 실패하면 다음 미러로 자동 전환합니다.

추천 설정

{
  "registry-mirrors": [
    "https://docker.xuanyuan.me",
    "https://docker.1ms.run",
    "https://docker.m.daocloud.io"
  ]
}

미러는 2-3개면 충분합니다. 너무 많이 설정하지 마세요. Docker는 순서대로 시도하고, 첫 번째로 사용 가능한 미러에서 응답을 받으면 뒤쪽 미러는 사용하지 않습니다. 너무 많은 미러를 넣으면 해석 비용만 늘고, 이미 죽은 미러가 섞일 가능성도 커집니다.

Docker의 장애 회피 메커니즘

Docker daemon의 registry-mirrors 필드는 다음 방식으로 동작합니다.

1. docker pull ubuntu:latest를 실행합니다.
2. Docker는 먼저 첫 번째 미러인 docker.xuanyuan.me를 시도합니다.
3. 첫 번째 미러가 timeout되거나 오류를 반환하면 Docker는 두 번째 미러인 docker.1ms.run으로 자동 전환합니다.
4. 모든 미러가 실패하면 마지막에 Docker Hub 공식 원본으로 fallback합니다.

이 메커니즘의 장점은 단일 미러가 장애를 일으켜도 배포가 중단되지 않는다는 것입니다. 단점은 첫 번째 미러가 느리지만 실패하지는 않는 경우입니다. 이때 Docker는 계속 그 미러를 사용하고, 더 빠른 미러로 자동 전환하지 않습니다.

그래서 정기적인 속도 측정이 의미가 있습니다. 가장 빠른 미러를 첫 번째에 두고, 그다음으로 빠른 미러를 두 번째에 두면 됩니다.

설정 적용 여부 검증

설정을 수정한 뒤 Docker 서비스를 재시작합니다.

sudo systemctl restart docker

그다음 미러 설정이 적용됐는지 확인합니다.

docker info | grep -A 5 "Registry Mirrors"

다음과 비슷한 출력이 보일 것입니다.

Registry Mirrors:
 https://docker.xuanyuan.me/
 https://docker.1ms.run/
 https://docker.m.daocloud.io/

이렇게 보이면 설정이 성공적으로 적용된 것입니다. 이후 이미지를 pull할 때 Docker는 이 미러들을 우선 사용합니다.

macOS와 Windows의 설정 경로

Docker Desktop(macOS 또는 Windows)을 사용한다면 설정 경로가 다릅니다.

• macOS: Docker Desktop → Settings → Docker Engine → JSON 편집
• Windows: 마찬가지로 Settings → Docker Engine에서 편집

설정 내용은 동일하고, 인터페이스만 다릅니다. 수정 후 “Apply & Restart”를 클릭하면 Docker Desktop이 자동으로 재시작됩니다.

---

다시 말하지만 daemon.json에는 data-root(이미지 저장 경로), log-driver(로그 드라이버), storage-driver(스토리지 드라이버) 같은 다른 필드도 설정할 수 있습니다. 이런 설정이 있다면 registry-mirrors와 같은 JSON 안에 병합해야 하며, 기존 내용을 덮어쓰면 안 됩니다. Python 버전 스크립트는 이 처리를 이미 포함하고 있고, Shell 버전은 수동 병합이 필요합니다.

---

정리

길게 설명했지만 핵심은 세 가지입니다.

1. 속도 측정 방법: 먼저 HTTP HEAD로 연결 가능한 미러를 빠르게 선별하고, 상위 몇 개만 실제 pull로 검증하세요. ping은 추천하지 않습니다. ping은 ICMP 응답을 측정할 뿐 다운로드 속도와는 직접 관련이 없습니다.

2. 자동화 스크립트: Shell 버전은 운영자가 빠르게 배포하기 좋고, Python 버전은 정밀한 속도 측정과 크로스 플랫폼 사용에 적합합니다. 두 스크립트 모두 daemon.json을 자동 업데이트해 수동 설정의 번거로움을 줄여줍니다.

3. 미러 선택: 2026년 5월 실측 기준으로 Xuanyuan 미러와 1ms 미러가 가장 빠르고 안정적입니다. AtomHub는 NAS 사용자와 공익 성격의 사용 환경에 적합합니다. 이미 사용할 수 없어진 미러(USTC, NetEase, 제한이 심한 Alibaba Cloud 가속기)는 더 이상 쓰지 않는 것이 좋습니다.

---

실행 제안:

• 이 글의 속도 측정 스크립트(Shell 또는 Python)를 사용해 현재 네트워크 환경에서 각 미러의 속도를 테스트하세요.
• cron 또는 systemd timer로 예약 작업을 만들어 매주 자동으로 속도를 측정하고 설정을 갱신하세요. 미러 상태는 빠르게 바뀌므로 정기 검증이 가장 안전합니다.
• 팀의 CI/CD를 담당하고 있다면, 배포 전에 미러 사용 가능 여부를 검증하도록 속도 측정 스크립트를 파이프라인에 통합하세요. 한밤중에 이미지 pull 실패로 알림을 받는 일을 줄일 수 있습니다.

마지막으로 이 글이 도움이 됐다면 팀이나 개발자 커뮤니티에 공유해도 좋습니다. Docker 미러 문제는 꽤 흔하고, 아직도 많은 사람이 수동으로 미러를 바꾸고 있습니다. 누군가의 시간을 조금 아껴줄 수 있을 것입니다.