티스토리 애드센스 승인기 4편
마지막 거절 후 29일 동안 바꾼 글쓰기 방식
2026년 5월 9일 마지막 거절 이후, 나는 글 개수를 세는 방식에서 벗어나 검색 의도, 구조, 캡처, 출처, FAQ를 먼저 보는 방식으로 글을 다시 쓰기 시작했다.
1편은 거절 메일의 흐름,
2편은 블로그 정체성 문제,
3편은 About,
Privacy,
Contact,
sitemap 같은 사이트 구조를 다뤘다.
4편에서는 마지막 거절 이후 글을 어떻게 다시 썼는지를 정리한다.
2026년 5월 9일, 마지막 거절 뒤에 달라진 것
2026년 5월 9일에 또 거절 메일이 왔다.
그때부터 2026년 6월 7일 승인 메일을 받기 전까지는 달력상 29일이었다.
긴 시간처럼 보이지만,
실제로는 블로그를 완전히 갈아엎기에는 짧고,
글쓰기 습관을 바꾸기에는 충분한 시간이었다.
그 전까지는 글을 올렸다는 사실에 더 가까웠다.
오늘 본 도구,
오늘 생긴 오류,
오늘 궁금했던 기능을 기록했다.
기록 자체는 나쁘지 않았다.
문제는 그 글이 처음 들어온 사람에게 바로 읽힐 만큼 정리되어 있었는가였다.
애드센스가 보는 블로그는 내 메모장이 아니라,
낯선 방문자에게 광고가 붙어도 되는 공개 사이트였다.
마지막 거절 뒤에는 글 개수를 늘리는 생각을 잠깐 멈췄다.
대신 이미 있는 글과 새로 쓸 글을 보면서 질문을 바꿨다.
이 글은 누가 검색할까.
검색한 사람은 무엇을 해결하고 싶을까.
제목만 보고 들어온 사람이 첫 10초 안에 방향을 알 수 있을까.
읽다가 막히면 표,
이미지,
코드블록,
FAQ 중 무엇이 도와줄 수 있을까.
이 질문을 넣으니 글의 모양이 바뀌었다.
제목은 더 구체적이 되었고,
첫 문단은 길게 돌아가지 않게 되었다.
목차가 생겼고,
중간에는 비교표나 체크리스트가 들어갔다.
공식 문서나 저장소를 확인한 글은 출처를 남겼고,
실제 화면을 보여줘야 하는 글에는 캡처를 넣었다.
마지막에는 자주 물을 만한 질문을 FAQ로 따로 묶었다.
이것을 승인 공식이라고 말하고 싶지는 않다.
애드센스 승인에는 공개되지 않은 판단 요소가 있고,
같은 방식으로 써도 모든 블로그가 같은 결과를 얻는 것은 아니다.
다만 내 경우에는 마지막 거절 이후 글의 방향이 분명히 달라졌다.
글이 많아졌다는 것보다,
글 하나가 끝까지 읽힐 만한 단위가 되도록 고치기 시작했다는 점이 더 컸다.
- 글 개수만 늘리면 언젠가 통과하겠지.
- 짧아도 내 경험이니까 괜찮겠지.
- 공식 문서 링크는 귀찮으니 생략해도 되겠지.
- 방문자는 알아서 필요한 부분만 찾아 읽겠지.
- FAQ나 목차는 있어도 그만, 없어도 그만이겠지.
승인 전후로 가장 크게 바뀐 부분은 주제 선정이었다.
기술 블로그라면 오늘 본 도구를 그냥 소개하는 것보다,
그 도구를 검색한 사람이 바로 궁금해할 질문을 제목에 담는 편이 읽히기 쉽다.
글감은 좁히고, 제목은 더 구체적으로 썼다
5월 말부터 올린 글을 다시 보면 흐름이 보인다.
Superpowers,
DESIGN.md,
whichllm,
Gemma SFT,
Codex goal,
Gemini CLI,
MCP 같은 글은 모두 막연한 생각 정리가 아니라 특정한 문제를 겨냥했다.
무엇인지,
왜 쓰는지,
어떻게 확인하는지,
어떤 기준으로 판단해야 하는지에 초점을 맞췄다.
예전에는 관심사가 넓은 것이 블로그의 장점이라고 생각했다.
하지만 승인 준비를 하면서는 넓은 관심사보다 명확한 묶음이 더 필요하다고 느꼈다.
AI 도구와 개발 생산성이라는 큰 축 안에서,
각 글이 하나의 검색 질문을 맡도록 정리했다.
그렇게 해야 카테고리도 덜 흩어져 보이고,
방문자도 다음 글로 이동할 이유를 찾기 쉬웠다.
예를 들어 MCP 글은 단순히 MCP가 유행한다는 이야기가 아니었다.
제목부터 AI 스킬과 도구 연결 표준의 차이를 묻는다.
Gemini CLI 글은 종료 소식 자체보다 Antigravity CLI로 무엇을 바꿔야 하는지에 맞췄다.
Hermes,
OpenClaw,
NanoClaw 비교 글은 세 도구를 한 번에 놓고 선택 기준을 보여주는 글이었다.
이 방식은 글을 쓰는 사람에게도 도움이 되었다.
주제가 좁아지면 글의 끝이 보인다.
공식 문서 확인,
설치나 테스트 여부,
비교 기준,
위험 요소,
결론이 자연스럽게 생긴다.
반대로 주제가 너무 넓으면 글이 길어져도 독자는 어디에서 답을 얻어야 하는지 모른다.
마지막 거절 뒤에는 그 차이를 계속 의식했다.
| 바꾸기 전 생각 | 바꾼 뒤 기준 |
|---|---|
| 오늘 알게 된 내용을 기록한다. | 검색자가 실제로 입력할 질문을 먼저 정한다. |
| 제목은 넓고 편하게 쓴다. | 도구명, 비교 대상, 문제 상황을 제목에 넣는다. |
| 본문은 생각나는 순서대로 쓴다. | 요약, 목차, 설명, 검증, FAQ 순서로 읽는 길을 만든다. |
| 이미지는 있으면 넣는다. | 글의 주장을 확인할 수 있는 캡처만 넣는다. |
| 출처는 마지막에 대충 모은다. | 공식 문서, 저장소, 실제 테스트 화면을 함께 남긴다. |
사람들은 긴 글을 처음부터 끝까지 순서대로 읽지 않는다.
먼저 제목을 보고,
그다음 목차를 보고,
중간 표와 FAQ를 훑는다.
그래서 긴 글일수록 읽는 길을 먼저 만들어야 했다.
목차, 표, FAQ를 기본값으로 넣었다
마지막 거절 전에는 글이 있어도 구조가 일정하지 않았다.
어떤 글은 짧은 메모에 가까웠고,
어떤 글은 긴 설명이지만 중간에 쉬어 갈 지점이 부족했다.
승인 준비를 하면서는 글을 하나의 작은 문서처럼 만들려고 했다.
첫 화면에서 핵심을 말하고,
목차로 흐름을 보여주고,
중간에는 표나 체크리스트로 판단 기준을 만들었다.
MCP 글은 이 변화가 잘 보이는 예시다.
제목은 MCP를 정확히 이해하자는 질문으로 시작하고,
본문에서는 AI 스킬과 도구 연결 표준의 차이를 나눈다.
목차가 있으면 독자는 바로 원하는 지점으로 이동할 수 있다.
MCP가 무엇인지 이미 아는 사람은 구조나 보안 쪽으로 내려가면 되고,
처음 보는 사람은 정의부터 읽으면 된다.
FAQ도 같은 이유로 넣었다.
FAQ는 글 끝에 붙이는 분량 채우기가 아니었다.
글을 읽다가 남을 만한 질문을 미리 받는 장치였다.
MCP는 AI 스킬과 같은 것인가,
MCP를 쓰면 RAG가 필요 없는가,
MCP 서버는 반드시 원격 서버여야 하는가 같은 질문은 실제로 독자가 헷갈릴 수 있는 부분이다.
이런 질문을 끝에서 다시 잡아주면 글 전체가 덜 흩어진다.
이 구조는 애드센스만을 위한 것이 아니었다.
검색으로 들어온 사람에게도 도움이 된다.
글이 길더라도 목차와 FAQ가 있으면 필요한 답을 찾기 쉽다.
광고가 붙은 블로그라면 더 중요하다.
방문자가 광고 사이에서 길을 잃으면 글의 신뢰도 같이 떨어진다.
그래서 광고보다 먼저 읽는 길을 만들자는 쪽으로 생각을 바꿨다.
- 첫 화면에서 이 글이 해결할 질문을 말하는가.
- 목차만 봐도 본문 흐름이 보이는가.
- 비교가 필요한 부분은 표로 정리했는가.
- 실행 과정이 필요한 부분은 코드블록이나 단계로 나눴는가.
- 글 끝에 남을 질문을 FAQ로 회수했는가.
내가 실제로 본 화면,
확인한 공식 문서,
테스트한 명령을 남기면 글은 단순 의견에서 기록으로 바뀐다.
4편의 핵심은 바로 이 기록성이다.
공식 문서, 캡처, 코드블록을 함께 넣었다
Gemini CLI 글을 쓸 때는 종료 소식만 요약하지 않았다.
누가 영향을 받는지,
무엇을 옮겨야 하는지,
설정 파일이나 MCP 설정을 어디서 확인해야 하는지까지 체크리스트로 만들었다.
기술 글은 정보가 빠르게 바뀐다.
그래서 작성 기준 날짜,
공식 링크,
확인한 화면을 남기지 않으면 시간이 지나서 독자가 판단하기 어렵다.
코드블록도 비슷했다.
명령어나 파일 이름이 본문 안에 섞여 있으면 읽는 사람은 복사하기 어렵고,
어디까지가 설명이고 어디부터가 실행 명령인지 헷갈린다.
그래서 명령은 별도 블록으로 빼고,
파일명은 인라인 코드로 표시했다.
이 작은 차이가 기술 블로그에서는 꽤 크다.
비교 글에서는 표가 중요했다.
Hermes,
OpenClaw,
NanoClaw 비교처럼 선택지가 여러 개인 글은 문장만 길게 쓰면 독자가 다시 정리해야 한다.
표는 독자의 정리 비용을 줄인다.
각 도구의 출발점,
장점,
조심할 점을 나누면 글이 더 길어져도 오히려 읽기 쉬워진다.
이렇게 쓰다 보니 글 하나를 만드는 시간은 늘었다.
캡처를 준비하고,
링크를 확인하고,
표를 만들고,
FAQ를 쓰는 과정이 추가되었기 때문이다.
하지만 그 시간은 단순히 분량을 늘리는 시간이 아니었다.
방문자가 글을 읽고 판단할 수 있게 만드는 시간이었다.
- 공식 문서 링크: 제품 동작이나 정책을 확인할 수 있는 1차 자료
- 공개 저장소 링크: 설치 방법, 릴리스, README를 확인할 수 있는 자료
- 직접 캡처: 글에서 설명하는 화면이 실제로 어떻게 보이는지 보여주는 자료
- 코드블록: 독자가 그대로 확인하거나 따라 할 수 있는 실행 단위
- FAQ: 본문을 다 읽은 뒤에도 남을 수 있는 질문의 회수 장치
5,000자 안팎의 글을 쓰려고 했지만,
숫자 자체가 목적은 아니었다.
충분한 설명,
캡처,
구조,
출처를 넣다 보니 자연스럽게 길어진 글이 필요했다.
글 개수보다 검색 의도에 맞는 글
마지막 거절 뒤에 내가 가장 조심한 것은 글 수 집착이었다.
승인 후기들을 보면 몇 개 이상 써야 한다는 말이 자주 나온다.
물론 빈 블로그는 통과하기 어렵다.
하지만 글 수만 채운 블로그도 막힐 수 있다.
내 경험에서는 글 개수보다 각 글이 검색자의 질문을 끝까지 처리하는지가 더 중요하게 느껴졌다.
그래서 한 글 안에서 결론을 최대한 닫으려고 했다.
도구를 소개했다면 어떤 상황에서 쓰는지까지 말하고,
비교 글이라면 누가 무엇을 선택하면 좋은지까지 썼다.
설치 글이라면 설치 전 준비물,
실행 흐름,
실패할 수 있는 지점,
확인 방법을 넣었다.
읽는 데 걸리는 시간을 표시한 글도 이런 고민에서 나왔다.
독자가 어느 정도 시간을 들여야 하는지 예상할 수 있으면 긴 글도 덜 부담스럽다.
Google 애드센스 고객센터도 승인되지 않은 계정의 원인으로 콘텐츠 불충분,
콘텐츠 품질 문제,
사이트 탐색 문제 등을 설명한다.
또 사이트 페이지가 애드센스 사용에 적합한지 확인하라는 문서에서는 고유한 콘텐츠,
명확한 메뉴,
독창적이고 흥미로운 내용,
사용자 경험을 함께 보라고 안내한다.
결국 내 수정 방향은 이 공식 문서의 표현과도 어느 정도 맞닿아 있었다.
Google Search Central의 사용자 중심 콘텐츠 문서도 같은 방향을 말한다.
검색엔진만 보고 만든 글보다 사람에게 도움이 되는 글이 중요하다는 관점이다.
그래서 마지막 29일 동안의 기준은 단순했다.
이 글이 진짜 독자에게 도움이 되는가.
내가 직접 확인한 내용이 있는가.
제목과 본문이 같은 약속을 하고 있는가.
읽고 나면 독자가 다음 행동을 알 수 있는가.
승인 직전에는 이 기준으로 글을 계속 봤다.
짧은 글은 무조건 나쁘다고 생각하지 않았다.
다만 짧은 글이라도 끝이 있어야 했다.
긴 글도 무조건 좋은 것은 아니었다.
길어졌다면 그만큼 독자가 얻는 것이 있어야 했다.
표,
목차,
FAQ,
출처,
캡처가 들어간 이유도 결국 같은 곳으로 모였다.
글을 길게 만드는 것이 아니라,
글을 덜 막히게 만드는 것.
| 승인 직전 기준 | 내가 실제로 본 점검 질문 |
|---|---|
| 검색 의도 | 이 제목을 검색한 사람은 무엇을 알고 싶었을까? |
| 첫 문단 | 첫 화면에서 결론과 대상 독자가 보이는가? |
| 본문 구조 | 목차, 소제목, 표, 코드블록이 읽는 길을 만들고 있는가? |
| 신뢰 자료 | 공식 문서, 공개 저장소, 직접 캡처가 충분한가? |
| 마무리 | FAQ나 체크리스트로 남는 질문을 정리했는가? |
5편으로 이어지는 이야기
이렇게 글을 고치고,
사이트 구조를 정리하고,
새 글의 기준을 바꾼 뒤 2026년 6월 7일 밤에 승인 메일이 왔다.
5편에서는 그 메일을 받았을 때의 이야기,
승인 후 애드센스 화면,
자동 광고 설정,
첫 수익 인증을 어떻게 이어갈지 정리할 예정이다.
다만 이번 시리즈를 쓰는 이유는 누군가에게 빠른 돈벌이를 약속하기 위해서가 아니다.
애드센스는 1~2시간 글을 쓰고 바로 큰돈을 버는 구조로 설명되곤 하지만,
내 경험은 훨씬 느리고 지루했다.
그래서 이 시리즈는 강의 판매용 과장 대신,
실제로 무엇을 고쳤고 어떤 순서로 바꿨는지 남기는 기록에 가깝다.
FAQ
Q1. 정말 5,000자 이상 써야 애드센스 승인이 되나요?+
그렇게 단정할 수는 없습니다. 다만 내 경우에는 5,000자 안팎으로 충분히 설명하고, 목차와 캡처, 출처, FAQ를 넣은 글이 블로그의 신뢰도를 보여주기에 더 좋았습니다. 숫자보다 중요한 것은 검색 의도를 끝까지 처리하는 완성도였습니다.
Q2. FAQ는 꼭 넣는 편이 좋나요?+
모든 글에 꼭 필요한 것은 아니지만, 긴 설명형 글에는 도움이 됩니다. 독자가 헷갈릴 만한 질문을 글 끝에서 다시 정리하면 글의 마무리가 선명해지고, 본문에서 놓친 내용을 빠르게 회수할 수 있습니다.
Q3. 캡처 이미지는 몇 장 정도가 적당했나요?+
내 기준으로는 글의 주장을 설명하는 데 필요한 만큼만 넣었습니다. 단순 장식 이미지는 줄이고, 글 목록, 실제 화면, 표, 설정 화면처럼 독자가 확인할 수 있는 이미지를 우선했습니다.
Q4. 승인 직전에 글을 많이 올린 것이 결정적이었나요?+
글 수가 전혀 의미 없다고 보지는 않습니다. 하지만 마지막 수정기의 핵심은 양보다 방향이었습니다. AI와 개발 도구라는 축을 더 분명히 잡고, 각 글이 하나의 질문을 해결하도록 구성한 점이 더 중요했다고 봅니다.
Q5. 이 방식대로 하면 누구나 승인되나요?+
아닙니다. 애드센스 승인은 사이트 상태, 콘텐츠 품질, 정책 준수, 탐색 구조 등 여러 요소가 함께 작동합니다. 이 글은 보장 공식이 아니라, 내 블로그가 마지막 거절 뒤에 실제로 바뀐 지점을 기록한 사례입니다.
참고한 링크
'애드센스' 카테고리의 다른 글
| 결국 2026년 6월 7일, 승인 메일이 왔다 - 애드센스 승인기 5편 (0) | 2026.07.07 |
|---|---|
| 애드센스 준비는 글만 쓰는 게 아니었다 - 애드센스 승인기 3편 (0) | 2026.07.06 |
| 내 블로그는 왜 가치 없는 콘텐츠처럼 보였을까 - 티스토리 애드센스 승인기 2편 (2) | 2026.07.06 |
| 애드센스는 생각보다 오래 나를 거절했다 - 티스토리 애드센스 승인기 1편 (2) | 2026.07.06 |
