나는 타겟 쿼리에 대해 Google에서 1위를 차지하는 기사를 가지고 있습니다. 1위, 즉 스크롤을 내리기 전 첫 화면(above the fold)에 위치한 곳으로, SEO 관점에서는 문 바로 옆에 있는 주차 공간과 같습니다. 나는 그것이 자랑스러웠습니다. 깔끔한 헤딩(headings), 내부 링크(internal links), 그리고 1년간의 인내라는 지루한 방식으로 얻어낸 결과였으니까요.

그런 다음 Brave에서 동일한 쿼리를 검색했습니다. 내 기사는 5페이지에 있었습니다. 5페이지라니요. 2019년의 포럼 스레드 어딘가 아래, URL들이 애도조차 받지 못한 채 죽어가는 곳 말입니다.

정말로 쓰라렸던 부분은 몇 분 후에 일어났습니다. 내 터미널에서 실행 중인 Claude Code에게 해당 주제를 조사하고 좋은 출처를 인용해 달라고 요청했습니다. 결과로 세 개의 링크가 돌아왔습니다. 그중 내 것은 하나도 없었습니다. 내가 직접 만들고 내 머신에서 실행되는 나의 에이전트가 내가 쓴 기사를 찾을 수 없었던 것입니다. 에이전트는 Brave를 검색하고 있었고, Brave에서 나는 존재하지 않았습니다.

Same article shown as #1 on Google and page 5 on Brave, with an AI agent failing to find it

Google과 Brave는 같은 웹을 보고 있지 않다

여기서 본능적으로 드는 생각은 Brave가 그저 Google의 더 작고 투박한 거울일 것이라고 가정하는 것입니다. 하지만 그렇지 않습니다. Brave는 완전히 별개의 크롤링(crawl)을 통해 구축된 자체 인덱스(index)와 고유한 랭킹 로직(ranking logic)을 운영합니다. 내 페이지가 한 곳에서는 1위이고 다른 곳에서는 5위라고 말하는 것은 오류를 설명하는 것이 아닙니다. 나는 우연히 같은 행성을 공유하고 있는 두 개의 서로 다른 웹 지도를 설명하고 있는 것입니다.

Brave의 인덱스는 사이드 프로젝트가 아닌 실제 인프라입니다. 이는 Google 및 Microsoft와 완전히 독립적으로 400억 개 이상의 페이지를 커버하며 매일 1억 개 이상의 페이지를 새로고침합니다. 흥미로운 점은 어떻게 최신 상태를 유지하느냐 하는 것입니다. 신호의 상당 부분은 Web Discovery Project에서 옵니다. 이는 사용자들이 실제로 방문하는 페이지에 대한 익명 데이터를 공유하기로 선택한 수천만 명의 Brave 브라우저 사용자들로부터 나옵니다. 따라서 순수하게 백링크(backlinks)와 일반적인 SEO 메커니즘에 따라 순위를 매기는 대신, Brave는 인간이 실제로 도달하는 페이지에 의존합니다.

이 점을 생각해보면, 제가 겪었던 '5페이지 문제(page 5 problem)'가 왜 그렇게 정확하게 설명되는지 알 수 있습니다. 제 기사가 Google에서 상위권에 올랐던 이유는 Google의 메커니즘에 맞춰 최적화했기 때문입니다. 하지만 Brave에서는 전혀 순위에 오르지 못했는데, 이는 Brave의 별도 인덱스(index)가 제 글의 존재를 인지하고 있는지 단 한 번도 확인해 본 적이 없었기 때문입니다. 저는 잘못된 시험을 위해 공부하면서 그 시험에서 A를 받고 있었던 셈입니다.

내가 전혀 사용하지 않는 검색 엔진이 AI의 탐색 여부를 결정하는 이유

이 지점부터는 단순한 호기심의 문제를 넘어, 제 수입과 직결된 문제가 됩니다.

2025년 5월, Microsoft는 Bing Search API를 은퇴한다고 발표했으며, 이는 2025년 8월 11일에 완전히 종료되었습니다. 수년 동안 수많은 AI 도구와 제3자 검색 서비스들이 내부적으로 Bing의 API를 기반으로 작동해 왔습니다. 서비스가 중단되었을 때, 명확한 대체재는 보이지 않았습니다. Google은 그라운딩(grounding)이나 RAG(검색 증강 생성)를 위해 개발자들에게 실제 웹 인덱스를 개방하지 않으며, Google의 Programmable Search Engine은 더 좁은 목적을 위해 만들어졌습니다. 스크레이퍼(scraper) 기반의 API들(Tavily, Exa 및 기타 서비스들)은 결국 자신들이 소유하지 않은 인덱스에 의존하게 되며, 이는 타인의 차단 정책, 가격 책정, 서비스 약관(terms-of-service) 리스크를 그대로 떠안아야 함을 의미합니다.

결국 대규모로 운영 가능한 독립적인 상업용 웹 검색 API는 단 하나, Brave만이 남게 되었습니다. Brave의 최고 비즈니스 책임자(CBO)는 이러한 변화를 개발자들에게 "시장에서 유일한 독립적 검색 API"를 제공하는 것이라고 설명했는데, 이번만큼은 마케팅 문구가 단순히 현재의 지형을 묘사하고 있을 뿐입니다.

그러니 그 연쇄 과정을 따라가 보십시오. AI 코딩 에이전트(AI coding agents)는 웹 검색이 필요합니다. 그들이 실제로 구매할 수 있는 독립적인 웹 검색 API는 Brave의 것입니다. 따라서 에이전트들은 Brave를 검색합니다. Cursor, Cline, Windsurf 모두 웹 조회(web lookups)를 위해 Brave를 사용하며, Anthropic은 Claude MCP 데모 서버 중 하나로 Brave Search를 가장 먼저 출시했습니다. 또한 Brave는 에이전트 툴체인(agent toolchains)에 내장되는 기본 웹 검색 제공업체로서 그 비중이 점점 커지고 있습니다. 사용량 기준 상위 AI 기업들은 모두 학습(training) 또는 추론(inference) 단계에서 Brave Search를 접하고 있습니다.

Flow from your content into Brave's index and out to AI agents like Claude Code, Cursor, Cline, and Perplexity

단도직입적으로 말해서, Brave의 인덱스(index)는 점점 늘어나는 AI 에이전트들의 정문 역할을 하고 있습니다. 만약 당신의 콘텐츠가 그 인덱스에 없거나, 있더라도 5페이지에 있다면, 그 에이전트들은 절대로 사용자에게 그 콘텐츠를 전달하지 않을 것입니다. 당신이 Google에서 1위 결과일지라도, 엔지니어들이 무언가를 조사하기 위해 실제로 사용하는 도구들에게는 기능적으로 보이지 않는 존재가 될 수 있습니다. 저 또한 제 노트북에서 그랬습니다.

LLM Context API는 구조화된 데이터(structured data)를 먼저 읽지만, 우리 대부분은 이를 제공하지 않았습니다

2026년 2월, Brave는 LLM Context API를 출시했으며, 이는 "인덱싱된다는 것"의 의미 자체를 바꾸어 놓았습니다. 기존의 웹 검색 API는 인간에게 필요한 것, 즉 제목, URL, 클릭할 수 있는 스니펫(snippet)을 반환했습니다. 반면 LLM Context API는 모델에게 필요한 것, 즉 프롬프트(prompt)에 바로 넣을 수 있도록 미리 청크(chunk)로 나뉘고 순위가 매겨진 콘텐츠 조각들을 반환합니다. 이 API는 이미 Brave Search 내부에서 하루 2,200만 개 이상의 답변을 생성하는 데 사용되고 있습니다.

모든 블로그 운영자가 주목해야 할 세부 사항은 추출(extraction) 단계에 있습니다. API가 당신의 페이지에서 콘텐츠를 가져올 때, JSON-LD 스키마(schemas)와 표(tables)를 행 수준의 세밀함(row-level granularity)으로 보존하며, 추출 과정에서 해당 구조화된 데이터를 우선시합니다. 한 보고서는 이를 아주 직설적으로 표현했습니다. 이제 이것은 선택 사항이 아닙니다.

따라서 만약 귀하의 페이지가 깔끔한 TechArticle 또는 FAQPage JSON-LD를 제공한다면, API는 작성자, 헤드라인, 발행일 및 핵심 주장(key claims)을 깔끔하게 추출하여 모델에 직접 전달할 수 있습니다. 만약 실제 답변이 9번째 단락에 파묻힌 채 <div 태그의 덩어리(soup)로만 제공된다면, API는 더 많은 노력을 기울여야 하며 귀하의 페이지는 구조화 작업을 미리 수행한 페이지에 밀리게 됩니다. 스키마(Schema)는 이제 Google 리치 스니펫(rich snippets)을 위한 '있으면 좋은 것(nice-to-have)'이 아닙니다. 그것은 귀하의 콘텐츠가 읽히는 형식이 되었습니다.

그리고 이 이야기가 마치 제가 거대 모델의 승리를 예고하려는 것처럼 들리기 전에, Brave는 그 반대를 말하는 벤치마크를 발표했는데, 이는 제가 올해 읽은 것 중 가장 고무적인 내용입니다.

"데이터 품질이 모델 성능을 이긴다"는 이제 느낌이 아닌 측정된 결과입니다

Brave는 1,500개의 쿼리에 대해 쌍체 비교 평가(pairwise evaluation)를 실시했습니다. 채점자 역할을 하는 Claude Opus와 Sonnet이 판단하였으며, 위치 편향(position bias)을 제거하기 위해 각 쌍을 두 가지 순서로 모두 점수 매겼습니다. 핵심 결과는 다음과 같습니다. 오픈 웨이트(open-weight) 모델인 Qwen3를 기반으로 작동하는 그들의

이것은 제가 LLMO Framework에서 구축해 온 프레임워크 작업과 관련하여 계속해서 되돌아오게 되는 부분입니다. 저는 이를 인덱스 측면의 수정(index-side fixes)을 위한 표준 플레이북(canonical playbook)으로 취급하는데, 그 내용은 바로 모델이 아니라 모델에게 전달하는 데이터를 최적화해야 한다는 점을 명확히 공식화하고 있습니다. Brave의 벤치마크는 제가 발견한 것 중 이 아이디어를 가장 깔끔하게 증명하는 외부 증거입니다.

나의 '5페이지 문제'에 대해 실제로 취한 조치

진단부터 시작하십시오. 비용이 들지 않을 뿐만 아니라 유익한 방식으로 겸손함을 일깨워주기 때문입니다.

1. Brave에서 직접 검색해 보세요. search.brave.com에 접속하여 본인의 기사 제목과 타겟 쿼리(target queries)를 실행해 보세요. 그 결과를 Google과 비교해 보십시오. 제가 처음 이 작업을 했을 때, 저의 "상위 랭킹" 포스트 중 세 개가 Brave의 초기 몇 페이지 어디에도 나타나지 않았고, Google이 묻어버렸던 포스트 하나가 Brave에서는 상단 근처에 자리 잡고 있는 것을 발견했습니다. 두 인덱스(indexes)는 직접 확인해 보기 전까지는 믿기 힘들 정도로 서로 다릅니다.
2. 에이전트에게 당신을 찾아달라고 요청해 보세요. Claude Code나 Brave 기반의 도구를 열고, 특정 주제를 조사하고 출처를 인용해 달라고 요청한 뒤, 당신의 URL이 나타나는지 확인해 보세요. 이것이 진정한 테스트입니다. 왜냐하면 이것이 에이전트를 통한 독자(reader-via-agent)가 밟게 될 정확한 경로이기 때문입니다. 저의 경우 실패했습니다. 그 실패가 바로 이 글이 존재하는 이유 전체입니다.
3. JSON-LD를 서버 사이드 렌더링(server-rendered) 방식으로 배포하세요. 저자, 헤드라인, 날짜, 설명을 포함한 TechArticle 및 FAQPage 스키마(schema)를 추가하고, 크롤러와 LLM 컨텍스트 API(Context API)가 실제로 이를 볼 수 있도록 반드시 서버 사이드에서 렌더링되도록 하십시오. JavaScript가 실행된 후에만 나타나는 클라이언트 주입형 스키마(Client-injected schema)는 인덱스가 절대 읽지 못하는 스키마입니다.
4. 추출을 위한 구조화(Structure for extraction). 깔끔한 헤딩 계층 구조(heading hierarchy), 비교를 위한 실제 <table> 요소, 기술적인 내용에 대한 펜스 코드 블록(fenced code blocks)을 사용하세요. LLM 컨텍스트 API는 이를 행(row) 수준 및 블록(block) 수준의 정밀도로 추출합니다. 깨끗한 블록을 제공하면 깨끗하게 추출될 것이고, 엉망인 상태로 제공하면 건너뛰게 될 것입니다.

이 중 어느 것도 생소한 것이 아닙니다. 대부분은 Google이 어쨌든 보상을 해주었기에 제가 건너뛰었던 위생(hygiene) 관리의 문제입니다. 저는 "1위 달성"이라는 결과가 "2014년 스타일의 구조화"보다 우선하도록 방치했습니다. 하지만 Brave 인덱스(index)는 그런 관용을 베풀지 않습니다.

불편한 요약

수년 동안 "Google에서 순위를 올린다"는 말은 그 자체로 완결된 문장이었습니다. 하지만 이제는 불완전한 문장이 되었습니다. Google은 여전히 인간 검색의 약 90%를 점유하고 있으므로 SEO(검색 엔진 최적화)가 죽은 것은 아니며, 제가 그것을 불태워버리라고 말하는 것도 아닙니다. 하지만 인간의 검색과 에이전트(agent)의 검색은 이제 서로 다른 레일 위에서 작동하며, 에이전트 레일은 점점 더 Brave를 통해 지나가고 있습니다. Google만을 위해 최적화하는 것은 AI 도구들이 실제로 쿼리(query)하는 인덱스 상에서는 아무런 이득도 가져다주지 못합니다.

해결책은 그로스 해킹(growth hack)이 아닙니다. Brave로 가서 직접 검색해 보고, 에이전트가 당신을 찾지 못하는 것을 지켜본 다음, Brave의 인덱스가 보상하는 구조화되고 깨끗하며 추출 가능한 콘텐츠를 제공하는 것입니다. 저는 Google에서 1위를 차지했음에도 불구하고 제 자신의 에이전트가 저를 인용하게 만들 수 없었습니다. 이를 해결하는 것은 제가 전혀 사용하지 않았던 검색 엔진이 그동안 조용히 제 숙제를 채점해 오고 있었다는 사실을 인정하는 것부터 시작되었습니다.

JSON-LD 패턴과 AI 엔진이 왜 완벽하게 좋은 페이지들을 계속 무시하는지를 포함하여, 이 인덱스 측면에 대한 전체 구현 플레이북(playbook)을 원하신다면, llmoframework.com에서 작업 중인 버전을 확인하실 수 있습니다.