Models.dev, 모델 선택을 데이터 문제로 바꾸다

Models.dev는 AI 모델의 스펙, 가격, 기능을 모으는 오픈소스 데이터베이스다. README는 models.dev를 “AI model specifications, pricing, and capabilities”를 위한 포괄적 데이터베이스라고 설명하며, API JSON을 통해 모델 ID를 조회할 수 있다고 안내한다. 저장소는 2025년 6월 공개됐고, 2026년 5월 22일 기준 GitHub API에서 별 약 3,943개와 fork 약 986개가 확인된다. 데이터는 AI SDK의 모델 ID와 연결되고, 프로젝트는 opencode 내부에서도 쓴다고 밝힌다.

이 뉴스가 중요한 이유는 모델 선택이 더 이상 브랜드 비교가 아니기 때문이다. 기업은 GPT, Claude, Gemini, Qwen, Mistral, 오픈소스 모델을 작업별로 섞어 쓴다. 컨텍스트 길이, vision 지원, tool calling, structured output, 가격, rate limit, 지역 규정이 모두 다르다. Gemini 3.5 Flash, 에이전트 속도전의 신호탄과 Qwen3.7-Max, 에이전트 장기 실행 경쟁의 신호탄을 비교하려면 최신 표가 필요하고, 그 표는 블로그 글보다 API로 제공되는 데이터에 가까워야 한다.

모델 카탈로그가 인프라가 되는 순간

과거에는 “가장 좋은 모델 하나”를 고르면 충분했다. 지금은 다르다. 요약은 저렴한 모델, 코드 리뷰는 강한 추론 모델, 이미지 이해는 멀티모달 모델, 긴 로그 분석은 장문 컨텍스트 모델을 쓰는 식으로 라우팅한다. 이때 가격표와 기능표가 틀리면 비용 예측과 품질 평가가 모두 흔들린다. Models.dev는 사람에게 보이는 웹사이트이면서 동시에 프로그램이 읽는 데이터 소스라는 점에서 에이전트 인프라에 가깝다.

경쟁 구도: 모델 허브보다 메타데이터 허브

Hugging Face가 모델 파일과 커뮤니티의 허브라면, Models.dev는 상용·오픈 모델을 실제 앱에서 호출할 때 필요한 운영 메타데이터를 겨냥한다. OpenRouter, LiteLLM, Vercel AI SDK 같은 계층도 비슷한 문제를 다루지만, Models.dev의 포지션은 실행 프록시가 아니라 공개 데이터베이스다. Forge, 작은 로컬 모델을 에이전트로 쓰는 법처럼 로컬 모델까지 섞는 흐름에서는 이런 중립 데이터가 더 중요해진다.

한국 기업의 시사점

국내 기업은 모델 도입에서 단가, 개인정보, 지연시간, 품질을 함께 본다. 그러나 내부 문서가 오래되면 “어느 모델이 얼마였더라”라는 기억이 구매와 아키텍처 결정을 좌우한다. Models.dev 같은 공개 데이터는 내부 FinOps 대시보드, RAG 라우터, 에이전트 정책 엔진의 초기 테이블로 쓸 수 있다. 단, 가격과 기능은 공급자 변경에 따라 바뀌므로 운영에서는 캐시 날짜와 검증 절차를 함께 저장해야 한다. Semble, 에이전트 코드 검색의 토큰세를 줄이다가 다룬 토큰 비용 문제도 결국 이런 데이터와 연결된다.

결론

Models.dev의 메시지는 단순하다. AI 모델이 많아질수록 선택은 취향이 아니라 데이터 파이프라인이 된다. 모델 카탈로그를 코드로 읽고 테스트로 검증하는 팀이 비용과 품질을 더 빠르게 조정할 수 있다.

FAQ

Models.dev는 무엇인가?

AI 모델의 스펙, 가격, 기능, 모델 ID를 모으는 오픈소스 데이터베이스다.

왜 API가 중요한가?

앱이나 에이전트 라우터가 최신 모델 정보를 자동으로 읽어 비용과 기능에 따라 호출 대상을 바꿀 수 있기 때문이다.

가격 정보만 보면 충분한가?

아니다. 컨텍스트 길이, 멀티모달 지원, tool calling, structured output 같은 기능도 함께 봐야 한다.

국내 기업이 그대로 써도 되나?

초기 기준표로는 유용하지만, 실제 계약 단가와 지역 규정, 보안 요구사항은 내부 데이터로 보정해야 한다.

장기적으로 어떤 시장을 만들까?

모델 라우팅, 비용 최적화, 평가 자동화, 에이전트 정책 엔진의 공통 메타데이터 계층으로 확장될 수 있다.