AI업무자동화로 블로그 발행을 넘길 때 무엇이 문제였나?
AI업무자동화로 네이버 블로그 발행을 크론에 넘기면서 처음 막힌 곳은 편집기 조작이 아니었다. 원고가 앞으로도 계속 나오는지, 그리고 발행한 글이 검색에 실제로 뜨는지를 무엇으로 재는지, 이 두 질문에 처음 세운 답이 둘 다 틀렸다. 이 글은 그 두 가정을 세웠다가 버린 순서와, 버린 뒤에 바꾼 구조를 그대로 남긴 기록이다.
우리는 홈페이지에 지역·업종별 데이터 리포트를 올리고, 그 리포트를 네이버 블로그용 원고로 다시 써서 발행해 왔다. 2026년 9월 15일까지 블로그 발행은 사람이 손으로 했다. 그날 낮에 발행 도구를 만들어 두 번째 원고를 편집기에서 조립하고 그림 수·표 수·순서 검증까지 확인했고, 그날 밤 "크론 배선을 깔고 자동으로 돌아가게 하라"는 지시가 내려왔다. 그때까지 예약 실행 설정 파일 317번째 줄의 주석은 "발행은 사람 승인 대상이라 크론에 넣지 않는다"였다. 이 주석을 지우는 순간부터, 사람이 매일 눈으로 하던 확인을 기계가 대신해야 했다.
블로그로 나가야 할 이유는 숫자로 분명했다. 같은 날 집계에서 홈페이지 리포트 화면의 외부 방문은 16일 동안 51회였고, 리포트 하단 상담 폼 제출은 0건이었다. 방문이 이 정도면 폼 전환율이 1%라도 기대 제출은 1건이 안 된다. 폼이 약한지 판정할 분모조차 없었으니, 이미 있는 원고를 네이버라는 다른 유통 경로로 내보내는 일이 순서상 먼저였다.
비용으로 바꾸면 이렇다. 블로그 글 한 편을 편집기에 조립하는 데 약 10분이 걸린다. 사람이 매일 이 10분을 쓰거나, 아니면 발행이 멈춘다. 무인화의 목표는 하루 최소 1편이 사람 손 없이 나가고, 실패하면 알림이 오고, 이상하면 스스로 멈추는 상태였다. 마지막 조건, 이상하면 스스로 멈추는 장치를 처음에는 가볍게 봤다.
처음 잰 숫자: 원고 재고 169편, 새 리포트 0편
크론을 설계하며 원고 재고부터 셌다. 블로그용으로 다시 쓴 리포트 원고는 169편이 있었다. 하루 1편씩 내면 한동안 걱정할 필요가 없어 보이는 숫자였다.
원고의 원천인 홈페이지 리포트 쪽은 사정이 달랐다. 리포트도 무인 발행 크론이 하루에 여러 번 돌고 있었는데, 9월 15일에는 3회차가 모두 0편이었다. 로그에 남은 사유는 셋 다 "미사용 질문 0건"이었다. 리포트는 아직 쓰지 않은 질문 하나로 한 편을 만드는 구조라, 질문 목록이 바닥나면 새 리포트도 나오지 않는다. 질문 목록을 늘리는 일은 어떤 주제를 다룰지 정하는 사업 판단에 묶여 결정을 기다리는 중이었다.
반대편에 다른 숫자가 있었다. 같은 회사의 기술블로그는 9월 7일 이후 매일 4~6편씩 새 글이 나오고 있었다. 당시 기술블로그 피드에 66편이 있었고, 자동매매·주식 주제 4편을 빼면 62편이었다. 이 숫자를 처음부터 블로그 원고 공급원으로 보지는 않았다. 기술블로그는 홈페이지에만 싣는 글이라고 생각했기 때문이다.
노출은 아직 재지 않았다. 측정 계획만 있었다. 네이버 서치어드바이저(네이버의 웹사이트 관리 도구)에서 첫 2~3편의 색인 반영과 노출을 보고, 9월 22일쯤 발행 간격을 다시 정한다는 계획이었다. 이 계획이 다음 절의 두 번째 가설이다.
세운 가설: 재고가 있으니 하루 1편, 노출은 서치어드바이저로 본다
처음 세운 가설은 둘이었다. 첫째는 공급 가설이다. 원고 169편이 쌓여 있으니 공급은 당분간 문제가 아니고, 하루 1편 간격으로 시작하면 된다. 둘째는 측정 가설이다. 서치어드바이저에서 첫 2~3편의 색인과 노출을 확인하면 간격을 늘릴지 줄일지 판단할 수 있다.
원고 169편이면 당분간 공급 걱정은 없다. 하루 1편으로 시작하고, 첫 2~3편의 서치어드바이저 색인·노출을 보고 간격을 조정한다.
하루 1편이라는 숫자에도 단서가 붙어 있었다. 처음 기록에는 이 값을 대표가 정한 값처럼 적었다가, 같은 날 "결정이 아니라 시작 기본값"으로 고쳐 적었다. 정해진 근거가 없는 숫자를 결정처럼 적어 두면, 나중에 바꿀 때마다 누군가의 승인을 다시 받아야 하는 숫자가 되기 때문이다.
크롬 쪽에도 가설이 하나 있었다. 크론은 사람의 작업 창이 받는 포트 번호를 물려받지 못하므로, 크론 전용 고정 포트 9250과 그 전용 크롬 프로필을 쓰면 다른 작업과 부딪히지 않는다고 봤다. 공용 포트 9222는 지식인 답변과 캡차 처리 크론이 함께 써서 창이 서로 밀리고 있었다. 이 가설이 어떻게 깨졌는지는 크롬이 옆 작업에 꺼진 이유에 따로 정리했고, 이 글에서는 결과만 짧게 다룬다.
가설은 어디서 틀렸나?
측정 가설이 먼저 깨졌다. 같은 날 밤 23시, 서치어드바이저는 우리 도메인을 등록해서 보는 도구라 blog.naver.com 아래에 있는 글의 노출은 잴 수 없다는 지적이 나왔다. 확인해 보니 맞았다. 9월 22일까지 기다렸어도 판정할 숫자는 나오지 않았을 것이고, 그동안 크론은 노출 여부를 모른 채 매일 발행했을 것이다.
그래서 측정 대상을 바꿔 직접 쟀다. 서치어드바이저 대신, 손으로 발행한 두 글의 전체 제목을 네이버 블로그 검색에 넣었다. 두 글 모두 발행 3시간 안에 검색 결과에 떴다. 이 확인은 사람이 손으로 한 번 했지만, 같은 방법이면 크론이 매 회차 스스로 반복할 수 있다. 측정 수단이 생긴 자리다.
공급 가설은 숫자를 다시 읽자마자 무너졌다. 169편은 재고이지 공급이 아니다. 원고는 리포트에서만 나오는데 새 리포트가 0편이면, 재고는 매일 1편씩 줄기만 한다. 측정이 생겨 발행 간격을 하루 2편으로 올리면 더 빨리 준다. 처음에 이 숫자를 보고 안심한 이유는 들어오는 쪽 숫자(3회차 0편)를 나가는 쪽 숫자(169편)와 나란히 놓지 않았기 때문이다.
크롬 가설도 틀렸다. 크론 전용 크롬에 22:02에 로그인했는데, 옆 세션이 화면 조작 도구를 한 번 부르자 22:03:41에 그 크롬이 다시 켜졌고 조립 중이던 탭이 사라졌다. 화면 조작 도구의 정리 기능이 살려 둘 크롬을 9222~9241 포트 대역의 소유자로만 판단해, 대역 밖의 9250 크롬을 주인 없는 창으로 보고 강제 종료했다. 전용 포트를 쓰면 안전하다는 가정은, 다른 누군가가 그 포트를 "모르는 창"으로 취급하는 순간 성립하지 않았다.
진짜 원인은 무엇이었나: 확인 대상과 확인 수단이 서로 다른 곳에 있었다
세 가설이 틀린 이유를 나란히 놓으면 공통점이 하나 보인다. 확인하려는 대상과 확인 수단이 서로 다른 시스템에 있었다. 노출을 확인하려는 대상은 blog.naver.com의 글인데 수단은 우리 도메인용 도구였다. 공급을 확인하려는 대상은 리포트의 질문 목록인데 우리가 센 숫자는 블로그 원고 재고였다. 크롬을 지키려는 대상은 9250 크롬인데 정리 기능이 보는 범위는 9222~9241이었다.
사람이 매일 손으로 발행할 때는 이 차이가 드러나지 않는다. 원고가 바닥나면 쓰는 사람이 먼저 알고, 검색에 안 뜨면 다음 날 검색해 보다가 알고, 크롬이 꺼지면 화면에서 본다. 크론은 그 눈이 빠진 상태로 같은 일을 반복한다. 그래서 무인화는 발행 동작만 옮기는 일이 아니라, 사람이 무심코 하던 확인을 각각 기계가 볼 수 있는 숫자로 바꾸는 일이었다.
크롬 쪽은 처음 겪는 사고도 아니었다. 2026년 7월 23일부터 25일까지 지식인 답변 발행 크론이 3일 연속 전량 실패했다. 초안 8건 중 발행은 0건이었고, 로그는 매번 "네이버 로그인 만료"라고 진단했다. 실제 원인은 다른 작업 창이 화면 조작 도구를 부를 때마다 발행용 9222 크롬이 정리돼 로그아웃된 데 있었다. 그때는 보호할 포트 목록에 9222 하나를 고정으로 넣어 막았고, 기록에 "두 번째로 오래 살아야 하는 크롬이 생기면 같은 파일을 다시 고쳐야 한다"는 단서를 남겼다. 9250은 정확히 그 두 번째였다. 포트 번호를 하나씩 등록하는 방식으로는 같은 사고가 크롬이 늘 때마다 반복된다.
정리하면 진짜 원인은 크롬 조작 기술이 아니라 확인의 위치였다. 노출은 블로그 검색 결과에서, 공급은 원고를 만드는 원천에서, 크롬 생존은 실제 디버그 소켓에서 재야 했다. 아래 조치는 전부 이 세 확인을 제자리로 옮긴 작업이다.
조치: 노출 감시, 두 번째 원고 공급원, 크론 전용 크롬
먼저 한 회차의 순서를 고정했다. 크론이 정해진 시각에 발행 스크립트를 부르면 다음 순서로 진행한다. 일시정지 파일이 있으면 바로 끝낸다. 오늘 이미 발행한 글이 있으면 끝낸다. 로그인 유지 쿠키로 네이버 로그인을 확인한다. 아직 발행하지 않은 다음 원고를 고르고, 그림이 없으면 굽는다. 편집기에서 조립하고, 실패하면 새 편집기로 1번만 다시 조립한다. 그림 수·표 수·순서 검증을 통과할 때만 발행하고, 로그인하지 않은 상태로 글 주소를 열어 응답 200을 확인한 뒤 발행 기록 파일에 적고 슬랙 채널로 알린다. 실패는 운영 경보 채널에도 사본을 남긴다.
노출 확인은 매 회차에 넣었다. 9월 22일 한 번 판정하는 계획을 버리고, 회차마다 최근 3편을 대상으로 발행 후 2시간이 지났는데도 전체 제목 검색에 없으면 크론을 자동으로 멈추고 알림을 보낸다. 손 발행 두 글이 3시간 안에 떴다는 실측이 이 기준의 근거다. 측정이 생겼으므로 상한도 하루 2편으로 올렸다. 이 역시 대표 결정이 아니라 기본값으로 적었다. 이 감시가 실제로 무엇을 잡았는지는 노출 감시 기록에 있다.
공급은 두 번째 원천을 붙여 풀었다. 네이버 블로그에 “기술블로그” 카테고리(2번)를 새로 만들고, 발행 스크립트가 기술블로그 피드를 직접 읽어 원고를 만들게 했다. 원고는 본문 전체가 아니라 요약이다. 첫 문단과 소제목별 앞 두 문장을 모으고 원문 링크를 붙였다. 표지 그림은 기술블로그 그림 생성기로 굽고, 원문에 그림이 있으면 1장을 더한다. 자동매매·주식처럼 블로그에 싣지 않을 주제는 링크드인 배포 스크립트가 이미 가진 제외 목록을 그대로 불러 쓴다. 같은 목록을 두 곳에 복사하면 언젠가 한쪽만 고쳐지기 때문이다.
크론 시각도 원천별로 나눴다. 처음에는 리포트를 10시 40분, 기술블로그를 16시 40분에 두고 원천별 하루 1편, 합계 2편으로 잡았다. 같은 날 밤 지시로 기술블로그를 6시 40분으로 옮겼다. 리포트 10시 40분 회차와 겹치지 않고, 첫 무인 발행이 바로 다음 날인 9월 16일 오전에 나오는 시각이다.
크롬은 판정 기준을 바꿨다. 정리 기능이 살려 둘 크롬을 "9222~9241 포트 소유자"가 아니라 "디버그 소켓을 가진 chrome.exe 전부"로 판단하게 고쳤다. 크론 전용 포트 번호는 설정 파일 한 곳에만 두고 다른 코드는 그 값을 불러 쓴다. 비상 정지는 파일 하나를 만드는 것으로 충분하게 했고, 바꾸기 전의 예약 실행 설정은 따로 백업했다.
검토했다가 버린 안도 남긴다.
- 기술블로그 본문 전체를 네이버로 옮기기: 원문 사이트 유입이 줄고 같은 글이 두 곳에 생겨 기각
- 네이버 계정을 새로 만들어 분리: 새 계정은 신뢰를 0부터 쌓아야 해서 기각
- 로그인된 기존 크롬 프로필(4.4GB) 복사: 무인 재로그인 스크립트가 이미 있어서 기각
- 공용 포트 9222 사용: 다른 크론과 창을 나눠 써야 해서 기각
- 작업 창용 포트 대역 안의 번호 고정: 그 포트가 비면 다른 작업 창이 포트와 로그인 프로필을 물려받아서 기각
재측정 결과는 어떻게 나왔나?
크롬부터 다시 쟀다. 수리 직후 정리 기능이 살려 둘 크롬으로 7개를 잡았고 종료 대상은 0개였다. 크롬 기동 유예 90초가 지난 뒤 작업 창 없이 정리 기능을 따로 돌려도, 9250 크롬은 같은 프로세스 번호 163736을 그대로 유지했다. 옆에서 화면 조작 도구를 불러도 크론 전용 크롬이 꺼지지 않는다는 뜻이다.
카테고리 선택은 실제 발행 없이 확인했다. 빈 편집기를 열어 발행 창에서 “기술블로그” 카테고리를 고르는 동작까지 통과시키고 발행 버튼은 누르지 않았다. 공급 쪽은 숫자가 바뀌었다. 리포트 원고 169편은 여전히 줄기만 하지만, 기술블로그는 매일 4~6편씩 새 원고 재료가 들어오는 원천이 됐다.
그리고 이틀 뒤, 이 글에서 정한 원고 형식 하나가 뒤집혔다. 9월 17일, 네이버가 외부 링크가 있는 글을 노출에서 불리하게 다루는 경향이 강하다는 판단으로 원고의 홈페이지 링크를 전부 빼기로 했다. 기술블로그 원고의 "요약 + 원문 링크"도 "요약 + 회사명 문장 + 네이버에 이미 발행한 기술블로그 글끼리의 상호 참조"로 바꿨다. 원고 181편을 다시 만든 뒤 홈페이지 주소가 남은 원고는 0편이었고, 발행 스크립트에 넣은 외부 링크 차단 장치는 옛 원고 181편 중 181편을 막고 새 원고 181편 중 0편을 막았다. 관련 테스트 8건도 통과했다.
노출 감시는 곧 쓸모를 증명했다. 9월 19일 이미 나간 글 7편을 고쳐 다시 발행했더니, 9월 19일 12시 23분·15시 31분과 9월 20일 9시 5분 세 차례 측정에서 7편 모두 전체 제목 검색에서 사라졌다. 블로그 전체 8편 중 1편만 노출을 유지했다. 이 숫자가 아니었다면 크론은 매일 새 글을 낸 뒤 기존 글의 관련 글 목록을 고쳐 다시 발행하는 동작을 계속했을 것이다. 그 자동 재발행은 기본값을 꺼짐으로 바꿨다.
측정 도구 자체가 틀린 적도 있다. 9월 18일 상위 노출 글과 우리 글의 구조를 같은 자로 재는 측정기를 만들었는데, 첫 버전은 상위 노출 글 9건이 전부 소제목이나 인용구를 쓴다고 셌다. 편집기의 컴포넌트형 소제목을 세지 못하는 결함을 고쳐 다시 재니 9건 중 7건이었다. 같은 측정에서 우리가 발행한 5편은 소제목·인용구·구분선·링크 카드가 모두 0이었다. 숫자를 얻은 뒤에도 그 숫자를 만든 도구를 한 번 더 의심해야 했다.
이 결과도 한 번 정정했다. 노출을 유지한 1편은 손대지 않은 글이라고 봤는데, 실제로는 9월 18일 구조 개편 때 이미 한 번 수정 발행된 글이었다. 그러니 "수정하면 검색에서 영구히 빠진다"는 결론은 과했다. 회복에 21시간보다 오래 걸리는지, 한 시간 안에 7편을 몰아 고친 게 문제인지, 제목까지 바꾼 게 문제인지는 아직 가르지 못했다.
남는 한계: 무엇을 아직 모르나?
무인 발행은 돌기 시작했지만 남은 한계가 분명하다. 일부는 운영 비용이고, 일부는 아직 측정하지 못한 질문이다.
- 시간: 한 회차 조립이 약 10분 걸린다. 크론 시각을 원천별로 떨어뜨려 둔 이유이기도 하다
- 로그인: 캡차나 2차 인증이 걸리면 그날은 실패 알림만 남고 사람이 1번 손을 대야 한다
- 성과: 발행이 쌓여 매출로 이어지는지는 성과 지표 5개로 10월 초에 판정하기로 했고, 9월 15일 기준으로는 전부 출발값이었다
- 공급: 리포트 질문 목록은 여전히 사업 판단을 기다린다. 기술블로그가 멈추면 공급은 다시 재고 소모로 돌아간다
- 노출: 수정 발행 7편이 사라진 원인을 셋 중 하나로 가르는 실험을 아직 하지 않았다
- 유입: 외부 링크를 빼면서 네이버에서 홈페이지로 넘어오는 경로를 포기했다. 링크드인·X에는 원문 링크를 유지한다
로그인 실패 알림도 원인을 곧바로 말해 주지 않는다. 9월 19일 10시 40분 회차는 실패로 끝났는데, 처음에는 크롬 원격 중계의 응답 대기 시간이 문제로 보였다. 실제로는 발행용 크롬에 열려 있던 빈 새 탭 하나가 페이지 활성화 요청에 응답하지 않아 로그인 확인이 끝없이 기다린 것이었다. 중계 대기 시간은 증상이었다. 응답 없는 탭을 정리하는 단계를 로그인 스크립트에 넣었지만, 알림 한 줄만 보고 원인을 짚기는 여전히 어렵다.
그리고 이 기록에는 노출 감시가 크론을 몇 번 멈췄는지, 기술블로그 원고가 실제로 몇 편 나갔는지 같은 이후 숫자가 없다. 9월 15일 결정 시점과 이틀 뒤 정정까지의 기록이라, 그 뒤의 누적 성과는 따로 재야 한다.
비슷한 자동 발행을 만든다면 무엇부터 확인해야 하나?
블로그든 뉴스레터든 발행을 크론에 넘기기 전에 세 가지를 먼저 적어 보길 권한다. 첫째, 원고 재고가 아니라 새 원고가 들어오는 속도다. 재고가 169편이어도 들어오는 숫자가 0편이면 공급이 아니라 소모다. 둘째, 노출을 재는 도구가 정말 그 글이 사는 곳을 보는지다. 우리 도메인용 도구는 남의 플랫폼에 올린 글을 보지 못했다. 셋째, 자동화 크롬처럼 오래 살아야 하는 프로세스를 다른 작업의 정리 기능이 어떤 기준으로 판단하는지다.
세 질문 모두 사람이 손으로 할 때는 묻지 않아도 되던 질문이다. AI업무자동화로 반복 업무를 넘길 때 실제로 시간이 드는 쪽은 동작을 옮기는 일보다 이런 확인을 숫자로 바꾸는 일이었다. 사내 콘텐츠 발행이나 반복 업무를 무인화하는 구조가 궁금하면 상담으로 문의할 수 있다.