💻 computer science

GitHub Template Repositories: Served Domains, Maintenance, and Practitioner Guidelines

본 논문은 효과적인 템플릿 프로젝트를 설계하고 관리하기 위한 실질적인 가이드라인을 도출하기 위해, 5개 프로그래밍 언어에 걸친 GitHub 템플릿 저장소들을 대상으로 이들의 적용 도메인, 유지보수 특성 및 품질 문제를 분석한 대규모 실증 연구를 제시한다.

원저자: Leuson Da Silva, Altaf Allah Abbassi, Imen Trabelsi, Paulo Borba, Foutse Khomh

게시일 2026-06-15

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Leuson Da Silva, Altaf Allah Abbassi, Imen Trabelsi, Paulo Borba, Foutse Khomh

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

GitHub를 소프트웨어를 구축하기 위한 설계도를 공유하는 거대하고 북적이는 디지털 시장이라고 상상해 보십시오. 수년 동안 사람들이 이러한 설계도를 공유하는 주요 방식은 '포크(fork)'를 만드는 것이었습니다. 이는 마치 누군가의 집 설계도를 복사하여 자신의 부지로 옮긴 뒤, 자신만의 스타일로 개조하는 것과 같습니다.

하지만 2019년, GitHub는 새로운 기능인 **템플릿 저장소(Template Repositories)**를 도입했습니다. 이것은 완성된 집의 복사본이 아니라, **조립식 스타터 키트(pre-fabricated starter kits)**라고 생각하면 됩니다. 이미 완성된 집을 가져와서 수정해야 하는 대신, 템플릿은 당신이 새로 지을 집을 위한 완벽한 기초, 올바른 배관, 그리고 정확한 배선을 제공합니다. 이는 중고 주택을 사서 허물고 다시 짓는 것이 아니라, 카탈로그에서 '주택 키트'를 구매하는 것과 같습니다.

이 논문은 이러한 스타터 키트에 대한 대규모 조사 연구입니다. 연구진은 세 가지 큰 질문을 던졌습니다: 사람들은 이 키트들로 어떤 종류의 집을 짓고 있는가? 이 키트들은 신뢰할 수 있는가? 그리고 미래에 어떻게 더 나은 키트를 만들 수 있을까?

연구 결과는 다음과 같으며, 이해하기 쉽게 정리되었습니다:

1. 이 키트들은 어디에 사용되는가? (도메인)

연구진은 다섯 가지 주요 프로그래밍 언어(Python, JavaScript, Java 등)에 걸쳐 수천 개의 템플릿을 조사했습니다.

최고의 승자: **웹 개발(Web Development)**이 단연 가장 인기 있는 용도입니다. 모든 스타터 키트의 60~70%가 웹사이트를 구축하기 위한 것임을 의미합니다. 이는 JavaScript나 TypeScript 같은 언어들이 인터넷을 구축하는 주요 도구라는 점을 생각하면 당연한 결과입니다.
전문가 영역: 어떤 언어들은 더 전문화되어 있습니다. 예를 들어, Python 템플릿은 '맥가이버 칼(Swiss Army knives)'처럼 웹사이트부터 인공지능, 데이터 과학까지 모든 분야를 아우릅니다. 반면, **C#**과 Java 템플릿은 주로 비디오 게임이나 기업용 소프트웨어 같은 특정 분야에 집중되어 있습니다.
누가 만드는가? 흥미롭게도, 이러한 키트 대부분은 대기업이 아닌 개인에 의해 만들어집니다. 이는 건설 기업이 판매하는 설계도가 아니라, DIY 애호가들이 각자의 설계도를 공유하는 동네와 같습니다.

2. 이 키트들은 신뢰할 수 있는가? (유지보수 및 품질)

주택 키트를 구매한다면 당신은 다음과 같은 점을 알고 싶을 것입니다: 나무가 썩지는 않았는가? 설명서는 명확한가? 연구진은 버그, 보안 취약점, 그리고 지저분한 코드(code smells)를 찾아냄으로써 이 템플릿들의 '건강 상태'를 점검했습니다.

'왜곡된' 현실: 대부분의 템플릿은 사실 매우 깨끗합니다. 엄청나게 많은 템플릿이 중대한 문제 제로(0) 상태입니다. 하지만 아주 적은 수의 템플릿이 형편없는 상태여서 평균을 깎아먹고 있습니다. 이는 90%의 키트는 완벽하지만, 10%는 무너져 내리고 있는 상점과 같습니다.
'만능 법칙'은 없다: 단순히 별(좋아요)이나 포크(fork)가 많다고 해서 그 키트가 좋다고 가정해서는 안 됩니다.
- JavaScript의 경우, 포크가 많을수록 오히려 버그가 더 많았습니다 (아마도 사람들이 지저분한 코드를 복사했기 때문일 것입니다).
- Python의 경우, 포크가 많을수록 버그가 더 적었습니다.
- 교훈: 템플릿의 인기가 반드시 높은 품질을 보장하는 것은 아닙니다. 더 자세히 살펴봐야 합니다.
누가 차이를 만드는가? 조직(기업)이 만든 키트가 개인보다 약간 더 깨끗한 경향이 있지만, 그 차이는 미미합니다. 누가 만들었느냐보다 사용하는 언어가 더 중요합니다.

3. 어떻게 더 나은 키트를 만들고 사용할 것인가 (가이드라인 및 함정)

연구진은 단순히 버그를 세는 데 그치지 않고, 무엇이 템플릿을 성공적으로 만드는지 파악하기 위해 최고와 최악의 키트들을 살펴보았습니다.

좋은 습관 (가이드라인):

모든 것을 자동화하라: 최고의 키트에는 오류를 점검하고 부품을 자동으로 업데이트하는 '로봇(자동화 도구)'이 포함되어 있습니다.
훌륭한 매뉴얼을 작성하라: 키트가 어떻게 조립되는지 모른다면 그것은 쓸모가 없습니다. 최고의 템플릿은 단순히 파일 목록만 나열하는 것이 아니라, 명확하고 단계적인 가이드를 제공합니다.
올바른 버튼을 사용하라: 많은 템플릿이 사용자에게 저장소를 '클론(clone)'하라고 안내합니다. 연구진은 이렇게 말합니다: 그렇게 하지 마십시오! GitHub의 특정 '이 템플릿 사용하기(Use this template)' 버튼을 사용하십시오. 그래야 원본의 기록 없이 깨끗하고 새로운 복사본을 만들 수 있습니다.
버전을 일치시켜라: 만약 키트가 특정 도구(예: 게임 엔진의 특정 버전)를 사용한다면, 템플릿은 어떤 버전을 지원하는지 명확히 명시해야 합니다. 그렇지 않으면 잘못된 벽돌로 집을 짓게 될 수 있습니다.

나쁜 습관 (함정):

'가짜' 템플릿: 어떤 사람들은 이미 완성된 복잡한 애플리케이션을 가져와서 단순히 '템플릿'이라는 라벨만 붙여 놓습니다. 이는 마치 가구가 다 갖춰진 사람이 살고 있는 집을 '스타터 키트'라고 속여 파는 것과 같습니다. 혼란스럽고 사용하기 어렵습니다.
유령 도시: 어떤 템플릿들은 방치되어 있습니다. 제작자는 업데이트를 중단했지만, '아카이브(archived)' 처리하거나 '비활성(inactive)' 상태로 표시하지 않았습니다. 이는 사용자가 무너져가는 기초 위에 집을 짓도록 속이는 행위입니다.
뒤섞인 꾸러미: 하나의 폴더 안에 다섯 가지 다른 언어의 템플릿을 한데 모아 두는 것은 지저분합니다. 이는 배, 자동차, 집의 설계도를 한 상자에 담아두는 것과 같습니다. 각 언어별로 분리된 명확한 키트를 갖는 것이 좋습니다.

결론

이 연구는 이러한 스타터 키트를 사용하거나 만드는 모든 이들에게 보내는 경고입니다.

사용자를 위한 조언: 가장 인기 있는 템플릿을 무작정 잡지 마십시오. 실제로 유지보수가 되고 있는지, 문서가 명확한지, 그리고 당신의 구체적인 필요에 부합하는지 확인하십시오.
제작자를 위한 조언: 템플릿을 만든다면 그것을 하나의 '제품'처럼 취급하십시오. 계속 업데이트하고, 좋은 지침을 작성하며, 그것이 단순히 복사하기 위한 것이 아니라 재사용되도록 설계되었는지 확인하십시오.

연구진은 이 템플릿들이 매우 새롭기 때문에(2019년에 도입됨), 우리는 이제 막 이들이 소프트웨어 세계를 어떻게 형성하는지 이해하기 시작하는 단계라고 언급했습니다. 이들은 소프트웨어 구축 속도를 높여주는 강력한 도구이지만, 오직 올바르게 구축되고 사용될 때만 그러합니다.

기술 요약: GitHub 템플릿 저장소: 서비스 도메인, 유지보수 및 실무자 가이드라인

문제 정의

GitHub는 오랫동안 포크(fork)와 풀 리퀘스트(pull request)를 통해 코드 공유를 지원해 왔으나, 템플릿 저장소(2019년 도입)는 스캐폴딩(scaffolding)을 통해 새로운 프로젝트를 생성하는 차별화된 메커니ği즘을 제공한다. 이러한 가용성에도 불구하고, 다음 사항에 대한 경험적 지식의 공백이 존재한다:

이 템플릿들이 서비스를 제공하는 구체적인 도메인.
재사용 가능한 산출물로서의 유지보수 특성 및 신뢰성.
효과적인 템플릿 설계 및 채택을 안내하는 관행과 함정.

협업적 진화를 촉진하는 포크와 달리, 템플릿은 초기 프로젝트 설정을 가속화하는 것을 목표로 한다. 그러나 이들의 보급률, 품질, 사용 패턴에 대한 이해 없이는 실무자와 연구자들이 이러한 산출물을 효과적으로 설계, 평가 또는 발전시키는 데 필요한 지침을 얻을 수 없다.

방법론

저자들은 GitHub에서 가장 널리 사용되는 5가지 프로그래밍 언어(TypeScript, Python, JavaScript, Java, C#)를 대상으로 대규모 경험적 연구를 수행하였다. 연구는 세 가지 연구 질문(RQ)을 중심으로 구성되었으며, 엄격한 데이터 수집 및 분석 파이프라인을 따랐다.

1. 데이터 수집 및 필터링

출처: GitHub Search API.
식별 전략: 저자들은 키워드 기반 휴리스틱(예: "boilerplate", "starter")보다 더 포괄적인 미공개 template:true 파라미터를 발견하고 검증하였다.
필터링: 저장소는 활성 상태, 비아카이브(non-archived), 비포크(non-forked), 공개 상태이며 별(star)이 최소 2개 이상인 것으로 필터링되었다.
샘플 크기: 총 14,780개의 저장소를 마이닝하였으며, 언어별 필터링 및 비영어 프로젝트 제거 후 도메인 분석(RQ1)에는 12,818개, 유지보수 분석(RQ2/3)에는 13,381개를 유지하였다.

2. 연구 질문 1: 도메인 및 소유권

접근 방식: 저자들은 프로젝트 설명, 토픽, README를 기반으로 저장소를 도메인별로 자동 분류하기 위해 LLM-as-a-judge 전략(DeepSeek-V3.2 사용)을 채택하였다.
검증: 100개의 Python 프로젝트에 대한 수동 분석을 통해 분류 체계를 교정하였다. LLM의 성능은 192개 저장소의 인간 합의 기반 정답(ground truth)과 비교하여 85.4%의 일치율(Cohen's $\kappa$ = 0.82)을 달성하며 검증되었다.
소유권 분석: 개인 및 조직 소유자를 구분하기 위해 메타데이터를 추출하였다.

3. 연구 질문 2: 유지보수 및 신뢰성

도구: SonarQube를 사용하여 템플릿 스냅샷에 대한 정적 분석을 수행하고 코드 스멜(code smells), 버그, 보안 핫스팟 및 취약점을 탐지하였다.
통계 분석: 저장소 특성(별, 포크, 연령, 최근 커밋, 소유권)과 품질 이슈 간의 연관성을 분석하기 위해 **음이항 회귀 모델(Negative Binomial regression models)**을 사용하였다. 지표는 저장소 크기(KLOC)에 따라 정규화되었다.
교정: 여러 테스트에 걸친 허위 발견율(false discovery rates)을 제어하기 위해 Benjamini–Hochberg 교정이 적용되었다.

4. 연구 질문 3: 가이드라인 및 함정

질적 분석: 심층적인 질적 검사를 위해 선별된 최상, 최악, 혼합 품질 점수의 저장소 샘플을 선정하였다.
프로세스: 두 명의 연구자가 샘례를 독립적으로 분석하여 반복되는 패턴을 식별하였고, 이를 가이드라인(모범 사례)과 함정(흔한 오류)으로 통합하였다.
LLM 검증: 저자들은 LLM이 가이드라인 준수 여부를 평가하는 데 있어 인간의 판단을 근사할 수 있는지 테스트하였으며, 중간 정도의 일치도( $\kappa$ = 0.46)를 확인하였다.

주요 결과

1. 도메인 및 소유권 (RQ1)

지배적 도메인: **웹 개발(Web Development)**이 모든 생태계에서 지배적인 도메인이다 (예: TypeScript의 경우 67.7%, JavaScript의 경우 52%).
언어별 특성화:
- Python은 가장 다재다능하며, 높은 머신러닝/AI 템플릿 집중도를 포함하여 모든 도메인을 유의미하게 다룬다.
- C# 및 Java는 게임 개발과 강한 연관성을 보인다.
- TypeScript 및 JavaScript는 웹 개발에 집중되어 있다.
소유권: 개인 사용자가 전체 템플릿의 약 3분의 2를 소유하고 있으며, 나머지는 조직이 소유한다. 조직은 표준화에 집중하는 경향이 있는 반면, 개인은 주로 오픈소스 커뮤니티를 지원하거나 모범 사례를 보여주는 것을 목표로 한다.

2. 유지보수 및 품질 (RQ2)

이슈 분포: 품질 이슈는 드물고 매우 편중되어 있다. 소수의 저장소가 대부분의 버그와 취약점을 포함하고 있다. 언어당 약 39~54%의 템플릿이 이슈가 없는 것으로 보고된다.
생태계 의존성: 저장소 특성과 품질 사이의 보편적인 패턴은 없다.
- JavaScript/TypeScript: 포크 수가 많을수록 더 많은 이슈와 상관관계가 있다(양의 상관관계).
- Python: 포크 수가 많을수록 더 적은 버그와 상관관계가 있다(음의 상관관계).
- 소유권: 조직 소유 템플릿은 일부 언어(예: Java, C#)에서는 이슈 밀도가 약간 낮지만, 다른 언어(예: TypeScript 버그)에서는 더 높게 나타나, 소유권이 균일한 품질 신호가 아님을 보여준다.
활동성: 최근 커밋 활동은 이슈 수와 매우 미미한 연관성만을 보이는데, 이는 인기나 최근 활동만으로는 템플릿 신뢰성을 예측하는 약한 지표임을 시사한다.

3. 가이드라인 및 함정 (RQ3)

연구를 통해 7가지 가이드라인과 5가지 함정을 도출하였다:

가이드라인:

G1: 유지보수 관행(CI/CD, 린팅, 테스트)을 통합하라.
G2: 포괄적이고 접근 가능한 문서(다국어 지원 포함)를 제공하라.
G3: 직접적인 클로닝(cloning) 대신 "이 템플릿 사용하기(Use this template)" 기능을 사용하도록 명시적으로 교육하라.
G4: 로드맵을 통해 진화 과정을 소통하라.
G5: 핵심(core)으로부터 변형을 파생시켜 템플릿을 재사용 가능한 패밀리로 구성하라.
G6: 기술 버전을 릴리스와 일치시켜라.
G7: 커뮤니티 지원(예: Discord, 후원)을 권장하라.

함정:

P1: 적절한 스캐폴딩 없이 전체 구현체를 템플릿으로 재사용하는 것.
P2: 불분명하거나 비활성 상태인 저장소 상태(아카이브 처리 또는 폐기 신호 전달 실패).
P3: 하나의 저장소 내에 여러 개의 별개 템플릿을 호스팅하는 것.
P4: 기술 구현 문제와 템플릿 스캐폴딩을 혼합하는 것.
P5: 빈 템플릿 또는 문서 누락.

의의 및 기여

본 논문은 소프트웨어 공학 커뮤니티에 다음과 같은 기여를 한다고 주장한다:

경험적 통찰: GitHub 템플릿에 대한 최초의 대규모 특성화를 제공하며, 웹 개발이 주요 사용 사례이고 유지보수 품질은 균일하기보다 생태계에 따라 다름을 밝혀냈다.
실행 가능한 가이드라인: 실무자들이 임시방편적인 생성을 넘어 고품질 템플릿을 설계, 선택 및 유지 관리할 수 있도록 구체적인 가이드라인과 함정을 제공한다.
데이터셋 공개: 향후 연구를 위해 상위 5개 프로그래밍 언어를 다루는 데이터셋을 공개한다.
연구자를 위한 시사점: 연구자들에게 템플릿은 완전하고 진화하는 프로젝트가 아닌 스캐폴딩을 나타내므로, 일반적인 소프트웨어 개발 관행을 분석할 때 템플릿을 필터링하여 제외해야 한다고 경고한다.
GitHub를 위한 시사점: 저자들은 현재 미공개 파라미터에 의존하는 방식이 편향을 초래할 수 있으므로, GitHub가 미래의 마이닝 연구의 재현성을 높이기 위해 템플릿에 대한 공식 API 지원 및 메타데이터를 제공해야 한다고 제안한다.

연구는 템플릿이 단순한 프로젝트 스타터가 아니라, 하류(downstream) 프로젝트로 기술 부채가 전파되는 것을 방지하기 위해 적극적인 유지보수와 버전 관리가 필요한 업스트림 재사용 산출물로 취급되어야 한다고 결론짓는다.