무료 정적 블로그와 사이트 운영 한계 분석 (Free Static Blog Hosting Limit Analysis)

개요

이 문서는 GitHub, GitLab, Cloudflare, Cloudinary의 무료 플랜만 사용해서 블로그/사이트를 운영한다고 가정했을 때, 실제로 어디까지 가능한지와 어디서 병목이 생기는지를 정리한 운영 가이드다.

핵심 전제는 다음과 같다.

운영 형태는 정적 사이트 중심이다.
결제 정보 없이 쓸 수 있는 범위만 본다.
개인 1인 운영을 기본으로 한다.
블로그 본문은 Markdown 또는 정적 생성기(Hugo, Jekyll, Astro, Next static export 등)로 관리한다.
이미지는 가능하면 Cloudinary 또는 외부 최적화 경로를 사용하고, 저장소에는 가급적 가벼운 정적 자산만 둔다.

한 문장 결론은 이렇다.

텍스트 중심의 개인 블로그라면 무료만으로도 꽤 넉넉하게 운영 가능하다. 다만 이미지가 많아지고, 자동화 배포가 잦아지고, 서버사이드 기능이 늘어날수록 Cloudinary, GitLab CI/CD, Cloudflare Workers 쪽이 먼저 한계에 닿는다.

운영 전제와 판단 기준
서비스별 무료 한계 요약
실무에서 체감되는 병목 포인트
블로그 규모별 현실적 운영 시나리오
추천 조합과 우선순위
운영 체크리스트
Mermaid 다이어그램
요약 도표
인사이트와 핵심 정리
해당 문서의 한계점
참고자료 & 링크
태그

1. 운영 전제와 판단 기준

1.1 이 문서가 다루는 범위

이 문서는 “무료로 끝까지 버티는 법”이 아니라, 무료 플랜의 숫자를 실무 감각으로 해석하는 법에 초점을 둔다.

즉, 아래처럼 단순 숫자만 보는 방식은 피한다.

저장 용량만 본다
트래픽 숫자만 본다
빌드 횟수만 본다
파일 개수만 본다

실제로는 다음의 조합이 중요하다.

저장소 크기
이미지 저장 방식
배포 빈도
빌드 시간
정적 파일 개수
사용자 방문 패턴
변환/리사이즈 여부
자동화 스크립트 사용 여부

1.2 가장 중요한 해석 원칙

텍스트는 거의 안 막힌다.
Markdown 위주의 블로그는 용량보다 운영 방식이 더 중요하다.
이미지가 먼저 병목이 된다.
저장소, CDN, 이미지 변환, 외부 전송량이 가장 먼저 압박을 만든다.
빌드는 생각보다 빨리 소모된다.
글 자체보다 CI/CD 파이프라인이 더 자원을 먹는다.
정적 사이트는 무료 플랜과 궁합이 좋다.
서버가 없으니 과금 요소가 줄어든다.
“하나의 메인 블로그 + 몇 개의 실험 사이트” 수준이 가장 안정적이다.

2. 서비스별 무료 한계 요약

2.1 GitHub

GitHub Pages는 GitHub 저장소의 HTML, CSS, JavaScript 파일을 기반으로 사이트를 게시하는 정적 호스팅 서비스다. 공개 저장소의 GitHub Free에서 사용할 수 있고, Pages는 정적 사이트를 전제로 한다.

공식적으로 확인되는 핵심 제한

한 계정당 사용자/조직 사이트는 1개만 만들 수 있다.
게시된 GitHub Pages 사이트 크기는 1GB 이하여야 한다.
GitHub Pages source repository 권장 크기는 1GB다.
월 대역폭 소프트 한도는 100GB다.
빌드 소프트 한도는 시간당 10회다.
다만 커스텀 GitHub Actions 워크플로로 빌드·배포하면 이 빌드 한도는 적용되지 않는다.
배포는 10분을 넘으면 타임아웃된다.
일반 저장소에서는 50MiB 초과 파일에 경고가 뜨고, push 전체 크기 2GiB는 강하게 제한된다.
저장소 크기는 온디스크 기준 10GB 이하가 권장된다.

실무적 해석

텍스트 위주 블로그라면 사실상 굉장히 넉넉하다.
이미지까지 저장소에 넣기 시작하면 1GB는 생각보다 빨리 찬다.
글 수가 많아도 Markdown만 쌓이면 괜찮지만, 원본 이미지와 썸네일이 저장소 안에 같이 쌓이면 금방 무거워진다.
따라서 GitHub Pages는 본문 저장소, 이미지는 외부 호스팅 또는 Cloudinary로 분리하는 쪽이 오래 간다.

2.2 GitLab

GitLab Pages는 GitLab 저장소에서 정적 웹사이트를 게시하는 기능이다. GitLab.com 기준으로 Pages는 정적 사이트 배포에 사용된다.

공식적으로 확인되는 핵심 제한

GitLab.com Free tier의 각 프로젝트는 10GiB의 무료 저장소를 가진다. Git 저장소와 LFS가 여기에 포함된다.
GitLab.com의 Pages 사이트 최대 크기는 1GB다.
GitLab Free tier의 compute minutes는 월 400분이다.
job artifact 기본 최대 크기는 100MB다.
Free tier의 private top-level namespace는 최대 5명 사용자 제한이 있다.
2026-01-27 이후 생성된 Free tier 계정은 top-level groups 3개로 제한된다.

실무적 해석

GitLab은 Pages 자체보다 CI/CD minutes가 먼저 체감된다.
빌드가 1분 내외라면 한 달 400분은 꽤 넉넉하다.
빌드가 5분씩 걸리면 1달에 약 80회 수준으로 줄어든다.
정적 블로그에서 이미지 최적화, 스크린샷 생성, 미리보기 다중 배포를 많이 하면 무료 한계가 빨리 보인다.
개인 블로그 하나 운영하는 용도라면 충분하지만, 무거운 파이프라인을 돌리는 순간 체감이 확 달라진다.

2.3 Cloudflare

Cloudflare Free Plan은 기본적인 SSL, CDN, DDoS 보호를 제공한다. 블로그/사이트 운영 관점에서는 Cloudflare Pages와 Workers를 함께 보는 것이 중요하다.

Cloudflare Pages 무료 플랜 핵심 제한

Cloudflare Pages 사이트는 무료 플랜에서 파일 수 20,000개까지 가능하다.
무료 플랜 배포 한도는 월 500 deploys다.
계정당 Pages 프로젝트 수는 soft limit 100개다.
무료 플랜에서 Pages 프로젝트와 관련된 사용량 초과가 잦으면 생성 제한이 걸릴 수 있다.

Cloudflare Workers 무료 플랜 핵심 제한

Workers Free plan은 하루 100,000 requests까지다.
초과하면 해당 일자에 오류가 날 수 있다.
일반적으로 초당 요청 수 자체에는 일반 한도가 없다.
요청당 CPU time은 10ms 수준으로 매우 짧다.

실무적 해석

Cloudflare Pages는 정적 사이트에 아주 잘 맞는다.
파일 수 20,000개는 텍스트 블로그에는 넉넉하지만, 이미지 변형 파일을 많이 생성하면 금방 가까워질 수 있다.
배포 500회/월은 사람이 쓰는 블로그에는 매우 넉넉하지만, PR마다 자동 배포하는 개발 워크플로가 많으면 신경 써야 한다.
Workers Free는 가벼운 리다이렉트, 폼 처리, 간단한 API, 접근 제어에 좋다. 무거운 서버사이드 렌더링은 무료 한도에서 오래 버티기 어렵다.

2.4 Cloudinary

Cloudinary는 이미지/비디오 자산을 저장, 변환, 전송하는 미디어 플랫폼이다. 무료 플랜의 핵심은 크레딧 기반이라는 점이다.

공식적으로 확인되는 핵심 제한

무료 플랜은 신용카드 없이 가입 가능하다.
무료 플랜은 월 25 credits를 제공한다.
1 credit은 다음 중 하나의 기준으로 해석된다.
- 1,000 transformations
- 1 GB managed storage
- 1 GB image bandwidth
- 무료 플랜의 video bandwidth는 1 GB 기준
Cloudinary의 credits는 storage, bandwidth, transformations에 동시에 소모된다.

실무적 해석

Cloudinary 무료 플랜은 “이미지 몇 장 저장” 수준으로 보면 넉넉해 보이지만, 실제로는 전송량과 변환 횟수가 같이 줄어든다.
이미지가 많지 않은 개인 블로그에는 충분히 유효하다.
하지만 고해상도 사진, 여러 사이즈 파생본, 방문자 수가 많아지면 25 credits는 생각보다 빨리 줄어든다.
Cloudinary는 “원본 저장소”라기보다 실사용 이미지 파이프라인으로 생각하는 편이 맞다.

3. 실무에서 체감되는 병목 포인트

3.1 저장소가 먼저 막히는 경우

가장 흔한 오해는 “글이 많아지면 저장소가 먼저 찬다”는 생각이다. 실제로는 텍스트만이면 꽤 오래 간다.

예를 들어:

Markdown 글 1개 = 수십 KB ~ 수백 KB
이미지 1장 = 200KB ~ 5MB 이상
썸네일/리사이즈/웹용 복사본 = 이미지 수만큼 증가

즉, 저장소를 무겁게 만드는 건 글이 아니라 이미지와 파생 파일이다.

3.2 빌드가 먼저 막히는 경우

정적 블로그는 배포 자체는 단순하지만, 다음이 붙으면 금방 무거워진다.

이미지 리사이즈를 빌드 과정에서 수행
RSS, sitemap, search index를 매번 재생성
다중 환경 배포
미리보기(PR preview) 다중 생성
외부 API를 빌드 시점에 호출

이런 구조는 GitLab CI/CD minutes나 Cloudflare deploy 수에 민감해진다.

3.3 이미지 전송량이 먼저 막히는 경우

Cloudinary는 저장보다 전송량이 먼저 문제 되는 일이 많다.

예시:

글 1개당 이미지 3장
이미지 평균 300KB
페이지 1회 로드당 이미지 전송량 900KB

이 경우 25GB image bandwidth는 대략 다음 정도다.

25GB ≈ 25,000MB
25,000MB ÷ 0.9MB ≈ 약 27,700 페이지뷰

즉, 이미지가 많고 방문이 꾸준하면 Cloudinary 무료 플랜은 생각보다 빨리 닿는다.

이미지를 더 작게 만들면 상황은 크게 좋아진다.

이미지 평균 100KB, 페이지당 3장이라면
25GB ÷ 0.3MB ≈ 약 83,300 페이지뷰

그래서 Cloudinary 무료 플랜은 이미지를 얼마나 잘 압축하고, 몇 장을 쓰고, 얼마나 자주 변환하는지가 핵심이다.

4. 블로그 규모별 현실적 운영 시나리오

4.1 시나리오 A: 텍스트 중심 개인 블로그

구성:

글 1,000개 이상
글당 이미지 0~2장
전체 이미지 수 100~300장 수준
월 방문자 수 5,000~20,000명
정적 생성기 사용
배포는 글 쓸 때만 실행

판단:

GitHub Pages: 매우 안정적
GitLab Pages: 매우 안정적
Cloudflare Pages: 매우 안정적
Cloudinary: 이미지 최적화만 잘하면 충분

이 단계에서는 “무료라서 못 쓰는” 느낌이 거의 없다.

4.2 시나리오 B: 이미지가 많은 개인 블로그

구성:

글 300~800개
글당 이미지 3~10장
이미지 원본과 웹용 버전을 함께 관리
월 방문자 수 10,000~30,000명
모바일 사용자가 많아 이미지 전송량이 큼

판단:

호스팅( GitHub Pages / GitLab Pages / Cloudflare Pages )은 대체로 괜찮다
병목은 Cloudinary 또는 저장소 이미지 정책에서 먼저 온다
이미지가 Cloudinary를 통해 직접 서빙되면 bandwidth가 먼저 닿을 가능성이 높다

이 경우 운영 원칙은 간단하다.

원본은 보관용으로만 두고
실제 배포용은 최대한 작게 만들고
같은 이미지를 여러 크기로 무한 생성하지 말 것

4.3 시나리오 C: 자동화가 많은 개발형 블로그

구성:

PR마다 preview deployment 생성
매일 여러 번 커밋
빌드 시 이미지 처리, 문서 변환, 검색 인덱싱 수행
GitHub Actions / GitLab CI / Cloudflare Functions 사용

판단:

Cloudflare Pages는 deploy 수 500/월을 먼저 볼 수 있다
GitLab은 compute minutes 400분/월이 먼저 체감될 수 있다
GitHub Pages는 Actions 기반이면 상대적으로 편하지만, 빌드 방식에 따라 제한 체감이 달라진다

즉, 이 단계부터는 “글 운영”이 아니라 “소규모 플랫폼 운영”이 된다.

5. 추천 조합과 우선순위

5.1 가장 무난한 조합

GitHub Pages + Cloudflare(도메인/보호/캐시) + Cloudinary(이미지)

이 조합이 좋은 이유:

정적 블로그와 궁합이 좋다
커뮤니티/예제가 많다
운영 난이도가 낮다
개인 블로그를 오랫동안 유지하기 쉽다

5.2 CI/CD를 자주 쓰는 조합

GitLab Pages + Cloudflare + Cloudinary

이 조합이 좋은 이유:

CI/CD 중심 운영에 강하다
파이프라인을 세밀하게 관리하기 쉽다
다만 무료 compute minutes를 의식해야 한다

5.3 Cloudflare 중심 조합

Cloudflare Pages + Workers(필요할 때만) + Cloudinary

이 조합이 좋은 이유:

배포가 가볍고 빠르다
정적 사이트 배포가 깔끔하다
간단한 동적 기능을 Workers로 붙일 수 있다

주의점:

파일 수와 배포 횟수를 관리해야 한다
Workers를 많이 쓰는 구조라면 무료 100k requests/day를 넘기기 쉬워진다

5.4 운영 우선순위

정적 콘텐츠는 호스팅 서비스로 보낸다
이미지는 Cloudinary나 별도 경로로 분리한다
빌드와 배포는 꼭 필요한 순간에만 돌린다
서버사이드 로직은 최소화한다
자동 생성 파일을 무한히 늘리지 않는다

6. 운영 체크리스트

6.1 저장소 체크

Markdown 본문만 저장소에 들어가는가
이미지 원본이 저장소를 비대하게 만들고 있지 않은가
50MiB 초과 파일이 섞여 있지 않은가
저장소 온디스크 10GB를 넘어갈 가능성이 있는가

6.2 배포 체크

한 달에 몇 번 deploy 되는가
PR preview가 너무 자주 생성되지 않는가
빌드 시간이 1회당 몇 분인지 아는가
GitLab compute minutes 또는 Cloudflare deploy count를 의식하고 있는가

6.3 이미지 체크

원본을 그대로 배포하지 않는가
썸네일과 본문 이미지를 구분하는가
WebP / AVIF 같은 웹 친화 포맷을 쓰는가
Cloudinary에서 파생본을 과도하게 만들고 있지 않은가

6.4 트래픽 체크

월간 페이지뷰가 대략 얼마인지 아는가
이미지 1회 로드당 전송량이 얼마인지 아는가
Cloudinary bandwidth를 계산해 봤는가
Workers를 쓰면 요청당 CPU 시간이 짧다는 점을 반영했는가

7. Mermaid 다이어그램

%%{init: { "theme": "default", "flowchart": { "nodeSpacing": 20, "rankSpacing": 20 } }}%%
flowchart TD
    A["블로그 운영 시작"] --> B{"정적 사이트인가"}
    B -->|예| C["GitHub Pages / GitLab Pages / Cloudflare Pages"]
    B -->|아니오| D["서버형 호스팅 필요"]

    C --> E{"이미지가 많은가"}
    E -->|예| F["Cloudinary 사용"]
    E -->|아니오| G["저장소 중심 운영도 가능"]

    F --> H{"배포가 자주 일어나는가"}
    G --> H

    H -->|예| I["GitLab compute minutes / Cloudflare deploy 수 / GitHub Actions 빌드 한도 점검"]
    H -->|아니오| J["무료 플랜으로 장기 운영 가능"]

    I --> K["빌드 시간 단축 / 이미지 외부화 / 자동화 축소"]
    J --> L["1인 블로그 운영에 적합"]

8. 요약 도표

서비스	무료 핵심 한계	실무 체감 병목	개인 블로그 기준 권장 해석
GitHub Pages	사이트 1GB, bandwidth 100GB/mo, build 10회/시간, 1개 user/org site	이미지가 저장소를 키울 때	텍스트 중심 블로그에는 매우 넉넉
GitLab Pages	Pages site 1GB, 저장소+LFS 10GiB, compute minutes 400분/mo	CI/CD가 무거울 때	빌드가 짧으면 개인 운영에 충분
Cloudflare Pages	20,000 files/site, 500 deploys/mo, 100 projects/account soft limit	배포 횟수와 파일 수	정적 사이트에 매우 잘 맞음
Cloudflare Workers	100,000 requests/day, 10ms CPU/invocation	SSR 또는 무거운 로직	간단한 기능 추가용으로 적합
Cloudinary	25 credits/mo	이미지 전송량, 변환, 저장 동시 소모	이미지가 적으면 충분, 사진형 블로그는 빨리 압박

9. 인사이트와 핵심 정리

9.1 가장 중요한 결론

무료 플랜만으로도 개인 블로그 1개는 충분히 운영할 수 있다. 다만 그 전제는 분명하다.

정적이어야 한다
이미지가 과하지 않아야 한다
배포가 너무 잦지 않아야 한다
CI/CD가 무겁지 않아야 한다
외부 API 호출이 많지 않아야 한다

9.2 어느 서비스가 먼저 한계에 닿는가

보통 순서는 이렇다.

Cloudinary: 이미지 전송량과 변환량
GitLab CI/CD: compute minutes
Cloudflare Pages / Workers: deploy 수, 파일 수, 요청 수
GitHub Pages: 저장소가 무거워질 때, 또는 대역폭이 커질 때

9.3 실제 운영에서 가장 중요한 감각

“무료라서 아무것도 못 한다”가 아니라, **“무엇이 비용을 만드는지 이해하면 무료로도 꽤 멀리 간다”**가 맞다.

특히 개인 블로그는 다음 원칙을 지키면 오래 간다.

글은 Git 저장소에 둔다
이미지는 최적화해서 외부에서 서빙한다
빌드는 꼭 필요한 순간만 돌린다
배포 수를 줄인다
페이지를 가볍게 유지한다

10. 해당 문서의 한계점

각 서비스의 무료 정책은 변경될 수 있으므로, 최종 운영 전에는 반드시 공식 문서를 다시 확인해야 한다.
Cloudinary는 credit 기반이라 실제 체감은 이미지 크기, 변환 방식, 방문자 행동에 따라 크게 달라진다.
GitHub/GitLab/Cloudflare는 기능이 계속 추가·변경되므로, 이 문서는 “운영 판단 기준”이지 영구 규격표가 아니다.
정확한 트래픽 예측은 실제 페이지 무게, 이미지 장수, 캐시 전략을 반영해야 한다.

11. 참고자료 & 링크

GitHub Pages limits
- https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits
What is GitHub Pages?
- https://docs.github.com/en/pages/getting-started-with-github-pages/what-is-github-pages

12. 태그

#정적사이트 #블로그운영 #무료플랜 #사용량제한 #GitHub #GitLab #Cloudflare #Cloudinary #static-site #blog-hosting #free-tier #usage-limits

개요#

목차#

1. 운영 전제와 판단 기준#

1.1 이 문서가 다루는 범위#

1.2 가장 중요한 해석 원칙#

2. 서비스별 무료 한계 요약#

2.1 GitHub#

공식적으로 확인되는 핵심 제한#

실무적 해석#

2.2 GitLab#

공식적으로 확인되는 핵심 제한#

실무적 해석#

2.3 Cloudflare#

Cloudflare Pages 무료 플랜 핵심 제한#

Cloudflare Workers 무료 플랜 핵심 제한#

실무적 해석#

2.4 Cloudinary#

공식적으로 확인되는 핵심 제한#

실무적 해석#

3. 실무에서 체감되는 병목 포인트#

3.1 저장소가 먼저 막히는 경우#

3.2 빌드가 먼저 막히는 경우#

3.3 이미지 전송량이 먼저 막히는 경우#

4. 블로그 규모별 현실적 운영 시나리오#

4.1 시나리오 A: 텍스트 중심 개인 블로그#

4.2 시나리오 B: 이미지가 많은 개인 블로그#

4.3 시나리오 C: 자동화가 많은 개발형 블로그#

5. 추천 조합과 우선순위#

5.1 가장 무난한 조합#

5.2 CI/CD를 자주 쓰는 조합#

5.3 Cloudflare 중심 조합#

5.4 운영 우선순위#

6. 운영 체크리스트#

6.1 저장소 체크#

6.2 배포 체크#

6.3 이미지 체크#

6.4 트래픽 체크#

7. Mermaid 다이어그램#

8. 요약 도표#

9. 인사이트와 핵심 정리#

9.1 가장 중요한 결론#

9.2 어느 서비스가 먼저 한계에 닿는가#

9.3 실제 운영에서 가장 중요한 감각#

10. 해당 문서의 한계점#

11. 참고자료 & 링크#

12. 태그#

개요

목차

1. 운영 전제와 판단 기준

1.1 이 문서가 다루는 범위

1.2 가장 중요한 해석 원칙

2. 서비스별 무료 한계 요약

2.1 GitHub

공식적으로 확인되는 핵심 제한

실무적 해석

2.2 GitLab

공식적으로 확인되는 핵심 제한

실무적 해석

2.3 Cloudflare

Cloudflare Pages 무료 플랜 핵심 제한

Cloudflare Workers 무료 플랜 핵심 제한

실무적 해석

2.4 Cloudinary

공식적으로 확인되는 핵심 제한

실무적 해석

3. 실무에서 체감되는 병목 포인트

3.1 저장소가 먼저 막히는 경우

3.2 빌드가 먼저 막히는 경우

3.3 이미지 전송량이 먼저 막히는 경우

4. 블로그 규모별 현실적 운영 시나리오

4.1 시나리오 A: 텍스트 중심 개인 블로그

4.2 시나리오 B: 이미지가 많은 개인 블로그

4.3 시나리오 C: 자동화가 많은 개발형 블로그

5. 추천 조합과 우선순위

5.1 가장 무난한 조합

5.2 CI/CD를 자주 쓰는 조합

5.3 Cloudflare 중심 조합

5.4 운영 우선순위

6. 운영 체크리스트

6.1 저장소 체크

6.2 배포 체크

6.3 이미지 체크

6.4 트래픽 체크

7. Mermaid 다이어그램

8. 요약 도표

9. 인사이트와 핵심 정리

9.1 가장 중요한 결론

9.2 어느 서비스가 먼저 한계에 닿는가

9.3 실제 운영에서 가장 중요한 감각

10. 해당 문서의 한계점

11. 참고자료 & 링크

12. 태그