Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 이 시리즈를 쓰면서 실제로 겪은 것
스타 수는 무엇을 말하고 무엇을 말하지 않나
유지보수 신호를 직접 세는 법
라이선스는 상식으로 넘겨짚으면 안 된다
프로덕션 도입 전 체크리스트
마지막으로 — 숫자는 시점 값이다
링크

들어가며 — 이 시리즈를 쓰면서 실제로 겪은 것

앞의 다섯 편을 쓰면서 저장소 59개를 GitHub에서 직접 확인했습니다. 그 과정에서 배운 것이 목록 자체보다 유용할 수 있겠다고 생각했습니다.

가장 분명한 교훈은 이것입니다. 제가 안다고 생각한 정보의 상당수가 틀렸습니다. 저장소가 다른 계정으로 옮겨져 있었고, 라이선스가 제 기억과 달랐고, 활발하다고 여긴 프로젝트의 최근 푸시가 석 달 전이었습니다. 확인하지 않았다면 전부 그대로 썼을 것입니다.

스타 수는 무엇을 말하고 무엇을 말하지 않나

스타는 과거에 누군가 관심을 가졌다는 사실만 알려 줍니다. 되돌릴 일이 거의 없으므로 사실상 한 방향으로만 쌓입니다. 프로젝트가 방치되어도 숫자는 줄지 않습니다.

시리즈에서 나온 구체적인 예를 보겠습니다. open-telemetry/opentelemetry-collector는 스타가 7,377개로 4편 목록에서 가장 낮은 축이었습니다. 하지만 이 부품은 수많은 조직의 관측 파이프라인 한가운데에 있습니다. 조직이 저장소를 여러 개로 나눠 관심이 분산되었을 뿐입니다.

반대로 browser-use/browser-use는 2024년 10월에 만들어진 저장소가 스타 108,900개에 이르렀습니다. 큰 숫자지만, 그 숫자가 인터페이스 안정성을 보증하지는 않습니다.

스타는 규모를 재는 자가 아니라 화제성을 재는 자입니다.

유지보수 신호를 직접 세는 법

숫자로 확인할 수 있는 것부터 봅니다. 아래는 인증 없이도 동작하지만 시간당 요청 제한이 낮으니, 여러 저장소를 볼 계획이라면 토큰을 붙이는 편이 낫습니다.

# 예시: 기본 정보와 최근 릴리스 주기를 한 번에 확인
OWNER_REPO="ossf/scorecard"
curl -s "https://api.github.com/repos/${OWNER_REPO}" \
  | jq '{full_name, license: .license.spdx_id, stars: .stargazers_count, pushed_at, archived}'
curl -s "https://api.github.com/repos/${OWNER_REPO}/releases?per_page=5" \
  | jq -r '.[] | "\(.published_at[0:10])  \(.tag_name)"'

여기서 볼 것은 다음과 같습니다.

최근 커밋 날짜: 며칠 단위인지 몇 달 단위인지. 5편의 bentoml/BentoML은 확인 시점의 최근 푸시가 2026-08-03이었고, 1편의 Aider-AI/aider는 2026-05-22였습니다. 둘 다 죽었다는 뜻이 아니라, 더 봐야 한다는 신호입니다.
릴리스 간격: 날짜가 규칙적인지, 마지막 릴리스 이후 얼마나 지났는지. 커밋은 있는데 릴리스가 오래 없다면 사용자에게 전달되는 흐름이 막혔다는 뜻일 수 있습니다.
archived 값: 참이면 저장소가 동결된 상태입니다.
이슈 응답: 최근 열린 이슈에 메인테이너가 며칠 안에 반응하는지. 수가 아니라 응답 여부를 봅니다.
기여자 분포: 기여자 수보다 최근 병합을 실제로 수행한 사람의 수가 중요합니다. 기여자가 수천 명이어도 병합 권한이 두 명에게 몰려 있으면 버스 팩터는 2입니다.

마지막 항목은 자동화하기 어렵고 가장 중요합니다. 이 블로그의 버스 팩터에 관한 글에서 더 자세히 다뤘습니다.

ossf/scorecard(Apache-2.0, 스타 5,628개, 최근 푸시 2026-08-10 · 2026-08-12 기준)는 이런 점검 상당수를 자동화합니다. 다만 점수를 그대로 합격 기준으로 쓰기보다, 어떤 항목에서 감점됐는지를 읽는 도구로 쓰는 편이 낫습니다.

라이선스는 상식으로 넘겨짚으면 안 된다

이 시리즈에서 가장 많이 놀란 부분입니다. 59개 중 6개는 GitHub이 라이선스를 자동 분류하지 못했고, LICENSE 파일을 직접 열어 보니 내용이 제각각이었습니다.

open-webui/open-webui는 BSD 3조항 형태에 브랜딩 제거를 금지하는 조항이 더해져 있습니다. 사용 제한이 있으므로 OSI가 정의하는 오픈소스가 아닙니다.
oven-sh/bun의 LICENSE는 Bun 자체는 MIT이지만 LGPL-2 라이브러리를 정적 링크한다는 점과 그에 따른 조건을 함께 설명합니다.
zed-industries/zed는 LICENSE-GPL과 LICENSE-APACHE를 함께 두고 있습니다.
BerriAI/litellm과 SigNoz/signoz는 특정 디렉터리만 별도 라이선스를 따른다고 선언합니다.
pgvector/pgvector는 포스트그레스 계열의 허용적 라이선스 문구를 담고 있습니다.

정리하면 이렇습니다. GitHub 사이드바의 라이선스 표시는 요약이지 원문이 아닙니다. 그리고 소스를 볼 수 있다는 사실은 오픈소스라는 뜻이 아닙니다. AGPL처럼 조건이 강하지만 OSI 승인 오픈소스인 경우와, 사용 제한이 붙어 오픈소스가 아닌 경우를 구분하세요.

라이선스 전문을 직접 확인하고, 상업적 도입은 법무 검토를 거치세요. 이 글은 법률 자문이 아닙니다.

프로덕션 도입 전 체크리스트

기술 검토가 끝난 뒤, 도입을 결정하기 전에 다음을 문서로 남기시길 권합니다.

정확한 owner/repo 경로를 기록했는가. 이름이 비슷한 저장소나 오래된 경로를 참조하고 있지 않은가.
LICENSE 파일 원문을 읽었는가. 사내 사용, 재배포, 서비스 제공 중 우리 용도가 어디에 해당하는가.
최근 커밋, 최근 릴리스, 이슈 응답을 직접 확인했는가.
병합 권한이 몇 명에게 있는가. 그 사람들이 빠지면 어떻게 되는가.
프로젝트가 스스로 무엇이라고 말하는가. 1.0 이전이거나 실험적이라고 밝히고 있지는 않은가.
우리가 의존하려는 기능이 오픈소스 저장소 안에 있는가, 상용 제품에만 있는가.
이탈 비용은 얼마인가. 데이터를 표준 형식으로 꺼낼 수 있는가.
취약점이 공개되면 누가 언제 알게 되는가.

여덟 개 중 하나라도 답할 수 없다면, 그것이 다음에 확인할 항목입니다.

마지막으로 — 숫자는 시점 값이다

이 시리즈의 모든 수치에 날짜를 붙인 이유가 여기 있습니다. 스타 수와 최근 활동은 계속 변합니다. 날짜 없는 숫자는 검증할 수 없고, 검증할 수 없는 숫자는 근거가 되지 못합니다.

여러분이 이 글을 읽는 시점에 숫자는 이미 달라져 있을 것입니다. 그래서 목록보다 확인하는 절차가 오래 갑니다.

저장소 정보(스타 수·라이선스·최근 활동)는 2026-08-12에 GitHub에서 직접 확인한 시점 값입니다. 수치와 상태는 바뀝니다.

링크

시리즈: 이전 글 — 데이터와 ML 파이프라인 · 시리즈 첫 글 — AI 에이전트와 LLM 도구

이 블로그의 관련 글:

도구: curl 명령 빌더 · JSON 포매터