공식 페이지 변경 감지로 오래된 블로그 글 찾는 자동화
공식 페이지 변경 감지로 오래된 블로그 글 찾는 자동화
지원 조건이나 제품 안내를 확인해 글을 써도 시간이 지나면 공식 페이지가 바뀔 수 있어요. 문제는 변경 사실을 매일 직접 찾아보기 어렵다는 점이에요. 그렇다고 AI에게 페이지를 알아서 고치고 글까지 다시 발행하게 맡기면, 메뉴 문구 하나가 바뀐 일을 정책 변경으로 잘못 판단할 수도 있습니다.
공식 페이지 변경 감지의 목적은 자동 수정이 아니라 재확인이 필요한 글을 빨리 찾는 것이에요. 감시할 URL과 본문 기준값을 저장하고, 일정한 주기로 다시 가져온 값과 비교한 뒤 차이가 있을 때만 사람이 확인할 목록에 남기는 방식이 실용적입니다.
변경 알림은 답이 아니라 다시 확인할 글을 알려주는 신호로 사용해요.
자동 변경 감지가 필요한 이유
기간, 대상, 금액, 신청 경로가 들어간 글은 공식 안내가 바뀌면 내용이 금방 낡아요. 글마다 확인일과 출처 URL을 기록해도 다시 방문할 시점을 놓치기 쉽습니다. 이때 감시 목록에 공식 URL, 연결된 글 주소, 마지막 확인일, 중요 영역을 함께 적어두면 변경 신호와 수정 대상을 바로 연결할 수 있어요.
Google Apps Script의 외부 요청 기능은 공개 웹페이지나 API 응답을 가져오는 데 사용할 수 있습니다. 다만 로그인 화면, 동적 영역, 접근 제한 페이지는 제대로 읽히지 않을 수 있어요. 요청 성공과 핵심 문장의 정확한 추출은 따로 검증해야 합니다.
감시 URL과 기준값을 등록하는 방법
페이지 전체를 비교하면 광고나 추천 메뉴 때문에 알림이 많아질 수 있어요. 감시표에는 공식 URL과 함께 대상, 신청 기간, 문의처처럼 글의 결론에 영향을 주는 영역을 지정하세요.
| 기록 항목 | 적는 내용 | 확인 목적 |
|---|---|---|
| 공식 URL | 최종 안내 또는 공식 API 주소 | 출처 위치 고정 |
| 연결 글 | 재검토할 블로그 글 제목이나 관리 ID | 수정 대상 연결 |
| 중요 영역 | 대상, 기간, 금액, 신청 경로 | 메뉴 변경과 핵심 변경 구분 |
| 기준값 | 정리한 텍스트 또는 해시 | 이전 결과와 비교 |
| 확인일 | 마지막 정상 검토 날짜 | 재검증 이력 관리 |
URL만 저장하지 말고 그 페이지와 연결된 글, 확인할 항목까지 함께 기록해요.
본문 해시 비교와 오탐 줄이기
불필요한 공백과 반복 메뉴를 제거한 뒤 같은 규칙으로 본문 해시를 만들면 이전 값과 빠르게 비교할 수 있어요. 해시가 달라도 정책 변경이 확정된 것은 아닙니다. 동적 날짜나 배너가 섞이면 핵심 내용이 같아도 값이 달라질 수 있어요.
서버가 Last-Modified나 ETag 헤더를 제공하지 않을 수도 있어요. 헤더가 있어도 핵심 문장은 별도로 비교해야 합니다. 변경 전후 텍스트와 감지 시각을 저장하고, 차이가 난 항목은 검토 필요로만 표시하세요.
해시 차이는 변경 신호일 뿐이므로 핵심 문장의 전후 내용을 다시 확인해야 해요.
복사해서 쓰는 변경 검토 프롬프트
아래 프롬프트는 자동으로 사실을 확정하는 용도가 아니에요. 수집해 둔 이전 텍스트와 현재 텍스트를 비교해 사람이 확인할 질문을 만드는 초안입니다.
Apps Script 의사코드와 실행 제한
Apps Script에서는 UrlFetchApp으로 외부 URL을 요청할 수 있고, 설치형 시간 기반 트리거로 반복 실행을 예약할 수 있습니다. 설치형 트리거는 만든 사람의 계정으로 실행되며 서비스별 제한과 쿼터가 있어요. 요청 간격을 너무 짧게 잡거나 많은 URL을 한 번에 확인하면 실패할 수 있으므로 응답 상태와 오류도 기록해야 합니다.
오래된 글 재검증 체크리스트
□ 응답 코드가 정상이고 가져온 본문이 비어 있지 않은가?
□ 로그인이나 동적 화면 때문에 핵심 내용이 누락되지 않았는가?
□ 변경이 메뉴·배너·날짜 같은 오탐 후보는 아닌가?
□ 대상·기간·금액·신청 경로 중 실제로 바뀐 항목이 있는가?
□ 공식 원문과 연결 글의 문장을 직접 대조했는가?
□ 공식 출처 URL과 새 확인일을 기록했는가?
□ 수정 전 기존 문장과 변경 근거를 보관했는가?
□ 사람이 승인하기 전 자동 수정·발행하지 않았는가?
변경 신호가 난 글만 모아 공식 원문과 대조하면 전체 글을 다시 읽는 시간을 줄일 수 있어요.
자주 묻는 질문
Q. 해시가 바뀌면 블로그 글도 바로 수정해야 하나요?
아니요. 해시 차이는 페이지의 어떤 부분이 달라졌다는 신호예요. 핵심 정책이 바뀌었는지 사람이 공식 원문을 확인한 뒤 수정 여부를 결정해야 합니다.
Q. 모든 공식 페이지를 UrlFetchApp으로 확인할 수 있나요?
아니요. 로그인, 접근 제한, 동적 렌더링 방식에 따라 핵심 내용이 수집되지 않을 수 있어요. 이용 조건과 접근 가능 여부를 먼저 확인해야 합니다.
Q. 시간 기반 트리거는 얼마나 자주 실행하면 좋나요?
페이지의 변경 빈도와 서비스 쿼터를 고려해 정해야 해요. 마감이 잦은 공고와 거의 바뀌지 않는 안내 페이지를 같은 주기로 확인할 필요는 없습니다.
Q. AI가 변경 내용을 확정해도 되나요?
AI는 차이를 분류하고 확인 질문을 만드는 보조 역할이 적합해요. 날짜, 대상, 금액처럼 중요한 사실은 공식 원문에서 다시 확인하고 검증 보류 상태를 사용할 수 있어야 합니다.
공식 페이지 변경 감지는 오래된 블로그 글을 자동으로 고치는 기능이 아니라, 다시 확인할 대상을 좁히는 작업이에요. URL과 중요 영역, 기준값, 연결 글을 함께 관리하고 변경 신호가 생기면 전후 텍스트와 공식 원문을 대조하세요.
자동화의 마지막 단계는 발행이 아니라 재검토 목록이어야 합니다. 이 경계를 지키면 동적 페이지의 오탐이나 일시적인 접근 실패가 잘못된 수정으로 이어지는 일을 줄일 수 있어요.
댓글
댓글 쓰기