오픈소스 모델 고를 때 다운로드 수를 믿으면 안 되는 이유

다운로드 수를 보고 골랐다가 멈칫한 날

로컬에서 돌릴 오픈소스 모델을 하나 고르려고 허깅페이스를 뒤지던 날이었습니다. 처음엔 정렬 기준을 다운로드 수에 뒀습니다. 제일 많이 받은 게 제일 검증된 것 아니겠냐는, 앱스토어 별점 보듯 하는 습관이었습니다. 그런데 받아서 몇 개 돌려보니 숫자와 체감이 따로 놀았습니다. 가장 많이 받힌 축에 드는 파생 모델이 오히려 이상하게 굴었습니다.

그때부터 다운로드 수 말고 무엇을 봐야 하나를 정리하기 시작했습니다. 결론부터 말하면 저는 두 개의 축으로 봅니다. 하나는 공개 범위, 하나는 손상도입니다.

축 1 · 공개 범위 — 가중치만 준 건가, 만드는 법까지 준 건가

오픈소스라고 올라오는 모델 상당수는 사실 완성된 가중치 파일 하나만 줍니다. 결과물은 손에 쥐어지지만, 그게 어떤 데이터로 어떻게 학습됐는지는 알 수가 없습니다. 문제가 생겨도 원인을 추적할 방법이 없고, 재현도 검증도 남의 말에 기대야 합니다.

반대 사례도 봤습니다. 국내 기업 비드래프트가 공개한 모델은 가중치만 던지지 않았습니다. 학습 데이터 레시피, 전체 학습 코드, 하이퍼파라미터, 학습 로그, 중간 체크포인트, 평가 코드까지 같이 열었습니다. 허깅페이스에서 받을 수 있고 라이선스는 아파치 2.0이라 상업적 사용도 가능합니다. 다만 솔직하게 덧붙이면, 성능 벤치마크 수치는 아직 붙지 않았습니다. 그래서 “성능이 좋다”는 판단은 아직 이릅니다. 여기서 제가 눈여겨본 건 성능이 아니라 공개 방식 자체였습니다.

그래서 완전 공개형인지 가려내는 실무 기준은 단순합니다.

• 가중치 말고 학습 코드와 로그가 같이 있는가를 본다.

이게 있으면 문제가 났을 때 안을 열어볼 수 있고, 없으면 블랙박스를 신뢰로만 쓰는 셈입니다. 1인 개발자 입장에서 나중에 디버깅 비용을 생각하면 이 차이는 꽤 큽니다.

축 2 · 손상도 — 파생 튜닝은 다운로드 수와 품질이 따로 논다

두 번째 축은 파생 모델 이야기입니다. 누군가 base 모델을 가져다 튜닝해서 올린 것들 말입니다. 여기서 다운로드 수를 믿으면 특히 위험합니다.

Gemma 4 계열 파생 23개를 base와 하나씩 비교한 벤치마크를 봤습니다. 결과가 인상적이었습니다. 가장 많이 받힌 모델, 다운로드가 80만 회 근처였던 그 모델이 가장 망가져 있었습니다. 검열을 지우는 과정에서 손을 너무 크게 대는 바람에, 거부해야 할 상황에서 거부 자체를 못 하는 지경까지 갔습니다. 사람들이 많이 받은 이유와 그 모델이 멀쩡한지는 완전히 별개였던 셈입니다.

그래서 파생 모델을 고를 때 저는 두 지표를 봅니다.

• base 대비 출력 분포 변화(KL)가 낮을수록 원래 역량을 더 지킵니다.
• 전체 719개 텐서 중 손댄 텐서가 적을수록 부작용이 작습니다.

같은 검열 우회라도 방식이 다릅니다. heretic 계열은 이 방식으로, 즉 최소한만 정밀하게 건드리는 방식으로 우회율 95% 선을 내면서도 원래 분포를 크게 흔들지 않았습니다. 넓게 뭉개서 목적을 달성한 것과, 좁게 정밀하게 달성한 것은 결과물의 온전함이 다릅니다. 다운로드 수에는 이 차이가 전혀 드러나지 않습니다.

정리 — 받은 횟수는 선택 기준이 못 된다

두 축을 다시 붙여 보면 이렇습니다. 공개 범위는 “나중에 안을 열어볼 수 있는가”를, 손상도는 “튜닝이 원래 역량을 얼마나 지켰는가”를 봅니다. 둘 다 다운로드 수로는 보이지 않는 것들입니다.

특정 모델을 우열로 단정하려는 글은 아닙니다. 쓰임새에 따라 답은 갈립니다. 다만 한 가지는 분명합니다. 다운로드 수는 품질이 아니라 홍보 노출을 따라갑니다. 많이 받힌 데는 대체로 이유가 있지만, 그 이유가 “품질이 좋아서”라는 보장은 어디에도 없습니다. 적어도 받은 횟수 하나만 놓고 고르는 건, 제가 겪어 본 바로는 선택 기준이 되지 못했습니다.

---

이런 실무 기준을 정리한 글을 종종 씁니다. 혼자 개발하며 부딪힌 판단 기준들을 뉴스레터로 모아 보내니, 관심 있으시면 구독으로 이어 보셔도 좋겠습니다.