배경 및 맥락

생성형 AI 제품이 단순 chat completion에서 agent workflow로 이동하면서, 실제 운영 병목은 응답 품질보다 장시간 작업의 상태 관리로 옮겨가고 있다. Deep Research, 대용량 Batch 처리, 장시간 video generation처럼 수분에서 수시간이 걸리는 작업에서는 클라이언트가 반복적으로 상태를 조회하는 polling 방식이 API 비용과 지연을 동시에 키운다. 특히 여러 작업을 병렬로 실행하는 agent 시스템에서는 polling 수만 건이 운영 부담과 장애 표면을 만든다.

Google의 이번 발표는 Gemini API를 더 이상 즉답형 모델 엔드포인트가 아니라 비동기 작업 런타임으로 다루기 시작했다는 신호다. 완료 시점에 서버가 이벤트를 밀어주는 구조는 메시지 큐, workflow engine, job scheduler와의 결합을 훨씬 자연스럽게 만든다.

---

핵심 내용

Google은 Gemini API Webhooks를 통해 작업 완료 시 실시간 HTTP POST를 전송한다고 밝혔다. 이 기능은 Batch API, Deep Research, 긴 영상 생성처럼 오래 걸리는 작업에 맞춰 설계됐고, 개발자는 더 이상 GET operations를 반복 호출하지 않아도 된다. 보안 측면에서는 Standard Webhooks 규격을 따르며 webhook-signature, webhook-id, webhook-timestamp 헤더를 사용해 서명 검증, idempotency, replay 방지를 구현한다.

구성 방식도 실무적이다. 프로젝트 전역 webhook은 HMAC으로 보호할 수 있고, 개별 요청에서는 JWKS 기반으로 엔드포인트를 동적으로 override할 수 있다. 또한 최소 한 번 전달(at-least-once delivery)을 보장하고 최대 24시간 자동 재시도를 제공해, 네트워크 불안정이나 일시적 다운타임을 견딜 수 있게 했다.

---

경쟁 구도 / 비교

대부분의 모델 API는 아직도 long-running job에서 polling을 기본값으로 둔다. 이 방식은 구현은 단순하지만, job 수가 늘어날수록 불필요한 API 트래픽과 운영 복잡도가 기하급수적으로 증가한다. 반면 webhook 기반 구조는 상태 변경을 이벤트로 외부 시스템에 전달하므로, agent orchestration 계층이 queue consumer나 workflow worker처럼 동작할 수 있다.

이 차이는 단순 편의 기능이 아니라 플랫폼 성격의 차이다. webhook이 표준화될수록 모델 공급자는 inference vendor를 넘어 workflow runtime provider가 되고, 개발팀은 LLM 호출 로직보다 이벤트 처리 아키텍처의 안정성을 더 크게 보게 된다.

---

의미

산업적으로는 agent 플랫폼의 성숙도가 모델 성능에서 운영 시스템 품질로 이동하고 있다는 신호다. 앞으로 장시간 AI 작업을 많이 다루는 제품일수록 callback reliability, retry semantics, auditability가 핵심 평가 항목이 된다.

실무적으로는 Gemini 기반 시스템을 운영하는 팀이 polling loop를 걷어내고 webhook consumer, dead-letter queue, 서명 검증, 중복 수신 방지, 추적용 event logging을 표준 컴포넌트로 준비해야 한다. agent 앱은 점점 웹 앱이 아니라 비동기 분산 시스템처럼 설계해야 한다.