허깅페이스 인기 데모 1000개를 세어 보니 823개가 같은 도구였어요 — 스트림릿은 9개뿐이에요
허깅페이스 Spaces 상위 1000개를 공개 API로 받아 SDK와 마지막 수정일, 메타데이터 결측을 전수로 셌어요. gradio가 82.3%였고 27.6%는 마지막 수정 연도가 2024년 이하였어요.
AI 기술을 누구나 쉽게 활용할 수 있도록 실전 가이드를 작성합니다. ChatGPT, Claude, AI 자동화, SEO 분야를 전문으로 다룹니다.
AI 도구를 직접 서버에 올리려고 하면 결국 도커 이미지 이름을 적는 자리에서 막혀요. docker pull 뒤에 무엇을 적어야 하는지, 그게 몇 기가바이트인지, 맥에서도 도는지가 화면만 봐서는 잘 안 보여요.
그래서 한 번에 세어 봤어요.
2026년 9월 8일 오전 10시 24분에서 10시 31분 사이(한국 시각)에 도커 허브 공개 API를 370번 불러서, AI 셀프호스팅에 쓰는 이미지 저장소 40개를 조회했어요. 결과부터 적을게요. 이 40개 중 latest 태그가 있는 건 33개, 없는 건 7개였어요. 그리고 latest가 있는 33개 중 arm64 매니페스트가 붙은 건 26개였어요.
이 글이 재는 자리를 먼저 못박을게요. 인증 토큰 없이 열리는 공개 창구만 불렀고, 이미지를 한 장도 내려받지 않았고, 컨테이너를 한 번도 실행하지 않았어요. 그러니까 아래 용량은 전부 레지스트리가 신고한 압축 크기이지 제 디스크에서 잰 값이 아니에요.
![]()
| 항목 | 값 |
|---|---|
| 자료 | 도커 허브 공개 REST API v2 |
| 인증 | 없음 |
| 조회한 저장소 | 40개 |
| 네트워크 호출 | 370번 |
| 조회 일시 | 2026년 9월 8일 오전 10시 24분에서 10시 31분 사이(한국 시각) |
| 보조 확인 | 깃허브 컨테이너 레지스트리 4건 |
저장소마다 세 가지를 불렀어요. 저장소 정보, latest 태그 정보, 그리고 최근 태그 목록이에요. 태그 목록은 한 번에 100개까지만 주기 때문에, 아키텍처 분포를 볼 때는 그 100개가 표본이라는 점을 계속 붙여 두고 읽어야 해요.
여기서 미리 밝혀 둘 게 하나 더 있어요. 이 40개는 제가 손으로 적은 후보 81개에서 추린 목록이에요. 도커 허브 전체를 훑어서 무작위로 뽑은 표본이 아니라, 지목한 40개를 전수로 센 거예요. 그래서 이 글에 나오는 모든 비율은 「이 40개 중」이라는 말을 떼면 틀린 문장이 돼요. 후보 81개 중 28개는 제가 짐작한 경로가 틀려서 404가 났는데, 그 도구들이 도커 허브 어딘가에 다른 이름으로 있을 가능성이 있어요. 없다고 쓸 수 없는 자리예요.
그리고 표에 적은 「프로젝트 공식」이라는 구분은 네임스페이스 이름이 프로젝트 이름과 같다는 뜻으로 제가 붙인 라벨이에요. 도커 허브가 발급하는 인증 배지를 확인한 게 아니에요. 이 구분을 「공식 인증을 받았다」로 읽으시면 안 돼요.
가장 먼저 걸린 게 이 대목이었어요. 문서를 보고 docker pull 명령을 그대로 옮겨 적었는데 안 받아지는 경우가 왜 생기는지가 여기서 설명돼요.
latest 태그를 지정해 부른 40번의 호출 중 200이 33번, 404가 7번이었어요. 이 7개가 어떤 상태인지를 따로 갈라 봤어요.
| 구분 | 개수 |
|---|---|
latest가 있음 | 33개 |
태그는 있는데 latest라는 이름만 없음 | 5개 |
| 태그 신고 개수가 0개 | 2개 |
태그는 멀쩡히 있는데 latest만 없는 곳이 5개예요. 이 다섯 곳의 태그 신고 개수는 각각 1,850개, 1,154개, 668개, 183개, 71개였어요. 태그가 1,850개나 있는데 그중에 latest라는 이름이 없는 거예요.
정말 그런지 확인하려고 다섯 곳의 최신 태그를 하나씩 골라 다시 불러 봤어요. 다섯 곳 모두 200으로 응답했어요. 예를 들어 nvidia/cuda는 13.3.1-cudnn-runtime-ubuntu24.04를 지정하니 2.11 GB짜리 amd64와 arm64 이미지가 그대로 나왔어요. pgvector/pgvector는 pg17-trixie가 155 MB로 응답했고요.
그러니까 이 5개는 이미지가 없는 게 아니라 이름을 지정하는 방식이 다른 것이에요. 버전을 명시하도록 강제하는 구성이라 오히려 재현성 쪽에서는 나은 선택일 수 있어요. 다만 문서를 그대로 복사해 붙이는 사람에게는 한 번 막히는 자리예요.
남은 2개는 태그 신고 개수가 0이었어요. 여기가 이 조사에서 제일 조심해야 하는 대목이라 따로 파 봤어요.
| 저장소 | 상태값 | 등록일 | 최종 갱신 | 내려받기 수 | 태그 |
|---|---|---|---|---|---|
mlflow/mlflow | initialized | 2019-03-29 | 2019-03-29 | 0 | 0개 |
bitnami/mlflow | active | 2023-09-28 | 2025-08-27 | 746,890 | 0개 |
두 곳은 사정이 달라요. mlflow/mlflow는 2019년에 이름만 만들어 두고 한 번도 푸시가 없었던 껍데기예요. 내려받기 수가 0회인 게 그 증거고요. 반면 bitnami/mlflow는 746,890회나 내려받혔던 실재하는 이미지였는데 지금은 태그가 0개예요.
옛 태그들이 어디로 갔는지도 찾아봤어요. bitnamilegacy/mlflow에 321개가 그대로 남아 있고 최종 갱신이 2025-08-29예요. 사라진 게 아니라 옮겨진 거예요. 같은 네임스페이스의 bitnami/pytorch는 2026-09-05까지 갱신되고 있으니 그 네임스페이스 전체가 죽은 것도 아니고요.
그리고 여기가 이 글에서 제일 중요한 교정이에요. 도커 허브의 mlflow/mlflow가 비어 있다고 해서 MLflow에 컨테이너 이미지가 없는 게 아니에요. 깃허브 컨테이너 레지스트리 쪽 ghcr.io/mlflow/mlflow를 익명 토큰으로 조회해 보니 latest를 포함해 태그가 최소 100개 있었어요.
| 경로 | 응답 | 첫 쪽 태그 수 | latest |
|---|---|---|---|
ghcr.io/mlflow/mlflow | 200 | 100 | 있음 |
ghcr.io/open-webui/open-webui | 200 | 100 | 있음 |
ghcr.io/berriai/litellm | 200 | 100 | 있음 |
ghcr.io/deepset-ai/haystack | 403 | 확인 불가 | 확인 불가 |
마지막 줄도 그대로 읽어야 해요. 403은 「이미지가 없다」가 아니라 「익명으로는 목록을 볼 수 없다」예요. 없다고 쓰면 틀려요.
그래서 이 절에서 확인된 문장은 여기까지예요. 도커 허브 쪽 저장소가 비어 있고, 실제 이미지는 다른 레지스트리에 있거나 익명으로는 확인할 수 없다. 도구를 못 찾았다고 포기하기 전에 다른 레지스트리를 한 번 보는 게 실무에서 바로 쓸 수 있는 결론이에요.
덧붙이자면 이 글은 도커 허브만 전수로 봤고 깃허브 컨테이너 레지스트리는 4건만 찔러 봤어요. quay.io나 nvcr.io, 각 클라우드 사업자의 레지스트리는 아예 보지 않았어요.

맥을 쓰신다면 이 절이 제일 궁금하실 거예요.
latest가 있는 33개의 플랫폼 목록을 세어 보니 arm64가 붙은 게 26개, amd64만 있는 게 7개였어요.
amd64만 있는 7개는 infiniflow/ragflow, pytorch/pytorch, tensorflow/tensorflow, paddlepaddle/paddle, huggingface/transformers-pytorch-gpu, rocm/pytorch, intel/intel-extension-for-pytorch예요. 뒤의 여섯은 딥러닝 프레임워크와 GPU 기반 이미지고요. 채팅 화면이나 벡터 데이터베이스처럼 응용 쪽에 가까운 도구들은 대체로 arm64가 함께 올라와 있었어요.
여기서 중요한 유보를 하나 붙일게요. arm64 매니페스트가 붙어 있다는 것과 애플 실리콘에서 잘 돈다는 것은 다른 이야기예요. 이 글은 컨테이너를 한 번도 실행하지 않았어요. 그래서 실제 동작 여부도, 속도도, 안정성도 말할 수 없어요. 확인된 건 레지스트리에 그 아키텍처용 이미지가 올라와 있다는 사실까지예요.
그리고 latest만 보면 놓치는 게 있어요. 최근 태그 100개까지 넓혀 보면 arm64가 한 번이라도 나오는 저장소는 이 40개 중 30개예요. latest에는 arm64가 없는데 다른 태그에는 있는 곳이 4개 있었어요.
| 저장소 | latest 아키텍처 | 최근 태그 100개 |
|---|---|---|
infiniflow/ragflow | amd64 | amd64, arm64 |
deepset/haystack | latest 없음 | amd64, arm64 |
pgvector/pgvector | latest 없음 | amd64, arm64 |
nvidia/cuda | latest 없음 | amd64, arm64 |
latest 하나만 보고 「이건 맥에서 못 쓴다」고 접으면 네 번 중 네 번이 성급한 판단이 되는 셈이에요. 태그 목록을 한 번 더 열어 보는 게 나아요.
다만 이 표의 오른쪽 칸은 최근 태그 100개 표본에서 나온 값이에요. 저장소가 신고한 전체 태그 개수와 섞어 읽으면 안 돼요. 앞 칸은 정확한 값이고 뒤 칸은 표본이에요.
플랫폼을 세다가 예상 밖의 값이 나왔어요. latest가 있는 33개 중 10개는 플랫폼 목록에 unknown/unknown 항목이 섞여 있어요.
이건 실행 가능한 플랫폼이 아니라 빌드 증명 기록이에요. 화면에서 플랫폼 개수를 그냥 세면 지원 아키텍처가 실제보다 많아 보이게 돼요. 「이 이미지는 세 가지 플랫폼을 지원한다」고 읽었는데 실제로는 둘인 경우가 이 자리에서 생겨요.
최근 태그 100개 목록에서도 운영체제와 아키텍처가 모두 빈 항목이 섞인 저장소가 2개 있었어요. 자동으로 세는 스크립트를 만드신다면 이 두 종류를 먼저 걸러 내야 숫자가 맞아요.
latest가 있는 33개의 amd64 압축 크기를 오름차순으로 세워 봤어요.
| 구간 | 개수 |
|---|---|
| 500 MB 미만 | 14개 |
| 0.5 GB 이상 | 19개 |
| 1 GB 이상 | 14개 |
| 2 GB 이상 | 9개 |
| 5 GB 이상 | 4개 |
| 10 GB 이상 | 2개 |
qdrant/qdrant)rocm/pytorch)같은 「AI 도커 이미지」라는 말 안에서 398배가 벌어져요. 벡터 데이터베이스인 qdrant/qdrant가 71 MB, semitechnologies/weaviate가 87 MB, 검색 쪽인 searxng/searxng가 94 MB예요. 반대쪽에는 huggingface/transformers-pytorch-gpu 12.92 GB와 rocm/pytorch 27.47 GB가 있고요.
그래서 「AI 도구는 무겁다」는 한 문장은 이 자료로는 성립하지 않아요. 무거운 건 GPU 기반 이미지와 딥러닝 프레임워크 쪽이고, 응용 도구 쪽은 500 MB 미만이 14개예요. 무엇을 올리느냐에 따라 필요한 디스크가 완전히 달라져요.
여기에도 유보가 붙어요. 이 값들은 레지스트리가 신고한 압축 크기예요. 실제로 내려받아 압축을 푼 뒤 디스크가 얼마나 차는지는 이 글이 재지 않았고, 그 값은 위 숫자보다 커요. 그래서 이 글에서는 「설치하면 몇 GB를 쓴다」가 아니라 내려받는 양이 몇 GB다로만 적었어요.
모델 파일 쪽 용량이 궁금하시면 올라마 라이브러리 219개의 모델 용량을 전수로 잰 글에 따로 정리해 뒀어요. 이미지 용량과 모델 용량은 더해져서 디스크에 쌓이는 값이라 함께 보시는 게 좋아요.
같은 latest 태그에서 두 아키텍처를 모두 잴 수 있는 곳이 26쌍이었어요. 둘을 비교해 보니 22쌍은 arm64가 더 작았고 4쌍은 더 컸어요.
| 저장소 | amd64 | arm64 | 차이 |
|---|---|---|---|
marqoai/marqo | 7.14 GB | 1.40 GB | -80.4퍼센트 |
onerahmet/openai-whisper-asr-webservice | 2.51 GB | 1.65 GB | -34.4퍼센트 |
ollama/ollama | 3.45 GB | 2.60 GB | -24.6퍼센트 |
openwebui/open-webui | 1.70 GB | 1.54 GB | -9.1퍼센트 |
qdrant/qdrant | 71 MB | 70 MB | -0.8퍼센트 |
milvusdb/milvus | 1.06 GB | 1.07 GB | +1.7퍼센트 |
vllm/vllm-openai | 8.04 GB | 9.04 GB | +12.4퍼센트 |
가장 벌어진 곳은 marqoai/marqo로 arm64가 80.4퍼센트 작았어요. 7.14 GB가 1.40 GB로 줄어드는 폭이에요. 반대쪽은 vllm/vllm-openai로 arm64가 12.4퍼센트 더 컸고요.
이 차이가 왜 생기는지는 이 글이 단정하지 않을게요. 이미지 안 레이어를 열어 보지 않았거든요. 확인된 건 같은 태그라도 아키텍처에 따라 내려받는 양이 다르고, 그 폭이 저장소마다 제각각이라는 사실까지예요.
실무로 옮기면 이렇게 돼요. 다른 사람이 적어 둔 용량을 보고 계획을 세우실 때 그 값이 어느 아키텍처의 값인지를 확인하셔야 해요. 80퍼센트 차이가 나는 저장소가 실제로 있으니까요.

태그 개수를 세다가 자릿수가 달라지는 곳이 나왔어요.
| 저장소 | 신고 태그 수 |
|---|---|
semitechnologies/weaviate | 86,284 |
rayproject/ray | 64,878 |
localai/localai | 45,780 |
langgenius/dify-api | 23,068 |
milvusdb/milvus | 20,565 |
40개 저장소의 신고 태그 수 합계는 302,905개예요. 그런데 태그 목록 창구는 전체 개수를 알려 주면서 실제로는 한 번에 100개까지만 줘요. 한 호출로 다 받아진 저장소는 이 40개 중 9개뿐이었어요. 나머지 31개는 페이지를 넘겨야 전부 볼 수 있어요.
여기서 반드시 갈라 둬야 할 게 있어요. 「전체 태그 개수」는 창구가 신고한 값이고, 「아키텍처 분포」는 최근 100개 표본에서 나온 값이에요. 이 둘을 한 문장에 섞어 쓰면 표본에서 본 것을 전체에 대한 주장으로 부풀리게 돼요. 이 글에서도 두 값은 서로 다른 절에 나눠 적었어요.
태그가 8만 개라는 건 화면에서 눈으로 고르는 게 사실상 불가능하다는 뜻이기도 해요. 이런 저장소는 원하는 버전 규칙을 먼저 정해 두고 그 형태에 맞는 태그를 찾아 들어가는 편이 빨라요.
같은 조사를 약 57초 간격으로 두 번 돌려서 필드 단위로 대조해 봤어요.
| 대조 항목 | 결과 |
|---|---|
latest 태그 응답 상태 | 40개 전부 동일 |
latest 플랫폼 목록 | 40개 전부 동일 |
latest 아키텍처별 크기 | 40개 전부 동일 |
| 태그 신고 총개수 | 40개 전부 동일 |
| 내려받기 수 | 21개에서 증가 |
구조에 해당하는 값은 전부 같았고, 내려받기 수만 40개 중 21개가 움직였어요. 1분도 안 되는 사이에요. pgvector/pgvector가 753회, n8nio/n8n이 224회, searxng/searxng가 151회 늘었어요.
그래서 이 글에서 내려받기 수를 인용하실 때는 조회 시각을 함께 적어 두시는 게 맞아요. 참고로 이 40개의 내려받기 수 합계는 13억 3,239만 회였고 가장 많은 곳은 n8nio/n8n으로 2억 5,689만 회였어요. 전부 2026년 9월 8일 오전 10시 25분 기준 값이에요.
한 가지 더 못박아 둘게요. 여기서 말할 수 있는 건 57초 간격 두 번의 호출에서 구조 필드가 같았다는 것까지예요. 하루 뒤나 한 주 뒤에도 같다는 뜻이 아니에요. 태그는 언제든 추가되고 이름도 바뀔 수 있어요.
여기까지 센 값을 실제로 쓰는 순서로 정리해 볼게요.
첫째, latest가 있는지부터 확인해요. 이 40개 중 7개는 없었어요. 없으면 태그 목록을 열어 최신 태그를 직접 골라야 해요. 문서에 적힌 명령을 그대로 복사해 붙였는데 안 받아진다면 대체로 이 자리예요.
둘째, 아키텍처를 latest 하나로 판단하지 않아요. latest에는 amd64만 있어도 다른 태그에는 arm64가 있는 저장소가 4개 있었어요. 그리고 매니페스트가 있다는 것이 정상 동작을 보장하지는 않으니, 결국 한 번은 직접 띄워 보셔야 해요.
셋째, 용량은 아키텍처와 함께 읽어요. 같은 태그에서 80퍼센트까지 차이가 나요. 그리고 이 글의 값은 압축 크기라서 실제 디스크 점유량은 더 커요.
넷째, 도커 허브에서 못 찾았다고 접지 않아요. 다른 레지스트리에 있는 경우가 실제로 있었고, 익명으로는 목록을 못 보는 경우도 있었어요.
다섯째, 플랫폼 개수를 눈으로 세지 않아요. unknown/unknown이 섞인 저장소가 33개 중 10개예요.
처음 셀프호스팅을 해 보시는 거라면 로컬 LLM과 Open WebUI 설치 가이드부터 보시는 게 순서가 맞아요. 서비스를 올려 두고 쓰는 흐름 자체가 낯설다면 도커 컨테이너로 셀프호스팅하는 과정에 그 순서를 따로 적어 뒀어요.
정직하게 적어 둘게요.
세 줄로 줄이면 이래요.
첫째, 이 40개 중 7개는 latest가 없어요. 그중 5개는 태그 자체는 있고 이름만 없는 경우라, 최신 태그를 직접 지정하면 200으로 받아졌어요.
둘째, latest가 있는 33개 중 26개에 arm64가 붙어 있어요. amd64만 있는 7개는 대부분 딥러닝 프레임워크와 GPU 기반 이미지고요. 다만 매니페스트가 붙어 있다는 것이지 맥에서 잘 돈다는 확인은 아니에요.
셋째, 용량은 398배 벌어져요. 71 MB부터 27.47 GB까지고 중앙값은 747 MB예요. 500 MB 미만도 14개, 1 GB 이상도 14개라 한쪽으로 정리되지 않아요.
이미지 이름을 적기 전에 태그 목록을 한 번 열어 보시는 것만으로 대부분 정리돼요. latest가 없어서 막히는 경우도, 아키텍처를 잘못 판단하는 경우도 그 화면에서 걸러지거든요. 도커 허브에서 안 보인다면 그때는 다른 레지스트리를 한 번 보시면 되고요.
이 40개 중 7개는 latest 자체가 없어서 그렇게 적으면 받아지지 않아요. 다만 그 7개 중 5개는 태그 자체는 멀쩡히 있고 latest라는 이름만 없는 경우예요. 실제로 그 저장소의 최신 태그를 하나씩 지정해 다시 불러 보니 다섯 곳 모두 200으로 응답했어요. 2026년 9월 8일 오전 조회 기준이고, 태그 구성은 언제든 바뀔 수 있어요.
latest 태그에 arm64 매니페스트가 붙어 있는지를 보면 돼요. 이 글에서는 latest가 있는 33개 중 26개에 붙어 있었어요. 다만 매니페스트가 붙어 있다는 것과 실제로 잘 돈다는 것은 다른 이야기예요. 이 글은 컨테이너를 한 번도 실행하지 않았기 때문에 애플 실리콘에서의 동작이나 성능은 말할 수 없어요.
이 40개 중에서는 7개였고, 그중 여섯이 딥러닝 프레임워크와 GPU 기반 이미지였어요. 다만 latest에만 없는 것이지 다른 태그에도 없다는 뜻은 아니에요. 최근 태그 100개까지 넓혀 보면 latest에는 arm64가 없는데 다른 태그에는 있는 저장소가 4개 있었어요.
이 글의 용량은 전부 레지스트리가 신고한 압축 크기라서 「내려받는 양」이에요. 압축을 푼 뒤 실제로 차지하는 용량은 이보다 커요. 이 글은 이미지를 한 장도 내려받지 않았기 때문에 디스크 점유량은 재지 못했어요.
latest가 있는 33개 안에서 최소가 71 MB, 최대가 27.47 GB로 398배 차이가 났어요. 중앙값은 747 MB이고 33개를 합치면 85.7 GB예요. 1 GB 이상이 14개인데 500 MB 미만도 14개라, 「AI 이미지는 무겁다」는 한 문장으로는 정리되지 않아요.
아니에요. 이 조사에서 태그 0개로 나온 두 곳 중 한 곳은 같은 이름의 이미지가 깃허브 컨테이너 레지스트리에 latest를 포함해 최소 100개 올라와 있었어요. 도커 허브 쪽 저장소가 비어 있다는 것까지만 확인된 사실이고, 이미지가 없다고 읽으면 틀려요.
제가 손으로 적은 후보 81개 중 도커 허브에 실재하는 53개를 추린 다음, AI 스택 셀프호스팅에 쓰는 40개를 대상으로 삼았어요. 도커 허브 전체에서 무작위로 뽑은 표본이 아니라 지목한 40개의 전수예요. 그래서 이 글의 비율은 전부 「이 40개 중」으로만 읽으셔야 해요.