독자가 글 끝까지 안 읽는다면 본문을 광고로 샌드위치 만들지 마세요: PC 화면의 빈 옆자리를 파는 애드스테라 배치법

1. "광고는 있는데, 끝까지 읽어야 만날 수 있다"는 슬픈 배치

글을 올리는 사이트에 광고를 달았다.

화면에도 제대로 뜬다. 좋다.

그런데 자세히 보니 광고가 글 한참 아래에 있다.

독자는 제목을 읽는다. 도입부를 읽는다. 중간쯤에서 원하는 답을 얻는다. 검색 결과로 돌아간다. 다른 글로 넘어간다.

광고는 그 아래서 하염없이 기다린다.

"오늘도 아무도 못 만났습니다."

이러면 광고가 있어도, 위쪽만 읽고 떠나는 방문을 수익 기회로 충분히 바꾸지 못한다.

여기서 제일 먼저 떠오르는 생각이 "그럼 페이지 열자마자 큼직한 광고를 띄우면 되잖아"다.

이론상으로는 빠르다.

하지만 글을 읽으러 온 독자에게 광고 면접부터 보게 하는 사이트는 보통 미움을 받는다.

Coalition for Better Ads(더 나은 광고 연합)의 연구에서는 PC의 팝업, 카운트다운이 붙은 전면 광고(prestitial), 화면에 계속 붙어 따라다니는 대형 고정(sticky) 광고 등을 소비자가 받아들이기 어려운 광고 경험으로 분류한다. 2026년 업데이트에서는 PC 본문 영역에서 광고 밀도가 50%를 넘는 경우도 기준 미달로 추가됐다. ^[1][2]

그러니까 문제는

"광고를 더 많이 보여주고 싶다"

가 아니다.

"본문을 방해하지 않고, 독자가 자연스럽게 지나가는 자리로 광고 자리를 옮기고 싶다"

이다.

2. 그리고 PC 화면을 본다. "옆자리, 엄청 비어 있지 않나?"

스마트폰은 좁다.

본문만으로도 폭이 빠듯하다. 거기에 광고를 여러 장 끼워 넣으면 글은 금방 광고 밀푀유가 된다.

반면 PC는 다르다.

읽기 편하라고 본문 폭을 줄이면 양옆에 큰 여백이 남는다. 목차를 사이드바에 놓아도 그 위아래가 비어 있을 때가 있다.

여기서 깨닫는다.

본문 안에 광고를 더 넣지 않아도, 옆에 놀고 있는 땅이 있다.

광고 설계라기보다 부동산이다.

한가운데 노른자 땅은 본문에 준다. 독자가 걷는 길은 막지 않는다.

그 옆의 빈 터를 빌려준다.

애드스테라(Adsterra)는 현재 160×300, 160×600, 300×250, 320×50, 468×60, 728×90 등의 배너 크기를 안내하고 있다. 공식 가이드에서도 160×600은 좌우 사이드 배치용, 300×250은 본문 블록이나 사이드바에 잘 어울리는 크기로 소개한다. ^[3]

그래서 PC에서는

광고
↓
목차
↓
광고

라는 세로 배치가 꽤 자연스럽게 성립한다.

독자는 본문을 읽을 수 있다. 광고도 보인다.

길 한복판에 간판을 세울 필요가 없다.

3. PC에서는 "목차의 위아래"가 꽤 알짜 자리

예를 들어 오른쪽 사이드바에 목차가 있는 사이트라면 생각은 단순하다.

목차 위

300×250 같은 중간 크기 배너.

페이지를 연 뒤 비교적 이른 시점에 화면에 들어올 가능성이 높다.

목차

글 안내용 내비게이션.

원한다면 목차만 고정(sticky)으로 둔다.

목차 아래

160×600, 160×300, 또는 레이아웃 폭에 맞는 다른 광고 자리.

긴 글을 읽는 사람일수록 스크롤하다가 이 칸에 가까워진다.

중요한 건 광고까지 계속 고정할 필요는 없다는 점이다.

대형 고정 광고는 독자가 스크롤해도 화면을 계속 차지한다. Coalition for Better Ads에서는 화면의 30% 넘게 차지하는 대형 고정 광고를 PC에서 기준 미달 광고 경험으로 본다. ^[2]

그러니 "빈 옆자리를 쓴다"와 "독자를 옆에서 따라다닌다"는 별개의 이야기다.

여백은 팔자.

독자는 쫓아다니지 말자.

이것만으로도 꽤 품위가 생긴다.

4. 상단 광고도 갖고 싶다. 다만 H1을 광고 밑에 묻지는 말 것

글 끝뿐 아니라 페이지를 연 직후에도 광고 자리는 갖고 싶다.

이때도 맨 위에 거대한 배너를 곧바로 둘 필요는 없다.

자연스러운 순서는 대략

글 제목
→ 개요·메타 정보
→ 광고
→ 목차·본문

정도다.

독자는 먼저 "이게 무슨 글인지"를 확인할 수 있다.

그다음에 광고가 하나 있다.

그리고 본문으로 넘어간다.

애드스테라에는 일반 배너 외에 네이티브 배너(Native Banner)도 있는데, 사이트 쪽에서 블록 크기나 색, 글꼴 크기를 맞추기 쉬운 형식으로 안내된다. ^[4]

다만 "위에 두면 반드시 1PV가 곧 광고 수익"은 아니다.

애드스테라 광고에는 1,000회 노출당 과금(CPM)뿐 아니라 클릭당 과금(CPC), 전환 행동당 과금(CPA) 같은 여러 가격 모델이 있고, 실제 수익은 광고 수요, 국가, 기기, 광고 형식, 트래픽 품질 등에 따라 달라진다. ^[3]

정확히 말하면

이른 위치에 광고를 두면, 끝까지 읽히지 않아도 광고가 노출되고 눈에 띌 기회를 만들기 쉽다.

는 것이다.

"페이지만 열면 반드시 동전이 한 닢 떨어지는 마법 상자"가 아니다.

5. 광고가 뒤늦게 내려와 본문을 날려버리는 건 그만

광고 자리를 늘리면 또 다른 적이 나타난다.

화면 밀림, 즉 CLS(Cumulative Layout Shift)다.

페이지를 연다.

본문을 읽기 시작한다.

몇 초 뒤 광고가 로드된다.

갑자기 그 자리가 200px, 300px로 부풀어 오른다.

읽던 문단이 아래로 튀어 나간다.

글을 읽고 있었는데 바닥이 움직였다.

꽤 불쾌한 경험이다.

web.dev는 광고, iframe, 동적으로 끼워 넣는 요소를 CLS의 대표적인 원인으로 꼽는다. 대책은 광고가 로드되기 전에 min-height나 aspect-ratio 같은 CSS로 필요한 공간을 미리 확보해 두는 것이다. ^[5]

Core Web Vitals(구글의 페이지 경험 지표)에서는 최소 75%의 페이지 방문에서 CLS 0.1 이하를 '좋음'의 기준으로 본다. ^[5]

즉 광고 자리는

로드된 뒤에야 자리를 달라는 손님

이 아니라

처음부터 자리를 예약해 둔 손님

으로 만든다.

PC 사이드라면 300×250 크기의 상자를 먼저 확보한다. 160×600이라면 그 세로 공간을 먼저 잡는다.

광고가 늦게 와도 본문은 움직이지 않는다.

눈에 띄지 않는 차이지만 효과는 크다.

6. 여기서 애드스테라 특유의 함정. "같은 광고 코드를 옆에도 붙이면 되지 않나?"

광고 자리가 하나 있다.

사이드바에도 갖고 싶다.

그럼 같은 코드를 복사해서 두 번 붙이면 순식간에 끝난다.

안타깝게도 이건 애드스테라 스스로 말린다.

공식 가이드에서는 같은 배너 코드를 한 페이지에서 두 번 쓰면 통계와 CPM에 악영향이 갈 수 있으니, 같은 크기를 두 개 쓰더라도 코드를 따로 발급받으라고 안내한다. ^[6]

같은 광고가 동시에 뜨면 독자에게도 광고주에게도 이상한 화면이 되기 쉽다.

그래서

• article-top
• desktop-sidebar-top
• desktop-sidebar-bottom

처럼 역할별로 독립된 광고 자리(플레이스먼트, 코드가 따로 발급되는 광고 슬롯)를 만드는 편이 좋다.

여기에는 장점이 하나 더 있다.

어디가 진짜 돈을 버는지 알 수 있다.

상단은 노출은 많은데 CPM이 약한가?

사이드 아래는 노출은 적은데 단가가 높은가?

PC에서만 강한가?

자리가 따로 있으면 비교할 수 있다.

같은 코드를 복붙해 전부 한 숫자에 섞어 버리면, 개선하려 해도 무엇을 개선하는지 알 수 없다.

광고 배치는 "떴으니 됐다"가 아니라, 측정할 수 있어야 비로소 운영이 된다.

7. 그리고 자동화하려 하면, API가 갑자기 "보기만 하세요"라고 한다

여기가 묘하게 웃기다.

사이트 쪽 구현은 상당 부분 자동화할 수 있다.

AI 코딩 에이전트에게

• 공통 글 레이아웃을 조사하고
• 광고 컴포넌트를 추가하고
• PC에서만 사이드 광고를 띄우고
• 스마트폰에서는 숨기고
• 화면 밀림 방지용 공간을 확보하고
• 빌드하고
• 배포하고
• 실제 서비스 HTML을 확인하는

것까지 맡길 수 있다.

그럼 애드스테라 쪽도 API로 광고 자리를 만들면 완전 자동화 아닐까?

여기서 Publisher API를 본다.

애드스테라 Publisher API로는 등록한 사이트, 광고 자리 목록, 노출 수, 클릭 수, CTR(클릭률), CPM, 수익 등을 가져올 수 있다. ^[7]

편리하다.

하지만 2026년 9월 25일 시점에서 퍼블리셔 쪽에서 쓸 수 있는 HTTP 메서드는 GET뿐이다. ^[7]

즉

볼 수는 있다.
만들 수는 없다.

Publisher API는 감시 카메라로는 훌륭하지만 문손잡이는 아니다.

새 광고 유닛을 만들려면 Publisher 대시보드에서 사이트를 고르고, ADD UNIT에서 크기를 선택해, 발급된 코드를 가져오는 GUI 작업이 남는다. ^[8]

자동화가 99% 끝났는데 마지막 1%에서 인간이 소환된다.

"그럼 마지막으로, 이 버튼을 눌러 주세요."

문명이 여기까지 왔다.

마지막에 남은 일이 광고 자리 만들기 버튼이다.

브라우저를 조작할 수 있는 AI 에이전트라면 그 GUI도 조작 대상으로 삼을 수 있다. 다만 Publisher API만으로는 새 광고 자리 생성을 대신할 수 없다는 경계는 알아 둬야 한다.

8. 배너가 반응형이라고 생각하고 대충 놓으면, 스마트폰에서 사고 난다

또 하나 중요한 게 기기별 표시다.

애드스테라 공식 배너 가이드는 애드스테라 배너가 반응형이 아니라서 기기에 따라 크기가 자동으로 바뀌지 않는다고 설명한다. 그래서 CSS로 PC용과 모바일용 표시를 전환하는 방법을 안내한다. ^[6]

그러니 PC에서 160×600이 보기 좋게 들어갔다고 그대로 스마트폰에 가져가면

광고가 본문보다 태도가 크다

는 일이 벌어진다.

설계는 기기별로 나눈다.

스마트폰

• 글 상단에 작은 광고
• 필요하면 글 끝에도
• 사이드 광고는 띄우지 않음
• 광고가 본문 폭을 빼앗지 못하게 함

PC

• 글 상단 광고
• 목차 위 사이드 광고
• 목차 아래 사이드 광고
• 기존의 글 끝 광고
• 폭이 충분할 때만 추가 사이드 영역을 검토

다만 PC라고 무한정 놓아도 되는 건 아니다.

2026년에 추가된 Better Ads Standards(더 나은 광고 기준)에서는 PC 본문 영역에서 광고 밀도가 50%를 넘는 경험을 기준 미달로 보고, 사이드 레일 광고도 밀도 계산에 포함된다. ^[1]

여백은 팔아도 된다.

하지만 벽이란 벽에 전부 포스터를 붙여서 본문이 동네 게시판처럼 되는 데까지 가면 안 된다.

9. 결론: 먼저 팔아야 할 것은 '독자의 주의'보다 '남아도는 공간'

광고 수익을 늘리고 싶을 때 가장 무성의한 해법은 본문 안에 광고를 더 넣는 것이다.

하지만 PC의 글 페이지에는 그보다 먼저 쓸 수 있는 게 있다.

여백.

본문은 읽기 편한 폭 그대로 둔다.

제목은 가장 먼저 읽게 한다.

이른 위치에 광고를 하나 둔다.

PC에서는 목차의 위아래에 따로따로 광고 자리를 둔다.

큰 고정 광고로 독자를 쫓아다니지 않는다.

광고 자리의 공간은 미리 확보해 화면 밀림을 막는다.

같은 배너 코드를 복사하지 말고, 자리마다 나눠서 측정한다.

그리고 새 광고 자리 만들기만큼은 Publisher API가 GET 전용이라 대시보드 GUI를 거친다.

설계로서는 아주 단순하다.

본문을 광고로 채우는 게 아니라, 본문 바깥의 놀고 있는 부동산을 빌려준다.

독자는 읽을 수 있다.

광고는 보인다.

사이트는 숫자를 비교할 수 있다.

광고주도 같은 소재가 동시에 두 장 나란히 뜨는 일을 피할 수 있다.

모두가 조금씩 나아진다.

그리고 마지막에 하나 남는다.

AI가 코드를 쓰고, CSS를 고치고, 빌드하고, 배포하고, 실서비스를 확인한 뒤에, 광고 회사 관리 화면에서 '광고 유닛 추가'를 누른다.

웹 자동화의 최종 보스가 대체로 버튼 하나라는 게 좀 웃기다.

1. Coalition for Better Ads, “CBA Updates Desktop Web and Mobile Web Standards,” announced January 14, 2026; updated desktop standard includes ad density above 50%, with siderail ads included in density calculation. and https://www.betterads.org/desktop-ad-density-over-50-percent betterads.org
2. Coalition for Better Ads, “The Research” and “Large Sticky Ads [Desktop].” and https://www.betterads.org/desktop-large-sticky-ad/ betterads.org
3. Adsterra, “Standard Banner Ad Sizes 2026: Complete Guide with Dimensions,” July 9, 2026 adsterra.com
4. Adsterra, publisher product information for Native Banners, describing customizable block size, colors and font sizes adsterra.com
5. web.dev, “Optimize Cumulative Layout Shift,” last updated February 7, 2025. Ads and dynamically injected content are common CLS sources; reserve space with min-height/aspect-ratio web.dev
6. Adsterra, “Banner Ads Still Drive High CPM and Revenues for Publishers.” Current publisher guidance warns against reusing the same Banner code twice on one page and notes that Adsterra Banners are not automatically responsive across devices adsterra.com
7. Adsterra, “Ad network API” and “Adsterra Publisher API: Easily Pull Data to Power Your Monetization Strategy,” current as checked September 25, 2026. Publisher API exposes websites, placements and performance reports and supports GET only. and https://adsterra.com/blog/how-to-use-adsterra-publishers-api/ adsterra.com
8. Adsterra, “Buy Banner Ads | Adsterra Banner Advertising,” publisher flow: choose a site, ADD UNIT, select Banner size and copy the generated code adsterra.com