무인 에이전트 자동화, 크론 폴링과 이벤트 트리거의 비용 격차를 실측하다

무인으로 돌아가는 에이전트 자동화 시스템을 운영하고 있고, 폴링 주기를 1분으로 할지 5분으로 할지 감으로 정해온 엔지니어라면 이 글이 유용합니다. cron 기반 스킬 러너를 여러 개 굴리는 인프라를 가진 조직이라면 특히 그렇습니다. 이 연구는 폴링 주기 하나를 두고 벌어지는 지연시간과 낭비 비용의 줄다리기를 실제로 재본 결과이자, 이벤트 기반 트리거로 옮겨갈 때 반드시 같이 가져가야 할 멱등성 설계를 수치로 보여주는 작업입니다.

문제의식: 폴링 주기는 왜 늘 감으로 정해지는가

사람이 지켜보지 않는 자동화 시스템은 대개 정해진 시간마다 깨어나 상태를 확인하고, 바뀐 게 있으면 움직이고 없으면 다시 잠드는 방식으로 만들어집니다. 이유는 단순합니다. 폴링은 파라미터가 하나뿐이고, 메시지가 영영 오지 않아 무한정 기다릴 일도 없고, 최악의 동작이 주기 안에서 확정되며, 별도의 푸시 인프라나 외부에 열린 엔드포인트, 메시지 브로커, 중복 처리 로직이 필요 없습니다. 폴링이 기본값인 건 최적이어서가 아니라 엔지니어링 저항이 가장 적은 길이기 때문입니다.

문제는 이 선택이 만드는 트레이드오프를 대부분의 운영자가 실제로 측정하지 않는다는 데 있습니다. 주기를 짧게 잡으면 상태 변화를 알아채는 시간은 줄지만, 깨어나서 아무것도 발견하지 못하고 그냥 종료하는 호출 수가 그만큼 늘어납니다. 주기를 길게 잡으면 그 낭비는 줄지만 탐지 지연이 워크로드가 감당할 수 있는 범위 밖으로 밀려날 수 있습니다. 50분 늦게 처리된 신호는 결국 처리되더라도 무의미할 수 있습니다. 실무에서는 “5분이면 반응성이 괜찮아 보인다”거나 “1시간이면 저렴해 보인다”는 느낌으로 주기를 고르고, 이벤트 발생률이 한 자릿수 넘게 바뀌어도 그 값을 다시 들여다보는 일은 드뭅니다. 반대편에 있는 이벤트 기반 트리거링(관측 대상 시스템이 알림을 밀어주고 하네스가 반응하는 방식)은 이득이 막연한 채로 큰 마이그레이션 비용으로만 취급되곤 합니다.

무엇을 어떻게 쟀나: 통제된 시뮬레이션 설계

이 연구는 실제 시스템을 배포해 트래픽을 재는 대신, 통제되고 재현 가능한 이산사건 시뮬레이션으로 이 트레이드오프를 측정합니다. 웹훅이나 큐 인프라를 실제로 구축하지 않았고, 이후 보고하는 모든 수치는 시뮬레이션 출력값입니다. 이 선택은 의도적입니다. 두 트리거 방식이 완전히 동일한 이벤트 스트림을 관측하도록 만들어야 지연시간과 비용의 차이를 순전히 트리거 메커니즘 차이로 귀속시킬 수 있고, 워크로드 변동의 영향을 배제할 수 있기 때문입니다.

시간당 4건의 상태 변화가 발생하는 포아송 과정을 24시간 동안 시뮬레이션해, 시드 42로 총 98건의 이벤트를 생성했습니다. 이 이벤트 스트림을 두 팔에 똑같이 흘려보냅니다. 한쪽은 10초부터 7200초(2시간)까지 열 가지 고정 폴링 주기를 순서대로 시도하며, 각 호출은 무언가를 발견하든 못하든 동일하게 1단위 비용을 소모합니다. 다른 쪽은 이벤트가 발생할 때마다 평균 2.0초, 표준편차 0.5초의 가우시안 지연을 갖는 푸시 배달을 시도하며, at-least-once 배달 시맨틱을 흉내 내기 위해 각 이벤트가 3% 확률로 중복 배달을 만들고, 배달마다 멱등성 키 검사(0.02단위)를 거쳐 핸들러를 실행(0.1단위)하며, 5% 확률로 실패하면 최대 3회까지 재시도한 뒤 데드레터로 넘깁니다.

핵심 발견: 어떤 폴링 주기도 이벤트 트리거를 두 축에서 동시에 이기지 못한다

폴링 주기를 짧게 잡을수록 안전할 것 같지만, 실측 결과는 정반대의 그림을 보여줍니다. 10초 주기에서는 8640번의 호출 중 8543번, 즉 98.88%가 깨어나 아무 일도 발견하지 못하고 그냥 종료됩니다. 실무에서 흔히 쓰는 60초 주기조차 낭비 비율이 93.61%에 달합니다. 낭비 비율이 20% 아래로 내려가려면 주기를 1800초 이상으로 늘려야 하는데, 그때는 평균 탐지 지연이 이미 16분 가까이 벌어져 있습니다.

시뮬레이션 결과를 나타낸 그림입니다. 24시간 창, 시간당 4건 발생률의 포아송 이벤트 98건(시드 42) 기준으로, 10초 주기에서는 98.88%, 60초 주기에서도 93.61%의 호출이 허탕입니다. 낭비 비율이 20% 아래로 떨어지는 지점은 주기 1800초 이상이며, 그 대가로 평균 지연은 약 16분까지 늘어납니다.

같은 98건의 이벤트 스트림을 이벤트 기반 푸시로 처리하면 결과가 완전히 다릅니다. 평균 지연은 1.997초, p95는 2.902초, 최댓값은 3.582초에 그치고, 총 비용은 12.12단위입니다. 가장 빠른 폴링 주기인 10초는 8640단위를 써서 평균 지연 5.086초라는, 푸시보다도 못한 결과를 냅니다. 즉 713배 더 많은 컴퓨팅을 쓰고도 지연시간은 2.5배 더 나쁩니다. 반대로 가장 저렴한 7200초 주기는 12.0단위로 푸시와 비용은 비슷하지만, 평균 지연이 3318.250초로 약 1661배 느립니다. 테스트한 열 가지 폴링 주기 중 어느 것도 지연시간과 비용 두 축에서 동시에 푸시를 따라잡지 못했습니다.

시뮬레이션에서 도출한 비율을 정리한 그림입니다(시드 42). 푸시는 평균 지연 1.997초에 비용 12.12단위, 가장 빠른 폴링(10초)은 평균 5.086초에 8640단위, 가장 저렴한 폴링(7200초)은 평균 3318.250초에 12.0단위로 나타났습니다. 푸시는 가장 빠른 폴링보다 지연은 2.5배 낮으면서 컴퓨팅은 713배 적게 쓰고, 가장 저렴한 폴링은 비용은 비슷하지만 지연은 1661배 더 나쁩니다.

이 현상에는 구조적인 이유가 있습니다. 폴링에서는 호출 횟수가 관측 기간을 주기로 나눈 값에 비례하고 평균 지연은 주기의 절반에 비례하기 때문에, 두 값의 곱이 거의 일정하게 유지되는 쌍곡선 위에서만 움직일 수 있습니다. 어느 한쪽을 줄이면 반드시 다른 쪽이 커집니다. 반면 푸시에서는 비용이 샘플링 주기의 역수가 아니라 이벤트 발생률 자체에 비례하고, 지연은 샘플링이 아니라 배달 메커니즘이 결정합니다. 두 값이 서로 분리되어 있습니다. 다만 이 우위는 이벤트가 상대적으로 드문 워크로드에서 두드러지는 성질이며, 이벤트 발생률이 폴링 주기와 맞먹을 정도로 높아지면 낭비 비율 자체가 0에 가까워지므로 격차도 그만큼 좁아집니다.

멱등성은 선택이 아니다: 중복 배달 3.9%가 말해주는 것

지연시간과 비용만큼 중요한 질문이 하나 더 있습니다. 이벤트를 두 번 배달받으면 어떻게 되느냐입니다. at-least-once 배달을 전제로 한 이 실험에서 멱등성 키 검사를 제거하고 나머지 조건을 그대로 유지했더니, 102번의 배달 시도 중 4번, 대략 3.9%가 하류 액션을 잘못 두 번 실행시키는 결과로 이어졌습니다. 원래 실험에서는 멱등성 검사가 정확히 이 중복 3건을 모두 걸러냈고, 98건의 이벤트가 정확히 98건의 액션으로 이어졌으며 데드레터는 0건이었습니다.

이 3.9%라는 숫자를 부하가 몰리거나 네트워크가 불안정할 때만 나타나는 예외 상황으로 읽으면 안 됩니다. at-least-once 배달을 채택하는 순간, 중복 배달은 예외가 아니라 전송 계층의 정상적이고 정해진 동작이 됩니다. 데이터베이스에 대한 중복 쓰기는 upsert로 무해하게 처리할 수 있지만, 에이전트가 취하는 액션은 사정이 다릅니다. 메시지를 두 번 보내거나, 주문을 두 번 넣거나, 이슈를 두 번 열거나, 비용이 드는 하류 워크플로를 두 번 실행시킬 수 있고, 이런 액션 상당수는 사후에 멱등하게 만들 방법이 없습니다. 그래서 중복 제거는 핸들러가 실행되기 전, 트리거 경계에서 이뤄져야 합니다. 재시도 정책에 종료 조건이 없다면 그것은 무한 루프이거나 조용한 유실이며, 둘 다 사람이 들여다볼 수 있는 명시적인 데드레터 큐보다 나쁩니다. 이번 실험에서 데드레터가 0건 나온 것은 실패가 서로 독립적이라는 모델의 가정을 그대로 반영한 결과일 뿐입니다. 실제 장애는 상관관계를 가지고 몰려서 발생합니다. 하류 의존성 하나가 죽으면 그 창 안의 모든 시도가 함께 실패하고, 자격증명이 만료되면 회전할 때까지 모든 호출이 똑같이 실패합니다. 이런 상관 실패 아래에서는 재시도가 독립적인 도움을 거의 주지 못하고, 데드레터 큐야말로 재시도로 못 고친 실패를 붙잡는 유일한 장치가 됩니다.

회사와 사회, 과학에 남는 것

이 결과가 곧바로 남기는 실무적 함의는 세 갈래로 나뉩니다. 회사 차원에서는 cron 기반 launchd 스킬을 다수 굴리는 아웃터 루프 레지스트리가 이벤트 자동화에 투자할 가치가 있는지를 폴링 주기 스윕과 이벤트 지연시간 실측으로 정량 판단할 근거를 얻습니다. 사회 차원에서는 유휴 폴링 루프가 낭비하는 컴퓨팅과 그에 따른 에너지 비용을 줄이는 방법을 제시해, 비슷한 문제를 가진 다른 무인 자동화 운영자들도 참고할 수 있는 결정 기준을 남깁니다. 과학 차원에서는 프로덕션 에이전트 하네스를 다섯 축(루프, 하네스, 평가, 트레이싱, 메모리)으로 나눠 보는 프레임워크에서 명시적으로 비어 있던 축, 즉 트리거링을 채우는 재현 가능한 A/B 방법론을 남깁니다. 도구 라우팅, 자기검증, 스캐폴딩 구조는 이미 여러 연구가 다뤄왔지만, 하네스가 애초에 “할 일이 생겼다”는 사실을 어떻게 알아채는지는 그동안 측정 대상이 아니었습니다.

τ/2 잔여 대기시간이라는 고전적인 결과도 실무적으로 쓸모가 있습니다. 포아송 도착을 주기 τ로 샘플링할 때 평균 탐지 지연이 τ/2로 수렴한다는 이 관계식을 이용하면, 운영자는 자신의 지연시간 예산을 알고 있는 것만으로 최대 허용 폴링 주기를 대략 예산의 두 배로 어림하고, 그 주기에서 호출 횟수를 관측 기간 나누기 주기로 계산해 가격을 매길 수 있습니다. 그 가격이 감당할 수 없는 수준이라면, 남은 선택지는 푸시뿐입니다. 다만 이 논문은 “항상 이벤트로 전환하라”고 말하지 않습니다. 관측 대상이 애초에 푸시 채널을 제공하지 않거나, 상태 변화 자체가 지연 요구사항보다 훨씬 느리게 일어나거나, 아직 이벤트 인프라를 구축할 만큼 워크로드가 정당화되지 않는 경우라면 폴링이 여전히 올바른 선택입니다.

한계

가장 먼저 짚어야 할 한계는 이 모든 수치가 실제 배포가 아니라 시뮬레이션에서 나왔다는 점입니다. 웹훅 엔드포인트나 메시지 브로커, 큐, 이벤트 핸들러를 실제로 구축해 트래픽을 흘린 적이 없습니다. 단일 시드(42)와 단일 발생률(시간당 4건), 서로 독립적이라고 가정한 i.i.d. 실패 모델 위에서만 측정했다는 한계도 있습니다. 이 i.i.d. 실패 가정이 가장 중요한 방향에서 비현실적입니다. 실제 장애는 상관관계를 가지고 몰려서 일어나는데, 이 모델은 그런 상황을 만들지 않기 때문에 데드레터가 0건으로 관측된 결과를 일반화해서는 안 됩니다. 냉시작 지연이나 브로커, 중복 제거 저장소, 모니터링의 상시 운영 비용도 이번 비용 모델에는 반영하지 않았는데 실제 도입 시에는 이 비용만큼 푸시 쪽 우위가 좁아질 가능성이 큽니다. 다음 단계로 가장 자연스러운 것은 실제 무인 자동화 시스템의 신호 발생 트레이스를 기록해 이 시뮬레이션에 재생시켜 보고, 기존 폴링 경로 옆에 실제 푸시 경로를 나란히 배포해 라이브 트래픽에서 지연시간과 비용, 중복률, 데드레터율을 검증하는 필드 실측입니다.

논문 상세 정보는 다음 링크에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-08-04-event-vs-cron-agent-automation