구조화 데이터의 주소 자리에 ‘undefined’가 찍혀 있었다.
1권 12장을 올리고 로그인하지 않은 방문자 화면으로 확인하던 중이었다. 구조화 데이터는 검색 엔진이 글의 제목과 날짜, 주소를 기계가 읽는 형태로 알 수 있게 본문에 넣는 정보다. 발행 코드에 변수 하나가 빠져서 그 주소 칸에 값 대신 ‘undefined’라는 글자가 들어갔다. 바로 고쳤고(1권 13장), 그 뒤로는 발행 전에 본문에 ‘undefined’나 그림 자리표시가 남았는지 기계적으로 검사한다. 이 글은 워드프레스 같은 블로그를 운영하며 AI로 발행을 자동화하고 싶은 비개발자를 위해 쓴다. 소재는 이 연재 자체를 올린 방식이다. 에필로그에서 짧게 소개한 흐름을 단계별로 풀고, 실제로 걸린 것을 함께 적는다. 고급편의 여섯 번째 글이다.
6.1 블로그 자동 발행에서 가장 중요한 것은 무엇일까?
쓰기보다 확인이다. 발행 전에는 사실 목록과 대조하고, 발행 뒤에는 방문자 화면을 본다.
이 연재는 AI가 쓴 글을 검증 없이 올리는 방식으로 만들지 않았다. 사람이 정한 사실과 기준에서 출발해 초안, 대조, 발행, 방문자 화면 확인, 기록으로 이어진다. 돌아보면 걸린 것은 대부분 쓰는 단계가 아닌 확인 단계에서 나왔다. 구조화 데이터의 undefined도, 연재 목록 페이지의 설명 문구도 방문자 화면에서 발견했다. 이미 올린 글을 나중에 고쳐야 할 일도 생겼다. 글을 써 주는 부분은 이 흐름에서 한 칸일 뿐이다. 그래서 발행을 맡길 때 내가 요청문에서 가장 공들이는 대목은 무엇을 쓰라는 지시보다, 어디서 멈추라는 조건과 무엇을 확인하라는 항목이다. 이 글도 그 순서를 따라간다.
6.2 한 편은 어떤 단계를 거쳐 올라갈까?
그림 6-1은 이 연재 한 편이 올라가는 순서다. 첫째, 실제 기록에서 사실 목록을 만든다. 둘째, 초안을 쓴다. 셋째, 초안을 사실 목록과 문장 단위로 대조한다. 넷째, 그림을 만들고 개인정보를 가린다. 다섯째, 이미지와 글을 사이트에 올린다. 여섯째, 로그인하지 않은 방문자 화면으로 결과를 확인한다. 일곱째, 운영 기록 파일과 기획서 두 문서에 결과를 적는다. 멈춤 조건은 두 곳에 붙어 있다. 대조에서 사실 목록 밖 문장이나 자리표시가 남으면 발행으로 넘어가지 않는다. 방문자 화면 확인에서 어긋난 것이 나오면 기록하기 전에 고친다. 한 편에 이 흐름을 한 번 돌렸고, 이틀 동안 1권 후반과 에필로그, 고급편 다섯 편을 올렸다.
6.3 초안은 누가 쓰고 누가 대조할까?
초안은 하위 에이전트가 쓰고, 대조는 그 작업자를 띄운 부모 세션이 한다.
글마다 먼저 사실 목록을 만든다. 실제 기록을 메모리 검색으로 찾아 날짜와 수치를 확인하고, 확인한 것만 목록에 적는다. 메모리 검색은 Aside가 지난 작업에서 남긴 기록을 찾아 보는 기능이다. 목록 밖 경험은 글에 쓰지 않는다. 초안은 하위 에이전트에게 맡긴다. 하위 에이전트는 지금 대화하는 세션이 따로 띄운 작업자를 말한다. 이 작업자는 사실 목록과 문체 기준이 되는 원고, 검색 최적화 기준을 읽고 워드프레스 블록 형식으로 초안을 쓴다. 블록 형식은 워드프레스 편집기가 문단, 제목, 표, 그림을 한 덩어리씩 나눠 저장하는 방식이다. 초안을 넘길 때는 사실 목록 밖이라고 판단한 문장을 스스로 보고하게 한다.
대조는 부모 세션이 맡는다. 부모 세션은 하위 에이전트를 띄운 원래 세션이다. 초안을 문장 단위로 사실 목록과 맞춰 보고 고친다. 실제로 고친 예를 들면 이렇다. 고급편 4편에서는 약관 인용을 원문과 한 글자씩 맞췄다. 1권 14장에서는 캡처에 가상 값을 넣었다는 틀린 문장을 바로잡았다. 1권 10장부터는 지어낸 장면을 지웠다. 하위 에이전트의 자진 보고는 출발점이고, 대조는 보고되지 않은 문장까지 한 문장씩 본다. 이 단계가 발행 전의 첫 번째 멈춤 조건이다. 사실 목록으로 뒷받침되지 않는 문장이 남아 있으면 발행으로 넘어가지 않는다.
검색 최적화 기준은 내 사이트용으로 따로 적어 둔 문서다. 첫 문단은 60자 안팎의 직답으로 시작하고, 소제목의 30~50%는 질문형으로 쓴다. 250~450자로 떼어 읽어도 말이 되는 문단을 여러 개 두고, 비교는 표로 보여 준다. 이미지는 한 장 이상 넣고, 구조화 데이터에는 발행일과 수정일을 넣는다. 이 기준도 처음부터 잘 맞지는 않았다. 1권 1~9장은 질문형 소제목 기준을 너무 넓게 적용해 질문이 과했다(에필로그).
6.4 그림 만들기와 개인정보 가리기
설명용 도식은 코드로 그린다. SVG라는 형식으로 선과 글자를 적고, 브라우저에서 열어 PNG 이미지로 바꾼다. 실제 화면은 Aside 설정 화면이나 공개 페이지를 탭으로 열어 찍는다. 이 환경에서는 화면 일부만 잘라 찍는 기능이 좌표를 무시해서, 전체 화면을 찍은 뒤 이미지 도구로 잘랐다. 개인정보가 보이면 캡처 직전에 화면에 보이는 글자만 가상 값으로 바꾼다. 카드 끝자리, 작업 이름, 사이트 주소 같은 것이다. 설정값 자체는 건드리지 않는다. 화면에 보이는 글자만 바꾸면 캡처가 끝난 뒤 실제 설정에는 아무 흔적이 남지 않는다. 이 글의 그림 6-2와 6-3도 사이트 이름 등을 가상 값으로 바꿔 찍었다.
여기에 정해진 절차를 둔 이유가 있다. 예전에 다른 에이전트로 블로그 게시를 자동화했을 때, 잘리지 않은 전체 화면 캡처가 그대로 올라가 비공개 정보가 약 7시간 노출된 사고가 있었다(1권 14장). 그 뒤로 캡처, 자르기, 가리기는 정해진 절차로 하고, 무엇을 찍을지는 사람이 정한다. 자동화에 맡기는 것은 절차의 실행이다. 어떤 화면을 공개할지는 내 판단으로 남겨 둔다. 뒤에 나오는 요청 예시에서 개인정보를 멈춤 조건으로 넣은 것도 이 사고 때문이다.
6.5 REST로 올린다는 건 무슨 뜻일까?
편집기 화면을 누르는 대신, 사이트가 열어 둔 데이터 창구로 이미지와 글을 보낸다는 뜻이다.
REST API는 프로그램이 사이트와 데이터를 주고받는 창구다. 이미지는 이 창구로 올리고 대체 텍스트를 붙인다. 대체 텍스트(alt)는 이미지를 볼 수 없는 사람과 검색 엔진에게 그림 내용을 글로 알려 주는 설명이다. 이 환경에서는 올릴 파일을 먼저 작업 폴더로 복사해야 했다(고급편 5편). 글도 같은 창구로 발행한다. 작성자인 필명 계정, 카테고리, 대표 이미지, 요약, 댓글 닫힘을 한 번에 지정한다. 요약은 검색 결과에 나오는 설명으로 쓰인다. 인증은 로그인된 관리자 세션의 보안 토큰으로 한다.
본문 끝에는 구조화 데이터를 넣는다. 제목, 설명, 발행일, 수정일, 대표 이미지, 저자를 담은 Article 형식이다. 글을 올린 뒤에는 앞 글에 ‘다음 글’ 링크를 단다. 앞 글 본문에서 ‘이전 글’ 링크의 정확한 문자열 한 곳을 찾아 그 앞에 넣는다. 넣기 전에는 찾은 개수가 1인지 먼저 확인한다. 둘 이상이면 엉뚱한 자리에도 들어갈 수 있고, 0이면 앞 글의 문장이 내가 아는 것과 다르다는 뜻이다. 어느 쪽이든 넣기 전에 원인부터 확인한다. 그림 6-2는 이렇게 발행을 마친 뒤의 글 목록이다. 고급 활용 카테고리의 1~5편이 작성자 강지우, 발행됨 상태로 있다.
6.6 편집기에서 블록 검증하기
REST로 올린 글도 편집기에서 한 번 연다. 모든 블록이 ‘유효’한지 보는 블록 검증이다. 블록 검증은 저장된 블록이 편집기가 기대하는 모양과 맞는지 확인하는 과정이다. 1권 1장을 올릴 때 이미지 블록에 너비와 높이 속성을 넣었다가 블록 검증이 실패한 적이 있다. 그 뒤로는 그 속성을 넣지 않는다. 반대로 문제처럼 보였지만 문제가 없던 일도 있다. 편집기 화면이 첫 문장을 두 번 보여 준 적이 있었는데, 공개 본문에는 한 번뿐이어서 원고 중복이 아니었다. 편집기 화면만 보고 원고를 고쳤다면 멀쩡한 첫 문장을 지웠을 것이다. 그래서 편집기에서 이상한 것을 보면 공개 화면과 맞춰 본 뒤에 판단한다. 그림 6-3은 고급편 5편의 편집기 화면이다.
6.7 방문자 화면에서는 무엇을 확인할까?
로그인하지 않은 방문자가 받는 화면을 본다. 내 브라우저로 보면 관리자 화면이 섞인다.
확인은 명령줄 요청으로 한다. 명령줄 요청은 브라우저 없이 주소를 불러 서버가 보내는 내용을 그대로 받아 보는 방법이다(고급편 1편). 브라우저로 부르면 내 로그인 쿠키가 함께 실려 관리자 화면이 섞인다. 쿠키는 사이트가 나를 알아보도록 브라우저에 저장해 두는 작은 정보다. 관리자 화면이 섞이면 방문자에게는 없는 것이 보이고, 방문자가 겪을 문제는 가려질 수 있다. 그래서 이 확인에는 브라우저 요청을 쓰지 않는다(1권 9장). 이미지 크기 변형도 하나씩 부른다. 워드프레스가 이미지를 올릴 때 여러 크기로 만들어 두는 사본인데, 한 편에 17개였다. 확인하는 항목은 표 6-1과 같다.
| 항목 | 무엇을 보나 | 왜 |
|---|---|---|
| 응답 코드 | 200인지 | 글이 정상으로 열리는지부터 본다 |
| 대표 주소(canonical) | 이 글 주소를 가리키는지 | 검색 엔진이 어느 주소를 원본으로 볼지 정한다 |
| 구조화 데이터 | Article이 1개인지, 그 주소가 이 글 주소인지 | 1권 12장의 undefined가 여기서 나왔다 |
| 이미지 크기 변형 | 모든 변형이 200인지(한 편에 17개) | 하나라도 빠지면 어떤 화면에서는 그림이 깨질 수 있다 |
| 표 개수 | 원고의 표 수와 같은지 | 올리는 과정에서 블록이 빠지지 않았는지 본다 |
| 예시 상자 | 옆으로 넘치지 않는지 | 좁은 화면에서도 읽혀야 한다 |
| 본문 링크 | 걸어 둔 링크가 제 주소로 가는지 | 앞뒤 글과 1권을 오가는 길이다 |
| 연재 목록 | 이 글이 목록에 올라갔는지 | 목록에서 들어오는 독자가 찾을 수 있어야 한다 |
6.8 실제로 걸린 것
undefined 말고도 방문자 화면에서 나온 것이 있다. 연재 목록 페이지의 검색 설명이 사이트 기본 문구로 나오고 있었다. 사이트 코드를 고쳐 목록마다 고유한 설명이 나오게 했다(2026년 9월 27일). 이때는 순서를 지켰다. 고치기 전에 문법 검사를 하고 원본 파일을 백업했다. 저장한 뒤에는 서버 파일을 다시 읽어 넣은 코드와 같은지 확인했고, 사이트 캐시를 비웠다. 캐시는 빨리 보여 주려고 이전 결과를 저장해 두는 것이다. 마지막으로 다른 페이지 종류, 곧 홈, 도서 목록, 분야, 저자, 글, 사이트맵이 그대로인지도 방문자 화면으로 확인했다. 한 곳을 고친 뒤에는 다른 곳이 바뀌지 않았는지까지 봐야 끝난다.
이미 발행한 글을 고칠 일도 생긴다. 고급편 4편의 주제를 바꾸면서 2편과 3편의 예고 문구와 관련 문장을 고쳤다. 고친 뒤에는 블록 검증과 방문자 화면 반영을 다시 확인했다. 발행 후 수정도 발행과 같은 확인을 거친다. 사이트 점검 때는 고쳤는데도 그대로 보이는 일이 있었다. 그럴 때는 브라우저, 사이트, 호스팅 세 곳의 캐시를 의심했고, 사이트 코드의 버전을 올려 자산 주소가 바뀌면 바로 반영되기도 했다(1권 9장). 자산은 화면 모양을 정하는 스타일 파일 같은 것이다. 작은 규칙도 하나 있다. 탭이 쌓이지 않게, 한 작업이 끝날 때마다 그 작업에서 연 탭을 닫았다(고급편 5편). 표 6-2는 이렇게 걸린 것을 한곳에 모은 것이다.
| 무엇이 | 어디서 발견 | 어떻게 고침 | 이후 규칙 |
|---|---|---|---|
| 구조화 데이터 주소 자리에 ‘undefined'(1권 12장) | 방문자 화면 확인 | 발행 코드의 빠진 변수를 바로 고침 | 발행 전에 undefined와 그림 자리표시를 기계적으로 검사 |
| 연재 목록 페이지의 검색 설명이 사이트 기본 문구 | 방문자 화면 확인 | 사이트 코드를 고쳐 목록마다 고유한 설명 | 문법 검사, 백업, 저장 뒤 다시 읽기, 캐시 비우기, 다른 페이지 종류 확인 |
| 이미지 블록의 너비·높이 속성(1권 1장) | 편집기 블록 검증 | 속성을 뺌 | 그 속성은 넣지 않음 |
| 편집기에서 첫 문장이 두 번 보임 | 편집기 화면 | 공개 본문에는 한 번뿐이라 고칠 것 없음 | 편집기에서 이상하면 공개 화면과 맞춰 보고 판단 |
| 4편 주제 변경으로 2·3편 예고가 어긋남 | 발행 뒤 기획 변경 | 예고 문구와 관련 문장 수정 | 수정 뒤에도 블록 검증과 방문자 화면 재확인 |
| 고쳤는데 그대로 보임 | 사이트 점검 | 캐시를 의심, 버전을 올려 자산 주소 변경 | 브라우저·사이트·호스팅 캐시부터 본다 |
| 부분 캡처가 좌표를 무시 | 그림 만들기 | 전체 화면을 찍고 이미지 도구로 자름 | 같은 방식으로 찍는다 |
| 탭이 쌓임 | 작업 중 | 연 탭을 닫음 | 한 작업이 끝날 때마다 닫는다 |
6.9 채널마다 승인 기준을 다르게 둔다
공개 게시는 되돌려도 흔적이 남는 일이다(1권 11장). 그래서 채널마다 사람이 승인하는 지점을 다르게 둔다. 이 연재는 내가 “시작”, “진행해줘”로 편마다 발행을 맡겼고, 발행 뒤 결과를 받아 확인했다. 발행 버튼 앞에서 매번 멈추게 하지는 않았지만, 편마다 시작은 내가 말하고 끝은 내가 본다. SNS 게시물과 답글은 다르다. 초안을 내가 승인한 뒤에만 올린다. 다른 블로그 채널로 옮길 때는 원문을 그대로 붙이지 않고 그 채널에 맞게 다시 구성하며, 끝에 내 사이트 링크를 단다는 규칙을 2026년 9월에 세웠다. 같은 글이라도 어디에 어떻게 나가느냐에 따라 사람이 끼는 자리가 달라지는 셈이다.
이 연재의 글에는 공통으로 하나를 붙인다. 모든 글 끝에 “저자의 실제 사용 경험과 Aside 도움말을 바탕으로 AI의 도움을 받아 작성·편집했습니다”라는 문구를 붙인다. 이 글의 맨 끝에도 있다.
6.10 발행을 맡기는 요청 예시
아래는 설명을 위해 만든 가상의 요청이다. 담을 것은 세 가지다. 사실 목록만 소재로 쓰기, 발행 전 멈춤 조건, 방문자 화면 확인 결과를 표로 보고하기.
[가상 설정] 블로그 글 한 편을 맡길게. 초안부터 방문자 화면 확인까지 해 줘. 1. 소재는 첨부한 사실 목록만 써. 목록 밖 경험이나 숫자는 넣지 마. 2. 초안은 워드프레스 블록 형식으로 쓰고, 사실 목록 밖이라고 판단한 문장은 따로 적어 줘. 3. 초안을 사실 목록과 문장 단위로 대조해서 고쳐 줘. 4. 그림은 내가 정한 화면만 찍어. 개인정보는 화면 글자만 가상 값으로 바꾸고 설정은 건드리지 마. 5. 발행 전에 아래 중 하나라도 있으면 멈추고 나에게 물어봐. - 본문에 'undefined'나 그림 자리표시가 남아 있다 - 사실 목록으로 뒷받침되지 않는 문장이 있다 - 캡처나 본문에 개인정보가 보인다 6. 발행할 때 작성자, 카테고리, 대표 이미지, 요약, 댓글 닫힘을 한 번에 지정해. 7. 발행 뒤에는 로그인하지 않은 방문자 화면으로 확인해. 내 브라우저 요청은 쓰지 마. 8. 결과는 표로 보고해 줘. 항목 / 기대값 / 실제값 / 통과 여부. 항목: 응답 코드, 대표 주소, 구조화 데이터, 이미지 크기 변형, 표 개수, 본문 링크, 연재 목록 9. 끝나면 이 작업에서 연 탭을 닫아.
5번이 이 요청의 중심이다. 세 조건은 모두 이 연재를 올리며 실제로 걸렸거나 사고로 이어졌던 것에서 나왔다. undefined는 1권 12장에서, 사실 목록 밖 문장은 대조 단계에서, 개인정보는 예전 블로그 자동화의 캡처 사고에서 왔다. 멈추고 물어보라고 적어 두면 애매한 경우에 발행 쪽으로 넘어가지 않는다. 8번은 방문자 화면 확인을 말로 된 “문제없음” 대신 항목별 값으로 받으려는 줄이다. 기대값과 실제값이 나란히 있으면 어느 항목에서 어긋났는지 바로 보인다. 9번은 고급편 5편에서 정한 탭 규칙을 옮긴 것이다.
6.11 다음 편: SNS 운영 자동화와 승인
다음 편에서는 초안 승인 뒤에만 올리는 SNS 운영 자동화와 그 승인 방식을 다룬다.
이 글의 확인 범위
기준일은 2026년 9월 27일이다. Aside와 워드프레스의 동작과 화면은 바뀔 수 있다.
- 이 글의 흐름은 2026년 9월 26~27일 이 연재를 올리며 내 사이트에서 관찰한 결과다.
- 블록 형식, 블록 검증, REST API, 이미지 크기 변형은 워드프레스 기준으로 썼다. 워드프레스 버전과 사이트 설정에 따라 다를 수 있다.
- 표 6-1의 확인 항목은 내 사이트에서 쓰는 기준이며, 모든 블로그에 필요한 목록은 아니다.
- 이미지 크기 변형 17개, 약 7시간, 이틀은 내 작업 기록이다.
- 그림 6-1은 설명용 도식이고, 그림 6-2와 6-3은 워드프레스 관리자 화면이다. 사이트 이름 등은 가상 값이다. 6.10절의 요청은 가상이다.
참고한 자료
2026년 9월 27일 확인. WordPress REST API 핸드북
다음 글: 고급 활용 7 · SNS는 허용된 길로
이전 글: 고급 활용 5 · 자동화를 돌리는 컴퓨터 설정
1권: 『Aside 브라우저 사용설명서』 연재 목록
『Aside 고급 활용』 연재 목록
저자의 실제 사용 경험과 Aside 도움말을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 초판 선공개 원고 v1.0.