애드센스 간접 수익화 | 회원과 결제가 없는 정적 사이트

간접 수익화

직접 판매형은 상품, 배송, 환불, 결제, 고객 계정이 설계의 중심이다. 방문자가 장바구니에 담고 카드로 결제하면, 운영자가 대금과 배송과 환불을 직접 처리한다. 고객 이메일과 주문 기록이 운영자 DB에 쌓인다. 광고주와의 미수금도 운영자 몫이다. 미수금은 광고주가 아직 주지 않은 대금이다. 직접형은 그 추심을 운영자가 진다.

애드센스 간접형은 그 층을 운영자가 쥐지 않는다. 방문자가 글을 읽고, Google 네트워크가 그 페이지에 광고를 붙이고, 클릭이나 노출에 따라 Google이 게시자에게 정산한다. 대신 검색 의존, 계정 제한, 무효 트래픽, 소득 신고 검토는 남는다. 월급처럼 고정액을 보장하는 구조가 아니다. 검색에 글이 안 잡히면 방문이 없고, 방문이 없으면 매칭할 페이지가 없다. 그래서 첫 세션의 본체는 결제 모듈이 아니라 읽을 글과 정책에 맞는 본문이다.

자격은 공식 문서 기준이다. 정책에 맞는 콘텐츠, 독창적인 본문, 만 18세 이상. 「글 몇 개면 무조건 승인」 같은 보장 숫자는 없다. AdSense 약관의 18세는 국내 민법상 성년과 같은 숫자가 아니다. 미성년은 보호자 계정 경로가 별도로 있다.

게시자는 페이지를 열고 글을 유지하는 쪽이다. 광고주는 Google 네트워크를 통해 그 페이지에 노출을 산다. 방문자는 글을 읽으러 온 사람이지, 운영자의 고객 계정이 아니다. 간접형이라는 말이 개인정보 부재를 뜻하지는 않는다. 회원가입이 없어도 Google과 서드파티가 쿠키와 광고 식별자를 쓴다.

핵심 포인트: 첫 세션의 목표는 회원과 결제, 문의 저장이 없는 정적 사이트에 개인정보처리방침과 서버 전용 비밀키를 두는 것이다.

AdSense가 하는 일

페이지가 열리면 브라우저가 광고 스크립트를 받는다. 스크립트는 게시자 ID(pub-...)와 광고 단위 코드로 슬롯을 찾고, Google 쪽에 페이지 내용과 방문 맥락을 넘겨 매칭을 요청한다. 매칭은 그 페이지에 어떤 광고를 넣을지 고르는 일이다. 정산은 그 노출이나 클릭을 게시자 계정에 쌓아 지급하는 단계다. 운영자가 광고주와 단가를 협상하는 화면은 없다.

게시자는 슬롯이 있는 HTML을 유지한다. Google은 광고주 수요와 페이지 신호를 맞춘다. 광고주는 네트워크를 통해 노출을 산다. 세 주체가 한 요청 안에서 만난다. 운영자 DB에 주문 row가 생기지 않는 이유가 이 분리에 있다. 대신 계정 제한과 무효 트래픽 심사는 Google 쪽이 연다. 정산 주기와 지급 하한은 Help가 기준이다. 본문에 없는 금액을 만들지 않는다.

게시자 ID와 광고 단위 코드는 페이지 소스에 나타난다. Google이 페이지에 광고를 붙이려면 그 식별자가 HTML에 있어야 한다. 숨기려고 서버만 알게 하면 광고가 안 붙는다. DB 관리자 키나 결제 비밀키와 같은 등급으로 취급하지 않는다. Publisher ID Help가 이 차이를 설명한다. 게시자 ID는 계정을 가리키는 공개 번호다. 광고 단위 코드는 그 계정 아래 슬롯을 가리킨다.

승인 심사는 가치 있는 콘텐츠와 정책 준수가 본체다. PSI 점수 몇 점이면 안전하다는 공식 기준선은 없다. 빈 목록이 200으로 열리거나 주제가 흩어지면 속도보다 먼저 반려 사유가 된다. 심사 전에 속도 점수를 위해 본문을 지우거나 광고를 숨기는 편법은 정책 리스크다.

계정 제한은 정산이 멈추거나 사이트 연결이 끊기는 쪽으로 나타난다. 무효 트래픽, 정책에 안 맞는 콘텐츠, 필수 고지 누락이 그 입구다. Help 문장이 본문과 다르면 Help가 이긴다. ads.txt는 도메인에서 누가 광고를 팔 수 있는지를 선언하는 파일이다. 필수 콘텐츠와 쿠키 고지 Help가 고지 페이지와 함께 이 파일을 점검 목록에 둔다. HTTPS가 아니면 스크립트와 쿠키 경로가 브라우저에서 막히거나 경고가 난다.

ads.txt는 사이트 루트에 두는 텍스트다. 광고를 사는 쪽이 그 파일을 읽어, 이 도메인의 재고를 팔 권한이 있는 계정을 확인한다. 방침 페이지와 같이 점검 목록에 있는 이유는, 고지와 판매 권한이 심사에서 한 묶음으로 보이기 때문이다. 파일만 있고 방침에 쿠키와 거부 경로가 없으면 고지가 비어 있다. 방침만 있고 ads.txt가 없으면 판매 권한 선언이 비어 있다. HTTPS가 아니면 스크립트와 쿠키가 브라우저에서 막히거나 경고가 나, 슬롯이 비어도 방문 맥락은 이미 새어 나갈 수 있다.

정적 사이트에 남기는 페이지

정적 사이트는 방문마다 서버가 주문을 받거나 계정을 만들지 않는 구성이다. HTML과 CSS, 이미지, 글 본문이 호스팅에서 그대로 나간다. 주제 하나인 골격이면 홈, 글, 소개, 개인정보처리방침이 남는다. 회원가입, 로그인, 주문, 결제, 배송지, 댓글, 뉴스레터, 문의폼, 파일 업로드는 이 골격 밖에 있다.

폼이 있다는 말은 브라우저가 이름과 이메일을 서버로 보낸다는 뜻이다. 그 순간부터 운영자는 보관 기간, 삭제 요청, 스팸, 첨부 악성 파일을 같이 진다. 댓글과 문의함은 화면상으로는 작아 보여도, 개인정보처리의 입구로는 회원 가입과 같은 등급이다. 뉴스레터는 수신 동의와 수신 거부 경로가 따로 필요한 수집이다. 파일 업로드는 저장 위치와 공개 URL이 생기기 때문에, 정적 골격의 이미지 CDN과도 성격이 다르다.

AI에게 「일단 다 만들어」라고 하면 그 기능이 한 번에 열려 공격면이 넓어진다. 공격면은 공격자가 닿을 수 있는 입구의 넓이다. 회원, 결제, 문의, 업로드가 한꺼번에 열리면 그 입구가 같이 늘어난다.

채팅에 고정하는 제약의 예는 제품 설정이 아니라, 대화에 남기는 범위 문장이다. 다음 블록이 그 형태다.

목표: 정적 콘텐츠 사이트. 수익화는 애드센스 간접형만.
금지: 회원가입, 로그인, 결제, 문의폼, 댓글, 업로드, 뉴스레터.
비밀키: 서버 Secrets만. 프론트와 채팅에 실제 키와 PII 금지.
필수 페이지: 개인정보처리방침(Google 쿠키, 맞춤광고, 거부 링크 포함).

PII는 개인식별정보다. 이름, 이메일, 전화, 주문, 토큰이 여기에 해당한다.

회원가입을 빼는 이유

회원가입은 화면의 버튼이 아니라 계정 테이블이다. 이메일을 받아 비밀번호 해시를 저장하고, 세션 쿠키를 발급하고, 비밀번호 재설정 메일을 보내면, 그 순간부터 운영자는 계정 탈취, 스팸 가입, 삭제 요청, 로그의 이메일을 같이 진다. 애드센스 정산은 그 테이블을 필요로 하지 않는다.

로그인은 같은 테이블의 다른 입구다. /login, /signup, /auth 링크가 메뉴에 있으면 방문자는 폼이 있다고 느낀다. 링크만 있고 404여도 심사는 메뉴 문구를 기능으로 읽는다. 숨은 라우트가 빌드에 남아 있으면 검색 로봇이 그 주소를 따라가 빈 폼이나 오류 페이지를 색인할 수 있다.

「나중에 팔 수도 있으니 미리 회원을 넣는다」는 선택이 사고를 자주 만든다. 지금 붙이면 테스트 계정과 더미 비밀번호, 문의함 스팸까지 한꺼번에 운영 부담이 된다. 팔 시점에 붙이면 된다. 간접형의 짧은 공격면은 계정 층을 열지 않는 데서 나온다.

관리자 인증을 첫 세션에 열면 열쇠와 세션 쿠키가 같이 생긴다. 글 수정은 로컬에서 하거나, 호스팅이 제공하는 비공개 배포 경로가 있으면 그쪽으로 둔다. 방문자용 사이트와 글 고치는 도구를 같은 공개 도메인에 붙이면, 관리 입구가 광고 페이지와 같은 공격면에 놓인다.

쿠키와 행태정보

쿠키는 브라우저에 남는 작은 기록이다. 광고 네트워크는 그 기록으로 같은 방문자를 페이지 사이에서 이어 본다. 행태정보는 어떤 글을 읽었는지, 어디에 머무르는지 같은 이용 흔적이다. 회원가입 버튼이 없어도 이 층은 광고 스크립트가 붙는 순간 열린다. 스크립트가 HTML에 있으면 브라우저는 제3자 도메인으로 요청을 보낸다. 그 요청에 쿠키가 실릴 수 있다. 운영자 서버가 이메일을 받지 않아도, Google과 서드파티 쪽에는 식별자가 남는다.

맞춤광고는 그 흔적으로 광고를 고르는 방식이다. 끄거나 거부하는 경로가 방침 문장에 없으면, 정적 사이트라도 고지가 비어 있는 상태가 된다. Google 광고 설정은 계정에 로그인한 방문자가 맞춤광고를 줄이는 화면이다. aboutads.info는 업계 옵트아웃 안내 주소의 예로 본문에 등장한다. 두 경로가 방침 문장에 같이 있는 구성이 정적 골격의 최소다. 링크가 푸터에만 있고 방침 본문에 문장이 없으면, 심사와 방문자가 같은 페이지에서 거부 방법을 못 찾는다.

가입 폼이 없어도 IP, 접속 시간, 기기, 방문 페이지, 광고 식별자, 리퍼러가 남을 수 있다. IP는 접속한 네트워크 주소다. 리퍼러는 어느 페이지에서 왔는지를 담는 헤더다. 분석 스크립트는 그 흔적을 집계 서버로 보낸다. 분석과 광고는 필요할 때만 켠다. 방문 통계만 필요하면 광고 식별자까지 켜지 않는 구성이 공격면이 작다. 둘을 한 태그에 묶으면 방침에 적을 항목이 같이 늘어난다.

세 행의 아래 둘을 미리 열면 간접형의 짧은 공격면이 사라진다. 맨 위 행은 가입을 없애도 남으므로 방침 문장이 정적 골격의 필수다. Privacy Mode나 유명 도구라는 이유만으로 이 층이 닫히지는 않는다. Cursor Data Use는 채팅 학습과 보관을 다를 수 있다고 적을 뿐, 방문자 쿠키를 대신 고지하지 않는다.

개인정보처리방침

필수 콘텐츠와 쿠키 고지는 AdSense Help에 페이지가 따로 있다. 방침 URL이 푸터에 없어도, 페이지가 있어도 거부 경로가 링크가 아니면 고지가 끝난 것이 아니다. 「개인정보를 소중히 합니다」만 있으면 수집 항목과 거부 경로가 비어 있다.

방침 문장에 들어가는 최소는 Google과 서드파티 쿠키, 맞춤광고, 거부 경로다. 거부 경로의 예는 광고 설정과 aboutads.info다. 수집하는 것이 광고 식별자와 접속 로그뿐이어도, 목적과 보관, 거부 방법을 적는다. 정적 사이트에도 이 고지가 필요하다.

해외 방문이 있으면 AdSense Privacy and messaging 등으로 EEA, 영국, 스위스용 인증 CMP가 대상이 된다. CMP는 동의 관리 플랫폼이다. 배너 한 장만 있고 거부 선택이 없으면 고지가 아닌 장식에 가깝다. 국내만 타깃이어도 방침 문장은 남긴다. EEA와 영국, 스위스 동의 요건은 AdSense Help에 따로 있다.

해외 트래픽을 처음부터 크게 받을 계획이면 쿠키 고지 수준을 넘어 인증 CMP와 지역별 동의 흐름이 별도 세션이 된다. 정적 한국어 블로그 가정과 요구사항이 다르다.

무효 트래픽

무효 트래픽은 사람이 글을 읽어서 생긴 클릭이 아니라, 유도나 봇, 실수 클릭에 가까운 요청이다. Invalid traffic 문서가 이 구간의 1차 출처다. 본인과 지인에게 광고 클릭을 부탁하거나 「광고 눌러 후원」, 품질을 모르는 유료 트래픽, 메뉴와 광고를 같은 모양으로 붙이는 일은 계정 위험에 가깝다.

메뉴 버튼과 광고 슬롯이 같은 색과 같은 높이에 있으면, 글을 누르려다 광고를 누른 기록이 쌓인다. 실수 클릭은 방문자가 글을 읽으려다 생긴 입력이지만, 네트워크가 유도로 읽을 수 있다. 슬롯과 본문 링크를 시각적으로 가르는 쪽이 계정 위험을 줄인다.

본인 광고를 반복 클릭하거나 지인에게 「한 번만 눌러 달라」고 하면 무효 트래픽으로 분류될 수 있다. 테스트는 광고 없는 스테이징에서 한다. 스테이징은 프로덕션과 같은 빌드이나 광고 스크립트만 뺀 주소인 경우가 많다.

계속되거나 반복되는 광고 수입은 소득 신고 검토 대상일 수 있다. 규모가 커지면 국세청 또는 세무 전문가가 기준이다. 이 문서는 세무 자문이 아니다.

API 키

비밀키는 브라우저에 두지 않는 쪽이 맞다. AI, DB, 메일, 결제, 관리자 토큰은 호스팅 Secrets에 둔다. Secrets는 빌드와 런타임 서버만 읽는 저장소다. .env라도 NEXT_PUBLIC_나 VITE_ 접두사가 붙으면 빌드가 그 값을 프론트 번들에 싣는다. 접두사가 붙은 변수는 「브라우저에도 보여도 된다」는 표시라, 관리 열쇠에 붙이면 설계가 뒤집힌다.

방문자가 개발자 도구로 문자열을 읽는다. 한 번 노출되면 저장소에서 지우는 것만으로는 부족하고, 키를 폐기하고 재발급하는 절차가 남는다. GitHub Secret Scanning은 공개 저장소에서 열쇠 모양 문자열을 찾는다. 이미 커밋된 키는 히스토리와 CDN 캐시에 사본이 남을 수 있다. 최근 커밋만 고치면 옛 커밋을 받은 사람은 옛 값을 그대로 가진다.

페이지 소스와 번들에서 sk-, service_role, API_KEY, SECRET 문자열이 보이면 프론트 유출이다. 애드센스 pub-는 공개 전제라 이 목록에서 제외한다. 채팅에 실제 키를 붙여 오류를 재현하는 습관도 같은 유출이다. 재현은 스키마와 마스킹한 로그만으로도 되는 경우가 많다.

소스맵은 압축된 스크립트를 원본 줄로 되돌리는 파일이다. 프로덕션에 소스맵이 열려 있으면 변수 이름과 경로가 방문 도구에 드러난다. 관리 열쇠가 그 파일에 문자열로 남아 있으면 번들만 지워도 부족하다.

게시자 ID pub-는 HTML에 있어야 광고가 붙는다. 그걸 시크릿 저장소에만 두면 슬롯이 비어 심사가 콘텐츠와 고지만 본다. 반대로 결제 비밀키를 pub-처럼 페이지에 두면 방문자가 출금 경로를 갖는다. Publisher ID Help가 공개 전제를 설명하는 이유다. 호스팅 Secrets에 둔 값은 서버 로그에 찍히지 않게 하고, 채팅 재현에도 붙이지 않는다. 노출이 의심되면 그 키를 폐기하고 새 값을 Secrets에만 넣는다. 저장소 히스토리의 옛 값은 이미 나간 사본이다.

개인정보가 새는 네 경로

바이브 코딩의 속도는 장점이다. 위험은 작동하는 코드가 곧 안전한 코드가 아니라는 점이다. AI는 요청한 기능을 빨리 붙이지만, 요청하지 않은 보안을 자동으로 채운다고 보장하지 않는다. 유출은 네 갈래로 갈린다.

첫째는 채팅이다. 오류를 고치려 고객 이름, 이메일, 전화, 주문, DB 덤프, 서버 로그, 토큰, 비밀번호, 결제 데이터를 통째로 채팅에 넣으면 도구 정책과 무관하게 밖으로 나간다. 채팅 로그는 로컬 히스토리와 클라우드 동기화, 팀 공유에 사본이 남을 수 있다. 안전한 요청은 가상 식별자, 마스킹한 로그, 스키마와 재현 단계만 남긴다. 가상 식별자는 user-1처럼 실제 이름이 아닌 자리 표시다. Cursor Data Use에 따르면 Privacy Mode에 따라 학습과 보관이 달라질 수 있다. 유명 도구라는 이유만으로 비공개라고 가정하지 않는다.

둘째는 프론트 번들이다. 브라우저 JS에 AI나 DB 관리, 메일, 클라우드, 결제, 관리자 키가 들어가면 방문자가 본다. 번들은 페이지가 불러오는 자바스크립트 파일이다.

셋째는 DB 정책이다. 정적 애드센스 사이트라면 DB와 인증을 아예 두지 않는 선택이 가장 짧다. 나중에 글을 관리하려고 테이블을 미리 만들면, 그 테이블이 비어 있어도 접속 열쇠와 정책이 이미 생긴다. RLS를 켰다고 끝이 아니다. 모든 행 공개, 비로그인 수정, service_role이 브라우저에 포함, 테스트용 공개 정책을 그대로 배포하는 사고가 흔하다. RLS는 행 단위 접근 제어다. 정책이 「모두 읽기」로 열려 있으면 스위치만으로는 막히지 않는다. service_role은 정책을 건너뛰는 관리 열쇠라, 프론트 번들에 실리면 방문자가 테이블을 우회한다.

넷째는 로그와 분석이다. 가입 폼이 없어도 IP, 접속 시간, 기기, 방문 페이지, 광고 식별자, 리퍼러가 남을 수 있다. 방침에 수집과 목적, 보관, 거부 방법을 적는다. 분석 스크립트는 필요할 때만 켠다. 서버 액세스 로그에 쿼리스트링으로 이메일이 실리면, 회원 테이블이 없어도 네 번째 갈래가 열린다. 문의폼을 빼는 이유가 그 쿼리를 만들지 않기 위해서이기도 하다.

네 경로는 서로 겹친다. 채팅에 붙인 덤프가 프론트 키를 포함하고, 그 키가 열린 DB로 이어지는 식이다. 첫 세션에서 회원과 결제를 두지 않으면 세 번째 갈래가 아예 생기지 않는다. GitHub Secret Scanning은 공개 저장소에서 열쇠 모양 문자열을 찾는다. 이미 커밋된 키는 히스토리와 CDN 캐시에 사본이 남는다. 최근 커밋만 고치면 옛 커밋을 받은 사람은 옛 값을 가진다. 폐기와 재발급이 본체다.

공개 URL에서 확인하는 항목

문서에 「했다」고 적는 것과 배포 URL에서 드러나는 것은 다르다. 스테이징이 프로덕션과 같은 빌드면 그 URL이 기준이다. 로컬호스트에서만 메뉴를 보면, 배포 뒤에 남은 /signup 링크를 놓친다.

수익 모델이 간접형인지는 결제 버튼, 장바구니, 「구매하기」가 본문과 헤더, 푸터에 없는지로 갈린다. 있으면 이 문서의 범위가 아니다. 문의 제출, 댓글 입력, 파일 첨부가 동작하면 서버에 이메일이 쌓이는지가 네트워크 탭에 나타난다. 화면에 입력칸이 없어도 fetch나 action이 메일 API를 부르면 수집이 있는 것이다.

위 항목이 닫힌 뒤에 AdSense 코드를 넣는 순서가 사고 입구를 줄인다. 승인을 서두르는 것보다, 빨리 만든 사이트가 바로 사고 나는 사이트로 가는 길을 먼저 닫는 쪽이 본문에 맞는 순서다.

결제와 회원이 본체일 때

사이트의 본체가 디지털 상품 판매, 컨설팅 예약, 회원제, 결제이면 빼기 전략을 그대로 따르지 않는다. 그때는 결제와 계정, 환불이 설계의 중심이고 애드센스는 부가다. 부가 광고는 본문 옆 슬롯이지, 상품 페이지를 대신하지 않는다. 환불 창구와 계정 삭제가 없는 회원제는 방침이 비어 있는 상태와 같다.

결제대행(PG) 약관, 환불 창구, 파일 다운로드 권한은 애드센스 Help가 아니라 PG와 상거래 규칙 쪽이다. 회원제는 최소 수집과 보관 기간, 삭제 경로가 방침의 중심이 된다. 회사 도메인과 회사 Git에 개인 부업 광고를 올리는 구성은 겸업과 보안 규정이 개인 저장소와 다르다. 이미 로그인 코드가 있는 저장소는 기능을 통째로 빼기보다, PII가 있는 테이블 목록을 먼저 보고 권한을 줄인다.

채팅에 남기는 범위

바이브 코딩의 첫 세션은 대화 한 줄이 곧 라우트와 폼이 된다. 「랜딩 페이지 만들어 줘」만 보내도 회원가입과 문의폼이 붙는 이유는, 모델이 일반적인 사이트 골격으로 그 기능을 넣기 때문이다. 금지 목록이 대화에 없으면 그 기능은 기본값에 가깝다. 목표 문장에 정적 콘텐츠와 애드센스 간접형만 적고, 회원가입과 로그인, 결제, 문의폼, 댓글, 업로드, 뉴스레터를 금지에 두는 이유가 여기 있다.

비밀키 줄은 서버 Secrets만 허용한다. 프론트와 채팅에 실제 키와 PII를 붙이지 않는다는 문장이 같이 있어야, 오류를 재현하려고 덤프를 붙이는 습관이 막힌다. 가상 식별자 user-1과 마스킹한 로그, 스키마와 재현 단계만으로도 대부분의 화면 오류는 재현된다. Cursor Data Use는 Privacy Mode에 따라 학습과 보관이 달라질 수 있다고 적는다. 유명 도구라는 이유만으로 채팅이 비공개라고 가정하지 않는 근거가 그 문서다.

필수 페이지 줄에 개인정보처리방침을 넣고, Google 쿠키와 맞춤광고, 거부 링크를 괄호로 고정한다. 이 줄이 없으면 모델이 「개인정보를 소중히 합니다」한 문단으로 방침을 채운다. 필수 콘텐츠와 쿠키 고지 Help가 요구하는 것은 그 문장이 아니라, 쿠키와 맞춤광고와 거부 경로가 링크로 있는 페이지다.

거부 경로의 예는 광고 설정과 aboutads.info 링크다. 방침에 수집 항목과 목적, 보관, 거부 방법이 문장으로 있어야 한다. 가입 폼이 없어도 IP, 접속 시간, 기기, 방문 페이지, 광고 식별자, 리퍼러가 남을 수 있다. 분석과 광고는 필요할 때만 켠다. Privacy and messaging은 EEA와 영국, 스위스 방문이 있을 때 인증 CMP를 점검하는 화면이다. 배너 한 장만 있고 거부 선택이 없으면 고지가 아닌 장식에 가깝다.

PII를 채팅에 넣은 뒤에는 도구 정책과 무관하게 사본이 밖으로 나간다. 로컬 히스토리, 클라우드 동기화, 팀 공유가 그 사본의 자리이다. 이미 붙여 보낸 키는 채팅에서 지우는 것만으로 끝나지 않는다. API 키 절과 같이 폐기와 재발급이 본체다.

광고 코드를 넣는 순서

위 항목이 닫히기 전에 AdSense 코드를 넣으면, 심사 대상 페이지에 빈 폼과 키 문자열이 같이 올라간다. 승인을 서두르는 것보다, 빨리 만든 사이트가 바로 사고 나는 사이트로 가는 길을 먼저 닫는 쪽이 본문에 맞는 순서다. 홈과 대표 글과 목록이 빈 본문 200이 아닌지, 개인정보처리방침이 거부 경로를 문장으로 갖는지, 번들에 관리 열쇠가 없는지를 배포 URL에서 본 뒤에 스크립트를 붙인다.

게시자 ID는 페이지 소스에 나타난다. 숨기려고 서버만 알게 하면 광고가 안 붙는다. 광고 단위 코드는 그 계정 아래 슬롯을 가리킨다. 둘 다 공개 전제다. DB 관리자 키나 결제 비밀키와 같은 등급으로 취급하지 않는다. Publisher ID Help가 이 차이를 설명한다.

테스트 클릭은 광고 없는 스테이징에서 한다. 스테이징은 프로덕션과 같은 빌드이나 광고 스크립트만 뺀 주소인 경우가 많다. 본인 광고를 반복 클릭하거나 지인에게 「한 번만 눌러 달라」고 하면 무효 트래픽으로 분류될 수 있다. Invalid traffic 문서가 그 분류의 1차 출처다. 메뉴 버튼과 광고 슬롯이 같은 색과 같은 높이에 있으면, 글을 누르려다 광고를 누른 기록이 쌓인다. 슬롯과 본문 링크를 시각적으로 가르는 쪽이 계정 위험을 줄인다.

자격은 정책에 맞는 콘텐츠, 독창적인 본문, 만 18세 이상이다. 「글 몇 개면 무조건 승인」 같은 보장 숫자는 없다. AdSense 약관의 18세는 국내 민법상 성년과 같은 숫자가 아니다. 미성년은 보호자 계정 경로가 별도로 있다. Help 문장이 본문과 다르면 Help가 이긴다.

계속되거나 반복되는 광고 수입은 소득 신고 검토 대상일 수 있다. 규모가 커지면 국세청 또는 세무 전문가가 기준이다. 이 문서는 세무 자문이 아니다. 계정 제한은 정산이 멈추거나 사이트 연결이 끊기는 쪽으로 나타난다. 무효 트래픽, 정책에 안 맞는 콘텐츠, 필수 고지 누락이 그 입구다.

EEA와 영국, 스위스 방문이 있으면 Privacy and messaging으로 인증 CMP를 점검한다. 배너 한 장만 있고 거부 선택이 없으면 고지가 아닌 장식에 가깝다. 국내만 타깃이어도 방침 문장은 남긴다. 해외 트래픽을 처음부터 크게 받을 계획이면 지역별 동의 흐름이 별도 세션이 된다. 정적 한국어 블로그 가정과 요구사항이 다르다.

방문에서 정산까지

방문자가 글을 열면 브라우저는 HTML을 받고, 그 안에 있는 광고 스크립트를 실행한다. 스크립트는 게시자 ID와 광고 단위 코드로 슬롯을 찾고, 페이지 내용과 방문 맥락을 Google 네트워크에 넘긴다. 매칭은 그 요청에 어떤 광고를 넣을지 고르는 일이다. 노출이나 클릭이 계정에 쌓이면 정산이다. 운영자가 광고주와 단가를 협상하는 화면은 이 경로에 없다. How AdSense works가 그리는 콘텐츠, 방문, 매칭, 정산이 이 순서다.

슬롯이 본문 링크와 같은 색이면 글을 누르려다 광고를 누른 기록이 쌓인다. 그 기록은 방문자가 읽어서 생긴 입력이지만, 네트워크가 유도로 읽을 수 있다. 본인과 지인 클릭, 「광고 눌러 후원」, 품질을 모르는 유료 트래픽이 같은 Invalid traffic 문서의 계정 위험 쪽에 가깝다. 테스트는 광고 없는 스테이징에서 한다.

가입이 없어도 스크립트가 붙는 순간 쿠키와 행태정보가 열린다. 방침에 광고 설정과 aboutads.info가 링크로 없으면 고지가 비어 있다. 분석 스크립트는 IP, 접속 시간, 기기, 방문 페이지, 광고 식별자, 리퍼러를 집계 서버로 보낼 수 있다. 필요할 때만 켠다. 회원 이메일과 주문 DB는 이 골격 밖에 두는 편이 간접형의 짧은 공격면이다. 나중에 팔 시점에 결제와 계정을 붙인다. 지금 붙이면 테스트 계정과 문의함 스팸이 같이 열린다.

프론트 번들의 NEXT_PUBLIC_와 VITE_는 방문자가 개발자 도구로 읽는다. GitHub Secret Scanning은 공개 저장소에서 열쇠 모양 문자열을 찾는다. 이미 커밋된 키는 히스토리와 CDN 캐시에 사본이 남는다. 최근 커밋만 고치면 옛 커밋을 받은 사람은 옛 값을 가진다. 폐기와 재발급이 본체다. 소스맵이 프로덕션에 열려 있으면 변수 이름과 경로가 드러난다. RLS를 「모두 읽기」로 열어 두고 service_role을 번들에 실으면, 스위치만으로는 테이블이 막히지 않는다. 정적 애드센스 사이트라면 DB와 인증을 아예 두지 않는 선택이 가장 짧다.

채팅 제약 블록의 목표, 금지, 비밀키, 필수 페이지 네 줄이 첫 세션의 계약이다. 그 계약이 대화에 없으면 모델이 일반적인 사이트 골격으로 회원가입과 문의폼을 넣는다. 배포 URL에서 결제 버튼과 /signup과 방침 문장과 번들 열쇠를 본 뒤에 AdSense 코드를 넣는다. 로컬호스트만 보면 배포 산출물에 남은 링크를 놓친다.

마무리

앞에서 다룬 애드센스 간접 수익화의 핵심만 짧게 정리한다.

• 간접형은 상품과 결제를 운영자가 직접 쥐지 않는다. Google이 매칭과 정산을 맡는다.
• 첫 세션의 골격은 홈, 글, 소개, 개인정보처리방침이다. 회원과 결제와 문의 저장은 그 밖에 있다.
• 가입이 없어도 광고 쿠키와 행태정보는 남고, 방침에 거부 경로가 문장으로 들어간다.
• 비밀키는 서버 Secrets에 두고, 노출되면 폐기와 재발급이다. pub-는 공개 전제다.
• 유출은 채팅의 PII, 프론트 키, 열린 DB, 로그와 분석 네 갈래다.
• 무효 트래픽과 광고 슬롯 혼동은 계정 위험과 연결된다.
• 판매가 본체면 이 문서의 빼기 전략이 그대로 적용되지 않는다.

「애드센스 첫 세션은 기능을 더하는 일이 아니라 책임을 빼는 일이다」 게시자 ID는 공개 전제이고, DB 관리 키와 같은 등급이 아니다.

출처와 링크

• How AdSense works: https://support.google.com/adsense/answer/6242051
• Eligibility requirements: https://support.google.com/adsense/answer/9724
• 필수 콘텐츠와 쿠키 고지: https://support.google.com/adsense/answer/1348695?hl=ko
• EEA UK CH 동의 요건: https://support.google.com/adsense/answer/13790256
• Invalid traffic: https://support.google.com/adsense/answer/16737
• Publisher ID: https://support.google.com/adsense/answer/105516
• Cursor Data Use: https://cursor.com/data-use
• GitHub Secret Scanning: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning

조사 기준: 2026년 8월. AdSense 정책과 동의 요건은 바뀔 수 있으므로 신청과 배포 직전 공식 Help가 기준이다. 범위는 회원과 결제가 없는 정적 사이트와 애드센스 첫 세션이다.