글을 자동으로 쓰는 건 어렵지 않습니다. 어려운 건 쓸 만한 자리를 고르는 판정입니다. 축마다 그 판정이 다릅니다. 세 축이 각각 어떤 관문을 통과해 글이 되는지, 실제로 잰 숫자와 함께 펼칩니다.
블로그 전체의 유입을 끌어오는 자리입니다. 수익은 여기서 안 납니다. 대신 여기서 지수가 쌓여야 뒤의 두 축이 순위를 받습니다. 그래서 속도가 지표고, 소재 단위는 사건 하나입니다.
뒤의 게이트가 7~8할을 떨어뜨립니다. 처음부터 적게 모으면 그날 쓸 게 없습니다.
통과분이 발행량보다 훨씬 많아야 합니다. 딱 맞게 통과하면 하루라도 수집이 흔들리는 날 축이 통째로 비어요.
사람들은 기사 제목을 검색하지 않습니다. 그 안의 인물명 + 사건어를 칩니다.
따옴표 안을 먼저 보면 안 됩니다. "같은 사람 맞아?" 송혜교에서 앵커로 '같은'이 잡히고, '건강 악화' 아이유에서는 '건강악화'가 잡힙니다. 둘 다 검색되지 않는 말이에요. 따옴표 구간을 통째로 지우고 바깥에서 인물명을 먼저 찾은 뒤, 못 찾을 때만 안을 봅니다.
그리고 기관·단체 이름으로 끝나는 앵커는 후보를 아예 안 만듭니다. 협회·재단·공단 같은 꼬리가 붙은 이름은 "그게 뭐냐"에 답하는 자리인데, 우리 글은 그 답이 아닙니다.
지표 셋을 같이 봅니다. 하나라도 빠지면 반드시 사고가 납니다.
비율은 검색량 ÷ 문서수입니다. 이게 승산 지표예요. 검색량이 커도 문서가 더 많으면 집니다.
| 키워드 | 월검색 | 문서수 | 비율 | 판정 |
|---|---|---|---|---|
| 이슈 롱테일 A | 30,240 | 1,381 | 21.90 | 채택 |
| 이슈 롱테일 B | 1,010 | 486 | 2.08 | 채택 |
| 대형 제품군 + 추천 | 16,270 | 646,809 | 0.03 | 탈락 |
| 화제성 1위 소재 | 54,810 | 225,784 | 0.24 | 탈락 |
게이트를 켠 다음 날, 12개 후보 중 11개를 떨어뜨리고 살아남은 하나로 글을 썼습니다. 검색 620 / 문서 4,780 / 비율 0.13. 다 통과였어요. 그런데 모바일 비중이 27%였습니다. 모바일이 PC보다 적은 검색어는 업무 중에 기관 홈페이지·채용을 찾는 사람이고, 우리 독자가 아닙니다. 그래서 네 번째 지표가 생겼습니다. 인물·작품 검색어는 모바일이 78~90%라 안 걸립니다.
검색량은 검색광고 API(HMAC-SHA256 서명, 서명 문자열은 타임스탬프.메서드.경로이고 쿼리스트링은 넣지 않습니다), 문서수는 오픈API 블로그 검색의 total. 두 API를 후보마다 호출하면 비싸므로 결과를 24시간 캐시합니다. 광고 API가 주는 경쟁도 지표(compIdx)는 광고 경쟁도라 SEO 판정에 쓰면 안 됩니다. 인물명은 광고주가 없어 전부 '낮음'으로 나옵니다.
이걸 안 하면 게이트가 통째로 헛일이 됩니다.
승산 키워드를 고른 뒤 생성 단계에 그냥 소재만 넘기면, 모델이 더 그럴듯한 제목을 만들면서 그 키워드를 빼버립니다. 고생해서 고른 자리를 놓치는 거예요. 제목 앞 15자 안에 그대로 들어가게 지시하고, 검수에서 다시 확인합니다.
제목 형태 궁금증으로 닫는다 (말줄임표 비중 72%) 앞머리 사건 먼저, 이름은 뒤 길이 30~50자 따옴표 금지
이슈축 제목이 말줄임표로 끝나는 건 이 축이 검색이 아니라 홈피드에서도 먹기 때문입니다. 홈피드는 지수 없이 노출되는 유일한 경로라 신생 블로그에 제일 큰 자리예요. 거기선 클릭을 부르는 제목이 이깁니다.
억지로 채우지 않습니다.
파이프라인이 매일 정해진 개수를 채우게 만들면, 못 이길 소재로도 글을 씁니다. 그 글은 순위를 못 받고, 대신 블로그의 발행 이력만 채웁니다. 빈 축이 의미 없는 글보다 낫습니다.
돈이 실제로 나오는 자리입니다. 그래서 판정 기준이 이슈축과 다릅니다. 조회 1건의 값이 다르거든요. 소재 단위는 사건이 아니라 상품 하나입니다.
이 축이 처음에 죽은 이유가 이것 하나였습니다.
제휴 상품을 커미션이 높은 순으로 골랐습니다. 합리적으로 보이죠. 그런데 커미션이 높은 상품은 대개 대형 가전이고, 그 대표 키워드는 구조적으로 못 이기는 급이었습니다.
| 커미션순으로 고른 상품의 키워드 | 월검색 | 문서수 | 비율 |
|---|---|---|---|
| 에어프라이어 추천 | 16,270 | 646,809 | 0.025 |
| 식기세척기 추천 | 1,620 | 456,908 | 0.004 |
| 언더싱크정수기 가격 | 20 | 7,236 | 0.003 |
큰 키워드는 문서가 수십만 건이고, 피해서 내려간 롱테일은 검색량이 20(API 최소 표시값)입니다. 양쪽 다 못 씁니다. 경쟁만 피하면 아무도 안 찾는 자리에 도착합니다. 수요와 경쟁은 반드시 같이 봐야 합니다.
상품 풀 전체를 훑어보니 자리가 실제로 있었습니다. 패턴은 둘입니다.
| 키워드 | 월검색 | 문서수 | 비율 | 패턴 |
|---|---|---|---|---|
| 리베나제습기 | 1,380 | 101 | 13.66 | 저인지 브랜드 |
| 냉장고900리터 | 21,020 | 8,651 | 2.43 | 제품군 + 규격 |
| 이파람에어컨 | 7,390 | 3,282 | 2.25 | 저인지 브랜드 |
| 냉장고500리터 | 15,640 | 9,531 | 1.64 | 제품군 + 규격 |
추천·가격·순위·비교 접미어는 후보 생성 단계에서 아예 제외합니다. 이 넷이 붙는 순간 문서가 수십만 건이 돼서 무조건 집니다. 대신 상품명에서 용량·인치·리터 같은 규격 토큰을 뽑아 조합 키워드를 만듭니다.
같은 게이트를 쓰면 안 됩니다. 목적이 다르니까요.
검색량 하한은 낮추고(구매 의도라 1건의 값이 큽니다) 문서수 상한은 올리고 비율은 높였습니다. 실제로 검색 1,600짜리가 비율 1.2로 최상위에 옵니다.
승산 → 시즌 → 커미션. 이 순서입니다.
시즌(이 달에 뭐가 팔리나)과 커미션(얼마 남나)은 순위가 난 다음에 의미가 생기는 값입니다. 순위가 없으면 팔리지도 남지도 않아요. 그래서 승산을 맨 앞에 둡니다.
손해도 아니었습니다. 승산 기준으로 고른 상품이 커미션 10만원대였어요. 두 기준이 꼭 충돌하지는 않습니다.
커미션 1위만 보고 200만원대 대형 가전만 다뤘더니 클릭 115에 주문 0이었습니다. 블로그 독자가 그 자리에서 200만원을 결제하지 않습니다. 이 발견이 세 번째 축을 만든 이유입니다.
억지로 붙이면 광고글이 되고, 축이 죽습니다.
글에서 실제로 나온 낱말과 상품명을 맞춥니다. 겹치는 게 없으면 그냥 링크 없이 발행합니다. 매칭도 조심해야 해요 — 낱말 뒤에 '색'이 붙으면 제외합니다. '크림색 점퍼'가 화장품 크림으로 잡힌 적이 있습니다.
대가성 고지는 글 맨 앞에 둡니다. 법적 요건이고, 뒤에 숨기면 그게 더 큰 문제가 됩니다.
리뷰축이 가격대 벽에 막혀서 만든 축입니다. 10~30만원대라 결제까지의 거리가 짧습니다. 그리고 이 축은 세 축 중 판정이 가장 까다롭습니다 — 비율만 봐서는 반드시 틀립니다.
헤드 키워드 23개를 재서 전량 버렸습니다.
| 키워드 | 월검색 | 문서수 | 비율 |
|---|---|---|---|
| 가평풀빌라 | 71,800 | 158,550 | 0.453 |
| 국내여행지추천 | 54,810 | 225,784 | 0.243 |
| 애견동반펜션 | 48,160 | 272,843 | 0.177 |
| 서울호캉스 | 27,410 | 439,603 | 0.062 |
| 수영장있는호텔 | 3,030 | 2,326,673 | 0.001 |
| 호텔가성비 | 30 | 2,712,845 | 0.000 |
문서수가 전부 10만 단위입니다. 여행은 국내 블로그에서 가장 오래 갈린 밭이에요. 그리고 반대편도 같이 봐야 합니다 — 경쟁을 피해 내려간 결혼기념일호텔(월 30) 레이트체크아웃호텔(월 40)은 아무도 안 찾는 자리입니다. 양쪽 다 버립니다.
소재 단위를 '지역·테마'가 아니라 숙소 한 곳으로 바꿉니다.
| 키워드 | 월검색 | 모바일 | 문서수 | 비율 |
|---|---|---|---|---|
| 여수베네치아호텔 | 34,250 | 0.85 | 13,296 | 2.58 |
| 소노캄고양 | 35,960 | 0.78 | 15,216 | 2.36 |
| 스카이베이경포호텔 | 42,190 | 0.89 | 35,818 | 1.18 |
| 썬크루즈호텔 | 14,240 | 0.89 | 30,434 | 0.47 |
왜 고유명이 이기나. 헤드 키워드는 10년치 재고와 싸우는데, 고유명은 그 숙소가 리뉴얼하거나 시즌 프로모션을 할 때마다 문서가 갱신되고 옛 글이 죽습니다. 그리고 검색 의도가 달라요. 가평글램핑은 탐색 단계고 소노캄고양은 결제 직전입니다. 제휴 축에서 이 차이가 수수료를 가릅니다.
지역 이름 하나를 시드로 넣으면 연관 키워드가 1,000개 넘게 나옵니다. 상위 20개는 전부 헤드라 쓸모없지만, 그 아래에 고유명이 섞여 있어요. 시드 → 연관 대량 수확 → 고유명 필터 → 문서수 비율 판정. 이 네 단계로 소재 큐가 자동 생성됩니다. 사람이 숙소를 고르지 않습니다.
공백이 들어간 키워드는 검색량 API가 오류를 냅니다. 그런데 반환값은 0으로 보여서 검색량이 없는 것처럼 읽힙니다. 0이 아니라 측정 실패예요. 조합 키워드는 공백을 붙여서 넣어야 합니다.
이 단계가 이 축에서 제일 값나가는 부분입니다.
승산 1위였던 소노캄고양(비율 2.36)의 상위 10건을 실제로 열어봤습니다.
| 상위 10건의 결 | 건수 |
|---|---|
| 뷔페·디저트·중식당 | 4 |
| 돌잔치·상견례·프로포즈 등 행사 | 3 |
| 근처 맛집 | 1 |
| 숙박(객실·조식) | 2 |
10건 중 숙박은 2건입니다. 이 검색어는 호텔 뷔페와 행사장을 찾는 자리였어요. 숙박 예약 의도가 아니니 제휴 링크를 붙일 자리가 아닙니다. 지표는 다 통과했는데 사람이 달랐던 겁니다.
반면 여수베네치아호텔은 10건 중 9건이 객실·수영장·조식·주차 글이었습니다. 이쪽이 맞습니다.
비율을 통과한 뒤 한 층을 더 둡니다. 상위 10건 제목에 숙박 어휘(객실·룸·조식·수영장·주차·체크인·숙소·호캉스)가 6건 이상일 때만 소재로 채택합니다. 숫자만 보는 게이트 위에 사람이 정한 의도를 얹는 층이에요. 이 형태는 다른 축에도 그대로 이식됩니다.
우리는 안 가봤고, 가본 척은 하지 않습니다. 그럼 뭘로 이기나.
후기 글에는 구조적인 빈틈이 있습니다. 후기는 자기가 묵은 방 하나만 씁니다. 슈페리어에 묵은 사람은 디럭스 뷰를 모르고, 여름에 간 사람은 겨울 수영장 온도를 모릅니다.
그런데 독자가 예약 직전에 궁금한 건 "이 사람 방은 어땠나"가 아니라 "내가 담을 방은 뭐가 다른가"입니다. 그 자리가 비어 있어요.
그래서 포맷을 후기가 아니라 예약 전 확인표로 잡습니다. 등급별 뷰 차이, 조식 1인 가격, 수영장 운영시간과 온도, 취소 규정처럼 후기에 잘 안 나오는 조건을 한 화면에 모읍니다. 이건 안 가보고도 정확히 쓸 수 있고, 오히려 후기보다 정확합니다 — 후기는 그날 그 방 기준이라 시즌이 지나면 틀리거든요.
같은 규칙을 쓰면 손해입니다.
| 항목 | 이슈축 | 숙소축 |
|---|---|---|
| 형태 | 궁금증으로 닫기 | 검색어 나열형 |
| 앞머리 | 사건 먼저, 이름 뒤 | 고유명 먼저 |
| 길이 | 30~50자 | 24~39자 |
| 구성 | 훅 + 반전 | 고유명 + 조건어 3~5개 |
이슈축은 홈피드에서 클릭을 받아야 해서 말줄임표로 궁금증을 남깁니다. 숙소축은 검색이고, 검색자는 자기 질문어가 제목에 그대로 있는 글을 누릅니다. 궁금하게 만들면 안 됩니다. 그래서 제목 규칙 문서를 축별로 갈랐습니다.
수수료율보다 먼저 확인할 게 있습니다.
숙박 제휴사는 각자 최소 출금액이 있습니다. 단독 제휴로 붙으면 한 곳당 200달러, 150달러씩 쌓아야 하는데, 시작 단계 트래픽으로는 어느 벽도 못 넘고 한 푼도 못 받습니다.
그래서 여러 제휴사를 한 계정에서 묶어주는 중개 플랫폼을 씁니다. 합산으로 5만원이면 출금이 되니까요. 수수료가 조금 낮아도 받을 수 있는 돈이 받지 못하는 돈보다 큽니다.
제휴 링크 실적이 게시한 채널에 귀속되는지 링크를 발급한 계정에 귀속되는지 확인하세요. 계정에 귀속되면 다른 계정 블로그에 붙여도 실적이 잡히고, 채널에 귀속되면 채널 등록 절차가 따로 필요합니다. 이걸 모르고 붙이면 몇 주치 실적이 사라집니다.
축이 하나 늘면 발행량이 늘고, 발행량이 늘면 저품질 선을 넘습니다.
새 축을 주 2건으로 묶고 기존 축의 자리를 뺏지 않게 했습니다. 하루 총량을 그대로 두고 축별로 나눈다는 뜻입니다. 총량만 두면 먼저 도는 축이 그날 몫을 다 먹습니다.
새 축이 같은 블로그·같은 장부를 쓰면, 대시보드에서 두 축을 가르는 건 카테고리 칸 하나뿐입니다. 발행 스크립트가 그 칸을 다르게 적으면 글이 조용히 다른 축으로 새고, 새 축은 계속 '첫 글 발행 전'으로 남습니다. 틀려도 에러가 안 납니다. 축을 늘릴 때 제일 먼저 확인할 자리예요.
축마다 기준은 다르지만 구조는 같습니다. 이 여덟 개가 실제로 쓰인 것들입니다.
검색량 ÷ 문서수. 수요와 경쟁을 한 숫자로 묶습니다. 둘 중 하나만 보면 반드시 틀립니다 — 경쟁만 피하면 아무도 안 찾는 자리에 도착하고, 수요만 보면 10년치 재고와 싸우게 됩니다.
숫자 게이트 위에 얹는 층입니다. 모바일 비중으로 한 번, 상위 10건의 결을 세어서 또 한 번. 지표는 통과했는데 사람이 다른 경우를 잡습니다. 두 번의 오판이 이 층을 만들었습니다.
모든 임계값을 파일 하나에 둡니다. 코드 상수로 두면 학습이 못 바꾸고, 무엇보다 되돌릴 수가 없습니다. 바꿀 때는 이전 값과 판정일을 같이 기록하고, 그날 효과가 없으면 자동으로 되돌립니다.
글의 모양(줄 길이·블록 수·사진 수·정렬)을 파일 하나로 두고 프롬프트·조립·검수가 모두 그걸 읽습니다. 세 곳에 흩어져 있으면 한 곳만 고치는 날이 오고, 검수는 통과하는데 옛 규격으로 쓰는 상태가 됩니다.
조립 결과를 캡처하고 수치로 재되 발행은 하지 않습니다. 규격을 바꿀 때마다 실제 글을 내보면 블로그가 실험장이 됩니다. 이걸 만든 뒤로 개조 검증을 한 건도 발행 없이 합니다.
"실패 문구가 없으니 성공"은 아무것도 안 해도 참이 됩니다. 발행은 로그인하지 않은 상태에서 그 글이 보이는지로만 판정합니다. 내 세션으로는 임시저장도 보이거든요.
주기적으로 전 축을 판정하고 죽은 것을 직접 되살립니다. 항목마다 "성공했으면 이 파일이 오늘 것이어야 한다"는 증거를 하나씩 정해둡니다. 증거가 없으면 되살려도 계속 실패로 잡혀 무한히 복구합니다.
하루 발행 상한을 코드 관문으로 박고 축별로 쪼갭니다. 사람의 재량에 남기면 반드시 어느 날 터집니다. 세는 기준은 우리 장부가 아니라 채널 실물이어야 하고요 — 남의 장부로 판정하면 "아직 안 찼다"가 영원히 참이 됩니다.