"검색은 이제 사람이 아니라 에이전트에게 답한다"

안녕하세요, 아티언스 최윤희 입니다.

2026년 11월 5~6일, 미국 노스캐롤라이나 더럼에서 열린 Tech SEO Connect 2026에 다녀왔습니다. 1편에서는 DAY 1에 진행된 총 9개 세션을 중심으로, 컨퍼런스를 관통한 메시지와 세션별 핵심, 그리고 우리 실무에 바로 연결할 수 있는 시사점을 정리합니다.

Tech SEO Connect는 어떤 행사인가

Tech SEO Connect는 "Technical SEO 전문가가, Technical SEO 전문가를 위해 만든 컨퍼런스" 입니다. SEO & AI 검색에 대한 입문용 세션 없이 실무자 수준의 발표만으로 이틀을 채웁니다. 업계에서 Technical SEO 전문 컨퍼런스 중 가장 강력한 선택이라고 꼽는 이벤트이기도 합니다.

항목내용
일정2026년 11월 5일(목)~6일(금), 전야 행사 11월 4일
장소Bay 7, American Tobacco Campus, Durham, NC
규모2일 18세션, 단일 트랙
발표자Microsoft Bing, Profound, DemandSphere, JetOctopus, HubSpot, Red Hat, Peec AI, iPullRank, MobileMoxie, Locomotive, Previsible 등

올해의 공통 주제는 명확했습니다. "검색엔진은 더 이상 사람에게 링크를 주는 시스템이 아니라, AI 에이전트에게 증거를 공급하는 시스템이 되고 있다." 거의 모든 세션이 이 전제 위에서 각 발표자의 다양한 시각으로 이야기되었습니다.

DAY1을 관통한 메세지

세션들을 전반적으로 보았을때, 여섯개의 축이 보입니다.

1) 그라운딩이 새로운 최적화 대상이다

  • 검색엔진은 더 이상 사람에게 링크 목록을 주는 시스템이 아니라, AI 에이전트에게 답변의 근거(증거)를 공급하는 시스템이 되고 있다. 쿼리는 시스템이 만든 여러 하위 질문으로 쪼개지고, 페이지가 아니라 문단 단위로 증거가 선택되며, 출처와 신선도가 함께 따라간다. 그 증거 위에서 AI가 브랜드를 추천하기 때문에, 최적화 대상은 "순위"에서 "내 문단이 증거로 뽑히는가, 그 답변이 나를 권하는가"로 바뀐다.

2) 측정의 기반이 무너지고, 다시 세워지고 있다

  • Google은 SERP 수집을 막기위하여 오염된 결과까지 내보내며, LLM 사업자는 1st-party 데이터를 주지 않고, AI 대화에서 시작한 구매는 Google 브랜드 검색이나 직접 유입으로 기록된다. 대응은 "정확도"가 아니라 "정밀도와 프로세스 신뢰"다 — 같은 입력을 반복 샘플링해 패턴을 보고, 수집 시점·샘플링·오염 여부를 데이터에 대한 데이터로 남기고, 여러 소스를 공통 축으로 정렬해 삼각측량한다.

3) 콘텐츠 포맷이 영상으로 이동하고 있다

  • AI Overview의 가시성은 내 사이트가 아니라 웹 전반의 합의에서 나오고, 그 합의를 가장 쉽게 만드는 포맷이 영상이다. Google은 영상을 수익화하고 학습할 수 있기 때문에 YouTube를 상위 인용 소스로 올렸다. AIO용 영상은 트랜스크립트가 핵심이고 오래된 영상도 노출되므로, 블로그 포스트를 쓰려 할 때 한 번은 영상을 먼저 고려할 것.

이 여섯개의 축을 한 문장으로 줄여보면...

Basic Technical SEO(크롤 가능성, HTML 구조, 신선도 등)의 중요성은 오히려 커졌고, 그 위에 "에이전트가 쓸 수 있는 증거"를 얹는 것이 새로운 과제이다

DAY 1. AI가 가져가는 정보와 우리가 관측하는 데이터

Solid Ground: What AI Agents Stand On, and Why It Shifts

Krishna Madhavan — Microsoft (Bing 크롤링·인덱싱·콘텐츠 이해 파이프라인 총괄)

주요 내용

  • 전통 검색은 "매칭되는 페이지와 스니펫"을 반환하지만, 그라운딩은 태스크와 관련된 증거(evidence) 를 패시지 단위로 선택하고 출처(provenance)를 붙여 반환합니다. 훨씬 높은 기준입니다.
  • 시스템은 사용자 쿼리를 그라운딩 쿼리(팬아웃) 로 분해합니다. 이는 사용자가 입력한 쿼리와 다르며, Bing Webmaster Tools에서 볼 수 있는 그라운딩 쿼리는 "AI가 쿼리를 어떻게 처리하는지"를 확인 할 수 있는 창구 입니다.
  • 그라운딩 API 응답에는 crawled at, last updated at 같은 신선도 필드가 포함됩니다. 최종 수정일을 표기하지 않거나 변경 이력을 관리하지 않으면 불리합니다.
  • AI 가시성이 낮을 때의 5대 실수: 의도치 않은 robots 차단, CDN/WAF의 Bingbot 차단, noindex 오용, 중복·트랩 URL, 크롤 로그만 보고 인덱스됐다고 가정.
  • 세션 1주 전 발표된 Bing의 새 퍼블리셔 컨트롤: AI 학습과 AI 그라운딩을 각각 따로 허용·거부할 수 있는 페이지 단위 설정을 제공하며, 기존 noarchive/nocache는 2027년 3월 1일 이후 AI 제어 신호로 해석되지 않습니다(12월 15일 전환 창구 오픈).

실무 시사점

  • 가격·재고·스펙 같은 핵심 사실은 패시지 단위로 추출 가능한 평문 HTML로, 불필요한 텍스트로 "증거 밀도"를 희석하지 말 것
  • 클라이언트 사이트의 noarchive/nocache 사용 현황을 2027년 3월 전에 점검할 것

SEO in a Post-Google World

Vivan Marwaha — Profound (콘텐츠 리드)

주요 내용 (Profound 자체 데이터 기준)

  • AI 검색 대화의 약 20%가 커머스 의도이며, 커머스 대화는 1년 새 120% 성장했습니다. 60%는 첫 프롬프트에 브랜드를 언급하지 않고, 응답당 평균 3.7개 브랜드가 언급되며 16%는 명확한 "top pick"이 있습니다.
  • 단계별 행동: 발견 단계의 34%는 발견 안에서 맴돌고, "affordable/cheap" 같은 가격 형용사가 다른 수식어보다 3~4배 많습니다. 평가 단계로 갈수록 수치 조건(사이즈·성능)이 2배 이상 늘어납니다.
  • 숨은 전환: AI 대화에서 시작한 여정은 중앙값 5일 만에 구매로 이어지고, 사용자는 AI 답변의 링크를 클릭하기보다 직접 브랜드 사이트나 Google로 이동할 확률이 9배 높습니다. 구매자의 약 1/6은 직전 1주 내, 약 1/3은 직전 1개월 내 관련 AI 대화를 했습니다.

실무 시사점

  • 어트리뷰션에 "AI 대화 → Google 브랜드 검색 → 직접 유입" 경로를 가정하고, 브랜드 검색량·직접 유입 증가를 AI 영향 지표로 추적
  • 제품 페이지에 수치 스펙·가격 조건을 구조화하고, 실제 에이전트로 구매·비교 태스크를 테스트

Why Google Is Taking Aggressive Action on SERP Data Collection and What to Do About It

Ray Grieselhuber — DemandSphere 창업자/CEO

주요 내용

  • Google이 공격적인 이유: ① AI 검색은 질문을 여러 하위 쿼리로 쪼개 검색하는데, 그 검색 결과를 내주는 인덱스를 직접 만드는 데는 수십억 달러가 들어 상당수 AI 서비스가 Google 검색 결과를 긁어 원료로 씁니다. ② AI Overview 답변 자체를 대량 수집하면 다른 모델을 학습시킬 수 있습니다(증류). ③ 장기적으로 사람 대신 검색하는 에이전트는 광고를 클릭하지 않으므로, 이는 Google 광고 모델의 생존 문제입니다.
  • 타임라인: 2025년 1월 브라우저 자동화 필수화 → 9월 num=100 제거 → 12월 SerpApi 소송(2026년 7월 기각, 수정 제소로 진행 중) → 2026년 여름 프록시 압수와 /goto 리다이렉트 → 9월 사상 최악의 차단 → 그리고 "Poisoned SERP" — 차단 대신 그럴듯하지만 틀린 결과 페이지를 제공하는 단계.
  • DemandSphere의 대응: 상위 2~3페이지 집중, 최근 30일 데이터를 인메모리로 두고 실시간 오염 감지 후 "poison" 라벨링, 그리고 Observability — 언제 수집했는지, 샘플링됐는지, 오염됐는지를 지표화하는 "데이터에 대한 데이터".
  • "데이터를 신뢰한다 = 데이터를 만드는 프로세스를 신뢰한다." 수십만 키워드에 대해 실제 사용자와 비교할 기준은 없으므로, 우리가 하는 것은 같은 입력을 반복해 시스템 반응의 패턴을 보는 종단 모니터링입니다.
  • API/MCP에만 의존하면 데이터를 소유한 것이 아닙니다. 웨어하우징과 다중 소스 삼각측량이 필요합니다.

실무 시사점

  • 랭킹 데이터 벤더에 수집 시점·샘플링·오염 여부 메타데이터를 요구하고, 2026년 9~10월 데이터는 GSC로 교차 검증
  • 신뢰 가중치는 GSC → 랭크 트래커 → AI 가시성 툴 순으로
  • GEO 측정 툴도 같은 수집 리스크를 공유한다는 점을 클라이언트에게 미리 설명

Evergreen Crawl: See Your Site Exactly as Googlebot Saw It

Serge Bezborodov — JetOctopus 공동창업자/CTO

주요 내용

  • 전통 크롤의 문제: 직접 돌려야 하고, 대형 사이트는 끝나면 이미 낡은 데이터이며, 무엇보다 크롤러의 알고리즘대로 사이트를 보게 됩니다. Googlebot은 사이트 구조가 아니라 사용자 수요 기반으로 파도처럼 선별 크롤합니다.
  • 로그는 URL·상태코드·리퍼러 정도만 담고, 크롤은 콘텐츠·인덱스 가능성을 담지만 둘의 교집합은 일부뿐입니다.
  • 에버그린 크롤: 봇과 서버 사이의 "웨이터"가 응답 HTML을 한 모금 맛보고(파싱) 기록합니다. 추가 서버 부하 없이 항상 최신이고, 과거 시점 조회도 가능합니다. 대시보드(로그 분석·AI 봇·Googlebot·에버그린 크롤)를 오픈소스로 공개했습니다(테스트 단계).
  • 배포 전 검증과 대규모 변경은 전통 크롤("장거리 여행"), 라이브 사이트의 일상 모니터링은 에버그린 크롤("데일리 드라이버").

실무 시사점

  • Cloudflare를 쓰는 클라이언트라면 봇별 실제 응답 HTML을 저장·비교하는 구조를 검토
  • 배포 모니터링은 전통 크롤(배포 전) + 봇 응답 기반 일별 추적(배포 후)의 2단 구조로

AI Bots on Your Site: What They See, Why It Matters, and Where to Draw the Line

Lauren Green — Microsoft (Technical AI SEO Manager)

주요 내용

  • Ahrefs의 1,700만 인용 연구 기준으로 ChatGPT 인용 페이지의 평균 연령은 약 2.6년, Google AI Overview는 약 3년입니다.
  • 개발자 문서에서 읽어낸 것: OpenAI는 SearchBot과 GPTBot을 모두 허용하면 한 번의 크롤을 두 용도에 재사용하고, URL별 SLA 없이 인기도·크롤 상태에 따라 갱신합니다. Anthropic의 학습 제외 설정은 과거 학습분에 영향이 없습니다. 파라메트릭 메모리(학습 시점 지식) vs RAG(검색 증강) 의 차이가 낡은 URL이 노출되는 이유입니다.
  • T-Mobile 시절 사례: 만료된 “iPhone $800 할인” 프로모 블로그가 AI Overview에 노출돼 소셜로 확산 → 블로그 삭제와 신고로 진화. 이와 별도로, AI 리퍼러로 404에 도착한 사용자에게 “AI가 여기로 데려왔네요”라고 안내하고 내부 검색을 제공하는 다른 사이트의 사례를 소개하며 권장했습니다.
  • 4가지 실행 항목: 2년 이상 된 공식 문서 최신화(갱신/리다이렉트/폐기), 국제 봇과 로케일 페이지 점검(hreflang이 AI 인용에서도 작동하는지 확인), 커뮤니티·UGC를 학습에 넣을지 결정, robots·사이트맵 정기 감사.

실무 시사점

  • 콘텐츠 감사에 "2년 이상 + AI 리퍼러 존재" 세그먼트를 추가해 갱신/리다이렉트/폐기 결정
  • 프로모션·가격 페이지는 종료 시 즉시 처리 — AI는 만료된 프로모를 오래 기억함
  • 다국어 사이트는 AI 봇이 어느 로케일을 크롤·인용하는지 분리 측정

Video SEO to Super-Charge AIO Visibility

Cindy Krum — MobileMoxie CEO

주요 내용

  • Google은 Chrome으로 클릭 이후 행동을 기록해 여정을 모델링하고, 그 데이터가 광고까지 먹여 살립니다. YouTube가 AI 검색의 상위 인용 소스가 된 것은 사람이 영상을 좋아해서만이 아니라 Google이 수익화·학습할 수 있어서입니다.
  • Google의 BCG 의뢰 연구가 말하는 4S — Stream, Scroll, Shop, Search — 각각 YouTube·Discover·Merchant Center·검색광고로 수익화되며 모두 영상 요소가 큽니다.
  • 영상 주제 프롬프트: best / explain / review / versus / alternative to. "계란 삶는 법" 같은 지루한 주제도 YouTube에 올리면 인용됩니다.
  • AIO용 영상과 YouTube 랭킹용 영상은 다릅니다. AIO에서는 트랜스크립트가 더 중요하고, 일관성·채널 지표는 덜 중요하며 오래된 영상도 노출됩니다. 세로 숏폼은 AIO보다 Discover와 숏비디오 캐러셀에 뜹니다.
  • 진입이 두렵다면 남의 비디오 팟캐스트에 전문가로 출연 → 원본을 받아 클립으로 재배포하는 것부터.

실무 시사점

  • GEO 콘텐츠 전략에 영상 채널(YouTube 랜드스케이프 + 트랜스크립트)을 별도 트랙으로 포함
  • 이미 AIO에 노출되는 페이지부터 영상으로 전환하는 우선순위 리스트 작성

Brand Visibility Reporting When No Single Data Source Covers It

Savannah Casto — Locomotive Agency (Business Intelligence Lead)

주요 내용

  • 브랜드 가시성이 답해야 할 4가지 질문: 수요(Google Trends, DataForSEO), 대화(LLM 답변, Reddit 언급), 성과(GA4·GSC·Ads·CRM), 맥락(경쟁사).
  • 데이터가 지저분한 이유: 소스마다 지역 정보의 세분화 수준이 다르고(GA4는 도시까지, Google Trends는 주까지, AI 답변 데이터는 국가까지, Reddit은 아예 없음), 집계 주기 같은 스키마가 다르며, 브랜드명이 깨끗하게 구분되지 않습니다(“Locomotive”로 검색하면 기차가 나옵니다).
  • 파이프라인 원칙: 소스별로 켜고 끌 수 있는 개별 Cloud Run 잡, 각 소스는 최세분 위치 수준을 유지하되 공통 축(date, country, location, brand)으로 정렬, 하나의 거대 테이블 대신 용도별 테이블, Raw → BigQuery 정제 → BI.
  • BigQuery ML + Gemini로 SQL 예약 쿼리만으로 분류·점수·생성: 브랜드별 감성, 경쟁사 광고 메시지 분류(어떤 상을 언급하는지 추출 → 수상 응모 우선순위), LLM 인용 사이트 카테고리화(에이전시는 "요율 리스트" 사이트 인용이 가장 많음 → 아웃리치 기회).

실무 시사점

  • 클라이언트 GEO 대시보드에 적용할 구조: 소스별 독립 수집 → 공통 축 정규화 → 용도별 테이블 → BI
  • 브랜드명 엔티티 해소 규칙(동음이의·구 브랜드·자회사)을 명시적으로 설계
  • AI 분류를 쓸 때는 전체를 AI에 맡기지 말고, 규칙으로 결정할 수 있는 것(알려진 도메인, 경쟁사 목록 등)은 규칙으로 먼저 처리하고 규칙에 걸리지 않은 나머지만 AI에 보낼 것. AI가 분류한 결과도 일부를 뽑아 사람이 검수할 것.

When Server Logs Lie: The Wire-Level Truth Behind Googlebot's Ghost Errors

Jori Ford

주요 내용

  • 사례 — 로그도, 엔지니어도, GSC도 "정상"인데 트래픽이 사라졌다. CMS를 컴포저블 디자인으로 업그레이드하고 SEO 템플릿 검토까지 마친 뒤 출시했는데 트래픽이 급락했습니다. 서버 로그는 200, 엔지니어는 에러 없음, GSC URL 검사도 정상. 원인은 렌더링 단계의 전송 실패였습니다. 서버는 껍데기 HTML을 정상적으로 보냈기 때문에 로그에는 200이 찍혔지만, 그 뒤 JavaScript로 콘텐츠를 조립하는 과정에서 일부 데이터 전송이 지연·중단됐고, Googlebot은 빈 페이지 상태로 렌더링을 끝냈습니다. 사람의 브라우저는 기다려 주기 때문에 눈으로는 멀쩡해 보였습니다.
  • 로그는 "보냈다"를 기록하지 "도착했다"를 기록하지 않는다. 그래서 로그가 200이어도 봇이 콘텐츠를 받지 못하는 경우가 생깁니다. 발표자가 든 전형적인 패턴 세 가지: ① 응답은 200인데 실제 전송된 바이트가 기대 페이로드보다 작음 ② "connection closed"로 기록되지만 실체는 타임아웃 — 사람은 기다리지만 Googlebot은 렌더링에 5초 이상 쓰지 않음 ③ HTTPS 전환 시 TLS 핸드셰이크 중 패킷 손실로 봇만 막힘. 엣지가 빠르더라도 봇 요청이 후순위로 처리되면 봇에게만 느릴 수 있습니다.
  • 확인 방법 — 로그 대신 패킷을 본다. Screaming Frog를 List 모드·JavaScript 렌더링 ON·스냅샷 타이밍 5초로 설정해 Googlebot의 타임아웃을 흉내 내고, 동시에 Wireshark로 기기를 오가는 패킷을 캡처합니다. 문제 URL로 필터링하면 어느 스트림이 중간에 취소됐는지, 보낸 바이트와 받은 바이트가 어디서 어긋나는지 보입니다. 대형 사이트는 전체 크롤 대신 단일 URL 스크립트로 격리합니다.
  • 엔지니어를 움직이는 것은 재현 가능성이다. 엔지니어의 유닛·기능 테스트는 통과했으므로 "네 일을 안 했다"는 말은 통하지 않습니다. 관찰 내용, 도달 경로, 기대한 DOM과 실제 렌더 결과, 그리고 문제의 에셋·스트림·타임스탬프를 지목해야 합니다. 네트워크 호출은 비용이기 때문에 엔지니어가 반응하고, Core Web Vitals에는 잡히지 않는 문제일 수 있습니다.
  • 이커머스·핀테크 주의. 가상 피팅, 시각화 위젯, 계산기 같은 인터랙티브 도구는 UX와 링크빌딩에는 좋지만 크롤러에게는 트랩이 되어 크롤 예산을 먹어 치울 수 있습니다.
  • 최후 수단으로만. 패킷 분석은 수백만 줄을 필터링하는 작업이라 비용이 큽니다. 실패 페이지를 모아 패턴이 있을 때만 하고, 타임스탬프가 릴리스 시점과 맞지 않으면 릴리스 탓을 하지 말고, TLS 복호화 키를 격리해 재실행할 수 없으면 시작하지 말 것. 수정 후에는 같은 분석을 다시 돌려 고쳐졌는지 검증합니다.

실무 시사점

  • 리플랫폼·컴포저블 전환 프로젝트의 출시 체크리스트에 "5초 렌더 스냅샷 크롤" 추가
  • 로그와 GSC가 정상인데 트래픽이 급락할 때의 에스컬레이션 경로로 패킷 분석을 포지셔닝

The Philosophy Minor's Guide to Log Files

Jamie Indigo

주요 내용

  • 로그 해석에는 숨은 전제가 있다. "Googlebot이 요청했다면 로그에 남는다. 로그에 없다. 그러니 요청하지 않았다"는 논리는 구조상 타당해 보이지만, "우리가 모든 로그를 갖고 있다"는 전제 위에 서 있습니다. 실제로는 CDN 로그, 오리진 서버 로그, WAF 로그가 각각 다른 것을 기록합니다. CDN에서 응답한 요청은 오리진에 남지 않고, WAF가 차단한 요청은 오리진에 도달하지도 않습니다.
  • 봇의 정체는 '주장'과 '증명'을 구분해서 봐야 한다. User-Agent 문자열은 누구나 쓸 수 있는 자기소개라서 주장일 뿐이고, 역DNS 조회는 더 낫지만 위조될 수 있으며, 각 회사가 공개한 IP 범위와 대조하는 것이 실질적인 증명입니다. 그래서 봇은 '모름(unknown) → 의심(suspected) → 자기 선언(declared) → 검증됨(verified)' 단계로 다뤄야 하고, 검증됐다는 것도 "참"이 아니라 "현재로서는 보증됨"이며 언제든 바뀔 수 있습니다.
  • AI 크롤링은 늘고, 위장도 늘고 있다. 동일 조건 비교로 AI 크롤링은 약 3배 성장했고 학습 봇이 특히 많이 가져갑니다. 동시에 봇 검증 실패율이 상반기 대비 3분기에 크게 늘었습니다. 봇이 자신을 숨기는 방식이 바뀌고 있다는 뜻이자, "AI 가시성을 위해 봇을 다 열어두는" 사이트를 노린 접근도 늘고 있다는 뜻입니다.
  • 에이전트는 세 가지 방식으로 나타난다. ① Silent — 차단당하지 않으려고 일반 브라우저처럼 위장 ② Declared — IP 범위와 문서를 공개 ③ Signed — 요청마다 암호학적 서명을 붙여 신원을 증명(Web Bot Auth 표준, Cloudflare 등이 검증 지원). 다만 서명은 "누구인지"를 증명할 뿐 "무엇을 하려는지"는 증명하지 않습니다.
  • 새 에이전트가 나타나면 가정하지 말고 관찰하라. 문서 없이 출시된 에이전트는 테스트 페이지에 고유한 쿼리 마커를 심어 두고, CDN 엣지 로그와 오리진 로그를 모두 캡처해 실제 행동을 재현 가능하게 기록한 뒤 공식 문서와 비교합니다. "로그에 없으니 괜찮다"는 가정은 금물입니다 — 서버가 499 같은 상태를 기록하도록 설정되어 있지 않을 수도 있습니다. "AI Mode의 페치는 Googlebot인가, Gemini는?" 같은 기존 전제도 테스트 대상입니다.
  • 로그 분석용 AI 스킬은 문서가 아니라 실패에서 시작한다. 전제가 틀리면 데이터가 많을수록 더 나쁩니다. 페이지 세그먼트를 정규식으로 정의했다면 실제로 돌려보고, 틀린 것을 스킬에 기록하고, WAF 택소노미와 봇 정의가 바뀔 때마다 갱신해야 합니다. 결과물은 "주장을 넣으면 검증 가능한 쿼리로 바꿔 주는 기계"입니다.

실무 시사점

  • 봇 분석 리포트에 "어느 로그에서, 어떤 정의로" 측정했는지 항상 명시
  • 봇 허용 정책을 UA 문자열이 아니라 IP 범위 + 서명 검증 기준으로 설계 — "AI 가시성을 위해 다 열어두기"는 공격면
  • 새 에이전트 출시 시 테스트 페이지로 실제 페치 행태를 관찰하는 루틴화

마무리 하며...

DAY 1은 "검색엔진이 무엇을 반환하는가"가 바뀌었다는 이야기로 시작해(Madhavan), 그 변화가 구매 여정(Marwaha)과 측정(Grieselhuber, Casto), 그리고 봇을 보는 방법(Bezborodov, Green, Ford, Indigo)까지 어떻게 번지는지를 보여준 하루였습니다. 2편에서는 에이전틱 웹과 ChatGPT의 랭킹 구조, SEO의 역할 재정의, 마이그레이션과 AI 코딩 습관을 다룬 DAY 2 세션과, 이틀의 내용을 우리 팀의 실행 항목으로 옮긴 결과를 정리합니다.