네이버 검색광고 API로 키워드 검색량을 재고 글감 게이트를 만든 기록

블로그 글을 316편 넘게 썼습니다. 그런데도 주당 클릭은 8회. 순위를 확인하니 주력 키워드 다수가 평균 4~9위였고, 이미 1페이지에 올라와 있는데도 클릭은 그대로였습니다. 순위가 아니라 키워드를 찾는 사람이 없었던 것입니다.

처음에는 제목이나 본문 구조를 다시 손봐야 한다고 봤습니다. 아니었습니다. 색인된 글의 노출을 확인하고 방향을 바꿨고, 글을 다 쓴 다음 순위를 확인하는 대신 쓰기 전에 월간 검색량부터 재기로 했습니다.

먼저 결론부터

• 네이버 데이터랩은 키워드 사이의 상대적인 흐름을 보기에는 맞지만, 월간 검색 횟수를 바로 알 수는 없었습니다.
• 절대 검색량은 네이버 검색광고 API의 keywordstool에서 확인했습니다. PC와 모바일 조회수도 나뉘어 나옵니다.
• 요청마다 HMAC-SHA256 서명이 필요했고, 서명 문자열 형식을 틀리면 키가 있어도 호출이 되지 않았습니다.
• 한 번에 넣을 수 있는 키워드는 5개였습니다. 목록을 길게 붙여 넣는 방식으로는 측정이 끝나지 않았습니다.
• 월 검색량이 500 미만이면 글감에서 제외했고, 2,000~50,000 구간을 목표로 잡았습니다.
• 파이썬이 3.11에서 3.14로 올라간 뒤 예약 작업 일부가 멈췄습니다. API 호출 코드보다 실행 환경이 먼저 깨졌습니다.

서명 문자열:
{타임스탬프}.{HTTP메서드}.{경로}

서명 방식:
비밀키로 HMAC-SHA256 해시
해시 결과를 base64로 인코딩

순위가 있어도 노출이 없었습니다

처음 측정한 이유는 검색 성과가 너무 이상했기 때문입니다. 평균 순위가 4~9위인데도 주당 클릭은 8회였습니다. 순위만 놓고 보면 제목을 조금 바꾸거나 내부 링크를 넣으면 될 것처럼 보였던 겁니다.

색인된 글 156편의 노출은 1,391회였습니다. 글 하나당 8.9회. 1페이지 안에 있어도 검색 자체가 거의 일어나지 않으면 노출은 늘지 않습니다. 그런데 순위 보고서만 보면 경쟁에서 밀린 것처럼 보이지만, 실제로는 처음부터 수요가 없는 키워드를 고른 경우가 섞여 있었습니다.

그래서 데이터랩 그래프는 후보를 찾는 용도로만 남겼습니다. 데이터랩은 상대 지수라서 특정 키워드가 다른 시기에 올랐는지는 보이지만, 글 하나를 쓸 만큼 검색이 있는지 판단할 숫자는 주지 않았습니다. 필요한 건 상대적인 선이 아니라 월간 조회수였습니다.

검색광고 API 호출은 서명에서 막혔습니다

절대 수치를 받은 곳은 네이버 검색광고 API의 api.searchad.naver.com/keywordstool입니다. 검색광고 계정과 실제 광고 집행은 별개입니다. 계정만 만든 뒤 API 키를 받으면 호출은 됩니다.

문제는 단순한 키 전달이 아닙니다. 타임스탬프, HTTP 메서드, 요청 경로를 점으로 이어 붙이고 비밀키로 HMAC-SHA256 서명을 만든 다음, 그 결과를 base64로 바꿔 타임스탬프, API 키, 고객 ID, 서명과 함께 헤더에 넣습니다.

message = f"{timestamp}.{method}.{path}"
digest = hmac.new(
    secret_key.encode(),
    message.encode(),
    hashlib.sha256,
).digest()
signature = base64.b64encode(digest).decode()

경로에 도메인까지 넣는 식으로 문자열을 만들면 틀립니다. 요청 URL과 서명 경로는 같아 보입니다. 하지만 서명에 들어가는 건 경로뿐입니다. 둘을 분리해서 처리하니 호출 흐름이 정리됐습니다.

키워드는 한 번에 5개까지. 후보를 묶어 호출한 뒤 결과를 저장하고 다음 묶음으로 넘겼습니다. 월 10회 미만인 키워드는 정확한 값 대신 < 10으로 돌아왔는데, 이 값은 작은 차이를 비교할 자료가 아니라 검색량이 거의 없다는 표시로만 썼습니다.

316편을 재서 글감 기준을 바꿨습니다

주력 키워드 316편을 표본으로 재고 구간을 나눴습니다.

월 500 미만       쓰지 않음
월 500~2,000      약한 키워드
월 2,000~50,000   목표 구간
월 50,000 초과    작은 사이트가 잡기 어려운 머리 키워드

검색량만 높으면 된다는 뜻은 아닙니다. 월 50,000을 넘는 키워드는 수요가 커도 작은 사이트가 경쟁하기 어려웠고, 반대로 500 미만은 순위가 잡혀도 노출이 거의 없었습니다. 그래서 새 글감은 목표 구간 안에서 고릅니다. 너무 넓은 키워드는 더 구체적인 표현으로 다시 나눕니다.

9월 상반과 하반의 표본을 각각 30개씩 재면서 품질 하락도 확인했는데, 중앙값은 6,175에서 1,430으로 떨어졌고 500 미만 비율은 10%에서 33%로 늘었습니다. 좋은 키워드를 먼저 쓴 뒤 변두리로 밀려나고 있었습니다.

원인으로 보인 건 하루 12편씩 내던 속도. 글감 목록을 빨리 비우는 동안 검색량 확인 없이 제목만 그럴듯한 키워드가 섞였습니다. 이후에는 발행 직전에 검색량을 재고, 500 미만이면 초안이 있어도 목록에서 빼는 게이트를 넣었습니다.

성과를 읽는 시점과 실행 환경도 같이 깨졌습니다

발행 시기별 노출에서는 다른 문제도 보입니다. 새 글은 바로 평가하면 안 됩니다.

8월 하반 27편    노출 359회   글당 13.3
9월 상반 123편   노출 598회   글당 4.9
9월 하반 144편   노출 94회    글당 0.7

구글이 순위를 잡는 데 한두 달이 걸렸습니다. 9월 하반 글의 수치가 낮다고 해서 그 시기에 쓴 키워드가 전부 실패했다고 볼 수는 없었습니다. 게이트가 효과 없다고 적을 뻔했습니다. 날짜를 다시 확인하니 게이트는 비교 구간 이후에 들어가 있었고, 측정값은 있어도 그 값으로는 게이트의 효과를 검증할 수 없었습니다.

파이썬 환경도 같은 시기에 흔들렸습니다. 홈브루가 파이썬을 3.11에서 3.14로 올리면서 pip로 설치했던 패키지가 이전 폴더에 남았고, 예약 작업은 python3를 그대로 불렀고, 빌드는 성공한 다음 단계에서 죽었습니다.

스크립트 40개 가운데 외부 패키지를 쓰는 것은 5개뿐이었습니다. 피해는 작았습니다. 검색광고 API 호출처럼 표준 라이브러리의 hmac, hashlib, base64만으로 처리한 코드는 그대로입니다. 패키지 설치 문제인지 API 서명 문제인지 한꺼번에 추측하지 않고, 먼저 새 python3가 어느 환경을 가리키는지 확인하면서 복구했습니다.

검색량 측정이 글감의 정답을 주지는 않았습니다. 다만 1페이지 순위인데도 노출이 없는 이유와, 많이 쓰는데도 전체 품질이 떨어지는 이유를 숫자로 구분하게 했습니다. 이제는 발행량보다 키워드 목록의 월간 검색량을 먼저 봅니다.