장기 실행 도구 호출

오래 걸리는 작업을 에이전트가 안전하게 기다리고 재개하는 방식은 무엇인가.

수초가 아니라 수분·수시간이 걸릴 수 있는 도구 작업을 Agent가 안전하게 시작하고, 상태를 보존하며, 나중에 재개하려면 어떤 구조가 필요한가?

장기 실행 도구 호출은 몇 초 안에 결과가 돌아오는 일반적인 함수 호출과 달리, 작업이 오래 걸리거나 외부 시스템의 완료를 기다려야 하는 도구 실행을 말한다.

예를 들어 대규모 코드 빌드, 영상 인코딩, 데이터 파이프라인, 긴 브라우저 자동화, 외부 승인 대기는 하나의 HTTP 요청을 열어둔 채 기다리는 방식으로 처리하기 어렵다.

Agent가 도구를 호출한 뒤 결과가 나올 때까지 하나의 연결을 계속 유지하면 몇 가지 문제가 생긴다.

그래서 긴 작업은 보통 호출이 아니라 작업 제출로 모델링한다.

가장 단순한 패턴은 다음과 같다.

이 구조에서는 Agent 세션과 실제 실행시간을 분리할 수 있다.

결과를 받는 방법은 크게 polling과 callback으로 나눌 수 있다.

Polling은 Agent가 일정 간격으로 작업 상태를 조회하는 방식이다. 단순하지만 조회 비용이 반복된다.

Callback이나 webhook은 작업 완료 시 실행 시스템이 이벤트를 보내는 방식이다. 효율적이지만 이벤트 전달 실패, 인증, 중복 이벤트 처리까지 설계해야 한다.

작업이 여러 단계라면 각 단계의 결과를 저장하는 checkpoint가 유용하다.

중간 상태가 없다면 90% 진행된 작업이 마지막 단계에서 실패했을 때 처음부터 다시 해야 할 수 있다. 반대로 체크포인트가 있으면 완료된 단계를 건너뛰고 실패한 지점 근처에서 재개할 수 있다.

Agent는 오류를 보고 같은 도구 호출을 다시 시도할 수 있다. 이때 같은 요청이 두 번 실행돼도 문제가 없는지 고려해야 한다.

읽기 작업은 대체로 재시도하기 쉽지만 결제, 메시지 전송, 리소스 생성은 중복 실행이 치명적일 수 있다. 이런 작업에는 idempotency key나 중복 실행 검사가 필요하다.

긴 작업의 상태를 모델의 대화 컨텍스트에만 저장하면 안 된다. 세션이 끊기거나 컨텍스트가 압축되면 작업 상태를 잃을 수 있기 때문이다.

실행 상태는 데이터베이스나 durable workflow engine처럼 모델 밖의 영속 저장소가 관리하고, Agent는 필요한 순간에 다시 읽는 것이 안정적이다.

장기 실행 도구는 동기 함수가 아니라 durable job으로 취급하는 편이 안전하다. 안정적인 구조의 핵심은 job id, 명시적 상태, 영속 저장, idempotency, timeout·취소, 그리고 완료를 다시 Agent에게 전달하는 메커니즘이다.