내가 구축 중인 오픈 소스 AI 검색 가시성 감사 스택

대부분의 AI 검색 (AI Search) 가시성 작업은 너무 일찍 모호해집니다.

한 팀이 "ChatGPT에서 어떻게 나타날 수 있을까요?"라고 묻습니다.

그러면 작업은 곧바로 프롬프트 (prompts), 대시보드 (dashboards), 콘텐츠 아이디어, 경쟁사 확인, 브랜드 언급 스크린샷으로 건너뜁니다.

그러한 것들도 중요할 수 있습니다.

하지만 페이지 레이어 (page layer)가 엉망이라면, 나머지 시스템을 해석하기 어려워집니다. 낮은 인용률 (citation rate)은 콘텐츠 문제일 수도 있고, 크롤링 (crawl) 문제, 스키마 (schema) 문제, 엔티티 (entity) 문제, 또는 기계가 재사용할 수 있을 만큼 페이지가 충분히 명확하게 표현되지 않은 문제일 수도 있습니다.

그래서 저는 제 AI 검색 가시성 워크플로우의 오픈 소스이며 검사 가능한 레이어로 geo-audit을 구축하고 있습니다. 첫 번째 공개 버전은 의도적으로 지루합니다. LLM에게 무엇인가를 판단해 달라고 요청하기 전에, 사이트를 크롤링하고, 헤드 태그 (head tags)를 검사하며, JSON-LD를 파싱하고, 캐노니컬 URL (canonical URLs)을 확인하여 이를 반복 가능한 증명 패킷 (proof packet)으로 변환하는 것입니다. [1]

왜 결정론적 게이트 (deterministic gates)부터 시작하는가?

결정론적 체크 (deterministic checks)가 예방 가능한 노이즈를 제거하기 때문입니다.

팀이 LLM에게 특정 페이지가 "AI 검색에 좋은가?"라고 묻기 전에, 저는 더 단순한 것들을 알고 싶습니다:

경로 (route)를 가져올 수 있는가?
최종 URL이 안정적인가?
하나의 명확한 제목이 있는가?
메타 설명 (meta description)이 있는가?
캐노니컬 URL (canonical URL)이 의도된 기록 원본과 일치하는가?
눈에 보이는 H1이 있는가?
JSON-LD가 존재하는가?
JSON-LD가 파싱되는가?
명백한 noindex 또는 스키마 공백이 존재하는가?

이 중 그 어떤 것도 모델 (model)을 필요로 하지 않습니다.

그것이 핵심입니다.

AI 검색 가시성 작업은 나중에 LLM 체크가 필요하지만, 기본 레이어는 코드 수준에서 반복 가능해야 하며, 모든 변경 사항 이후에 다시 실행할 수 있을 만큼 충분히 지루해야 합니다.

무엇이 먼저 공개되었는가?

첫 번째 공개 릴리스에는 geo-audit에 두 가지 모듈인 site-crawl-lite와 head-schema-gate가 추가되었습니다. [2]

Table showing the two public geo-audit modules: site-crawl-lite and head-schema-gate, what each checks, and why each matters for AI Search visibility

site-crawl-lite는 소규모 사이트의 경로 인벤토리 (route inventory)를 제공합니다. 이는 상태(status), 최종 URL, 제목(title), 메타 설명(meta description), 캐노니컬(canonical), H1, 단어 수(word count), JSON-LD 개수 및 유형, 링크 개수, 이미지 alt 개수, 그리고 noindex 상태를 확인합니다.

head-schema-gate는 홈페이지나 대상 경로를 더 직접적으로 확인합니다: 제목, 설명, 캐노니컬, H1, Open Graph, JSON-LD 파싱 오류, Article 저자 sameAs, BreadcrumbList, 그리고 FAQPage 시그널(signals)을 점검합니다.

이 모듈들은 현재 정보 제공용 게이트 (informational gates) 역할을 합니다. 이들은 점수와 실행 항목 (action items)을 생성하지만, 기존의 복합적인 방법론 (composite methodology)을 몰래 변경하지는 않습니다.

이는 의도적인 설계였습니다.

공개 감사 도구 (public audit tool)는 새로운 점검 항목을 추가하는 동시에 점수 산정 기준 (scoring goalposts)을 옮겨서는 안 되기 때문입니다.

비밀 경계 (secrets boundary)는 어떻게 작동하나요?

공개 저장소 (public repository)에는 실제 API 키, 개인 자격 증명 (private credentials), 내부 호스트 이름, 또는 개인적인 비밀 정보가 절대 포함되어서는 안 됩니다.

저장소를 클론(clone)하는 사용자는 본인의 키를 직접 가져와 사용합니다.

결정론적 모듈 (deterministic modules)은 유료 API 없이도 실행됩니다. 만약 누군가 더 풍부한 제공업체 점검 (provider checks)을 원한다면, .env.example을 로컬의 .gitignore 처리된 .env 파일로 복사하여 자신만의 자격 증명을 설정할 수 있습니다. [[3]] [[4]]

경계는 간단합니다:

공개 저장소 (Public repo) = 안전한 코드, 문서, 플레이스홀더 (placeholders), 테스트, 그리고 신뢰 점검.

개인 작업 공간 (Private workspace) = 로컬 키, 팀 자격 증명, 설정된 제공업체, 그리고 배포 전용 증거.

이 경계는 에이전트 (agents)가 개입될 때 더욱 중요해집니다.

만약 에이전트가 비밀 정보에 손을 대지 않고도 공개 코드를 안전하게 개선할 수 있다면, 도구는 공개적으로 진화할 수 있습니다. 동일한 스택이 설정된 키를 가진 개인 환경에서 실행된다면, 개인 계층을 유출하지 않으면서도 더 풍부한 감사 (audits)를 수행할 수 있습니다.

이것이 더 넓은 스택에서 어디에 위치하나요?

저는 하나의 도구가 모든 것을 대체할 수 있다고 생각하지 않습니다.

운영 스택 (operating stack)에는 계층 (layers)이 존재합니다.

첫째, 크롤링(crawl) 및 헤드/스키마 게이트(head/schema gates)는 기술적 기준 질문에 답합니다: 사이트가 검색 엔진(search engines), 답변 엔진(answer engines), 그리고 소셜 플랫폼(social surfaces)을 위해 깔끔하게 가져오기(fetch) 및 표현될 수 있는가?

둘째, ContentOS 준비 상태는 발행 질문에 답합니다: 페이지가 발행 전 소스 팩(source pack), 주장(claims), 증거(evidence), 답변 단위(answer units), FAQ, 그리고 인간의 검토(human review)를 갖추고 있는가? \u20226\u2022

셋째, 배포 확인(distribution checks)은 권위(authority) 질문에 답합니다: Medium, LinkedIn, Habr, VC.ru, X, Substack, GitHub, 그리고 프로필 페이지들이 권위를 표준 URL(canonical URL)로 다시 전달하는가?

넷째, 측정(measurement)은 비즈니스 질문에 답합니다: 작업물이 배포된 후 프롬프트 세트(prompt sets), 인용(citations), 소스 컨텍스트(source context), 경쟁사, 그리고 다운스트림 트래픽(downstream traffic)이 변화하는가? \u20225\u2022

geo-audit은 현재 첫 번째 계층에서 가장 강력한 성능을 보입니다.

그것으로 충분합니다. 좋은 오픈 소스 기반은 검사하기에 충분히 작으면서도 실행하기에 충분히 유용해야 합니다.

첫 번째 증명(proof)에서 무엇을 발견했는가?

나는 표준 노트를 발행하기 전에 나의 사이트에 대해 두 가지 새로운 게이트를 실행했습니다.

결과는 극적인 실패가 아니었습니다. 이는 최근의 기술적 정리 이후 기준 게이트(baseline gate)가 보여주어야 할 정확한 모습입니다: site-crawl-lite는 점검된 19개 경로(routes) 전체에서 99/100를 반환했고, head-schema-gate는 홈페이지에서 94/100를 반환했습니다. \u20222\u2022

남은 노트들은 사소한 후속 조치들이었습니다: JSON-LD가 없는 경로 하나와, 이미 브레드크럼(breadcrumb) 형태의 마크업이 존재함에도 불구하고 BreadcrumbList를 권장하는 사항 하나였습니다.

이것은 유용한 신호(signal)입니다.

이는 다음 개선 사항이 공황 상태의 재작성(panic rewrite)이 아니라, 스키마 일관성 검사(schema consistency pass)라는 것을 말해줍니다.

이것이 대체하지 못하는 것은 무엇인가?

이것은 Screaming Frog, Sitebulb, Oncrawl, 로그 파일 분석(log-file analysis), 엔터프라이즈 크롤(enterprise crawls), 전체 키워드 제품군(full keyword suites), 또는 유료 브랜드 모니터링 제품을 대체하지 않습니다.

그러한 도구들은 여전히 유용합니다.

핵심(point)이 다를 뿐입니다.

저는 저장소 워크플로 (repo workflow) 내부에서 실행될 수 있고, 증거 아티팩트 (proof artifacts)를 생성하며, 비밀 정보 (secrets)를 로컬에 유지하고, 무엇을 확인했는지 정확하게 설명할 수 있는, 설치 우선적이고 에이전트 친화적이며 테스트 가능한 스택을 원합니다.

이를 통해 공개적으로 프로세스를 개선하는 것을 더 쉽게 만들고, 소스 코드를 첨부하여 해당 개선 사항에 대해 글을 쓸 수 있습니다.

다음에 구축하고 싶은 것

다음 모듈들은 화려하지 않습니다.

그것이 하나의 특징 (feature)입니다.

저는 내부 링크 그래프 (internal-link graph), 라우트 준비 상태 실행기 (route-readiness runner), 이미지 대체 텍스트 게이트 (image-alt gate), 사이트맵/피드/LLM 일관성 체크 (sitemap/feed/llms consistency checker), 그리고 ContentOS 소스 팩에서 발행 준비 점수 (publish-readiness scoring)로 이어지는 더 강력한 브리지 (bridge)를 원합니다.

제가 유지하고 싶은 패턴은 간단합니다:

결정론적 레이어 (deterministic layer)를 구축합니다.

제 사이트에서 이를 증명합니다.

코드를 공개합니다.

정전적 노트 (canonical note)를 작성합니다.

그런 다음 퍼스트 파티 페이지 (first-party page)가 기록의 원천 (source of record)이 된 후에만 아이디어를 배포합니다.

이 기사의 정전적 버전 (canonical version)은 관련 페이지와 배포 링크를 최신 상태로 유지하는 제 사이트에 있습니다. [[7]]

FAQ

geo-audit가 Screaming Frog나 Sitebulb를 대체할 수 있나요?

아니요. 이것은 검사 가능한 AI 검색 가시성 감사 레이어 (inspectable AI Search visibility audit layer)입니다. 대규모 크롤링 (crawling), 로그 파일 분석 (log-file analysis), 그리고 고급 기술적 SEO 워크플로 (technical SEO workflows)를 위해서는 여전히 엔터프라이즈 크롤러 (Enterprise crawlers)가 중요합니다.

공개 저장소에 API 키가 포함되어 있나요?

아니요. 공개 사용자는 로컬 환경 변수 (local environment variables) 또는 .gitignore 처리된 .env 파일을 통해 자신의 키를 가져옵니다. 공개 저장소에는 실제 자격 증명 (credentials)이 아닌 플레이스홀더 (placeholders)와 문서가 포함되어야 합니다. [[3]]

유료 API 없이도 도구를 실행할 수 있나요?

네. 결정론적 모듈 (deterministic modules)은 유료 API 키 없이 실행됩니다. 선택적 키를 사용하면 더 풍부한 브랜드 언급 (brand-mention), PageSpeed, 그리고 제공업체별 체크 (provider-specific checks) 기능을 사용할 수 있습니다. [[4]]

왜 크롤 (crawl) 및 헤드/스키마 게이트 (head/schema gates)부터 시작하나요?

페이지에 canonical 태그, 제목(titles), 설명(descriptions), JSON-LD 또는 크롤링 가능한 경로(crawlable routes)가 누락되어 있다면 LLM 점수 산정(LLM scoring)의 효용성이 떨어지기 때문입니다. 결정론적 검사(Deterministic checks)를 통해 먼저 방지 가능한 노이즈를 제거합니다.