Cloudflare Browser Run 실패, HAR 파일로 재실행 전에 진단하기

Cloudflare는 2026년 9월 18일 실패한 실행을 살펴보는 방식을 바꿨습니다. 이제 완료된 Browser Run 기록에서 콘솔 로그, HAR 파일로 내보낼 수 있는 네트워크 요청, 최종 페이지 구조를 확인할 수 있습니다. 새 브라우저를 띄우기 전에 이미 비용을 들여 확보한 증거부터 진단할 수 있게 된 것입니다.

실행 후 남는 증거 묶음: HAR 파일·로그·DOM

이전에는 브라우저 작업이 끝나면 결과물과 오류 처리 내용, 그리고 Session Recording을 켜 둔 경우 리플레이만 남았습니다. 실패 원인이 드러나지 않으면 로그를 더 심은 뒤 작업을 다시 실행하는 것이 일반적이었습니다.

새 Inspect 패널은 완료된 기록 옆에 다음 세 가지 보기를 제공합니다.

• Logs에서는 수집된 콘솔 출력을 검색하고 로그 수준별로 걸러낼 수 있습니다.
• Network에서는 각 요청의 메서드, 상태, 헤더, 페이로드, 응답, 소요 시간을 볼 수 있습니다. 이 활동은 브라우저 요청 흐름의 표준 아카이브 형식인 HAR 파일로 내보낼 수 있습니다.
• DOM에서는 기록이 끝난 시점의 페이지 구조를 확인하고 복원된 HTML을 복사할 수 있습니다. DOM은 브라우저가 페이지에서 구성한 요소 트리를 뜻합니다.

이 기능은 또 하나의 실시간 디버깅 화면이 아니라 실행이 끝난 뒤 살펴보는 증거입니다. Cloudflare의 Session Recording은 동영상이 아니라 구조화된 rrweb 이벤트 데이터입니다. DOM 변경, 마우스와 키보드 이벤트, 페이지 이동을 기록합니다. Inspect 패널은 세션이 종료된 뒤 이 리플레이 주변에서 검색 가능한 단서를 제공합니다.

이 점에서 이번 릴리스는 Cloudflare가 앞서 내놓은 Browser Run 변경과 다릅니다. 세션 보호 규칙과 읽기 전용 Live View는 실행 중인 작업이 이동할 수 있는 범위와 이를 지켜보는 클라이언트가 할 수 있는 일을 통제합니다. 반면 Inspect는 완료된 작업이 왜 실패했는지 팀이 직접 설명할 수 있게 해줍니다.

브라우저 자동화에서 기록으로 어떤 실패를 밝혀낼 수 있나

브라우저 안에 흔적을 남긴 실패라면 이 패널이 브라우저 디버깅에 유용합니다.

혼자 운영하는 SaaS 창업자는 거부된 요청을 찾을 수 있습니다

정기적으로 실행하는 데이터 추출 작업이 페이지에는 도달하지만 아무 데이터도 반환하지 않는다고 가정해 보겠습니다. Network 보기에서는 API가 401을 반환했는지, 요청 제한으로 429가 발생했는지, 리디렉션이 브라우저를 엉뚱한 곳으로 보냈는지, 특정 의존성이 실행 시간 대부분을 차지했는지 확인할 수 있습니다.

임시 로그를 추가하기 전에 요청과 응답의 세부 내용을 먼저 살펴볼 수 있습니다. 그러면 첫 진단의 범위가 작아집니다. 기존 실행이 이미 드러낸 자격 증명, 백오프, 리디렉션, 느린 의존성 문제만 바로잡으면 됩니다.

에이전시 책임자는 페이지 변경과 스크립트 버그를 구분할 수 있습니다

클라이언트 워크플로는 선택자가 바뀌었거나, 로그인 페이지가 예상 화면을 대신했거나, 에셋 요청에서 오류가 나서 실패할 수 있습니다. 최종 DOM과 복사한 HTML은 브라우저가 실제로 어느 화면에서 끝났는지 보여줍니다. 요청 흐름을 보면 그 화면까지 어떻게 도달했는지도 알 수 있습니다.

구현팀에 넘길 자료도 구체적이 됩니다. 이제 “자동화가 깨졌다”는 말 대신 최종 요소 트리와 사용 가능한 헤더, 페이로드, 상태, 소요 시간이 담긴 HAR 파일을 전달할 수 있습니다.

플랫폼 엔지니어는 문제가 생긴 탭을 따라갈 수 있습니다

기록은 target-1 같은 Chrome DevTools Protocol 대상별로 이벤트 배열을 구분하며, 각 대상은 일반적으로 브라우저 탭 하나를 나타냅니다. 여러 탭을 기록하면 이 대상들이 따로 표시되고, 대시보드의 Inspect 패널은 선택한 탭을 따라갑니다.

인증 전환과 에이전트 워크플로에서는 이 구분이 중요합니다. 로그인 탭은 성공했지만 실제 작업 탭은 실패할 수 있기 때문입니다. 대상별 증거를 보면 서로 다른 두 흐름을 뒤섞지 않을 수 있습니다.

작업 한 번을 기록하고 네트워크 추적 가져오기

기록은 명시적으로 켜야 합니다. 브라우저 세션을 처음 확보할 때 활성화해야 하며, 기존 세션에 다시 연결하면서 나중에 켤 수는 없습니다.

가장 작게 시작하려면, 현재 실패할 때마다 수동 재현이 필요한 정기 Browser Session 하나를 고르면 됩니다.

1. 1

   실행할 때 기록 활성화하기

   Cloudflare의 Puppeteer 예제는 최초 실행 호출에 recording: true를 전달합니다. 브라우저를 닫기 전에 세션 ID를 보관해야 합니다.

   import puppeteer from "@cloudflare/puppeteer";
   
   interface Env {
   	MYBROWSER: Fetcher;
   }
   
   export default {
   	async fetch(request: Request, env: Env): Promise<Response> {
   		const browser = await puppeteer.launch(env.MYBROWSER, { recording: true });
   		const page = await browser.newPage();
   
   		await page.goto("https://example.com");
   		// ... your automation steps ...
   
   		const sessionId = browser.sessionId();
   		await browser.close();
   
   		return new Response(`Session recorded: ${sessionId}`);
   	},
   };

   Playwright도 같은 실행 옵션을 사용합니다. CDP 연결이라면 WebSocket URL에 recording=true를 넣습니다.

2. 2

   완료된 기록 요청하기

   세션이 종료되면 세션 ID로 기록을 요청합니다.

   curl https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID> \
     -H "Authorization: Bearer <API_TOKEN>"

   응답의 이벤트 배열은 result.events 아래에 들어 있습니다. target-1 같은 키가 네트워크 요청에 필요한 대상 ID입니다. 새 기록은 Cloudflare가 처리를 마치는 동안 잠시 404를 반환할 수 있습니다. 첫 404를 기록 누락으로 판단하지 말고 조회를 다시 시도해야 합니다.

3. 3

   대상의 원시 요청 가져오기

   기록 응답에 포함된 대상 하나를 선택합니다. target 매개변수는 필수입니다.

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>' \
     -H "Authorization: Bearer <API_TOKEN>"

   사용 가능한 요청과 응답 세부 정보가 담긴 수집 요청을 JSON으로 돌려줍니다.

4. 4

   HAR 파일로 내보내기

   개발자가 브라우저 네트워크 뷰어나 다른 분석 도구에서 추적을 확인해야 한다면 format=har를 추가합니다.

   curl 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/recording/<SESSION_ID>/network?target=<TARGET_ID>&format=har' \
     -H "Authorization: Bearer <API_TOKEN>"

   이 파일은 접근 경로가 짧은 디버그 산출물로 취급해야 합니다. 문서에 명시된 응답에는 사용 가능한 헤더와 페이로드가 포함될 수 있으므로, 작업 데이터와 같은 수준으로 다루는 편이 안전합니다.

첫 실패가 발생한 뒤에야 기록을 켜는 실수를 하기 쉽습니다. 이미 지나간 실행에서는 거슬러 올라가 확인할 증거가 없습니다. 다음 실패가 중요한 정기 작업부터 기록을 시작해야 합니다.

브라우저 요금보다 더 큰 비용이 있습니다

Cloudflare의 현재 Browser Run 요금에는 기록이나 기록 저장에 대한 별도 요금이 없습니다. 기록된 Browser Session도 일반적인 브라우저 사용 시간과 동시 실행 요금에 포함됩니다. Session Recording은 베타이므로 이를 영구적인 약속이 아니라 현재 공개된 가격으로 봐야 합니다.

Workers Free에는 하루 10분의 브라우저 사용 시간과 동시 브라우저 세 개가 포함됩니다. Workers Paid는 계정당 월 최소 $5이며, 브라우저 사용 시간 10시간과 동시 브라우저 10개를 포함합니다. 이후 추가 브라우저 사용 시간당 $0.09, 일별 최대치의 월평균을 기준으로 추가 동시 브라우저당 $2가 부과됩니다.

진단을 위한 재실행 한 번의 직접 비용은 미미하지만, 그 전후에 드는 인력 비용은 그렇지 않습니다. 아래는 Cloudflare 벤치마크가 아니라 계획을 위한 가정입니다.

• 계정은 이미 포함된 브라우저 사용 시간 10시간을 모두 썼습니다.
• 정기 작업 한 번은 10분이 걸리고 한 달에 12번 실패합니다.
• 실패를 재현하고 진단할 때마다 운영자 시간 20분이 듭니다.
• 기존 기록을 살펴보는 데는 운영자 시간 5분이 듭니다.
• 운영자 시간의 총비용은 시간당 $75로 가정합니다.
• 기록 점검으로 진단용 재실행 한 번을 피하더라도 수정 사항을 검증하기 위한 실행은 나중에 필요할 수 있습니다.

이 차이에서 순수 브라우저 비용은 18센트뿐입니다. 나머지 $225는 운영자 시간입니다. 또한 Cloudflare는 청구 주기의 사용량을 모두 합산한 뒤 계정 수준에서 브라우저 사용 시간을 반올림합니다. 따라서 10분 실행에 해당하는 1.5센트가 청구서에 별도 항목으로 표시될 것이라고 보아서는 안 됩니다.

이것이 비즈니스에 미치는 실질적인 영향입니다. Inspect 패널이 브라우저 컴퓨팅 비용을 크게 줄여주는 것은 아닙니다. 대신 사고 대응 과정에서 계측하고, 재현하고, 기다리는 한 차례의 순환을 없앨 수 있습니다.

기록으로 확인할 수 없는 것

기록은 문서 상태와 이벤트를 수집할 뿐, 렌더링된 모든 픽셀을 담지는 않습니다.

이러한 한계에 걸리는 실패에는 다른 진단 방법이 필요합니다. Canvas에 그린 차트, 타사 iframe 안의 결제 양식, 동영상 상태, WebGL 장면, 마스킹된 필드에 입력한 값은 주변 기록이 정상으로 보여도 잘못되어 있을 수 있습니다.

DOM 보기 역시 기록이 끝난 시점의 구조를 보여줍니다. 작업이 마지막에 도달한 페이지는 설명할 수 있지만, 앞선 모든 상태를 픽셀 단위로 정확히 재현한 스크린샷은 아닙니다.

운영상의 제한도 있습니다. 기록은 30일 동안 제공되며, 길이는 최소 1초에서 최대 2시간입니다. launch() 또는 CDP를 이용한 Browser Session에서 작동하고 Quick Actions에서는 만들 수 없습니다. DOM이 자주 바뀌는 페이지는 변경될 때마다 데이터가 생기므로 이벤트 스트림이 매우 커질 수 있습니다.

지금 워크플로를 바꿔야 하는 팀은 어디인가

Puppeteer, Playwright, CDP 정기 작업을 운영하고 실패할 때마다 가장 먼저 누군가가 재현부터 한다면 이번 주에 적용할 만합니다. 모든 작업이 아니라 하나에만 기록을 추가한 뒤, 그 기록이 첫 진단 질문에 답하는지 측정해 보세요.

중요한 상태가 주로 Canvas, WebGL, 미디어, 교차 출처 iframe, 마스킹된 양식 필드에 있다면 기다리는 편이 낫습니다. 기록만으로는 이를 대체할 수 없으므로 스크린샷, 애플리케이션 로그, 목적에 맞춘 계측을 계속 사용해야 합니다.

Quick Actions만 사용한다면 이번 변경의 영향은 없습니다. 기록만을 위해 Browser Session으로 옮기면 구현 방식이 달라지고 요금 모델에 동시 실행 항목도 추가됩니다. 디버깅상의 이점이 이 전환을 정당화하는지 따져봐야 합니다.

월요일에 바로 할 일

반복해서 실패한 정기 Browser Session 하나를 고릅니다. 최초 실행에 recording: true를 추가하고, 자체 작업 ID 옆에 세션 ID를 저장한 뒤 다음 예약 실행이 정상적으로 종료되게 둡니다.

그런 다음 기록을 가져와 처음으로 관련 있는 대상 ID를 선택하고 원시 네트워크 추적이나 HAR 파일을 요청합니다. 실패한 요청이나 최종 페이지 상태를 특정하는 데 걸린 시간을 재보세요. 이 증거로 진단용 재실행 한 번을 줄였다면 해당 작업의 기록을 계속 켜 두고 추적을 사고 기록에 포함합니다. 도움이 되지 않았다면 기록을 다시 끄고 실제 사각지대에 부족한 신호를 추가합니다.

플랫폼 변경을 운영자 관점에서 풀어낸 글을 더 받아보려면 뉴스레터를 구독하세요.