글을 쓰는 사람에게 AI가 내 글을 참고한다는 소식은 두 가지 질문을 남깁니다. 원문을 읽으러 오는 사람이 늘어나는지, 방문으로 이어지지 않는 사용에도 대가를 받을 수 있는지입니다. 두 질문은 닮았지만 같은 수익 구조를 뜻하지는 않습니다.
Cloudflare는 2026년 9월 30일 Pay Per Use 베타를 발표했습니다. 콘텐츠 이용을 두고 구매자와 발행자가 조건을 맞추고 정산할 수 있게 하려는 시도입니다. 개인 서비스를 만들고 글도 쓰는 제 입장에서는 새로운 수익이라는 표현보다 누가 조건을 정하고 무엇을 확인할 수 있는지가 먼저 궁금했습니다.
이 글은 프로그램에 참여해 돈을 받은 후기가 아닙니다. 10월 11일 확인한 공식 발표를 바탕으로 구조를 간략히 살펴보고, 개인 블로그에 적용하기 전에 적어 볼 질문을 정리합니다. 참여 자격이나 예상 수입이 확인됐다는 뜻으로 읽지는 않으셨으면 합니다.
접근한 횟수와 사용한 대가는 다릅니다
공식 발표에 따르면 구매자는 사용 조건과 가격을 제안하고 발행자는 수락할 제안을 선택합니다. 구매자가 사용 내역을 보고하고 Cloudflare가 정산을 지원하는 구조입니다. 따라서 모든 봇의 접근에 자동으로 요금이 붙는 제도라고 이해하면 출발점부터 어긋납니다.
웹 서버에 남는 접근 기록과 구매자가 보고하는 사용 기록은 다른 정보입니다. 접근 기록은 어떤 요청이 들어왔는지를 설명하지만, 그 내용이 이후 어떤 작업에 얼마나 쓰였는지까지 저절로 보여 주지는 않습니다. 보상 구조를 이해하려면 사용의 정의와 계산 단위를 먼저 읽어야 합니다.
개인 운영자는 방문 수에 익숙해서 새로운 숫자도 방문 수익처럼 환산하기 쉽습니다. 그러나 방문이 적어도 특정 자료가 필요할 수 있고, 방문이 많아도 구매 조건과 맞지 않을 수 있습니다. 확인하지 않은 이용량에 임의의 단가를 곱해 예상 수입을 만드는 것은 판단을 오히려 흐립니다.
저라면 수익 칸을 비워 둔 채 조건표부터 만들겠습니다. 누가 어떤 글을 어떤 용도로 쓰려는지, 사용을 어떻게 보고하는지, 정산에서 무엇을 확인할 수 있는지 적는 표입니다. 비어 있는 칸은 낙관적인 추측으로 채우지 않고 미확인으로 남겨야 다음에 물어볼 내용이 분명해집니다.
내 글을 썼다는 사실과 사이트 제어권을 나눕니다
독립 사이트와 플랫폼 블로그는 운영자가 바꿀 수 있는 범위가 다릅니다. 직접 운영하는 사이트에서는 서버와 배포 설정을 다룰 수 있지만, 네이버나 티스토리에서는 플랫폼이 제공하는 설정 범위 안에서 움직입니다. 개인 도메인을 연결했다는 사실만으로 콘텐츠 수집이나 정산 기능까지 직접 제어할 수 있다고 보기는 어렵습니다.
이 글에서는 두 플랫폼의 사용자가 Pay Per Use를 곧바로 켤 수 있다고 안내하지 않습니다. 프로그램의 참여 조건뿐 아니라 플랫폼의 제공 기능과 정책을 함께 확인해야 하기 때문입니다. 서비스를 소개하는 화면에 신청 버튼이 있더라도 내 블로그가 같은 방식으로 연결되는지는 별도 문제입니다.
| 먼저 적을 항목 | 확인할 질문 |
| 운영 환경 | 콘텐츠 접근과 수집 설정을 누가 변경할 수 있습니까? |
| 콘텐츠 범위 | 내가 작성한 부분과 외부 자료가 섞인 부분을 구분했습니까? |
| 참여 조건 | 현재 내 사이트 유형과 계정이 지원 대상입니까? |
| 사용 확인 | 보고된 내역에서 어떤 글과 기간을 확인할 수 있습니까? |
| 종료 조건 | 참여를 중단할 때 이후 처리 범위를 설명할 수 있습니까? |
특히 글 안에는 직접 쓴 문장만 있는 것이 아닙니다. 사진, 외부 표, 인용문, 공동 작업 자료가 들어갈 수 있습니다. 이미 블로그에 공개했다는 이유만으로 새로운 이용 조건까지 모두 제공할 수 있다고 가정하지 말고, 무엇이 내 관리 범위인지 목록을 분리해야 합니다. 구체적인 허용 여부는 해당 자료와 프로그램의 조건으로 확인할 부분입니다.
자료 목록은 복잡한 시스템으로 만들 필요가 없습니다. 글 주소 옆에 직접 작성, 외부 인용, 이미지 출처처럼 구성을 적는 것으로 시작할 수 있습니다. 이 기록은 새 프로그램 참여를 보류하더라도 출처 보완이나 오래된 이미지 교체에 그대로 쓸 수 있습니다.
가격보다 보고와 중단 조건을 먼저 읽습니다
제안에 금액이 보이면 그 숫자부터 비교하게 됩니다. 하지만 같은 가격처럼 보여도 사용 범위와 보고 방식이 다르면 단순 비교가 어렵습니다. 정산 주기, 이용 내역을 볼 수 있는 범위, 오류를 발견했을 때 문의할 경로까지 함께 적어야 실제 운영 부담을 판단할 수 있습니다.
구매자 보고가 중심인 구조에서는 보고된 수치의 의미를 이해하는 일이 중요합니다. 내 방문 통계와 수치가 다르다고 곧바로 누락이라고 결론 내리기보다 각각 무엇을 세는지 대조해야 합니다. 반대로 설명할 수 없는 차이를 그냥 새로운 시장의 특성이라며 넘길 이유도 없습니다.
예를 들어 글 하나가 여러 번 쓰였다는 보고를 받는다면, 그 여러 번이 요청 수인지 다른 단위인지부터 확인합니다. 전체 합계만 제공된다면 개별 글에 대한 판단은 제한될 수 있습니다. 이때 필요한 것은 더 정밀한 수익 예측이 아니라 현재 자료로 알 수 있는 범위를 정확히 표시하는 일입니다.
- 읽기 전: 내 콘텐츠 목록과 운영 환경을 정리합니다.
- 제안 비교: 금액과 사용 범위, 보고 단위를 같은 줄에 적습니다.
- 참여 판단: 확인할 수 없는 조건과 그 영향을 남깁니다.
- 참여 이후: 실제 보고와 정산을 대조할 담당 시간과 기록 위치를 정합니다.
- 보류 기준: 중요한 사용 범위나 중단 절차를 설명할 수 없으면 결정을 미룹니다.
혼자 운영하는 서비스에서는 작은 수익도 의미가 있지만, 확인과 문의에 쓰는 시간도 비용입니다. 월말에 읽지 못하는 보고서가 쌓이는 구조라면 새 수익원이 일을 줄여 주는 것은 아닙니다. 참여를 결정하기 전 관리할 수 있는 범위부터 정해 두는 편이 지속하기 쉽습니다.
수익 실험 때문에 글의 목적을 바꾸지는 않습니다
보상 방식이 새로 생기면 거기에 맞춘 글을 더 만들어야 할 것 같은 압박이 생길 수 있습니다. 그러나 아직 확인되지 않은 구매 수요를 상상하며 비슷한 글을 늘리면 사람이 읽을 이유부터 약해질 수 있습니다. 저는 기존 독자의 질문에 답하는 글을 유지하면서 유통 조건을 따로 관찰하는 편이 낫다고 생각합니다.
어떤 자료가 가치 있는지는 주제 이름만으로 정해지지 않습니다. 오류를 재현한 조건, 수정이 실패했던 이유, 운영에서 선택을 바꾼 기준처럼 다른 사람이 판단을 재사용할 수 있는 정보가 필요합니다. 이런 기록은 새 보상 체계가 자리 잡지 않더라도 원래 독자에게 도움이 됩니다.
검토를 다시 할 조건도 구체적으로 정할 수 있습니다. 내 플랫폼의 공식 지원이 생겼을 때, 참여 대상이 명확해졌을 때, 이용 보고 예시를 확인했을 때처럼 판단에 필요한 정보가 바뀌는 시점입니다. 관련 뉴스가 나올 때마다 사이트를 이전하거나 설정을 바꿀 필요는 없습니다.
마치며: 받을 금액보다 설명할 수 있는 조건이 먼저입니다
Pay Per Use는 콘텐츠 이용 대가를 협의하는 새로운 시도이지만, 개인 블로그의 자동 수익을 보장하는 장치는 아닙니다. 내 운영 환경의 제어권, 콘텐츠 범위, 구매 조건과 사용 보고를 구분해야 기대와 현실을 함께 볼 수 있습니다.
오늘 할 일로는 최근 글 세 편의 주소와 외부 자료 포함 여부를 적어 보시길 권합니다. 이어서 사이트 설정을 어디까지 직접 바꿀 수 있는지 한 줄 덧붙이면 됩니다. 그 작은 목록이 있어야 새로운 보상 제안을 보았을 때 내 상황에 적용되는 이야기인지부터 판단할 수 있습니다.
출처: Cloudflare, Pay Per Use 베타 발표(2026-09-30, 확인 2026-10-11). 본문은 공개된 구조에 대한 검토이며, 실제 가입·정산 경험이나 개별 플랫폼의 지원을 확인한 결과가 아닙니다.
'인생잡담 > 1인 개발자의 현실' 카테고리의 다른 글
| 오픈소스 첫 기여를 유지보수자의 언어로 읽는 법 (0) | 2026.09.14 |
|---|---|
| 유지보수 계약으로 바꾼 1인 개발자의 일거리 정리 — 계속 만들기 위해 줄이는 일의 기준 (0) | 2026.09.10 |
| 혼자 만든 서비스를 접어야 할 때 — 유지·전환·종료 판단 기준 6가지 (0) | 2026.08.17 |
| 사이드 프로젝트, 수익 나는 사람은 4%뿐 — 숫자로 본 인디해킹의 현실 (0) | 2026.08.16 |