스타트업에서 '야생형 개발자'로 구르던 시절, 저는 금요일 오후 5시만 되면 등골이 서늘했습니다.
서비스가 터졌는데, 우리 코드가 문제가 아니었거든요.
믿고 쓰던 오픈소스 라이브러리의 메인테이너가 "더 이상 유지보수 안 합니다"라며 아카이브(Archive)를 선언하고 떠나버린 겁니다.
보안 이슈는 터졌는데 패치는 안 나오고, 포크(Fork) 떠서 직접 고치자니 레거시 코드가 너무 복잡했죠.
모래 위에 성을 쌓고 있었다는 걸 뼈저리게 느꼈습니다.
최근 체계가 잡힌 대기업으로 이직하고 나서야 알게 된 충격적인 사실이 하나 있습니다.
시니어급 팀장님들은 단순히 "기능이 잘 돌아가는가?"만 보지 않더군요.
그들은 이 오픈소스가 '내년에도 살아있을지'를 봅니다.
오늘은 그분들이 코드 리뷰나 아키텍처 설계 단계에서 몰래(?) 체크하는, 그리고 최근 제가 도입해보고 감탄한 도구인 OSS Sustain Guard가 보여주는 핵심 지표들을 공유하려 합니다.
1. "이 프로젝트, 버스 팩터(Bus Factor)가 1인가?" (유지보수자의 번아웃)
가장 먼저 보는 건 코드 퀄리티가 아닙니다.
바로 '사람'입니다.
수천 개의 스타(Star)를 받은 라이브러리라도, 알고 보면 단 한 명의 개발자가 퇴근 후 시간을 갈아 넣어 유지하는 경우가 허다합니다.
그 한 명이 아프거나 번아웃이 오면, 우리 서비스의 공급망(Supply Chain)이 끊기는 겁니다.
이 도구는 requirements.txt나 package.json을 긁어와서 유지보수자의 활동 건강 상태를 점수화합니다.
단순히 커밋 수가 아니라, 최근 활동의 지속성을 보고 "아, 이 메인테이너 지쳐가고 있구나"라는 신호를 잡아냅니다.
2. 좀비 프로젝트 판별 (Issue/PR 처리 속도와 커뮤니티)
이슈가 쌓이는 속도보다 닫히는 속도가 현저히 느리다면?
그건 이미 '좀비 프로젝트'가 되어가고 있다는 신호입니다.
우리는 흔히 npm install이나 pip install을 할 때, 당장 내 로컬에서 에러가 안 나면 안심하곤 합니다.
하지만 팀장님들은 "최근 3개월간 머지된 PR이 있는가?"를 집요하게 묻습니다.
OSS Sustain Guard는 CHAOSS(오픈소스 건강 분석 프로젝트) 지표를 기반으로, 커뮤니티가 실제로 살아 숨 쉬는지, 아니면 겉만 멀쩡한 유령 도시인지를 시각화해 줍니다.
단순한 그래프가 아니라, '안정성(Stability)'과 '기여자 경험(Contributor Experience)'이라는 관점에서 점수를 매겨주니 의사결정이 훨씬 빨라지더군요.
3. 자금의 흐름 (Funding & Sustainability)
이건 제가 스타트업 때는 전혀 신경 쓰지 못했던 부분입니다.
"돈이 도는 프로젝트인가?"
상업적 지원을 받거나, 기부(Sponsorship)가 활발한 프로젝트는 쉽게 망하지 않습니다.
반면, 아무런 경제적 보상 없이 열정 페이로만 돌아가는 프로젝트는 언제든 중단될 리스크(Risk)를 안고 있죠.
이 도구에는 재밌는 기능이 하나 있는데, 바로 '감사의 자판기(Vending Machine of Gratitude)'입니다.
우리가 의존하고 있는 라이브러리 중 자금 지원이 가장 시급한 곳을 찾아내 줍니다.
기업 입장에서는 리스크 관리를 위해 해당 프로젝트에 후원(Funding)을 하거나, 대체제를 찾을 명확한 근거가 됩니다.
우리는 코드를 빌려 쓰는 것이지, 소유한 게 아닙니다.
대기업에 와서 배운 건 기술적인 화려함보다 '지속 가능성(Sustainability)'의 중요성이었습니다.
아무리 화려한 AI 기능을 붙이고 MSA로 쪼개놔도, 기반이 되는 라이브러리가 무너지면 서비스는 멈춥니다.
이제 막 팀장이 되었거나, 시니어 개발자로 넘어가는 과도기에 있는 분들이라면 꼭 한 번쯤 고민해 보셨으면 합니다.
"지금 우리가 `import` 하는 저 라이브러리, 3년 뒤에도 살아있을까요?"
이 질문에 답을 할 수 없다면, 지금 당장 CI/CD 파이프라인에 이런 분석 도구를 태워보는 것도 좋은 '액션 아이템'이 될 겁니다.
우리의 퇴근 시간은 소중하니까요.
