AI자동화 네이버 블로그 발행: 고친 글 7편이 검색에서 사라졌다

무엇이 문제였나: 자동 발행은 돌았는데 노출은 무엇으로 재나?

문제는 발행 자체보다 발행 뒤에 있었습니다. 2026년 9월 15일, 자사 사이트 리포트 하단에 붙여 둔 상담 폼을 16일 동안 지켜본 판정이 나왔습니다. 폼 제출은 0건이었고, 같은 기간 리포트 페이지의 외부 방문은 51세션이었습니다. 폼이 약하다는 증거도, 괜찮다는 증거도 아니었습니다. 읽을 수 있는 결론은 하나였습니다. 들어오는 사람 자체가 너무 적었습니다. 그래서 이미 써 둔 글을 사람이 많이 검색하는 네이버 블로그로 옮겨 싣기로 했습니다.

같은 날 밤, 사람 손을 거치던 네이버 블로그 발행을 예약 실행으로 넘겼습니다. 한 번 도는 흐름은 이렇습니다. 일시정지 표시 파일이 있으면 멈추고, 오늘 이미 발행한 글이 있으면 끝냅니다. 로그인 상태를 확인하고, 아직 안 올린 다음 원고를 고르고, 그림이 없으면 굽습니다. 편집기에서 글을 조립하고 실패하면 새 편집기로 한 번 더 조립합니다. 그림 수·표 수·순서 검증을 통과해야만 발행 버튼을 누릅니다.

발행 뒤에는 로그인하지 않은 상태로 글 주소를 열어 200 응답이 오는지 보고, 발행 기록 파일에 한 줄을 남기고, 슬랙 채널로 알립니다. 한 회차 조립에 약 10분이 걸립니다. 여기까지는 잘 돌았습니다. 빠진 칸은 하나였습니다. 비로그인 200 응답은 글이 존재한다는 뜻이지, 누군가 검색했을 때 그 글이 보인다는 뜻이 아닙니다. 하루 1편을 계속 쌓을지, 늘릴지, 멈출지를 정하려면 노출을 재는 자가 필요했습니다.

비용 관점에서도 이 칸이 중요했습니다. 리포트 원고는 169편이 쌓여 있었지만 새 리포트는 당분간 늘지 않는 구조였습니다. 매일 한 편씩 내보내면 원고는 소모만 됩니다. 노출이 안 되는 글에 원고를 소모하면 되돌릴 방법이 없습니다.

처음 잰 숫자: 두 글이 3시간 안에 제목 검색에 떴다

처음 계획은 단순했습니다. 발행 간격 하루 1편을 기본값으로 두고, 첫 2~3편이 네이버 서치어드바이저에 색인으로 잡히는지 본 다음 9월 22일에 간격을 다시 정하기로 했습니다. 하루 1편은 누가 정한 목표가 아니라 시작용 기본값이었습니다.

그런데 9월 15일 23시에 이 계획의 전제가 무너졌습니다. 직접 확인해 보니 이미 올린 두 글이 모두 발행 후 3시간 안에 네이버 블로그 검색에서 제목 전체로 찾힙니다. 측정 방법은 가장 원시적인 방법이었습니다. 글 제목 전체를 그대로 검색창에 넣고, 블로그 검색 결과에 우리 글이 있는지 봅니다. 이 방식은 사람이 실제로 보는 화면과 같은 자리를 재기 때문에 해석할 여지가 적습니다.

두 편이면 표본이 작습니다. 그래도 이 숫자는 두 가지를 알려 줬습니다. 첫째, 네이버는 새 블로그 글을 몇 시간 안에 검색에 올립니다. 일주일을 기다려 판정할 이유가 없었습니다. 둘째, 노출 여부는 발행 직후 몇 시간 안에 확인할 수 있으니, 매 회차마다 기계가 직접 잴 수 있었습니다.

세운 가설: 색인 도구로 재고, 링크와 상호 참조는 많을수록 좋다

이 무렵 저희가 세운 가설은 세 개였습니다. 지금 보면 셋 다 일부가 틀렸지만, 당시에는 각각 그럴듯한 근거가 있었습니다. 순서대로 적습니다.

• 가설 1: 노출은 네이버 서치어드바이저의 색인 반영으로 잴 수 있다. 9월 22일에 첫 2~3편을 보고 판정한다
• 가설 2: 블로그 글 끝에 홈페이지 원문으로 가는 링크를 붙이면 유입이 늘어난다. 표가 길면 상위 5행만 보여 주고 나머지는 원문 링크로 넘긴다
• 가설 3: 새 글이 나올 때마다 기존 글 3편의 “함께 보면 좋은 글” 목록을 고쳐 다시 발행하면 글끼리 서로 이어져 방문자가 더 오래 머문다

가설 3은 9월 17일에 들어갔습니다. 실측해 보니 한쪽만 가리키는 연결이 남아 있었습니다. 리포트 3편 가운데 광고대행 글은 자기를 가리키는 글이 0편이었습니다. 원인은 둘이었습니다. 관련 글을 태그가 겹치는 글로만 골랐고, 새 글이 나와도 기존 글은 새 글을 가리키지 않았습니다. 그래서 관련 글을 같은 주제 축에서 3편까지 채우고, 새 글을 발행한 뒤에는 기존 글의 관련 글 블록을 다시 써서 수정 발행하게 했습니다.

이 기능의 비용은 그때도 알았습니다. 새 글 1편마다 기존 글 최대 3편이 수정 발행되고, 한 편에 약 3~4분이 듭니다. 네이버가 잦은 수정을 어떻게 보는지는 실측이 없었습니다. 위험은 적어 두었지만, 노출 감시 장치가 지켜보니 괜찮을 거라고 보고 켜 두었습니다.

가설이 틀린 지점: 왜 고친 글 7편이 검색에서 사라졌나?

가설 1은 가장 먼저 틀렸습니다. 서치어드바이저는 우리 도메인을 등록해서 보는 도구라, blog.naver.com 아래에 있는 블로그 글의 노출은 잴 수 없었습니다. 같은 날 밤 이 지적을 받고 9월 22일 판정 계획을 버렸습니다. 대신 매 회차마다 최근 3편을 발행 2시간이 지난 뒤 전체 제목으로 검색해, 결과에 없으면 발행을 자동으로 멈추고 알리는 노출 감시 함수(exposure_guard)를 넣었습니다. 그 대가로 발행 상한은 하루 2편으로 올렸습니다.

가설 2는 9월 17일에 철회했습니다. 네이버는 외부 링크가 있는 글을 검색과 추천 노출에서 밀어내는 경향이 강하다는 판단이었습니다. 링크를 1개로 줄이는 안도 검토했지만, 외부 링크가 있다는 사실은 같아서 노출 불이익을 피하지 못한다고 보고 버렸습니다. 결국 외부 링크를 모두 뺐고, 표는 상위 5행만 싣던 방식을 버리고 전 행을 원고에 직접 싣습니다. 리포트 표는 최대 15행이라 자릿수 문제도 크지 않았습니다.

가설 3이 가장 비싸게 틀렸습니다. 9월 18일에는 상위 노출 글과 같은 구조로 바꾸려고 기존 7편을 전부 수정 발행했고, 그 직후 다시 잰 구조 검사는 전부 통과했습니다. 그런데 그다음, 끊긴 작업을 이어받아 발행글의 대시 문자를 빼려고 7편을 또 수정 발행했습니다. 그 뒤 9월 19일 12:23, 15:31, 9월 20일 09:05 세 차례 실측에서 7편 모두 제목 전체 검색(모바일 블로그 탭과 통합검색)에서 보이지 않았습니다. 같은 기간 이번에 손대지 않은 1편만 노출을 유지했습니다.

9월 18일 구조 개편의 근거도 숫자였습니다. 같은 검색어 3종의 상위 노출 글 9건 가운데 7건이 소제목이나 인용구를 썼는데, 그때까지 저희가 올린 5편은 소제목·인용구·구분선·링크 카드가 모두 0개였습니다. 원인은 원고 변환기가 소제목을 굵은 본문 문단으로 바꿔 온 데 있었습니다. 화면에서는 본문과 글자 크기가 같았습니다. 이 개편 자체는 옳았지만, 개편을 위해 기존 7편을 한꺼번에 다시 발행한 일이 뒤에 대조군을 흐리는 결과로 이어졌습니다.

측정은 처음과 같은 방법을 썼습니다. 글 제목 전체를 검색창에 넣고 결과에 우리 글이 있는지 봤습니다. 블로그에 있는 글은 이 8편이 전부였으므로, 블로그 계정 전체가 저품질로 묶인 상황은 아니라고 판단했습니다. 계정 아이디로 통합검색을 해도 그 1편만 나왔습니다. 계정 전체가 걸렸다면 그 1편도 사라졌어야 합니다.

진짜 원인: 무엇이 노출을 지웠는지 아직 셋 중 하나로 못 갈랐다

9월 20일 09:05 시점에 저희가 내린 결론은 “이미 나간 글을 고치면 검색에서 빠지고 돌아오지 않는다”였습니다. 7편 대 1편이라는 대비가 선명했기 때문입니다. 이 결론은 과했습니다. 작업을 마무리하며 기록을 다시 감사하다가, 대조군으로 쓴 그 1편도 9월 18일 구조 개편 때 이미 한 번 수정 발행한 글이라는 사실을 찾았습니다.

“수정하면 검색에서 영구히 안 돌아온다”는 결론은 대조군이 실제로는 대조군이 아니었다는 사실 하나로 무너졌다. 수정 자체는 7편과 1편 모두 겪었다.

그 1편은 9월 18일 수정 뒤에도 최소 9월 19일 낮까지 노출을 유지했습니다. 그러면 남는 설명은 세 갈래입니다. 회복까지 걸리는 시간이 21시간보다 길었을 수 있습니다. 아니면 9월 19일 수정에만 있던 조건, 즉 한 시간 안에 7편을 몰아서 고친 일, 제목까지 바꾼 일, 이틀 연속으로 같은 글을 두 번 편집한 일 가운데 하나가 진짜 원인일 수 있습니다. 이 셋을 가르는 실험은 아직 하지 않았습니다.

같은 시기 발행이 실패한 일도 있었습니다. 9월 19일 10시 40분 회차가 종료 코드 1로 끝났습니다. 처음에는 브라우저와 스크립트 사이 중계 프로그램의 응답 대기 시간 초과를 원인으로 봤습니다. 실제 원인은 발행용 크롬에 열려 있던 빈 새 탭 하나였습니다. 그 탭이 페이지 이벤트를 켜는 명령(Page.enable)에 응답하지 않았고, 로그인 확인 단계가 그 응답을 무한히 기다렸습니다. 중계 시간 초과는 증상이었지 원인이 아니었습니다.

두 사례가 같은 교훈을 줍니다. 처음 눈에 띈 변수가 원인처럼 보여도, 비교 대상이 정말 그 변수만 달랐는지 확인하기 전에는 결론을 닫지 않습니다. 검색 소실 쪽은 그 확인을 못 했으므로, 원인을 단정하지 않고 위험을 줄이는 조치만 했습니다.

어떻게 고쳤나: 노출 감시, 자동 재발행 차단, 외부 링크 이중 방어

원인을 못 갈랐으니 조치의 기준은 “어떤 원인이든 재발하지 않게”였습니다. 자동 발행은 매일 새 글을 낸 직후 기존 글 3편의 관련 글 목록을 고칩니다. 그대로 두면 원인이 무엇이든 같은 일이 다시 일어납니다. 반대로 관련 글 상호 링크를 아예 없애면 그 이득까지 통째로 버리는 과잉 대응입니다. 그래서 가운데를 골랐습니다.

• 발행 직후 기존 글을 고쳐 다시 올리는 단계는 기본으로 끈다. 환경 변수 NAVER_AUTO_RELINK=1을 줄 때만 동작한다
• 이미 나간 글은 더 손대지 않는다. 대시를 빼는 식의 사소한 수정도 하지 않는다
• 발행 일시정지 표시 파일은 그대로 둔다. 재개 조건은 수정 없는 새 글 3편으로 노출을 다시 확인하는 것이다
• 매 회차 최근 3편을 발행 2시간 뒤 전체 제목으로 검색하고, 없으면 자동 정지와 알림을 보낸다
• 발행 원고에 블로그 자기 주소 외의 URL이 하나라도 있으면 조립 전에 발행 자체를 막는다

마지막 항목은 9월 17일 외부 링크 제거 때 넣은 장치입니다. 원고를 만드는 생성기에서 링크를 빼는 것만으로는 부족하다고 봤습니다. 생성기가 실수하면 링크가 그대로 나가기 때문입니다. 그래서 발행 스크립트에도 같은 검사를 두어, 원고에 우리 블로그 주소 외의 URL이 섞이면 발행 단계에서 멈추게 했습니다. 두 곳에서 따로 막는 이중 방어입니다.

발행 환경도 이 무렵 한 번 흔들렸습니다. 예약 실행은 대화형 작업 창이 받는 포트 번호를 물려받지 못해서, 발행 전용 크롬을 대역 밖 고정 포트 9250에 따로 띄웠습니다. 공용 포트 9222는 지식iN 답변·캡차 처리 예약 작업이 같이 써서 창이 서로 밀리기 때문입니다. 그런데 같은 PC의 다른 작업 창이 화면 조종 도구를 한 번 부르면, 그 도구의 정리 단계가 9222~9241 포트만 살려 둘 크롬으로 보고 9250 크롬을 강제 종료했습니다. 22:02에 로그인한 크롬이 22:03:41에 다시 켜지며 조립 중이던 탭이 사라졌습니다. 판정 기준을 “디버그 소켓을 가진 크롬 전부”로 바꾼 뒤, 기동 유예 90초가 지나 정리를 다시 돌려도 9250 크롬(PID 163736)은 살아 있었습니다. 발행이 멈추면 노출 감시도 의미가 없어서, 이 수리를 노출 작업보다 먼저 끝냈습니다.

원고 공급도 손봤습니다. 리포트 무인 발행은 9월 15일 3회차가 모두 “미사용 질문 0건”으로 0편이었고, 새 리포트는 당분간 늘지 않습니다. 반면 기술블로그는 9월 7일 이후 매일 4~6편이 새로 나왔습니다. 피드 66편 가운데 자동매매·주식 주제 4편을 빼면 62편이 후보였습니다. 그래서 네이버에 기술블로그 카테고리를 하나 더 만들고, 리드와 소제목별 앞 두 문장을 뽑은 요약 원고를 매일 06시 40분에 따로 발행하게 했습니다. 리포트 회차 10시 40분과 겹치지 않습니다.

기술블로그 본문 전체를 옮기는 안은 버렸습니다. 원문 사이트 유입이 줄고 같은 글이 두 곳에 생기기 때문입니다. 네이버 계정을 따로 만드는 안도 버렸습니다. 새 계정은 신뢰가 0에서 시작합니다. 비슷한 자동 발행에서 글 구조를 어떻게 맞췄는지는 네이버 블로그 링크 카드 자동 발행 글에 따로 정리했습니다.

재측정 결과: 무엇이 확인됐고 무엇이 아직인가?

조치마다 따로 다시 쟀습니다. 결과를 숫자로 먼저 적고, 그 숫자가 증명하지 않는 부분을 뒤에 적습니다.

링크 차단 쪽은 적대 테스트로 쟀습니다. 외부 링크가 들어 있는 옛 원고 181편을 발행 스크립트에 넣어 181편 모두 막히는지 보고, 새로 만든 원고 181편은 하나도 막히지 않는지 봤습니다. 둘 다 기대대로 나왔습니다. 생성기와 발행기 중 한쪽이 실수해도 링크가 나가지 않는다는 뜻입니다.

구조 쪽은 측정기 자체가 한 번 틀렸습니다. 상위 노출 글 9건을 재는 첫 버전은 편집기 컴포넌트형 소제목을 세지 못해 “9건 중 9건이 구조 장치를 쓴다”고 과장했습니다. 다시 재니 9건 중 7건이었고, 이 정정을 기록에 그대로 남겼습니다. 소제목 구분선도 처음에는 소제목마다 넣었다가, 소제목이 많은 기술블로그 글에서 11줄까지 늘어 상위 글 최대치 8을 넘기는 바람에 관련 글 앞 1회로 줄였습니다.

반대로 이 재측정이 증명하지 않는 것도 분명합니다. 자동 재발행을 끈 뒤 새 글의 노출이 유지되는지는, 발행을 다시 켜고 수정 없는 새 글 3편으로 확인해야 압니다. 사라진 7편이 시간이 지나면 돌아오는지도 아직 숫자가 없습니다. 개선 전후로 확실히 말할 수 있는 숫자는 링크와 구조 쪽뿐이고, 노출 쪽은 위험을 줄인 상태에서 멈춰 있습니다.

남는 한계: 어떤 조건이 진짜 원인인지 어떻게 가를까?

가장 큰 한계는 원인을 못 갈랐다는 점입니다. 판별하려면 변수를 하나씩만 바꾼 실험이 필요합니다. 예를 들어 글 한 편만 본문 한 글자를 고쳐 다시 올리고, 다른 한 편은 제목만 바꾸고, 또 한 편은 같은 날 두 번 고친 뒤 각각 같은 방법으로 제목 검색을 재는 식입니다. 다만 실험 자체가 그 글들의 노출을 잃을 수 있는 실험이라, 잃어도 되는 글로만 할 수 있습니다.

두 번째 한계는 비용입니다. 한 회차 조립에 약 10분이 걸리고, 로그인 중 캡차나 2차 인증이 뜨면 그날은 실패 알림만 남고 사람이 한 번 손을 대야 합니다. 브라우저 쪽 명령 하나가 왕복하는 데 약 26초가 걸려서, 소제목·인용구 변환은 조립을 마친 뒤 브라우저 안에서 한 번에 처리하도록 바꿨습니다. 그래도 발행 시간이 짧다고 하긴 어렵습니다.

세 번째 한계는 성과입니다. 발행을 쌓는 일이 실제 문의와 매출로 이어지는지는 성과 지표 5개로 10월 초에 판정하기로 했고, 이 글을 쓴 원문 기록 시점에는 다섯 지표 모두 기준선 상태였습니다. 노출을 지키는 장치는 갖췄지만, 노출이 매출로 이어지는지는 아직 다른 질문입니다.

비슷한 일을 하는 분께 남기고 싶은 요점은 셋입니다. 자동 발행의 성공 판정을 “페이지가 열린다”에서 멈추지 말 것. 이미 검색에 뜬 글을 자동으로 고치는 기능은 원인이 확인될 때까지 기본으로 끌 것. 대조군이 정말 한 변수만 달랐는지 확인하기 전에는 결론을 닫지 말 것. 네이버 블로그나 사내 업무를 이렇게 무인으로 돌리는 구조가 궁금하면 상담으로 물어봐 주세요.