무슨 일이 있었나요?
리눅스 관련 블로그 LinuxStans에 흥미로운 분석 글이 올라왔어요. 우리가 매일 쓰는 인프라의 바탕이 되는 핵심 오픈소스 프로젝트 23개를 살펴봤대요. 그랬더니 그중 11개, 그러니까 거의 절반이 사실상 한두 명의 메인테이너 손에서 유지되고 있었다는 내용이에요.
메인테이너(maintainer) 는 프로젝트를 관리하는 사람이에요. 이슈를 분류하고, 다른 사람이 보낸 코드(PR)를 리뷰해서 합치고, 보안 취약점이 신고되면 패치를 만들고, 새 버전을 배포해요. 식당으로 치면 주방장 겸 사장 겸 설거지 담당인 셈이에요.
“오픈소스는 전 세계 개발자가 같이 만드는 거 아니야?”라고 생각하기 쉬운데요, 현실은 꽤 달라요. 기여자 목록에 수백 명이 있어도, 실제로 릴리스 버튼을 누르고 밤새 보안 이슈에 대응하는 사람은 한두 명인 경우가 정말 많거든요.
‘버스 팩터’가 뭐냐면
이 문제를 이야기할 때 자주 쓰는 말이 버스 팩터(bus factor) 예요. 좀 과격한 표현이긴 한데, “팀원 몇 명이 버스에 치이면 프로젝트가 멈추는가”를 나타내는 숫자예요. 버스 팩터가 1이라는 건, 그 한 사람이 아프거나 이직하거나 그냥 지쳐서 손을 놓는 순간 프로젝트도 멈춘다는 뜻이에요.
XKCD의 ‘Dependency’라는 만화를 보신 적 있을 거예요. 거대한 현대 디지털 인프라가 탑처럼 쌓여 있는데, 그 맨 아래를 받치는 건 네브래스카의 누군가가 2003년부터 묵묵히 관리해 온 작은 프로젝트 하나예요. 웃자고 그린 만화인데, 이번 분석은 그게 과장이 아니라는 걸 숫자로 보여 준 셈이에요.
실제로 무슨 일이 생길 수 있을까요?
그냥 ‘좀 불안하다’ 수준이 아니라는 건 과거 사건들이 이미 보여 줬어요. 아래는 이 글에 나온 목록과는 별개로 잘 알려진 사례들이에요.
Heartbleed (2014): 전 세계 웹 서버의 상당수가 쓰던 OpenSSL에서 치명적인 취약점이 발견됐어요. 당시 OpenSSL에서 일하던 정규 인력은 손에 꼽을 정도였고, 들어오는 후원금은 1년에 수천 달러 수준이었어요. 이 사건이 터진 뒤에야 리눅스 재단이 Core Infrastructure Initiative를 만들어 자금을 지원하기 시작했어요.
xz utils 백도어 (2024): xz는 거의 모든 리눅스 배포판에 들어가는 압축 라이브러리예요. 여기에 백도어가 심어질 뻔했어요. 공격자는 ‘Jia Tan’이라는 이름으로 2년 넘게 성실한 기여자 행세를 했어요. 그러면서 혼자 프로젝트를 관리하느라 지쳐 있던 메인테이너의 신뢰를 얻었고, 결국 공동 관리 권한을 받아 악성 코드를 숨겼어요. 마이크로소프트의 엔지니어 안드레스 프로인트(Andres Freund)가 SSH 로그인이 0.5초 정도 느려진 걸 수상하게 여겨 파고들었기에 망정이지, 아니었으면 전 세계 수많은 서버가 뚫릴 수도 있었어요.
curl: curl은 수십억 대의 기기에 들어가 있는데, 다니엘 스텐베리(Daniel Stenberg)가 25년 넘게 이끌어 왔어요. 그는 최근 AI로 만든 엉터리 보안 버그 리포트가 쏟아져 메인테이너의 시간을 빼앗는다는 문제를 공개적으로 지적하기도 했어요.
왜 이렇게 됐을까요?
구조적인 이유가 있어요. 첫째, 돈이 흐르지 않아요. 수많은 기업이 이 프로젝트들 위에서 매출을 올리지만, 정작 메인테이너에게 돌아가는 건 거의 없어요. 둘째, 눈에 띄지 않는 일이에요. 새 프레임워크는 GitHub 스타를 받지만, 20년 된 압축 라이브러리를 관리하는 일은 아무도 알아주지 않아요. 셋째, 새로 들어오기가 어려워요. 오래된 C 코드베이스에는 수십 년 동안 호환성을 지키려고 내린 결정들이 쌓여 있어요. 그래서 새 사람이 들어오기 힘들고, 결국 아는 사람만 계속 맡게 돼요.
업계가 손을 놓고 있는 건 아니에요. OpenSSF, 독일 정부가 만든 Sovereign Tech Agency, GitHub Sponsors 같은 곳들이 메인테이너에게 돈과 보안 지원을 연결하려고 해요. 다만 규모로 보면 아직 문제를 다 메우기엔 한참 부족하다는 평가가 많아요.
한국 개발자에게 주는 시사점
1. 우리 서비스의 버스 팩터부터 확인해 보세요. package.json이나 build.gradle에서 핵심 의존성 몇 개만 골라 GitHub에서 최근에 커밋한 사람이 몇 명인지 보세요. OpenSSF Scorecard 같은 도구를 쓰면 프로젝트의 유지보수 상태를 점수로 볼 수도 있어요. 생각보다 무서운 결과가 나올 수 있어요.
2. SBOM과 공급망 보안은 이제 기본기예요. SBOM(소프트웨어 자재 명세서)은 우리 소프트웨어에 어떤 오픈소스가 어떤 버전으로 들어 있는지 정리한 목록이에요. 국내에서도 정부가 SW 공급망 보안 가이드라인을 내놓았고, 공공·금융권을 중심으로 요구가 늘고 있어요. 취약점이 터졌을 때 “우리도 영향을 받나?”라는 질문에 5분 안에 답할 수 있어야 하거든요.
3. 작은 기여도 큰 힘이 돼요. 코드를 짜야만 기여할 수 있는 건 아니에요. 문서 오타 수정, 재현 가능한 버그 리포트, 이슈 정리만 해 줘도 혼자 버티는 메인테이너한테는 큰 도움이 돼요. 회사 차원에서는 핵심 의존성 프로젝트에 소액이라도 정기 후원하는 걸 검토해 볼 만해요. 장애가 한 번 났을 때 드는 비용에 비하면 훨씬 싸니까요.
마무리
한 줄 정리: 인터넷 기초 공사의 절반은 지친 한두 사람의 어깨 위에 있고, 그 사람이 손을 놓는 순간이 곧 우리 서비스의 리스크예요.
여러분 회사나 팀은 의존하는 오픈소스에 어떤 식으로든 돌려주고 있나요? 직접 메인테이너로 활동해 본 분이 있다면, 가장 힘들었던 점이 뭐였는지도 궁금해요.
🔗 출처: Hacker News