Cloudflare Workflows의 새 7일 기본값: 성공·오류 기록 설계법

Cloudflare Workflows 기본값만 바뀌었고 상한은 그대로입니다

Cloudflare Workflow는 대기나 재시도 중에도 상태를 잃지 않는 단계형 작업입니다. 플랫폼은 작업을 이어갈 수 있을 만큼의 상태를 저장하고, 작업이 완료되거나 오류로 끝난 뒤에도 일정 보존 기간 동안 해당 인스턴스를 유지합니다.

이렇게 남은 인스턴스는 운영 과정의 증거가 됩니다. Cloudflare 인스턴스 API에서는 상태, 매개변수, 출력, 단계별 세부 정보, 시도 내역, 실행 시간, 오류를 확인할 수 있습니다. 예전에 실행한 결제 대사, 고객 데이터 가져오기, 게시 작업이 실패했다면 무슨 일이 있었는지 재구성할 때 이 기록이 핵심 단서가 됩니다.

9월 변경 사항의 범위는 세 가지로 정리됩니다.

• 9월 10일 이후에 생성한 Workers Paid Workflow는 완료 및 오류 인스턴스 상태의 기본 보존 기간이 7일입니다.
• 기존 Workflow에는 현재 보존 방식이 그대로 적용됩니다. Cloudflare는 이전 Workflow의 보존 기간을 소급해 줄이지 않았습니다.
• Workers Free는 기본값과 상한 모두 3일로 유지됩니다.

Paid에서는 여전히 상태를 최대 30일까지 보관할 수 있습니다. Cloudflare가 낮춘 것은 기본값이지 최댓값이 아닙니다.

이 차이를 알면 문서 사이의 어색한 충돌도 풀립니다. 요금 페이지는 7월 21일에 마지막으로 업데이트됐으며, 여전히 Paid 기본값을 30일로 안내합니다. Workers API 레퍼런스는 8월 12일에 업데이트됐고, 보존 설정을 생략하면 계정 최댓값을 사용한다고 설명합니다. 두 페이지 모두 9월 10일 변경 로그보다 앞서 작성됐습니다.

따라서 더 최근에 발표된 구체적인 규칙을 기준으로 삼아야 합니다. 새 Paid Workflow의 기본값은 7일입니다. 기존 Paid Workflow는 바뀌지 않았고, Paid 상한은 여전히 30일입니다.

이제 7일은 인시던트 대응 시한입니다

중요한 것은 7일이 짧게 느껴지는지가 아닙니다. 팀이 중요한 장애를 일곱째 날 전에 발견하느냐입니다.

결제나 주문 작업을 운영하는 백엔드 책임자는 지원팀이나 재무팀이 기록을 대사할 때가 돼서야 불일치를 접할 수 있습니다. 그때 이미 보관 기간이 끝났다면 외부 거래 기록은 남아 있어도, 실행 경로를 설명해 줄 Workflow의 단계별 시도 내역과 오류 정보, 출력은 사라졌을 수 있습니다.

SRE가 빠지기 쉬운 함정도 있습니다. Cloudflare에서는 Workflow 메트릭을 31일 동안 조회할 수 있지만, 이 분석 기간과 상세 인스턴스 상태의 보존 기간은 서로 다릅니다. 메트릭으로 장애 이벤트가 발생했다는 사실은 확인할 수 있습니다. 그렇다고 오래된 인스턴스의 매개변수, 출력, 시도 내역, 오류까지 여전히 남아 있다고 볼 수는 없습니다.

이는 AI 에이전트 장애 분석 툴에도 그대로 적용되는 운영 원칙입니다. 증거 보존 기간은 장애가 발생한 시점부터 누군가 그 중요성을 알아차리는 시점까지의 지연에 맞춰야 합니다.

에이전시의 기술 책임자에게 가장 큰 위험은 정책의 불일치입니다. 변경 전에 만든 장기 운영 고객 Workflow는 기존 기간을 유지하지만, 변경 후 새로 만든 대체 Workflow는 별다른 안내 없이 7일이 적용될 수 있습니다. 코드 경로가 같아 보여도 고객 런북은 틀릴 수 있습니다.

Workflow 실행 기록은 성공과 오류로 나눠 보관하십시오

Cloudflare가 두 가지 제어값을 제공하는 데는 이유가 있습니다.

• successRetention은 성공적으로 완료된 뒤 상태를 보관하는 기간입니다.
• errorRetention은 오류가 발생하거나 종료된 뒤 상태를 보관하는 기간입니다.

성공한 실행의 최종 비즈니스 결과는 주문 행, 객체 키, 발송 메시지 ID, 완료된 가져오기 기록처럼 다른 곳에 남는 경우가 많습니다. 외부 시스템을 최종 기준으로 삼는다면, 성공 기록은 즉각적인 지원과 재실행 확인에 필요한 짧은 기간만 남겨도 충분할 수 있습니다.

오류 실행은 다릅니다. 완료되지 못한 경로 자체가 중요한 경우가 많습니다. 조사 담당자에게 필요한 정보는 실패한 단계, 이전 시도, 입력 매개변수, 중간 출력일 수 있습니다. 장애가 늦게 드러날 수 있다면 모든 성공 실행을 똑같이 오래 보관하는 것보다 오류 보존 기간을 길게 잡는 편이 타당합니다.

공식 변경 예시도 두 경로를 명확히 나눕니다.

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

이는 예시일 뿐, 어디에나 적용되는 권장값은 아닙니다. 오류 보존 기간은 현실적으로 장애를 발견하고 조사하는 데 걸릴 수 있는 최장 시간을 기준으로 정해야 합니다. 성공 보존 기간은 실제 결과가 기준 시스템에 기록된 뒤 운영자가 Workflow 기록을 얼마나 오래 필요로 하는지에 맞추면 됩니다.

활성 상태를 분리해야 스토리지 비용 계산이 맞습니다

Cloudflare는 Workflow 스토리지를 GB-month 단위로 과금합니다. Workers Paid에서는 첫 1 GB-month가 포함되며, 초과 스토리지는 GB-month당 $0.20입니다. Cloudflare는 30일 청구 기간 동안 매일 기록한 최대 스토리지의 평균으로 사용량을 계산합니다.

스토리지 합계에는 실행 중, 대기 중, 오류 발생, 완료 상태의 인스턴스가 모두 포함됩니다. 따라서 종료된 상태의 보존 기간을 줄이면 완료 상태 스토리지는 감소할 수 있지만, 아직 실행 중이거나 대기 중인 작업의 상태까지 없어지는 것은 아닙니다.

현재 요금 페이지에는 Workflows 단계 및 스토리지 과금이 2026년 8월 10일부터 적용된다고 나옵니다. 앞서 나온 7월 과금 공지는 과금이 해당 날짜보다 일찍 시작되지는 않는다고만 안내했습니다. 현재 페이지로 공개된 과금 시작일은 분명해졌지만, 특정 계정의 다음 청구서에 무엇이 표시될지까지 보장하는 근거는 아닙니다.

아래는 명시적인 가상 모델입니다. Cloudflare 벤치마크도 아니고, 절감액을 약속하는 계산도 아닙니다.

실행량이 일정한 상태에서 성공한 실행이 새로 보존되는 상태를 매일 1 GB씩 추가한다고 가정하겠습니다. 실행 중이거나 대기 중인 인스턴스는 두 시나리오 모두에서 0.5 GB-month를 더합니다. 성공 보존 기간의 효과만 떼어 보기 위해 오류 상태 스토리지는 비교에서 제외합니다. errorRetention을 30일로 유지한다면 해당 상태를 측정해 양쪽에 같은 오류 기록 항목으로 더해야 합니다.

모델상 차이는 $4.60입니다. 그래서 입력값을 분명히 밝혀야 합니다. 단계 출력이 아주 작은 팀은 절감액이 거의 없을 수 있습니다. 반대로 실행량이 많고 큰 결과를 저장하는 Workflow라면 보관된 성공 상태의 비중이 훨씬 클 수 있습니다. 새 기본값은 배수를 바꾸지만, 실제 청구액을 결정하는 것은 상태 크기와 완료율입니다.

반드시 알아야 할 한계

Paid의 최댓값은 여전히 30일입니다. 고객이나 규제기관의 문제 제기 또는 월별 대사에서 그 기간이 지난 뒤 문제가 드러날 수 있다면 Workflows 인스턴스 상태만 아카이브로 삼아서는 안 됩니다. 필요한 최소한의 증거를 별도의 보존 및 접근 정책을 갖춘 시스템으로 내보내야 합니다.

오류 보존 기간이 길어지면 오류 상태도 더 많이 저장됩니다. 올바른 정책은 "오류를 영원히 보관"하는 것이 아닙니다. 인시던트를 발견하고 재구성할 만큼 보관한 뒤, 인스턴스 ID, Workflow 버전, 타임스탬프, 상태, 민감 정보를 제거한 오류, 영향을 받은 비즈니스 객체처럼 오래 유지할 핵심 기록만 간결하게 남기는 방식이 적절합니다.

성공 보존 기간을 짧게 잡으려면 전제 조건도 필요합니다. 성공 결과가 이미 신뢰할 수 있는 곳에 저장돼 있어야 합니다. 어떤 동작이 일어났다는 유일한 기록이 Workflow 출력뿐이라면, 이를 더 빨리 삭제할수록 스토리지와 증거가 함께 줄어듭니다.

마지막으로 인스턴스별 재정의는 정책을 파편화할 수 있습니다. 생성 경로가 여러 개인 에이전시는 대시보드 기본값을 올바르게 설정하고도 특정 호출자만 다른 기간을 요청하게 만들 수 있습니다. 보존 정책은 대시보드 설정에만 둘 것이 아니라 코드 리뷰, 런북, 비용 모델에도 반영해야 합니다.

지금 해야 할 일

9월 10일 이후 Paid Workflow를 만들었거나, 장애가 7일 뒤에야 담당자에게 전달될 수 있거나, 완료 상태가 스토리지 비용에서 눈에 띄는 항목이라면 이번 주에 조치하십시오. 성공 보존과 오류 보존을 따로 설정해야 합니다.

아직 실행량이 적은 파일럿 단계이고 보관 상태가 포함된 1 GB-month 안에 머문다면 최적화는 미뤄도 됩니다. 다만 스토리지 초과 요금이 0이더라도 조사 가능 기간은 중요하므로 정책 자체는 명시해야 합니다.

9월 10일 전에 이미 존재하던 Workflow라면 이번 기본값 변경의 영향을 받지 않습니다. Workers Free도 기본값과 상한이 3일로 유지됩니다. 어느 경우든 플랫폼 보존 기간을 넘어 비즈니스 조사가 필요하다면 외부 기록을 남겨야 한다는 원칙은 같습니다.

월요일에 새 Workflow를 만드는 모든 경로를 점검하십시오. successRetention과 errorRetention을 모두 명시하고 안전한 장애를 발생시킨 뒤, 상세 상태를 확인할 수 있는 마지막 날을 검증합니다. 첫 실제 인시던트가 대신 시험하기 전에 그 날짜를 런북에 적어 두십시오.

다음 플랫폼 변경 사항을 실무 중심으로 정리한 뉴스레터를 받아보세요.