전통 OSS와 오픈소스 AI 모델(OSM)의 협업이 어떻게 나뉘는지에 대한 연구(feat. CSCW26)

9bow · 7월 5, 2026, 9:30오전

OSS와 오픈소스 AI 모델, 같은 "오픈소스"가 맞을까

리눅스 커널이나 PostgreSQL 같은 오픈소스 소프트웨어(Open Source Software, OSS)를 떠올려 봅시다. 전 세계의 낯선 개발자들이 버그를 신고하고, 패치를 제출하고, 서로의 코드를 리뷰하며 하나의 결과물을 함께 키워 나갑니다. 우리가 흔히 "오픈소스 정신"이라고 부르는 것은 바로 이런 모습, 즉 누구나 들여다보고 고칠 수 있는 협업의 풍경입니다.

그런데 최근 우리가 "오픈소스"라고 부르는 대상이 하나 더 늘었습니다. 바로 LLaMA 2, Stable Diffusion, DeepSeek-R1 같은 오픈소스 AI 모델(Open Source AI Model, OSM) 입니다. 이 글에서 정리하는 논문 From OSS to Open Source AI: an Exploratory Study of Collaborative Development Paradigm Divergence는 바로 이 지점에서 출발합니다. 같은 "오픈소스"라는 이름을 달고 있지만, 코드가 아니라 모델 가중치를 공유하는 OSM의 협업 방식은 전통 OSS와 정말로 같을까요? 베이징대학교(Peking University) 연구팀은 "무언가 다른 일이 벌어지고 있다" 는 막연한 직관을 넘어, 이를 대규모 데이터로 실제 측정하고 그 원인까지 파고듭니다.

이 논문은 GitHub의 OSS 저장소 1{,}428{,}792 개와 Hugging Face(HF) Hub의 OSM 저장소 1{,}440{,}527 개를 수집해 협업의 양상을 정량적으로 비교하고, 여기에 전문가 10 명 심층 인터뷰를 더한 혼합 연구(mixed-methods study)입니다. 결론을 미리 말하면, OSS와 OSM의 협업 패러다임은 세 가지 핵심 차원에서 측정 가능할 만큼 뚜렷하게 갈라져 있었습니다. CSCW26(ACM Conference on Computer-Supported Cooperative Work and Social Computing)에 채택된 연구입니다.

전통 OSS가 성공한 세 가지 기둥

연구팀은 먼저 전통 OSS 패러다임이 성공해 온 토대를 세 가지로 정리합니다. 첫째는 분산 참여(distributed participation) 로, 지리적으로 흩어진 기여자들이 각자의 노력을 모아 집단 지성을 형성합니다. 둘째는 포용적 과정(inclusive processes) 으로, 소스 코드와 개발 과정이 모두 열려 있어 누구나 검사하고 수정하고 재배포할 수 있습니다. 셋째는 사용자 혁신(user innovation) 으로, 소프트웨어에서 직접 이득을 보는 사용자가 그 발전을 이끌면서 오늘의 사용자가 내일의 개발자가 되는 순환 고리가 만들어집니다.

이 세 기둥은 에릭 레이먼드(Eric Raymond)가 성당과 시장(The Cathedral and the Bazaar)에서 제시한 바자르(bazaar) 모델로 잘 알려져 있습니다. 소수의 엘리트가 닫힌 공간에서 완성품을 빚어내는 "성당"과 달리, 시끌벅적한 시장처럼 수많은 참여자가 동시에 뛰어들어 결과물을 다듬는다는 비유입니다. 그리고 이 시장의 무대가 된 곳이 바로 1 억 5{,}000 만 명이 넘는 개발자와 4 억 2{,}000 만 개가 넘는 저장소를 품은 GitHub입니다.

그런데 "공유하는 대상"이 바뀌었다

문제는 OSM이 공유하는 대상이 코드가 아니라는 데 있습니다. OSS가 "소스 코드 안에 담긴 구축 논리(building logic)" 를 공유한다면, OSM은 "학습의 결과물(training results)", 즉 모델 아키텍처와 가중치를 공유합니다. 게다가 학습 데이터와 전체 학습 과정은 공개되지 않는 경우가 많아, OSS보다 투명성이 떨어지는 경향이 있습니다.

연구팀은 이 차이가 단순한 형식의 문제가 아니라 협업의 사회기술적(socio-technical) 성격 자체를 바꿀 수 있다고 봅니다. 그래서 핵심 질문을 다음과 같이 던집니다. "OSS와 OSM 개발 패러다임은 측정 가능할 만큼 다른 협업 행동을 보이는가?" 그리고 이를 네 개의 연구 질문(RQ)으로 구체화합니다.

RQ1: 협업 강도(collaboration intensity)는 OSS와 OSM에서 어떻게 다른가?
RQ2: 협업 개방성(collaboration openness)은 어떻게 다른가?
RQ3: 사용자 혁신(user innovation)은 어떻게 다른가?
RQ4: 이런 차이를 만드는 사회기술적 요인은 무엇인가?

두 패러다임의 개발 파이프라인 비교

본격적인 측정에 앞서, 연구팀은 OSS와 OSM의 개발 과정을 각각 하나의 파이프라인으로 모델링합니다. 무엇을 측정해야 할지 감을 잡기 위한 예비 분석입니다.

OSS 파이프라인(위 그림)은 코드 중심으로 돌아갑니다. 핵심 개발 단계에서 내부 개발자는 커밋으로, 외부 개발자는 풀 리퀘스트(Pull Request)로 기여하며, 제안된 수정은 리뷰를 거쳐 통합됩니다. 중요한 것은 하류(downstream)의 흐름입니다. 배포된 버전을 받아 쓰던 사용자가 기능을 추가하거나 버그를 고친 뒤, 그 결과를 다시 상류(upstream)로 되돌려 보내는 순환 고리가 형성됩니다. 오늘의 사용자가 내일의 기여자가 되는 구조입니다.

반면 OSM 파이프라인(위 그림)에는 OSS에 없는 단계가 끼어 있습니다. 모델 아키텍처 구성과 더불어 데이터 수집, 전처리, 품질 검증으로 이어지는 데이터 엔지니어링(data engineering) 과 막대한 연산 자원이 드는 사전 학습 및 파인튜닝(fine-tuning) 과정입니다. 그리고 결정적으로, 하류 사용자는 모델을 배포해 추론에 쓰거나 API를 호출하거나, 도메인 요구가 생기면 공개된 모델을 출발점 삼아 추가 파인튜닝을 할 뿐, 원본 모델로 기여를 되돌려 보내는 경우가 드뭅니다. OSS의 순환 고리가 OSM에서는 끊겨 있는 셈입니다.

연구팀은 이 파이프라인 모델의 타당성을 검증하기 위해 경험 많은 실무자와 연구자를 대상으로 익명 설문을 진행했고, 일주일간 179 건의 유효 응답을 받았습니다. OSS 파이프라인에는 82.1\%, OSM 파이프라인에는 84.4\% 가 동의했으며, 명시적으로 반대한 응답자는 한 명도 없었습니다. 이 두 파이프라인의 차이가 바로 RQ1(협업 강도), RQ2(협업 개방성), RQ3(사용자 혁신)이라는 세 측정 축을 끌어냅니다.

어떻게 측정했는가

연구의 전체 흐름은 위 그림과 같습니다. 데이터 수집과 정제를 거쳐, 통계 분석, 소셜 네트워크 분석, 콘텐츠 분석을 수행한 뒤, 마지막에 반구조화 인터뷰(semi-structured interview)로 정량 결과의 배경을 해석하는 구조입니다.

데이터 수집 단계에서는 GitHub의 이벤트 스트림을 담은 GHArchive를 출발점으로 삼고, 잘리거나 빠진 텍스트는 REST API로 보완해 4 억 3{,}763 만여 개 저장소를 추출했습니다. HF Hub에서는 URL API로 데이터를 모으되, 접근 권한이 필요한 모델은 자동 요청 스크립트로 처리해 1{,}440{,}527 개 저장소를 수집했습니다.

데이터 정제 에서 두 가지 처리가 눈에 띕니다. 하나는 표본 균형(sample balancing) 입니다. HF Hub가 2016 년에 설립된 점을 고려해 2016 년 이전에 생성된 GitHub 저장소를 제외하고, 별(star) 수 기준 층화 무작위 표본 추출(stratified random sampling)로 OSM 표본과 비슷한 규모인 1{,}428{,}792 개 OSS 저장소를 맞췄습니다. 다른 하나는 봇 제거(bot dropping) 로, 사람의 상호작용만 남기기 위해 OSS에서 69{,}847 개, OSM에서 1{,}155 개의 봇 계정을 걸러냈습니다.

분석은 세 갈래로 진행됩니다. 첫째, 통계 분석 에서는 두 플랫폼이 공유하는 비교 가능한 지표를 강도 순으로 골랐습니다. 직접 기여를 뜻하는 커밋(commit), 프로젝트 이해와 지식 교환을 뜻하는 이슈/논의(issue/discussion), 단순 선호를 뜻하는 별/좋아요(star/like)가 그것입니다. 둘째, 소셜 네트워크 분석 에서는 저장소나 개발자를 노드로 두고 같은 개발자가 두 대상에 관여하면 엣지를 잇는 방식으로 네트워크를 구성했습니다. 셋째, 콘텐츠 분석 에서는 이슈/논의 텍스트의 주제를 분류했습니다.

콘텐츠 분석 방법은 특히 흥미롭습니다. 연구팀은 커밋 메시지를 쓰려다 포기했는데, OSS 표본의 커밋 2{,}363 만여 건 중 의미 있는 메시지는 3.46\% 에 불과했고 OSM도 5.52\% 에 그쳤기 때문입니다. 대신 이슈/논의 텍스트를 택했고, Claude 3.7 Sonnet 에 Chain-of-Thought(CoT) 프롬프팅을 적용해 초기 코딩을 수행한 뒤, 두 저자가 100 개 표본을 독립적으로 수작업 라벨링해 검증하는 사람 개입(human-in-loop) 워크플로우를 설계했습니다. 검증 결과 환각(hallucination)은 관찰되지 않았다고 보고합니다.

RQ1: 협업 강도는 100배 넘게 차이 난다

첫 번째 결과는 협업 강도입니다. 위 그림은 OSS와 OSM 저장소의 커밋 수 분포를 보여주는데, 두 분포 모두 한쪽으로 치우쳐 있지만 그 정도가 OSM에서 훨씬 심합니다. OSM에서는 절대다수 저장소가 극소수의 커밋과 논의만을 가지고, 소수의 저장소에 활동이 집중됩니다.

통계 수치는 그 격차를 적나라하게 드러냅니다. 저장소당 평균 커밋 수는 OSS가 1464.28 개인 반면 OSM은 10.65 개에 그쳤고, 평균 이슈/논의 수는 OSS가 35.94 개인데 OSM은 0.20 개에 불과했습니다. 별/좋아요도 OSS가 평균 142.78 개, OSM이 0.93 개였습니다. 모든 지표에서 활동량이 100 배 이상 벌어졌고, Mann-Whitney U 검정 결과 모든 비교가 p < 0.001 로 통계적으로 유의했습니다.

지표	평균	중앙값	최댓값
커밋 (OSS)	1464.28	24.00	71{,}860{,}646
커밋 (OSM)	10.65	2.00	65{,}092
이슈 (OSS)	35.94	0.00	1{,}607{,}850
논의 (OSM)	0.20	0.00	3{,}010
별 (OSS)	142.78	16.00	318{,}751
좋아요 (OSM)	0.93	0.00	10{,}194

네트워크 분석은 한 가지 반직관적인 장면을 보여주는데, 해석이 핵심입니다. 상위 10{,}000 개 저장소로 만든 저장소 커밋 네트워크 에서는 오히려 OSM의 노드 연결률(80.07\%)이 OSS(47.80\%)보다 높았습니다. 언뜻 OSM 협업이 더 활발해 보이지만, 의미는 정반대입니다. 저장소 간 엣지는 같은 개발자가 두 저장소에 모두 기여할 때 생기므로, OSM의 높은 연결률은 "영향력 있는 프로젝트 대부분이 동일한 소수 개발자 집단에 의해 개발된다" 는 신호입니다. 반대로 OSS의 낮은 연결률은 개발자 구성이 그만큼 다양하다는 뜻입니다.

반면 개발자를 노드로 둔 개발자 네트워크 에서는 OSS가 커밋과 이슈 양쪽에서 OSM보다 높은 연결률과 평균 차수(degree)를 보였습니다. 개발자 이슈 네트워크의 평균 차수만 봐도 OSS는 5880.94, OSM은 139.45 로 격차가 큽니다. 결국 OSS 생태계의 개발자들이 협력적 개발과 지식 교환 양면에서 훨씬 폭넓게 연결되어 있음을 보여줍니다.

RQ2: 직접 기여는 닫혀 있지만, 지식 교환은 열려 있다

두 번째 축은 협업 개방성입니다. 연구팀은 조직이 발행한 OSM 저장소를 골라 커밋과 논의 참여자의 소속을 분석했습니다. 그 결과 커밋 기여자의 79.55\% 가 발행 조직 소속이었고 19.36\% 는 HF 스태프로, 합치면 98.91\% 가 내부자였습니다. 외부 기여 비율은 고작 1.09\% 인 셈입니다. 비교를 위해, 선행 연구(Dias et al.)는 기업이 소유한 OSS 프로젝트에서도 외부 개발자 커밋이 56.7\% 에 달한다고 보고한 바 있습니다. 직접 기여의 개방성에서 두 패러다임의 간극이 얼마나 큰지 보여주는 대비입니다.

흥미로운 반전은 논의(discussion) 에서 나타납니다. 논의 참여자 중 발행 조직 소속은 9.01\% 에 불과했습니다. 즉 코드/가중치를 직접 고치는 일은 조직 내부에 닫혀 있지만, 질문하고 정보를 나누는 지식 교환의 장은 여전히 외부에 열려 있다는 뜻입니다.

이 패턴은 거시적으로도 확인됩니다. 연구팀은 위 그림처럼 OSM 사용자 네트워크에 Louvain 커뮤니티 탐지 알고리즘을 적용한 뒤, 알고리즘이 찾아낸 커뮤니티가 실제 조직 소속과 얼마나 겹치는지를 측정했습니다. 커밋 네트워크 에서는 그 일치도가 평균 49.8\% 에 달해, 기여 기반 협업 군집이 실제 조직과 상당 부분 포개졌습니다. 일부 조직은 HF Hub에 계정이 없어 관측조차 안 되므로 실제 값은 더 높을 것이라고 덧붙입니다. 반면 논의 네트워크 의 일치도는 9.2\% 에 그쳤습니다. 직접 기여는 조직 단위로 닫혀 있고 지식 교환은 열려 있다는 결론을, 같은 데이터의 두 측면에서 재확인한 셈입니다.

RQ3: "함께 고치기"에서 "가져다 쓰기"로

세 번째 축인 사용자 혁신은 커뮤니티의 대화 내용에서 드러납니다. 연구팀은 이슈/논의 텍스트를 다섯 가지 주제로 분류했습니다. 버그 리포트(bug report), 제안(suggestion), 사용법 문제(usage problem), 성능 평가(performance evaluation), 그리고 기타(others)입니다.

위 그래프가 보여주는 분포는 두 커뮤니티의 성격을 선명하게 가릅니다. OSS에서는 버그 리포트가 42.7\% 로 가장 많았고 제안이 28.2\% 로 뒤를 이었습니다. 코드베이스의 문제를 찾아 고치고 기능을 확장하는, 협업을 통한 개선에 대화가 집중된다는 뜻입니다. 반면 OSM에서는 사용법 문제가 40.0\% 로 가장 많았고 성능 평가가 22.3\% 로 두 번째였습니다. 모델 자체를 개선하기보다 어떻게 활용할지에 무게가 실린 것입니다.

연구팀은 이 차이를 두 가지 혁신 패턴으로 개념화합니다. OSS는 사용자가 직접 수정과 집단 문제 해결로 결과물을 키우는 협업적 개선 혁신(collaborative improvement innovation) 이고, OSM은 사용자가 베이스 모델을 건드리지 않은 채 새로운 응용을 발굴하고 하류 적응(파인튜닝 등)으로 가치를 만드는 적응적 활용 혁신(adaptive utilization innovation) 입니다.

중요한 점은, 적응적 활용도 분명한 혁신 가치를 만든다는 것입니다. 사용자들이 사용법 문제의 해법과 모델 평가 결과를 공유하면서 개인의 경험이 공공재로 전환되고, 모델의 한계와 최적 전략이 함께 드러납니다. 예를 들어 한 사용자는 Llama-3.1-8B-Instruct를 쓰면서 "채팅 템플릿으로 포맷한 입력보다 원본 프롬프트(시스템과 사용자 입력을 한 문자열로 이은 것)가 더 잘 작동한다" 는 관찰을 공유했습니다. 또 다른 사용자는 "모델을 로컬 엑셀 스프레드시트에 연결해 맞춤형 감성 분석 도구를 만들었다" 고 했습니다. 이처럼 모델을 새로운 시스템에 결합하는 재조합 혁신(recombinant innovation) 이 OSM 생태계의 한 축을 이룹니다.

RQ4: 무엇이 이 분기를 만드는가

마지막으로 연구팀은 인텔, 마이크로소프트 등 기업과 학계, 독립 커뮤니티를 아우르는 전문가 10 명(P1 ~ P10 )을 인터뷰해 그 배경 요인을 네 갈래로 정리합니다. 참여자들은 앞선 정량 결과가 자신들의 실무 경험과 일치한다고 확인해 주었습니다.

기술적, 구조적 장벽

가장 근본적인 요인은 모델이라는 산출물 자체의 성질입니다. 첫째, 추적 가능성의 상실(loss of traceability) 입니다. 텍스트 소스 코드는 줄 단위 변경으로 논리를 추적할 수 있지만, 모델 가중치는 줄 단위 구분이 없는 이진 객체입니다. P1은 "소프트웨어 코드에는 명확한 논리가 있지만, 모델 가중치는 데이터 파일에 가깝고 사람이 읽을 수 있는 줄 단위 갱신 특성이 없는 블랙박스" 라고 표현합니다. P4는 한발 더 나아가 "변경이 추적 가능해야 하는데, 추적이 안 되면 어떻게 협업을 말할 수 있겠는가" 라고 반문합니다.

둘째, 구조적 비분해성(structural non-decomposability) 입니다. 소프트웨어는 모듈로 나뉘어 분산 팀이 독립적으로 개발할 수 있지만, 모델은 구조가 촘촘히 얽혀 있어 그렇지 못합니다. P3의 말처럼 "트랜스포머의 특정 레이어를 독립된 팀들에 나눠 맡길 수는 없습니다." 셋째, 재현 불가능성과 확률성(irreproducibility and stochasticity) 입니다. 학습이 환경 요인과 랜덤 시드에 민감해 학습 상태를 완벽히 재현하기 어렵고, 재현이 안 되면 외부 기여자가 자신의 개선을 검증할 길이 막혀 협업의 피드백 고리가 끊깁니다.

자원 제약

두 번째 요인은 자원의 벽입니다. 모델을 검증하거나 학습하는 일은 재정적으로나 연산적으로나 막대한 비용이 듭니다. P8은 이를 연산의 벽(compute wall) 이라 부르며, "우리 회사는 작년에 5 억 달러 이상을 투자했고 그중 70\% 가 연산에 쓰였습니다. 개인 기여자는 그런 참여를 감당할 수 없습니다" 라고 말합니다. 여기에 데이터 접근 불가(data inaccessibility) 가 겹칩니다. 고품질 학습 데이터는 점점 더 독점 자산으로 취급되고, 초기 데이터 수집에 외부 크라우드소싱을 쓰더라도 이후의 "데이터 플라이휠(data flywheel)" 과정은 철저히 내부에 머뭅니다. 데이터가 모델 학습의 토대인 만큼, 데이터 접근 불가는 외부 기여를 사실상 차단합니다.

인프라와 도구의 불일치

세 번째 요인은 플랫폼입니다. GitHub가 협업 생산을 위한 작업장이라면, HF 같은 플랫폼은 완성된 모델을 배포하는 레지스트리(registry)에 가깝습니다. P6은 "GitHub가 협업 생산의 작업장 역할을 한다면, HF는 주로 완성된 모델을 배포하는 레지스트리로 작동한다" 고 짚습니다. 또한 표준 버전 관리 도구는 거대한 이진 가중치를 다루기에 부적합해, 협업이 메타데이터 수준에 머물고 모델 자체의 집단적 정제로 나아가지 못합니다. P7의 말처럼 "효과적인 버전 관리 없이는 진정한 협업 개발에 필요한 세밀함에 도달할 수 없습니다."

기업의 전략적 요인

마지막 요인은 기업 전략입니다. OSM에서 오픈소스는 커뮤니티 가치에 대한 헌신이라기보다 시장 경쟁과 생태계 확장을 위한 전략적 선택인 경우가 많습니다. P9은 "스타트업은 모델 API를 주력 상품으로 팔기 때문에 모델을 오픈소스로 풀 가능성이 낮습니다. 대기업은 팔 수 있는 다른 서비스가 있지만, 작은 회사에게는 모델 그 자체가 가진 전부" 라고 설명합니다. 또한 연산, 데이터, 알고리즘에 걸쳐 기여를 분리해 측정하기 어렵다는 크레딧 할당(credit assignment) 문제도 있습니다. P5의 말처럼 "소프트웨어는 코드 줄 수(LoC)로 크레딧을 잴 수 있지만", 모델은 그렇지 못해 명확한 수익 배분이나 소유권 정의가 거의 불가능합니다.

OSM 협업을 어떻게 끌어올릴 것인가

연구팀은 진단에서 멈추지 않고 OSM 협업을 개선할 경로도 제시합니다.

첫째, 레시피를 통한 투명성의 실무화 입니다. 완전한 재현이 어렵다면, 데이터 큐레이션 논리와 하이퍼파라미터 설정, 환경 명세를 담은 학습 레시피(training recipe)를 표준 패키지로 공유해 "원클릭 재현" 에 다가가자는 제안입니다.

둘째, 모듈성의 모방 입니다. PEFT(Parameter-Efficient Fine-Tuning)나 모델 병합(model merging) 같은 기법은 모델 변형의 생산을 종단 간(end-to-end) 학습에서 분리해 내는 "유사 모듈성(pseudo-modularity)" 으로, 독립 기여자가 특화된 어댑터를 만들어 베이스 모델과 합성하도록 진입 장벽을 낮춥니다.

셋째, 모델에 맞춘 인프라 구축 입니다. P7이 언급한 FastCDC 같은 알고리즘으로 이진 가중치의 차등 저장과 추적을 시도하거나, vLLM 같은 표준 추론 엔진과 자동 랭킹 플랫폼을 결합해 빠른 피드백을 가능케 하자는 것입니다.

넷째, 이미 떠오르고 있는 새로운 협업 패턴입니다. 핵심 개발에서 배제된 주변부 기여자들이 프롬프트 라이브러리, 평가 벤치마크, 문서를 함께 만드는 주변부 지식 생산(peripheral knowledge production), 레드티밍과 프롬프트 테스트로 모델의 행동 경계를 탐색하는 집단적 경계 발견(collective boundary discovery), 그리고 대기업은 연산 자원을, 파트너와 커뮤니티는 전문성과 도메인 데이터를 내놓는 자원 기반 협업(resource-based collaboration) 이 그것입니다.

이 연구가 던지는 메시지

이론적으로 이 연구는 레이먼드의 바자르 모델이 OSM의 협업 실태를 충분히 담아내지 못한다는 점을 실증적으로 보여줍니다. 첫째, 핵심부와 주변부(core-periphery) 의 관계가 재편됩니다. OSS에서는 소스 코드가 공개되어 있어 주변부 행위자도 들여다보고 개입할 여지가 있지만, OSM에서는 모델 학습 과정의 구조적 접근 불가가 주변부의 배제를 오히려 심화시킵니다. 그런데 흥미롭게도 이 배제가 주변부 노동의 감소로 이어지지는 않습니다. OSS에서 주변부 작업이 버그 리포트처럼 교정적, 보조적 역할에 머무는 데 비해, OSM의 주변부는 파인튜닝 프로토콜과 정렬 기법, 사용 경험이라는 맥락적 지식을 생산하는 생성적 혁신(generative innovation) 의 장이 됩니다.

둘째, 연구팀은 조정 작업(articulation work) 의 성격 변화에도 주목합니다. OSS의 조정 작업이 분산된 개발자들의 비동기 통합과 작업 분배를 조율하는 데 초점을 둔다면, 모델의 비분해성 탓에 OSM의 조정 작업은 연산 자원과 대규모 데이터셋, 사람의 선호 정렬 과정 같은 중앙화된 자원의 접근을 관리하는 쪽으로 옮겨 갑니다. 코드 중심 기여 모델로는 포착할 수 없는 새로운 협업 논리입니다.

물론 한계도 분명합니다. 두 플랫폼에서 공통으로 비교 가능한 지표만 골랐기에 풀 리퀘스트 같은 상호작용은 제외되었고, 분석 대상도 GitHub와 HF Hub에 한정됩니다. 인터뷰 표본도 10 명으로, 빠르게 변하는 AI 커뮤니티의 모든 관점을 담기에는 부족할 수 있습니다. 연구팀은 더 넓은 AI 개발 맥락에서 협업 실태를 추적하는 종단 연구와, 식별된 장벽을 완화할 모델 적응형 인프라 설계를 후속 과제로 제안합니다.

결국 이 논문이 남기는 메시지는 명료합니다. 같은 "오픈소스"라는 깃발 아래 있어도, 공유하는 대상이 코드에서 모델 가중치로 바뀌는 순간 협업의 문법 자체가 달라진다는 것입니다. OSS의 시끌벅적한 시장이 OSM에서는 소수가 짓고 다수가 가져다 쓰는 구조로 재편되는 지금, 우리에게 필요한 것은 모델이라는 새로운 산출물에 맞는 협업 도구와 관행일지도 모릅니다.

From OSS to Open Source AI: an Exploratory Study of Collaborative Development Paradigm Divergence 논문

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~