2026년 5월 6일 기준, AI 서비스 운영비 0원은 정적 웹 배포와 제한된 서버리스 사용에서만 현실적이다.
서버비가 0원이라는 말과 사업 운영비가 0원이라는 말은 다르다.
이 둘을 섞는 순간 계산표가 바로 흐려진다.
흐려진 계산표는 보통 카드 명세서에서 다시 선명해진다.
기분 나쁜 방식으로 선명해진다.
그래서 이 글에서는 AI 서비스 운영비 0원을 감성 문장이 아니라 비용 항목으로 쪼개서 본다.
정적 페이지는 어디까지 무료에 가까운지.
Cloudflare Workers는 어느 지점부터 월 5달러가 되는지.
WordPress 블로그는 왜 0원이 어려운지.
LLM API 호출은 왜 호스팅비와 따로 봐야 하는지.
그리고 광고 수익이 월 서버비를 얼마나 상쇄해야 손익분기인지까지 계산한다.
조코딩류 수익형 AI 서비스 레퍼런스에서 가져올 것은 제목이나 소재가 아니다.
가져올 것은 순서다.
문제를 찾는다.
작게 만든다.
공개한다.
비용을 줄인다.
수익을 붙인다.
데이터로 다음 행동을 정한다.
이 순서를 TECHTAEK 버전으로 바꾸면 AI 서비스 운영비 계산표가 된다.
먼저 숫자부터 보자
우리 Blog OS 내부 메모에는 2026년 3월 기준 AdSense 최근 28일 페이지뷰가 5,180이었다.
같은 메모의 페이지 RPM은 $2.18이었다.
계산상 월 예상 수익은 약 $11-12 수준이었다.
호스팅은 Cloudways 기준 월 $30으로 적혀 있었다.
이후 비용 우선 운영 보드에서는 클라우드 고정비를 약 $35까지 보수적으로 잡았다.
그러면 현재 문제는 단순하다.
월 $30-35 고정비를 내는 구조에서는 작은 블로그 수익이 바로 사라진다.
글이 돈을 벌기 전에 서버가 먼저 월급을 가져간다.
서버가 사람보다 먼저 월급을 받는 상황이다.
이건 별로 낭만적이지 않다.
그래서 운영비 0원 논의는 멋진 AI 앱 이야기가 아니라 손익분기 이야기부터 시작해야 한다.
월 고정비별 필요한 페이지뷰
| 월 고정비 | RPM $2.18 기준 월 필요 PV |
하루 필요 PV | 해석 |
|---|---|---|---|
$35 |
약 16,055 | 약 535 | 현재 소형 블로그에는 꽤 무겁다 |
$30 |
약 13,762 | 약 459 | 2026년 3월 메모의 손익분기와 비슷한 구간 |
$10 |
약 4,587 | 약 153 | 현실적인 방어선 |
$5 |
약 2,294 | 약 77 | 작은 블로그도 버틸 만한 선 |
$0 |
0 | 0 | 호스팅 손익분기는 사라지지만 API 비용은 남는다 |
공식은 단순하다.
월 필요 PV = 월 고정비 / 페이지 RPM * 1000
RPM이 $2.18일 때 월 고정비 $35를 버티려면 월 16,055PV가 필요하다.
하루로 나누면 약 535PV다.
반대로 월 고정비를 $5로 낮추면 하루 77PV 정도면 호스팅비 방어가 된다.
운영비 0원 이야기가 중요한 이유가 여기 있다.
매출을 10배로 늘리는 것보다 고정비를 7분의 1로 줄이는 쪽이 빠를 때가 있다.
이건 초라한 이야기가 아니다.
작은 서비스가 살아남는 방식이다.
계산을 바로 해보고 싶으면 아래 미니 계산기부터 만져도 된다.
AI 서비스 운영비 미니 계산기
월 PV, RPM, 고정비, AI 호출비를 넣으면 광고 수익과 손익분기 PV가 바로 나온다.
현재 입력값으로 계산 중.
본문을 다 읽기 전에 숫자를 먼저 넣어보면 뒤쪽 표가 훨씬 덜 추상적으로 보인다.
역시 사람은 설명보다 자기 카드값에 더 집중한다.
실전 예시
작은 AI 계산기 페이지를 만들었다고 하자.
월 3,000PV가 나온다.
RPM이 $2.18이면 광고 수익은 약 $6.54다.
Cloudways 월 $30이면 여전히 적자다.
Hetzner나 Cloudflare 조합으로 월 $5 근처까지 낮추면 흑자 전환이 가능하다.
Cloudflare 정적 페이지만으로 운영비를 0원에 가깝게 만들면 서버비 기준으로는 바로 방어가 된다.
하지만 사용자가 버튼을 누를 때마다 외부 LLM API를 호출하면 이야기가 달라진다.
그 비용은 호스팅비가 아니라 추론비다.
추론비를 빼고 0원이라고 말하면 계산표가 예쁘긴 하다.
예쁜데 좀 위험하다.
운영비 0원의 6개 비용통
AI 서비스 운영비를 한 줄로 쓰면 반드시 틀린다.
최소 6개 통으로 나눠야 한다.
첫 번째는 정적 웹 호스팅이다.
HTML, CSS, JavaScript, 이미지 같은 파일을 배포하는 비용이다.
두 번째는 서버리스 함수 비용이다.
사용자 요청마다 작은 코드를 실행하는 비용이다.
세 번째는 데이터베이스와 저장소 비용이다.
사용자 입력, 결과, 파일, 세션, 로그가 여기에 들어간다.
네 번째는 LLM 또는 AI API 비용이다.
이건 서비스가 AI라는 이름을 붙이는 순간 가장 자주 숨어버리는 비용이다.
다섯 번째는 운영 도구 비용이다.
이메일, 모니터링, 분석, 배포, 백업, 보안 도구가 여기에 들어간다.
여섯 번째는 사람 시간이다.
직접 운영하면 카드값은 줄지만, 장애 대응과 업데이트 시간이 생긴다.
사람 시간은 청구서에 안 찍혀서 더 무섭다.
안 찍히면 공짜처럼 보이니까.
비용통 분리표
| 비용통 | 0원 가능성 | 대표 선택지 | 주의할 점 |
|---|---|---|---|
| 정적 웹 호스팅 | 높음 | Cloudflare Pages, GitHub Pages | 동적 기능은 별도 계산 |
| CDN/SSL/DNS | 높음 | Cloudflare Free | 고급 보안 기능은 유료 가능 |
| 서버리스 함수 | 중간 | Cloudflare Workers Free | 일 요청량과 CPU 제한 확인 |
| DB/상태 저장 | 중간 | D1, KV, R2 Free 구간 | 쓰기 작업과 저장량이 늘면 과금 |
| LLM API | 낮음 | OpenAI, Anthropic, Google 등 | 호스팅비와 완전히 별도 |
| WordPress 런타임 | 낮음 | VPS, 관리형 호스팅 | PHP, MySQL, 백업, 보안 관리 필요 |
| 운영 도구 | 중간 | 무료 분석, 무료 모니터링 | 무료 플랜 한도와 로그 보존 기간 |
여기서 핵심은 정적 웹 호스팅과 AI 추론을 분리하는 것이다.
정적 웹은 무료에 가까워질 수 있다.
AI 추론은 사용량 기반 비용이다.
둘을 한 문장에 넣고 운영비 0원이라고 부르면 독자는 혹한다.
운영자는 식은땀을 흘린다.
실전 예시
사용자가 생년월일을 넣으면 운세처럼 짧은 결과 페이지를 보여주는 AI 서비스를 생각해보자.
결과 로직이 브라우저 안 JavaScript로 끝나면 정적 웹에 가깝다.
결과 로직이 Workers에서 짧게 실행되고 저장도 안 하면 서버리스 무료 구간에 들어갈 수 있다.
결과마다 LLM을 호출하면 API 비용이 생긴다.
결과 이미지를 생성하면 이미지 생성 비용과 저장소 비용이 붙는다.
사용자 결과를 저장하고 공유 링크를 만들면 DB와 저장소 비용이 붙는다.
같은 AI 서비스라는 제목이어도 비용 구조는 완전히 달라진다.
그래서 만들기 전에 이름보다 비용통을 먼저 잡아야 한다.
서비스 이름은 나중에 바꿀 수 있다.
청구서는 대체로 못 바꾼다.
Cloudflare로 0원에 가까워지는 구간
Cloudflare 쪽 숫자는 꽤 선명하다.
Cloudflare Workers 공식 가격 문서는 Free 플랜에서 하루 100,000 요청을 제공한다고 안내한다.
Paid 플랜은 계정당 월 최소 $5부터 시작한다.
Paid에는 월 1,000만 요청과 3,000만 CPU 밀리초가 포함되고, 초과분은 요청 백만 건당 $0.30, CPU 백만 밀리초당 $0.02로 제시되어 있다.
또 공식 문서의 예시에는 정적 자산 요청이 무료이며 무제한이라고 적혀 있다.
이 문장이 중요하다.
정적 페이지 중심 서비스는 트래픽이 커져도 서버 실행 비용이 느리게 증가한다.
Cloudflare Pages 제한 문서도 Free 플랜에서 월 500회 빌드, 프로젝트당 100개 커스텀 도메인, 사이트당 20,000개 파일 한도를 보여준다.
Pages Functions 요청은 Workers 쿼터에 들어간다.
즉 정적 자산과 함수 실행을 나눠서 봐야 한다.
정적 파일만 많이 읽히는 서비스는 강하다.
모든 요청이 함수로 들어가는 서비스는 계산해야 한다.
Cloudflare-only 구성이 맞는 경우
| 조건 | 판단 |
|---|---|
| 페이지 대부분이 정적 HTML/JS/CSS다 | 매우 적합 |
| 사용자별 데이터 저장이 거의 없다 | 적합 |
| 결과 계산이 브라우저나 짧은 Worker에서 끝난다 | 적합 |
| 이미지, PDF, 대용량 파일 저장이 많지 않다 | 적합 |
| 실시간 채팅, 긴 작업, 백그라운드 큐가 많다 | 계산 필요 |
| WordPress 관리자 화면과 플러그인이 필요하다 | 부적합 |
| 매 요청마다 LLM API를 호출한다 | 호스팅은 싸도 추론비 별도 |
이 표에서 제일 자주 놓치는 줄은 마지막 줄이다.
Cloudflare가 싸다고 LLM 호출까지 공짜가 되는 건 아니다.
Cloudflare는 도로를 싸게 깔아줄 수 있다.
하지만 도로 위에서 부르는 택시비까지 대신 내주지는 않는다.
묘하게 당연한데, 막상 서비스 만들 때는 잘 잊는다.
실전 예시
AI 서비스 운영비 계산기를 만든다고 하자.
사용자가 월 방문자 수, RPM, 서버비, API 호출 단가를 넣는다.
브라우저에서 계산만 하면 Cloudflare Pages 정적 서비스로 충분하다.
결과를 URL에 쿼리스트링으로 담아 공유하면 DB도 필요 없다.
이 경우 호스팅 비용은 0원에 가깝다.
반대로 사용자의 계산 기록을 계정별로 저장하면 D1이나 KV가 필요해진다.
사용자가 입력한 사업 아이디어를 LLM이 분석해주면 API 비용이 붙는다.
PDF 리포트를 생성해 저장하면 R2 같은 저장소 비용도 봐야 한다.
처음부터 다 넣으면 서비스는 멋있다.
운영비도 같이 멋있게 튄다.
작게 시작하려면 정적 계산기 -> 선택형 저장 -> 선택형 AI 분석 순서가 낫다.
Hetzner와 Cloudways는 어디에 들어가나
Cloudflare-only가 항상 답은 아니다.
WordPress 블로그, PHP 플러그인, MySQL, 관리자 화면, 기존 테마를 그대로 써야 하면 VPS나 관리형 호스팅이 더 현실적이다.
여기서 Hetzner와 Cloudways가 갈린다.
Hetzner는 저렴한 VPS 쪽이다.
직접 서버를 관리하는 대신 월 비용을 낮춘다.
Cloudways는 관리형 호스팅 쪽이다.
서버 관리 부담을 줄이는 대신 비용이 올라간다.
우리 내부 이전 메모는 2026년 3월에 Cloudways 월 $30에서 Hetzner와 Cloudflare 조합으로 월 $5대까지 낮추는 방향을 검토했다.
다만 Hetzner는 2026년 4월 1일부터 가격 조정을 적용했다.
공식 가격 조정 문서 기준으로 Germany/Finland의 CX23은 월 €3.99, CPX22는 월 €7.99로 바뀌었다.
미국 리전 CPX11은 월 $6.99로 제시되어 있다.
예전 메모의 세부 인스턴스명과 가격은 그대로 베끼지 말고 오늘 가격표로 다시 확인해야 한다.
이런 데서 자동화가 삐끗하면 글은 멀쩡한데 돈 계산이 틀어진다.
글보다 청구서가 더 냉정하다.
Cloudways 공식 가격 페이지는 2026년 5월 6일 확인 시 DigitalOcean 기반 Flexible 플랜에서 프로모션 가격을 전면에 보여주고 있었다.
예를 들어 Micro/Small 항목에 월 $11, 2GB RAM, 1 vCPU, 50GB Storage, 2TB Transfer가 표시되었다.
하지만 공식 페이지의 프로모션 가격과 내 실제 청구액은 다를 수 있다.
그래서 이 글에서는 Cloudways를 관리형이라 편하지만 고정비가 올라갈 수 있는 선택지로 본다.
정확한 이전 판단은 내 계정의 실제 청구서를 기준으로 해야 한다.
가격표는 지도다.
청구서는 현장이다.
세 가지 운영 방식 비교
| 방식 | 월 비용 감각 | 장점 | 약점 | 맞는 상황 |
|---|---|---|---|---|
| Cloudflare 정적 웹 | $0에 가까움 |
빠르고 단순, CDN 강함 | 동적 기능과 DB는 설계 필요 | 계산기, 랜딩, 문서, 정적 AI 데모 |
| Hetzner VPS + Cloudflare | $5-10대 가능 |
WordPress 가능, 비용 낮음 | 서버 관리는 직접 해야 함 | 블로그 1-3개, 작은 PHP/MySQL 앱 |
| Cloudways 관리형 | $10-35+ 가능 |
관리 편함, WordPress 운영 편함 | 고정비가 수익을 먼저 먹을 수 있음 | 운영 시간을 돈으로 사야 하는 경우 |
여기서 Cloudflare 정적 웹은 운영비를 줄이는 선택이다.
Hetzner VPS는 비용과 유연성의 중간 선택이다.
Cloudways는 운영 편의성을 사는 선택이다.
셋 중 뭐가 좋냐는 질문은 너무 크다.
진짜 질문은 이거다.
지금 내 병목이 돈인가, 시간인가, 안정성인가.
돈이 병목이면 Cloudflare나 Hetzner 쪽을 먼저 본다.
시간이 병목이면 Cloudways 같은 관리형이 말이 된다.
안정성이 병목이면 무료 플랜만 믿고 가면 곤란하다.
무료는 훌륭한 시작점이지, 항상 훌륭한 운영정책은 아니다.
실전 예시
TECHTAEK 같은 WordPress 블로그 3개를 이미 운영 중이라고 하자.
글, 이미지, 플러그인, 관리자 계정, 리디렉션이 다 얽혀 있다.
이걸 하루아침에 정적 웹으로 바꾸는 건 비용 절감이 아니라 새 프로젝트다.
이 경우 단기 액션은 Hetzner VPS 이전 검토가 더 현실적이다.
반대로 새로 만드는 AI 운영비 계산기는 처음부터 정적 웹으로 만들 수 있다.
사용자 계정도 없고, DB도 없고, 계산 로직도 단순하다.
그럼 Cloudflare Pages로 충분하다.
기존 블로그는 VPS로 줄이고, 새 계산기는 정적으로 만든다.
이렇게 역할을 나누면 된다.
모든 걸 한 기술로 밀어붙이면 편해 보인다.
대체로 나중에 안 편하다.
AI 기능을 넣는 순간 계산이 바뀐다
운영비 0원 글에서 가장 조심해야 할 부분은 AI라는 단어다.
정적 웹은 무료에 가까워질 수 있다.
하지만 AI 추론은 보통 무료가 아니다.
사용자가 버튼을 누를 때마다 모델 API를 호출하면 호출 횟수와 토큰 수가 비용이 된다.
이미지 생성, 음성 변환, 영상 생성은 텍스트보다 비용이 더 빨리 커질 수 있다.
그래서 AI 서비스 비용 계산에는 최소 4개 입력값이 필요하다.
월 방문자 수.
전환율.
사용자 1명당 AI 호출 횟수.
호출 1회당 평균 비용.
이 네 가지가 없으면 무료로 만들 수 있다는 말은 아직 검증 전 문장이다.
검증 전 문장은 아이디어 회의에서는 귀엽다.
운영 회의에서는 살짝 위험하다.
AI 호출비 계산식
월 AI 호출비 = 월 방문자 수 * AI 기능 사용률 * 사용자당 호출 횟수 * 호출당 평균 비용
예를 들어 월 방문자 10,000명인 서비스가 있다.
그중 20%가 AI 기능을 쓴다.
사용자당 평균 2번 호출한다.
호출 1회 평균 비용이 $0.01이면 월 AI 호출비는 $40이다.
호스팅이 0원이어도 전체 운영비는 0원이 아니다.
이 지점에서 수익화 설계가 들어와야 한다.
광고만으로 방어할지.
무료 결과는 짧게 주고 상세 분석은 유료로 돌릴지.
API 사용량을 일일 제한으로 막을지.
사용자에게 자기 API 키를 넣게 할지.
아니면 AI 호출을 아예 선택 기능으로 둘지.
이 결정이 없으면 서비스는 공개 후에 비용을 배운다.
비용은 선생님치고 수업료가 좀 세다.
실전 예시
블로그 글 하단에 내 서비스 운영비 계산해보기 버튼을 붙인다고 하자.
첫 버전은 순수 계산기로 만든다.
방문자는 서버비, RPM, 예상 PV, API 호출 단가를 직접 넣는다.
계산은 브라우저에서 끝난다.
이 버전은 호스팅비가 0원에 가깝다.
두 번째 버전에서 내 상황을 AI가 해석해주기 버튼을 붙인다.
이 버튼만 LLM API를 호출한다.
버튼 위에는 AI 분석은 하루 1회 제한을 둔다.
이렇게 하면 무료 계산기는 트래픽을 받고, AI 기능은 비용을 통제한다.
조코딩식 수익형 구조를 TECHTAEK에 옮기면 이런 모양이 된다.
무작정 AI를 붙이는 게 아니라, 무료 가치와 유료 비용을 분리한다.
여기서 수익화는 거창한 결제창만 뜻하지 않는다.
광고 수익, 뉴스레터 구독, 체크리스트 다운로드, 제휴 링크, 유료 템플릿이 모두 후보가 된다.
광고 수익으로 운영비를 방어하는 표
운영비 0원에 가까운 구조를 만들었다고 해도, 수익표를 같이 봐야 한다.
무료 호스팅이 목표가 아니라 지속 가능한 운영이 목표이기 때문이다.
광고 수익형 글에서는 RPM이 핵심이다.
RPM은 페이지뷰 1,000회당 수익이다.
우리 내부 메모의 RPM $2.18을 기준으로 하면 계산이 꽤 보수적이다.
AI/개발 주제는 키워드와 국가에 따라 RPM이 크게 달라질 수 있다.
하지만 지금은 장밋빛 숫자보다 현재 데이터가 더 중요하다.
현재 숫자로 버티면 좋은 구조다.
현재 숫자로 못 버티는데 미래 숫자만 믿으면 불안한 구조다.
불안한 구조는 처음엔 열정으로 버틴다.
그다음엔 카드 알림으로 교육받는다.
RPM별 손익분기표
| 월 고정비 | RPM $2.18 |
RPM $5 |
RPM $10 |
메모 |
|---|---|---|---|---|
$5 |
2,294PV | 1,000PV | 500PV | VPS 최소비 방어선 |
$10 |
4,587PV | 2,000PV | 1,000PV | 작은 운영 도구 포함 |
$30 |
13,762PV | 6,000PV | 3,000PV | 관리형 호스팅 방어선 |
$35 |
16,055PV | 7,000PV | 3,500PV | 현재 비용 우선 보드의 보수적 기준 |
$50 |
22,936PV | 10,000PV | 5,000PV | API/도구 비용까지 포함한 소형 앱 |
이 표에서 중요한 것은 한 줄이다.
RPM이 올라가면 고정비를 버티기 쉬워진다.
하지만 RPM 상승은 내가 완전히 통제할 수 없다.
고정비 절감은 내가 비교적 통제할 수 있다.
그래서 비용 우선 운영에서는 새 글 10개보다 고정비 1개를 먼저 본다.
이건 블로그가 망했다는 뜻이 아니다.
블로그를 사업처럼 보겠다는 뜻이다.
사업은 매출도 보지만 비용도 본다.
당연한 말인데, 블로그는 종종 이 당연한 말을 까먹는다.
글 쓰는 사람은 조회수표를 보고, 사업하는 사람은 손익표를 본다.
우리는 둘 다 봐야 한다.
실전 예시
AI 운영비 계산표 글이 월 1,000PV를 만든다고 하자.
RPM이 $2.18이면 월 수익은 $2.18이다.
이 글 하나로 Cloudways 월 $30을 방어하기는 어렵다.
하지만 이 글이 Cloudways -> Hetzner 이전 글, Cloudflare AI Platform 글, AI 코딩툴 비용표로 내부 링크를 보내면 가치가 달라진다.
광고 수익만이 아니라 허브 회수율을 올리는 글이 된다.
여기에 계산표 CTA를 붙여 뉴스레터 구독을 받으면 수익 경로가 하나 더 생긴다.
즉 이 글의 목표는 단독 대박이 아니다.
비용 절감 허브의 입구가 되는 것이다.
입구가 좋아야 안쪽 글도 산다.
문을 멋지게 칠하는 게 아니라, 손잡이를 찾기 쉽게 만드는 작업이다.
조코딩식 수익글에서 가져올 것
조코딩 공식 사이트를 보면 AI 수익형 프로젝트, 바이브코딩, 웹서비스, 앱 개발, 수익화 같은 흐름이 전면에 있다.
소개 페이지에서도 단순히 만드는 것을 넘어 수익화와 사업화로 이어지는 방향을 강조한다.
여기서 우리가 가져올 것은 소재가 아니라 구조다.
AI로 돈 벌었다라는 문장을 그대로 따라가면 금방 얇아진다.
대신 왜 이 구조가 돈이 되는가를 분석하면 오래 쓸 수 있다.
조코딩식 구조는 대략 이렇게 읽을 수 있다.
하나, 누구나 이해하는 문제를 잡는다.
둘, AI와 웹 기술로 빠르게 만든다.
셋, 공개해서 트래픽을 받는다.
넷, 광고나 강의나 제품으로 수익 경로를 붙인다.
다섯, 사례로 다시 콘텐츠화한다.
TECHTAEK은 여기서 비용을 더 앞에 둬야 한다.
우리 상황은 새 글 공장이 아니라 비용 회수 모드이기 때문이다.
최근 운영 보드에는 7일 수익 $1.86, 글당 회수액 $0.0165, 색인 응급 41건 같은 숫자가 있다.
이 숫자에서 새 글을 무작정 늘리면 체력이 먼저 빠진다.
그래서 이번 글은 신규 포스트이지만 예외로 둔다.
왜냐하면 이 글 자체가 비용 절감 허브와 직접 연결되기 때문이다.
TECHTAEK식 변환표
| 조코딩식 흐름 | TECHTAEK 변환 | 본문 장치 |
|---|---|---|
| AI로 만들기 | 정적 웹과 서버리스로 작게 만들기 | Cloudflare-only 분기표 |
| 공개하기 | 검색 유입 가능한 계산표 글로 공개 | RPM/PV 손익분기표 |
| 수익화하기 | 광고, 체크리스트, 뉴스레터 CTA | 운영비 계산표 CTA |
| 사례화하기 | Blog OS 비용 절감 리포트로 후속 연결 | Cloudways/Hetzner 내부링크 |
| 강의/커뮤니티 전환 | 무료 템플릿 또는 이메일 구독 | 계산표 업데이트 알림 |
여기서 핵심은 따라 만들기가 아니다.
따라 계산하기다.
누군가의 성공 사례는 멋있다.
하지만 내 서버비를 대신 내주지는 않는다.
내 표로 바꿔야 내 의사결정이 된다.
그래서 이 글은 수익 인증 글이 아니라 운영비 판단 글이어야 한다.
돈 냄새는 나지만, 장부 냄새가 먼저 나는 글.
그게 TECHTAEK 쪽에 더 맞다.
실전 예시
제목을 AI로 월 100만원 버는 법으로 잡으면 클릭은 받을 수 있다.
하지만 내부 Blog OS와 연결이 약하다.
제목을 AI 서비스 운영비 0원은 어디까지 가능할까로 잡으면 Cloudflare, Hetzner, Cloudways, AdSense, 계산표가 모두 연결된다.
이 글은 기존 Cloudflare AI Platform 글에서 내려오는 독자도 받을 수 있다.
기존 Cloudways -> Hetzner 이전 메모와도 연결된다.
나중에 AI 코딩툴 월비용 계산표 CTA로도 확장할 수 있다.
조회수 하나만 보는 글이 아니라 허브를 만드는 글이 된다.
허브 글은 첫날 박수가 작아도 오래 남는다.
그리고 오래 남는 글이 고정비를 천천히 이긴다.
빠른 박수보다 느린 현금흐름이 더 착할 때가 있다.
어떤 서비스는 정말 0원에 가깝다
운영비 0원이 항상 과장은 아니다.
정확한 조건에서는 꽤 현실적이다.
정적 웹으로 만들 수 있는 서비스가 그렇다.
클라이언트에서 계산하고, 서버에 저장하지 않고, 외부 API를 거의 부르지 않는 구조다.
예를 들면 체크리스트 생성기.
간단한 세금 또는 비용 계산기.
마크다운 템플릿 생성기.
키워드 분류표.
로컬 브라우저에서만 돌아가는 작은 도구.
이런 것들은 Cloudflare Pages나 Workers Free 구간에 잘 들어간다.
그리고 콘텐츠 글과 붙이면 광고 수익형 CTA가 된다.
독자는 글만 읽고 나가지 않는다.
계산해보고, 체크해보고, 다른 글로 이동한다.
검색 유입 글에서 이 작은 행동이 중요하다.
PV만 높고 다음 행동이 없으면 블로그는 얇다.
작은 도구 하나가 붙으면 블로그가 서비스처럼 보이기 시작한다.
거창한 SaaS가 아니어도 된다.
계산기 하나로도 충분히 시작할 수 있다.
0원에 가까운 서비스 후보
| 후보 | 왜 0원에 가까운가 | 수익화 연결 |
|---|---|---|
| AI 서비스 운영비 계산기 | 브라우저 계산으로 충분 | AdSense, 뉴스레터, 템플릿 |
| 블로그 호스팅 손익분기 계산기 | 입력값 4개로 끝남 | Cloudways/Hetzner 글 내부링크 |
| LLM API 호출비 추정기 | 모델 단가를 사용자가 입력 | AI 코딩툴 비용 글 CTA |
| MCP 서버 권한 체크리스트 | 저장 필요 없음 | 보안 글 리드미끼 |
| ETF 세후 현금흐름 계산기 | 단순 산식 중심 | 배당노마드 CTA |
| 종합소득세 체크표 생성기 | 공식 동선 링크 중심 | TAEK2 CTA |
이 후보들은 모두 공통점이 있다.
사용자 입력을 서버에 꼭 저장할 필요가 없다.
로그인이 없어도 된다.
결과가 즉시 나온다.
콘텐츠 글과 자연스럽게 붙는다.
LLM이 없어도 1차 가치를 줄 수 있다.
여기에 선택적으로 AI 해석을 붙이면 된다.
처음부터 AI가 주인공이면 비용이 먼저 뛴다.
처음에는 계산표가 주인공이어도 된다.
계산표는 말이 없지만 일을 잘한다.
가끔은 말 많은 AI보다 낫다.
실전 예시
이 글 끝에 AI 서비스 운영비 계산표를 붙인다고 하자.
입력칸은 월 PV, RPM, 호스팅비, AI 기능 사용률, 사용자당 호출 횟수, 호출당 비용이다.
결과는 월 광고 수익, 월 AI 호출비, 월 순손익, 손익분기 PV다.
이 기능은 첫 버전에서 서버가 필요 없다.
HTML과 JavaScript로 끝난다.
이후 반응이 좋으면 계산 결과 공유 URL을 만든다.
그 다음에 이메일로 계산표 업데이트를 보내는 뉴스레터를 붙인다.
마지막에 AI 해석 기능을 선택 옵션으로 둔다.
이 순서가 비용 우선이다.
처음부터 계정, 저장, AI 분석, PDF, 결제까지 붙이면 개발자는 뿌듯하다.
운영자는 울 수 있다.
둘이 같은 사람이라면 더 조심해야 한다.
어떤 서비스는 0원이 아니다
반대로 0원이라고 말하면 안 되는 서비스도 있다.
사용자 계정이 필요하다.
데이터를 장기 저장한다.
이미지나 파일을 많이 저장한다.
매 요청마다 AI 모델을 호출한다.
긴 작업을 큐로 돌린다.
관리자 화면과 CMS가 필요하다.
보안 로그와 백업이 중요하다.
이런 서비스는 무료 구간으로 시작할 수는 있어도 0원 운영이라고 부르기는 어렵다.
특히 WordPress 블로그는 정적 페이지와 다르다.
WordPress는 PHP와 데이터베이스가 살아 있어야 한다.
플러그인 업데이트와 보안 패치도 필요하다.
관리자 로그인도 있다.
이미지와 백업도 있다.
그래서 WordPress를 Cloudflare Pages처럼 계산하면 안 된다.
Cloudflare가 앞단 캐시를 잘해줘도 원본 서버는 필요하다.
캐시는 좋은 방패지만, 집 자체는 따로 있어야 한다.
집세는 여전히 나온다.
0원이라고 부르면 위험한 신호
| 신호 | 왜 위험한가 | 현실적 대응 |
|---|---|---|
| 로그인과 계정이 있다 | 세션과 DB가 필요하다 | 무료 DB 한도와 백업 정책 확인 |
| 파일 업로드가 있다 | 저장소와 트래픽이 늘어난다 | R2/S3 비용과 삭제 정책 설계 |
| AI 결과를 저장한다 | DB 쓰기와 저장량이 증가한다 | 저장 기간 제한 |
| 매 요청마다 LLM 호출 | 사용량이 바로 비용이 된다 | 호출 제한과 캐시 적용 |
| WordPress 플러그인이 많다 | 서버 자원과 보안 관리 필요 | VPS 또는 관리형 비용 인정 |
| 실시간 기능이 있다 | 연결 유지 비용이 생긴다 | Workers/Durable Objects 비용 확인 |
| 팀/기업 고객 대상이다 | SLA와 지원이 필요하다 | 유료 플랜 또는 별도 인프라 검토 |
여기서 나쁜 선택은 없다.
다만 이름을 정확히 붙여야 한다.
무료 구간 실험.
월 5달러 운영.
월 30달러 관리형 운영.
월 50달러 AI 기능 포함 운영.
이렇게 부르면 의사결정이 쉬워진다.
모두 0원이라고 부르면 다음 회의가 이상해진다.
이상한 회의는 보통 길다.
길고 생산성이 낮다.
그런 회의는 피하는 게 인류애다.
실전 예시
사용자가 자신의 블로그 URL을 넣으면 AI가 SEO 리포트를 만들어주는 서비스를 생각해보자.
URL 크롤링이 필요하다.
본문 추출이 필요하다.
LLM 분석이 필요하다.
결과 저장이 필요할 수 있다.
PDF 다운로드가 붙을 수 있다.
이건 정적 웹 계산기가 아니다.
Cloudflare 위에서 만들 수는 있지만 0원 서비스라고 보면 안 된다.
무료 체험은 가능하다.
월 사용량 제한도 가능하다.
하지만 제품이 돌아갈수록 비용이 늘어나는 구조다.
이런 서비스는 처음부터 가격 정책을 같이 설계해야 한다.
무료 사용자는 짧은 리포트.
구독자는 긴 리포트.
운영자는 일일 예산 한도.
이 정도는 첫 버전에 있어야 한다.
비용 한도 없는 AI 기능은 귀여운 폭탄이다.
생긴 건 버튼인데, 안에는 청구서가 들어 있다.
2026년 기준 추천 의사결정 순서
AI 서비스 운영비를 줄이고 싶다면 기술부터 고르면 순서가 꼬인다.
먼저 콘텐츠와 기능을 나눠야 한다.
검색 유입을 받을 페이지는 정적 웹에 가깝게 만든다.
사용자가 직접 값을 넣고 결과를 얻는 계산 기능도 가능하면 브라우저에서 처리한다.
로그인과 저장은 정말 필요할 때만 붙인다.
LLM 호출은 선택 기능으로 둔다.
WordPress가 필요한 기존 블로그는 별도 비용 절감 프로젝트로 본다.
이게 가장 덜 화려하지만 현실적이다.
화려함은 종종 비용을 데려온다.
비용은 친구처럼 오지 않는다.
대체로 알림처럼 온다.
7단계 체크리스트
| 단계 | 질문 | 선택 |
|---|---|---|
| 1 | 이 서비스의 핵심 결과가 정적 계산으로 가능한가 | 가능하면 브라우저 계산 |
| 2 | 사용자별 저장이 꼭 필요한가 | 아니면 URL 공유나 로컬 저장 |
| 3 | AI 호출이 핵심인가 부가 기능인가 | 부가 기능이면 선택 버튼 |
| 4 | 월 예상 PV와 RPM은 얼마인가 | 손익분기 PV 계산 |
| 5 | 월 고정비를 $5-10 아래로 낮출 수 있는가 |
Cloudflare/Hetzner 검토 |
| 6 | WordPress가 꼭 필요한가 | 필요하면 VPS/관리형 인정 |
| 7 | 비용 초과 시 자동으로 멈추는가 | 일일 제한, 예산 알림, 캐시 |
이 체크리스트를 통과하면 운영비 0원 논의가 꽤 정직해진다.
정직한 계산은 처음엔 재미없다.
하지만 오래 갈수록 강하다.
특히 작은 블로그와 1인 서비스는 강한 계산표가 필요하다.
대형 서비스는 돈으로 실수를 덮을 수 있다.
작은 서비스는 구조로 실수를 줄여야 한다.
돈이 적으면 설계가 더 중요해진다.
이건 우울한 말이 아니라 자유로운 말이다.
작게 만들 수 있으면 작게 실험할 수 있다.
작게 실험할 수 있으면 오래 버틸 수 있다.
오래 버티면 데이터가 쌓인다.
데이터가 쌓이면 다음 선택이 쉬워진다.
실전 예시
새로운 TECHTAEK 미니툴을 만든다고 하자.
첫 주 목표는 결제가 아니다.
첫 주 목표는 Search Console 노출과 클릭, 체류, 내부링크 이동이다.
둘째 주 목표는 계산표 CTA 클릭이다.
셋째 주 목표는 뉴스레터 구독이나 템플릿 요청이다.
넷째 주에 AI 해석 버튼을 붙일지 결정한다.
이렇게 가면 비용은 늦게 붙고 데이터는 먼저 쌓인다.
반대로 첫 주부터 AI 분석, PDF, 로그인, 결제, 관리자 페이지를 다 붙이면 출시가 늦어진다.
출시가 늦어지면 데이터도 늦어진다.
데이터가 늦어지면 감으로 운영한다.
감은 좋을 때도 있지만, 청구서 앞에서는 자주 약하다.
이 글의 CTA는 계산표여야 한다
이 주제의 CTA는 강의 판매보다 계산표가 먼저다.
독자가 지금 필요한 것은 나도 만들 수 있다보다 내가 만들면 얼마가 나가나일 가능성이 높다.
그래서 글 하단 CTA는 AI 서비스 운영비 계산표가 맞다.
계산표는 다음 칸을 가져야 한다.
월 방문자 수.
페이지 RPM.
월 고정 호스팅비.
AI 기능 사용률.
사용자당 AI 호출 횟수.
호출당 평균 비용.
월 저장소 비용.
월 운영 도구 비용.
예상 광고 수익.
예상 AI 호출비.
예상 순손익.
손익분기 PV.
이 정도면 독자는 자기 상황을 바로 넣어볼 수 있다.
블로그 입장에서는 체류 시간과 재방문 이유가 생긴다.
뉴스레터 입장에서는 업데이트를 보낼 명분이 생긴다.
운영자 입장에서는 다음 글감이 생긴다.
좋은 CTA는 독자를 억지로 붙잡지 않는다.
독자가 하려던 계산을 대신 도와준다.
그게 제일 자연스럽다.
본문에서는 위 인라인 계산기를 CTA로 쓴다.
별도 HTML 백업본은 발행 번들에 남겨두되, 공개 글에서는 죽은 정적 링크를 만들지 않는다.
첫 문구는 길게 설명하지 않아도 된다.
월 PV와 AI 호출비를 넣고 손익분기 PV를 계산해보자.
이 정도면 충분하다.
독자는 이미 글을 읽고 계산할 마음이 생긴 상태다.
그때 필요한 건 설득이 아니라 입력칸이다.
계산표 기본 양식
| 입력값 | 예시 | 설명 |
|---|---|---|
| 월 PV | 5,180 | 최근 28일 페이지뷰 |
| 페이지 RPM | $2.18 |
AdSense 기준 |
| 월 고정비 | $35 |
호스팅, 도구, 백업 |
| AI 기능 사용률 | 20% | 방문자 중 AI 버튼 사용 비율 |
| 사용자당 호출 | 2회 | 1명당 평균 AI 요청 |
| 호출당 비용 | $0.01 |
모델별 평균 비용 |
| 저장소/기타 | $0-5 |
R2, DB, 모니터링 등 |
계산 결과 양식
| 결과 | 공식 | 예시 |
|---|---|---|
| 광고 수익 | PV / 1000 * RPM | $11.29 |
| AI 호출 수 | PV * 사용률 * 호출수 | 2,072회 |
| AI 호출비 | 호출 수 * 호출당 비용 | $20.72 |
| 총비용 | 고정비 + AI 호출비 + 기타 | $55.72 |
| 순손익 | 광고 수익 – 총비용 | -$44.43 |
| 손익분기 PV | 총비용 / RPM * 1000 | 25,560PV |
이 예시는 일부러 조금 아프게 잡았다.
월 PV 5,180에서 AI 기능을 막 붙이면 손익이 더 나빠질 수 있다.
그래서 첫 버전은 브라우저 계산기로 두는 게 낫다.
AI 분석 버튼은 사용량 제한을 둔다.
또는 뉴스레터 구독자에게만 제공한다.
또는 비용을 감당할 수 있는 유료 템플릿과 연결한다.
수익화는 욕심이 아니라 제한 장치가 될 수 있다.
무료가 무조건 착한 건 아니다.
무료인데 운영자가 계속 적자면 오래 못 간다.
오래 못 가면 독자에게도 별로다.
이번 글에서 실제로 확인한 것
이 글은 운영비 0원이라는 말을 그대로 믿고 쓴 글이 아니다.
2026년 5월 6일 기준으로 공식 가격표와 내부 운영 숫자를 함께 확인했다.
Cloudflare Workers 가격 문서에서는 Free 플랜의 하루 100,000 요청과 Paid 플랜의 월 최소 $5 구조를 확인했다.
같은 문서에서 정적 자산 요청은 무료이고 무제한이라는 설명도 확인했다.
Cloudflare Pages 제한 문서에서는 Free 플랜의 월 500회 빌드, 프로젝트당 커스텀 도메인 100개, 사이트당 파일 20,000개 제한을 확인했다.
Hetzner 가격 조정 문서에서는 2026년 4월 1일부터 적용되는 새 가격을 확인했다.
Cloudways 가격 페이지에서는 2026년 5월 6일 기준 공식 페이지가 프로모션 가격을 전면에 보여주는 것도 확인했다.
내부 메모에서는 2026년 3월 기준 AdSense 최근 28일 PV 5,180, RPM $2.18, 월 예상 수익 약 $11-12, Cloudways 월 $30 기준을 확인했다.
또 2026년 5월 비용 우선 운영 보드에서는 클라우드 고정비를 약 $35까지 보수적으로 잡고 있었다.
즉 이 글의 판단은 무료 플랜이 있으니 공짜다가 아니다.
정적 웹, 서버리스, VPS, 관리형 호스팅, 광고 수익을 같은 계산표에 올려놓은 판단이다.
아직 확인하지 않은 것도 있다.
이 글에서 제안한 AI 서비스 운영비 계산표 미니툴은 아직 배포 전이다.
따라서 실제 Cloudflare Pages 배포 시간, 검색 노출, CTA 클릭률, 계산기 사용률은 후속으로 검증해야 한다.
첫 검증 기준은 단순하게 잡는 게 좋다.
D+3 기준 Search Console 노출.
D+3 기준 클릭률.
D+3 기준 계산표 CTA 클릭.
D+7 기준 내부링크 이동.
D+14 기준 뉴스레터 또는 템플릿 전환.
이 숫자가 없으면 이 글은 좋은 계산 글에서 멈춘다.
이 숫자가 쌓이면 비용 절감 허브가 된다.
TECHTAEK에서 중요한 건 여기다.
도구를 말하는 글이 아니라, 도구를 운영에 붙였을 때 숫자가 어떻게 바뀌는지 보는 글이어야 한다.
확인 범위 표
| 항목 | 확인 상태 | 메모 |
|---|---|---|
| Cloudflare Workers 가격 | 확인 | Free 요청량, Paid 월 $5, 정적 자산 무료/무제한 |
| Cloudflare Pages 제한 | 확인 | 월 500 builds, 20,000 files, functions는 Workers 쿼터 |
| Hetzner 2026 가격 조정 | 확인 | 2026년 4월 1일 이후 가격으로 재계산 필요 |
| Cloudways 가격 페이지 | 확인 | 공식 페이지와 실제 청구액은 분리해서 봐야 함 |
| 내부 AdSense RPM | 확인 | 2026년 3월 기준 $2.18 |
| 내부 클라우드 고정비 | 확인 | $30-35 방어 필요 |
| 계산표 미니툴 배포 | 미확인 | 다음 실행 과제 |
| CTA 클릭률 | 미확인 | 발행 후 검증 |
실전 예시
이 글을 발행한 뒤 바로 성공이라고 부르면 안 된다.
발행은 시작 버튼이다.
성공 여부는 Cloudflare AI Platform 글에서 들어온 독자가 이 글로 이동하는지 봐야 한다.
이 글에서 Cloudways -> Hetzner 메모로 이동하는지도 봐야 한다.
그리고 계산표 CTA가 눌리는지 봐야 한다.
노출은 있는데 클릭이 없으면 제목이나 첫 20%를 고친다.
클릭은 있는데 체류가 짧으면 표 위치를 올린다.
체류는 있는데 CTA가 없으면 하단 문구를 바꾼다.
CTA는 있는데 전환이 없으면 계산표 자체를 미니툴로 만든다.
이렇게 숫자가 다음 수정 지시를 줘야 한다.
감으로 계속 다듬으면 글은 예뻐진다.
하지만 돈은 예쁜 순서로 들어오지 않는다.
많이 틀리는 지점
운영비 0원 글에서 가장 흔한 실수는 비용 이름을 섞는 것이다.
호스팅비와 AI 호출비를 섞는다.
무료 플랜과 프로덕션 운영을 섞는다.
가격표와 실제 청구서를 섞는다.
정적 웹과 WordPress를 섞는다.
트래픽과 수익을 섞는다.
이렇게 섞이면 글은 읽기 쉬워 보이지만 실행이 어려워진다.
실행이 어려운 글은 TECHTAEK에서 힘이 약하다.
읽고 나서 바로 표 하나는 채울 수 있어야 한다.
그 표가 없으면 정보는 많은데 손에 남는 게 없다.
손에 남는 게 없으면 다시 검색창으로 간다.
검색창으로 간 독자는 돌아오지 않을 수 있다.
그러니 실수 지점을 미리 막아야 한다.
실수 방지표
| 실수 | 왜 문제인가 | 고치는 방법 |
|---|---|---|
| 호스팅비 0원을 전체 운영비 0원으로 말함 | LLM API와 도구 비용이 숨는다 | 비용통 6개로 나눠 쓴다 |
| 무료 플랜 한도만 보고 서비스 설계 | 사용량 증가 때 막힌다 | 일일 요청, 저장량, 로그 보존을 본다 |
| Cloudways 가격표만 보고 현재 청구액을 무시 | 실제 손익과 달라진다 | 계정 청구서 기준으로 재계산한다 |
| Hetzner 예전 가격을 그대로 사용 | 2026년 4월 이후 가격이 달라졌다 | 공식 가격 조정 문서를 다시 본다 |
| WordPress를 정적 웹처럼 계산 | 원본 서버와 DB가 필요하다 | VPS/관리형 비용을 인정한다 |
| AI 호출 버튼을 무제한으로 열어둠 | 트래픽이 비용으로 바로 바뀐다 | 호출 제한, 캐시, 예산 알림을 둔다 |
| 광고 RPM을 낙관적으로 잡음 | 손익분기가 허상으로 보인다 | 현재 RPM과 낙관 RPM을 따로 둔다 |
| CTA 없이 정보만 제공 | 회수 경로가 없다 | 계산표, 체크리스트, 내부링크를 넣는다 |
실전 예시
Cloudflare 무료니까 AI SEO 리포트도 무료로 운영 가능이라고 생각했다고 하자.
첫 문장은 맞을 수도 있다.
정적 랜딩 페이지는 무료에 가까울 수 있다.
하지만 SEO 리포트가 URL을 크롤링하고, 본문을 추출하고, LLM으로 분석하고, PDF를 저장하면 이미 다른 서비스다.
그때는 Workers 요청, 실행 시간, 저장소, LLM API, PDF 생성 비용을 따로 본다.
그래도 무료 구간에서 시작할 수는 있다.
다만 무료로 시작 가능과 무료로 지속 운영 가능은 다른 문장이다.
이 차이를 본문에서 분리해주면 독자가 과한 기대를 하지 않는다.
과한 기대를 줄이면 이탈은 조금 생길 수 있다.
대신 신뢰가 남는다.
TECHTAEK은 그 신뢰가 더 중요하다.
최종 판단
AI 서비스 운영비 0원은 가능하다.
하지만 모든 AI 서비스에 가능한 말은 아니다.
정적 웹, 브라우저 계산, 제한된 서버리스, 저장 최소화 구조에서는 0원에 가까워질 수 있다.
WordPress, 계정, DB, 파일 저장, LLM API, 긴 작업이 붙으면 0원이 아니라 낮은 비용 운영으로 보는 게 맞다.
Cloudflare는 0원에 가까운 시작점을 만들기 좋다.
Hetzner는 WordPress나 작은 서버가 필요할 때 월 $5-10대 방어선으로 볼 만하다.
Cloudways는 운영 편의를 사는 선택지지만, 작은 AdSense 블로그에서는 고정비가 수익을 먼저 먹을 수 있다.
그러니 지금 TECHTAEK에서 해야 할 일은 새 AI 서비스를 크게 만드는 것이 아니다.
먼저 비용표를 만든다.
그 다음 정적 계산기를 붙인다.
그 다음 내부 링크로 비용 절감 허브를 만든다.
마지막에 반응이 확인된 곳에만 AI 분석 기능을 붙인다.
이 순서면 조코딩식 만들고 공개하고 수익화하기를 우리 상황에 맞게 바꿀 수 있다.
핵심은 수익 인증이 아니다.
고정비를 낮추고, 계산표를 공개하고, 작은 도구로 다음 행동을 만드는 것이다.
운영비 0원이라는 말은 멋있다.
하지만 더 멋있는 건 운영비가 왜 0원에 가까운지 설명할 수 있는 표다.
표가 있으면 유행이 지나도 의사결정이 남는다.
그리고 작은 서비스는 그런 표 위에서 오래 살아남는다.
내부 연결
Cloudflare AI Platform은 에이전트 추론 계층으로 언제 쓸 만한가 2026은 Cloudflare를 AI 추론 계층으로 볼 때의 분기표다.Cloudways -> Hetzner + Cloudflare 이전 가이드는 기존 WordPress 운영비를 낮추는 실전 이전 메모다.블로그 수익 & 호스팅 현황은 AdSense RPM, PV, Cloudways 비용을 처음 손익표로 묶은 내부 기준점이다.- 이 글은 위 세 글 사이에서
비용 계산 허브역할을 한다. - 실행용 미니 계산기는 본문 첫 20% 안에 인라인으로 배치했다.
관련 글
- Cloudflare AI Platform은 에이전트 추론 계층으로 언제 쓸 만한가 2026
- AI 에이전트 시대 클라우드는 왜 다시 불편해졌나 2026
- Codex에서 GPT-5.5를 써야 할까 2026
FAQ
Cloudflare만 쓰면 AI 서비스 운영비가 진짜 0원인가?
정적 웹과 제한된 Workers 사용에서는 0원에 가까울 수 있다.
하지만 LLM API, 이미지 생성, DB 저장, 파일 저장, 운영 도구 비용은 별도다.
그래서 호스팅비 0원과 전체 운영비 0원을 분리해야 한다.
WordPress 블로그도 Cloudflare Pages로 옮기면 0원이 되나?
정적 사이트로 완전히 변환하면 가능성이 있다.
하지만 일반적인 WordPress는 PHP, MySQL, 관리자 화면, 플러그인, 백업이 필요하다.
그 경우 Cloudflare는 앞단 캐시와 보안에 도움을 주지만 원본 서버 비용은 남는다.
Hetzner가 Cloudways보다 무조건 좋은가?
아니다.
Hetzner는 비용이 낮은 대신 서버 관리 책임이 커진다.
Cloudways는 비용이 높을 수 있지만 운영 편의성이 있다.
돈이 병목이면 Hetzner, 시간이 병목이면 관리형 호스팅이 맞을 수 있다.
AI 기능은 언제 붙이는 게 좋은가?
처음부터 모든 요청에 붙이기보다 선택 기능으로 붙이는 게 안전하다.
먼저 정적 계산기나 체크리스트로 사용성을 확인한다.
그 다음 반응이 있는 버튼에만 AI 해석을 붙인다.
광고 수익만으로 운영비를 방어할 수 있나?
가능하지만 RPM과 PV에 따라 다르다.
RPM $2.18 기준 월 $35 고정비를 방어하려면 월 16,055PV 정도가 필요하다.
월 $5 고정비라면 약 2,294PV면 된다.
그래서 작은 블로그에서는 수익 증대와 비용 절감을 같이 봐야 한다.
이 글에서 바로 실행할 한 가지는 무엇인가?
월 고정비, RPM, 월 PV를 한 표에 넣어 손익분기 PV를 계산하는 것이다.
그 다음 비용이 큰 순서대로 줄인다.
새 글을 쓰기 전에 서버비가 먼저 새고 있는지 확인하는 편이 빠를 때가 많다.
참고 자료
- Cloudflare Workers Pricing
- Cloudflare Pages Limits
- Hetzner Price Adjustment, 2026-04-01 적용
- Cloudways Pricing
- 조코딩 공식 사이트
- 조코딩 소개
- 내부 메모:
02.Areas/blog/mgmt/260309-blog-revenue-hosting.md - 내부 메모:
02.Areas/blog/mgmt/260309-cloudways-to-hetzner-migration.md - 내부 리포트:
02.Areas/blog/report/260506-creator-monetization-benchmark.md