오픈소스 프로젝트가 조용히 망하는 어이없는 방법들

잘 만든 프로젝트가 왜 갑자기 죽을까

깃허브에 가보면 별이 수천 개 달려 있는데 마지막 커밋이 2년 전인 프로젝트가 정말 많거든요. 처음엔 활발하게 돌아가다가 어느 순간 조용해지고, 이슈에는 답이 안 달리고, PR은 쌓이기만 하다가 결국 누군가 포크를 떠서 새로운 프로젝트가 생기는 그런 흐름이요. 오랫동안 오픈소스를 운영해온 개발자가 이런 현상을 정리한 글이 화제인데, "실력 부족이 아니라 정말 어이없는 이유로 망한다"는 게 핵심이에요.

오픈소스 프로젝트의 죽음은 보통 갑자기 오지 않아요. 코드가 나빠져서 죽는 게 아니라, 사람들 사이의 관계와 운영 방식이 망가지면서 천천히 죽어간다는 거죠. 이 글의 매력은 "이런 거 잘 알고 있다"고 생각하는 사람들도 실제로는 똑같은 함정에 빠진다는 점을 짚어준다는 데 있어요.

1인 메인테이너의 함정

가장 흔한 패턴은 메인테이너 한 명이 모든 걸 떠안는 거예요. 처음에는 좋아서 시작했는데, 어느 순간부터 "이슈가 100개 쌓였네", "PR 리뷰 밀렸네" 하면서 부담이 되거든요. 이게 뭐냐면 본업이 따로 있는 개발자가 퇴근 후나 주말에 무료 봉사로 코드를 만지다 보니 점점 지쳐가는 거예요. 영어권에서는 이걸 메인테이너 번아웃(maintainer burnout) 이라고 부르는데, 최근 몇 년 사이 오픈소스 생태계의 가장 큰 문제로 떠올랐어요.

해결책으로 흔히 "공동 메인테이너를 영입하자"고 하는데, 막상 하려고 보면 누구한테 권한을 줘야 할지 판단이 안 서거든요. 그래서 "내가 좀만 더 버티면 되겠지" 하다가 결국 어느 날 갑자기 손을 놓아버리는 식이에요. 글쓴이는 권한 위임을 미루는 것 자체가 프로젝트를 죽이는 가장 흔한 원인이라고 지적해요.

거버넌스 없이 시작한 죄

두 번째 함정은 거버넌스(governance) 가 없는 거예요. 거버넌스라고 하면 거창해 보이는데, 쉽게 말하면 "누가 무슨 결정을 어떻게 내릴지에 대한 규칙"이에요. 작은 프로젝트일 때는 메인테이너 마음대로 해도 별 문제가 없는데, 기여자가 늘어나고 사용자가 많아지면 "왜 이 PR은 머지하고 저건 안 하냐", "로드맵을 누가 정하냐" 같은 갈등이 생기거든요.

이때 명확한 규칙이 없으면 사람들이 떠나기 시작해요. 특히 회사에서 그 라이브러리를 쓰고 있는데 갑자기 호환성을 깨는 변경이 들어가면 "이 프로젝트는 못 믿겠다"는 인식이 퍼지고, 결국 포크가 떠지거나 대체 라이브러리로 옮겨가는 거죠. Babel, Webpack, Vue 같은 큰 프로젝트들이 어느 시점에서 명시적인 거버넌스 문서를 만들고 RFC 절차를 도입한 이유가 바로 이거예요.

기업 후원의 양날의 검

또 하나 의외의 죽음 원인이 "기업이 너무 도와주는 것"이에요. 한 회사가 풀타임 개발자를 붙여서 적극적으로 기여하면 처음엔 좋거든요. 빠르게 발전하고 기능이 늘어나니까요. 그런데 그 회사가 사업 전략을 바꾸면 어느 날 갑자기 지원이 끊겨버려요. 그러면 프로젝트는 자생력을 키울 시간도 없이 휘청거리는 거죠.

Meta가 React Native 운영 방식을 바꿨을 때, Google이 AngularJS에서 Angular로 넘어갈 때 커뮤니티가 받은 충격을 생각해보면 이해가 빨라요. 글쓴이는 "단일 기업에 의존하지 말고, 여러 회사가 분산해서 후원하는 구조를 만들어야 한다"고 강조해요. Linux Foundation이나 Apache Foundation 같은 중립 재단 아래로 들어가는 것도 좋은 선택지예요.

한국 개발자에게 주는 시사점

한국에서 활발한 오픈소스 프로젝트들도 비슷한 문제를 겪고 있어요. 토스, 카카오, 네이버 같은 회사들이 만든 라이브러리들이 점점 늘어나는데, 회사 내부 사정으로 메인테이너가 바뀌면 갑자기 업데이트가 멈추는 경우가 종종 있거든요. 만약 여러분이 회사에서 오픈소스 라이브러리에 의존하는 시스템을 만들고 있다면, 그 프로젝트의 메인테이너 수, 최근 커밋 빈도, 거버넌스 문서 유무를 한 번쯤 체크해보는 게 좋아요.

반대로 본인이 오픈소스를 운영하고 있다면, 부담스럽더라도 CONTRIBUTING.md와 GOVERNANCE.md 문서를 일찍 만들어두세요. 별 거 아닌 것 같은데, 이 두 파일이 있고 없고가 프로젝트 수명을 결정짓는 경우가 많거든요.

정리하며

오픈소스 프로젝트는 코드가 좋아서 살아남는 게 아니라, 사람과 시스템이 잘 굴러갈 때 살아남아요. 기술적 우수성보다 운영의 지속 가능성이 훨씬 중요하다는 얘기죠.

여러분이 자주 쓰는 오픈소스 라이브러리 중에 "이거 메인테이너 한 명 떠나면 끝나겠다" 싶은 게 있나요? 그리고 본인이 그런 프로젝트의 메인테이너라면 어떤 준비를 하고 계신가요?