Cloudflare Workflows 실행 기록, 왜 예전보다 빨리 없어질까

실행 상태를 얼마간 보존할지 고르는 AI 생성 개념 이미지입니다.

예전 Cloudflare Workflows에서는 오래된 실행 상태를 볼 수 있었는데 새로 만든 워크플로에서는 더 빨리 사라진다면, 코드만 비교하지 말고 생성 시점과 보존 설정을 함께 확인해야 합니다. 같은 서비스 안에서도 기존 작업과 새 작업이 다른 기본값을 사용할 수 있습니다.

Cloudflare Workflows를 새로 만들 때는 성공과 오류 인스턴스 상태를 각각 며칠 보존할지 명시적으로 검토하세요.

2026년 9월 10일 공지는 그날 이후 생성한 Workers Paid 워크플로의 완료·오류 인스턴스 상태 기본 보존을 7일로 바꾼다고 안내합니다. 다만 확인한 API·요금 문서에는 다른 기본값 설명이 남아 있어, 옵션을 생략한 모든 실행 경로의 값을 여기서 단정하지는 않습니다.

새 워크플로와 기존 워크플로를 먼저 구분합니다

공지에 적힌 변경 대상은 9월 10일 이후 생성한 Paid 워크플로입니다. 기존 워크플로의 보존 기간은 바뀌지 않으며, Free 플랜은 기본값과 한도 모두 3일이라고 설명합니다. Paid의 최대 보존 한도는 30일로 유지됩니다.

따라서 모든 실행 기록이 한꺼번에 7일로 바뀌었다고 읽으면 안 됩니다. 오래 사용하던 워크플로인지 새로 생성한 워크플로인지, 어떤 플랜인지, 이미 명시한 보존 설정이 있는지를 대조해야 합니다. 같은 코드를 복사했더라도 새 리소스를 만든 경우에는 기본값이 다른 조건일 수 있습니다.

또 이 변경은 인스턴스 상태의 보존에 관한 것입니다. 애플리케이션이 다른 데이터베이스나 객체 저장소에 따로 남긴 업무 결과까지 같은 기간 뒤 삭제된다는 뜻은 아닙니다. 어떤 자료가 어디에 저장되는지 알아야 실제로 잃을 수 있는 정보의 범위를 파악할 수 있습니다.

공식 문서의 기본값 설명이 일치하지 않습니다

2026년 9월 13일 확인한 Workers API 참조는 retention을 생략하면 계정의 최대 보존 기간을 사용한다는 설명을 포함합니다. Workflows 요금 문서에도 Paid 기본값 30일이라는 문구가 남아 있습니다. 신규 Paid 워크플로의 7일을 안내한 공지와 표현이 다릅니다.

이 글에서 실제 계정에 워크플로를 만들어 기본값을 비교한 것은 아닙니다. 따라서 어느 화면이나 호출 경로든 생략하면 반드시 같은 값이 적용된다고 보장할 수 없습니다. 문서의 생성 시점 조건과 실제 워크플로 설정을 함께 확인해야 합니다.

그 차이가 중요한 작업이라면 기본값에만 의존하지 않는 편이 분명합니다. 지원되는 범위 안에서 성공과 오류 보존 기간을 직접 정하고, 실제 리소스에 적용된 설정을 대조합니다. 명시한 옵션과 확인한 상태를 기록하면 다음 기본값 변경에도 의도를 읽을 수 있습니다.

문서가 다르다는 이유만으로 한쪽을 삭제하거나 오류라고 단정할 필요는 없습니다. 어떤 문서의 어떤 조건을 기준으로 설정했고 실제 환경에서 무엇을 확인했는지를 구분해 남기는 것이 현재 할 수 있는 정확한 대응입니다.

성공과 오류 상태의 용도를 따로 생각합니다

가상의 자료 수집 작업을 생각해 보겠습니다. 정상적으로 수집한 결과는 별도 저장소에 보관하고, 성공 여부는 다음 날 확인합니다. 반면 오류 원인은 담당자가 주 단위로 모아 조사합니다. 이 경우 성공 상태와 오류 상태가 필요한 기간이 같지 않을 수 있습니다.

성공 상태를 짧게 남기려면 업무 결과를 다른 곳에서 다시 찾을 수 있어야 합니다. 실행 상태 안에만 최종 결과를 두고 보존을 줄였다면, 나중에 필요한 자료도 함께 찾기 어려워질 수 있습니다. 어떤 정보를 인스턴스 상태에서 읽는지 먼저 구분해야 합니다.

오류 상태도 오래 남기기만 하면 모든 진단 정보가 보존되는 것은 아닙니다. 외부 서비스의 응답, 별도 로그 제품의 기록, 재현에 필요한 입력 자료가 다른 곳에 있을 수 있습니다. 상태 보존과 문제를 다시 조사할 수 있는 자료의 보존을 함께 설계해야 합니다.

기간을 정할 때는 오류를 발견하고 담당자가 살펴보는 데 걸리는 시간을 기준으로 생각해 볼 수 있습니다. 작업 주기와 담당 일정, 별도 보관 자료를 적어보면 모든 항목에 최대 기간을 넣거나 무조건 짧게 줄이는 것보다 판단이 쉬워집니다.

인스턴스 생성 옵션으로 기간을 명시합니다

API 참조는 successRetention과 errorRetention을 제공하며, 성공 완료와 오류·종료 상태 이후의 보존 기간을 구분합니다. 다음은 이미 env.MY_WORKFLOW 바인딩과 연습용 워크플로가 준비된 Paid 환경을 가정한 미실행 예시입니다.

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

  return {
    id: instance.id,
    details: await instance.status(),
  };
}

여기서 2일과 30일은 앞의 가상 업무를 설명하기 위한 선택입니다. 모든 서비스에 적합한 권장값은 아닙니다. Free 플랜에 Paid의 기간을 그대로 붙여도 된다는 예제로 읽어서는 안 됩니다.

이 함수는 실제로 호출하면 인스턴스를 생성합니다. 단순한 설정 조회나 dry-run이 아니므로 운영 경로에 바로 넣어 호출할 코드는 아닙니다. 연습용 입력과 권한이 준비된 환경에서 검토해야 하며, 실제 워크플로가 요구하는 입력도 그 정의에 맞춰 전달해야 합니다.

반환받은 ID는 어떤 실행을 조사할지 연결하는 자료입니다. 생성 직후의 status가 아직 진행 중일 수도 있으므로 인스턴스를 만들었다는 사실을 성공 완료로 기록하지 않습니다. 상태 조회 결과와 기간 설정 자체의 확인도 구분합니다.

상태를 다시 읽는 것과 설정을 확인하는 것은 다릅니다

이미 만든 인스턴스는 ID로 가져와 상태를 읽을 수 있습니다. 다음 예시는 같은 워크플로에 해당 ID의 인스턴스가 존재한다는 조건입니다.

async function inspectInstance(env, instanceId) {
  const instance = await env.MY_WORKFLOW.get(instanceId);
  return await instance.status();
}

API가 상태와 결과를 반환한다고 해서 그 응답에 적용된 retention 설정이 모두 다시 실려 온다고 가정하지 않습니다. 상태 조회는 실행 상태를 확인하는 경로이고, 보존 설정은 생성 옵션과 워크플로·인스턴스 설정 화면 등 실제로 제공되는 경로에서 따로 대조해야 합니다.

공지에서는 대시보드에서도 워크플로와 인스턴스의 보존 기간을 설정할 수 있다고 설명합니다. 코드에 적힌 값과 화면에서 설정한 값이 다르면 어느 경로가 현재 리소스에 적용됐는지 확인해야 합니다. 명시한 설정이 있다는 것만으로 실제로 사용된 경로까지 검증된 것은 아닙니다.

조회에 실패했다면 곧바로 보존 만료라고 단정하지 않습니다. 다른 워크플로의 ID를 사용했는지, 인스턴스가 실제로 생성됐는지, 보고 있는 계정과 리소스가 맞는지도 확인합니다. 어떤 오류가 났는지 기록한 뒤 시간 조건과 비교해야 합니다.

비용과 조사 가능 기간을 함께 봅니다

Workflows 요금 문서는 실행 중인 상태뿐 아니라 완료·오류 등 보관되는 상태의 저장도 사용량에 포함한다고 설명합니다. 오래 보존할 자료가 많다면 기간 선택이 비용과 관련될 수 있습니다. 하지만 상태를 줄였을 때 얼마가 절감되는지는 실제 사용량을 확인해야 합니다.

이 글에는 비용이나 저장 공간을 측정한 수치가 없습니다. 보존 기간을 절반으로 줄이면 청구서도 정확히 절반이 된다는 식으로 계산하지 않습니다. 실행 수와 상태 크기, 다른 과금 항목과 집계 기간도 영향을 주기 때문입니다.

비용을 줄이려는 작업에서는 어떤 정보를 더 짧게 남겨도 되는지를 먼저 정합니다. 필요한 오류 원인을 조사하기 전에 상태가 사라진다면, 저장 비용을 아낀 대신 문제를 해결할 자료를 잃을 수 있습니다. 반대로 업무 결과가 별도로 보존되고 실행 상태를 다시 보지 않는다면 더 짧은 보존을 검토할 여지가 있습니다.

기존 작업을 옮길 때 보존 의도도 함께 옮깁니다

코드와 이름만 복사해 새 워크플로를 만들면 생성 시점에 따른 기본값이 바뀔 수 있습니다. 이전 리소스가 그대로 유지된 것인지 새 리소스를 만든 것인지 확인하고, 성공·오류 보존 기간을 이전 의도와 맞춰야 합니다.

점검 기록에는 워크플로 생성 시점, 플랜, 명시한 옵션, 실제로 확인한 설정과 인스턴스 ID, 필요한 업무 결과의 저장 위치를 남깁니다. 기간이 지난 뒤에도 무엇을 찾아야 하는지 알 수 있어야 단순히 ‘기본값 사용’이라는 표현을 넘어설 수 있습니다.

실행 기록이 보이지 않는 경우에는 화면의 조회 기간과 대상부터 확인하고, 보존 만료·다른 위치의 자료·실제 조회 실패를 구분합니다. 이 글은 사라진 상태를 복구할 수 있다고 보장하지 않으며 실제 삭제나 복원을 수행하지 않았습니다.

새 Workflows를 만들 때는 성공과 오류를 각각 얼마나 볼 필요가 있는지 먼저 정하세요. 공지와 참조 문서의 조건 차이를 남기고, 중요한 보존 기간은 명시한 뒤 실제 설정과 대조합니다. 업무 결과를 어디에서 다시 찾을지도 함께 정해야 실행 상태의 수명이 짧아져도 필요한 자료를 놓치지 않을 수 있습니다.