오픈소스 기여자가 적다는 소식, 의존성을 바꿀 근거가 될까
기여자 수와 특정 후원 목록만으로 오픈소스의 안전성과 지속성을 판단하기 어렵다. SQLite와 XZ의 공식 자료를 대조하고, 릴리스·지원·인계 경로에서 의존성의 유지 비용을 확인한다.
의존 라이브러리에 알려진 취약점이 없고 테스트도 통과한다. 그런데 다음 보안 수정이나 릴리스를 누가 맡는지는 모른다. 개발자가 의존성을 고를 때 코드의 현재 상태와 그 코드를 계속 배포할 사람의 여건을 함께 봐야 하는 이유다.
이 질문을 다시 꺼낸 계기는 오픈소스 23개 프로젝트의 기여 이력을 분석한 The people holding up the internet이다. 이를 소개한 Linux Stans 글의 갱신 표기는 2026년 10월 9일이고, GeekNews에는 10월 12일 오전 5시 46분, 한국 시각으로 등록됐다. 원자료는 10월 자료로 표시되며 정확한 최초 공개일은 명시하지 않는다. 새 취약점 발표가 아니라, 의존성을 유지할 조건을 다시 읽게 하는 조사다.
기여자 수는 질문의 출발점이다
분석자는 2025년 10월 7일부터 2026년 10월 7일까지 병합과 봇을 제외한 변경을 세고, 10회 이상 작성한 사람을 정기 기여자로 분류했다. 그 기준에서 23개 중 11개 프로젝트가 1~2명에 해당한다. 공개된 23개 프로젝트 데이터에서도 이 집계를 확인했다. 저장소를 다시 수집하거나 전체 분석을 재실행한 것은 아니다.
이 숫자의 정확한 의미는 일정 기간에 일정 횟수 이상 변경을 작성한 사람이 적다는 것이다. 유지보수자의 총인원이나 프로젝트의 안전성을 직접 측정한 값은 아니다. 아홉 번 기여한 사람은 이 기준에서 빠지고, 검토·버그 분류·보안 신고 대응은 커밋 작성자 수로 드러나지 않는다. 다른 시스템의 이력을 복제한 저장소에서는 기여 표시도 달라질 수 있다. 원자료의 방법과 한계
내가 주목한 부분은 작은 팀이라는 사실보다 책임이 모이는 지점이다. 안정된 라이브러리는 변경이 적어도 충분히 유지될 수 있다. 반대로 기여자가 많아도 릴리스 권한과 코드의 핵심 지식이 한 사람에게만 있으면 그 사람이 자리를 비울 때 문제가 남는다. 이 조사 대상 23개를 오픈소스 전체의 대표 표본으로 읽어서도 안 된다.
따라서 낮은 기여자 수를 곧바로 교체 사유로 삼기보다, 필요한 수정이 생겼을 때 누가 검토하고 배포할 수 있는지 묻는 신호로 쓰는 편이 낫다고 본다.
후원 목록에 없다는 말의 범위를 확인한다
원자료의 공개 지원 조사는 Sovereign Tech Agency, Alpha-Omega, Open Collective, GitHub Sponsors 네 경로를 대상으로 한다. 여기서 지원을 찾지 못했다는 결과는 그 프로젝트의 수입 전체가 없다는 뜻이 아니다. 조사의 지원 범위
SQLite가 좋은 예다. 공식 홈페이지는 후원사와 SQLite Consortium을 표시한다. 공식 지원 안내에는 유료 전문 지원, 맞춤 수정, 별도 라이선스를 가진 확장 제품이 있다. 공개 후원 플랫폼의 명단과 프로젝트가 유지보수 비용을 마련하는 방식은 서로 다른 정보다.
XZ도 공식 자료를 함께 읽으면 빠진 경로가 보인다. Lasse Collin의 사건 설명 페이지는 2025년 1월 17일 갱신에서 Liberapay 계정을 만들었다고 밝힌다. 이는 앞의 네 경로에 포함되지 않는다. 계정이 있다는 사실만으로 충분한 자금이 확보됐다고 판단할 수도 없지만, 후원 경로 자체가 없다고 요약하는 것은 부정확하다.
나는 의존성 검토에 자금 사정을 넣을 때 공식 후원 안내와 상용 지원을 먼저 확인하겠다. 무료 사용이 가능하다는 조건과, 장애가 났을 때 응답 시간이나 수정 범위를 계약할 수 있다는 조건을 나눠 적는다. 유료 지원을 구매한다면 실제로 어떤 버전과 업무를 맡아 주는지 확인해야 한다. 후원금은 보통 내가 원하는 일정의 패치를 주문하는 계약으로 기대할 수 없다.
사람이 늘어도 릴리스의 신뢰가 자동으로 늘지는 않는다
XZ의 공식 사건 설명은 2024년 배포된 5.6.0과 5.6.1의 릴리스 tarball에 백도어가 있었고, 해당 파일을 Jia Tan이 만들고 서명했다고 기록한다. tarball은 배포용 소스를 묶은 파일이다. 같은 페이지는 공격을 작동시키는 코드가 Git 저장소에는 포함되지 않았다고 설명한다.
이 사실에서 가져갈 교훈은 기여자를 더 받아도 소용없다는 것이 아니다. 서명이 있어도 서명자의 행위가 올바르다는 보장은 없고, 저장소의 코드와 실제 배포 파일을 확인하는 일도 서로 다르다는 점이다. 나는 기여 인원을 늘리는 작업과 권한을 검토하는 작업을 함께 설계해야 한다고 읽는다.
특히 누가 릴리스를 만들고 서명하는지, 권한 변경을 누가 확인하는지, 배포 결과를 다른 사람이 검증할 수 있는지가 중요하다. 사용자는 모든 업스트림의 내부 절차를 감사하기 어렵다. 업스트림은 원래 프로젝트의 개발·배포 경로를 뜻한다. 그래서 공식 보안 연락처, 릴리스 문서, 인계 안내처럼 공개적으로 확인할 수 있는 근거부터 살피고, 없는 정보는 없다고 남겨야 한다.
핵심 의존성 하나에서 운영 경로를 따라간다
서비스의 모든 라이브러리에 같은 조사 시간을 쓰기는 어렵다. 나는 인증, 데이터 보관, 배포처럼 중단 시 영향이 큰 경로에서 의존성 하나를 골라 다음 표를 작성하겠다. 아래는 실제 도입 성과가 아니라 검토 방법의 제안이다.
| 확인할 경로 | 남길 근거 |
|---|---|
| 무엇을 쓰는가 | 실제 배포 버전, 패키지 출처, 연결된 핵심 라이브러리 |
| 수정은 어디서 오는가 | 업스트림 또는 배포판의 보안 공지와 지원 기간 |
| 누가 배포하는가 | 릴리스 담당, 검증 절차, 담당자 부재 시 경로 |
| 우리 팀은 무엇을 할 수 있는가 | 재현 자료 제공, 지원 계약, 대체·복구에 필요한 시간 |
배포판이 패치를 제공한다면 그 경로를 이용하는 것도 대안이다. 다만 패치를 이전 버전에 옮기는 백포트 지원과 원 프로젝트의 장기 지속성은 같은 조건이 아니다. 보안 패치를 받을 수 있는 기간과, 새 기능이나 호환성 문제를 해결할 주체를 따로 확인한다. 자체 포크는 수정 권한을 확보하지만 코드 검토와 릴리스 책임도 우리 팀으로 가져온다.
가령 중요한 결함이 보고된 상황을 가정해 보자. 버전을 올리고 회귀 테스트를 하는 경로가 있는지, 패치가 늦으면 기능을 제한하거나 다른 구현으로 바꿀 수 있는지 적어 본다. 해결책이 내부 포크뿐이라면 그 코드를 읽을 사람과 유지할 시간을 비용에 넣어야 한다. 커밋 그래프가 활발하다는 이유로 이 작업이 사라지지는 않는다.
지원에도 여러 방식이 있다. 유지보수자가 요청한 재현 자료를 정리하거나 문서를 고치는 일은 작은 출발점이 된다. 회사 예산으로 후원하거나 지원 계약을 마련할 수도 있다. 어느 방법이든 유지보수자가 검토할 시간을 필요로 하므로, 기여량을 늘리는 일과 부담을 줄이는 일이 항상 같지는 않다.
새 의존성을 고를 때 내가 남기고 싶은 결론은 “사람이 적어서 위험하다”보다 구체적이다. 필요한 수정이 어디에서 나오고, 검증된 배포를 어떻게 받으며, 그 경로가 멈추면 어떤 비용으로 이어 갈 수 있는가. 이 답이 있어야 작은 팀의 프로젝트도 책임 있게 사용할 수 있다.
참고 자료
이 이야기가 도움이 되었나요?