매크로프로그램 무인 발행에서 무엇이 문제였나
매크로프로그램으로 네이버 블로그 발행을 자동화할 때 문제는 글 품질이 아니라 발행용 크롬이 중간에 죽는 데 있었습니다. 2026년 9월 15일 낮에 저희는 발행 스크립트를 새로 만들었고, 두 번째 원고를 편집기에서 조립하고 검증하는 데까지 확인했습니다. 그날 밤 대표가 “블로그 발행은 예약 실행으로 자동으로 돌아가게”라고 지시했습니다. 그전까지 예약 작업 목록(crontab)의 317번째 줄에는 “발행은 사람이 승인하는 일이라 예약 실행에 넣지 않는다”는 주석이 있었고, 이 지시로 그 원칙을 풀었습니다.
무인 발행 한 회차는 단계가 많습니다. 일시정지 플래그를 확인하고, 오늘 이미 발행한 글이 있으면 끝냅니다. 없으면 로그인 유지 쿠키로 네이버에 로그인하고, 아직 안 나간 원고를 하나 꺼냅니다. 그림이 없으면 굽고, 편집기에서 본문을 조립합니다. 조립이 실패하면 새 편집기를 열어 한 번 더 조립합니다. 그림 수·표 수·순서를 검증해 통과할 때만 발행하고, 로그인하지 않은 상태로 글 주소가 HTTP 200을 돌려주는지 확인한 뒤 발행 목록 파일에 적고 슬랙 채널로 알립니다.
이 모든 단계가 크롬 창 하나 위에서 돌아갑니다. 한 회차 조립에 약 10분이 걸리므로, 그 10분 안에 크롬이 꺼지면 회차 전체가 날아갑니다. 사람이 앉아 있으면 다시 누르면 그만이지만, 새벽이나 오전에 혼자 도는 예약 작업에서는 그날 발행이 0편으로 끝납니다. 비용은 시간보다 신뢰 쪽에 있었습니다. 매일 한 편씩 나간다는 전제가 깨지면 예약 실행으로 옮긴 이유 자체가 사라집니다.
네이버 블로그 글 구조를 자동으로 맞춘 이야기는 네이버 블로그 링크 카드 자동 발행 글에 따로 적었습니다. 이 글은 그 앞단, 발행기가 올라탈 크롬을 어떻게 살려 두느냐를 다룹니다.
처음 잰 숫자: 22:02 로그인, 22:03:41 재기동
예약 실행은 작업 창이 받는 포트 번호를 물려받지 못합니다. 그래서 발행 전용으로 대역 밖 고정 포트 9250과 그 전용 프로필 chrome-debug-9250을 따로 두었습니다. 공용 포트 9222는 지식iN 답변·캡차 처리 예약 작업이 같이 쓰고 있어서, 함께 쓰면 창이 서로 밀립니다.
9250 크롬에서 22:02에 로그인을 마쳤습니다. 이어서 원고 조립을 시작했는데, 22:03:41에 크롬이 다시 켜졌고 조립 중이던 편집기 탭이 사라졌습니다. 로그인부터 재기동까지 2분이 채 안 걸렸습니다. 그 사이 우리 발행 스크립트는 크롬을 닫는 명령을 한 번도 보내지 않았습니다.
측정 방법은 단순했습니다. 발행 스크립트 로그의 로그인 완료 시각, 크롬 프로세스의 새 기동 시각, 그 사이 같은 PC에서 화면 조종 도구를 부른 다른 작업 창의 호출 시각을 나란히 놓았습니다. 숫자는 두 개뿐이었지만 순서가 분명했습니다.
포트를 고를 때 버린 선택지도 적어 둡니다. 작업 창에 나눠 주는 대역 안의 포트 하나를 발행용으로 고정하는 방법은, 그 포트가 비는 순간 다른 작업 창이 그 포트와 로그인 프로필을 그대로 물려받을 수 있어서 버렸습니다. 로그인이 이미 된 9224 프로필(4.4GB)을 통째로 복사하는 방법도 있었지만, 로그인 상태 유지를 체크해 영속 쿠키를 받는 무인 재로그인 스크립트가 이미 있어서 굳이 큰 프로필을 옮길 이유가 없었습니다.
이렇게 고른 9250은 작업 창 대역과 겹치지 않고 다른 예약 작업과도 창을 나눠 쓰지 않는 자리였습니다. 적어도 설계 단계에서는 이 크롬을 건드릴 프로그램이 없다고 봤습니다. 22:03:41의 재기동은 그 판단이 틀렸다는 첫 신호였습니다.
세운 가설: 로그인이 풀린 것인가?
첫 가설은 로그인 만료였습니다. 근거가 있었습니다. 2026년 7월 23일부터 25일까지 3일 연속, 밤 11시 지식iN 발행 예약 작업이 초안 8건 중 0건을 발행했고, 그때 로그는 매번 “네이버 로그인 만료”로 진단했습니다. 네이버 기본 로그인은 “로그인 상태 유지”를 체크하지 않으면 세션 쿠키만 발급해서, 크롬이 다시 켜지면 곧바로 로그아웃 상태가 됩니다.
두 번째 가설은 “7월에 이미 고친 문제”라는 생각이었습니다. 7월 사고의 근본 원인은 다른 작업 창이 자기 포트로 화면 조종 도구를 부를 때 정리 단계가 “내 포트가 아니면 꺼도 안전하다”고 판단해 9222 발행 크롬까지 꺼 버린 데 있었습니다. 그때 정리 단계의 보호 목록에 9222를 고정으로 넣었고, 재기동 뒤에도 로그인이 살아 있는지 끝까지 검증했습니다. 그래서 같은 종류의 사고는 막혔다고 믿고 있었습니다.
- 가설 1: 9250 크롬의 네이버 로그인이 풀려서 편집기 탭이 튕겨 나갔다
- 가설 2: 다른 작업 창이 크롬을 끄는 문제는 7월 수리로 이미 막혔다
- 가설 3(나중에 세운 가설): 정리 단계의 보호 기준이 새 포트 9250을 모른다
가설 2를 믿은 데는 이유가 있었습니다. 7월 수리 때 저희는 다른 작업 창이 화면 조종 도구를 아무리 불러도 9222 발행 크롬이 로그아웃되지 않는다는 점을 처음부터 끝까지 다시 돌려 확인했습니다. 같은 수리에서 하트비트 점검도 고쳤습니다. 이전 점검은 페이지 글자 안에 특정 문자열이 있는지만 보는 가짜 로그인 확인이었고, 존재하지 않는 재로그인 명령을 부르고 있었습니다. 이 둘을 실제 로그인 상태를 판정하고 무인으로 복구하는 스크립트 호출로 바꿨습니다. 검증까지 마친 수리였기 때문에, 9월의 증상을 보고도 정리 단계를 의심하는 데 시간이 걸렸습니다.
가설이 틀린 지점은 어디였나?
가설 1은 시각이 맞지 않았습니다. 22:02에 로그인을 확인한 직후 크롬 프로세스 자체가 새로 떴습니다. 로그인이 풀려서 탭이 튕긴 경우라면 크롬 프로세스는 그대로 살아 있고 페이지만 로그인 화면으로 바뀝니다. 저희가 본 장면은 프로세스가 죽고 다시 태어난 모습이었습니다. 로그인 만료는 크롬이 죽은 결과로 따라온 증상이었고, 원인이 아니었습니다.
가설 2는 더 아프게 틀렸습니다. 7월 수리는 보호 목록에 9222라는 숫자 하나를 박아 넣은 방식이었습니다. 당시 결정 기록에도 단점이 적혀 있었습니다. 보호 포트가 하드코딩 상수라서 두 번째 장수 프로필이 필요해지면 같은 파일을 다시 고쳐야 한다는 내용입니다. 그때는 장수 프로필이 1개뿐이라 설정 파일로 빼는 일을 과설계로 보고 미뤘습니다. 9월에 저희는 바로 그 두 번째 장수 프로필, 9250을 만들었습니다.
돌아보면 7월의 수리는 사고 하나를 막았지 사고의 종류를 막지는 못했습니다. “이 포트는 지켜라”는 목록 방식은 새 예약 작업이 새 포트를 쓸 때마다 목록을 고쳐야 하고, 고치는 사람이 목록의 존재를 기억해야 합니다. 9월의 저희는 기억하지 못했습니다.
두 가설을 지우고 나니 가설 3이 남았습니다. 크롬을 끈 프로그램은 같은 PC에 있고, 그 프로그램은 9250이라는 숫자를 모릅니다. 이를 확인하려면 로그를 더 모을 필요 없이, 화면 조종 도구가 시작할 때 도는 정리 단계 코드를 직접 열어 보면 됐습니다.
진짜 원인: 포트 대역으로 크롬의 주인을 판정했다
정리 단계 코드를 열어 보니 원인이 한 줄에 있었습니다. 화면 조종 도구는 시작할 때 남은 크롬을 치우는 정리 단계를 돌리는데, 이 단계는 살려 둘 크롬을 “9222~9241 포트 소켓을 가진 크롬”으로만 잡고 있었습니다. 작업 창에 나눠 주는 포트 대역이 9222부터 9241까지였기 때문입니다. 대역 밖 9250에서 살아 있는 발행 크롬은 이 기준에 들지 않았고, 정리 단계는 그 크롬을 주인 없는 창으로 보고 Stop-Process -Force로 강제 종료했습니다.
결과적으로 어느 작업 창이든 화면 조종 도구를 한 번만 불러도 9250 크롬이 죽었습니다. 22:02 로그인, 옆 작업 창의 호출, 22:03:41 재기동, 조립 중 탭 소멸이라는 순서가 정확히 이 동작을 보여 줍니다. 발행 스크립트 쪽에는 잘못이 없었고, 같은 PC를 함께 쓰는 다른 프로그램이 청소를 너무 넓게 하고 있었습니다.
이 결함이 무서운 이유는 증상이 원인과 멀리 떨어져 나타나는 데 있습니다. 발행 로그에는 “탭이 사라졌다”거나 “로그인이 안 된다”만 남고, 크롬을 끈 프로그램의 이름은 어디에도 남지 않습니다. 7월에도 3일 동안 로그는 매번 로그인 만료를 가리켰습니다.
7월과 9월의 사고를 나란히 놓으면 구조가 같습니다. 여러 작업 창이 같은 PC에서 화면 조종 도구를 병렬로 쓰는 일은 정상 운영입니다. 그 정상 사용이 다른 목적으로 오래 떠 있어야 하는 예약 작업 전용 크롬을 부수적으로 망가뜨립니다. 7월에는 “내 포트가 아니면 안전하다”는 판정이, 9월에는 “작업 창 대역 안에 있어야 주인이 있다”는 판정이 같은 결과를 냈습니다. 판정의 문구만 바뀌었고, 크롬의 주인을 포트 번호로 추측한다는 점은 그대로였습니다.
조치: 판정 기준을 포트 번호에서 디버그 소켓으로 바꿨다
고친 곳은 판정 기준 하나입니다. 살려 둘 크롬을 “9222~9241 포트 소켓 소유자”가 아니라 “디버그 소켓을 가진 chrome.exe 전부”로 바꿨습니다. 디버그 포트를 열고 떠 있는 크롬은 누군가 원격으로 조종하려고 띄운 크롬입니다. 그 주인이 작업 창이든 예약 작업이든, 정리 단계가 함부로 끌 대상이 아닙니다.
실패했을 때의 경로도 이때 함께 정했습니다. 편집기 조립이 실패하면 새 편집기를 열어 딱 한 번 다시 조립합니다. 그림 수·표 수·순서 검증을 통과하지 못하면 발행 버튼을 누르지 않습니다. 실패는 콘텐츠 알림 채널과 별도로 운영 경보 채널에도 사본을 남깁니다. 크롬이 죽는 문제를 고친 뒤에도 회차가 실패할 수 있다는 전제로, 실패가 조용히 묻히지 않게 하는 쪽에 무게를 뒀습니다.
7월처럼 보호 목록에 9250을 하나 더 넣는 방법도 있었습니다. 그렇게 했다면 오늘은 고쳐지지만, 세 번째 예약 작업이 세 번째 포트를 쓰는 날 같은 사고가 다시 납니다. 포트 번호 범위를 판정에서 아예 빼면, 앞으로 어떤 포트에 어떤 장수 크롬을 띄워도 이 정리 단계는 손대지 않습니다.
예약 실행 쪽 설정도 함께 정리했습니다. 처음 예약은 매일 10시 40분 하루 1편이었습니다. 대표가 “카테고리 하나 더 만들어 기술블로그도 올라가면 좋겠다”고 해서 원고 출처를 둘로 나눴습니다. 리포트 원고는 10시 40분, 기술블로그 원고는 처음 16시 40분으로 잡았다가 같은 날 밤 대표 지시로 06시 40분으로 옮겼습니다. 출처별 하루 1편, 합쳐 하루 2편이 상한입니다.
출처를 나눈 데도 숫자가 있습니다. 리포트 무인 발행은 9월 15일 3회차 모두 “미사용 질문 0건”으로 0편을 냈고, 쌓아 둔 리포트 원고 169편은 소모만 하는 처지였습니다. 반면 기술블로그는 9월 7일 이후 매일 4~6편씩 새 글이 나왔습니다. 피드 66편 가운데 자동매매·주식 주제 4편을 빼면 62편이 남았습니다. 기술블로그 원고는 본문 전체를 옮기지 않고 리드와 소제목별 앞 두 문장만 요약해 싣기로 했습니다. 전문을 옮기면 원문 유입이 줄고 같은 문서가 두 곳에 생기기 때문입니다.
끄는 장치도 하나 두었습니다. 정해진 경로에 일시정지 플래그 파일 하나를 만들면 다음 회차부터 발행을 건너뜁니다. 예약 작업 목록은 바꾸기 전에 백업 파일로 남겼습니다.
재측정 결과는 어떻게 나왔나?
수리 직후 정리 단계를 다시 돌렸습니다. 살려 둘 크롬(roots)으로 7개가 잡혔고 종료 대상은 0개였습니다. 수리 전에는 9250이 이 자리에서 종료 대상으로 잡혔습니다.
한 번으로 끝내지 않았습니다. 정리 단계에는 방금 뜬 크롬을 건드리지 않는 기동 유예 시간 90초가 있습니다. 수리 직후의 0개는 이 유예 덕분일 수도 있어서, 90초가 지난 뒤 어느 작업 창에도 속하지 않은 호출로 정리 단계를 다시 돌렸습니다. 9250 크롬의 프로세스 번호(PID) 163736이 정리 전후로 그대로 남았습니다. 프로세스 번호가 같다는 말은 크롬이 꺼졌다가 다시 뜬 적이 없다는 뜻입니다.
발행 쪽에서도 결과를 확인했습니다. 9월 15일 밤 기준으로 두 글 모두 발행 후 3시간 안에 제목 전체로 블로그 검색을 하면 나왔습니다. 그리고 기술블로그 회차를 06시 40분으로 옮기면서 첫 무인 발행을 9월 16일 오전에 받도록 했습니다.
측정 도구도 하나 정정했습니다. 처음에는 네이버 서치어드바이저로 색인과 노출을 보고 첫 2~3편 뒤에 발행 간격을 정하려 했는데, 서치어드바이저는 우리 도메인용이라 blog.naver.com 글의 노출을 재지 못했습니다. 그래서 매 회차 최근 3편을 대상으로, 발행 2시간이 지났는데 제목 전체 검색에 안 나오면 발행을 자동으로 멈추고 알리는 검사를 넣었습니다.
노출을 빠르게 확인한 덕에 발행 상한도 조정했습니다. 처음에는 하루 1편을 기본값으로 두고 일주일 뒤 판정할 계획이었는데, 두 글이 3시간 안에 검색에 나온 것을 보고 상한을 하루 2편으로 올렸습니다. 이 값은 실측으로 바꾼 기본값이고, 노출 감시가 언제든 발행을 멈출 수 있다는 전제 위에 있습니다. 기술블로그용 네이버 카테고리 선택도 빈 편집기에서 발행 버튼을 누르지 않은 채 먼저 확인했습니다.
남는 한계: 크롬은 살렸지만 발행이 늘 성공하지는 않는다
크롬이 죽는 문제는 풀렸지만 무인 발행이 매일 성공한다는 보장은 아직 없습니다. 한 회차 조립에 약 10분이 걸리고, 로그인에 캡차나 2차 인증이 걸리면 그날은 실패 알림만 남습니다. 그때는 사람이 한 번 손을 대야 합니다.
같은 종류의 다른 원인도 계속 나왔습니다. 9월 19일 10시 40분 발행이 실패했을 때 처음에는 크롬 중계 프로그램의 타임아웃을 의심했는데, 진짜 원인은 발행 크롬에 열린 빈 새 탭 하나가 Page.enable 명령에 응답하지 않아 로그인 확인이 무한히 기다린 데 있었습니다. 중계 타임아웃은 증상이었습니다. 크롬을 살려 둔다고 크롬 안의 탭까지 건강하다는 뜻은 아닙니다.
자동 재발행 단계를 끈 사정도 적어 둡니다. 글끼리 서로 참조하게 하려고, 새 글 한 편을 발행할 때마다 기존 글 최대 3편의 관련 글 목록을 고쳐 다시 발행하도록 만든 적이 있습니다. 편당 약 3~4분이 더 들었고, 네이버가 잦은 수정을 어떻게 보는지는 실측이 없었습니다. 아래의 검색 소실이 이 우려를 현실로 보여 줬습니다.
노출 쪽 한계도 남았습니다. 9월 19일 밤 이미 나간 글 7편을 수정 발행했더니, 9월 19일 12:23·15:31, 9월 20일 09:05 세 번의 측정에서 7편 모두 제목 전체 검색에서 사라졌습니다. 블로그의 글 8편 가운데 손대지 않은 것으로 보였던 1편만 남았습니다. 처음에는 “수정한 글은 검색에 돌아오지 않는다”로 결론을 냈는데, 나중에 그 1편도 9월 18일 구조 개편 때 이미 한 번 수정 발행했다는 기록을 찾았습니다. 회복에 21시간보다 오래 걸리는지, 한 시간 안에 7편을 몰아 고친 탓인지, 제목까지 바꾼 탓인지는 아직 가르지 못했습니다. 지금은 발행 뒤 기존 글을 자동으로 다시 고치는 단계를 기본으로 꺼 두었습니다.
마지막으로, 블로그 발행이 매출로 이어지는지는 이 수리와 별개의 질문입니다. 당시 성과 지표 5개는 모두 기준선 상태였습니다. 크롬을 살린 일은 매일 발행할 수 있는 조건을 만든 데까지입니다.
비슷하게 여러 자동화가 한 PC의 브라우저를 나눠 쓰는 구조라면, 정리 코드가 무엇을 기준으로 “주인 없는 창”을 판정하는지 먼저 열어 보길 권합니다. 포트 번호나 이름 목록으로 판정하고 있다면 다음 자동화를 붙이는 날 같은 일이 생깁니다. 사내 업무 자동화를 이런 구조로 설계하는 일이 고민이라면 상담으로 이야기해 주세요.
정리 단계의 기준을 바꾼 데에도 대가가 있습니다. 이제 디버그 포트를 연 채 정말로 버려진 크롬이 남아 있으면, 정리 단계는 그 창도 치우지 않습니다. 포트 번호로 주인을 추측하던 방식은 살아 있는 창을 죽였고, 새 방식은 버려진 창을 남길 수 있습니다. 이 대가가 실제로 얼마나 쌓이는지는 아직 재지 않았습니다.