🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

허깅페이스는 기존 사용자의 작업 방식을 유지하는 브리지와 무중단 백그라운드 마이그레이션을 기반으로, 50만 개 저장소와 20페타바이트 규모의 허브를 깃 대용량 파일 저장소에서 젯으로 전환하고 있다.

📌 핵심 요약

• 허깅페이스는 허브의 인공지능 작업량이 기존 깃 대용량 파일 저장소의 확장 한계를 넘어섬에 따라, 콘텐츠 주소 기반 저장소와 러스트 클라이언트를 기반으로 하는 젯 저장 체계로 전환했다.
• 전환 과정에서는 일괄적인 강제 변경을 피하고, 하나의 저장소가 젯 파일과 기존 대용량 파일을 함께 포함하며, 업로드와 다운로드를 중단하지 않은 채 백그라운드에서 마이그레이션할 수 있도록 설계했다.
• 젯을 지원하지 않는 기존 클라이언트의 요청은 깃 대용량 파일 브리지가 단일 파일 방식으로 변환하고, 기존 방식으로 업로드된 파일은 분산 큐와 작업자 파드를 거쳐 젯의 콘텐츠 주소 기반 저장소로 옮겨진다.
• 약 500테라바이트 규모의 초기 대형 마이그레이션에서 임시 파일 누적, 콘텐츠 주소 기반 저장소의 자원 부족, 네트워크와 블록 저장장치 입출력 병목이 드러났으며, 소프트웨어 패치와 인프라 확장으로 처리량을 크게 높였다.
• 젯은 신규 사용자와 조직의 기본 저장 방식이 되었으며, 기존 저장소도 순차적으로 전환된다. 다만 저장 용량 표시는 물리적 중복 제거량이 아니라 파일과 리비전의 논리적 크기를 기준으로 계산된다.

🧩 주요 포인트

1. 허깅페이스는 허브의 인공지능 작업량이 기존 깃 대용량 파일 저장소의 확장 한계를 넘어섬에 따라, 콘텐츠 주소 기반 저장소와 러스트 클라이언트를 기반으로 하는 젯 저장 체계로 전환했다.
2. 전환 과정에서는 일괄적인 강제 변경을 피하고, 하나의 저장소가 젯 파일과 기존 대용량 파일을 함께 포함하며, 업로드와 다운로드를 중단하지 않은 채 백그라운드에서 마이그레이션할 수 있도록 설계했다.
3. 젯을 지원하지 않는 기존 클라이언트의 요청은 깃 대용량 파일 브리지가 단일 파일 방식으로 변환하고, 기존 방식으로 업로드된 파일은 분산 큐와 작업자 파드를 거쳐 젯의 콘텐츠 주소 기반 저장소로 옮겨진다.
4. 약 500테라바이트 규모의 초기 대형 마이그레이션에서 임시 파일 누적, 콘텐츠 주소 기반 저장소의 자원 부족, 네트워크와 블록 저장장치 입출력 병목이 드러났으며, 소프트웨어 패치와 인프라 확장으로 처리량을 크게 높였다.
5. 젯은 신규 사용자와 조직의 기본 저장 방식이 되었으며, 기존 저장소도 순차적으로 전환된다. 다만 저장 용량 표시는 물리적 중복 제거량이 아니라 파일과 리비전의 논리적 크기를 기준으로 계산된다.

🧠 상세 정리

1. 깃 대용량 파일 저장소를 넘어선 허브의 성장

허깅페이스 젯 팀은 2025년 1월 새로운 저장 백엔드를 배포한 뒤 초기에는 허브 다운로드의 약 6퍼센트만 새 인프라로 처리했다. 이후 6개월 동안 약 50만 개 저장소와 20페타바이트의 데이터가 젯 전환에 참여했으며, 기사 공개 시점에는 허브 사용자 100만 명 이상이 젯을 사용하고 있었다. 2025년 5월부터는 신규 사용자와 조직에 젯이 기본값으로 적용되었고, 이처럼 큰 규모의 변경에도 보고된 문제는 깃허브 이슈, 포럼 글, 디스코드 메시지를 모두 합쳐 수십 건 정도였다. 허깅페이스는 이러한 전환의 배경으로 인공지능 개발자가 다루는 대규모 모델과 데이터셋의 작업량이 증가하면서 기존 깃 대용량 파일 저장소만으로는 허브의 성장을 감당하기 어려워졌다는 점을 제시한다.

2. 강제 전환을 피한 세 가지 설계 원칙

마이그레이션 계획의 핵심 원칙은 기존 방식에서 젯으로 한 번에 넘어가는 강제 전환을 만들지 않는 것이었다. 젯이 활성화된 하나의 저장소 안에도 젯 파일과 기존 대용량 파일이 함께 존재할 수 있어야 했으며, 저장소를 옮기는 동안 별도의 잠금을 걸어 업로드나 다운로드를 중단해서도 안 됐다. 허깅페이스는 사용자가 즉시 작업 절차를 바꾸거나 새 클라이언트를 설치하도록 요구하지 않는 것을 커뮤니티에 대한 중요한 약속으로 보았다. 이 원칙은 구현 복잡성을 높였지만, 이용자가 현재 사용하는 브라우저, 깃, 구형 라이브러리를 그대로 유지한 상태에서 인프라가 내부 전환을 담당하도록 만들었고, 결과적으로 수페타바이트의 데이터를 며칠 단위로 이동하면서도 허브 이용에 미치는 영향을 줄였다.

3. 젯 지원 클라이언트의 청크 기반 전송

최신 허깅페이스 허브 라이브러리에 통합된 젯 지원 클라이언트를 사용하면 업로드와 다운로드가 젯의 전체 처리 경로를 통과한다. 업로드할 때 클라이언트는 콘텐츠 정의 청킹 방식으로 파일을 여러 조각으로 나누고, 만들어진 청크를 콘텐츠 주소 기반 저장소로 전달해 객체 저장소에 보관한다. 다운로드할 때는 콘텐츠 주소 기반 저장소가 파일 재구성에 필요한 청크와 바이트 범위 정보를 제공하며, 클라이언트는 해당 범위를 요청해 로컬에서 원래 파일을 복원한다. 이 구조는 파일 전체를 매번 하나의 덩어리로 전송하는 기존 방식과 달리 실제로 필요한 콘텐츠 단위를 중심으로 데이터를 이동할 수 있게 하며, 변경된 데이터가 적은 경우 전송량과 처리 시간, 대역폭 및 연산 사용량을 줄이는 기반이 된다.

4. 기존 클라이언트를 위한 깃 대용량 파일 브리지

청크 기반 전송을 지원하지 않는 구형 허깅페이스 허브 라이브러리나 자바스크립트 클라이언트도 젯 저장소에서 파일을 계속 올리고 내려받을 수 있다. 이용자가 허브의 파일 조회 경로로 젯 기반 파일을 요청하면 깃 대용량 파일 브리지가 기존 프로토콜처럼 보이는 하나의 사전 서명 주소를 만들어 반환하고, 내부적으로는 객체 저장소에 보관된 콘텐츠를 재구성해 요청자에게 전달한다. 실제 경로에는 브리지 앞단의 콘텐츠 전송망, 파일 메타데이터를 관리하는 데이터베이스, 객체 저장소 등 여러 요소가 더 포함되지만, 사용자에게는 기존 단일 파일 다운로드와 비슷하게 보인다. 반대로 젯을 알지 못하는 클라이언트가 파일을 업로드하면 데이터는 먼저 기존 대용량 파일 저장소에 들어간 뒤 백그라운드 작업으로 젯에 옮겨지므로, 클라이언트 업그레이드 여부가 저장소 이용 가능성을 가르는 장벽이 되지 않는다.

5. 분산 큐로 수행되는 무중단 백그라운드 마이그레이션

기존 파일을 젯으로 옮겨야 할 때마다 웹훅이 발생하고, 해당 이벤트는 분산 큐를 통해 오케스트레이터로 전달된다. 오케스트레이터는 필요하면 저장소에서 젯을 활성화하고, 저장소에 있는 모든 대용량 파일의 리비전 목록을 조회한 다음 파일 수나 전체 크기를 기준으로 작업 묶음을 만든다. 한 묶음은 파일 1천 개 또는 500메가바이트 가운데 먼저 도달하는 한도를 따르며, 생성된 작업은 다시 별도의 큐에 배치되어 마이그레이션 작업자 파드가 처리한다. 각 작업자는 목록에 포함된 기존 파일을 내려받아 젯 핵심 라이브러리로 콘텐츠 주소 기반 저장소에 다시 업로드하며, 이 체계는 십수 페타바이트가 넘는 모델과 데이터셋을 옮기고 약 50만 개 저장소를 젯 저장소와 동기화하는 데 사용되었다.

6. 대형 저장소 전환에서 드러난 세 가지 병목

허깅페이스는 2025년 4월 약 2천 개 저장소와 500테라바이트에 가까운 데이터를 보유한 바토프스키의 마이그레이션을 통해 시스템의 한계를 시험했다. 전역 중복 제거에 쓰이는 임시 샤드 파일이 임시 디렉터리와 젯 캐시 사이의 서로 다른 마운트 지점 때문에 정상적으로 이동되거나 삭제되지 않았고, 디스크가 가득 차면서 저장 공간 부족 오류가 연쇄적으로 발생했다. 또한 수백 개의 수기가바이트 업로드가 동시에 몰리자 다운로드 급증에 맞춰 확장해 두었던 콘텐츠 주소 기반 저장소의 자원이 부족해졌으며, 작업자 파드에서는 예상 처리량을 제한하는 네트워크와 블록 저장장치 입출력 병목도 확인되었다. 팀은 젯 핵심 라이브러리를 수정하고 콘텐츠 주소 기반 저장소의 용량을 늘리며 작업자 노드 사양을 강화했고, 이 경험을 바탕으로 1.7페타바이트와 2만5천 개 저장소, 6.1페타바이트와 4만2천 개 저장소를 보유한 대형 사용자들의 전환도 수행했다.

7. 처리량 향상과 마찰 없는 점진적 보급

초기 바토프스키 마이그레이션에서 콘텐츠 주소 기반 저장소는 초당 약 35기가비트를 지속 처리했으며, 그중 약 5기가비트는 평상시 허브 트래픽이었다. 이후 두 대형 사용자의 마이그레이션에서는 일상 트래픽 약 40기가비트를 계속 처리하면서 순간적으로 약 300기가비트까지 도달했고, 2025년 7월 기준 기본 처리량도 초당 100기가비트에 가까워졌다. 허깅페이스는 기존 이용자에게 피해를 주지 않으면서 가능한 한 빠르게 효과를 확대한다는 두 목표 아래, 젯 클라이언트를 먼저 안정화한 뒤 허브 라이브러리의 필수 의존성으로 포함했다. 모든 업로드 경로가 젯을 지원할 때까지 기다리거나 특정 작업 방식을 강요하는 대신, 이용자가 기존 절차를 유지하도록 두고 인프라가 점진적 전환을 흡수한 것이 대규모 이전을 조기에 시작할 수 있었던 핵심이었다.

8. 전체 사용자 확대와 저장 용량 표시의 의미

허깅페이스는 2025년 1월과 2월 고사용량 이용자를 먼저 참여시켜 인프라를 압박 시험하고 피드백을 받았으며, 이후 대기 명단을 운영한 뒤 신규 사용자에게 젯을 기본 적용했다. 다음 단계에서는 기존 사용자의 모든 저장소를 기존 대용량 파일 저장소에서 젯으로 옮기고, 새로 만드는 저장소도 기본적으로 젯을 사용하게 하며, 브라우저와 깃의 청크 기반 지원도 추가할 계획이라고 밝혔다. 최신 허깅페이스 허브 라이브러리를 설치하면 빠른 전송 기능을 바로 이용할 수 있지만, 업그레이드하지 않더라도 현재의 브라우저나 깃 작업 방식에는 제한을 두지 않는다. 기사 댓글에서 제기된 저장 용량 문제에 대해 작성자는 허브가 물리적으로 저장된 중복 제거 후 크기가 아니라 각 파일과 리비전의 논리적 크기 합계를 표시한다고 설명했으며, 이는 계산의 예측 가능성과 전역 중복 데이터의 소유권을 공정하게 배분하기 어려운 문제를 고려한 정책이다. 따라서 저장 용량 표시가 줄어들지는 않지만 실제 변경분만 전송함으로써 속도, 대역폭, 연산 사용량의 이점은 얻을 수 있고, 젯 프로토콜과 전체 인프라 스택을 공개 소스로 제공하는 작업도 후속 계획에 포함되어 있다.

🧾 핵심 주장 / 시사점

• 대규모 저장 시스템 전환의 핵심은 새 저장 엔진 자체뿐 아니라, 구형 클라이언트의 요청을 변환하는 브리지와 기존 데이터를 지속적으로 옮기는 백그라운드 파이프라인에 있었다.
• 500테라바이트 규모의 실제 마이그레이션은 임시 파일 수명 주기, 마운트 지점 차이, 저장소 자원, 네트워크와 입출력처럼 개별 시험만으로 드러나기 어려운 병목을 노출했고, 이후 처리량을 약 35기가비트에서 최대 약 300기가비트 수준으로 높이는 계기가 되었다.
• 젯의 전역 중복 제거는 물리적 저장과 전송 효율을 개선하지만, 허브의 용량 표시는 소유권과 예측 가능성을 위해 논리적 파일 크기를 기준으로 하므로 이용자에게 표시되는 할당량이 자동으로 감소하는 것은 아니다.

✅ 액션 아이템

• 허브 전체(50만 개 저장소) 전환에서 기존 사용성 연속성을 지키기 위해 브리지 기반 병행 저장소와 업로드·다운로드 무중단 원칙을 유지한다.
• 젯 미지원 클라이언트 요청은 단일 파일 변환 브리지를 거친 뒤 분산 큐와 작업자 파드로 전달되어 기존 LFS 자산이 누락 없이 젯 콘텐츠 주소 저장소로 이관되도록 절차를 점검한다.
• 500테라바이트 초도 이관에서 드러난 임시 파일 누적, 자원 부족, 네트워크·블록 I/O 병목에 대해 패치·인프라 조치 전후 성능 지표를 비교해 개선 효과를 검증한다.

❓ 열린 질문

• 백그라운드 마이그레이션 구간에서 업로드·다운로드를 중단하지 않으며 50만 저장소 전환을 끝내기 위한 성공 판정 기준은 무엇인가?
• 기존 방식으로 업로드된 파일이 큐와 작업자 파드 단계에서 지연 또는 실패할 때 재시도·재배치 우선순위와 허용 임계값은 어떻게 정할 것인가?
• 논리적 크기 기준으로 표시되는 저장 용량이 물리 중복 제거량과 다를 때 사용자 과금·사용량 안내에 어떤 비교 지표를 병행해 오해를 줄일 것인가?