대부분의 에이전트 튜토리얼은 5분짜리 대화에서 끝납니다. 사용자가 말하고, 모델이 답하고, 도구를 한두 번 호출합니다. 하지만 실제 업무는 그렇게 짧지 않습니다. 신규 입사자 온보딩은 서류 서명과 장비 배송을 기다리며 며칠에서 몇 주가 걸립니다. 인보이스 분쟁은 거래처 회신을 기다립니다. 세일즈 prospecting은 여러 touchpoint 사이에 긴 대기 시간이 있습니다.
Google Developers Blog는 2026년 5월 12일 Agent Development Kit(ADK)로 장시간 AI 에이전트를 만드는 튜토리얼을 공개했습니다. 예시는 New Hire Onboarding Coordinator Agent입니다. 환영 패킷을 보내고, 서류 서명을 기다리고, IT provisioning을 위임하고, 하드웨어 배송을 기다린 뒤, 첫날 일정을 보내는 흐름입니다.
이 글의 핵심은 “큰 context window를 쓰자”가 아닙니다. 오히려 반대입니다. 장시간 workflow에서는 raw conversation history에 의존하지 말고, 명시적인 durable state machine과 persistent session, event-driven resume 구조를 써야 합니다.
일반적인 stateless 패턴은 모든 사용자 메시지와 모델 응답을 conversation history에 붙이고, 다음 호출 때 전체 blob을 다시 넣습니다. 짧은 Q&A에는 충분합니다. 하지만 며칠짜리 업무에서는 세 가지 문제가 생깁니다.
첫째, prompt context pollution입니다. 오래된 tool output, 중복된 instruction, 지나간 잡담이 누적됩니다. 모델은 지금 어떤 단계인지 헷갈리기 시작합니다.
둘째, token cost explosion입니다. 현재 결정에 필요하지 않은 이틀 전 대화를 계속 replay하면 비용이 커집니다. 수백 턴짜리 업무라면 모델 호출마다 낭비가 반복됩니다.
셋째, idle time 이후 hallucination입니다. 에이전트가 3일 동안 문서 서명을 기다리다가 다시 깨어났을 때, 거대한 context dump를 보고 중간 승인이나 배송 상태를 실제로 있었던 일처럼 착각할 수 있습니다.
따라서 해결책은 더 긴 history가 아니라 더 명확한 상태입니다. “지금 단계는 WELCOME_SENT이고, pending signal은 document_signed다”처럼 현재 상태를 구조화해서 보관해야 합니다.
ADK 튜토리얼은 START, WELCOME_SENT, DOCUMENTS_SIGNED, IT_PROVISIONED, HARDWARE_DELIVERED, COMPLETED 같은 상태를 정의합니다. 이 방식의 장점은 모델이 과거 대화에서 현재 단계를 추론하지 않아도 된다는 점입니다. 시스템 instruction은 session state의 current_step, new_hire_details, pending_signals를 직접 읽습니다.
실무에서 상태 머신을 설계할 때는 다음 기준을 권합니다.
예를 들어 환불 처리 에이전트라면 RECEIVED, ELIGIBILITY_CHECKED, APPROVAL_PENDING, REFUND_REQUESTED, REFUND_COMPLETED, REJECTED 같은 상태가 필요합니다. APPROVAL_PENDING 상태에서는 환불 실행 tool을 호출하지 못하게 해야 합니다. 사람이 승인하거나 정책 조건이 충족되어야 다음 단계로 넘어갑니다.
상태 머신이 있어도 저장소가 휘발성이면 소용없습니다. 컨테이너가 재시작되거나 scale-to-zero가 발생하면 상태가 사라집니다. Google 튜토리얼은 ADK의 DatabaseSessionService를 사용해 SQLite 또는 Cloud SQL 같은 지속 저장소에 session state를 보관하는 구조를 보여줍니다.
여기서 실무 포인트는 “대화 저장”과 “상태 저장”을 구분하는 것입니다. 모든 메시지를 보관하는 것보다 현재 업무 상태, 필요한 식별자, pending signal, 마지막 안전 checkpoint를 보관하는 것이 더 중요합니다. 로그는 감사와 디버깅용이고, state는 다음 실행을 위한 source of truth입니다.
운영 환경에서는 다음 필드를 기본으로 두면 좋습니다.
이렇게 하면 모델이 다시 깨어났을 때 필요한 정보만 볼 수 있습니다. 오래된 대화는 필요할 때만 조회하면 됩니다.
장시간 에이전트의 핵심은 idle time입니다. 며칠 동안 문서 서명을 기다리는데 thread를 계속 붙잡고 있거나 주기적으로 polling하면 비용과 복잡도가 커집니다. ADK 튜토리얼은 external event가 들어왔을 때 webhook endpoint가 session을 hydrate하고 state_delta를 적용한 뒤 agent를 resume하는 방식을 보여줍니다.
이 패턴은 여러 업무에 그대로 적용됩니다.
중요한 것은 webhook payload를 그대로 믿지 않는 것입니다. event source 검증, idempotency key, replay 방지, 상태 전이 유효성 검사가 필요합니다. 예를 들어 현재 상태가 START인데 hardware_delivered 이벤트가 들어오면 무시하거나 error state로 보내야 합니다.
튜토리얼은 IT provisioning을 specialized sub-agent에 위임합니다. 여기서 multi-agent는 “모델 여러 개를 붙이면 똑똑해진다”가 아닙니다. 역할과 권한을 분리하는 설계입니다.
HR onboarding agent는 전체 workflow를 알고 있지만, IT 계정 생성의 세부 절차는 IT agent가 처리합니다. Finance agent, Security agent, Legal agent도 같은 방식으로 나눌 수 있습니다. 각 agent는 자기 도구와 상태 범위만 가져야 합니다.
권한 분리 없이 multi-agent를 도입하면 오히려 위험합니다. 모든 agent가 모든 tool을 호출할 수 있으면 책임 경계가 사라집니다. delegation에는 input schema, output schema, timeout, failure handling, approval policy가 함께 있어야 합니다.
장시간 AI 에이전트 설계의 핵심은 모델에게 오래 기억시키는 것이 아닙니다. 업무 상태를 모델 밖에 명확히 저장하고, 모델은 현재 단계에서 필요한 판단만 하게 만드는 것입니다. 다음 에이전트 프로젝트가 하루를 넘기는 업무라면 첫 질문은 프롬프트가 아니라 이것이어야 합니다. “이 workflow의 상태 머신은 무엇인가?”
