좋은 코드만 있으면 될까요?
오픈소스 라이브러리를 고를 때 보통 뭘 보세요? GitHub 스타 수, 최근 커밋 날짜, 문서가 잘 돼 있는지 정도일 거예요. 그런데 Codeberg에 올라온 한 블로그 글은 그보다 더 중요한 게 있다고 말해요. 바로 소프트웨어를 둘러싼 커뮤니티예요.
참고로 Codeberg는 독일의 비영리 단체가 운영하는 Git 호스팅 서비스예요. GitHub 같은 기업 플랫폼과 달리 커뮤니티가 직접 운영하는 곳이라, 이런 주제가 올라오는 게 자연스러운 곳이기도 하죠. 이 글을 계기로 커뮤니티가 왜 소프트웨어의 수명을 결정하는지 실제 사례와 함께 풀어볼게요.
코드는 사진, 커뮤니티는 심장
소프트웨어는 한 번 만들고 끝나는 물건이 아니에요. 보안 취약점이 나오면 패치해야 하고, 의존하는 라이브러리가 바뀌면 따라가야 해요. 새 OS나 런타임이 나오면 호환성도 맞춰야 하고요. 그러니까 코드는 '지금 이 순간의 사진'일 뿐이에요. 그 사진을 계속 새로 찍어줄 사람들이 있어야 프로젝트가 살아 있는 거예요.
여기서 자주 나오는 개념이 버스 팩터(bus factor)예요. 이게 뭐냐면 '몇 명이 갑자기 사라지면 프로젝트가 멈추는가'를 나타내는 숫자예요. 버스 팩터가 1이면 핵심 개발자 한 명이 번아웃으로 손을 놓는 순간 프로젝트가 멈춘다는 뜻이죠. 생각보다 많은 핵심 오픈소스가 이 상태예요.
이 위험이 현실로 드러난 게 2024년 xz utils 백도어 사건이에요. 이 프로젝트는 메인테이너 한 명이 거의 혼자 관리하고 있었는데요, 그가 지쳐 있던 틈을 노린 사람이 있었어요. 'Jia Tan'이라는 인물이 2년 넘게 성실한 기여자인 척 신뢰를 쌓았고, 결국 공동 메인테이너가 됐죠. 그리고 SSH 인증을 노리는 백도어를 심었어요. 다행히 한 엔지니어가 SSH 로그인이 0.5초쯤 느려진 걸 이상하게 여기고 파고든 덕분에 대형 사고 직전에 발견됐어요. 리뷰하는 눈이 충분히 많은 건강한 커뮤니티였다면 성공하기 훨씬 어려웠을 공격이에요.
포크가 살아남는 조건도 커뮤니티예요
최근 몇 년 동안 라이선스 변경 사태가 연달아 있었어요. HashiCorp가 Terraform의 라이선스를 BSL로 바꾸자 리눅스 재단 아래에서 OpenTofu라는 포크가 나왔어요. Redis가 라이선스를 바꿨을 때도 같은 방식으로 Valkey가 탄생했고요. 그 전에는 Elasticsearch에서 OpenSearch가 갈라져 나왔어요. 셀프 호스팅 Git 서비스인 Gitea에서는 Forgejo가 갈라져 나왔고요. 지금 Codeberg가 바로 이 Forgejo로 운영되고 있어요.
여기서 포인트는, 코드가 공개돼 있다고 포크가 저절로 성공하지는 않는다는 거예요. 포크는 누구나 버튼 한 번으로 만들 수 있어요. 하지만 기여자와 사용자가 따라오지 않으면 그냥 '복사본'으로 남거든요. 이 포크들이 살아남은 건 원래 프로젝트에 기여하던 사람들과 기업들이 함께 움직였기 때문이에요. 거꾸로 말하면, 한 회사가 거의 모든 걸 쥐고 있는 프로젝트는 그 회사의 결정 하나로 방향이 확 바뀔 수 있다는 뜻이기도 해요.
건강한 커뮤니티는 어떻게 알아볼까요?
몇 가지만 확인해 봐도 감이 와요. 먼저 이슈에 누가 답하는지 보세요. 매번 메인테이너 한 명만 답한다면 버스 팩터가 낮을 가능성이 커요. 커밋 기여자 분포도 중요해요. 한 사람이 커밋 대부분을 차지하고 있다면 위험 신호죠. 재단 소속인지, 한 회사가 소유하고 있는지도 장기적인 안정성에 영향을 줘요. 기여 가이드(CONTRIBUTING 문서)나 입문자용 이슈가 잘 정리돼 있다면 새로운 사람을 반기는 문화라는 신호예요. OpenSSF Scorecard나 CHAOSS 같은 도구를 쓰면 이런 지표를 좀 더 체계적으로 살펴볼 수 있어요.
한국 개발자에게 주는 시사점
첫째, 기술을 선택할 때 커뮤니티 건강도를 체크리스트에 넣어보세요. 실무에서는 지금 성능이 좋은 것보다 5년 뒤에도 관리되고 있을지가 더 중요할 때가 많거든요.
둘째, 사용자에서 기여자로 한 발짝만 나가보세요. 코드를 짜는 것만 기여가 아니에요. 버그 재현 방법을 꼼꼼히 남기는 것, 한국어 문서를 다듬는 것, 다른 사람 질문에 답하는 것 모두 커뮤니티를 튼튼하게 만드는 일이에요.
셋째, 이 이야기는 사내 프로젝트에도 그대로 적용돼요. 회사마다 '그 사람만 아는' 공통 모듈이 하나쯤 있잖아요. 사내 라이브러리도 문서와 리뷰 문화가 있어야 하고, 여러 사람이 함께 책임져야 오래 살아남아요.
마무리
한줄 정리: 코드는 복사할 수 있어도, 커뮤니티는 복사할 수 없어요.
여러분은 라이브러리나 프레임워크를 고를 때 커뮤니티를 얼마나 따져보시나요? 커뮤니티 덕분에 살아남은 프로젝트나, 커뮤니티가 무너지면서 함께 사라진 프로젝트를 겪어본 적이 있다면 들려주세요!
🔗 출처: Hacker News