오픈소스 프로젝트의 건강도를 어떻게 정량화할 것인가

기능 너머의 질문

기술 선정 시 팀은 기능, 성능, API 설계를 꼼꼼히 비교합니다. 그런데 체계적으로 평가되는 일이 드문 질문이 하나 있습니다. 이 프로젝트를 3년 뒤에도 누군가 유지보수하고 있을까라는 질문입니다.

이는 기우가 아닙니다. 컴포넌트가 한번 의존성 트리에 들어오면 그 유지보수 상태는 곧 우리의 리스크가 됩니다. 유지보수가 멈춘 프로젝트는 새 취약점에 패치가 나오지 않고, 새 런타임에 맞춰지지 않으며, 보안 사고가 났을 때 스스로 해결하는 수밖에 없다는 뜻입니다. 그리고 이전 비용은 도입 시점에 평가에 이틀 더 쓰는 비용보다 거의 언제나 훨씬 큽니다.

건강도 평가의 가치가 여기 있습니다. 그것이 예측하는 것은 '취약점이 나온 뒤 패치가 얼마나 빨리 도착하는가'이며, 이 숫자가 곧 리스크 노출도를 결정합니다.

정량화 가능한 네 가지 분류

### 1. 릴리스와 커밋 주기

가장 기본적인 활동 신호이지만, 봐야 할 것은 절대적 빈도가 아니라 규칙성과 추세입니다.

• 최근 릴리스로부터 얼마나 지났는가. 1년 이상이면 대개 명확한 경고 신호입니다(정말로 완성된 작은 유틸리티는 예외입니다).
• 릴리스 간격이 안정적인가, 아니면 월 단위에서 반년 단위로 바뀌었는가.
• 커밋 추이가 평탄한가, 증가하는가, 아니면 지속적으로 감소하는가.

'성숙해서 안정적인 것'과 '사실상 중단된 것'을 구분해야 합니다. 판단 방법은 이슈와 PR에 응답이 있는지 보는 것입니다. 릴리스는 멈췄지만 질문에는 답하는 프로젝트와, 모든 경로가 침묵하는 프로젝트는 리스크가 전혀 다릅니다.

### 2. 기여자 집중도(bus factor)

가장 간과되기 쉬우면서 예측력이 가장 큰 지표입니다.

bus factor가 묻는 것은, 핵심 기여자가 몇 명 동시에 떠나면 프로젝트가 정체되는가입니다. 값이 1이면 프로젝트 전체가 한 사람에게 의존한다는 뜻입니다.

측정 가능한 관점으로는 최근 1년 커밋 상위 3인이 전체에서 차지하는 비율, 커밋 권한을 가진 인원수, 유지보수자가 어떤 조직에 소속되어 있는지(조직의 뒷받침은 지속적인 자원 투입과 승계 구조를 뜻합니다) 등이 있습니다.

xz 사건의 신호 되짚기: 그 사건에서 공격자가 오랜 기간 침투해 결국 유지보수 권한까지 얻을 수 있었던 것은, 바로 원래 유지보수자가 혼자 감당하며 소진되어 도움이 절실했기 때문입니다. 사후에 보면 '단독 유지보수 + 장기간의 부담 + 갑자기 나타난 열성적인 기여자'는 하나의 완전한 리스크 신호 조합입니다. 그리고 이 신호들은 사건이 일어나기 전에 모두 공개되어 누구나 볼 수 있는 상태였습니다.

### 3. 응답 속도

커뮤니티가 아직 '살아 있다'는 가장 직접적인 증거는 외부 입력에 대한 응답입니다.

• 이슈 응답 시간의 중앙값은 얼마인가. 한 번도 답이 없는 이슈는 얼마나 되는가.
• PR은 제출부터 검토까지 얼마나 걸리는가. 오래 방치된 PR은 얼마나 되는가.
• 보안 문제의 전용 신고 경로(security.txt, SECURITY.md)가 있는가. 과거 보안 대응 속도는 어땠는가.

마지막 항목은 보안 평가에서 특히 중요합니다. 보안 대응 절차가 없는 프로젝트는 코드 품질이 아무리 좋아도 취약점이 나왔을 때 확실성을 주지 못합니다.

### 4. 자금과 거버넌스 구조

다소 정성적인 지표이지만 장기 지속 가능성을 좌우합니다.

• 재단(Linux Foundation, Apache, CNCF)이 호스팅하는가, 기업의 후원이 있는가.
• 거버넌스 문서, 의사결정 절차, 기여자 협약이 명시되어 있는가.
• 자금원이 있는가(후원, 상용 제품, 핵심 유지보수자의 고용).

개인의 여가 프로젝트라고 해서 쓸 수 없다는 뜻은 아닙니다. 훌륭한 기반 라이브러리 상당수가 거기서 시작했습니다. 다만 리스크 성격이 다르다는 뜻이므로, 기본값으로 무시할 것이 아니라 도입 심사 기록에 명시해야 합니다.

이미 있는 데이터 출처

이 평가를 처음부터 만들 필요는 없습니다.

• OpenSSF Scorecard는 프로젝트를 자동 채점하며 코드 리뷰, 브랜치 보호, 의존성 갱신, CI 보안 테스트 등을 다룹니다. 기준선으로 바로 참조할 수 있습니다.
• 저장소 메타데이터(기여자, 커밋 이력, 릴리스 타임라인)만으로도 지표의 대부분을 산출할 수 있습니다.
• 보안 대응 이력은 CVE 기록에서 역산할 수 있습니다. 이 프로젝트의 과거 취약점들이 공개부터 수정까지 얼마나 걸렸는지.

짚어둘 것은 스타 수가 가장 신뢰할 수 없는 지표라는 점입니다. 그것이 나타내는 것은 과거의 화제성이지 현재의 건강도가 아니며, 스타가 많은 프로젝트가 실은 오래전에 멈춰 있는 경우는 얼마든지 있습니다.

도입 심사에 넣기

건강도 평가를 실무에 안착시키는 방법은, 도입 판단의 명시적 단계로 만들고 의존성의 중요도에 따라 임계값을 달리하는 것입니다.

핵심 의존성(운영에 들어가고 교체가 어려움) — 요구를 높입니다. 활발한 유지보수, 1보다 큰 bus factor, 보안 대응 경로. 충족하지 못하면 아키텍처상의 격리 방안이나 대체품 평가를 요구합니다.

일반 의존성 — 건강도 점수를 기록하고 정기 재검토에 포함하며, 쇠퇴 신호가 나타나면 이전을 앞당겨 계획합니다.

개발 도구 의존성 — 임계값은 느슨해도 되지만 등록은 필요합니다. 빌드 환경도 공격면이기 때문입니다.

똑같이 중요한 것이 지속적인 모니터링입니다. 건강도는 변합니다. 도입 시점에 활발했던 프로젝트가 2년 뒤에는 멈춰 있을 수 있습니다. 건강도를 정기적인 의존성 재검토(예를 들어 분기별)에 넣는 편이 도입 때 한 번 보는 것보다 훨씬 유용합니다.

더 근본적인 관점

커뮤니티 건강도를 평가하는 일은 본질적으로 장기적인 관계를 평가하는 일입니다. 단순히 코드를 쓰는 것이 아니라, 우리 신뢰성의 일부를 만난 적 없는 사람들에게 맡기는 것입니다.

이것은 오픈소스를 피할 이유가 되지 않습니다. 현대 소프트웨어는 오픈소스 없이 성립하지 않습니다. 다만 '누가, 얼마나 오래 유지보수하는가'라는 질문을 '기능이 요건을 만족하는가'와 같은 무게의 자리에 놓을 이유는 됩니다.

---

관련 글: 기업 오픈소스 도입 심사 제도 구축하기 · EOL 오픈소스 컴포넌트의 리스크 대응 · 오픈소스·SBOM 가이드의 프로젝트 건강도 항목