Zero Data Retention Across Firecrawl Search, Scrape, and More

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Firecrawl은 Enterprise의 페이지 콘텐츠 처리 엔드포인트 전반에 Zero Data Retention(ZDR)을 제공하며, 검색의 전체 경로 보장과 익명화 모드, 에이전트 결과의 24시간 보관 예외를 구분한다.

📌 핵심 요약

• ZDR은 Enterprise 팀별 활성화 기능으로, /scrape, batch scrape, /crawl, /parse, /search, /interact, /agent를 지원한다. 요청이나 세션이 끝나면 처리한 콘텐츠·추출 데이터·검색 질의와 결과를 폐기하지만, 에이전트 결과는 실행 완료 후 24시간 동안 조회할 수 있고 이후 삭제된다.
• 검색의 end-to-end ZDR은 Firecrawl과 상위 검색 공급자 모두 데이터를 보관하지 않는 모드다. 익명화 ZDR은 Firecrawl이 보관하지 않지만 공급자가 식별 정보를 제거한 질의를 캐시할 수 있으며, 표준 요금은 결과 10개당 각각 10크레딧과 2크레딧이다. Enterprise 계약에는 다른 가격이 적용될 수 있다.
• Firecrawl Alexandria의 자체 인덱스는 약 4,300만 건의 논문 초록을 담은 Research Index, 코드 저장소·문서의 7,000만 개 이상 페이지를 담은 Developer Index, 미국 페이지 3,000만 개를 담은 Government & Legal Index로 구성된다. 자체 인프라에서 검색하므로 제3자 검색 엔진이 개입하지 않으며, Government & Legal Index 검색은 ZDR 여부와 관계없이 무료다.
• 일반 엔드포인트는 zeroDataRetention: true, 검색은 enterprise: ["zdr"] 또는 enterprise: ["anon"]으로 설정한다. ZDR이 활성화되지 않은 팀의 요청은 실패하며, /agent에는 Scrape ZDR과 Search ZDR이 모두 필요하다. /interact는 세션을 여는 첫 호출에서 설정해야 하고, Lockdown Mode는 기존 인덱스만 조회해 외부 요청을 막으며 기본적으로 ZDR을 적용한다.
• Firecrawl은 SOC 2 Type II 준수 상태이며 갱신이 진행 중이라고 설명하고, 미국 인프라에서 고객 데이터를 처리한다. Enterprise에는 DPA·맞춤형 MSA와 접근·네트워크·감사 통제를 제공하며, Trust Center에서 보안 자료를 요청할 수 있다. 자체 네트워크 안에서 처리가 필요한 팀은 기능 범위가 더 작은 오픈소스 엔진을 자체 호스팅할 수 있다.

🧩 주요 포인트

1. 보존 정책의 적용 범위와 예외 → Enterprise 활성화 여부, 엔드포인트별 설정, 에이전트 결과의 24시간 조회 기간을 함께 확인해야 실제 데이터 보관 조건을 판단할 수 있다.
2. 검색 경로와 가격의 차이 → end-to-end ZDR과 익명화 ZDR은 상위 검색 공급자의 보관 허용 범위가 다르며, 자체 인덱스는 제3자 검색 엔진을 거치지 않아 검색 대상과 보안 심사 요구가 모드 선택에 영향을 준다.
3. 보관·외부 전송·처리 위치의 구분 → ZDR은 데이터 보관을 제한하고 Lockdown Mode는 외부 요청을 제한하며, 미국 인프라 처리와 자체 호스팅의 차이는 별도의 배치 요건으로 검토할 필요가 있다.

🧠 상세 정리

1. ZDR의 적용 범위와 24시간 예외

Firecrawl은 Enterprise 플랜에서 페이지 콘텐츠를 처리하는 /scrape, batch scrape, /crawl, /parse, /search, /interact, /agent 전체에 Zero Data Retention을 제공한다고 설명한다. 기본 원칙은 요청을 메모리에서 처리하고 응답을 전달한 뒤 입력과 출력을 폐기하는 것으로, FAQ에서는 요청 또는 세션의 수명을 보관 경계로 표현한다. /scrape·/crawl·/parse에서는 페이지와 문서 콘텐츠 및 추출 데이터가 대상이며, /interact에서는 페이지 콘텐츠와 실행 출력, /search에서는 질의와 검색 결과가 포함된다. /agent에서는 프롬프트와 각 단계의 콘텐츠 및 결과가 대상이지만, 결과에는 별도 예외가 있다. 에이전트 결과는 실행 완료 후 사용자가 가져갈 수 있도록 24시간 동안 조회 가능하게 유지되고, 그 시간이 지나면 삭제된다.

2. 요청 정보 자체가 민감하다는 도입 배경

원문은 웹 데이터 API가 가져오는 본문뿐 아니라 요청에 들어가는 URL과 검색 질의 자체도 민감한 정보라고 강조한다. 펀드의 에이전트가 방문하는 URL은 실사 대상 기업을, 연구 에이전트의 질의는 검토 중인 약물·소송 대상·인수 건을 드러낼 수 있다는 사례를 든다. 따라서 페이지 콘텐츠가 유출되지 않더라도 요청 로그가 남는 것만으로 은행·병원 조직·법률회사에는 부담이 될 수 있다는 주장이다. 기업 구매에서는 출력 품질 평가에 앞서 데이터가 어디로 이동하는지 확인하는 조달 심사가 첫 관문이 되며, ZDR과 서명된 DPA, Trust Center의 정책 자료가 그 질문에 대응한다. Firecrawl은 도입 규모의 근거로 15만 개 이상 기업과 150만 명 이상 사용자, Fortune 100의 67% 이용, 오픈소스 저장소의 GitHub 스타 18만 개 이상을 제시한다.

3. 검색 API의 두 경로와 보장 수준

원문은 검색 API가 자체 검색을 수행하지 않고 소비자 검색 엔진으로 질의를 전달한다면, API 사업자가 자신의 사본을 삭제해도 전체 경로의 무보관을 보장할 수 없다고 지적한다. 소비자 검색 엔진이 질의를 기록하고 순위 개선이나 모델 학습에 활용하기 때문에, 자사 저장 여부와 모든 하위 처리자의 저장 여부는 서로 다른 주장이라는 설명이다. Firecrawl의 end-to-end ZDR은 enterprise: ["zdr"]로 지정하며, Firecrawl과 상위 검색 공급자가 모두 질의와 결과를 저장하지 않는다고 명시한다. 익명화 ZDR은 enterprise: ["anon"]으로 지정하며, Firecrawl은 보관하지 않지만 공급자는 사용자를 식별하는 정보를 제거한 질의를 캐시할 수 있다. 전체 처리 경로의 무보관이 필요한 심사에는 전자를, 계정과 연결된 Firecrawl 측 보관 금지가 요구되는 경우에는 후자를 선택하도록 안내한다. 표준 요금은 결과 10개당 각각 10크레딧과 2크레딧으로 익명화 모드가 5분의 1이며, Enterprise 계약에서는 다른 가격을 정할 수 있다.

4. 직접 수집과 Alexandria 자체 검색 인덱스

Firecrawl은 /scrape, /crawl, /parse, /interact에서는 자체 브라우저가 페이지를 가져와 렌더링하고 Markdown 또는 JSON으로 반환하므로, 검색 공급자로 이어지는 별도의 경로 문제가 없다고 설명한다. 이 데이터는 하나의 ZDR 시스템 안에서 처리된 뒤 요청이 끝나면 폐기되며, Enterprise용 스크래핑 ZDR은 2025년 7월부터 제공해 왔다고 밝힌다. 오픈 웹 검색과 달리 Firecrawl Alexandria의 자체 인덱스 조회도 회사가 운영하는 인프라에서 수행되어 제3자 검색 엔진이 개입하지 않는다. 인덱스는 약 4,300만 건의 논문 초록을 담은 Research Index, 코드 저장소와 문서에서 모은 7,000만 개 이상 페이지의 Developer Index, 미국 페이지 3,000만 개의 Government & Legal Index로 구성된다. Government & Legal Index 검색은 ZDR 적용 여부와 관계없이 무료라고 명시한다.

5. 요청별 설정과 실패 조건

스크래핑·배치 스크래핑·크롤링·파싱·상호작용·에이전트에는 zeroDataRetention: true를 전달하고, 검색에는 enterprise: ["zdr"] 또는 enterprise: ["anon"]을 전달해 ZDR을 요청한다. 검색 결과까지 스크래핑하는 요청에서는 enterprise 매개변수가 검색 부분과 이어지는 모든 스크래핑에 ZDR을 전달하므로 두 번째 플래그가 필요하지 않다. 팀에 ZDR이 활성화되지 않았다면 이를 적용하지 않은 채 실행하는 대신 요청이 실패하도록 설계되어 있다. /interact는 이 경우 403을 반환하고, /agent는 zdr_not_enabled 코드와 함께 400을 반환한다. 에이전트 실행은 작업 중 검색과 스크래핑을 모두 수행하므로 팀에 Scrape ZDR과 Search ZDR이 함께 활성화되어 있어야 한다. /interact는 세션을 여는 첫 호출에서 ZDR을 설정하면 이후 세션이 이를 상속하지만, ZDR 없이 시작한 세션을 나중에 전환할 수는 없다.

6. Lockdown Mode가 제한하는 외부 전송

Lockdown Mode는 /scrape에서 기존 인덱스의 캐시 결과만 제공하고 대상 사이트로 외부 요청을 보내지 않는 모드다. 모든 Lockdown 요청에는 기본적으로 ZDR이 적용되어 URL과 응답을 저장하지 않고 전달 후 작업을 정리하며, 통상적인 ZDR 추가 크레딧도 면제한다. 원문은 ZDR이 Firecrawl에 무엇이 남는지를 제한하는 반면, Lockdown Mode는 Firecrawl 인프라 밖으로 무엇이 나가는지를 제한한다고 구분한다. AI 에이전트가 스크래핑 URL을 선택할 때 프롬프트 인젝션이 URL 경로나 쿼리 문자열을 통해 문맥을 외부로 내보내도록 유도할 수 있는데, 기존 인덱스만 사용하면 그 전송 경로가 닫힌다는 설명이다. 규제 산업의 팀은 에이전트가 선택한 URL에는 Lockdown Mode를, 승인된 출처의 실시간 스크래핑에는 ZDR을 적용하는 방식으로 두 기능을 함께 원할 수 있다고 제시한다.

7. 보안 심사를 위한 계약과 증빙 자료

Firecrawl은 SOC 2 Type II를 준수하고 있으며 갱신이 진행 중이라고 밝히고, 고객 데이터는 미국에서 처리한다고 명시한다. Enterprise 고객은 DPA와 맞춤형 MSA를 체결할 수 있고, 공개된 하위 처리자 목록에는 변경 전 사전 통지가 제공된다. Trust Center는 인프라·조직·제품·데이터 보안의 현재 통제를 확인하는 출발점으로 제시된다. 이곳에서는 SOC 2 Type II 보고서와 최신 침투 테스트, 접근 통제·데이터 관리·정보 보안·제3자 관리 정책을 요청할 수 있다. 하위 처리자 페이지를 구독하면 새로운 하위 처리자가 고객 개인정보를 취급하기 전에 소식을 받을 수 있다고 설명한다. ZDR은 Enterprise 팀별로 활성화하므로 필요한 엔드포인트와 검색 모드를 Enterprise 페이지나 [email protected]로 전달하고, 보안 자료 요청도 병행하도록 안내한다.

8. 추가 통제와 자체 호스팅의 경계

Firecrawl은 어떤 클라이언트가 API를 호출하든 적용되도록 신원·네트워크·감사 통제를 서버에서 집행한다고 설명한다. SSO와 SCIM은 Okta, Entra ID, Google Workspace 등을 통한 SAML·OIDC 로그인과 디렉터리 동기화를 지원하며, IP 제한과 고정 IP는 API 키의 허용 IP·CIDR 범위 설정 및 전용 IP 경유를 제공한다. API 키는 특정 엔드포인트와 출력 형식으로 제한할 수 있고 키별·팀별 지출 상한도 설정할 수 있으며, Threat Protection은 조직이 통제하고 잠글 수 있는 정책에 따라 위험한 URL의 수집을 차단한다. SIEM 감사 로깅은 Microsoft Sentinel부터 시작해 각 스크래핑의 구조화된 감사 이벤트를 전달하고 ZDR 팀의 이벤트를 표시한다. PII 삭제는 redactPII: true로 스크래핑·파싱 출력의 개인식별정보를 전달 전에 제거하며, 페이지당 4크레딧이 추가된다. 이러한 관리형 통제를 사용해도 데이터 처리는 Firecrawl의 미국 인프라에서 이루어지므로, 자체 네트워크 내부 처리가 필요한 팀에는 기능 범위가 더 작은 오픈소스 엔진의 자체 호스팅을 대안으로 제시한다.

🧾 핵심 주장 / 시사점

• 검색 API의 무보관 주장은 Firecrawl 자체 보관 여부와 상위 검색 공급자까지 포함한 보관 여부를 나누어 읽어야 한다. 익명화 ZDR은 공급자의 익명 질의 캐시를 허용하므로 end-to-end ZDR과 보장 범위가 같다거나 단순한 가격 차이라고 해석할 수 없다.
• ZDR은 엔드포인트 전반에 제공되지만 적용 조건은 동일하지 않다. 에이전트의 24시간 결과 보관, 검색에서 후속 스크래핑으로 전달되는 설정, 상호작용 세션의 시작 시점 설정이 실제 운영 조건을 결정한다.
• 데이터 보관 금지, 외부 요청 제한, 자체 네트워크 내부 처리는 서로 다른 요구다. ZDR·Lockdown Mode·자체 호스팅을 구분하면 보안 통제를 제공한다는 설명과 실제 처리 위치 및 기능 제약을 함께 평가할 수 있다.

✅ 액션 아이템

• Enterprise 팀의 ZDR 활성화 여부와 엔드포인트별 설정을 확인하고, /agent의 Scrape ZDR·Search ZDR 동시 활성화 및 24시간 결과 보관 예외를 검토.
• 검색 심사 요구에 따라 end-to-end ZDR과 익명화 ZDR의 보관 범위 및 결과 10개당 10크레딧·2크레딧의 표준 요금 차이를 비교.
• 데이터 보관·외부 요청·처리 위치 요건을 구분해 ZDR, Lockdown Mode, 미국 인프라 처리와 자체 호스팅의 적합성을 검토.

❓ 열린 질문

• 에이전트 결과를 실행 완료 후 24시간 동안 조회 가능하게 보관하는 예외가 필요한 데이터 보관 조건을 충족하는가?
• 검색 심사는 상위 검색 공급자까지 무보관을 보장하는 end-to-end ZDR을 요구하는가, 아니면 익명 질의 캐시를 허용하는 익명화 ZDR로 충족되는가?
• 미국 인프라에서의 데이터 처리가 허용되는가, 아니면 기능 범위가 더 작은 자체 호스팅으로 자체 네트워크 내부 처리 요건을 충족해야 하는가?