이벤트로 움직이는 에이전트 자동화, 무인 실행을 안전하게 설계하는 법

사람이 호출하던 에이전트가 이벤트에 반응하기 시작했다

ChatGPT Work는 2026년 7월 9일 공개된 업무 자동화용 에이전트 제품이며, 8월 말 업데이트에서 웹훅 트리거 기반 예약 작업과 공유 태스크가 추가됐다. Codex 앱도 ChatGPT 데스크톱으로 병합되면서 Chat·Work·Codex가 하나의 클라이언트에 노출된다.

이 변화의 핵심은 편의 기능이 늘어난 데 있지 않다. 사람이 직접 호출하던 에이전트가 외부 이벤트와 시각 조건에 따라 스스로 실행되는 구조로 바뀌는 데 있다.

무인 실행은 실패 사실이 즉시 드러나지 않을 수 있다. 웹훅 재전송은 정상 동작이므로, 중복 실행을 막지 못하면 같은 작업이 반복된다. 트리거가 폭주하면 실행 횟수는 예측 범위를 벗어나고 과금과 부하가 함께 튄다. 따라서 트리거 등록부터 실행 결과 통지와 감사 로그까지 하나의 실행 체계로 다뤄야 한다.

수신 단계에서 실행 권한을 통제한다

어떤 시스템이 어떤 이벤트로 에이전트를 깨울 수 있는지 먼저 등록한다. 등록되지 않은 발신처의 호출은 수신 단계에서 폐기해야 한다. 발신처별로 서명 키를 발급하고 이를 검증하는 일도 같은 맥락이다. 인증 없이 공개 엔드포인트를 열어 두는 것은 실행 권한을 외부에 넘기는 것과 다르지 않다.

이벤트 페이로드는 스키마로 고정한다. 필수 필드 누락이나 타입 불일치를 실행 전에 걸러내야 발신처 변경 문제와 처리 로직 문제를 구분할 수 있다. 스키마 검증 실패는 실행 실패와 별도 범주로 남겨야 원인 추적이 길어지지 않는다.

중복과 장시간 실행을 제어하는 흐름

이벤트마다 멱등 키를 부여하고, 일정 기간의 실행 이력과 대조해 재실행을 차단한다. 발신처가 제공하는 이벤트 ID를 우선 사용하고, 없을 때만 페이로드 해시를 대체 수단으로 쓴다. 다만 해시는 내용은 같지만 의미가 다른 이벤트까지 같은 것으로 묶을 수 있다.

사용자 대기가 걸린 작업과 배경 정리 작업은 서로 다른 우선순위를 가져야 한다. 단일 FIFO에서는 긴 배치 작업 하나가 긴급한 작업까지 뒤로 밀어낸다. 큐 길이와 대기 시간에 상한을 두고, 초과분은 지연시키는 대신 명시적으로 거절한다.

장시간 작업에는 실행 시간 상한을 정한다. 상한을 넘길 가능성이 있는 작업은 단계로 나누고 체크포인트를 남긴다. 중단된 지점에서 다시 시작할 수 있도록 중간 상태를 외부에 저장해야 한다. 처음부터 다시 실행하는 재시도는 비용과 부작용을 모두 두 배로 만들 수 있다.

⤢✕

재시도와 통지는 실패의 확산을 막는 장치다

재시도는 즉시 재시도, 지수 백오프, 최종 포기의 세 단계로 나누고 각 단계에 상한 횟수를 둔다. 입력이 잘못된 요청처럼 재시도해도 결과가 달라지지 않는 실패를 반복하면 부하만 커진다. 재시도 가능한 실패와 그렇지 않은 실패를 분리해야 한다.

통지 경로도 성공과 실패를 다르게 설계한다. 성공은 요약으로 보내고 실패는 즉시 알린다. 모든 결과를 같은 채널에 보내면 실패 신호가 성공 메시지 더미에 묻힌다. 알림에는 트리거 출처, 멱등 키, 실행 시각, 실패 사유를 포함한다. 알림만 보고 재현할 수 없다면 운영 수단으로서 가치가 떨어진다.

감사 로그에는 누가 실행을 깨웠는지, 무엇을 했는지, 어떤 외부 시스템을 건드렸는지를 실행 단위로 남긴다. 로그 보관 기간과 접근 권한도 함께 정한다. 사람이 지켜보지 않은 실행일수록 사후 재구성은 유일한 검증 수단이 된다.

처음에는 되돌릴 수 있는 업무부터 맡긴다

반복 빈도가 높고 판단 폭이 좁으며 실패해도 되돌릴 수 있는 업무가 무인 실행의 출발점이다. 되돌릴 수 없는 결과를 만드는 업무는 초기 후보에서 제외한다. 처음부터 최악의 사례를 자동화하면 신뢰를 한 번에 잃을 수 있다.

트리거 조건은 문장으로 적어 검토받는다. 어떤 이벤트가 어떤 조건에서 어떤 작업을 호출하는지 명시하면, 같은 작업을 부르는 겹친 트리거를 발견하기 쉽다. 이런 중복 구성이 중복 실행의 흔한 출처다.

초기 범위는 읽기 전용 작업이나 초안 생성으로 제한하고, 확정 행위는 사람이 수행하게 둔다. 한정 기간 동안 실패율과 오탐 사례를 모아 확대 여부를 판단한다.

담당자가 실제로 확인하는 채널에 실패를 보내고, 무응답이면 상위로 넘기는 경로를 마련한다. 정상 재시도까지 전부 알리기 시작하면 알림 피로가 쌓이고, 결국 사람이 채널을 무시하게 된다.

일간·주간 실행 횟수와 토큰 사용량에는 상한을 둔다. 상한을 넘으면 자동으로 큐를 막고, 이를 장애가 아니라 설계된 동작으로 다룬다. 상한이 없으면 트리거 폭주가 그대로 청구서가 된다.

전체 트리거 수신을 멈추는 스위치와 특정 작업만 멈추는 스위치도 분리한다. 정지 권한을 가진 사람과 정지 뒤 복구 절차를 미리 정해 두어야 사고 중에 권한을 찾느라 피해가 커지는 일을 피할 수 있다. 신규 트리거 등록, 무인 실행 범위 확대, 비용 상한 조정은 승인 대상으로 두고 감사 로그의 정기 표본 점검을 운영 활동에 포함한다.

웹훅과 폴링은 요구 조건이 다르다

구분	웹훅 이벤트 구동	주기 폴링
반응 지연	낮음	주기에 비례
유휴 자원 소모	낮음	지속 발생
수신 인증 요구	필수	불필요
중복 처리 위험	높음	낮음
발신처 장애 영향	이벤트 유실	다음 주기 복구
구현 복잡도	높음	낮음

웹훅은 사건이 발생한 시점에 실행을 걸 수 있어 반응 지연이 전송 시간에 수렴한다. 변화가 없을 때는 자원을 쓰지 않고, 이벤트 단위의 맥락이 함께 들어오므로 실행 원인도 명확하다. 대신 공개 수신 엔드포인트가 필요하므로 발신처 인증과 서명 검증이 필수다. 재전송이 정상 동작이어서 멱등 처리가 없으면 중복 실행이 일상적으로 발생할 수 있고, 수신 측이 잠시 멈춘 동안의 이벤트는 발신처 재시도 정책에 좌우된다.

폴링은 구현이 단순하고 수신 엔드포인트를 열지 않아 공격면이 좁다. 실행 시점이 예측 가능해 부하 계획도 세우기 쉽다. 이전 조회 지점을 기억하면 유실도 구조적으로 잘 생기지 않는다. 반면 평균적으로 주기의 절반만큼 지연이 생기고, 변화가 없어도 계속 조회하므로 대상 시스템과 실행 측 자원을 함께 소모한다.

즉시성이 필요하고 발신처가 재시도를 보장하는 구간에는 웹훅을, 지연 허용치가 넉넉하고 발신처가 이벤트를 밀어주지 않는 구간에는 폴링을 배치하는 방식이 현실적이다.

사람 확인은 되돌릴 수 없는 행위에 남긴다

무인 실행은 사람의 근무 시간과 무관하게 처리할 수 있고 야간·주말 대기를 없애며 반복 업무의 단위 비용을 크게 낮춘다. 반대로 잘못된 판단은 곧바로 외부 시스템에 반영될 수 있고, 다음 근무일이 되어서야 발견된다면 발견 지연이 피해 규모로 이어진다.

사람 확인 후 실행은 되돌릴 수 없는 행위 앞에 판단 지점을 하나 더 둔다. 예외 상황을 사람이 흡수할 수 있지만, 처리량은 확인자의 가용성에 묶이고 확인이 형식화되면 안전 효과 없이 지연만 남는다. 되돌릴 수 있는 작업은 무인으로, 되돌릴 수 없는 작업에는 확인을 붙이는 구성이 두 방식의 장점을 함께 취한다.

단일 실행 큐는 운영이 단순하고 모니터링 지표가 한곳에 모이며 자원 배분이 자동으로 균형을 이룬다. 그러나 한 유형의 작업이 폭주하면 전체가 밀리고, 특정 작업의 실패가 큐 전체의 재시도 부하로 번져 장애 격리가 어렵다.

작업 유형별 분리 큐는 긴급 작업과 배경 작업이 서로를 밀어내지 않게 하고, 한 유형이 멈춰도 다른 유형은 계속 실행되게 한다. 유형마다 다른 재시도 및 상한 정책을 줄 수도 있다. 대신 큐 수만큼 모니터링과 자원 배분 판단이 늘고 전체 대기 상황을 한눈에 보기 어려워진다. 실행 유형이 서너 개를 넘고 지연 요구가 서로 달라지는 시점부터는 분리 큐의 운영 부담보다 장애 격리 이득이 커진다.

운영 통제로 연결되는 설계 요소

트리거 조건 명세화와 자동화 대상 선별은 프로세스 분해 및 자동화 적합성 평가와 연결된다. 사람 확인 지점을 어디에 둘지는 내부통제 설계의 문제다.

실행 큐의 우선순위와 분리 운영은 작업 스케줄링 및 부하 관리의 전형적인 운영 과제다. 감사 로그는 무인 실행의 추적성을 확보하는 수단이며, 재시도 백오프와 상한은 장애 전파를 끊는 가용성 보호 장치가 된다. 긴급 정지 스위치는 서비스 연속성 계획에서 필요한 수동 개입 경로에 대응한다.

무인 실행이 표준 사용 형태가 되는 흐름

상용 에이전트 제품은 웹훅 트리거와 예약 실행을 기본 기능으로 편입하며 무인 실행을 표준 사용 형태로 자리 잡게 하는 방향으로 움직이고 있다. 멱등 키와 서명 검증은 에이전트 수신 엔드포인트의 최소 요건으로 요구되는 흐름이다.

실행 비용 상한과 긴급 정지 스위치는 도입 심사 항목에 포함되며 운영 요건으로 굳어지는 방향이다. 무인 실행 감사 로그를 기존 운영 감사 체계에 통합하는 구성도 조직 표준으로 확산되는 흐름이다.

사람이 없는 시간의 자동화는 트리거 설계가 사고 예방 설계가 될 때만 운영할 수 있다. 입구에서는 발신처 인증과 스키마 검증으로 범위를 좁히고, 실행 중에는 멱등 키·재시도 상한·비용 상한으로 폭주를 막으며, 실행 뒤에는 감사 로그와 실패 알림으로 검증 가능성을 남긴다. 특히 실패 알림이 소음에 묻히지 않도록 관리하는 일은 무인 자동화의 마지막 안전 요건이다.