🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Firecrawl의 Lockdown Mode는 /scrape 요청을 기존 캐시 인덱스에서만 처리해 외부 웹 요청과 데이터 보존을 차단하는 보안 중심 스크래핑 모드다.

📌 핵심 요약

• Lockdown Mode는 보안에 민감한 워크로드를 위해 Firecrawl이 제공하는 캐시 전용 /scrape 모드로, lockdown: true 또는 CLI의 --lockdown 플래그 하나로 활성화된다.
• 핵심 목적은 LLM 에이전트가 사용자 입력에 따라 임의 URL을 스크랩할 때 발생할 수 있는 프롬프트 인젝션 기반 데이터 유출과 규제 환경의 외부 호출 통제 문제를 줄이는 것이다.
• 활성화되면 대상 URL로 직접 연결하지 않고 Firecrawl의 기존 인덱스에서만 결과를 제공하며, 캐시에 없으면 실시간 스크랩으로 전환하지 않고 SCRAPE_LOCKDOWN_CACHE_MISS 오류를 반환한다.
• Lockdown 요청에는 기본적으로 ZDR 의미가 적용되어 URL과 응답이 저장되지 않고 작업도 전달 직후 정리되며, HTTP 엔진·robots.txt 조회·검색 인덱스 쓰기·오디오 변환 같은 외부 경로가 엔진 레벨에서 차단된다.
• API, SDK, CLI, MCP 서버에서 동일하게 사용할 수 있지만 /scrape에만 적용되며, 최신 데이터가 필요한 경우나 캐시에 없는 URL에는 적합하지 않다.

🧩 주요 포인트

1. Lockdown Mode는 보안에 민감한 워크로드를 위해 Firecrawl이 제공하는 캐시 전용 /scrape 모드로, lockdown: true 또는 CLI의 --lockdown 플래그 하나로 활성화된다.
2. 핵심 목적은 LLM 에이전트가 사용자 입력에 따라 임의 URL을 스크랩할 때 발생할 수 있는 프롬프트 인젝션 기반 데이터 유출과 규제 환경의 외부 호출 통제 문제를 줄이는 것이다.
3. 활성화되면 대상 URL로 직접 연결하지 않고 Firecrawl의 기존 인덱스에서만 결과를 제공하며, 캐시에 없으면 실시간 스크랩으로 전환하지 않고 SCRAPE_LOCKDOWN_CACHE_MISS 오류를 반환한다.
4. Lockdown 요청에는 기본적으로 ZDR 의미가 적용되어 URL과 응답이 저장되지 않고 작업도 전달 직후 정리되며, HTTP 엔진·robots.txt 조회·검색 인덱스 쓰기·오디오 변환 같은 외부 경로가 엔진 레벨에서 차단된다.
5. API, SDK, CLI, MCP 서버에서 동일하게 사용할 수 있지만 /scrape에만 적용되며, 최신 데이터가 필요한 경우나 캐시에 없는 URL에는 적합하지 않다.

🧠 상세 정리

1. Lockdown Mode의 출시와 핵심 메시지

이 글은 Firecrawl이 보안에 민감한 스크래핑 작업을 위해 Lockdown Mode를 출시했다는 내용을 소개한다. Lockdown Mode는 /scrape 엔드포인트에 적용되는 캐시 전용 모드이며, 요청을 Firecrawl 내부의 기존 인덱스에서만 처리한다. 글의 핵심은 단순한 옵션 추가가 아니라, 외부 웹 요청 자체를 발생시키지 않는 방식으로 스크래핑 워크플로를 제한한다는 점이다. 사용자는 API, SDK, CLI, MCP 서버 등 /scrape를 사용할 수 있는 표면에서 동일한 플래그로 이 기능을 쓸 수 있다.

2. 문제의식: 외부 요청이 만드는 유출 경로

본문은 먼저 일반적인 실시간 스크랩이 제3자 원본 서버로 나가는 외부 요청이라는 점을 문제로 제시한다. 대부분의 워크로드에서는 이 방식이 괜찮지만, LLM 에이전트가 어떤 URL을 스크랩할지 결정하는 상황에서는 프롬프트 인젝션이 위험해질 수 있다. 공격자는 민감한 문맥을 URL 경로, 쿼리 문자열, 헤더 등에 끼워 넣어 자신이 제어하는 서버로 보내게 만들 수 있다. 또한 의료, 금융, 법률, 정부처럼 외부 호출의 승인과 기록이 필요한 조직에서는 모든 라이브 스크랩이 감사와 통제의 부담이 된다.

3. 작동 방식: 캐시에 있으면 제공하고 없으면 실패

Lockdown Mode는 lockdown: true를 전달하면 Firecrawl의 기존 인덱스에서만 결과를 가져오는 방식으로 작동한다. 대상 URL에 직접 연결하지 않고, robots.txt를 가져오지 않으며, 검색 인덱스 쓰기나 오디오 변환도 수행하지 않는다. URL이 캐시에 있으면 사용자는 해당 결과를 받지만, 캐시에 없으면 SCRAPE_LOCKDOWN_CACHE_MISS 오류가 반환된다. 글은 이 실패가 의도된 동작이라고 설명하며, 실시간 스크랩으로 조용히 되돌아가지 않기 때문에 사용자는 캐시 미스 여부를 즉시 알 수 있다.

4. 보안 보호: 엔진 레벨 차단과 기본 ZDR

Firecrawl은 Lockdown Mode에서 외부 작업을 여러 설정의 조합이 아니라 하나의 감사 가능한 지점에서 차단한다고 설명한다. HTTP 엔진, robots.txt 조회, 검색 인덱스 쓰기, 오디오 변환 같은 외부 경로가 같은 플래그에 의해 엔진 레벨에서 비활성화된다. 또한 모든 Lockdown 요청에는 자동으로 ZDR 의미가 적용되어 URL은 영구 저장되지 않고 응답도 저장되지 않는다. 스크랩 작업은 결과 전달 직후 정리되며, 표준 ZDR 가격 추가분도 면제된다고 본문은 밝힌다.

5. 지원 범위와 주요 사용 사례

Lockdown Mode는 POST /scrape에서 JSON으로 lockdown: true를 넘기는 방식뿐 아니라 Python, Node, Go, Rust, Java, .NET, Ruby, PHP, Elixir SDK에서도 사용할 수 있다. CLI에서는 firecrawl scrape --lockdown 형태로 제공되며, MCP 서버에서도 같은 플래그와 같은 동작을 사용한다. 본문은 별도 버전 요구사항이나 추가 설정 없이 /scrape를 호출할 수 있으면 사용할 수 있다고 설명한다. 사용 사례로는 규제 산업의 문서·규제 페이지·파트너 사이트 스크래핑, LLM 에이전트의 임의 외부 요청 방지, URL 자체가 민감한 워크플로, 원본을 다시 치지 않는 결정적 재생이 제시된다.

6. 제약과 주의점

본문은 Lockdown Mode가 모든 상황을 대체하는 기능은 아니라고 분명히 한다. 캐시 미스가 발생하면 새 스크랩을 수행하지 않고 오류를 반환하므로, 특정 URL을 Lockdown Mode로 제공하려면 먼저 일반 스크랩을 한 번 실행해 캐시를 채워야 한다. 또한 캐시 결과는 최대 2년 전 내용일 수 있어 뉴스 피드, 실시간 가격, 대시보드처럼 최신성이 중요한 데이터에는 적합하지 않다. lockdown이 활성화되면 actions, waitFor, 사용자 지정 헤더, 프록시 설정, changeTracking 같은 충돌 옵션은 무시되며, 현재는 /crawl, /map, /search가 아니라 /scrape에서만 지원된다.

🧾 핵심 주장 / 시사점

• 이 기능의 핵심 가치는 스크래핑 품질 향상보다 외부 네트워크 호출을 아예 차단해 LLM 에이전트의 데이터 유출 경로를 줄이는 데 있다.
• 캐시 미스 시 라이브 스크랩으로 자동 전환하지 않는 설계는 사용성보다 보안과 감사 가능성을 우선한 선택이다.
• Lockdown Mode는 이미 인덱싱된 안정적 자료를 재사용하는 워크플로에는 적합하지만, 최신성과 상호작용이 필요한 스크래핑에는 의도적으로 맞지 않는다.

✅ 액션 아이템

• 임의 URL 스크랩 입력이 허용된 플로우는 /scrape만 사용하고 lockdown: true 또는 --lockdown을 기본값으로 둔다.
• 캐시 미스 시 실시간 스크랩 전환 없이 SCRAPE_LOCKDOWN_CACHE_MISS를 반환하도록 예외 처리를 고정해 운영한다.
• 최신 데이터가 필요한 경우 Lockdown 범위를 제외해 /scrape 외부 수집 경로로 분기시키고 업데이트 요건을 분리한다.

❓ 열린 질문

• 캐시 의존 수집에서 최신성이 급한 업무는 어떤 기준으로 Lockdown 적용 대상을 제한할 것인가?
• URL·응답이 저장되지 않는 ZDR 모드에서 사고 대응을 위해 필요한 로그 최소 범위는 어디까지인가?
• HTTP 엔진·robots.txt·검색 인덱스 쓰기·오디오 변환이 차단될 때 API/SDK/MCP 중 가장 먼저 사용자 지연이 발생하는 지점은 어디인가?