2026-09-26에이전트

on_active_run으로 Sume AI 에이전트 중복 실행 막기

Sume의 on_active_run 필드는 실행 중에 들어온 두 번째 실행 요청의 처리를 정합니다. 그대로 실행하거나, 건너뛴 실행을 기록하거나, 409를 받고 아무것도 실행하지 않습니다.

읽는 시간 5분Sume

Sume에서 AI 에이전트 실행이 겹치지 않게 하려면 실행 요청에 on_active_run을 함께 보내세요. skip은 두 번째 실행을 시작하는 대신 skipped 실행을 기록하고, reject는 409로 요청을 거부합니다. Format 실행 요청의 기본값은 allow라서 실행이 나란히 돌고, 스케줄(Action)에 보내는 API 실행 요청의 기본값은 skip입니다.

아래 규칙은 2026-09-26에 확인한 Sume 문서 Format 호출하기 (영문), 고급: API로 스케줄 실행하기, Run 웹훅 (영문) 페이지에서 가져왔습니다. 스케줄 설정은 AI 영상 에이전트 스케줄 실행에서 다룹니다.

on_active_run 값은 각각 어떻게 동작하나요?

이 검사는 Format별, 스케줄별로 이뤄집니다. 이 Format의 실행이 이미 진행 중일 때, 또는 이 Action의 실행이 활성일 때 어떻게 할지를 정합니다. 스케줄의 API 트리거 문서는 한 Action에서 동시에 활성인 실행이 하나뿐이라고 덧붙입니다.

Format 호출하기 (영문)와 고급: API로 스케줄 실행하기 기준, 2026-09-26 확인.
값	Format 실행	Scheduled(Action) 실행
`allow`	기본값. 동시에 실행됨. 워크스페이스 생성 동시성은 그대로 적용	여기서는 쓸 수 없는 값. 이 필드는 `skip` 또는 `reject`만 받음
`skip`	대신 `skipped` 실행을 기록	기본값. `status: "skipped"`, `skip_reason: "previous_run_active"`와 함께 `200`. 실행 행이 기록됨
`reject`	`409 format_run_in_progress`	`409 action_run_in_progress`. 실행이 기록되지 않음

두 번째 요청은 건너뛰어야 하나요, 거부해야 하나요?

스케줄 문서가 제시하는 규칙은 하나입니다. 누락된 트리거를 호출 쪽에서 오류로 드러내야 한다면 reject를, 트리거가 겹치는 일이 예상되고 해가 없다면 skip을 쓰세요. 409를 받았을 때 스케줄 문서는 나중에 재시도하거나 skip을 쓰라고 하고, Format 문서는 기다리거나 reject를 빼라고 합니다. Format에서 allow는 실행이 나란히 돌아도 안전할 때만 유지하세요.

curl -sS -X POST "https://api.sume.com/v1/formats/acme/product-promo/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: catalog-sync-2026-09-26" \
  -d '{
    "input": { "product_url": "https://example.com/p/8823" },
    "on_active_run": "skip",
    "generation_spend_cap_usd": 20
  }' | jq '.data | {status, skip_reason, next_action}'

건너뛴 실행은 어떻게 알아보나요?

건너뛴 실행은 다른 실행이 진행 중이어서 실행되지 않은 것입니다. 생성 응답에서 이미 종료 상태이고, skip_reason이 담기며, next_action은 retry_later입니다. 두 표면 모두 이 값을 건너뛴 실행에만 씁니다. 스케줄에서 이유는 previous_run_active입니다.

HTTP 상태가 아니라 영수증의 status로 분기하세요. 스케줄에서 200은 멱등성 재전송이거나 건너뛰었다는 뜻이며, 200이 작업이 끝났다는 뜻은 아닙니다.

건너뛰거나 거부된 실행에도 비용이 들거나 웹훅이 오나요?

Format 실행에서 skipped 실행은 비용이 들지 않으며, 409를 포함한 생성 시점의 4xx는 아무것도 실행되지 않았고 아무것도 청구되지 않았다는 뜻입니다. 스케줄에서 건너뛴 실행은 작업을 시작한 적이 없고, 거부된 요청은 실행을 아예 기록하지 않습니다.

둘 다 웹훅을 보내지 않습니다. 건너뛴 실행은 작업을 시작하지 않고 곧바로 종료된 실행을 기록하므로 알려 줄 완료가 없습니다. POST를 기다리지 말고 생성 응답의 status를 읽으세요. 거부된 요청은 생성 시점에 거절되므로 실행된 것도, 알릴 것도 없습니다. 웹훅은 실행이 완료되거나 실패할 때 실행당 한 번 발송됩니다.

멱등성 키와는 어떻게 다른가요?

둘은 서로 다른 문제를 해결합니다. Idempotency-Key는 같은 요청을 재전송하는 경우를 다룹니다. 같은 키에 같은 페이로드를 보내면 idempotency_hit: true가 담긴 원래 영수증이 돌아오고 두 번째 실행은 시작되지 않습니다. on_active_run은 실행이 활성인 동안 도착한 다른 요청을 다룹니다. 재시도와 두 번째 트리거가 모두 일어날 수 있다면 둘 다 보내세요. 키 설계는 AI 영상 API 멱등성 키에서 다룹니다.

on_active_run은 어디서 다르게 동작하나요?

다음 네 가지 경우를 주의하세요.

cron 발동: 문서는 on_active_run을 API 실행 요청의 필드로 정의하며, cron 표현식이 시작하는 실행에 대한 중복 설정은 문서화하지 않습니다.
대량 실행 큐는 모든 항목을 on_active_run: "allow"로 실행하므로, 항목에 skip이나 reject를 넣어도 동시성 창이 멈추지 않습니다. 자식 실행에는 워크스페이스 생성 동시성이 그대로 적용됩니다.
Agent Completions의 요청 필드 목록에는 on_active_run이 없습니다. completion은 매번 새 스레드에서 실행됩니다.
스케줄 본문을 Format 호출에 복사하면 동작이 바뀝니다. 스케줄의 기본값은 skip이고 Format의 기본값은 allow이므로, Format 문서는 그렇게 하지 말라고 합니다.

출처

작성자 Sume