크롤링 키워드 선정 7일 실측 — 슬래시 하나가 멈춘 채점

크롤링 키워드를 13개 늘리자 무엇이 문제였나?

크롤링 키워드 선정에서 가장 비싼 실수는 쓸모없는 키워드를 계속 모으는 일이고, 그다음으로 비싼 실수는 모으고 있다고 믿은 키워드가 실제로는 채점되지 않는 일입니다. 이번 7일 판정에서 둘을 동시에 만났습니다. 앞의 것은 비용 문제였고, 뒤의 것은 조용한 데이터 유실이었습니다.

우리 수집기는 네이버 검색 API로 블로그와 카페 글을 키워드별로 가져옵니다. 크론이 한 번 돌 때마다 API를 47회 호출하고, 키워드가 늘면 호출 수와 실행 시간이 함께 늘어납니다. 2026년 7월 21일에 스마트플레이스·인스타그램 광고·유튜브 광고·구글 광고·앱개발 4종·SA 광고·광고 성과·CPC·애드부스트·A/B 테스트까지 13개를 한 번에 넣었습니다. 광고와 앱 외주 수요가 어디서 말해지는지 보려는 목적이었습니다.

키워드를 넣는 결정은 가볍게 했지만, 빼는 결정은 미리 규칙으로 묶어 두었습니다. '1주일 크론 누적 후 적중률로 판정한다.' 넣을 때 판단은 짐작이지만, 7일 뒤 판단은 숫자이기 때문입니다. 이 글은 그 7일째인 2026년 7월 28일의 판정과, 판정 도중 드러난 경로 버그, 그리고 8일 뒤 다시 잰 결과를 순서대로 적은 기록입니다.

수집 파이프라인 자체가 궁금하다면, 같은 수집기에서 검색 결과 정렬 옵션 하나가 수집 품질을 바꾼 이야기를 네이버 검색 API 정렬 기준 글에 따로 적어 두었습니다.

처음 잰 숫자: 7일 누적 수집량과 적중률

측정은 두 단계였습니다. 먼저 채널별 수집 결과를 합쳐 최근 7일 요약을 만들고, 그다음 키워드별 판정 스크립트로 제거 대상을 골랐습니다. 제거 기준은 두 줄입니다. 7일 누적 수집이 50건 이상일 것, 그리고 그중 적중(8점 이상) 글이 0%일 것. 50건 미만은 표본이 작아 판정하지 않고 다음으로 미룹니다.

50건이라는 선은 '0%'가 우연인지 아닌지 가르기 위한 최소치입니다. 몇 건 모으지 않은 상태에서 적중이 0건이면 그냥 운이 나빴을 수 있지만, 50건을 모아도 0건이면 그 키워드로 들어오는 글의 성격 자체를 의심할 만합니다. 반대로 적중이 한 건이라도 있으면 0%가 아니므로 일단 남깁니다. 기준을 이렇게 느슨하게 잡은 이유는, 잘못 지운 키워드는 다시 넣어도 그 사이의 데이터가 비지만, 잘못 남긴 키워드는 다음 판정에서 걸러지기 때문입니다.

판정은 키워드 단위가 아니라 '채널×키워드' 조합 단위로 했습니다. 같은 '앱개발 비용'이라도 블로그와 카페에서 모이는 글의 성격이 다르기 때문입니다. 결과는 9개 조합이 기준에 걸렸습니다.

블로그에서는 '어플 개발' 277건, '앱개발 비용' 196건, '앱 제작 견적' 99건, 'SA 광고' 64건, '애드부스트' 51건이 모두 적중 0%였습니다. 카페에서는 '앱 제작 견적' 176건, '앱개발 비용' 143건, '인스타그램 광고' 135건, 그리고 한 주 앞선 2026년 7월 20일에 넣었던 '비상주사무실' 64건이 같은 판정을 받았습니다.

눈에 띄는 점은 수집량과 쓸모가 거꾸로 갔다는 사실입니다. 가장 많이 모인 블로그 '어플 개발'이 277건으로 1위였는데 적중은 0건이었습니다. 앱 개발 비용·견적을 다루는 글은 대부분 개발사가 쓴 홍보 글이라, 외주를 맡기려는 사람의 목소리는 거의 섞이지 않았습니다. 이 해석은 적중률 0%에서 거꾸로 짚은 추정이고, 글을 한 건씩 분류해 확인하지는 않았습니다.

세운 가설: 7일이면 13개 전부 판정할 수 있다

키워드를 넣던 날 세운 가설은 단순했습니다. 크론이 매일 돌면 7일 뒤에는 13개 키워드 모두 판정할 만큼 데이터가 쌓이고, 적중률 숫자 하나로 남길지 뺄지 가를 수 있다는 가설이었습니다. 이 가설에는 전제가 셋 숨어 있었습니다.

• 수집이 되면 채점도 된다 — 모은 글은 전부 점수를 받는다
• 7일이면 모든 조합이 50건을 넘는다
• 적중률이 0%가 아니면 남길 만하다

첫째 전제가 당연해 보인 이유는 수집과 채점이 한 크론 안에서 이어서 돌기 때문입니다. 수집 로그에 건수가 찍히면 채점도 따라 돌았으리라 여기기 쉽고, 우리도 7일 동안 수집 건수만 봤습니다. 둘째 전제는 기존 키워드들이 대부분 7일이면 50건을 넘겼던 경험에서 나왔습니다. 셋째 전제는 '0%만 아니면 남긴다'는 판정 기준 자체에 들어 있었습니다.

세 전제 모두 당연해 보였고, 그래서 따로 확인하지 않았습니다. 판정일에 숫자를 펼쳐 보니 셋 다 한 번씩 틀렸습니다.

가설은 어디서 틀렸나?

첫째 전제가 가장 크게 틀렸습니다. 'A/B 테스트' 키워드의 채점 기록을 보니 2026년 7월 21일 2건 이후로 한 건도 없었습니다. 그런데 같은 기간 원본 수집은 7일 동안 804건으로 정상이었습니다. 글은 매일 들어오는데 점수가 매겨진 글은 첫날 2건에서 멈춰 있었습니다. 적중률로 치면 이 키워드는 0%도 아니고 판정 불가였습니다.

둘째 전제도 두 곳에서 어긋났습니다. 카페 'SA 광고'는 25건, 카페 '애드부스트'는 23건으로 50건 기준에 못 미쳐 판정을 보류했습니다. 7일은 키워드 13개에 똑같이 흘렀지만, 채널별로 쌓이는 속도는 달랐습니다.

셋째 전제는 숫자를 비교해 보고서야 흔들렸습니다. 살아남은 조합의 적중률은 블로그 기준 'CPC' 4.0%, '유튜브 광고' 3.8%, '구글 광고' 2.7%가 상위였습니다. 같은 수집기가 Threads 기존 키워드군에서 내는 적중률은 14~48%, 파워링크 광고 키워드는 35~37%입니다. 0%는 아니지만, 가장 나은 조합도 기존 키워드군 하단의 3분의 1에 못 미쳤습니다.

이 조합들을 남긴 이유는 적중률이 아니었습니다. 광고 단가(CPC) 상한을 계산하려고 광고 성과·전환율 관련 글을 따로 모으는 목적이 있었고, 그 목적이 없었다면 전부 제거 대상이었습니다. 가설대로라면 '0%가 아니니 존치'였겠지만, 실제 존치 근거는 적중률 밖에 있었습니다.

진짜 원인은 무엇이었나: 키워드 이름이 곧 폴더 경로였다

채점이 멈춘 원인은 키워드 이름에 든 슬래시(/) 하나였습니다. 수집기는 키워드 이름을 그대로 폴더 이름으로 써서 원본을 `raw/<키워드>/` 아래에 날짜별 파일로 저장합니다. 리눅스 파일 시스템에서 슬래시는 폴더 구분자입니다. 그래서 'A/B 테스트'는 폴더 하나가 아니라 `raw/A/` 안에 `B 테스트/`가 들어 있는 두 단계 폴더가 됐습니다.

저장은 실패하지 않았습니다. 폴더가 한 단계 더 깊어졌을 뿐 파일은 매일 정상으로 쌓였고, 그래서 원본 수집 804건이라는 멀쩡한 숫자가 나왔습니다. 반면 채점 단계는 7월 22일부터 이 키워드를 한 건도 처리하지 않았습니다. 에러 메시지도, 경고도 없었습니다. 채점 쪽이 왜 조용히 넘어갔는지는 기록에 남아 있지 않아, 여기서는 '파일은 있는데 채점 대상으로 잡히지 않았다'는 관측까지만 적습니다.

이 버그를 찾은 계기는 판정 스크립트가 아니라 숫자 두 개를 나란히 놓은 일이었습니다. 판정 스크립트는 채점된 글만 세기 때문에, 채점이 멈춘 키워드는 '표본 부족'이나 '적중 0%'처럼 평범한 결과로 보입니다. 원본 폴더의 파일 수와 채점 기록 수를 따로 세어 804건 대 2건이라는 차이를 보고 나서야, 판정 결과가 아니라 파이프라인이 이상하다는 쪽으로 방향을 틀었습니다. 그다음 원본 폴더를 열어 `raw/A/` 라는 예상 밖의 폴더를 찾았습니다.

구조로 보면 원인은 슬래시가 아니라 '사람이 읽는 이름'과 '기계가 쓰는 식별자'를 한 값으로 겸한 설계입니다. 키워드 이름은 사람이 검색창에 칠 말 그대로라 기호가 들어가기 쉽습니다. 그 값이 경로·파일명·목록 키로 동시에 쓰이면, 이름에 들어간 기호 하나가 저장과 조회를 서로 다른 곳으로 보냅니다.

조치: 9개 조합 제거와 경로 이관

조치는 두 갈래였고 같은 날 끝냈습니다. 판정에 걸린 9개 조합은 블로그·카페 수집 키워드 목록에서 지웠습니다. 키워드를 채널별로 따로 관리하기 때문에, 같은 '앱개발 비용'이라도 블로그와 카페에서 각각 판정대로 지우는 방식입니다.

경로 버그는 세 단계로 고쳤습니다. `raw/A/B 테스트/` 아래 날짜별 파일 8개를 `raw/AB테스트/`로 옮기고, 키워드 이름을 슬래시 없는 'AB테스트'로 바꿔 블로그·카페 두 목록에 다시 등록했습니다. 채점이 재개된 뒤 새 이름으로 다시 판정하기로 했습니다.

이름을 바꾸는 순간 이 키워드는 사실상 새 키워드가 됩니다. 옮긴 파일 8개는 채점을 거친 적이 없고, 7일 판정 때 원본에서 짐작한 적중률 0.4%도 검증되지 않은 숫자였습니다. 그래서 이 키워드만은 판정 시계를 처음부터 다시 돌리기로 했습니다. 경로 버그 하나가 남긴 진짜 비용은 파일 몇 개가 아니라 판정 주기 한 바퀴, 곧 7일이었습니다.

조합 9개를 지운 효과는 크론 한 번의 API 호출 예산 47회와 실행 시간에서 나옵니다. 다만 제거 뒤 호출 수와 실행 시간을 다시 재지는 않았습니다. '절감했다'는 방향은 분명하지만 몇 회, 몇 초가 줄었는지는 이 글에 적을 수 있는 숫자가 없습니다. 개선율만 말하고 절대값을 감추는 글이 되지 않으려고, 재지 않은 것은 재지 않았다고 남깁니다.

기각한 선택지도 두 개 적어 둡니다. 13개를 전부 남기고 한 주 더 지켜보는 안은, 판정 도구가 이미 있는데 쓰지 않는 셈이라 버렸습니다. 경로 버그를 기록만 해 두고 다음 작업으로 미루는 안도 버렸습니다. 이미 7일을 잃었고, 파일 8개 이관과 이름 변경만으로 추가 유실을 바로 막을 수 있었기 때문입니다.

재측정 결과: 8일 뒤 다시 잰 숫자는 무엇을 말했나?

한 번 재고 끝내지 않으려고 2026년 8월 6일에 같은 판정 스크립트를 8일 창으로 다시 돌렸습니다. 이번 판정이 본 글은 중복을 뺀 17,975건이었습니다. 기준은 그대로 50건 이상·적중 0%였고, 제거 대상 7개 조합이 새로 나왔습니다.

가장 궁금했던 'AB테스트'는 이름을 바꾼 뒤 블로그에서 92건을 다시 모았고, 이번에는 채점이 정상으로 돌았습니다. 결과는 적중 0%였습니다. 판정 불가였던 키워드가 제대로 채점된 뒤 제거 대상으로 확정된 셈입니다. 카페 'AB테스트'는 39건으로 50건에 못 미쳐 다시 보류했습니다. 7월 28일 판정 때 '0.4%'라는 원본 추정치가 있었지만 채점을 거치지 않은 숫자라 믿지 않기로 했었고, 재측정이 그 판단을 뒷받침했습니다.

나머지 여섯 조합도 적중 0%로 빠졌습니다. 블로그 'AI 자동화' 605건, 블로그 '검색광고' 422건, 카페 'CPC' 111건, 카페 '앱 개발 대행' 89건, 카페 '어플 개발' 87건, 블로그 '앱 개발 대행' 59건입니다. 반대로 같은 키워드라도 다른 채널에서 적중이 있으면 남겼습니다. 'AI 자동화'는 카페에서 1.7%, 'CPC'는 블로그에서 1.1%로 살아남았습니다.

채널별로 따로 판정하는 이유가 여기서 드러납니다. 키워드 단위로 묶어 판정했다면 'AI 자동화'는 카페 적중 때문에 블로그 605건까지 계속 모았을 테고, 반대로 블로그 0%를 근거로 통째로 지웠다면 카페의 1.7%를 잃었을 겁니다. 같은 말이라도 블로그와 카페에서 쓰는 사람과 쓰는 이유가 다르기 때문에, 판정 단위를 채널까지 쪼개야 버릴 것만 버릴 수 있습니다.

눈여겨볼 점은 첫 판정의 생존자가 두 번째 판정에서 빠졌다는 사실입니다. 7월 28일에 카페 0.9%로 남은 '어플 개발'과 '앱 개발 대행', 카페 1.2%로 남은 'CPC'가 8월 6일에는 모두 0%였습니다. 두 판정의 집계 창이 얼마나 겹치는지는 기록에 남아 있지 않아, 적중률이 실제로 떨어졌는지 창이 바뀌어 달라 보였는지는 가르지 못했습니다. 다만 1% 안팎의 적중률은 판정 한 번으로 존치를 확정하기에 너무 얇다는 점은 분명해졌습니다.

남는 한계: 이름과 목록을 손으로 적는 구조

경로 버그는 고쳤지만, 그 버그를 만든 구조는 그대로입니다. 수집 키워드는 블로그 목록과 카페 목록 두 곳에 사람이 직접 적고, 그 이름이 곧 경로입니다. 다음에 누군가 'B2B/B2C 마케팅' 같은 이름을 넣으면 같은 일이 다시 일어날 수 있습니다. 이름에서 경로용 식별자를 따로 만들거나, 등록할 때 슬래시 같은 경로 기호를 거부하는 검사가 필요하지만 이번에는 넣지 않았습니다.

감시 쪽 빈틈도 그대로입니다. 이번 버그는 7일 동안 아무 알림 없이 이어졌고, 판정일에 사람이 수집 건수와 채점 건수를 나란히 놓고서야 드러났습니다. 키워드마다 '어제 수집한 건수'와 '어제 채점한 건수'를 비교해 수집은 있는데 채점이 0이면 알리는 검사가 있었다면 첫날인 7월 22일에 잡혔을 겁니다. 이 검사도 이번 수정 범위에는 넣지 않았습니다.

같은 유형이 다른 자리에서도 나왔습니다. 8월 6일 재측정 날, 서비스 수요 신호를 모으는 프로필 하나가 3주 넘게 일일 보고서에 한 번도 나오지 않았다는 사실을 찾았습니다. 신호 매칭은 정상으로 돌아 7개 신호가 잡혀 있었는데, 보고서를 쓰는 코드 두 곳이 프로필 목록을 손으로 적어 두고 새 프로필을 빠뜨렸습니다. 보고서 파일 8개를 전부 검색해 보니 0/8이었습니다. 이번에도 목록에 한 줄을 더하는 최소 수정만 했고, 프로필 설정을 읽어 자동으로 도는 구조로 바꾸는 작업은 남겨 두었습니다.

적중률 쪽 한계도 남습니다. 살아남은 조합은 전부 기존 키워드군보다 구조적으로 낮고, 가장 높은 블로그 'CPC'도 4.0%였습니다. 이 조합들은 광고 단가 계산이라는 별도 목적 때문에 남아 있으니, 다음 판정도 적중률 하나가 아니라 그 목적에 쓸 데이터가 실제로 모였는지로 봐야 합니다. 재평가는 2주 뒤로 잡았습니다.

크롤링 키워드 선정에 옮겨 쓸 수 있는 세 가지

• 넣는 날에 빼는 규칙을 같이 정한다 — 이번에는 '7일 누적 50건 이상 · 적중 0%면 제거'였다
• '수집 건수'와 '채점 건수'를 따로 센다 — 804건 대 2건처럼 둘이 벌어지면 판정보다 먼저 파이프라인을 의심한다
• 사람이 읽는 이름을 경로·파일명·목록 키로 겸해 쓰지 않는다 — 겸해 쓴다면 등록할 때 경로 기호를 막는다

키워드 수가 늘수록 이 판정은 사람 눈으로 버티기 어려워집니다. 우리는 판정 스크립트를 먼저 만들어 두었기 때문에 7일째 되는 날 명령 두 줄로 13개를 정리할 수 있었고, 그 과정에서 숫자가 맞지 않는 한 곳을 발견했습니다. 수집·채점 파이프라인을 직접 운영하면서 비슷한 판정 기준이나 유실 감시가 필요하다면 상담으로 문의해 주세요.

작성: SGK Studio 엔지니어링. 이 글의 수치는 2026년 7월 28일과 8월 6일의 판정 기록에서 옮겼습니다.