2026년 현재, 우리는 팀들이 AI 에이전트(AI agents)를 단순한 고급 챗봇(chatbots)이 아닌 디지털 작업자(digital workers)로 취급하는 것을 목격하고 있습니다. 이러한 변화는 구축 방식의 모든 것을 바꿉니다. 그리고 대부분의 사람들이 아직 명명하지 않은 문제를 만들어냅니다. 바로 **에이전트 스케줄링 (agent scheduling)**입니다.

이것은 단순히 "에이전트를 위한 크론 잡 (cron jobs for agents)"에 관한 것이 아닙니다. 더 깊은 차원의 문제입니다. 에이전트가 정해진 일정에 따라 실행되어야 하고, 여러 실행 간에 상태 (state)를 처리하며, 실패한 단계를 재시도하고, 다른 에이전트와 협업하며, 감사를 위해 구조화된 로그 (structured logs)를 생성해야 한다면—그것은 인프라 (infrastructure) 작업입니다. 그리고 아직 거의 아무도 이를 위한 적절한 레이어 (layer)를 구축하지 못했습니다.

"채팅"에서 "작업자"로의 전환

지난 2년 동안 에이전트에 대한 논의는 역량 (capability)에 집중되었습니다: "에이전트가 코드를 작성할 수 있는가? 복잡한 작업을 계획할 수 있는가?" 2026년 중반에 이 논쟁은 종결되었습니다. 진짜 질문은 다음과 같이 바뀌었습니다: "우리가 프로덕션 (production) 환경에서 에이전트를 안정적으로 실행하고, 그들이 하는 일을 측정하며, 실행 시점을 제어할 수 있는가?"

Reddit의 에이전트 커뮤니티들도 병행하여 움직였습니다. 2026년 초의 스레드들은 자율성 (autonomy)에 대해 논쟁했습니다. 6~7월에 이르러 가장 호응이 좋은 스레드들은 스케줄링 패턴 (scheduling patterns), 상태 복구 (state recovery), 그리고 비용 거버넌스 (cost governance)에 관한 것입니다. 빌더(Builders)들은 다음과 같은 에이전트를 원합니다:

• 정해진 일정에 따라 실행 (야간 보고서, 시간 단위 조정, 주간 검토)
• 컨텍스트 (context)를 잃지 않고 재시작을 견딤
• 다운스트림 시스템 (downstream systems)이 반응할 수 있는 이벤트 (events)를 생성
• 기존 워크플로 (workflows)와 통합 (Jira, Slack, GitHub, 귀하의 모니터링 스택)
• 서로 간섭하지 않고 병렬로 실행
• 단순한 부수 효과 (side effects)가 아닌 구조화된 결과로 보고

이것은 단순한 기능 요청이 아닙니다. 이것은 운영 인프라 (operational infrastructure)의 정의입니다.

스케줄링이 단순한 크론 (Cron)이 아닌 이유

당신은 이렇게 생각할지도 모릅니다: "좋아, 그냥 크론 (cron)과 내 에이전트 프레임워크 (agent framework)를 사용하면 되겠지." 단순한 경우에는 그것이 작동합니다. 하지만 다음과 같은 상황에서는 무너집니다:

1. 상태(State)가 실행 간에 유지되어야 합니다. AWS 지출을 조정(reconcile)하는 에이전트는 지난주의 기준선(baseline)을 기억하고, 이상 징후를 탐지하며, 추세가 임계값을 넘으면 에스컬레이션(escalate)해야 합니다. Cron + 매번 새로 시작하는 방식은 정보 손실을 초래합니다. 내구성(durability)이 필요합니다.

2. 실행(Runs) 간의 조정이 필요합니다. 보고 에이전트, 이메일 에이전트, 에스컬레이션 에이전트가 서로 다른 스케줄로 실행됩니다. 보고가 오전 8시에 끝난다면, 이메일은 오전 8시가 아닌 8시 5분에 실행되어야 합니다. 의존성 관리(dependency management)가 필요합니다.

3. 실패에 대한 가시성이 필요합니다. 실패한 cron 작업은 로그 파일의 한 줄에 불과합니다. 하지만 워크플로(workflow)를 완료하지 못한 에이전트는 컴플라이언스(compliance) 문제, 고객 환불, 또는 마감 기한 미준수로 이어집니다. 구조화된 실패 캡처(structured failure capture)와 재시도 정책(retry policies)이 필요합니다.

4. 감사 추적(Audit trails)이 중요합니다. 에이전트 주도 작업이 문제를 일으켰을 때, 해당 결과로 이어진 정확한 상태, 입력값, 그리고 추론(reasoning) 과정을 재현할 수 있어야 합니다. Cron 로그는 이를 제공하지 않습니다. 세션 지속성(session persistence)이 필요합니다.

5. 멀티 런타임(Multi-runtime) 팀. 데이터 에이전트는 Bedrock에서 실행됩니다. 코딩 에이전트는 Claude Managed Agents에서 실행됩니다. 워크플로 에이전트는 n8n에서 실행됩니다. 이들은 서로 다른 스케줄을 가지며 컨텍스트(context)를 전달해야 합니다. 런타임을 추상화하는 컨트롤 플레인(control plane)이 필요합니다.

Cron은 이 중 그 어떤 것도 해결하지 못합니다. 이것이 프로덕션 환경에서 신뢰할 수 있는 에이전트 시스템을 구축하는 팀들이 결국 이 계층을 직접 다시 만드는 이유입니다.

프로덕션 에이전트 스케줄링의 모습

대규모로 작동하는 에이전트 시스템을 출시하는 팀들에게서 제가 보고 있는 패턴은 다음과 같습니다:

계층 1: 에이전트 런타임 (Agent Runtime)
에이전트 자체—로직, 도구, 추론(reasoning)을 의미합니다. 이는 어떤 플랫폼(Claude Managed Agents, Bedrock, Cursor, 셀프 호스팅)에서도 실행될 수 있습니다.

계층 2: 세션 및 상태 관리 (Session & State Management)
세션을 소유하고, 상태를 지속시키며, 각 실행에서 어떤 일이 일어났는지 추적하는 컨트롤 플레인(control plane)입니다. 이곳에 에이전트의 작업 기억(working memory), 추론 흔적(reasoning trace), 그리고 결과물을 저장합니다.

Layer 3: 스케줄링 및 오케스트레이션 (Scheduling & Orchestration)
정해진 스케줄에 따라 에이전트를 실행하고, 재시도 (retries)를 처리하며, 에이전트 간의 핸드오프 (handoffs)를 조정하고, 다른 시스템이 반응할 수 있는 이벤트를 방출하는 시스템입니다.

Layer 4: 관측 가능성 및 감사 (Observability & Audit)
구조화된 로깅 (structured logging), 실행당 에이전트별 비용 추적 (cost tracking), 그리고 전체 재생 (replay) 기능입니다.

대부분의 팀은 레이어 1과 2만 가지고 있습니다. 3과 4가 빠져 있습니다. 그래서 무언가 고장 나면 왜 그런지 알 수 없고, 의존성 (dependencies)을 추적할 수 없으며, 어떤 일이 일어났는지 감사 (audit)할 수 없습니다.

문제 영역 (The Problem Space)

몇 가지 구체적인 예시입니다:

데이터 품질 에이전트 (Data Quality Agent) (매일 밤 실행): 데이터 웨어하우스 (data warehouse)를 감사하고, 이상 징후를 찾아내며, 티켓을 생성합니다. 어제의 기준점 (baseline)을 기억해야 하고, 오탐 (false positives)을 건너뛰어야 하며, 변동성이 임계값 (threshold)을 넘으면 에스컬레이션 (escalate)해야 합니다. 매일 밤 새로 실행하는 것은 낭비이며 패턴을 놓치게 됩니다.

조정 에이전트 (Reconciliation Agent) (매시간 실행): 은행 피드 (bank feeds)를 총계정원장 (GL) 항목과 일치시킵니다. 실행 도중 실패하면 처음부터 다시 시작하는 것이 아니라 체크포인트 (checkpoint)에서 재개해야 합니다. 성공하면 정산 에이전트 (settlement agent)가 수신하여 조치할 수 있도록 이벤트를 방출해야 합니다. 불일치가 발생하면 전체 컨텍스트 (context)와 함께 이를 드러내야 합니다.

코드 리뷰 에이전트 (Code Review Agent) (온디맨드 + 매일 밤 백필): 리뷰어가 수동으로 실행합니다. 밤에는 열려 있는 PR (Pull Request)을 대상으로 실행됩니다. 서로 다른 컨텍스트를 가진 두 개의 서로 다른 스케줄로 작동합니다. 작업의 중복을 제거하고 충돌 없이 두 트리거를 모두 처리해야 합니다.

멀티 에이전트 보고 파이프라인 (Multi-Agent Report Pipeline): 보고 에이전트가 오전 6시에 실행됩니다. 이메일 에이전트는 이를 기다렸다가 오전 6시 15분에 실행됩니다. 보고가 실패하면 이메일 에이전트는 포기하기 전에 보고를 재시도해야 합니다. 이메일이 실패하더라도 보고가 다시 실행되어서는 안 됩니다. 단순한 크론 (cron) 더미가 아니라 DAG (directed acyclic graph, 유향 비순환 그래프) 오케스트레이터가 필요합니다.

어떤 인프라가 이를 해결하는가

이 분야에서 몇몇 플랫폼들이 등장하고 있습니다:

LiteLLM Agent Platform은 스케줄링(scheduling)을 일급 기본 요소(first-class primitive)로 포함합니다. 즉, cron 스케줄을 가진 에이전트를 정의하고, 에러 핸들링(error handling)을 설정하며, 다른 에이전트에 대한 의존성(dependencies)을 구성하고, 전체 세션 지속성(session persistence)과 함께 실행(runs)을 추적할 수 있습니다. 이 플랫폼은 멀티 런타임 추상화(multi-runtime abstraction, 에이전트가 서로 다른 플랫폼에서 실행되더라도 제어 평면(control plane)이 이를 통합함), 재시작 시의 상태 복구(state recovery), 그리고 모든 실행에 대한 구조화된 관측성(structured observability)을 처리합니다.

n8n, Prefect, Temporal은 모두 2026년에 에이전트 우선(agent-first) 방식의 오케스트레이터 변형 버전을 출시하고 있습니다. 이들은 스케줄링 + 상태 + 관측성 부분을 잘 처리하지만, 제어 평면 추상화(control-plane abstraction, 여러 에이전트 런타임에 걸친 통합 API)를 중심으로 설계되지는 않았습니다.

AWS, Google, Anthropic은 모두 플랫폼이 스케줄링 계층을 처리하는 서버 측 관리형 에이전트 인프라(server-side managed agent infrastructure)를 출시하고 있습니다. 트레이드오프(tradeoff)는 제어권은 줄어들고 편의성은 높아진다는 점입니다.

데이터 거주성(data residency), 커스텀(customization) 또는 컴플라이언스(compliance)를 위해 셀프 호스팅(self-hosted) 제어권을 원하는 팀들을 위해 나타나고 있는 패턴은 다음과 같습니다: 에이전트 플랫폼 (제어 평면) + 선택한 런타임 + 스케줄링 및 오케스트레이션을 위한 인프라.

질문해야 할 세 가지 사항

프로덕션(production) 에이전트를 위한 플랫폼을 평가하고 있다면, 다음을 질문하십시오:

1. cron을 다시 구축하지 않고도 에이전트가 정기적으로 실행되도록 스케줄링할 수 있는가? 플랫폼 자체가 스케줄을 관리하고, 재시도(retries)를 처리하며, 결과를 추적할 수 있습니까?

2. 플랫폼이 실행 간의 세션 상태(session state)를 추적하는가? 에이전트가 작업을 시작했다가 실패한 후 재시도할 때, 컨텍스트(context)를 가지고 재개합니까, 아니면 처음부터 다시 시작합니까?

3. 플랫폼이 멀티 에이전트 의존성(multi-agent dependencies)을 처리하는가? 외부 도구 없이 "Report Agent가 성공한 후에 Email Agent가 실행된다"라고 설정할 수 있습니까?

만약 답변이 "네, 저희가 구축했습니다"와 "네, 하지만 직접 연결해야 합니다"로 갈린다면, 당신은 인프라 계층을 찾은 것입니다.

이것이 지금 중요한 이유

2026년에는 세 가지 일이 동시에 일어나고 있습니다:

1. 팀들이 에이전트를 프로덕션(production)에 배포하고 있습니다. 파일럿이나 개념 증명(PoC) 단계가 아닙니다. 실제 워크플로 자동화(workflow automation) 단계입니다.

2. 에이전트 워크플로(agent workflows)는 상태 유지(stateful)가 필요하며 장시간 실행됩니다. 더 이상 요청-응답(request-response) 방식이 아닙니다. 이들은 몇 시간 또는 며칠에 걸쳐 지속되는 비동기적(asynchronous)이고 다단계인 프로세스입니다.

3. 관측 가능성(Observability)과 거버넌스(governance)는 필수 사항입니다. 규제 압박(EU AI Act, Colorado AI Act)과 운영상의 현실(에이전트가 무엇을 했는지 이해해야 함)로 인해, 팀들은 제어 및 감사 계층(control and audit layer)을 구축할 수밖에 없습니다.

스케줄링(Scheduling)은 이 세 가지가 함께 작동하도록 만드는 빠진 조각입니다.

만약 당신이 2026년에 에이전트 시스템을 구축하면서 스케줄링, 상태 복구(state recovery), 관측 가능성을 직접 수동으로 다시 만들고 있다는 것을 깨달았다면, 그것은 플랫폼이 잘못되었다는 신호가 아닙니다. 그것은 문제 영역이 실재하며, 에이전트 스케줄링을 위한 인프라가 필수적인 기본 요건(table-stakes)이 되고 있다는 신호입니다.

지금 앞서 나가는 팀들은 에이전트 스케줄링을 사후 고려 사항이 아닌 인프라로 취급하는 팀들입니다.

당신이 맞닥뜨린 다음 프로덕션 에이전트 인프라 문제는 무엇인가요? 플랫폼의 기본 요소(platform primitive)가 되어야 한다고 생각함에도 불구하고, 당신이 직접 수동으로 다시 만들고 있는 것이 무엇인지 궁금합니다.