과거의 소프트웨어 개발은 직접 재료를 사서 (코드 작성), 레시피를 따라 요리를 만드는 과정이었습니다. 하지만 요즘은 **이미 맛을 낸 '완성된 소스' (예전부터 훈련된 AI 모델, PTM)**를 사다가 요리에 섞어 쓰는 경우가 많습니다.
이 '완성된 소스'를 **PTM(Pre-Trained Models)**이라고 부릅니다. 이 논문은 이 소스들을 어떻게 사용하는지, 그리고 그 과정에서 어떤 문제가 생기는지 401 개의 실제 프로젝트 (요리실) 를 조사해서 밝혀냈습니다.
🔍 이 논문이 발견한 3 가지 놀라운 사실
1. 소스들은 '혼합'되어 있고, '기록'이 엉망입니다 (RQ1)
현상: 요리사들은 보통 하나의 소스만 쓰지 않습니다. 52.6% 의 프로젝트는 여러 개의 소스를 섞어 씁니다.
바꾸기 쉬운 소스 (Interchangeable): "이 소스 대신 저 소스를 써도 맛이 비슷하니까 괜찮아"라고 생각해서 여러 개를 준비해 둡니다. (예: 소금 대신 간장, 혹은 다른 브랜드의 소금)
서로 다른 역할의 소스 (Complementary): "이건 국물용, 저건 고기용"처럼 각자 다른 역할을 합니다.
문제점: 하지만 이 소스들이 어디에 들어갔는지 기록 (문서) 이 엉망입니다.
레시피 책 (README) 에는 안 적혀 있고, 요리사 머릿속 (코드) 에만 있거나, 혹은 냉장고 (설정 파일) 에 따로 떨어져 있습니다.
가장 큰 문제: "어떤 소스를 썼는지"는 적어두지만, **"언제, 어떤 버전의 소스"**를 썼는지는 거의 적지 않습니다. (예: "소금 사용"이라고만 적고, "2023 년산 소금"이라고 안 적음). 그래서 나중에 같은 요리를 만들려고 해도 맛이 달라질 수 있습니다.
2. 요리는 '그대로' 쓰지 않고 '수정'해서 씁니다 (RQ2)
현상: 완성된 소스를 그대로 쓰는 경우는 드뭅니다. 대개는 수정을 가합니다.
기능 추출: 소스의 '맛'만 뽑아서 다른 요리에 씀.
생성: 소스를 바탕으로 새로운 요리를 만들어냄.
판단: 소스를 이용해 "이게 맛있는지 아닌지" 판단함.
문제점: 이 과정에서 **수정 (Adaptation)**이 너무 다양하게 일어납니다. 소스 병에 라벨을 붙이거나, 내용물을 조금 빼내거나, 다른 재료와 섞기도 합니다. 이렇게 수정된 소스는 원래의 소스와는 다른 '새로운 것'이 되지만, 그 변화가 제대로 기록되지 않아 나중에 고치기 어렵습니다.
3. 소스들이 서로 '대화'하고 있습니다 (RQ3)
현상: 여러 개의 소스가 서로 정보를 주고받습니다.
손 넘기기 (Feature Handoff): A 소스가 만든 맛을 B 소스가 받아서 더 다듬음.
피드백 (Feedback Guidance): B 소스가 요리를 할 때, A 소스가 "너무 짜다"라고 지적해서 B 소스가 다시 맛을 조절함.
평가 (Evaluation): C 소스가 요리를 다 만들고 나서 "이게 맛있는지" 점수를 매겨줌.
문제점: 이 복잡한 연결고리가 문서화되지 않아서, 한 소스가 바뀌면 다른 소스까지 망가질 수 있습니다. 마치 레고 블록이 서로 맞물려 있는데, 하나를 빼면 전체가 무너질 수 있는 것과 같습니다.
💡 결론: "소프트웨어 2.0"이라는 새로운 개념
저자들은 이 현상을 **"소프트웨어 2.0"**이라고 부릅니다.
소프트웨어 1.0 (과거): 코드가 모든 것을 결정했습니다. "A 라는 함수를 호출하면 B 가 나온다"는 확실하고 예측 가능한 세계였습니다.
소프트웨어 2.0 (현재): **데이터와 학습된 결과 (모델)**가 모든 것을 결정합니다. "이 소스를 쓰면 어떤 맛이 날지"는 확률적이고 상황에 따라 달라지는 세계입니다.
이제 개발자들은 단순히 코드를 짜는 게 아니라, '지능'이라는 재료를 어떻게 관리하고, 어떻게 연결할지, 그리고 그 변화가 어떻게 영향을 미치는지를 관리해야 합니다.
🚨 우리가 배워야 할 교훈
이 논문은 우리에게 이렇게 말합니다:
"완성된 AI 소스 (모델) 를 가져다 쓸 때는, 단순히 '사용'하는 게 아니라 하나의 '소프트웨어 부품'처럼 엄격하게 관리해야 합니다. 버전 기록을 남기고, 문서화하며, 서로 어떻게 연결되는지 파악해야만 나중에 요리를 실패하거나 맛이 변하는 사고를 막을 수 있습니다."
요약하자면, AI 시대의 소프트웨어는 더 이상 혼자서 코딩하는 것이 아니라, 수많은 '지능'이라는 레고 조각들을 어떻게 잘 조립하고 관리하느냐의 문제라는 것입니다.
1. 문제 제기 (Problem)
새로운 의존성 형태의 등장: PTMs 는 대규모 데이터로 사전 훈련되어 새로운 작업에 재사용될 수 있어 개발 비용과 시간을 절감합니다. 그러나 이는 기존 라이브러리 (코드 중심) 와는 근본적으로 다른 **'모델 중심 (Model-Centric)'**의 새로운 소프트웨어 의존성을 만들어냅니다.
유지보수 및 신뢰성 위협: PTMs 를 소프트웨어에 통합하는 방식이 불명확하여, 시스템의 유지보수성과 신뢰성을 위협할 수 있습니다. 특히 모델의 행동이 소스 코드가 아닌 학습된 파라미터와 데이터에 의해 결정되므로, 기존 의존성 관리 도구 (예: requirements.txt) 로는 이를 추적하거나 관리하기 어렵습니다.
연구 공백: 기존 연구는 주로 PTM 의 상류 (모델 허브, 보안, 공유) 에 집중했으나, 하류 (실제 소프트웨어 프로젝트에서의 통합 및 재사용) 에 대한 체계적인 연구는 부족했습니다.
2. 방법론 (Methodology)
이 연구는 **혼합 방법론 (Mixed-Methods)**을 사용하여 오픈소스 프로젝트의 PTM 재사용 패턴을 분석했습니다.
데이터 수집 및 샘플링:
데이터셋: PeaTMOSS 데이터셋 (Hugging Face 및 PyTorch Hub 에서 PTMs 를 사용하는 28,575 개의 GitHub 저장소) 을 사용했습니다.
샘플링: 100 개 이상의 스타를 가진 인기 프로젝트 중, Hugging Face(341 개) 와 PyTorch Hub(314 개) 를 사용하는 650 개의 저장소를 층화 무작위 표본 추출 (Stratified Random Sampling) 로 선정했습니다.
최종 분석 대상: 이 중 PTM 을 핵심 기능 구현에 사용하는 **401 개의 기능적 애플리케이션 (Functional Applications)**을 선정하여 심층 분석했습니다.
분석 절차:
RQ1 (의존성 구조 및 문서화): 소스 코드, 설정 파일 (YAML, JSON), README 등을 수동 및 자동 분석하여 PTM 의존성이 어떻게 선언되고 문서화되었는지 조사했습니다.
RQ2 (재사용 파이프라인): PTM 이 프로젝트 내에서 어떻게 초기화, 적응 (Adaptation), 추론되는지 단계를 식별하고, 이를 3 가지 주요 파이프라인 유형 (특징 추출, 생성, 판별) 으로 분류했습니다.
RQ3 (모델 간 상호작용): PTM 이 다른 학습된 구성 요소 (다른 PTM 이나 처음부터 훈련된 모델) 와 어떻게 상호작용하는지 (특징 전달, 피드백, 평가 등) 를 분석하여 상호작용 유형을 분류했습니다.
3. 주요 기여 (Key Contributions)
소프트웨어 의존성 2.0 의 개념 정립: PTM 을 '코드 중심'이 아닌 '모델 중심'의 의존성으로 정의하고, 기존 의존성 (1.0) 과의 구조적, 행동적, 추적 가능성 차이를 체계적으로 비교했습니다.
PTM 재사용 파이프라인의 체계적 분석: 오픈소스 프로젝트에서 PTM 이 어떻게 통합되는지에 대한 첫 번째 대규모 실증 분석을 제공하며, 10 가지 재사용 단계와 3 가지 주요 파이프라인 유형을 도출했습니다.
다중 모델 상호작용 분류 체계 (Taxonomy): PTM 과 다른 모델 간의 상호작용을 4 가지 유형 (특징 전달, 피드백 유도, 평가, 후처리 정제) 으로 분류하고, 이들의 구조적 특성과 모듈성을 분석했습니다.
실무적 함의 및 제안: 개발자, PTM 허브 제공자, MLOps 플랫폼 제공자, 연구자 등 각 이해관계자를 위한 구체적인 개선 방안과 도구 개발 필요성을 제시했습니다.
4. 주요 결과 (Key Results)
RQ1: 의존성 구조 및 문서화
다중 PTM 사용: 연구 대상 프로젝트의 **52.6%**가 여러 개의 PTM 을 사용했습니다.
교환 가능 (Interchangeable, 37%): 동일한 역할을 수행하며 서로 교체 가능한 모델들 (예: BERT 계열 내 다양한 변형).
상호 보완적 (Complementary, 23%): 서로 다른 역할 (예: 텍스트와 이미지 처리) 을 수행하며 함께 사용되는 모델들.
문서화 부족: PTM 의존성 선언이 소스 코드, 설정 파일, README 에 분산되어 있습니다. **단 21.2%**의 프로젝트만이 코드 외부 (README 또는 설정 파일) 에 모든 PTM 을 명시적으로 문서화했습니다.
버전 관리 부재: **12%**의 프로젝트만이 PTM 의 구체적인 버전을 명시했습니다. 버전 정보가 없으면 재현성 (Reproducibility) 과 장기적인 유지보수가 어렵습니다.
RQ2: 재사용 파이프라인의 단계 및 조직
10 가지 재사용 단계: 모델 초기화 (INIT), 적응 (ADPT), 데이터 처리 (PROC), 프롬핑 (PROM), 특징 공학 (FEAT), 파인튜닝 (FT), 추론 (INF), 후처리 (POST), 평가 (EVAL), 전달 (DLV) 등 10 가지 단계를 도출했습니다. 기존 ML 파이프라인과 달리 '평가'와 '전달' 단계가 PTM 재사용 맥락에서 독립적인 단계로 부각되었습니다.
3 가지 파이프라인 유형:
특징 추출 중심 (Feature Extraction, 59%): PTM 을 특징 추출기로 사용하여 downstream 작업에 활용.
생성 중심 (Generative, 20%): 텍스트, 이미지 등 새로운 콘텐츠를 생성.
판별 중심 (Discriminative, 21%): 분류, 회귀 등 예측 작업 수행.
적응의 필요성: PTM 은 'Plug-and-Play'가 거의 불가능하며, 대부분 **적응 (Adaptation)**이 필요합니다. 이는 헤드 추가, 레이어 삭제, 파인튜닝, 프롬프트 엔지니어링 등 다양한 형태로 이루어집니다.
RQ3: 모델 간 상호작용
상호작용 빈도: 연구 대상 프로젝트의 **50%**에서 PTM 이 다른 학습된 구성 요소와 상호작용했습니다.
4 가지 상호작용 유형:
특징 전달 (Feature Handoff, 42%): 한 모델의 출력 (임베딩 등) 을 다른 모델의 입력으로 전달.
피드백 유도 (Feedback Guidance, 45%): 학습/파인튜닝 과정에서 한 모델이 다른 모델에게 손실 함수 (Loss) 나 평가 신호를 제공 (예: CLIP 을 이용한 이미지 생성 가이드).
평가 (Evaluation, 9%): 생성된 결과의 품질을 측정하는 지표로만 사용.
후처리 정제 (Post-Processing Refinement, 4%): 생성된 결과의 안전성이나 품질을 검증/정제 (예: Stable Diffusion 의 안전성 검사기).
5. 의의 및 결론 (Significance & Conclusion)
소프트웨어 공학의 패러다임 전환: PTM 은 단순한 라이브러리가 아니라, 학습된 파라미터, 파이프라인, 상호작용에 의해 행동이 결정되는 **'의미론적 의존성 (Semantic Dependencies)'**입니다. 이는 기존 의존성 관리 도구로는 처리할 수 없는 복잡성을 야기합니다.
기술적 부채 (Technical Debt) 의 새로운 형태:
의존성 부채: 불명확한 버전 관리와 분산된 선언.
적응 부채: 공식적인 도구 없이 수행되는 모델 수정.
파이프라인 부채: 복잡하게 얽힌 다중 모델 간 상호작용.
모델 - 데이터 얽힘: 한 모델의 출력 변화가 다른 모델의 동작을 무작위하게 깨뜨릴 수 있는 위험.
향후 방향:
도구 개발: PTM 의존성을 추적하고 관리할 수 있는 SBOM(Software Bill of Materials) 표준 확장, 버전 관리 도구, 자동화된 테스트 프레임워크 필요.
연구 과제: PTM 의 재사용성, 상호작용 패턴, 그리고 이를 통한 시스템의 신뢰성 확보를 위한 연구가 시급함.
이 논문은 PTM 기반 소프트웨어 시스템의 복잡성을 실증적으로 규명함으로써, 더 견고하고 유지보수 가능한 ML 시스템 구축을 위한 이론적, 실무적 기반을 마련했다는 점에서 중요한 의의를 가집니다.