클로드 네이버 블로그 자동화 버그 기록: 롱테일 키워드가 거꾸로 뽑히던 날
클로드로 만든 블로그 자동화 프로그램을 실제 구글 블로거와 네이버 계정으로 돌려 보니, 가장 큰 버그는 코드 오류가 아니라 판단 오류였어요. 경쟁이 제일 심한 키워드를 오히려 대표 키워드로 고르는 롱테일 키워드 역전 버그가 그랬고, 이 글에서 그 버그를 포함해 3일 동안 만난 7가지를 어떻게 고쳤는지 기록해요.
핵심 요약
- 7가지 버그 중 제일 영향이 컸던 건, 경쟁이 가장 심한 키워드를 대표 키워드로 고르던 롱테일 키워드 역전이에요.
- 다른 계정 글에 엉뚱한 브랜드 문구가 붙던 문제와, 네이버 에디터에서 소제목이 사라지던 문제도 있었어요.
- “고쳤다”는 말은 실제 계정에서 돌려 보고 화면에서 확인하기 전에는 하지 않기로 했어요.
실계정으로 돌려보니 어떤 버그가 나왔나요?
본편 2에서 소개한 블로그 자동화 프로그램을 9월 28일부터 30일까지 3일 동안 데모 계정이 아니라 실제 계정으로 돌려 봤어요. 테스트용 데이터로는 안 보이던 문제가 줄줄이 나왔어요. 정리하면 이래요.
| 버그 | 어떻게 나타났나요 | 어떻게 고쳤나요 |
|---|---|---|
| 1. 롱테일 키워드 역전 | 경쟁이 가장 심한 키워드가 대표 키워드로 뽑혔어요 | 검색량·문서 수·경쟁도를 함께 보고 저경쟁 롱테일 키워드를 우선하도록 다시 설계했어요 |
| 2. 발굴 점수 0점 오류 | 검색량이 아주 작은 실시간 이슈 키워드가 억지로 최악 점수(0점)를 받았어요 | 점수 계산을 고쳤어요 |
| 3. 브랜드 하드코딩 | 다른 계정 글에도 “지원포유 이웃추가하세요” 같은 문구가 붙었어요 | 브랜드 문구를 코드에 고정하지 않고 계정별 정보를 따르게 했어요 |
| 4. 네이버 붙여넣기 무시 | 에디터가 본문 붙여넣기를 조용히 무시했어요 | 실제 컴퓨터 클립보드와 단축키 방식으로 바꿨어요 |
| 5. 소제목 사라짐 | 소제목(H2)이 통째로 없어졌어요 | 서식을 바꾸는 순서와 타이밍 문제, 두 원인을 모두 고쳤어요 |
| 6. 사진 설명 포커스 | 사진 설명을 쓴 뒤 다음 내용이 설명 칸 안으로 이어 붙었어요 | 입력 위치(포커스) 처리를 고쳤어요 |
| 7. AI 활용 설정 토글 | 이미지가 여러 장이어도 항상 첫 장만 설정됐어요 | 장마다 적용되게 고쳤어요 |
롱테일 키워드가 거꾸로 뽑히던 버그는 뭐였나요?
롱테일 키워드는 검색 수요는 있지만 경쟁이 덜한, 길고 구체적인 검색어를 말해요. 새 블로그가 상위에 노출되려면 이런 키워드가 유리해서, 프로그램이 제일 먼저 해야 할 일이 “글 쓸 키워드를 잘 고르는 것”이었어요.
그런데 제 프로그램은 거꾸로 하고 있었어요. 후보 중에서 경쟁이 가장 심한, 그러니까 가장 최악인 키워드를 대표 키워드로 골라 버리는 구조적인 버그였어요. 이 차이가 얼마나 큰지는 숫자로 보면 확 와닿아요. 2026년 10월 1일에 데이터랩툴즈로 확인한 네이버 블로그 문서 수는, “블로그 자동화”가 약 543만 건인 반면 “클로드 블로그 자동화 후기”는 약 3,800건이었어요. 같은 주제인데 경쟁 규모가 천 배 넘게 차이 나요.
고치는 방향은 이랬어요. 검색량, 문서 수, 경쟁도를 함께 보고 경쟁이 낮은 롱테일 키워드를 먼저 쓰게 전면 재설계했어요. 키워드를 발굴하는 곳, 실시간 채널에서 발굴하는 곳, 즉석으로 원고를 쓰는 곳, 원고 생성 자체까지 네 군데 진입점 모두에 적용했어요. 하나라도 빠지면 그 길로 다시 최악의 키워드가 들어오니까요.
발굴 점수가 0점으로 나오던 오류는 뭐였나요?
검색량이 아주 작은 실시간 이슈 키워드가 억지로 최악 점수인 0점을 받는 오류도 있었어요. 원인은 검색광고 API가 최신 화제를 아직 따라잡지 못하는데, 문서 수는 이미 많이 쌓여 있는 경우였어요. 갓 터진 이슈는 검색량 데이터가 비어 있는데 글은 벌써 많으니, 점수 계산이 “경쟁만 심한 키워드”로 읽어 버린 거예요. 이 부분도 계산을 고쳤어요.
다른 계정 글에 엉뚱한 브랜드 문구가 붙던 버그는요?
저는 여러 계정을 운영해요. 경제 블로그도 있고 AI 도구 블로그도 있어요. 그런데 AI에게 주는 지시문에 브랜드 이름이 그대로 박혀 있어서, 다른 계정의 글 끝에도 “지원포유 이웃추가하세요” 같은 문구가 붙었어요. 브랜드 문구를 코드에 고정하지 않고 계정별 정보를 따르게 고쳤어요. 이 일 뒤에 원고를 승인하기 전에 계정 콘셉트가 비어 있으면 경고하는 확인 단계도 넣었어요.
네이버 발행에서는 어떤 문제가 있었나요?
실제로 발행해 보며 찾은 네이버 쪽 문제는 네 가지였어요. 프로그램이 만든 가짜 클립보드 이벤트를 네이버 에디터가 조용히 무시해서 본문이 안 붙었고, 소제목이 통째로 사라지는 문제는 서식을 바꾸는 순서와 타이밍이 겹친 두 가지 원인이었어요. 사진 설명을 쓰고 나면 입력 위치가 설명 칸에 갇혀서 다음 내용이 그 안으로 이어 붙었고, 이미지의 AI 활용 설정은 여러 장 중 첫 장만 건드렸어요.
네이버나 뉴스 사이트처럼 외부 화면에 기대는 기능은 화면 구조가 바뀌면 조용히 실패할 수 있어요. 그래서 안 잡히는 항목을 먼저 점검하고, 실제 브라우저로 화면을 열어 안정적인 선택자를 찾고, 기존 방식은 지우지 않고 새 방식을 앞에 추가하는 순서를 문서로 정해 뒀어요. 네이버는 고친 뒤에 반드시 비공개 발행으로만 시험해요. 자동 발행은 플랫폼의 이용약관과 정책이 바뀔 수 있으니 따라 하기 전에 직접 확인해 주세요.
고쳤다는 걸 어떻게 확인했나요?
개발하면서 가장 많이 반복한 실수가 “코드만 보고 고쳤다고 판단하는 것”이었어요. 그래서 확인 순서를 정했어요.
| 순서 | 확인 내용 |
|---|---|
| 1 | 타입 검사와 테스트 |
| 2 | 서버와 워커 재시작(코드가 자동으로 반영되지 않는 구조라서) |
| 3 | 실제 발행과 검수까지 직접 실행 |
| 4 | 화면에 진짜로 보이는 값으로 확인 |
4번이 특히 중요했어요. 숨겨진 데이터에 속아서 “됐다”고 착각한 적이 있었거든요. 파이썬으로 만든 소재 발굴 도구를 이 프로그램으로 옮길 때도 점수 공식과 근거 문장이 원본과 같아야 해서, 원본 결과와 비교하는 테스트로 차이를 고정해 뒀어요. 네이버가 검색·데이터랩 API를 구버전에서 NAVER API HUB로 옮긴 것도 이 기간에 대응했어요. 새 방식에 맞게 코드를 고치고 검색광고 API 키를 새로 발급받아 연결했어요.
이 버그들에서 배운 점은 뭔가요?
- AI는 코드를 잘 짜지만, “어떤 키워드가 좋은 키워드인가” 같은 판단 기준은 제가 정해서 알려줘야 했어요.
- 데모 데이터로는 안 보이던 버그가 실계정에서 한꺼번에 나왔어요. 자동화는 실제 환경에서 돌려 봐야 해요.
- 외부 화면에 기대는 기능은 언제든 깨질 수 있다고 보고, 깨졌을 때의 대응 순서를 미리 정해 두는 게 안전해요.
이런 반복되는 실수를 막으려고 정한 원칙은 지침 15가지 글에 모았어요. 가장 중요한 사람 검수 규칙은 본편 5에서 이어서 다뤄요. 전체 구조는 본편 2, 로컬 모델 이야기는 본편 3에 있어요.
자주 묻는 질문
Q. 롱테일 키워드가 뭔가요?
검색하는 사람은 있지만 경쟁이 덜한, 길고 구체적인 검색어예요. “블로그 자동화”보다 “클로드 블로그 자동화 후기”처럼 구체적인 말이 롱테일에 가까워요.
Q. 왜 경쟁이 심한 키워드가 대표로 뽑혔나요?
후보 키워드를 비교해 대표를 고르는 기준이 거꾸로 되어 있었어요. 실계정으로 돌려 보고서야 발견했고, 검색량·문서 수·경쟁도를 함께 보는 방식으로 다시 설계했어요.
Q. 브랜드 문구가 다른 계정 글에 붙는 걸 어떻게 막았나요?
브랜드 문구를 코드에 고정하지 않고 계정별 정보를 따르게 했어요. 또 원고를 승인하기 전에 계정 콘셉트가 비어 있으면 경고해요.
Q. 네이버 발행은 공개로 테스트하나요?
아니요. 네이버는 고친 뒤 반드시 비공개 발행으로만 시험하고, 공개 발행으로 시험하지 않아요.
Q. AI가 만든 버그를 AI가 고친 걸 믿어도 되나요?
그래서 “고쳤다”는 말은 실제 발행과 검수까지 돌리고, 화면에 보이는 값으로 확인하기 전에는 하지 않아요. 공개 전환도 항상 사람이 확인한 뒤에만 돼요.
다음 글에서는 AI가 쓴 글이 사람 확인 없이 공개되지 않게 만든 검수 규칙을 이야기할게요. 경험을 지어내지 못하게 막는 방법도 함께 다뤄요.
