로컬에서 모델을 돌려 보려고 내려받기를 눌렀는데 파일 대신 이런 안내가 뜬 적 있으실 거예요. 연락처 정보를 공유하는 데 동의해야 접근할 수 있다는 문구요. 스크립트를 돌리던 중이면 더 당황스러워요. 목록에는 분명히 있었는데 파일 단계에서만 죽거든요.
그래서 얼마나 흔한 일인지 세어 봤어요.
결론부터 적을게요. 허깅페이스 다운로드 상위 1,000개 중 승인이 필요한 모델은 37개예요. 그중 자동 승인이 14개, 사람이 검토하는 수동 승인이 23개고요. 나머지 963개는 그냥 받아져요.
이 글이 재는 자리를 먼저 못박을게요. 공개 API 가 주는 메타데이터의 승인 설정 값만 봐요. 허브 전체를 센 게 아니라 많이 내려받는 1,000개 안에서 셌어요. 승인까지 걸리는 시간이나 거절 비율은 공개 지표가 없어서 재지 못했어요. 잰 것은 문이 걸려 있느냐와 그 문이 어떤 종류냐까지예요.

어떻게 쟀는지 먼저 밝힐게요
| 항목 | 값 |
|---|
| 자료 | 허깅페이스 공개 모델 API 와 공식 문서 저장소 원문 |
| 인증 | 없음. 토큰도 쓰지 않았어요 |
| 요청한 페이지 | 10회 (100개씩) |
| 받은 모델 | 1,000개 |
| 중복 | 0건 |
| 정렬 기준 | 다운로드 많은 순 |
| 조회 일시 | 2026년 9월 3일 오후 (한국 시각) |
한 가지 먼저 밝혀 둘게요. 다운로드 수는 최근 30일 기준 값이에요. 누적 횟수가 아니라서 순위가 계속 움직여요. 그리고 여기 나오는 비율은 허브 전체가 아니라 상위 1,000개 안의 비율이에요. "허브의 3.7퍼센트가 승인제"라고 읽으시면 틀려요.
1,000개 중 37개, 그런데 상위 100위 안에 8개
전체 분포부터 볼게요.
| 구분 | 개수 | 비율 |
|---|
| 승인 없이 받아짐 | 963개 | 96.3% |
| 자동 승인 | 14개 | 1.4% |
| 수동 승인 | 23개 | 2.3% |
| 승인제 합계 | 37개 | 3.7% |
숫자만 보면 드문 일 같아요. 그런데 순위 구간으로 갈라 보면 위쪽에 몰려 있어요.
| 구간 | 승인제 개수 |
|---|
| 1위부터 100위 | 8개 |
| 101위부터 200위 | 2개 |
| 201위부터 300위 | 3개 |
| 301위부터 400위 | 4개 |
| 401위부터 500위 | 3개 |
| 501위부터 600위 | 4개 |
| 601위부터 700위 | 7개 |
| 701위부터 800위 | 1개 |
| 801위부터 900위 | 2개 |
| 901위부터 1000위 | 3개 |
여기서 조심할 게 있어요. 위로 갈수록 승인제가 많아지는 단조 경향은 아니에요. 601위부터 700위 구간에도 7개가 있어요. 확실히 말할 수 있는 것은 상위 100위 안에 8개가 있다는 사실까지예요.
체감이 실제보다 큰 이유가 여기 있어요. 전체로는 3.7퍼센트인데, 처음 손대게 되는 유명한 모델일수록 걸려 있을 확률이 높거든요.
다운로드 총량으로도 재 봤어요. 1,000개 합계가 23억 7,876만여 회이고 그중 승인제 몫이 7,387만여 회예요. 3.11퍼센트로, 개수 비율과 크게 다르지 않았어요.
상위 100위 안 8개를 다 적어 둘게요
| 순위 | 방식 | 모델 |
|---|
| 40위 | 자동 | 화자 분리 모델 (pyannote) |
| 67위 | 수동 | 라마 3.2 1B 인스트럭트 |
| 71위 | 자동 | 음성 구간 분할 모델 (pyannote) |
| 72위 | 수동 | 라마 3.1 8B 인스트럭트 |
| 79위 | 자동 | 화자 분리 커뮤니티판 (pyannote) |
| 87위 | 자동 | 음성 구간 분할 구판 (pyannote) |
| 93위 | 자동 | 음성 활동 검출 모델 (pyannote) |
| 95위 | 수동 | 프롬프트 가드 86M |
눈에 띄는 게 하나 있어요. 8개 중 5개가 한 조직 것이에요. 음성 처리 계열인 pyannote 인데, 회의록이나 자막을 다루는 도구가 안에서 흔히 쓰는 모델이에요. 승인제가 큰 언어 모델만의 이야기가 아니라는 뜻이에요.
자동 승인과 수동 승인은 다른 문이에요
여기서 많이 헷갈려요. 공식 문서에 적힌 대로 정리할게요.
자동 승인은 기본값이에요. 이용자가 이름과 이메일 주소를 저자와 공유하는 데 동의하면 그 순간 열려요. 저자를 기다릴 필요가 없어요.
수동 승인은 저자가 직접 검토해요. 요청은 대기, 승인, 거절 세 목록으로 관리돼요.
그리고 가장 중요한 대목이 여기예요.
거절되면 다시 요청할 수 없어요. 문서 원문이 그렇게 적혀 있어요. 거절 사유는 최대 200자까지 이용자에게 보여요. 그래서 회사 이름이나 용도를 묻는 양식을 대충 채워 넣는 게 생각보다 위험해요. 한 번 거절당하면 그 계정으로는 되돌리기 어려워요.
또 하나. 승인은 조직이 아니라 개인에게만 부여돼요. 문서에 명시돼 있어요. 회사 대표 계정으로 한 번 승인받아 두면 팀 전체가 쓸 수 있을 것 같지만 그렇지 않아요. 팀원마다 각자 요청하고 각자 동의해야 해요.

승인 없이 받으면 실제로 어떻게 되나
말로만 두지 않고 직접 요청해 봤어요. 로그인하지 않은 상태로 파일 주소를 그대로 불렀어요.
| 요청한 것 | 응답 |
|---|
| 라마 3.2 1B 인스트럭트 설정 파일 (수동) | 401 |
| 젬마 3 1B 설정 파일 (수동) | 401 |
| 플럭스 1 dev 설정 파일 (자동) | 401 |
| 음성 분할 모델 설정 파일 (자동) | 401 |
| 승인 불필요 모델 설정 파일 (대조군) | 200 |
응답 헤더에 오류 코드가 GatedRepo 로 찍혔고, 본문에는 접근이 제한돼 있으니 로그인하라는 문구가 왔어요.
여기서 두 가지를 확인했어요.
첫째, 자동 승인이라고 그냥 받아지는 게 아니에요. 자동이든 수동이든 비로그인 응답은 똑같이 401 이었어요. 자동 승인이 뜻하는 것은 동의를 누른 뒤 저자를 기다리지 않아도 된다는 데까지예요.
둘째, 메타데이터는 막히지 않아요. 같은 모델의 정보 조회 주소는 200 으로 열려 있었어요. 모델 카드도 파일 목록도 보여요. 파일만 막혀요. 목록이 보이니 당연히 받아질 거라 여기고 스크립트를 돌리면, 준비 단계는 멀쩡히 지나가고 실제 내려받기에서만 죽는 이유가 이거예요.
어느 조직이 문을 걸어 두나
상위 1,000개 안에서 세어 봤어요.
| 조직 | 상위 1,000개 안 | 그중 승인제 |
|---|
| 메타 (meta-llama) | 12개 | 12개 |
| 구글 (google) | 47개 | 9개 |
| pyannote | 7개 | 6개 |
| 메타 연구 (facebook) | 29개 | 3개 |
| 블랙포레스트랩스 | 4개 | 3개 |
| 엔비디아 | 33개 | 2개 |
메타의 라마 계정은 이 표본 안에 든 12개가 전부 승인제예요. 조직 전체가 그렇다고까지는 못 적어요. 상위 1,000개 안에서 12개가 전부 그랬다는 뜻이에요.
반대로 구글은 47개 중 9개만 걸려 있어요. 같은 회사 모델이어도 계정과 계열에 따라 갈려요.
용도별로도 갈렸어요. 승인제 37개 중 글 생성 계열이 15개로 가장 많았고, 이미지를 읽고 답하는 계열이 6개, 음성 인식 계열이 3개였어요.
같은 계열인데 승인이 필요 없는 것도 있어요
이름에 같은 단어가 들어간 모델을 갈라 세어 봤어요.
| 이름에 포함 | 승인제 | 승인 불필요 |
|---|
| 젬마 | 9개 | 58개 |
| 라마 | 12개 | 14개 |
| 플럭스 | 3개 | 5개 |
| pyannote | 6개 | 1개 |
젬마 계열은 승인 불필요가 58개나 돼요. 대부분 다른 사람이 올린 양자화본이나 미세조정본이에요. 반대로 pyannote 는 승인 불필요가 1개뿐이에요.
여기서 꼭 붙여야 할 유보가 있어요.
이 표를 우회 경로로 읽으시면 안 돼요. 이름이 비슷하다고 같은 파일이 아니고, 무엇보다 라이선스 의무는 내려받은 자리가 아니라 가중치를 따라가요. 원본이 비상업 조건이면 다른 사람이 올린 사본을 받아도 그 조건이 사라지지 않아요. 파생본은 원본과 조건이 같을 수도 다를 수도 있으니 각 모델 카드를 따로 확인하셔야 해요.
쓸 수 있느냐를 가르는 라이선스 쪽은 상위 1,000개 모델의 라이선스 태그를 센 글에 따로 정리해 뒀어요. 이 글은 받을 수 있느냐만 봐요. 두 가지는 다른 문제예요.

AI 모델 접근 요청, 막히기 전에 알아 두면 좋은 것
- 먼저 로그인부터 하세요. 토큰만 만들어 두는 것과 접근 요청을 넣는 것은 다른 단계예요. 토큰이 있어도 요청을 안 넣었으면 막혀요.
- 요청은 브라우저에서만 됩니다. 공식 문서에 그렇게 적혀 있어요. 명령줄로는 요청 자체가 안 들어가요.
- 양식을 성의 있게 채우세요. 수동 승인 모델에서 거절되면 다시 요청할 수 없어요.
- 팀이라면 인원수만큼 요청하세요. 승인은 개인 단위로만 부여돼요.
- 자동 승인이라도 로그인은 필요해요. 자동은 기다림이 없다는 뜻이지 문이 없다는 뜻이 아니에요.
- 스크립트에 넣기 전에 파일 한 개를 먼저 받아 보세요. 목록 조회는 200 이 나와도 파일은 401 일 수 있어요.
모델 크기를 먼저 가늠하고 싶으시면 올라마 라이브러리 219개 용량을 전수로 잰 글이 도움이 될 거예요.
확인하지 못한 것
정직하게 적어 둘게요.
- 허브 전체를 세지 않았어요. 다운로드 상위 1,000개 안에서만 셌어요. 전체 비율은 이 글이 모릅니다.
- 승인까지 걸리는 시간을 재지 않았어요. 저자마다 다르고 공개 지표가 없어요.
- 거절 비율을 모릅니다. 저자만 볼 수 있는 값이에요.
- 데이터셋과 스페이스는 보지 않았어요. 모델만 셌어요.
- 각 모델의 라이선스 조건을 판단하지 않았어요. 문이 걸려 있는지만 봤어요.
- 실제로 승인을 요청해 보지는 않았어요. 비로그인 응답까지만 확인했어요.
정리
승인이 필요한 모델은 상위 1,000개 중 37개로 드문 편이에요. 그런데 상위 100위 안에만 8개가 있어서 체감은 훨씬 커요. 처음 손대게 되는 유명한 모델일수록 걸려 있거든요.
자동 승인 14개와 수동 승인 23개는 다른 문이에요. 자동은 동의만 하면 그 자리에서 열리고, 수동은 사람이 봐요. 그리고 수동에서 거절되면 다시 요청할 수 없어요.
기억해 두실 것은 두 줄이에요. 로그인하고 브라우저에서 요청하세요. 그리고 팀이면 각자 하세요. 이 두 가지만 알아도 대부분의 막힘은 지나갑니다.