끄적임 "클론 333, 방문자 2" — 퍼블릭 저장소 트래픽 숫자의 진실

웅파 2026-10-26 10:48:11 13

2026년 10월 26일 · @martin

333명이 내 코드를 받아갔다고?

결론부터 말하면, 퍼블릭 저장소의 클론 수는 관심도 지표가 아니다. 14일 동안 클론 333, 방문자 2. 이 두 숫자를 나란히 놓고 나서야 알았다.

AICreo를 퍼블릭 저장소(aivance-kr/AICreo)로 올려두고 별생각 없이 지내다가, 어느 날 Insights → Traffic 페이지를 열었다. 클론 그래프에 이렇게 찍혀 있었다.

Unique cloners in last 14 days: 333

솔직히 잠깐 설렜다. 홍보 한 번 안 했는데 2주 만에 333명이 받아갔다니. 어디 커뮤니티에 링크라도 돌았나 싶었다. 그런데 26년 개발하면서 배운 게 하나 있다면, 숫자가 너무 좋으면 일단 의심부터 하라는 거다.

바로 옆 Views 그래프를 봤다.

Unique visitors in last 14 days: 2

333 대 2. 이 비율이면 답은 정해져 있다. 사람은 보통 저장소 페이지를 먼저 열어 README를 훑어보고, 그다음에 clone한다. 페이지를 한 번도 안 열고 clone부터 하는 건 사람이 아니라 프로그램의 행동이다.

게다가 그 2명도 높은 확률로 나다. 다른 기기에서, 혹은 로그아웃 상태로 들어간 내 브라우저. 결국 사람은 많아야 2명, 나머지 330여 건은 전부 자동화라는 얘기다.

퍼블릭 저장소를 clone해 가는 자동화는 생각보다 종류가 많다. 정확한 비율은 GitHub이 알려주지 않지만, 용의자는 대략 이렇다.

용의자	왜 clone하나
CI/CD 체크아웃	GitHub Actions의 `actions/checkout`이 돌 때마다 clone으로 잡힌다. 러너 인스턴스나 IP가 바뀌면 별개의 cloner로 집계된다.
아카이버	Software Heritage 같은 곳이 공개 코드를 통째로 보존한다. 새 저장소나 새 커밋이 생기면 바로 가져간다.
코드 검색엔진	검색 인덱스를 만들기 위해 긁어간다.
AI 학습 데이터 수집기	공개 코드는 학습 데이터 후보다.
보안 스캐너	취약점, 라이선스, 시크릿 유출 탐지 서비스. 그리고 `.env`와 API 키를 노리는 악성 스캐너도 여기 섞여 있다.
미러·패키지 인덱서	미러 사이트, composer.json을 보고 붙는 패키지 관련 봇.

나는 집 우분투 서버에 GitHub 셀프호스티드 러너를 돌리고 있어서, 푸시할 때마다 CI 몫도 꽤 쌓였을 것이다. 나머지는 전부 외부 봇이라고 보면 된다.

한 줄로 요약하면, 퍼블릭 저장소는 사람이 보기 전에 기계가 먼저 읽는다.

Traffic 페이지 하나만 제대로 읽어도 대부분 판별된다.

Clones와 Views를 나란히 본다. Views는 한 자릿수에서 수십인데 cloner만 수백이면 거의 확실히 자동화다.
Referring sites와 Popular content를 본다. 비어 있거나 github.com만 있으면 외부에서 들어온 사람이 없다는 뜻이다.
Clone 그래프의 날짜를 본다. 푸시하거나 Actions가 돈 날과 같이 튀면 CI 몫이다. 커밋 없는 날에도 꾸준하면 외부 크롤러나 스캐너다.
Actions 실행 횟수를 센다. 14일간 몇 번 돌았는지 세면 CI 몫을 대략 뺄 수 있다.
Star, Fork, Watch를 본다. 이게 안 늘었다면 사람의 관심으로 보기 어렵다.

진짜 반응을 보고 싶다면 볼 숫자는 Unique visitors, Star, Fork, Referring sites다. Clones는 빼도 된다.

333이라는 숫자는 의미가 없지만, 그 숫자가 알려주는 사실 하나는 중요하다. 내 저장소의 커밋 이력 전체가 2주에 수백 번씩 어딘가로 복사되고 있다는 것.

그 복사본 중 일부는 시크릿만 골라 찾는 스캐너다. 개발 초기에 .env나 DB 비밀번호, API 키를 실수로 커밋했다가 다음 커밋에서 지웠다면? 파일은 사라졌어도 히스토리에는 그대로 남아 있다. 스캐너는 최신 코드가 아니라 히스토리를 본다.

그래서 퍼블릭 저장소라면 한 번은 히스토리 전체를 스캔해 두는 게 좋다.

gitleaks detect --source . -v

뭔가 걸리면 순서가 중요하다. 히스토리를 지우는 것보다 키 교체가 먼저다. 이미 수백 곳에 복사됐다고 가정해야 하기 때문이다.

다행히 내 저장소는 이상이 없었다. 히스토리를 훑어봐도 .env나 키가 커밋된 흔적은 없었다. 그래도 "없을 거야"와 "확인했다"는 다르다. 봇 수백 개가 다녀간 뒤라면 더더욱.

333을 보고 설렜던 건 5분 정도였다. 방문자 2를 확인하고 나서 내린 결론은 짧았다. 의미 없는 숫자구만.

그래도 헛걸음은 아니었다. 퍼블릭 저장소는 사람보다 기계가 훨씬 먼저, 훨씬 자주 읽는다는 걸 숫자로 확인했으니까. 1인 개발자에게 진짜 지표는 클론 수가 아니라 README를 읽고 Star를 누른 한 사람이다.

혹시 여러분 저장소에도 클론 수가 이상하게 높다면, 기뻐하기 전에 Views부터 열어보시길. 그리고 gitleaks 한 번 돌려보시길.