대부분의 에이전트 데모는 5분짜리 챗봇입니다. 사용자가 묻고, 모델이 답하고, 도구 한두 번 호출하면 끝납니다. 하지만 실무 프로세스는 그렇게 짧지 않습니다. 신규 입사자 온보딩은 며칠에서 몇 주가 걸리고, 인보이스 분쟁은 공급사 답변을 기다리며 멈춥니다. 영업 시퀀스는 한 달 동안 여러 번 follow-up이 필요합니다.
Google Developers Blog가 2026년 5월 12일 공개한 ADK 튜토리얼은 이 문제를 정면으로 다룹니다. 예시는 New Hire Onboarding Coordinator Agent입니다. 에이전트가 welcome packet을 보내고, 문서 서명을 기다리고, IT provisioning을 위임하고, 하드웨어 배송을 기다린 뒤 day-one schedule을 보냅니다. 핵심은 장시간 AI 에이전트를 채팅 로그가 아니라 명시적 상태 머신과 persistent session으로 운영한다는 점입니다.
이 글은 ADK 자체 사용법보다 더 넓은 설계 원칙을 정리합니다. LangGraph, Temporal, 자체 workflow engine을 쓰더라도 같은 문제가 생기기 때문입니다.
가장 흔한 에이전트 구현은 모든 사용자 메시지와 모델 응답을 conversation history에 붙이고, 다음 호출 때 전체를 다시 모델에 넣는 방식입니다. 짧은 Q&A에는 괜찮습니다. 그러나 며칠짜리 업무에는 세 가지 문제가 생깁니다.
첫째, prompt context pollution입니다. 오래된 도구 결과, 이미 끝난 의사결정, 중복 지시가 context window를 채웁니다. 모델은 현재 단계가 무엇인지 헷갈리기 시작합니다. 둘째, token cost explosion입니다. 매번 몇 주치 대화를 재생하면 비용이 빠르게 커집니다. 셋째, idle time hallucination입니다. 에이전트가 3일 동안 문서 서명을 기다리다 재개될 때, 모델은 중간에 일어나지 않은 일을 “기억”했다고 착각할 수 있습니다.
이 문제는 더 큰 context window로 해결되지 않습니다. 문제는 정보량이 아니라 상태 표현 방식입니다. 에이전트의 현재 단계, 완료된 작업, 대기 중인 외부 이벤트, 다음에 호출 가능한 도구를 명시적 state로 저장해야 합니다.
Google 튜토리얼은 START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, COMPLETED 같은 명시적 상태를 둡니다. 에이전트는 채팅 기록에서 현재 위치를 추론하지 않고 session state의 current_step을 읽습니다.
이 구조의 장점은 단순합니다. 상태가 START면 이름, 이메일, 시작일을 받고 welcome packet을 보냅니다. WELCOME_SENT면 문서 서명을 기다리고 다른 도구를 호출하지 않습니다. DOCUMENTS_SIGNED면 IT provisioning으로 넘어갑니다. 상태가 허용하지 않는 도구 호출은 설계상 막을 수 있습니다.
상태 머신은 모델에게 “잘 기억해줘”라고 부탁하는 대신 시스템이 진행 순서를 보장하게 합니다. 특히 승인, 결제, 계정 생성, 고객 커뮤니케이션처럼 실수 비용이 큰 업무에서는 필수입니다. 에이전트가 똑똑해져도 workflow invariant는 코드로 보장해야 합니다.
상태 머신만 있어도 메모리에 저장하면 서버 재시작 때 모두 날아갑니다. 그래서 long-running agent에는 persistent session이 필요합니다. Google 예시는 ADK의 DatabaseSessionService를 SQLite 또는 Cloud SQL에 연결해 ToolContext.state 변경을 durable하게 저장합니다.
여기서 중요한 원칙은 도구가 상태 전이를 atomic하게 수행해야 한다는 점입니다. 예를 들어 send_welcome_packet 도구가 성공했다면 current_step을 WELCOME_SENT로 바꾸고 pending_signals에 document_signed를 넣어야 합니다. 서버가 바로 죽어도 재시작 후에는 WELCOME_SENT에서 이어져야 합니다.
실무에서는 다음 정보를 session에 저장하는 편이 좋습니다.
반대로 raw chat history 전체를 영구 상태의 중심에 두면 안 됩니다. 대화 로그는 감사와 디버깅용이고, workflow state는 별도 schema로 관리해야 합니다.
장시간 업무의 대부분은 idle time입니다. 문서 서명, 배송 완료, 결제 확인, 고객 답변, 법무 승인처럼 외부 이벤트를 기다립니다. 이때 에이전트가 계속 polling하거나 스레드를 붙잡고 있으면 비용과 운영 복잡도가 커집니다.
더 나은 구조는 event-driven resumption입니다. 외부 시스템이 webhook을 보내면 서버가 session을 hydrate하고, pending signal을 처리한 뒤 에이전트를 다음 상태에서 재개합니다. 예를 들어 /webhooks/document_signed가 호출되면 current_step을 DOCUMENTS_SIGNED로 바꾸고 IT provisioning sub-agent를 실행합니다.
이 구조는 queue와 잘 맞습니다. webhook handler는 이벤트를 검증하고 idempotency key를 확인한 뒤 job queue에 넣습니다. worker는 session을 로드하고 상태 전이를 시도합니다. 이미 처리된 이벤트면 무시합니다. 실패하면 retry policy를 적용합니다.
장시간 프로세스는 보통 여러 전문 영역을 포함합니다. 온보딩에서는 HR, IT, 시설, 보안이 얽힙니다. 고객지원에서는 billing, technical support, account management가 얽힙니다. 그래서 sub-agent delegation이 필요합니다.
하지만 멀티 에이전트를 먼저 붙이면 복잡도가 폭발합니다. 순서는 상태 머신, persistent session, 이벤트 재개, 그 다음 sub-agent입니다. 메인 오케스트레이터는 current_step과 next_allowed_tools를 관리하고, 전문 sub-agent는 제한된 작업만 수행하게 해야 합니다.
예를 들어 IT provisioning sub-agent는 계정 생성과 접근권한 설정만 담당합니다. HR 에이전트가 가진 개인 정보 전체를 볼 필요가 없습니다. Sub-agent마다 입력 schema, 출력 schema, 권한 범위, timeout, fallback 정책을 따로 둬야 합니다.
출처: Google Developers Blog “Build Long-running AI agents that pause, resume, and never lose context with ADK”, 2026년 5월 12일 공개.
