F1.1～F1.5, 25편의 흩어진 모델을 한자리에

F01의 단백질 구조 예측 역사부터 F24의 LoRA 미세조정까지, 우리는 다섯 개의 소주제(§F1.1 구조 예측, §F1.2 오픈 구조·도킹·MD, §F1.3 단백질 언어모델, §F1.4 DNA/RNA 파운데이션 모델, §F1.5 세포 파운데이션 모델)를 거쳐왔습니다. 이 모델 중 다수는 HuggingFace Hub에서 찾거나 배포할 수 있지만, 일부는 저자 저장소·전용 API·별도 배포 경로만 제공합니다. F25에서는 허브를 출발점으로 삼되, 공식 배포 경로까지 확인하는 실무 지도를 그립니다.

원리 — 모델 허브를 안전하게 탐색하는 기준

모델 카드가 알려주는 것과 알려주지 않는 것

HuggingFace의 각 모델 페이지에는 **모델 카드(model card)**가 딸려 있습니다. 여기에는 아키텍처 개요, 학습 데이터, 라이선스, 벤치마크 수치, 사용 예시 코드가 담기지만, 그 내용의 정확성과 최신성은 저장소를 관리하는 주체(원 저자, 커뮤니티 포팅 등)에 따라 편차가 큽니다. F16～F23을 거치며 우리가 자주 만든 {/* VERIFY */} 표시를 실무에서도 똑같이 적용해야 합니다 — 모델 카드의 벤치마크 수치는 원 논문과 대조해 확인하고, 라이선스는 반드시 원문 그대로 재확인해야 합니다.

세 갈래로 나눠보는 선택 기준

이 시리즈에서 만난 25개 모델을 실무 선택 기준으로 재분류하면 다음과 같은 표로 정리할 수 있습니다.

손 계산 예제: 라이선스 조합의 위험

F12에서 다뤘던 ESM3처럼 비상업 제한이 있는 모델을, F24에서 다룬 LoRA로 미세조정해 사내 서비스에 배포하려 한다고 가정해봅시다. 미세조정으로 학습한 LoRA 가중치 자체는 새로 만든 산출물이지만, 그 가중치는 원본 사전학습 가중치(비상업 라이선스) 없이는 작동하지 않습니다.

$\text{배포 가능 여부} = \text{LoRA 가중치 라이선스} \ \cap\ \text{원본 사전학습 가중치 라이선스}$

두 라이선스의 교집합이 상업적 사용을 허용하지 않으면, 아무리 미세조정을 잘해도 상업 배포는 불가능합니다. 이 판단은 매번 원문 라이선스 텍스트를 직접 확인해야 하며, 모델 카드의 요약 문구만 보고 단정해서는 안 됩니다.

실습: HuggingFace Hub API로 F1 시리즈 모델 메타데이터 일괄 확인

# Colab T4, 무료 티어. huggingface_hub 라이브러리는 로그인 없이도
# 공개 모델의 메타데이터를 조회할 수 있습니다.

from huggingface_hub import HfApi

api = HfApi()

# F1 시리즈에서 다룬 모델들의 실제 저장소 경로는 공식 발표에 따라
# 갱신될 수 있으므로, 아래는 조회 절차를 보여주는 예시 목록입니다.
candidate_repo_ids = [
    "facebook/esm2_t12_35M_UR50D",  # F11 ESM-2 계열 예시
    # 나머지 F01～F25 관련 저장소는 실제 최신 경로를 허브 검색으로 확인 후 채웁니다.
]

for repo_id in candidate_repo_ids:
    try:
        info = api.model_info(repo_id)
        print(f"{repo_id}")
        print(f"  라이선스 태그: {info.card_data.get('license') if info.card_data else 'N/A'}")
        print(f"  최근 다운로드: {info.downloads}")
        print(f"  최근 업데이트: {info.lastModified}")
    except Exception as e:
        print(f"{repo_id} 조회 실패: {e}")

이 스크립트의 핵심은 "모델을 다운로드하기 전에 라이선스 태그와 최근 업데이트 시점을 코드로 먼저 확인하는 습관"입니다. 특히 라이선스는 모델 카드 갱신 이력에 따라 바뀌기도 하므로, 프로젝트에 편입하는 시점마다 재확인하는 것이 안전합니다.

CS 매핑

• 패키지 레지스트리와 의존성 관리: HuggingFace Hub에서 모델을 고르고 라이선스·버전을 확인하는 절차는, npm이나 PyPI 같은 패키지 레지스트리에서 의존성의 라이선스와 버전 호환성을 점검하는 소프트웨어 공급망 관리와 본질적으로 같은 작업입니다.
• 메타데이터 기반 신뢰도 판단: 다운로드 수·최근 업데이트 시점·모델 카드 완성도로 신뢰도를 가늠하는 것은 오픈소스 라이브러리를 채택하기 전 GitHub 스타 수·이슈 활성도·최근 커밋 이력을 확인하는 관행과 동일한 논리입니다.
• 라이선스 교집합 판단: 여러 구성요소(사전학습 가중치 + 미세조정 어댑터)의 라이선스를 조합해 전체 배포 가능성을 판단하는 것은 소프트웨어 라이선스 호환성(license compatibility) 분석의 표준 절차입니다.

자주 만나는 결함

• 모델 카드의 벤치마크 수치를 검증 없이 인용: 커뮤니티 포팅 저장소의 벤치마크는 원 논문과 다른 설정에서 재현된 경우가 흔합니다. 중요한 의사결정에 쓰기 전 원 논문 표와 대조해야 합니다.
• 비상업 라이선스 모델을 사내 서비스에 무심코 편입: F12의 ESM3처럼 비상업 제한이 있는 모델은 연구·프로토타이핑 단계에서는 문제가 없더라도, 실제 서비스 배포 전에 법무·라이선스 검토가 반드시 필요합니다.

더 깊게 파고 싶다면

본문은 BPD 연구진이 직접 재구성한 서술입니다. 원 논문과 공식 자료로 심화해봅시다.

• HuggingFace Hub 공식 문서: 모델 카드 작성 가이드라인과 API 레퍼런스.
• 오픈소스 라이선스 비교: MIT · Apache 2.0 · CC BY 4.0 등 각 라이선스 원문(Open Source Initiative 공식 텍스트).
• F01～F24 각 편의 "더 깊게 파고 싶다면" 절 — 이 25편에서 다룬 모든 원 논문 목록의 총합입니다.

F1 Fullstack 티어(Foundation Model + AI, 25편)를 모두 마쳤습니다. 다음 소주제(F26～F35, MLOps + 인프라)에서는 이 파운데이션 모델들을 실제 파이프라인에 편입시키는 Pixi·Snakemake·Nextflow 같은 실무 도구로 시선을 옮깁니다.