내 사이트 점검은 읽기 전용 전수 점검과 한 번에 하나씩 고치기로 나누면 된다.
8장에서는 남의 사이트에 같은 양식을 반복해 제출했다. 이번 장은 방향을 바꿔 내가 운영하는 사이트를 에이전트와 함께 살피고 고치는 일을 다룬다. 예제는 집필 환경에서 운영하는 워드프레스 기반 도서 소개 사이트(공개 페이지 100여 개)다. 2026년 8월과 9월 사이 이 사이트에서 실제로 겪은 일들을 일반화해 정리했다. 도메인과 호스팅, 플러그인 이름은 밝히지 않는다.
9.1 어떤 사이트 점검을 에이전트에게 맡기면 좋을까?
맡기기 좋은 점검은 페이지가 많고 확인할 항목이 정해져 있는 일이다. 모든 공개 주소가 정상 응답을 주는지, 제목과 이미지가 제대로 나오는지, 구조화 데이터에 날짜가 들어 있는지, 글자가 깨진 곳은 없는지 같은 항목은 사람이 100개 페이지를 하나씩 열어 보기에는 지루하고 빠뜨리기 쉽다. 에이전트는 사이트맵에서 주소를 모두 모아 같은 기준으로 한 줄씩 기록할 수 있다. 중요한 것은 점검과 수정을 같은 작업에 섞지 않는 것이다. 공식 작업 도움말에 따르면 작업마다 권한을 고를 수 있고, Read only는 파일을 바꾸지 않고 브라우저와 파일 맥락을 살펴보게 하며, 기본값은 Guard, 가장 넓은 권한은 Full access다. 점검은 Read only 작업으로 돌리고, 고칠 일이 정해지면 범위를 적은 별도 작업을 만든다. 이렇게 나누면 점검 도중에 에이전트가 무언가를 바꿀 걱정 없이 결과를 차분히 읽을 수 있다.
9.2 다른 AI가 준 점검 보고서는 그대로 믿어도 될까?
그대로 믿기보다 주장 목록으로 받아 하나씩 확인하는 편이 좋다. 이 사이트는 약 2주 동안 여러 채팅 AI에게서 점검 보고서를 6번 받았다. 각 주장을 실제 사이트와 대조해 보니 “깨졌다”, “빠졌다”는 주장의 절반가량이 사실이 아니었다. 틀린 이유는 두 가지였다. 하나는 확인하지 않고 짐작으로 쓴 경우, 다른 하나는 사이트가 바뀐 뒤에도 자기가 앞서 본 내용을 다시 확인하지 않고 재사용한 경우다. 개선 지시서 하나는 항목의 절반쯤이 이미 구현된 기능을 없다고 적고 있었고, 실제 화면과 비교한 뒤 반영한 항목은 5개뿐이었다. 그래서 보고서를 받으면 주장마다 “이것은 어떻게 확인할 수 있나”를 붙이고, 확인 방법이 없는 주장은 사실이 아니라 미확인으로 분류한다. 같은 AI에게 다시 물을 때는 “지난번 답을 재사용하지 말고 지금 상태를 다시 확인해 달라”고 분명히 적는다. 틀린 주장을 걸러내면 정말 필요한 수정에 시간을 쓸 수 있다.
9.3 왜 한 페이지가 아니라 전체를 훑어야 할까?
한 페이지에서 보인 문제가 몇 페이지에 퍼져 있는지 알아야 원인을 좁힐 수 있기 때문이다. 어느 날 장 페이지에서 글머리 기호가 알아볼 수 없는 문자로 깨져 보였다. 사이트맵에 있는 96개 주소를 모두 점검하자 20개 페이지에서 650곳이 깨져 있었다. 흥미로운 점은 피드, 사이트맵, AI용 텍스트 파일처럼 본문 필터를 거치지 않는 출력은 처음부터 깨진 곳이 0이었다는 사실이다. 이 차이 덕분에 원인이 본문을 가공하는 단계에 있다고 좁힐 수 있었고, 실제 원인은 사이트 전용 플러그인의 텍스트 처리 정규식에서 옵션 문자 하나가 빠진 것이었다. 한 글자를 고친 뒤 다시 전수 점검하니 20개 페이지가 0개로, 650곳이 0곳으로 줄었다. 전체를 세어 두면 고친 뒤에 같은 방법으로 다시 세어 효과를 숫자로 확인할 수 있다.
아래 표는 이 장에서 다루는 사례를 한데 모은 것이다. 모두 처음 보인 증상과 실제 원인이 달랐다.
| 무엇이 보였나 | 실제 원인 | 확인 방법 | 고친 규칙 |
|---|---|---|---|
| 외부 AI 보고서의 “빠졌다” 주장 다수 | 절반가량이 짐작이거나 예전 관찰 재사용 | 주장마다 실제 사이트와 대조 | 주장 목록으로 받고 확인 방법을 붙인다 |
| 장 페이지 글머리 기호 깨짐 | 전용 플러그인 정규식의 옵션 문자 하나 누락 | 96개 주소 전수 점검, 필터를 안 거치는 출력과 비교 | 고친 뒤 같은 방법으로 전수 재측정 |
| 업데이트 뒤 전용 페이지들이 404 | 플러그인 갱신으로 주소 규칙이 빠짐 | 고유주소 설정을 바꾸지 않고 다시 저장 | 배포 뒤 고유주소 재저장을 고정 단계로 |
| 서버는 200인데 브라우저에는 404 | 브라우저 캐시 | 쿠키 없는 새 요청으로 상태 코드 확인 | 판단은 비로그인 새 요청 기준 |
| 수정했는데 옛 CSS가 계속 나옴 | 플러그인 캐시만 비우고 호스팅 캐시는 남음 | 캐시 우회용 임의 쿼리 문자열 붙여 요청 | 먼저 반영 여부를 보고 필요한 캐시만 비운다 |
| 스테이징에 오래된 플러그인 경고 | 운영 쪽 업데이트가 스테이징에 반영 안 됨 | 경고 내용을 스테이징 화면에서 직접 확인 | 운영 업데이트 뒤 스테이징도 점검 |
| 꼬리말을 막았더니 정책 링크도 사라짐 | 같은 템플릿 조각에 우리 정보가 함께 있었음 | 비로그인 페이지에서 꼬리말 확인 | 전체 차단 대신 해당 부분만 직접 수정 |
9.4 점검과 수정은 어떤 순서로 흘러갈까?
흐름은 일곱 단계이고 마지막 기록이 다음 점검의 출발점이 된다. 먼저 보고서나 눈에 띈 증상을 주장 목록으로 만든다. 다음으로 읽기 전용 작업에서 로그인하지 않은 방문자 시점으로 전체 주소를 점검한다. 세 번째로 증상이 나온 페이지와 나오지 않은 페이지를 비교해 원인을 좁힌다. 네 번째로 한 가지만 고친다. 다섯 번째로 캐시를 우회한 비로그인 요청으로 결과를 확인한다. 여섯 번째로 같은 원인에 영향받을 수 있는 범위를 전수 재측정한다. 마지막으로 무엇을 왜 바꿨고 전후 숫자가 어떻게 달라졌는지 기록한다.
9.5 로그인한 화면과 방문자 화면은 왜 다를까?
에이전트가 쓰는 브라우저에는 내 로그인 쿠키가 실려 있기 때문이다. 관리자로 로그인한 상태에서 페이지를 요청하면 관리 막대가 붙은 관리자용 화면이 돌아오고, 오류 표시나 캐시 동작도 방문자와 다를 수 있다. 검색 로봇과 방문자가 보는 화면은 쿠키 없는 요청으로 따로 확인해야 한다. 이 연재 자체에서도 도움이 됐다. 한 장을 비로그인으로 확인하다가 날짜가 들어간 Article 구조화 데이터 블록이 빠져 있는 것을 발견했고, 그 글에만 추가했다. 지시문에 “로그인하지 않은 새 요청으로 확인”이라고 적어 두면 이런 차이를 놓치지 않는다.
비로그인 확인은 수정 전과 수정 후에 모두 한다. 수정 전 기록이 있어야 무엇이 달라졌는지 말할 수 있고, 수정 후 기록이 있어야 방문자에게도 반영됐다고 말할 수 있다. 관리 화면에서 저장이 성공했다는 표시는 서버가 값을 받았다는 뜻일 뿐, 방문자 화면에 나온다는 뜻은 아니다. 그 사이에 캐시와 템플릿과 필터가 끼어 있기 때문이다.
9.6 고쳤는데도 그대로 보이면 무엇을 의심할까?
고친 결과가 보이지 않을 때는 먼저 캐시와 배포 뒷정리를 의심하는 편이 좋다. 전용 플러그인을 업데이트한 뒤 전용 페이지 유형들이 모두 404를 낸 적이 있다. 원인은 업데이트 과정에서 주소 규칙이 빠진 것이었고, 고유주소 설정 화면에서 아무것도 바꾸지 않고 다시 저장하는 것만으로 복구됐다. 그 뒤로 이 재저장은 배포의 고정 단계가 됐다. 그런데 같은 시점에 브라우저는 계속 404를 보여 주고 있었다. 서버는 이미 200을 돌려주고 있었으니 브라우저 캐시가 만든 착각이었다. 반대로 주소 규칙을 바꾼 뒤 캐시된 200이 계속 나와 문제가 없어 보인 적도 있는데, 주소 끝에 임의의 쿼리 문자열을 붙여 캐시를 우회하자 실제 404가 드러났다. 캐시 플러그인만 비우고 호스팅 관리 화면의 캐시를 그대로 두어 홈이 옛 CSS 버전을 계속 내보낸 일도 있었다. 한편 메타데이터를 저장하자마자 캐시를 비우지 않아도 바로 반영된 적도 있다. 저장할 때 사이트가 스스로 캐시를 무효화하기 때문이다. 그래서 순서는 “먼저 비로그인으로 이미 반영됐는지 본다, 안 됐으면 필요한 캐시만 비운다”가 된다.
9.7 집계 결과가 이상하면 무엇부터 의심할까?
사이트보다 측정 방법을 먼저 의심한다. 이 사이트에서만 세 번 겪었다. 본문 블록만 정규식으로 잘라 글자 수를 셌더니 일부 페이지가 49자라는 터무니없는 값이 나왔다. 날짜를 og 메타 태그에서 찾았더니 0%가 나왔는데, 날짜는 JSON-LD 안에 있었다. 글자 수를 세려고 script 태그를 모두 지웠더니 JSON-LD까지 지워져 구조화 데이터가 0건으로 나왔다. 세 번 모두 사이트는 멀쩡했다. 그래서 규칙을 하나 정했다. 집계가 “전부 0″이나 “전부 같음”으로 나오면 결과를 보고하기 전에 파서를 먼저 확인한다. 2026년 9월 20일 장 페이지 136편을 기준 점검했을 때 구조화 데이터, 날짜, 이미지는 거의 100%였지만 질문형 헤딩은 평균 7%였고 250~450자 분량의 인용하기 좋은 문단은 적었다. 이 연재는 그 결과를 반영해 쓰고 있다. 색인 실험에서는 수동 색인 요청이 병목이 아니라는 결과도 나왔다. 요청한 쪽은 5개 중 4개, 요청하지 않은 쪽은 3개 중 3개가 색인됐다.
9.8 작은 수정이 다른 곳을 깨뜨리지 않게 하려면?
가장 작은 범위로 고치고, 고친 뒤에는 방문자 화면에서 주변까지 함께 본다. 테마의 기본 꼬리말을 필터로 통째로 막았더니 같은 템플릿 조각에 들어 있던 정책 링크와 사업자 정보까지 사라졌다. 필터를 되돌리고 템플릿 조각의 내용을 직접 고치는 방식으로 바꾸자 원하는 부분만 정리됐다. 운영 사이트와 스테이징 사본도 따로 챙긴다. 운영 쪽 플러그인을 업데이트했지만 스테이징에는 반영되지 않았고, 호스팅 업체의 보안 메일이 스테이징의 오래된 플러그인을 지적했다. 메일 내용도 하나의 주장으로 보고 확인해 보니 사실이었고, 그 뒤 업데이트했다. 운영 업데이트 뒤에는 스테이징도 점검 목록에 넣는다.
9.9 점검 요청과 수정 요청은 어떻게 쓸까?
아래는 설명용 지시문이다. 첫 번째는 Read only 작업에서, 두 번째는 범위를 정한 별도 작업에서 쓴다. 공식 보안 도움말에 따르면 도구와 접근은 Allow, Ask, Deny로 정하고 겹치면 Deny가 이긴다. 수정 작업에서는 바꿀 파일이나 화면만 허용하고, 작업 상세 화면에서 만들거나 바꾼 파일 목록을 확인한다.
[읽기 전용 점검 지시문 예시, 가상 설정] 목적: 내 사이트의 공개 페이지 전체를 방문자 시점으로 점검한다. 아무것도 바꾸지 않는다. 1. 사이트맵에서 모든 공개 주소를 모은다. 주소 개수를 먼저 알려 준다. 2. 각 주소를 로그인 쿠키 없는 새 요청으로 연다. 3. 주소마다 다음을 기록한다. - 상태 코드 (200 / 301 / 404 등) - 페이지 제목 - 본문 이미지가 실제로 불러와지는지 - 구조화 데이터(JSON-LD)에 발행일과 수정일이 있는지 - 깨진 문자가 있는지, 있다면 몇 곳인지 4. 결과는 표로: 주소 | 상태 | 제목 | 이미지 | 날짜 | 깨진 문자 | 근거 근거 칸에는 무엇을 보고 판단했는지 적는다. 5. 집계가 "전부 0"이나 "전부 같음"이면 보고 전에 측정 방법부터 다시 확인한다. 6. 설정, 글, 플러그인, 캐시는 건드리지 않는다. 고칠 점은 제안으로만 적는다.
[한 가지 수정 지시문 예시, 가상 설정] 목적: 점검 보고의 2번 항목 하나만 고친다. 1. 고치기 전 상태를 비로그인 요청으로 기록한다. (before) 2. 바꿀 곳은 한 군데만. 무엇을 어떻게 바꿀지 먼저 보여 주고 내 확인을 기다린다. 3. 수정 뒤 주소 끝에 임의의 쿼리 문자열(예: ?check=7391)을 붙여 캐시를 우회한 비로그인 요청으로 다시 확인한다. (after) 4. before / after를 나란히 보여 준다. 5. 같은 원인에 영향받을 수 있는 다른 페이지 목록을 만들고, 그 범위를 전수 재측정한다. 6. 캐시는 반영이 안 된 것을 확인한 경우에만, 필요한 곳만 비운다. 7. 다른 항목은 고치지 않는다. 발견하면 목록에만 추가한다.
점검 보고는 이런 모양으로 받는다. 형식을 보여 주기 위한 가상 예시이며 실제 결과가 아니다.
[가상 예시] 읽기 전용 점검 보고 점검 주소 96 / 정상 91 / 확인 필요 5 (비로그인 새 요청 기준) 1 /sample-page-a/ 200 이미지 정상 날짜 있음 깨진 문자 12곳 근거: 본문 글머리 기호 위치 2 /sample-page-b/ 404 - - - 근거: 캐시 우회 요청도 404 3 /sample-page-c/ 200 이미지 1개 실패 날짜 있음 0 근거: 이미지 주소 응답 404 참고: 피드와 사이트맵 출력에는 깨진 문자 0곳. 본문 가공 단계가 의심됨 변경한 것: 없음
아래 표는 점검부터 수정 뒤 확인까지를 한 장으로 줄인 것이다.
| 단계 | 확인할 것 | 통과 기준 |
|---|---|---|
| 주장 정리 | 보고서 항목마다 확인 방법이 있는가 | 방법 없는 주장은 미확인으로 분류 |
| 전수 점검 | 사이트맵 전체를 비로그인으로 보았는가 | 주소 개수와 기록 개수가 같음 |
| 측정 검증 | “전부 0”, “전부 같음”이 나왔는가 | 나왔다면 파서부터 재확인 |
| 수정 | 한 가지만 바꿨는가 | before 기록과 변경 내용이 1:1 |
| 배포 뒤 | 전용 페이지 유형이 살아 있는가 | 고유주소 재저장 후 200 |
| 반영 확인 | 캐시 우회 비로그인 요청으로 보았는가 | after가 기대한 값 |
| 영향 범위 | 같은 원인의 다른 페이지를 다시 셌는가 | 재측정 수치 기록 |
| 주변 확인 | 꼬리말, 링크 등 같은 틀의 다른 요소가 그대로인가 | 방문자 화면에서 이상 없음 |
| 스테이징 | 운영 변경이 스테이징에도 필요한가 | 필요하면 같은 절차로 반영 |
9.10 다음 장: 텔레그램으로 지시하고 결과 받기
이 장에서는 점검과 수정을 나누고, 방문자 시점으로 확인하고, 숫자로 전후를 비교하는 습관을 익혔다. 다음 10장에서는 자리를 비운 사이에도 휴대폰의 텔레그램으로 이런 작업을 지시하고 결과를 받는 방법을 다룬다.
확인한 공식 자료와 관찰 범위
2026년 9월 26일 확인. 작업 안내 · 보안과 권한 안내. 사례는 집필 환경의 실제 사이트 운영 기록을 일반화한 것이며, 도메인·플러그인·호스팅은 공개하지 않았다. 지시문과 보고는 설명용 가상 예시다.
다음 글: 10장 · 텔레그램으로 지시하고 결과 받기
이전 글: 8장 · 같은 양식의 폼을 반복 제출하기
『Aside 브라우저 사용설명서』 연재 목록
공식 자료와 집필 환경의 작업 기록을 바탕으로 AI의 도움을 받아 작성·편집했습니다. 흐름도와 예시는 설명용이며 실제 앱 화면이나 실제 값이 아닙니다. 초판 선공개 원고 v1.0.