에이전트 런타임 5곳, 1년이 2만 5천 개에서 끝납니다

글쓴이김성진·발행일2026년 9월 16일

AI 에이전트를 실제로 굴려 본 팀은 거의 예외 없이 같은 장면을 겪습니다.

에이전트가 40분째 문서를 읽고, 도구를 부르고, 중간 결과를 쌓고 있습니다. 그러다 서버가 재시작됩니다. 배포가 나갔을 수도 있고, 컨테이너가 죽었을 수도 있고, 부른 API가 30초 넘게 응답을 안 줬을 수도 있습니다.

그리고 처음부터 다시 시작합니다. 40분 치 토큰 값도 같이 날아갑니다.

이 문제를 푸는 도구 분류를 내구 실행(durable execution) 이라고 부릅니다. 이름이 어렵지만 하는 일은 단순합니다. 작업을 여러 개의 스텝(step) 으로 쪼개서, 각 스텝이 끝날 때마다 그 결과를 어딘가에 적어 둡니다. 도중에 죽으면 적어 둔 마지막 스텝 다음부터 다시 시작합니다.

이 글은 이런 분을 위해 썼습니다.

AI 에이전트나 긴 백그라운드 작업을 운영에 올리려는 분, 그리고 “큐(대기열) 하나 붙이면 되는 거 아닌가”라고 생각하다가 재시도 로직을 세 번째 다시 짜고 있는 분입니다.

먼저 결론부터 말씀드립니다. 다섯 곳의 요금표를 나란히 놓고 고르면 십중팔구 틀립니다. 이 분류에서 당신을 아프게 하는 건 가격이 아니라 한도입니다. 그것도 요금 페이지가 아니라 한도 문서(limits, quotas)에 조용히 적혀 있는 숫자들입니다.

이 글에서 다루는 다섯 곳은 이렇습니다.

• Temporal Cloud — 이 분야의 원조 격. 우버에서 나온 Cadence의 후속입니다.
• Inngest — 이벤트 기반으로 함수를 묶는 방식. 자바스크립트·파이썬 중심입니다.
• Trigger.dev — 오픈소스(Apache 2.0)이고 셀프호스팅이 가능합니다.
• Cloudflare Workflows — 엣지에서 도는 Workers 위에 얹힌 워크플로입니다.
• AWS Step Functions — 가장 오래됐고, AWS 안에서만 살면 가장 잘 붙습니다.

숫자는 전부 2026년 9월 16일 기준으로 각 사의 공식 요금·한도 문서를 직접 읽어 옮겼습니다. 확인하지 못한 값은 아래 따로 모아 두었습니다.

“1년 동안 돌아갑니다”와 “2만 5천 개에서 실패합니다”는 같은 문서에 있습니다

AWS Step Functions의 서비스 할당량 문서에는 이렇게 적혀 있습니다.

최대 실행 시간: 1년. 실행이 1년을 넘으면 States.Timeout 오류로 실패합니다.

그리고 바로 아래 줄에 이렇게 적혀 있습니다.

최대 실행 이력 크기: 단일 상태 머신 실행 이력에서 25,000개 이벤트. 실행 이력이 이 할당량에 도달하면 실행이 실패합니다.

두 문장은 모순이 아닙니다. 시간 제한과 분량 제한이 따로 있는 것이고, 오래 도는 에이전트는 시간보다 분량에 먼저 닿습니다.

왜 중요하냐면, 에이전트는 루프를 돕니다. 도구를 한 번 부를 때마다 “호출 시작 · 결과 도착 · 다음 상태로 이동” 같은 이벤트가 이력에 여러 개 쌓입니다. 도구 호출 한 번에 이벤트가 5개씩만 쌓여도 5,000번이면 한도입니다. 사람이 보기엔 “그냥 좀 오래 도는 작업”인데, 런타임 입장에서는 기록이 터진 겁니다.

그래서 이 분류를 고를 때 제일 먼저 봐야 할 숫자는 요금이 아니라 이력 한도입니다.

Temporal이 51,200개로 가장 넉넉하고, 무엇보다 10,240개에서 미리 경고를 줍니다. 벽에 부딪히기 전에 알려 주는 곳은 여기뿐입니다. 이 한도는 Temporal Cloud뿐 아니라 직접 띄운 Temporal에도 똑같이 적용되고, 설정으로 늘릴 수 없다고 문서가 못박고 있습니다.

Cloudflare와 Inngest는 이벤트가 아니라 스텝 개수로 셉니다. 세는 단위가 더 거칠어서 개발자가 머릿속으로 계산하기는 오히려 쉽습니다. “이 워크플로에 스텝이 몇 개냐”는 코드를 보면 바로 나오니까요.

스텝 하나가 버틸 수 있는 시간

이력 다음으로 자주 부딪히는 벽이 여기입니다. 에이전트가 부르는 도구 중에는 오래 걸리는 게 섞여 있습니다. 영상 인코딩, 대용량 크롤링, 사람 승인 대기 같은 것들입니다.

여기서 헷갈리기 쉬운 게 Cloudflare의 CPU 시간입니다.

벽시계 시간과 CPU 시간은 다릅니다. API 응답을 3분 기다리는 동안 CPU는 놀고 있으니 CPU 시간은 거의 0입니다. Cloudflare 문서도 “API 응답을 기다리거나 step.sleep으로 멈춰 있거나 그 밖에 놀고 있는 워크플로는 CPU 시간이 붙지 않는다”고 적고 있습니다.

그러니까 무료 플랜의 스텝당 CPU 10ms는 “10밀리초 안에 끝내라”가 아니라 “스텝 안에서 무거운 계산을 직접 하지 마라”에 가깝습니다. 외부 API를 부르고 결과를 받는 형태라면 10ms로도 굴러갑니다. 반대로 스텝 안에서 큰 JSON을 파싱하거나 이미지를 처리하면 무료 플랜에서는 바로 막힙니다.

Inngest의 2시간은 숫자가 깔끔한 대신 조건이 붙습니다. 문서에 “호스팅 제공자의 타임아웃이 먼저 적용될 수 있다”는 단서가 달려 있습니다. Vercel이나 Lambda에 얹어 돌리면 그쪽 제한이 먼저 걸립니다.

죽었을 때 몇 번까지 다시 해 줍니까

내구 실행의 핵심 기능은 재시도입니다. 그런데 “알아서 재시도해 줍니다”라는 문장 뒤에 붙는 조건이 곳마다 다릅니다.

Cloudflare Workflows는 스텝당 최대 재시도 횟수를 10,000회로 명시합니다. 이 목록에서 재시도 상한을 숫자로 적어 둔 곳은 여기가 유일합니다. 무료·유료 구분 없이 같은 값입니다. 재시도 사이의 대기까지 포함하면 스텝 하나가 며칠씩 버티는 것도 가능하다는 뜻입니다.

AWS Step Functions는 재시도 횟수보다 재시도의 값이 문제입니다. 요금 문서가 “재시도는 추가 상태 전이로 과금된다”고 못박고 있습니다. 불안정한 외부 API를 부르는 스텝이 하나 있고 그게 평균 3번씩 재시도된다면, 그 워크플로의 전이 수는 설계도에 그려진 것보다 3배가 됩니다. 설계도만 보고 요금을 계산하면 틀립니다.

여기에 Step Functions에는 다른 곳에 없는 장치가 하나 더 있습니다. 재실행(redrive) 입니다. 실패한 실행을 처음부터가 아니라 실패한 지점부터 다시 밀어 줍니다. 배포로 버그를 고친 뒤 어제 실패한 실행 수백 건을 그 자리에서 이어 돌릴 수 있다는 뜻입니다. 다만 이 문은 실행이 끝난 날부터 14일 뒤에 닫힙니다.

Inngest는 재시도가 스텝 한도를 갉아먹는 구조인지가 중요합니다. 함수당 스텝 상한이 1,000개인데, 재시도가 이 1,000개를 어떻게 소비하는지는 이번에 확인하지 못했습니다. 재시도가 잦은 함수를 설계 중이라면 이 항목은 직접 확인하고 가는 편이 안전합니다.

Temporal과 Trigger.dev의 재시도 횟수 상한도 이번 조사에서는 숫자로 확인하지 못했습니다. 아래 “문서에 없어서 못 적은 숫자”에 같이 적어 두었습니다.

잠들어 있는 동안에도 돈이 나갑니까

에이전트 워크플로에는 기다리는 구간이 많습니다. “사람 승인 기다리기”, “내일 아침까지 대기”, “3분 뒤 재시도” 같은 것들입니다.

이 대기 구간을 어떻게 취급하느냐가 실제 청구서를 크게 흔듭니다.

• Cloudflare Workflows: 대기 중에는 CPU 시간이 붙지 않습니다. 그리고 waiting 상태의 인스턴스는 동시 실행 개수에도 안 잡힙니다. 문서가 “잠들어 있는 인스턴스 수백만 개를 동시에 둘 수 있다”고 명시합니다. 최대 수면 시간은 365일입니다.
• Inngest: 대기 자체의 상한이 플랜마다 다릅니다. 무료는 최대 7일, 그 외 플랜은 최대 1년입니다.
• AWS Step Functions (Standard): 대기하는 동안 상태 전이가 발생하지 않으면 전이 요금은 안 붙습니다. 최대 유휴 시간은 1년으로, 전체 실행 시간 제한에 묶여 있습니다.
• Temporal Cloud: Timer도 과금 대상 Action에 포함됩니다. 즉 대기 자체가 한 번 세어집니다.
• Trigger.dev: 머신 시간 단위로 과금하는 구조라, 대기 처리 방식은 요금 페이지만으로는 판단하기 어렵습니다.

“하루에 한 번 깨어나 확인하고 다시 자는” 형태의 에이전트를 1만 개 굴린다면, 이 항목 하나로 월 비용이 몇 배 갈립니다.

동시에 몇 개가 돌 수 있습니까

에이전트를 사용자에게 열어 주는 순간 이 항목이 병목이 됩니다. 한 명이 쓸 때는 안 보이다가, 점심시간에 서른 명이 동시에 버튼을 누르면 그때 드러납니다.

여기서 단위가 서로 다르다는 점을 꼭 보셔야 합니다.

Trigger.dev와 Cloudflare는 “실행 개수”를 셉니다. 워크플로 하나가 통째로 한 칸을 차지합니다. Inngest는 “동시 스텝”을 셉니다. 무료 플랜의 5는 “동시에 5개 워크플로”가 아니라 “동시에 실행 중인 스텝 5개”입니다. 스텝이 열 개인 워크플로 하나만 돌려도 구간마다 칸을 잡습니다.

무료 플랜 숫자만 놓고 보면 Inngest의 5가 가장 빡빡해 보이지만, 무료 실행량은 월 5만 건으로 이 목록에서 가장 후합니다. 여유를 어디에 두느냐가 다를 뿐입니다. 짧은 작업을 많이 돌리면 Inngest 무료가 유리하고, 긴 작업을 동시에 여러 개 돌리면 Trigger.dev 무료의 20건이 유리합니다.

Cloudflare의 50,000건은 숫자가 크기도 하지만 앞서 본 규칙과 합쳐지면 더 커집니다. 대기 중인 인스턴스는 이 50,000에 안 잡힙니다. “며칠 뒤에 깨어나 확인하는” 형태의 워크플로라면 실질적인 상한이 사실상 없는 셈입니다.

AWS Step Functions의 100만 건은 압도적이지만, 조건이 하나 붙습니다. 문서에 “새 AWS 계정은 상태 전이 할당량이 낮게 시작하고, 사용량에 따라 AWS가 자동으로 올린다” 고 적혀 있습니다. 계정을 오늘 만들어 부하 시험을 돌리면 문서에 적힌 숫자가 안 나올 수 있다는 뜻입니다.

사고가 난 뒤 로그를 며칠까지 볼 수 있습니까

내구 실행을 쓰는 이유의 절반은 “죽어도 이어서 돈다”이고, 나머지 절반은 “왜 죽었는지 나중에 볼 수 있다” 입니다. 그런데 이 보존 기간이 생각보다 짧습니다.

무료 플랜에서 Inngest 24시간 · Trigger.dev 1일은 실무에서 꽤 아픕니다. 금요일 밤에 난 사고를 월요일 아침에 보려고 들어가면 이미 없습니다.

반대로 AWS Step Functions의 90일은 이 목록에서 가장 깁니다. 게다가 여기만 방향이 반대입니다. 늘리려고 요청하는 게 아니라, 규정 때문에 30일로 줄이려고 요청합니다. 실행 이력을 90일이나 들고 있는 게 오히려 부담인 조직이 있다는 뜻이고, 금융·의료 쪽이라면 이 항목이 먼저 걸릴 수 있습니다.

한 가지 더. Step Functions Standard에는 재실행(redrive) 가능 기간 14일이 따로 있습니다. 실패한 실행을 실패 지점부터 다시 밀어 주는 기능인데, 2주가 지나면 그 문이 닫힙니다. 이력은 90일 남아 있지만 되살릴 수는 없는 구간이 생깁니다.

값이 붙는 지점이 서로 다릅니다

이제 요금입니다. 다만 순서가 뒤에 온 이유가 있습니다. 다섯 곳이 각각 다른 것을 셉니다. 그래서 “월 얼마”를 나란히 놓는 비교는 거의 의미가 없습니다.

여기서 짚고 갈 지점이 셋 있습니다.

첫째, Temporal의 Action은 생각보다 자주 세어집니다. 워크플로 시작도, 액티비티 한 번도, 타이머 하나도, 시그널 하나도 전부 Action입니다. 에이전트 한 번 돌리는 데 Action이 50개씩 붙는다면 100만 Action은 에이전트 2만 번입니다.

둘째, Trigger.dev와 Cloudflare는 “시간”을 셉니다. 스텝 개수가 적어도 안에서 오래 돌면 값이 붙습니다. 반대로 Step Functions는 시간을 안 세고 전이만 셉니다. 한 스텝이 3시간 걸려도 전이는 그대로 1건입니다. 오래 기다리는 작업이 많다면 이 차이만으로 청구서가 갈립니다.

셋째, 재시도도 과금됩니다. Step Functions 문서는 “재시도는 추가 상태 전이로 과금된다”고 명시합니다. 재시도가 잦은 워크플로는 예상치의 두세 배가 나올 수 있습니다.

그리고 Temporal에는 요금표 바깥에 하나가 더 있습니다. 지원 요금입니다. Standard는 사용액의 10%가 붙고, Business는 월 500달러 또는 사용액의 10% 중 큰 쪽입니다. 사용액이 월 100달러인 팀이 Business 지원을 켜면 지원비가 본 요금의 5배가 됩니다.

크기 제한 — 에이전트 결과물이 통째로 막히는 자리

의외로 여기서 막히는 경우가 많습니다. 스텝이 돌려주는 값의 크기 제한입니다.

Step Functions의 256KiB가 눈에 띄게 작습니다. 에이전트가 문서를 읽어 요약 결과를 다음 스텝으로 넘기는 구조라면, 원문을 그대로 들고 다니다가 여기서 막힙니다. 그래서 AWS 쪽 관례는 “큰 데이터는 S3에 넣고 스텝에는 주소만 넘긴다”입니다. 코드가 한 겹 늘어난다는 뜻입니다.

Cloudflare의 1MiB도 비슷한 성격이고, 인스턴스당 전체 상태 저장 한도가 무료 100MB · 유료 1GB로 따로 있습니다.

도망갈 문이 있는 곳 — 셀프호스팅과 라이선스

서비스가 문을 닫거나 요금을 올렸을 때 빠져나갈 수 있는지도 선택 기준입니다. AI 워크플로 빌더를 비교한 글에서도 같은 항목이 결론을 갈랐습니다.

• Trigger.dev: 공식 문서가 “Apache 2.0 라이선스의 오픈소스”라고 명시하고, 셀프호스팅을 지원합니다. 이 목록에서 라이선스가 가장 명확합니다.
• Temporal: 서버가 오픈소스이고 직접 띄울 수 있습니다. Cloud는 그 운영을 대신 해 주는 상품입니다. 다만 51,200 이벤트 한도는 직접 띄워도 똑같이 걸립니다.
• Inngest: 개발용 로컬 서버를 제공하지만, 운영 환경은 클라우드 제품이 기본입니다.
• Cloudflare Workflows: Cloudflare 위에서만 돕니다.
• AWS Step Functions: AWS 위에서만 돕니다. 대신 AWS 안의 다른 서비스와 붙는 방식은 이 목록에서 가장 촘촘합니다.

문서에 없어서 못 적은 숫자

비교 글에서 제일 위험한 건 없는 숫자를 채워 넣는 일입니다. 확인하지 못한 항목을 그대로 적어 둡니다.

• Trigger.dev의 실행당 이력·스텝 한도: 요금 페이지에는 동시 실행 수와 보존 기간만 있고, 실행 하나가 가질 수 있는 스텝·이벤트 상한은 확인하지 못했습니다.
• Inngest Pro의 구간별 초과 단가표: 요금 페이지가 “물량이 늘수록 단가가 내려가는 계단식”이라고만 밝히고, 구간별 숫자는 공개하지 않습니다.
• Cloudflare Workflows의 무료 플랜 요금 상세: 한도는 공개돼 있지만, 스텝·상태 저장의 무료 포함량 숫자는 이번에 확인하지 못했습니다.
• Cloudflare AI Search(옛 AutoRAG): 같은 계열 제품을 확인하다 발견한 것인데, 공개 베타 동안 무료이고 “과금 시작 최소 30일 전에 안내한다”고 적혀 있습니다. 워크플로와는 별개 제품입니다.
• Temporal Cloud의 전체 실행 시간 상한: 시간 기준 상한을 명시한 문장은 찾지 못했습니다. 실질적인 상한은 이력 한도라고 보는 편이 안전합니다.
• Temporal·Trigger.dev의 스텝 재시도 횟수 상한: 숫자로 명시된 값을 확인하지 못했습니다. Cloudflare Workflows만 스텝당 10,000회로 공개돼 있습니다.
• Inngest에서 재시도가 스텝 한도를 소비하는지 여부: 함수당 스텝 1,000개 한도와 재시도의 관계는 문서에서 확인하지 못했습니다.

이 항목들은 영업에 문의하거나 계정을 만들어 콘솔에서 확인해야 합니다.

고르는 순서

다섯 곳을 한 번에 비교하려 하면 답이 안 나옵니다. 아래 순서로 걸러 내는 편이 빠릅니다.

1. 이미 AWS 안에 다 들어가 있습니까? 그러면 Step Functions부터 보십시오. 월 4,000 전이가 무료라 시험 삼아 붙이는 비용이 사실상 0입니다. 단, 입출력 256KiB와 이력 25,000개를 처음부터 계산에 넣어야 합니다.

2. 워크플로 하나가 며칠씩 잠들어 있습니까? Cloudflare Workflows가 유리합니다. 대기 중 CPU 시간이 안 붙고, 대기 인스턴스가 동시 실행 수에도 안 잡힙니다. 대신 스텝 안에서 무거운 계산을 하지 않는 구조로 짜야 합니다.

3. 실행 이력이 수만 건 단위로 쌓입니까? Temporal입니다. 51,200 이벤트에 10,240 사전 경고까지 있는 곳은 여기뿐입니다. 대신 Action 과금이라 잔동작이 많은 워크플로는 값이 빨리 오릅니다.

4. 자바스크립트·파이썬으로 빨리 붙이고 싶습니까? Inngest입니다. 월 5만 실행이 무료라 시작 문턱이 낮습니다. 다만 무료 플랜의 트레이스 24시간은 운영에 올리기 전에 반드시 확인하십시오.

5. 나중에 우리 서버로 옮길 여지를 남기고 싶습니까? Trigger.dev입니다. Apache 2.0이고 셀프호스팅을 공식 지원합니다. 실행 시간 제한이 없다는 점도 오래 도는 에이전트에는 매력적입니다.

마지막으로 하나만 덧붙이면, 이 다섯 곳 중 어디를 고르든 한도 문서를 요금 문서보다 먼저 읽는 습관이 돈보다 시간을 아껴 줍니다. 요금은 초과하면 청구서로 오지만, 한도는 초과하면 운영 중인 에이전트가 그냥 죽습니다.

에이전트가 무엇을 하고 있는지 들여다보는 도구가 따로 필요하다면 LLM 관측 도구를 비교한 글을, 에이전트가 코드를 직접 실행해야 한다면 AI 샌드박스 비교를 같이 보시면 그림이 맞춰집니다.