1. 사이트 이름을 물었더니 가상의 만화 캐릭터가 탄생했다
한 작은 사이트가 AI를 이용해 글을 계속 발행하고 있었다. 성격을 만화 캐릭터에 빗대는 글도 있었고, 『치이카와』의 하치와레에 관한 글도 있었다. 그런데 다른 AI에 사이트 캐릭터를 물었더니 『치이카와』에 나오는 ‘귀찮은 하치와레’를 말하는 것이냐고 되물었다.
잠깐, 그게 누구야?
사이트의 자체 캐릭터가 어느새 다른 작품에 취직한 셈이다. 이력서도, 면접도 없었다. AI 혼자 인사 발령을 냈다.
다만 확인된 것은 AI가 그렇게 답했다는 사실뿐이다. 실제로 관련 글을 읽고 혼동했는지, 이름만 보고 추측했는지는 알 수 없다. 그런 이름의 공식 캐릭터가 존재한다는 증거도 없다. 자신감 있는 AI 답변과 확인된 사실은 다르다.
2. 그동안 뒤에서는 글 생산 공장이 돌아간다
글을 쓰고, 읽기 쉽게 고치고, 12개 언어로 온전히 옮기고, 검사하고, 발행하고, 독자에게 전달한다. 도중에 막히면 원인을 찾아 수정한 뒤 다시 확인한다.
작업 보고도 점점 장편이 된다.
담당 AI A: “발행 오류를 고쳤습니다.”
담당 AI B: “검사를 통과했습니다.”
담당 AI C: “다른 중단 원인을 발견했습니다.”
감독 AI: “수리 담당을 더 투입하죠.”
독자: “글보다 작업 일지가 먼저 전집으로 나오겠는데?”
웃긴 장면이지만 핵심은 분명하다. 수정 사항을 저장한 것과 실제 공개 페이지에서 제대로 작동하는 것은 별개다. 글 공장은 수리 공장이 되기도 한다.
3. “글이 1,900개?” 무엇을 세었는지 먼저 보자
흔히 ‘글 수’라고 부르는 숫자는 최소한 다섯 종류다.
- 원본 글: 서로 다른 주제를 다룬 원고.
- 언어별 페이지: 같은 글을 다른 언어로 제공한 페이지.
- 완성했지만 미공개: 검사나 발행을 기다리는 원고.
- 공개 완료: 독자가 실제로 열 수 있는 페이지.
- 사이트 경로: 메뉴나 기능 페이지까지 포함할 수 있는 숫자.
예를 들어 원본 1,000개를 12개 언어로 모두 발행하면 언어별 글 페이지가 최대 12,000개가 된다. 그렇다고 독립적인 생각이 12,000개라는 뜻은 아니다.
한 운영 기록에는 사이트 경로 15,862개가 있었다. 그러나 일본어 글 15,862개라는 뜻은 아니다. ‘1,900개’라는 주장도 날짜, 계산 단위, 공개 여부를 알아야 검증할 수 있다. 숫자를 그냥 더하면 통계 담당자가 울게 된다.
4. GitHub 저장소 크기는 약 2.46GB였다
익명화한 사례의 GitHub 기록에는 2,400,972KiB가 표시됐다. 약 2.29GiB, 십진법으로 약 2.46GB다. 기준일은 2026년 10월 8일이다.
“글은 문자뿐인데 왜 이렇게 크지?”라고 생각하기 쉽다.
저장소에는 원고 외에도 프로그램, 번역 자료, 발행 목록, 검사 기록, 그림과 음성 파일, 이전 변경 기록이 들어갈 수 있다. 하지만 표시된 총량만으로 어떤 파일이 공간을 많이 차지했는지는 알 수 없다. 컴퓨터의 폴더 크기와 GitHub의 표시 수치도 같은 측정값은 아니다.
글: “저는 몇 KB밖에 안 돼요.”
기록: “옛날 버전도 보관했지.”
번역: “열한 명 더 데려왔어요.”
창고: “처음 듣는데요?”
5. 결론: 무료 저장소는 ‘총 5GB를 넘으면 과금’이 아니다
GitHub는 일반 Git 저장소에 대해 무료 플랜 전체에 적용되는 단일한 ‘총 몇 GB’ 과금 기준을 제시하지 않는다. 5GB는 요금 청구 시작점이 아니라 강력한 크기 권장 기준이다.
공식 문서에서는 1GB 미만이 이상적이며 5GB 미만을 강하게 권장한다. 다른 제한 문서에는 압축된 Git 기록의 디스크상 크기를 10GB 이하로 유지하라는 권장 기준도 있다. 10GB가 보장된 무료 용량이라는 뜻은 아니다.
지나치게 큰 저장소가 시스템에 부담을 주면 개선을 요구받을 수도 있다. ‘5GB면 바로 유료’도 틀렸고, ‘무료니까 무한 창고’도 틀렸다.
6. 실제 제한은 각각 다른 곳에 있다
| 대상 | 기준 또는 무료 포함량 |
|---|---|
| 일반 저장소 전체 | 단일 무료 총용량 과금선 없음. 이상적 기준 1GB 미만, 5GB 미만 강력 권장 |
| Git 기록의 디스크상 크기 | 권장 최대 10GB. 유료 전환선이 아님 |
| 일반 파일 하나 | 50MiB 초과 경고, 100MiB 초과 차단. 웹 업로드는 25MiB까지 |
| 한 번의 전송 | 2GiB 제한 |
| 대용량 파일용 Git LFS | 무료 플랜에 저장 10GiB, 전송 10GiB 포함. 일반 Git과 별도 |
| GitHub Actions 실행 결과물 | 무료 저장 공간 500MB, 일반적인 월 무료 실행 시간 2,000분 |
모두 같은 용량통이 아니다. Git LFS와 Actions 등은 초과 사용 시 상품별 결제 및 예산 설정에 따라 처리된다. 일반 Git 저장소가 2.46GB라고 해서 Actions의 500MB를 초과한 것은 아니다. 반대로 일반 저장소가 5GB 미만이어도 다른 무료 한도를 소진할 수 있다.
7. 글 수보다 저장소가 빨리 커지는 이유
Git은 현재 파일뿐 아니라 바뀌어 온 과정도 기록한다. 커다란 목록 파일을 매시간 수정하면 최신 버전에서는 한 개만 보여도 과거 버전은 기록에 남을 수 있다. 글 수정, 번역 재생성, 검사 로그 추가, 결과물 재저장이 쌓이면 글 수와 용량이 같은 속도로 늘지 않는다.
물론 Git은 내용을 압축하고 비슷한 기록을 효율적으로 저장한다. 파일을 한 번 고쳤다고 저장소가 반드시 두 배가 되지는 않는다. 실제 원인은 크기 분석으로 확인해야 한다.
변경 이력이 중요한 원본 글과 프로그램은 Git에 보관한다. 자주 다시 만드는 자료와 큰 미디어 파일은 상황에 따라 Git 바깥의 보관 장소를 고려한다.
8. 용량보다 먼저 작업 충돌이 문제가 될 수 있다
여러 AI가 거의 동시에 같은 파일을 바꾸면 변경이 충돌할 수 있다. 한 수리가 성공해도 다른 작업은 낡은 발행 목록을 보고 중단될 수 있다. 원고는 완성됐는데 공개 페이지는 옛 버전인 상황도 생긴다.
이를 전부 ‘GitHub 용량 부족’으로 설명하면 원인을 놓친다. 파일 크기, 수정 빈도, 동시 작업, 발행 상태는 서로 다른 문제다.
확인할 순서는 네 가지다. 최신 원고가 있는가? 검사를 통과했는가? 실제 배포되었는가? 공개 페이지가 새 본문을 보여 주는가? ‘수리 완료!’ 축하는 마지막 항목을 확인한 다음이면 충분하다.
9. 무료 운영을 오래 유지하는 네 가지 관리법
먼저 측정한다. 전체 표시 크기만 보고 삭제하지 말고 큰 파일과 이전 기록을 살핀다. GitHub가 소개하는 git-sizer도 도움을 줄 수 있다.
일회성 결과물은 따로 보관한다. 거대한 자동 생성 목록, 실행 로그, 이미지, 오디오를 모두 Git 기록에 쌓을 필요는 없다.
불필요한 전체 재작성을 줄인다. 관련 없는 수정 때문에 거대한 공용 목록을 다시 만들지 않는다. 충돌하면 현재 상태를 다시 읽고 실제 결과를 측정한다.
기록 삭제는 신중히 한다. 최신 파일을 삭제해도 옛 커밋에 남아 있을 수 있다. 기록 전체를 바꾸면 공유된 참조와 협업자의 사본이 깨질 수 있으니 먼저 영향과 백업을 확인한다.
10. 중요한 건 글 수보다 독자에게 도착한 내용이다
원본 글이 수천 개, 번역 페이지가 수만 개여도 방문자가 자동으로 늘지는 않는다. 검색되는가? 사실이 맞는가? 각 언어가 자연스러운가? 같은 말을 반복하지 않는가?
Google의 공식 안내는 독자에게 도움이 되는 독창적인 내용을 중요하게 본다. 검색 순위 조작을 주목적으로 가치 없는 페이지를 대량 생산하는 행위는 문제가 된다. AI 사용 자체가 문제가 아니라 독자 가치 없는 대량 생산이 위험한 것이다.
하치와레를 다룬 글을 보고 AI가 사이트 캐릭터를 ‘귀찮은 하치와레’로 만들어 버린 일도 비슷하다. 재미있는 농담이지만, 공식 설정으로 믿어서는 안 된다.
글 공장: “글을 늘리겠습니다.”
GitHub: “변경 기록도 늘어나죠.”
검사 담당: “오류를 줄이겠습니다.”
검색 AI: “새 캐릭터도 늘리겠습니다.”
모두: “그건 늘리지 마!”
정리하면 5GB는 GitHub 무료 플랜의 과금 벽이 아니다. 저장 용량, 발행 상태, 글의 품질, AI의 착각은 각각 따로 검증해야 한다. 성공은 저장한 숫자가 아니라 독자에게 정확히 전달한 내용으로 판단하자.
