오픈소스 AI 현황, 모델보다 생태계가 경쟁력이다

공개 가중치만으로는 부족해졌다

State of Open Source AI는 오픈소스 AI를 둘러싼 논쟁이 성숙 단계로 들어갔다는 신호다. 초기에는 "모델 가중치를 내려받을 수 있는가"가 핵심 질문이었다. 이제는 데이터셋, 학습 코드, 평가 절차, 라이선스, 추론 비용, 보안 업데이트, 커뮤니티 거버넌스가 함께 묶여야 기업이 실제로 도입할 수 있다.

이 변화는 Open Source Initiative의 Open Source AI Definition 논의와도 이어진다. 공개 모델이라고 부르는 대상이 정말 수정·재학습·재배포 가능한지, 아니면 단지 무료 추론 파일인지 구분해야 하기 때문이다. Hugging Face가 말한 오픈 AI 전환 비용에서 본 것처럼, 오픈 생태계의 비용은 누군가가 계속 떠안아야 한다.

기업 도입의 기준은 신뢰 가능한 공급망이다

기업은 모델 성능표만 보고 오픈소스 AI를 쓰지 않는다. 보안 패치가 언제 나오는지, 라이선스가 상업 이용과 파생 모델 배포를 허용하는지, 데이터 출처 문제가 없는지, 특정 국가 규제나 고객 계약에 걸리지 않는지를 본다. Linux Foundation AI & Data나 MLCommons 같은 조직이 중요한 이유도 여기에 있다. 모델 경쟁이 커질수록 공통 평가와 공급망 표준이 필요해진다.

한국 기업에는 이 지점이 기회다. 자체 프런티어 모델을 만들지 않더라도, 산업별 평가셋, 개인정보 비식별 파이프라인, 온프레미스 배포 패키지, 한국어 업무 벤치마크를 만들 수 있다. 30papers AI 학습 로드맵이 말하듯 학습의 병목은 도구보다 지식 구조에 있다. 오픈 모델도 마찬가지다. 모델을 내려받는 것보다 조직의 업무 언어로 검증하는 일이 더 어렵다.

오픈 모델의 경제학은 하이브리드다

오픈소스 AI가 클라우드 프런티어 모델을 완전히 대체한다는 주장은 과장이다. 실제 기업 환경에서는 난도별 라우팅이 더 현실적이다. 민감 데이터가 포함된 초안, 분류, 검색, 반복 요약은 로컬 또는 전용 인프라의 오픈 모델이 처리하고, 복잡한 추론이나 최종 검토는 상용 모델로 보낸다. Bonsai 27B 로컬 에이전트도 같은 비용 곡선을 보여준다.

이때 핵심은 모델 선택기가 된다. 어떤 요청은 작은 모델로 충분하고, 어떤 요청은 비싼 모델로 승격해야 한다. 오픈 모델을 많이 쓰는 조직일수록 평가 하네스, 캐시, 프롬프트 버전 관리, 실패 로그가 중요해진다. 그래서 오픈소스 AI 시장은 모델 제공자만의 경쟁이 아니라 관측성, 보안, 배포 자동화, 데이터 계약의 경쟁으로 넓어진다.

정책 논쟁도 세분화가 필요하다

오픈소스 AI 정책은 안전과 혁신 사이의 단순한 선택이 아니다. 생물·사이버·사기 악용 가능성이 있는 고성능 모델과, 교육·연구·지역 언어 보존에 필요한 공개 모델을 같은 잣대로 다루면 양쪽 모두 실패한다. NIST AI RMF는 위험을 맥락별로 나눠 보라고 제안한다. 오픈 모델에도 이 접근이 필요하다.

한국 정부와 공공기관은 공개 모델을 단순히 "국산 LLM" 조달 문제로 축소하면 안 된다. 공공 데이터셋 품질, 저작권 정리, 한국어 평가셋, 민간 재사용 조건, 보안 인증 경로를 함께 만들어야 한다. 그렇게 해야 스타트업이 모델 자체가 아니라 모델 위의 응용과 검증 계층에서 사업을 만들 수 있다.

자주 묻는 질문

Q1: 오픈소스 AI와 오픈웨이트 AI는 같은 말인가요?

A: 아니다. 오픈웨이트는 가중치 공개에 가깝고, 오픈소스 AI는 데이터·코드·수정 가능성·재배포 조건까지 포함해야 한다는 논의가 커지고 있다.

Q2: 기업은 왜 오픈 모델을 쓰나요?

A: 비용, 데이터 통제, 커스터마이징, 특정 산업 용어 대응 때문이다. 다만 유지보수와 보안 책임을 함께 감수해야 한다.

Q3: 한국어 모델에는 어떤 기회가 있나요?

A: 대형 범용 모델보다 법률, 제조, 의료, 공공문서처럼 평가 가능한 도메인 모델과 데이터셋이 더 현실적인 기회다.

Q4: 오픈 모델은 안전하지 않나요?

A: 모델과 용도에 따라 다르다. 공개 자체보다 배포 맥락, 접근 통제, 악용 모니터링, 패치 체계가 안전성을 좌우한다.

Q5: 개발팀은 무엇을 준비해야 하나요?

A: 모델 카드, 라이선스 검토, 벤치마크, 프롬프트 회귀 테스트, 실패 로그를 하나의 운영 파이프라인으로 묶어야 한다.