코딩 에이전트가 웹검색을 하면 왜 자꾸 헛다리를 짚을까

에이전트한테 코딩을 시켜본 사람이면 다 겪어봤을 거야. 라이브러리 사용법을 물으면 3년 전 튜토리얼 블로그를 물어오고, 에러 메시지를 던지면 같은 증상을 겪은 스택오버플로 질문 대신 SEO로 도배된 요약 사이트를 가져와. 정작 그 버그를 고친 머지된 PR은 검색 결과 어디에도 없어.

파이어크롤이 8월 21일 내놓은 Developer Index는 정확히 그 문제를 겨냥한 물건이야. 범용 웹검색 대신, 개발자가 실제로 답을 찾는 곳만 골라 인덱싱한 검색 API지. 인덱싱한 건 7000만 건 이상의 1차 소스 — 공개 레포의 README, 깃허브 이슈, 머지된 PR, 큐레이션된 문서 사이트, 그리고 OpenAPI 스펙.

핵심 발상은 단순해. 코드에 관한 질문의 정답은 대부분 블로그 글이 아니라 원본에 있어. 라이브러리가 어떻게 동작하는지는 소스와 README에, API 계약은 스펙 문서에, 알려진 버그와 그 수정은 이슈와 PR에 있지. 그런데 범용 검색 엔진은 그것들을 사람이 읽을 만한 콘텐츠로 취급해서 랭킹을 매기고, 그 과정에서 SEO에 최적화된 2차 가공물이 위로 올라와. 에이전트한테는 그게 독이야.

등장인물 정리 — 파이어크롤, 그리고 '에이전트용 검색'이라는 새 카테고리

파이어크롤은 원래 웹 스크래핑·크롤링 API로 이름을 알린 회사야. LLM에 웹 콘텐츠를 먹이기 좋은 형태로 바꿔주는 도구로 시작했지. 회사는 자사 고객을 15만 개 이상이라고 밝히고 있고, 명단에 쇼피파이, 캔바, 재피어, 애플, 리플릿, 알리바바, 도어대시 같은 이름을 올려두고 있어.

이 회사가 최근 하고 있는 건 스크래핑 도구에서 인덱스 사업자로의 이동이야. 스크래핑은 "네가 준 URL을 잘 긁어줄게"인데, 인덱스는 "뭘 물어봐야 할지 모를 때 어디를 봐야 하는지 내가 안다"야. 후자가 훨씬 방어하기 좋은 자리지. Developer Index 말고도 Research Index라는 자매 제품을 별도로 내놨는데, 논문·연구 자료 쪽을 같은 방식으로 커버하는 물건이야. 도메인별 전용 인덱스를 쌓아 올리는 전략이 뚜렷해.

경쟁 지형도 짚어두자. 이 자리에는 이미 여럿이 들어와 있어. Exa는 임베딩 기반 신경망 검색으로, Parallel은 에이전트용 웹 검색으로, Context7은 라이브러리 문서 전용으로, Mintlify는 문서 호스팅에서 검색으로 확장해왔어. 그리고 무엇보다 그냥 구글·빙을 붙이는 선택지가 늘 있지. 파이어크롤이 이번에 한 일의 절반은 제품 출시고, 나머지 절반은 그 경쟁자들과 자기를 같은 표에 올려놓은 것이야.

여기서 하나 짚고 넘어가야 할 게 있어. DevDex의 채점 방식에 대해 파이어크롤 제품 페이지와 외부 요약이 서로 다르게 전하고 있어. 한쪽은 모델 심판을 쓴다고, 다른 쪽은 심판 없이 결정론적으로 채점한다고 돼 있어. 이 차이는 사소하지 않은데, 모델이 채점하면 채점 모델의 편향이 결과에 섞이거든. 지금 확실히 말할 수 있는 건 쿼리 수(1179개)와 지표(recall@10)까지고, 채점 세부는 원문 벤치마크 공개분을 직접 확인하는 게 맞아.

벤치마크를 뜯어보면 — DevDex

파이어크롤은 DevDex라는 벤치마크를 함께 공개했어. 1179개의 실제 개발자 쿼리로 구성돼 있고, 레포·문서·PR을 아우르는 질문들이야. 측정 지표는 recall@10 — 상위 10개 결과 안에 정답 문서가 들어있는 비율이지.

인덱스 recall@10
Firecrawl Developer Index 0.63
Firecrawl Search 0.58
Parallel 0.57
Mintlify 0.54
Exa 0.54
일반 웹검색 0.45
Context7 (문서 전용) 0.17

가장 눈에 띄는 비교는 맨 아래 두 줄이야. 일반 웹검색이 0.45인데 Developer Index는 0.63. 18%p 차이고, 상대적으로는 40% 개선이야. 에이전트 파이프라인에서 이 정도 recall 차이는 체감이 커. 정답이 상위 10개 안에 없으면 에이전트는 그냥 없는 걸 지어내거나 엉뚱한 방향으로 몇 턴을 태우거든.

외부 경쟁자 중 가장 잘한 건 Parallel의 0.57이야. 파이어크롤은 자기가 "차선의 외부 제공사보다 약 10% 앞선다"고 표현했는데, 0.63 대 0.57이니 상대 비교로 맞는 표현이야.

Context7의 0.17은 따로 볼 필요가 있어. 이건 이 제품이 나쁘다는 뜻이 아니라 커버 범위가 다르다는 뜻이야. Context7은 라이브러리 문서만 다루는 도구인데, DevDex 쿼리에는 이슈와 PR을 찾아야 답이 나오는 질문이 잔뜩 섞여 있어. 문서만 가진 인덱스는 그런 질문에 구조적으로 답할 수가 없지. 이 표를 "Context7이 3.7배 나쁘다"로 읽으면 오독이야.

트랙별 점수를 보면 그림이 더 선명해져.

트랙 점수 무엇을 재나
Repository Discovery 0.76 이름을 모르는 상태에서 그 기능을 하는 레포 찾기
Issues & PRs 0.66 버그 리포트와 그걸 고친 PR 찾기
Documentation Lookup 0.47 how-to 질문에 답하는 문서 페이지 찾기

재밌는 역전이 있어. 가장 잘하는 게 레포 찾기(0.76)고, 가장 못하는 게 문서 찾기(0.47)야. 직관과 반대지. 보통 문서 검색이 제일 쉬울 것 같은데.

이유는 이래. 레포 발견은 신호가 풍부해 — 스타 수, 토픽 태그, README의 첫 문단, 의존성 관계가 전부 힌트야. 반면 문서 검색은 "정답 페이지가 딱 하나"인 경우가 많고, 같은 내용을 다루는 페이지가 버전별로 수십 개씩 존재해. 어느 버전의 어느 페이지가 정답인지 가리는 게 진짜 어려운 부분이야. 0.47이라는 숫자는 이 문제가 아직 안 풀렸다는 정직한 표시로 읽는 게 맞아.

신선도 — 사실 이게 진짜 승부처야

벤치마크 숫자보다 실무에서 더 중요할 수 있는 게 갱신 주기야. 파이어크롤은 대부분의 소스를 매일 갱신하고, 예시로 든 최근 항목 중에는 발행 18분 만에 인덱싱된 것도 있다고 밝혔어.

왜 이게 중요하냐면, 코딩 에이전트가 겪는 오류의 큰 축이 버전 불일치거든. 라이브러리가 지난주에 API를 바꿨는데 에이전트는 6개월 전 문서를 근거로 코드를 짜. 문법적으로 완벽하고 실행하면 터지지. 이 유형의 실패는 모델을 더 좋은 걸로 바꿔도 안 고쳐져. 인덱스가 낡았으면 모델이 아무리 똑똑해도 낡은 답이 나와.

머지된 PR을 인덱싱한다는 결정도 같은 맥락이야. 문서에 아직 안 반영된 변경사항이 가장 먼저 나타나는 곳이 PR이거든. "이 함수 시그니처가 왜 안 맞지"에 대한 답이 문서에는 없고 3주 전 머지된 PR에 있는 경우가 정말 흔해.

붙이는 방법과 필터

접근 경로가 여러 개야. CLI로는 npx -y firecrawl-cli@latest setup developer-index 한 줄이면 되고, MCP 서버로도 붙고, 파이썬·노드 SDK가 있는 REST API도 있어. 클로드 코드, 커서, 윈드서프 통합이 명시돼 있어.

무료 티어가 있는데 조건이 특이해. API 키 없이도 쓸 수 있는 키리스 무료 티어를 제공하고, 인증하면 레이트 리밋이 올라가는 구조야. 검색·스크래핑·인터랙트 기능이 키 없이 열려 있어. 도입 마찰을 극단적으로 낮춘 선택인데, 개발자 도구에서 이건 꽤 공격적인 전략이야.

필터가 실무에서 중요한 부분인데, 지원하는 축이 이래 — 타입(이슈/PR/README/문서), 레포, 언어, 토픽, 라이선스, 최소 스타 수. 라이선스 필터가 눈에 띄어. 사내 코드베이스에 참고 코드를 가져올 때 라이선스 호환성은 진짜 문제거든. GPL 코드를 참고해서 나온 결과가 상용 제품에 들어가면 골치 아파지니까. 에이전트 시대에 이 필터는 생각보다 중요해질 수 있어.

커버 범위는 넓게 잡혀 있어. 프론트엔드(Next.js, React, Vue, Svelte, Angular, Astro, Remix, Nuxt), 런타임·툴(Node.js, Deno, Bun, Vite, Tailwind, Playwright, Expo), 백엔드(Django, FastAPI, Flask, Rails, Laravel, Spring, tRPC), 언어(TypeScript, Python, Rust, Go, Swift, Kotlin, .NET, Flutter), 인프라(PostgreSQL, Redis, MongoDB, SQLite, Supabase, Prisma, 쿠버네티스, 도커, 테라폼, 클라우드플레어, 카프카, GraphQL, PyTorch).

각자의 이득

이 인덱스가 다루지 않는 것도 분명히 해두자. 사설 레포와 사내 코드는 대상이 아니야. 커버 목록에 올라온 건 전부 공개 생태계의 주요 프레임워크와 인프라 도구고, 회사 내부 코드베이스에 대한 질문은 여전히 자체 인덱싱이 필요해. 실무에서 에이전트가 헤매는 상당 부분이 사내 코드에서 발생한다는 걸 감안하면, 이건 전체 문제의 절반을 푸는 도구야.

에이전트를 만드는 팀이 가져가는 게 제일 커. recall이 올라가면 필요한 컨텍스트 검색 횟수가 줄고, 그건 곧 토큰과 지연시간이야. 에이전트가 답을 못 찾아 같은 검색을 다른 표현으로 다섯 번 반복하는 패턴은 비용 관점에서 최악인데, 그 반복이 줄어드는 게 실질 이득이지.

파이어크롤이 가져가는 건 포지션이야. 스크래핑 API는 대체 가능한 상품이지만 인덱스는 아니야. 7000만 건을 매일 갱신하는 파이프라인은 시간과 돈이 쌓여야 만들어지고, 그건 해자가 돼. 게다가 DevDex라는 벤치마크를 자기가 정의해서 공개했어. 벤치마크를 만든 쪽이 그 벤치마크에서 1등인 건 놀랄 일이 아니지만, 평가 기준을 정의하는 위치를 가져간 건 별개의 성과야.

기존 문서 검색 제품들은 압박을 받아. 특히 문서만 다루는 도구들은 표에서 구조적 열세로 보이게 됐어. 실제 용도가 다른데도 같은 표에 올라간 순간 비교당하거든.

과거 유사 사례 — 전용 인덱스는 항상 이겼나

전용 검색 인덱스가 범용 검색을 이긴 사례는 많아. 법률 검색, 특허 검색, 논문 검색은 전부 구글이 아니라 전용 서비스가 시장을 가져갔어. 도메인 지식이 랭킹에 반영돼야 하고, 사용자가 원하는 게 "인기 있는 문서"가 아니라 "정확한 문서"인 영역에서는 늘 그랬지.

반대 사례도 있어. 2000년대 후반 수직 검색 엔진이 우르르 나왔다가 대부분 사라졌어. 이유는 대체로 두 가지였어. 범용 검색이 그 영역을 충분히 잘하게 되면서 차이가 사라졌거나, 인덱스 유지 비용을 감당할 매출이 안 나왔거나. Developer Index도 같은 시험을 받게 될 거야.

다만 이번엔 조건이 좀 달라. 사용자가 사람이 아니라 에이전트거든. 사람은 검색 결과 10개를 훑고 판단할 수 있지만 에이전트는 상위 몇 개를 사실로 믿고 넘어가. recall의 가치가 사람 사용자일 때보다 훨씬 커진 거야. 그리고 에이전트는 사람보다 검색을 훨씬 많이 해. 이 두 가지가 전용 인덱스의 경제성을 예전보다 좋게 만들어.

경쟁자 카운터 플레이

Exa와 Parallel의 대응은 어렵지 않아. 둘 다 자체 평가로 반박하거나, DevDex 쿼리 분포가 파이어크롤의 인덱스 구성에 유리하게 짜였다는 점을 지적할 수 있어. 벤치마크를 만든 쪽이 1등인 구도는 언제나 이 반론에 열려 있거든. 다만 DevDex가 공개돼 있으니 반박도 데이터로 해야 해. 그 자체가 이 카테고리에 없던 규율이야.

Context7 같은 문서 전용 도구는 다른 선택지가 있어. 표에서 불리하게 보이는 건 커버 범위 차이 때문이니, "우리는 문서 정확도만 본다"는 별도 축을 세우고 그 축에서의 정밀도를 강조하는 쪽이 합리적이야. 실제로 문서 검색 트랙에서 Developer Index도 0.47밖에 못 냈으니 파고들 여지는 있어.

가장 흥미로운 대응은 깃허브 쪽에서 나올 수 있어. 파이어크롤이 인덱싱하는 것 중 상당 부분 — 이슈, 머지된 PR, README — 은 깃허브가 원본을 갖고 있는 데이터야. 깃허브가 자사 코파일럿에 같은 성격의 검색을 1급 기능으로 붙이면 데이터 소유자와 인덱서의 구도가 되지. 이런 구도에서 인덱서가 오래 버티려면 원본 소유자가 안 하는 걸 해야 하는데, 파이어크롤의 경우 그게 여러 출처를 가로질러 합치는 것이야. 깃허브 데이터에 외부 문서 사이트와 OpenAPI 스펙을 붙여 한 번에 검색하는 건 깃허브가 구조적으로 하기 애매한 일이거든.

그리고 모델 회사들도 변수야. 앤트로픽과 오픈AI 모두 자사 코딩 도구에 검색을 내장하는 방향으로 가고 있어. 이 레이어가 모델 제공사 쪽으로 흡수되면 독립 인덱스의 자리는 줄어들어. 파이어크롤이 MCP와 클로드 코드·커서·윈드서프 통합을 먼저 깔아둔 건 그 흡수보다 빨리 기본값이 되겠다는 계산으로 보여.

그래서 뭐가 달라지는데

코딩 에이전트를 붙여 쓰는 개발자라면 — 키 없이 무료 티어를 쓸 수 있으니 검증 비용이 거의 없어. 지금 쓰는 도구가 오래된 문서를 근거로 코드를 짜는 문제가 있었다면 붙여볼 만해.

에이전트 제품을 만드는 팀이라면 — 검색 레이어를 자체 구축할지 사올지 결정하는 재료가 하나 늘었어. 7000만 건 일일 갱신 파이프라인을 직접 만드는 비용을 생각하면 계산이 꽤 명확해질 거야.

개발자 도구 시장을 보는 입장이라면 — 눈여겨볼 건 벤치마크 자체야. 코딩 에이전트용 검색은 지금까지 공통 평가 기준이 없었어. DevDex가 그 자리를 가져가면 파이어크롤은 제품 순위와 무관하게 이 카테고리의 심판 자리에 앉게 돼.

문서를 관리하는 입장이라면 — 이제 문서의 독자에 에이전트가 추가됐다는 걸 전제해야 해. 버전 표기, 구조화, OpenAPI 스펙 정합성 같은 게 SEO보다 중요해지는 방향이야. 사람이 읽기 좋으라고 넣은 장식적인 서술보다, 버전과 시그니처가 기계적으로 정확한 쪽이 인덱스에서 유리해져.

오픈소스 메인테이너라면 — 이슈와 PR이 이제 검색 가능한 지식 자산으로 취급된다는 뜻이야. PR 설명에 뭘 왜 바꿨는지 한 줄 적어두는 습관이 예전보다 훨씬 큰 값어치를 갖게 됐어. 그 한 줄이 다른 사람의 에이전트가 찾아낼 유일한 근거가 될 수 있거든.

🥄 남은 궁금증 세 가지

— recall@10 0.63이면 좋은 거야? 절대 기준으로는 아직 낮아. 열 개 중에 정답이 없는 경우가 37%라는 뜻이니까. 다만 비교 대상이 전부 0.5대이고 일반 웹검색이 0.45라는 걸 감안하면 상대적으로는 확실히 앞서. 이 분야가 아직 초기라는 신호로 읽는 게 맞아.

— 자기가 만든 벤치마크에서 1등인 건 좀 그렇지 않아? 솔직히 그 지적은 타당해. 벤치마크 설계자가 자기 제품에 유리한 쿼리 분포를 고르는 건 늘 가능하거든. 다만 DevDex를 공개해뒀으니 경쟁사가 반박 데이터를 낼 수 있어. 그게 나오기 전까지 이 표는 참고 자료지 판결문은 아니야.

— 그럼 구글 검색은 이제 안 써도 돼? 그건 아니야. Developer Index는 코드·문서·이슈에 특화된 인덱스라 그 밖의 질문에는 답을 못 해. 에이전트 설계에서는 두 개를 다 붙이고 질문 유형에 따라 라우팅하는 쪽이 현실적이야.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.