네이버 블로그 노출체크 클로드코드로 자동화 시키기

소개

블로그 마케팅을 하면서 매일 반복하던 노가다가 있었습니다. "이번 주에 발행한 글이 특정 키워드로 검색했을 때 네이버에 잘 노출되고 있나?"를 키워드 하나하나 직접 검색해서 순위를 손으로 적는 일이었죠.

키워드 하나당 ①네이버 검색창에 입력 → ②통합검색 결과에서 우리 글이 몇 번째인지 눈으로 찾기 → ③안 보이면 다음 페이지 → ④순위를 스프레드시트에 기록. 키워드가 10개면 견딜만한데, 30~50개씩 쌓이는 주에는 오전 시간을 통째로 잡아먹는 작업이었습니다. 사람이 하는 일이라 빠뜨리거나 잘못 보는 실수도 잦았고요.

자동화 욕심은 늘 있었지만, 네이버는 검색 API가 통합검색의 실제 노출 순위(광고·뉴스·지식인이 섞인 실제 화면)를 반영하지 않아서 쉽게 손대기 어려운 영역이었습니다. 그래서 "Claude Code에게 통째로 맡겨보자"고 결심했습니다.

진행 방법

사용한 도구: Claude Code (터미널 기반 AI 코딩 도구)

빠르게 동작하는 것을 우선으로 만들고, 이후 같은 도구로 점검·리팩토링까지 한 번에 진행했습니다.

1단계 — 웹 페이지로 만들기 매번 터미널 여는 게 부담스럽고 동료가 쓰기도 어려울 것 같아서, 브라우저에서 버튼만 누르면 동작하는 웹 프로그램으로 요청했습니다. Claude Code는 FastAPI + 간단한 HTML 웹 화면, 구글 스프레드시트 연동(서비스 계정 인증), 네이버 통합검색 페이지를 직접 분석해 순위를 판별하는 구조를 만들어줬습니다. 인상적이었던 건 제가 시키기도 전에 "검색 API는 실제 순위와 달라서 못 쓰고, 검색 결과 페이지를 직접 가져와 분석해야 합니다"라고 함정을 먼저 짚어준 점이었어요.

2단계 — 일시정지/종료 기능 키워드가 많으면 몇 분씩 걸리는데 중간에 멈출 방법이 없어서 추가 요청했습니다. AI는 단순히 버튼만 만든 게 아니라 백그라운드 작업 상태(idle/running/paused/completed/stopped)를 공유 변수로 추적하고, 화면이 1초마다 진행률을 표시하도록 설계해줬습니다. 이후 Railway에 배포해 어디서든 접속 가능하게 했습니다.

3~4단계 — "결과가 이상한데?" 전체 점검 어느 시점부터 1페이지에 분명히 나오는 글이 "노출 없음"으로 찍히기 시작했습니다. 네이버가 검색 결과 페이지 구조를 바꾼 듯했어요. 망가진 부분만 고칠 수도 있었지만, "이왕 손대는 김에 다른 위험도 숨어있을지 모른다"는 생각에 전체 점검을 맡겼습니다.

AI는 문서를 먼저 만든 뒤(스프레드시트 각 열의 의미까지 정리), 요청하지도 않은 위험 요소를 줄줄이 찾아왔습니다. 가장 인상적이었던 건 "같은 시트를 다루는 스크립트 두 개가 열 위치를 한쪽은 0부터, 한쪽은 1부터 세고 있어 시트 구조가 바뀌면 한 칸씩 어긋날 위험이 있다"는 지적이었어요. 그런 게 있는 줄도 몰랐습니다.

발견된 문제와 수정:

수정은 컬럼 번호를 config.py에서 통일, 중복 코드를 별도 파일(url_utils.py, http_utils.py)로 분리, 데드코드 2개 정리, 에러 발생 시 로그에 남기도록 변경하는 식으로 깔끔하게 진행됐습니다.

💡 활용 이미지 / 캡처 화면을 이 부분에 첨부하시면 좋습니다 (웹 화면, 진행률 바, 시트가 채워지는 모습 등)

[재사용 프롬프트 1] 반복 업무 자동화 의뢰 (처음 만들 때)

[본인의 반복 업무]을 자동화하는 [웹 프로그램/스크립트]를 만들어줘.

현재 손작업 흐름은 이렇다:
1. [1단계 설명]
2. [2단계 설명]
3. [3단계 설명]

입력은 구글 스프레드시트의 [어떤 열]에 있고,
결과는 [어떤 열]에 자동 기입되면 좋겠다.

외부 사이트를 긁어와야 한다면 API가 정확한지 먼저 확인하고,
부정확하면 페이지를 직접 분석하는 방향으로 가줘.
차단 방지를 위해 요청 사이에 1~2초 여유를 두는 것도 잊지 말 것.

[재사용 프롬프트 2] 코드 점검할 때

이 프로젝트 전체를 점검하려고 한다. 두 가지를 부탁한다.

1단계 — 문서화:
프로젝트 전체 소스를 읽고 CLAUDE.md(전체 구조 정리)와
memory.md(작업 누적 기록)를 만들어줘.
나중에 다시 봐도 컨텍스트가 즉시 회복되는 수준으로.

2단계 — 코드 점검:
동작은 하지만 위험할 수 있는 부분을 모두 찾아줘.
- 같은 데이터를 다루는 코드의 일관성
- 에러가 조용히 무시되는 곳
- 외부 API/페이지 구조 변경에 취약한 부분
- 더 이상 사용되지 않는 데드코드

발견한 문제는 우선순위(P1/P2/P3)로 정리하고,
해결한 다음 memory.md에 누적 기록해줘.

[재사용 프롬프트 3] 외부 사이트 스크래핑할 때

[사이트명]에서 [어떤 정보]를 가져오고 싶다. 단, 다음을 지켜줘:
1. 공식 API가 있다면 먼저 확인하되, 실제 표시되는 결과와 다른지 비교해줘
2. HTML을 직접 분석할 경우, 페이지 구조가 바뀌었을 때를 대비해
   검증 로직을 넣어줘 (예: 0건 결과 시 로그에 남기기)
3. User-Agent를 랜덤으로 돌리고 요청 사이에 1~2초 여유 줘
4. 차단 방지가 핵심이니, 빠르게보다 안정적으로 만드는 것을 우선으로

결과와 배운 점

Before vs After

배운 점과 꿀팁

1. 사람용이 아니라 AI용 문서를 먼저 만들게 했다. CLAUDE.md / memory.md는 다음에 손댈 때 AI가 처음부터 코드를 다시 읽지 않아도 되게 해주는 AI용 컨텍스트 자료입니다.

2. "고쳐줘" 대신 "점검해줘"라고 요청했다. 특정 문제만 고쳐달라면 그 부분만 봅니다. "전체 점검"이라고 하면 알아서 위험을 찾아와 숨은 버그까지 잡습니다.

3. AI가 만든 코드의 위험을 AI에게 다시 검토시켰다. 만든 사람이 점검하면 같은 사각지대를 놓치는데, 같은 AI라도 "점검 모드"로 다시 보게 하면 객관적으로 찾아냅니다.

시행착오 (이렇게 하면 안 돼요)

• 네이버 자동화에 검색 API를 쓰려 하지 말 것 — 공식 API는 통합검색 실제 노출 순위와 다른 결과를 줍니다.

• 너무 빠르게 돌리지 말 것 — 키워드 사이 1~2초 여유가 필요합니다. "최대한 빠르게"는 첫날만 잘 돌고 며칠 뒤 차단됩니다.

• "동작만 하게 해줘"는 코드를 너저분하게 만듭니다 — 한 번씩 "정리/점검" 요청을 따로 줘야 합니다.

가장 큰 교훈은 만드는 것만큼 점검이 중요하다는 점이었습니다. 비개발자가 빠르게 만든 코드는 "동작은 하는데 위험이 숨어있는" 상태가 많은데, AI에게 점검을 맡기면 사고 전에 잡힙니다.

앞으로의 계획

• 재시도 로직 추가 (네트워크 오류로 한 행이 통째로 스킵되는 일 방지)

• 작업 완료 시 슬랙/메일 알림

• 노출 순위 변동 추적 (어제 1위 → 오늘 5위면 자동 경고)

• 정기적으로 AI에게 "변경 사항 점검" 요청 루틴화

도움 받은 글 (옵션)

(참고한 지피터스 글이나 외부 사례가 있다면 이곳에 링크를 추가하세요)