Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See

기술 요약: 코드 세계의 디포킹(Deforking)

문제 정의
글로벌 규모로 소프트웨어 저장소를 마이닝하는 것은 포킹(forking)으로 인해 근본적으로 왜곡됩니다. 단일 업스트림 히스토리가 수천 개의 파생 저장소로 복제될 때, 원시 저장소 수에 기반한 표준 지표(예: 저자 확산도, 프로젝트 크기, 의존성 팬아웃)는 수십 배 이상 부풀려집니다. 공유된 커밋 히스토리를 가진 저장소들을 병합하는 단순한 "디포킹" 접근 방식은 서로 관련 없는 소프트웨어들을 과도하게 병합하기 때문에 처참하게 실패합니다. 이는 트로이데(trivially) 공유되는 커밋 그룹(예: 빈 커밋, 동일한 초기 스캐폴딩, 또는 보일러플레이트 형태의 LICENSE/CI 파일)이 서로 떨어진 포크 패밀리들을 하나의 거대한 의미 없는 클러스터로 연결하는 "허브" 역할을 할 때 발생합니다. 이 현상은 저자 식별 모호성에서 발견되는 과도한 병합 문제와 유사합니다.

방법론
본 논문은 58억 7천만 개의 커밋과 1억 1,600만 개의 저장소를 포함하는 World of Code (WoC) V2604 컬렉션에 대해, 이전의 공유 커밋 접근 방식을 확장한 정교한 디포킹 맵을 제시합니다. 방법론은 세 가지 주요 단계로 구성됩니다:

1. 허브-노드 스타 인코딩(Hub-Node Star Encoding): 공유 커밋을 가진 저장소들을 이차 클리크($O(N^2)$)로 연결하는 대신, 저자들은 공유 커밋 관계를 이분 그래프(bipartite graph)로 구현합니다. 동일한 커밋을 공유하는 저장소들의 각 고유 집합에 대해, 하나의 "허브" 노드를 생성하고 이를 참여하는 모든 저장소와 에지로 연결합니다. 이를 통해 인코딩을 선형적($O(N)$)으로 단순화합니다.
2. 병렬 루뱅 클러스터링(Parallel Louvain Clustering): 생성된 이분 그래프를 병렬 루뱅(PLM) 알고리즘을 사용하여 클러스터링함으로써 커뮤니티를 식별합니다. 각 커뮤니티의 정준 대표(canonical representative, 허브 노드 제외)가 디포킹된 프로젝트 $P$가 됩니다.
3. 구조적 캡핑(Structural Capping): 보일러플레이트 허브로 인한 과도한 병합을 방지하기 위해, 저자들은 결정론적인 크기 캡($C$)을 도입합니다. 그래프 구축 과정에서, 크기가 $C$를 초과하는 공유 커밋 그룹은 노드 할당 전에 폐기됩니다. 이는 실제 포크 패밀리를 연결하는 수많은 작은 공유 커밋 그룹들은 보존하면서, 서로 다른 패밀리들을 연결하는 "거대 허브"를 제거합니다. 저자들은 최적의 임계값을 결정하기 위해 $C$ 값($C=250$ 및 $C=500$ 구체적 명시)을 탐색합니다.

주요 결과 및 기여

• 메가 클러스터 문제와 캡 (실험 D1): 캡을 적용하지 않으면 가장 큰 커뮤니티가 861,948개의 저장소를 흡수합니다. $C=250$의 캡을 적용하면 가장 큰 클러스터가 183,654개로 감소하며(78.7% 감소), 거대 클러스터의 꼬리 부분을 무너뜨립니다(멤버 수가 $10^5$ 이상인 클러스터가 13개에서 1개로 감소). 결정적으로, 이 캡은 실제 포크 패밀리를 파괴하지 않습니다. 다중 저장소 패밀리의 개수가 안정적으로 유지됨(1,434만 개에서 1,435만 개로 약간 증가)으로써, 캡이 패밀리 자체를 산산조각 내기보다는 패밀리 사이의 가교를 끊어낸다는 것을 보여줍니다.
• 잔차 분석 (실험 D2): 가장 큰 캡 적용 클러스터에 대한 매개 중심성(betweenness centrality)을 이용한 구조적 진단은, 남은 "잔차(residual)"가 클러스터링의 아티팩트가 아니라 실제 공유된 히스토리임을 밝혀냅니다. 높은 매개 중심성을 가진 노드들은 업스트림 히스토리를 실제로 벤더링(vendored)한 애그리게이터 저장소들(예: qtwebengine-chromium, Debian의 모노레포)입니다. 저자 식별 그래프에서는 구조적 절단이 메가 클러스터를 해체하지만, 프로젝트 그래프에서 상위 매개 중심성 노드를 잘라내는 것은 클러스터를 약 20%만 축소시킬 뿐입니다. 이는 잔차가 외과적으로 제거되어야 할 대상이 아니라, 밀집된 실제 공유 히스토리의 네트워크임을 확인시켜 줍니다.
• 개발자 시그널에 미치는 영향 (실험 D3): 캡은 "확산(spread)" 시그널(저자가 접하는 고유 프로젝트 수)을 유의미하게 복원합니다. 캡이 없는 디포킹은 평균 확산도를 89.6에서 4.4로 급락시켜, 다수의 프로젝트를 다루는 숙련된 저자들의 시그널을 사실상 지워버립니다. $C=250$ 캡은 평균 확산도를 38.2로 복원하고, 1,000개 이상의 프로젝트를 가진 저자의 수를 15명에서 2,213명으로 회복시키는 동시에, 실제 포크는 여전히 압축합니다.
• 외부 검증 (실험 D4): 이 맵은 GitHub의 선언된 포크 그래프(GHArchive ForkEvents로부터 재구성됨)를 통해 검증되었습니다. 두 엔드포인트가 모두 WoC에 존재한다는 조건 하에, 커밋 기반 디포킹과 GitHub의 선언된 포크 사이에는 99.01%의 에지 일치율을 보였습니다. 나머지 0.99%의 차이는 완전히 분리되었거나 커밋을 공유하지 않은 포크들로, 이는 커밋 기반 방식의 올바른 동작입니다. 또한 분석을 통해 WoC가 아직 수집하지 못한 선언된 포크 부모가 11.04%임을 식별하여 완결성 지표를 제공했습니다.
• 크로스 포지(Cross-Forge) 및 분리된 포크 (실험 D5): 이 맵은 플랫폼 메타데이터가 아닌 공유 커밋에 의존하므로, 단일 플랫폼 그래프에서는 보이지 않는 포크 패밀리를 식별합니다.
  • 크로스 포지 패밀리: 포크 패밀리의 5.41%가 여러 포지(예: GitHub, GitLab, Bitbucket)에 걸쳐 있습니다.
  • 비-GitHub 루트: 포크 패밀리의 1.51%가 GitHub가 아닌 곳에 호스팅된 정준 루트를 가집니다.
  • 분리된 포크: 분석 결과, 선언된 포크가 WoC 내에서 부모와 공유 커밋 히스토리가 없는 455,550개의 "하드-분리(hard-detached)" 에지를 식별했습니다. 이 중 240,441개는 독자적인 다운스트림 트리를 키워온 실제 독립적 기원을 나타냅니다.
• 갱신된 제외 목록: 저자들은 이전 GHTorrent 시대의 리스트보다 3.4배 더 큰 1억 3,410만 개의 자식 저장소를 포함하는 업데이트된 포크 제외 목록을 공개하며, 분리되지 않은 포크만을 제외하도록 정교화했습니다.

의의 및 주장
본 논문은 이 디포킹 맵이 포크의 다중성으로 인한 인기 및 확산 지표의 팽창을 교정하여, 글로벌 규모의 소프트웨어 저장소 분석을 위한 필수적인 전제 조건 구축임을 주장합니다.

저자들은 이 접근 방식이 플랫폼 메타데이터를 보완한다고 강조합니다. 플랫폼 그래프(GitHub 등)는 특정 기간 내에 UI 액션을 통해 생성된 포크만을 기록하지만, 이 커밋 기반 방식은 서로 다른 포지를 넘나들고 히스토리 분리를 견뎌낸 포크 관계를 복구합니다. 이 맵은 플랫폼 그래프가 표현할 수 없는 "WoC 전용" 포크 패밀리를 포착합니다.

저자들은 캡이 없는 맵(현재 WoC에서 배포 중인 것)의 경우, 구조적 진단 결과가 해당 메가 클러스터가 아티팩트가 아닌 실제 벤더링된 히스토리를 나타냄을 증명했으므로 그대로 유지해야 한다고 명시적으로 밝힙니다. 그러나 보일러플레이트로 인한 과도한 병합을 제거하기 위해 향후 채택 시에는 **캡 적용 맵 ($C=250$)**을 사용할 것을 권장합니다. 현재 유통 중인 캡 없는 버전은 사소한 공유 커밋에 의해 관련 없는 프로젝트들이 연결되는 과잉 병합 문제를 겪고 있다고 지적했습니다.

디포킹 맵, 캡 적용 변형, 포크 제외 목록, 복제 코드 등을 포함한 모든 결과물은 WoC V2604 컬렉션에 키를 둔 독립적으로 호스팅되는 패키지로 제공됩니다.