Blog system notes 2. 검색 노출은 제출 기록까지 가야 닫혔습니다

이 글의 핵심은 검색 노출 작업을 구현, 제출, 기록, 재시도 queue로 나누어 닫은 과정입니다.

지난 글에서는 AI Survival Log의 글쓰기 원본과 사이트 결과물을 분리했습니다. wiki/에서 글을 고치고, output/blog와 ai-survival-log-site/content/posts는 다시 만들 수 있는 결과물로 두는 구조였습니다.

그 다음에 바로 남은 질문은 검색이었습니다. 글이 사이트에 올라갔다고 해서 검색엔진이 그 글을 바로 이해하거나, 바로 수집하거나, 바로 검색 결과에 보여 주는 것은 아니었습니다.

이번 글은 SEO 전체 입문서가 아닙니다. 제 블로그에서 검색 노출 운영을 어떻게 작업 단위로 나눴는지 정리합니다. 핵심은 단순합니다. 검색 작업은 코드를 넣는 순간 끝나는 것이 아니라, 어떤 URL을 언제 제출했고 무엇이 아직 남았는지 기록해야 운영이 됩니다.

코드를 넣어도 검색 운영은 끝나지 않았습니다

처음에는 사이트에 검색엔진이 읽을 신호가 부족했습니다.

기본 title과 description 정도는 있었지만, robots.txt, sitemap.xml, canonical, Open Graph, Twitter metadata, BlogPosting JSON-LD 같은 신호가 충분하지 않았습니다. 사람은 페이지를 읽을 수 있었지만, 검색엔진이 대표 URL과 글의 구조를 안정적으로 판단하기에는 부족한 상태였습니다.

그래서 먼저 기술 SEO 기반을 넣었습니다. 하지만 이 단계가 끝난 뒤에도 작업이 닫힌 느낌은 아니었습니다.

이유는 명확했습니다. 파일이 생겼다는 사실과 검색엔진이 그 파일을 봤다는 사실은 다릅니다. 검색엔진이 언젠가 발견할 수 있는 상태와, 내가 중요한 URL을 제출하고 그 상태를 추적하는 운영은 다른 일이었습니다.

먼저 검색엔진이 읽을 신호를 깔았습니다

첫 번째 단계는 사이트가 자기 구조를 설명할 수 있게 만드는 일이었습니다.

ai-survival-log-site에는 전역 metadataBase, 페이지별 canonical, robots.txt, sitemap.xml, 포스트 상세 metadata, BlogPosting JSON-LD를 추가했습니다. 절대 URL을 안정적으로 만들기 위한 site URL 유틸도 같이 정리했습니다.

이 작업의 목적은 검색 순위를 바로 올리는 것이 아니었습니다. 검색엔진이 페이지를 발견하고, 대표 URL을 고르고, 이 문서가 블로그 글이라는 최소한의 신호를 읽을 수 있게 만드는 것이었습니다.

그래서 이 단계는 검색 운영의 바닥에 가깝습니다. 바닥이 없으면 제출을 해도 어디가 깨졌는지 구분하기 어렵습니다. 반대로 바닥이 있어도 제출과 추적이 없으면 운영 상태를 설명하기 어렵습니다.

제목과 설명은 upstream에서 고쳐야 했습니다

기술 신호만으로도 충분하지 않았습니다.

기존 글을 다시 보니 제목은 블로그 톤을 갖고 있었지만 검색 질의와 직접 맞물리지 않는 경우가 있었습니다. 도입부가 감각이나 맥락으로 시작해서, 독자가 이 글이 무엇을 설명하는지 늦게 알게 되는 글도 있었습니다. 관련 글 링크도 충분하지 않았습니다.

그래서 seoTitle, seoDescription, 도입부, 관련 글 링크를 함께 정리했습니다.

중요한 판단은 이 규칙을 site repo에만 두지 않는 것이었습니다. 글의 초안과 시리즈 구조는 upstream인 ai-survival-log의 wiki/에서 먼저 결정됩니다. 검색형 제목과 설명을 나중에 site에서 덧붙이는 방식으로 두면, 다음 글에서도 같은 문제가 반복됩니다.

그래서 content SEO rule은 upstream authoring 단계의 규칙으로 옮겼습니다. 글을 쓰는 곳에서 검색 의도, 설명문, 첫 문단, 관련 링크를 같이 봐야 했습니다.

sitemap 제출과 URL 제출은 다른 일이었습니다

운영하면서 가장 중요하게 구분한 것은 sitemap 제출과 개별 URL 제출이었습니다.

둘은 비슷해 보이지만 역할이 다릅니다.

구분	쉽게 말하면	이번 운영에서 한 일
sitemap.xml	검색엔진에게 사이트 안의 URL 목록을 알려 주는 발견 신호입니다	Google Search Console과 Naver Search Advisor에 sitemap을 제출했습니다
개별 URL 제출	중요한 글을 직접 확인해 달라고 요청하는 작업입니다	Google URL Inspection과 Naver 웹 페이지 수집 요청으로 P0 URL을 제출했습니다
제출 ledger	언제 무엇을 요청했는지 남기는 운영 원장입니다	submitted, todo, blocked, stale 상태를 URL별로 기록했습니다

Google 문서에서도 개별 URL은 URL Inspection 도구로 요청하고, 많은 URL은 sitemap을 제출하라고 안내합니다. 동시에 재크롤 요청은 며칠에서 몇 주가 걸릴 수 있고, 검색 결과 포함을 보장하지 않는다고 설명합니다.

Naver 쪽도 같은 감각으로 봤습니다. Search Advisor의 웹 페이지 수집 요청은 사용자가 주요 URL을 직접 요청하는 기능이지만, 요청한다고 해서 검색로봇이 실시간으로 방문하는 것은 아닙니다. sitemap도 URL 정보를 알려 주는 표준 신호이지, 모든 URL의 즉시 수집을 약속하는 장치는 아닙니다.

그래서 이 글에서 말하는 제출은 "검색 노출을 보장했다"는 뜻이 아닙니다. "검색엔진이 확인할 수 있는 경로를 만들고, 중요한 URL에 대해 수동 요청을 남겼다"는 뜻에 가깝습니다.

P0와 P1로 나누니 제출이 작업이 됐습니다

처음에는 모든 URL을 한 번에 떠올리면 부담이 컸습니다.

그래서 URL을 P0와 P1로 나눴습니다. P0는 최신성, 검색 의도, 시리즈 연결성, 운영 가치가 높은 글입니다. P1은 sitemap으로 발견될 수 있지만, 아직 제출 evidence가 없는 다음 묶음입니다.

2026년 5월 13일에는 P0 12개 URL을 먼저 제출했습니다. 묶음은 AI 웹개발 기초 5편, AI Native 위임자 4편, Developer Automation Lab 3편이었습니다. Google은 Search Console URL Inspection의 색인 생성 요청을 사용했고, Naver는 Search Advisor 웹 페이지 수집 요청을 사용했습니다.

2026년 5월 31일에는 published 글 전체를 다시 기준점으로 잡았습니다. current published post는 39개였고, Google/Naver sheet는 current URL 39개와 stale URL 3개로 정리했습니다. 이때 Google은 current submitted 22개, todo 17개, blocked 0개, stale 3개 상태였고, Naver는 current submitted 23개, todo 16개, blocked 0개, stale 3개 상태였습니다.

이 숫자의 가치는 성과 자랑이 아니라 작업 단위화에 있었습니다. "검색이 안 되는 것 같다"는 막연한 말 대신 "P0는 어디까지 제출했고, P1은 몇 개 남았고, blocked는 없다"고 말할 수 있게 됐습니다.

ledger가 없으면 며칠 뒤에는 추측이 됩니다

검색 제출은 바로 결과가 보이지 않는 작업입니다.

며칠 뒤에 다시 확인할 때 기억에 의존하면 거의 항상 흐려집니다. 어떤 URL을 제출했는지, 어떤 URL은 public 404 때문에 보류했는지, 어떤 URL은 콘솔 할당량 때문에 재시도해야 하는지 뒤섞입니다.

그래서 URL별 ledger를 뒀습니다.

상태	의미	다음 행동
submitted	콘솔에서 수동 요청을 완료했습니다	3일, 7일, 14일 뒤 색인 또는 수집 상태를 확인합니다
todo	아직 제출 evidence가 없습니다	P0와 P1 순서로 제출하거나 재시도합니다
blocked	robots, canonical, 404, 소유권, sitemap 조건이 깨졌습니다	제출보다 사이트 문제 해결을 먼저 합니다
stale	현재 post 목록에는 없는 과거 URL입니다	새 제출 대상에서 빼고 replacement나 redirect 여부만 확인합니다

이 표가 있으면 사람의 판단 피로가 줄어듭니다.

모든 URL을 매번 다시 해석하지 않아도 됩니다. blocked는 먼저 고쳐야 하는 문제이고, todo는 아직 evidence가 없는 일이며, submitted는 기다리며 모니터링해야 하는 일입니다.

quota 초과는 장애가 아니라 재시도 queue였습니다

2026년 5월 31일 후속 작업에서 좋은 예가 하나 나왔습니다.

최신 CodeTree 글은 처음 public preflight에서 공개 URL 404와 sitemap 누락 때문에 보류됐습니다. 이후 배포를 맞춘 뒤에는 URL 200, sitemap 포함, /llms.txt 포함, canonical과 metadata 정상 상태를 확인했습니다.

그 다음 Google P0 후속 batch 11개 중 10개는 Search Console URL Inspection 요청을 완료했습니다. 남은 1개는 사이트 문제가 아니라 Search Console 요청 할당량 초과였습니다.

이 차이를 ledger에 남기는 것이 중요했습니다.

할당량 초과는 blocked가 아닙니다. 공개 URL, sitemap, canonical이 정상이라면 사이트를 고치는 일이 아니라 재시도 queue에 남겨야 하는 일입니다. 같은 todo라도 이유가 다르면 다음 행동이 달라집니다.

그래서 검색 노출은 운영 기록으로 닫힙니다

이 작업 뒤에 SEO를 보는 감각이 조금 바뀌었습니다.

예전에는 SEO를 코드나 문장 수정으로만 생각하기 쉬웠습니다. metadata를 넣고, 제목을 고치고, sitemap을 만들면 어느 정도 끝났다고 느낄 수 있습니다.

하지만 실제 운영에서는 그 다음이 더 중요했습니다.

공개 URL이 살아 있는지 확인하고, sitemap에 포함됐는지 보고, 대표 metadata와 구조화 데이터가 맞는지 확인하고, Google과 Naver에 어떤 URL을 제출했는지 남기고, 며칠 뒤 다시 볼 날짜를 잡아야 했습니다.

그래서 이 글의 결론은 단순합니다.

검색 노출 작업은 구현으로 시작하지만, 제출 기록과 재시도 queue까지 남겨야 운영으로 닫힙니다.

다음 글에서는 이 감각을 발행 직전 queue로 옮깁니다. 콘텐츠가 준비됐는지, 빌드가 통과했는지, 공개 배포와 rollback 판단이 남았는지를 한 번에 섞어 보지 않고, content queue, build queue, deploy queue로 나눠 사용자가 쉽게 판단할 수 있는 표면으로 정리합니다.