네이버 블로그 글 구조를 자동 발행으로 상위 노출 글처럼 바꾼 과정

네이버 블로그 글 구조를 자동 발행으로 어떻게 맞췄나

네이버 블로그에 자동으로 올린 글이 화면에서 소제목 없는 긴 글로 보였고, 원인은 소제목이 굵은 본문 문단으로 바뀌던 변환 코드 한 곳이었습니다. 소제목·인용구·구분선·링크 카드를 쓰는 구조로 바꾸고, 이미 올라간 7편을 모두 고쳐 다시 발행했습니다.

SGK 스튜디오는 발행하는 글을 마크다운 원고로 만들고, 네이버 글쓰기 화면을 무인으로 조작하는 발행 스크립트가 그 원고를 블로그에 올립니다. 원고에서 `## 소제목`이라고 적은 줄이 네이버 화면에서는 어떻게 보이는지 아무도 눈으로 확인하지 않은 채 5편이 나갔습니다.

2026년 9월 18일 대표가 올라간 글을 직접 보고 두 가지를 지적했습니다. 글 구조를 전혀 신경 쓰지 않은 듯하다는 점, 그리고 다른 글로 넘기는 링크를 본문에 문자로 적어 놓았다는 점입니다. 에디터가 제공하는 링크 첨부 기능을 써야 보기에도 깔끔하다는 말이었습니다.

이 글은 그 지적에서 시작해 원인을 찾고, 측정기까지 한 번 틀렸다가 고친 과정을 순서대로 적은 개선 기록입니다. 네이버 블로그 글 구조를 자동화하려는 마케팅 담당자나 개발자가 같은 함정을 피하도록 숫자와 실패까지 그대로 남겼습니다.

무엇이 문제였나: 5편 모두 구조 장치가 0이었다

문제는 글의 내용이 아니라 모양이었습니다. 검색 결과 위쪽에 노출되는 글은 소제목을 나누고 인용구로 요점을 세우는데, 우리 글은 화면에서 한 덩어리로 보였습니다.

이 결함이 오래 숨어 있었던 데는 이유가 있습니다. 발행 스크립트의 검증 단계에는 구조를 보는 항목이 없었습니다. 소제목이 소제목처럼 보이는지는 어디에서도 검사하지 않았고, 원고를 만드는 쪽도 발행하는 쪽도 상대가 확인하리라 여겼습니다.

독자 입장에서 보면 손해는 더 분명합니다. 긴 글을 훑어 읽는 사람은 소제목으로 어디를 읽을지 정합니다. 소제목이 본문과 같은 크기로 묻히면 훑을 곳이 없어 첫 화면만 보고 나가기 쉽습니다.

비용으로 치면 이미 발행한 글 5편을 통째로 다시 손봐야 하는 상황이었고, 앞으로 나갈 글도 같은 결함을 그대로 물려받을 참이었습니다. 실패율로 보면 발행한 5편 전부가 구조 기준에서 탈락이었습니다.

정리하면 문제의 크기는 세 가지로 잴 수 있었습니다. 이미 나간 글 5편이 구조 기준에서 0점이고, 같은 결함이 앞으로 나갈 글에도 반복되며, 이를 잡아낼 검사가 없다는 점입니다. 앞의 둘은 손을 보면 풀리지만 마지막은 검사를 새로 세워야 풀립니다.

처음 잰 숫자: 상위 노출 글 9건 중 7건이 소제목이나 인용구를 쓴다

감으로 고치지 않으려고 먼저 자를 만들었습니다. 측정 스크립트에 `--structure`라는 기능을 새로 붙여, 검색 결과 상위 글의 제목 길이·소제목 수·문단 길이 분포·인용구·구분선·링크 카드·이미지를 우리 글과 같은 잣대로 재게 했습니다.

검색어 3종을 골라 상위 노출 글 9건을 재 보니, 9건 중 7건이 소제목이나 인용구 중 하나 이상을 씁니다. 같은 자로 잰 우리 글 5편은 소제목·인용구·구분선·링크 카드가 전부 0이었습니다.

측정 방법을 정리하면 이렇습니다. 검색어 3종을 정해 네이버 검색 결과 상위 글 9건을 열고, 각 글에서 다섯 가지를 셉니다. 소제목(글자 크기로 키운 것과 컴포넌트로 만든 것 모두), 인용구, 구분선, 링크 카드, 이미지입니다. 우리 글은 같은 스크립트로 라이브 주소를 열어 같은 방식으로 셉니다. 자가 같아야 비교가 성립하기 때문입니다.

상위 글이 정답이라는 뜻은 아닙니다. 다만 같은 검색어에서 독자와 검색 엔진이 실제로 고른 글이 어떤 모양인지는 우리가 임의로 정할 수 없는 기준이라, 출발점으로 삼기에 가장 정직했습니다.

이 절의 표는 그래서 두 번 읽어야 합니다. 우리 글의 0은 정확한 값이지만, 상위 글의 7은 나중에 고친 값입니다. 처음 낸 9와 재측정으로 바로잡은 7의 차이가 곧 측정기 결함의 크기였습니다.

여기서 처음에는 다른 숫자가 나왔습니다. 측정기의 첫 버전은 9건 모두 구조 장치를 갖췄다는 9/9를 내놓았고, 저희는 그 숫자로 «상위 글은 예외 없이 구조를 쓴다»고 기록했습니다. 이 9/9는 나중에 틀린 값으로 판명됩니다. 뒤에서 자세히 적겠습니다.

세운 가설: 원고에 소제목이 없어서 그렇다

첫 가설은 단순했습니다. 글을 쓰는 쪽에서 소제목을 충분히 나누지 않았을 것이라고 보았습니다. 그렇다면 원고 생성기에 소제목을 더 많이 넣으라고 지시하면 풀릴 일이었습니다.

이 가설은 그럴듯했고, 그래서 위험했습니다. 원고 품질 문제로 보면 고칠 곳이 글쓰기 지시문이라 눈에 잘 띄고 손쉽습니다. 그래서 지시문을 고치기 전에 원고 파일부터 열어 보기로 했습니다.

확인 방법은 간단했습니다. 발행한 글 5편의 원고 파일에서 소제목 줄을 세고, 같은 글의 라이브 화면에서 소제목이 몇 개인지 셉니다. 원고에는 있는데 화면에 없다면 글쓰기의 문제가 아니라 변환의 문제입니다.

그런데 원고 파일을 열어 보니 소제목은 이미 있었습니다. 기술블로그 원고는 섹션이 8개에서 12개까지 나뉘어 있었고, 마크다운으로는 전부 `## 소제목` 형식이었습니다.

가설이 틀린 지점: 원고는 멀쩡했고 화면에서만 사라졌다

원고에 소제목이 있는데 화면에서 안 보인다면, 원고와 화면 사이에 변환 단계가 있다는 뜻입니다. 그 단계를 따라가 보니 변환 함수 `parse_markdown()`이 나왔습니다.

이 함수는 `## 소제목`을 `<p><b>…</b></p>`로 바꾸고 있었습니다. 굵은 글씨를 입힌 일반 문단입니다. 글자 크기가 본문과 같아서 화면에서는 소제목이 아니라 «굵게 쓴 본문 줄»로 보였습니다.

가설이 틀린 이유는 명확했습니다. 저희는 원고를 점검했고, 화면은 점검하지 않았습니다. 원고가 맞아도 화면이 틀릴 수 있다는 단순한 사실을 놓친 것입니다.

실무에서 자주 겪는 함정이기도 합니다. 자동 발행 파이프라인을 운영하다 보면 «원고가 맞으니 결과도 맞다»고 믿기 쉽습니다. 하지만 원고와 화면 사이에 변환이 하나라도 끼면, 원고를 검사한 결과는 화면에 대해 아무것도 알려 주지 못합니다. 결과물이 놓이는 그 자리에서 다시 재야 합니다.

글 구조를 전혀 신경을 안쓴 것 같다 … 다른 글 유도를 그냥 링크를 본문에 적어버리면 어떡해.

진짜 원인은 무엇이었나: 구조 장치마다 만드는 방법이 달랐다

원인은 변환 함수 한 곳에 있었지만, 고치려고 보니 구조 장치마다 사정이 달랐습니다. 하나의 규칙으로 통일해서 해결할 수 있는 문제가 아니었습니다.

• 소제목: 네이버 편집기에서는 `sectionTitle`이라는 별도 컴포넌트여야 글자 크기가 커집니다. 굵은 문단으로는 흉내 낼 수 없습니다.
• 인용구·구분선: 편집기 툴바 버튼으로 넣는 컴포넌트입니다. 그런데 조립 도중에 툴바를 누르면 커서가 그림 업로드와 엉킵니다.
• 링크 카드(`oglink`): API로 만들 수 없습니다. `oglinkSign`이 네이버가 서명한 토큰이라서, 빈 문단에 URL만 단독으로 붙여넣어 편집기가 스스로 카드를 만들게 하는 길밖에 없습니다.

이 차이가 중요한 이유는 수정 범위를 정하기 때문입니다. 소제목만 고친다고 끝나지 않고, 인용구는 다른 방식으로, 링크 카드는 또 다른 방식으로 만들어야 합니다. 세 장치가 서로 다른 경로를 타니 하나를 고쳐 놓고 나머지도 해결됐다고 착각하기 쉽습니다.

원인을 한 문장으로 줄이면 이렇습니다. 원고의 마크다운은 «의도»이고 편집기의 컴포넌트는 «결과물»인데, 둘을 잇는 변환 단계를 아무도 결과물 쪽에서 검사하지 않았습니다.

툴바의 「링크 추가」 버튼도 시도했습니다. 그런데 이 버튼은 글감 검색 창을 열어서, 합성 입력으로는 조회가 되지 않았습니다. 두 번 실측해서 두 번 다 같은 결과였고, 그래서 URL 단독 붙여넣기로 정했습니다.

어떻게 고쳤나: 조립 후 한 번에 컴포넌트로 바꿨다

조치는 크게 세 갈래였습니다. 원고를 만드는 생성기, 글을 재는 측정기, 무인으로 발행하는 스크립트를 각각 손봤습니다.

고치는 방식은 세 가지를 놓고 골랐습니다. 첫째, 지금 방식을 그대로 둡니다. 대표의 지적을 그대로 무시하는 선택이라 처음부터 뺐습니다. 둘째, 관련 글 링크만 링크 카드로 바꾸고 소제목과 인용구는 그대로 둡니다. 지적의 절반인 구조를 놓치게 됩니다.

셋째가 채택안입니다. 제목 50자 상한, 소제목의 컴포넌트화, 리드 직후 인용구, 큰 소제목 앞 구분선, 문단 200자 분할, 관련 글 링크 카드까지 한 번에 바꾸는 전면 개편입니다. 범위가 넓은 대신 한 번의 검증으로 끝낼 수 있습니다.

생성기(PR #657)는 제목을 50자 상한으로 자르고, 리드 문단 바로 뒤에 인용구를 넣고, 중복이던 「정리」 섹션을 빼고, FAQ 질문을 `### ` 소제목으로 바꾸고, 관련 글을 `[링크: URL]` 자리표시자로 남기게 했습니다. 문단은 200자에서 나눕니다.

발행 스크립트는 소제목·인용구·구분선을 처음에는 일반 문단으로 붙입니다. 조립이 끝난 뒤 문서 JSON을 한 번만 손봐서 컴포넌트로 승격하는 방식입니다. 관련 글 링크는 빈 문단에 URL을 붙이고 카드가 생길 때까지 기다리는 함수가 맡습니다.

이 승격 작업을 브라우저 안에서 JS 한 번으로 처리한 이유는 비용 때문입니다. 브라우저 원격 조작 명령 한 번이 왕복에 약 26초 걸려서, 문단마다 왕복하면 발행 한 편이 끝없이 늘어집니다. 브라우저 안에서 재구성하니 왕복이 회당 1회로 줄었습니다.

측정기와 발행 스크립트를 같은 잣대로 맞춘 점도 중요합니다. 측정기가 구조를 세는 방식과 발행 스크립트가 검증하는 방식이 어긋나면, 한쪽이 통과시킨 글을 다른 쪽이 탈락시키는 일이 생깁니다. 그래서 구조 규격을 테스트에도 그대로 반영해 14 passed를 얻었습니다.

구분선은 실패에서 배웠습니다. 처음에는 «소제목마다» 넣었는데, 섹션이 8~12개인 기술블로그 글에서 구분선이 11줄까지 늘었습니다. 상위 노출 글의 최댓값이 8이라, 상위 글보다 많은 장식을 단 셈이었습니다. 그래서 «관련 글 앞 1회»로 줄였습니다.

자동화 작업에서 이런 순서를 고른 배경에는 작은 원칙이 있습니다. 한 번에 여러 곳을 건드리면 어디서 깨졌는지 찾기 어렵기 때문에, 원고 쪽 변경과 발행 쪽 변경을 나눠 각각 테스트를 붙였습니다. 생성기는 원고가 규격에 맞게 나오는지, 발행 스크립트는 그 원고가 편집기 안에서 컴포넌트로 바뀌는지를 따로 확인합니다. 둘 중 한 곳이 틀리면 어느 쪽인지 바로 알 수 있습니다.

제목 50자 상한도 같은 맥락입니다. 제목 길이도 측정기가 상위 글과 같은 자로 재는 항목이라, 생성기가 제목을 만들 때 50자 상한을 지키도록 `naver_title()` 함수를 두었습니다. 장식이 아니라 재는 항목은 만드는 쪽에서도 지키게 하자는 생각이었습니다. 원고 생성기와 측정기가 같은 목록을 보고 움직이면, 한쪽만 고쳐서 생기는 어긋남이 줄어듭니다. 이 방식은 소제목과 문단 길이에도 그대로 적용했습니다.

측정기가 틀렸을 때는 어떻게 했나: 9/9를 7/9로 정정했다

앞서 미뤄 둔 이야기입니다. 측정기의 첫 버전에는 결함이 있었습니다. 컴포넌트형 소제목(`se-section-sectionTitle`)을 세지 못했고, 글자 크기로만 소제목을 찾았습니다.

그 결과 상위 글 9건이 전부 구조 장치를 갖췄다는 9/9가 나왔고, 저희는 이 숫자를 조사 문서에 적었습니다. 재측정해서 7/9가 맞다고 확인한 뒤 PR #660으로 측정기를 고치고, 조사 문서에는 지우지 않고 «정정»이라는 표시와 함께 이전 값을 남겼습니다.

과장을 줄인 정정이라 방향은 안전했습니다. 그래도 이 사건이 알려 주는 점은 분명합니다. 측정기는 자기 눈에 보이는 장치만 센다는 사실입니다. 자를 만든 사람이 자의 눈금을 검증하지 않으면, 개선 작업 전체가 틀린 기준 위에 서게 됩니다.

재측정 결과: 라이브 글 7편이 전부 통과했다

기존에 발행한 글 7편을 모두 새 구조로 수정 발행했습니다. 그리고 발행 당시의 기록이 아니라 라이브 글을 다시 불러와 같은 측정기로 잰 뒤 통과 여부를 가렸습니다.

결과는 다음과 같습니다. 7편 전부 소제목이 8~12개, 링크 카드가 2~3개로 나왔고, 첫 편은 화면 캡처로 눈으로도 확인했습니다. 발행 스크립트의 자동 테스트는 14 passed였습니다. 구조 규격을 검사 조건에 넣은 뒤의 숫자입니다.

라이브 글을 다시 재는 방식을 고른 데는 이유가 있습니다. 수정 발행을 하면 글의 내용이 바뀌는데, 발행 당시에 남긴 기록은 옛 상태 그대로입니다. 기록만 믿으면 고친 뒤에도 실패로 보이거나, 반대로 고치지 않았는데 성공으로 보이는 일이 생깁니다.

수정 발행 자체도 비용이 듭니다. 관련 글까지 다시 쓰는 작업이 얽혀 있어 글 한 편을 고쳐 올리는 데 몇 분이 걸리고, 7편을 모두 새 구조로 옮기려면 그만큼의 무인 실행 시간이 필요합니다. 사람이 편집기에서 소제목을 하나씩 고르고 인용구를 달고 링크를 붙이는 수작업을 7편 곱하기 8~12개 소제목만큼 했다면 어땠을지 생각하면, 자동화로 옮긴 판단은 맞았습니다.

다만 이 판단은 앞으로도 편집기 구조가 안 바뀐다는 전제 위에 있고, 그 전제는 우리가 통제할 수 없습니다. 그래서 라이브 글을 계속 다시 재는 감시가 개선의 일부입니다.

발행 스크립트의 검증 단계에도 구조 하한을 넣었습니다. 소제목이 2개 미만이면 검증에서 탈락합니다. 앞으로 새 글이 예전의 «굵은 본문 5편»처럼 나가면 발행 도중에 걸립니다.

감시 쪽도 하나 고쳤습니다. 상태 점검 스크립트는 발행 당시 기록이 아니라 라이브 글을 다시 조회해서 구조 회귀를 판정합니다. 발행 기록을 기준으로 삼으면 수정 발행을 한 뒤에도 옛 실패가 남아 계속 빨간불이 되기 때문입니다.

남는 한계는 무엇인가

링크 정책과의 관계도 짚어 둡니다. 이보다 하루 앞선 9월 17일에 홈페이지로 향하는 외부 링크를 원고에서 모두 뺐습니다. 네이버는 외부 링크가 있는 글을 검색과 추천에서 밀어내는 경향이 있다고 판단했기 때문입니다. 그래서 이번 링크 카드는 전부 이미 네이버에 발행한 글끼리 잇는 카드입니다.

또 관련 글은 글마다 3편까지 채우고, 새 글이 나오면 기존 글의 관련 글 블록을 다시 써서 수정 발행하게 했습니다. 새 글 1편마다 기존 글 최대 3편이 수정 발행되고 편당 약 3~4분이 듭니다. 잦은 수정을 네이버가 어떻게 보는지는 실측한 적이 없어서, 노출 누락을 지켜보는 검사를 계속 돌리고 있습니다.

첫째, 링크 카드는 편집기가 자동으로 만들어 주는 방식이라 발행 스크립트가 카드가 생길 때까지 기다리는 폴링에 기댑니다. 네이버 화면이 바뀌면 이 부분이 먼저 깨질 수 있습니다.

넷째, 재측정에 쓴 표본이 작습니다. 상위 글 9건은 검색어 3종에서 뽑은 값이고, 검증한 우리 글은 7편입니다. 방향을 잡기에는 충분했지만 통계로 단정할 크기는 아닙니다. 그래서 이 글은 «이 구조가 노출을 올린다»가 아니라 «상위 글과 같은 구조로 맞췄다»까지만 주장합니다.

둘째, 소제목·인용구·구분선을 컴포넌트로 올리는 조립 후 수술은 편집기 내부 문서 구조를 직접 만집니다. 네이버가 내부 구조를 바꾸면 발행이 막히므로, 검증 단계의 구조 하한(소제목 2개 이상)이 마지막 안전망입니다.

셋째, 이 개선이 검색 노출을 실제로 올리는지는 아직 재지 못했습니다. 상위 글과 같은 구조를 갖췄다는 사실과 그 덕에 순위가 오른다는 주장은 별개이고, 지금 확인한 쪽은 앞의 사실뿐입니다.

이 한계 목록은 다음에 무엇을 재야 하는지 알려 주는 일정표이기도 합니다. 링크 카드 폴링과 조립 후 수술은 네이버 편집기가 바뀔 때 가장 먼저 깨질 자리라 감시 대상으로 올려 두었습니다. 노출 효과는 구조를 바꾼 글과 바꾸지 않은 글을 같은 기간 나란히 놓고 비교해야 답이 나옵니다. 지금은 그 비교군이 없으므로 효과를 말하지 않습니다.

블로그 글을 자동으로 발행하는 회사라면 발행 성공 여부만 보지 말고 라이브 화면의 구조를 함께 재 보시길 권합니다. 굵은 본문 문단으로 나가던 소제목처럼, 검사를 전부 통과하고도 독자에게는 다른 모양으로 보이는 결함이 이런 파이프라인에서는 흔합니다.

측정을 먼저 세우고 정정 이력까지 남기는 이 방식은 다른 지표를 읽을 때도 그대로 쓸 수 있습니다. 통계가 스스로를 증명하는 순환에 빠지지 않는지 따지는 이야기는 크몽 신규 판매자 칸 선택 기록에 적었습니다. 블로그 발행이나 업무 자동화를 맡기고 싶으시면 상담으로 문의해 주세요.