NVIDIA의 2026년 6월 GTC Taipei 프로그램에는 몇 시간 또는 며칠 동안 계획하고 작동하는 장기 실행 AI 에이전트 (long-running AI agents)에 관한 세션이 포함되어 있습니다. 일단 작업이 하나의 프로세스보다 오래 지속되면, 신뢰성은 임대(lease)와 복구(recovery)에 달려 있습니다.

명시적인 작업자 소유권(worker ownership)을 사용하세요:

UPDATE tasks
SET lease_owner = :worker,
    lease_expires_at = CURRENT_TIMESTAMP + INTERVAL '30 seconds'
...

작업자(worker)는 상태가 양호한 동안 임대(lease)를 갱신합니다. 도구 효과(Tool effects)는 멱등성 키(idempotency keys)를 사용합니다. 다른 작업자는 만료된 후에만 재개할 수 있으며, 동작하기 전에 내구성이 있는 작업 이벤트(durable task events)를 다시 재생(replay)해야 합니다.

최소한의 텔레메트리 (Minimum telemetry)

agent_task_lease_seconds
agent_task_heartbeat_age_seconds
agent_task_resume_total
...

단순히 높은 작업 지속 시간(task duration)이 아니라, 오래된 하트비트(stale heartbeats)와 반복되는 재개(repeated resumes)에 대해 경고를 설정하세요. 일부 작업은 길게 실행되는 것이 정상입니다.

드레인 테스트 (Run the drain test) 실행

1. 두 개의 내구성이 있는 단계(durable steps) 사이에서 대기(sleep)하는 가짜 도구(fake tool)로 작업을 시작합니다.
2. 작업자에게 일반적인 종료 신호(termination signal)를 보냅니다.
3. 작업자가 새로운 작업을 수락하는 것을 중단하는지 확인합니다.
4. 활성 임대(active lease)가 드레인 창(drain window) 동안에만 갱신되는지 확인합니다.
5. 마감 시간 이후에 강제 종료(force termination)합니다.
6. 다른 작업자를 시작하고, 첫 번째 효과를 반복하지 않고 재개하는지 확인합니다.

타임스탬프, 작업 ID, 임대 소유자(lease owners), 그리고 효과 멱등성 키(effect idempotency keys)를 기록하세요. 그 후 일회용 큐(disposable queue)를 정리합니다.

이것이 제가 MonkeyCode를 단순히 그 뒤에 있는 모델로만 판단하기보다 워크플로(workflow)로서 평가할 것을 권장하는 이유입니다. 장기 실행 코딩 작업은 내구성이 있는 상태(durable status)와 배포 소유권(deployment ownership)을 가시적인 관심사로 만듭니다. 호스팅된 SaaS는 플랫폼을 직접 운영하는 것을 피하게 해 주며, 오픈 소스 버전은 팀이 제어권이 필요할 때 셀프 호스팅 경로를 제공합니다. 어떤 선택을 하더라도 선택한 환경에서 취소, 복구 및 감사 증거(audit evidence)를 검증해야 할 필요성은 사라지지 않습니다.

저는 여기서 운영 환경의 결함 주입(fault-injection) 벤치마크를 보고하는 것이 아닙니다. 이 절차는 재사용 가능한 수락 테스트(acceptance test)입니다.

공개 사항: 저는 MonkeyCode 사용자로서 저의 개인적인 경험을 공유하는 것이며, 해당 프로젝트와는 관련이 없습니다.

하루 동안 실행될 수 있는 에이전트는, 하루 동안 버티지 못하는 워커(worker)로부터도 살아남아야 합니다. 자율성을 높이기 전에 소유권(ownership)을 만료 가능하게 만들고, 효과(effects)를 멱등(idempotent)하게 만들며, 복구(recovery)를 관찰 가능(observable)하게 만드십시오.