🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Firecrawl은 /scrape에 question과 highlights 형식을 추가해, 전체 페이지를 긁어 LLM에 넣는 복잡한 과정을 한 번의 호출로 줄이고 URL 기반의 근거 있는 답변이나 원문 그대로의 발췌를 훨씬 적은 토큰으로 반환한다고 발표했다.

📌 핵심 요약

• Firecrawl은 웹페이지에서 정확한 답변이나 특정 콘텐츠를 얻기 위해 전체 페이지 스크래핑, 청킹, 자체 모델 처리, 프롬프트 엔지니어링을 직접 수행해야 했던 기존 방식을 문제로 제시한다.
• 새로운 question 형식은 URL과 질문을 전달하면 페이지 내용에 근거한 집중된 답변을 반환하며, 페이지에 답이 없으면 내용을 지어내지 않고 없다고 말하도록 설계됐다.
• highlights 형식은 URL과 쿼리를 전달하면 페이지 안에서 조건에 맞는 문장, 코드 블록, 표를 원문 그대로 반환하며, 규정 준수·코드 추출·금융 데이터 캡처처럼 출처가 중요한 작업을 겨냥한다.
• highlights는 생성형 답변을 쓰기보다 세밀하게 조정된 모델이 줄 인덱스를 선택하고 Firecrawl이 해당 원문을 재조립하는 방식이라, 문장·코드·표가 다시 쓰이거나 조작되지 않는다.
• 두 형식은 전체 스크래프보다 최대 100배 토큰 효율적이고, 관리형 LLM 스택과 자동 폴백·프롬프트 인젝션 방어를 포함해 에이전트가 더 낮은 비용과 작은 컨텍스트로 웹 데이터를 사용할 수 있게 한다.

🧩 주요 포인트

1. Firecrawl은 웹페이지에서 정확한 답변이나 특정 콘텐츠를 얻기 위해 전체 페이지 스크래핑, 청킹, 자체 모델 처리, 프롬프트 엔지니어링을 직접 수행해야 했던 기존 방식을 문제로 제시한다.
2. 새로운 question 형식은 URL과 질문을 전달하면 페이지 내용에 근거한 집중된 답변을 반환하며, 페이지에 답이 없으면 내용을 지어내지 않고 없다고 말하도록 설계됐다.
3. highlights 형식은 URL과 쿼리를 전달하면 페이지 안에서 조건에 맞는 문장, 코드 블록, 표를 원문 그대로 반환하며, 규정 준수·코드 추출·금융 데이터 캡처처럼 출처가 중요한 작업을 겨냥한다.
4. highlights는 생성형 답변을 쓰기보다 세밀하게 조정된 모델이 줄 인덱스를 선택하고 Firecrawl이 해당 원문을 재조립하는 방식이라, 문장·코드·표가 다시 쓰이거나 조작되지 않는다.
5. 두 형식은 전체 스크래프보다 최대 100배 토큰 효율적이고, 관리형 LLM 스택과 자동 폴백·프롬프트 인젝션 방어를 포함해 에이전트가 더 낮은 비용과 작은 컨텍스트로 웹 데이터를 사용할 수 있게 한다.

🧠 상세 정리

1. 기존 웹페이지 질의 방식의 부담

글은 LLM으로 웹페이지에서 정확한 답을 얻거나 특정 콘텐츠를 뽑아내려면 사용자가 지금까지 여러 단계를 직접 맡아야 했다고 설명한다. 전체 페이지를 스크래핑하고, 이를 청크로 나누고, 자체 모델에 넣고, 원하는 답이 나오도록 프롬프트 엔지니어링까지 관리해야 했다는 것이다. Firecrawl은 이 과정이 에이전트나 개발자에게 비용, 구현 복잡도, 컨텍스트 낭비를 만든다고 본다. 이번 발표의 핵심은 이 흐름을 /scrape의 새 출력 형식 두 가지로 단순화해, 전체 페이지 대신 필요한 답변이나 발췌만 받게 하는 데 있다.

2. question 형식: 페이지에 근거한 집중 답변

question 형식은 URL과 질문을 함께 넘기면 해당 페이지 내용에서 직접 끌어온 답변을 반환하는 방식이다. 예시에서는 Firecrawl의 /scrape 문서 URL에 “/scrape가 지원하는 파일 형식은 무엇인가”라는 질문을 보내고, 결과의 question 필드를 출력한다. 이 형식은 푸터, 광고, 관련 없는 문장처럼 컨텍스트 창을 채우기만 하는 요소를 제거하고 질문에 맞는 답만 제공하도록 설계됐다. 답변은 관리형 LLM이 생성하지만, 시스템은 페이지 콘텐츠에 근거하도록 지시되며 페이지에 답이 없으면 추측하지 않고 없다고 말하는 동작을 목표로 한다.

3. highlights 형식: 원문 그대로의 발췌

highlights 형식은 답변을 문장으로 새로 합성하기보다, 페이지 안에서 쿼리에 맞는 정확한 텍스트를 그대로 돌려주는 데 초점을 둔다. 사용자는 URL과 쿼리를 넘기며, Firecrawl은 일치하는 문장, 코드 블록, 표를 페이지에서 찾아 반환한다. 글은 이 형식이 규정 준수, 코드 추출, 금융 데이터 캡처처럼 결과가 데이터로 소비되고 출처가 명확해야 하는 워크플로에 적합하다고 설명한다. 원문 인용이나 증거 확보가 중요한 상황에서는 모델이 다시 쓴 요약보다, 실제 페이지에 있던 표현을 그대로 받는 것이 더 안전하고 검증 가능하기 때문이다.

4. 재조립 방식과 원문 보존 원칙

highlights는 모델이 자유롭게 산문을 생성하는 구조가 아니라, 세밀하게 조정된 모델이 관련 줄 인덱스를 선택하고 Firecrawl이 그 텍스트를 다시 조립하는 방식으로 동작한다. 같은 블록에서 이어지는 문장들은 다시 문단으로 합쳐지고, 연속된 코드 줄은 원래 언어가 보존된 fenced code block으로 감싸진다. 표의 행은 헤더를 자동으로 포함한 마크다운 표로 재구성된다. 글은 이 과정에서 아무것도 다시 쓰거나 새로 만들어내지 않는다고 강조하며, highlights가 단순 요약 도구가 아니라 출처 충실도가 높은 발췌 도구라는 점을 분명히 한다.

5. Focus 벤치마크와 품질 주장

Firecrawl은 highlights의 품질을 Focus라는 지표로 측정했다고 설명한다. Focus는 반환된 스니펫이 페이지 안의 이상적인 구간과 얼마나 정확히 맞는지 보는 기준이며, 1.0이면 정답 구간만 정확하게 반환했다는 뜻이다. 낮은 점수는 필요한 내용을 놓쳤거나 주변의 불필요한 문맥이 함께 붙어 응답이 흐려졌다는 의미로 제시된다. 1만 개 URL 테스트 세트에서 Firecrawl Highlights는 0.446점을 기록했고 Exa Highlights는 0.160점을 기록해, Firecrawl이 약 2.8배 더 집중된 결과를 냈다고 글은 주장한다.

6. 에이전트 관점의 효율성과 안전장치

글은 두 형식이 에이전트에게 중요한 이유를 근거성, 토큰 효율, 운영 편의, 보안으로 나누어 설명한다. question은 페이지 내용에서만 답하도록 설계되고, highlights는 실제 원문을 반환하므로 에이전트의 출력이 페이지에 묶여 있게 된다. 전체 페이지를 깨끗한 마크다운이나 HTML 등으로 받는 표준 /scrape와 달리, question은 답만, highlights는 관련 발췌만 반환해 수십 또는 수백 번 조회하는 에이전트의 비용과 지연 시간을 줄일 수 있다. 또한 Firecrawl은 모델 체인, 자동 폴백, 프롬프트, 재시도 로직을 관리형 스택으로 제공하며, 페이지 콘텐츠와 사용자 프롬프트를 XML 태그로 분리하고 페이지 내용을 이스케이프하며 페이지 내 지시를 신뢰하지 않도록 해 프롬프트 인젝션에 대비한다고 설명한다.

🧾 핵심 주장 / 시사점

• 이 발표의 핵심 가치는 웹페이지 전체를 LLM 컨텍스트에 넣는 방식에서 벗어나, 질문에는 근거 있는 답만, 인용에는 원문 발췌만 가져오는 더 작은 단위의 웹 데이터 사용 방식에 있다.
• question과 highlights는 모두 웹 기반 에이전트의 반복 조회 비용을 낮추려는 기능이지만, 하나는 합성된 답변, 다른 하나는 검증 가능한 원문 조각이라는 점에서 사용 목적이 뚜렷하게 다르다.
• 프롬프트 인젝션 방어를 기능 설명의 주요 축으로 포함한 것은, 웹페이지 자체가 LLM에게 악의적 지시를 포함할 수 있다는 전제를 Firecrawl이 에이전트 인프라의 현실적인 위험으로 보고 있음을 보여준다.

✅ 액션 아이템

• 기존 전체 페이지 스크래핑·청킹·프롬프트 조정 흐름을 대체해 /scrape question/highlights 단일 호출로 근거 수집 파이프라인을 재설계한다.
• highlights의 원문 재조립 동작이 문장·코드·표 보존을 지키는지 규정 준수·코드 추출·금융 데이터 케이스부터 우선 점검한다.
• 관리형 LLM 스택 연동 시 자동 폴백 및 프롬프트 인젝션 방어를 함께 적용해 토큰 비용과 컨텍스트 요구량을 단계적으로 낮춘다.

❓ 열린 질문

• 기존 스크래프 대비 question·highlights가 실제 운영 트래픽에서 최대 100배 토큰 효율을 내는 조건은 어디인가?
• highlights의 line 인덱스 선택이 실패해 원문 문장·코드·표가 왜곡되거나 누락될 가능성은 어떤 패턴에서 가장 높을까?
• 페이지에 답이 없을 때 '없다'를 반환하도록 설계한 동작이 모호한 문서에서 오탐 없이 유지되려면 어떤 임계값을 적용할 것인가?