PiHarness가 에이전트를 다시 깨울 때, 티켓도 다시 만들어질까

에이전트가 고객 문의를 읽고 외부 서비스에 지원 티켓을 하나 만들었다고 해보자. 서비스는 생성을 마쳤지만, 반환된 티켓 번호를 에이전트가 저장하기 직전에 프로세스가 죽었다. 다시 켜진 에이전트에게 남은 것은 아직 끝나지 않은 도구 호출이다.

그 호출을 다시 실행하면 티켓이 두 개 생길 수 있다. 그렇다고 무조건 멈추면 오래 걸리는 일을 맡긴 의미가 줄어든다. 이 사이에서 Pi Durable과 Cloudflare PiHarness가 어떤 정보를 보존하고, 어떤 판단을 애플리케이션에 남기는지 살펴보자.

Cloudflare는 10월 2일자 공식 변경 기록에서 PiHarness 베타를 공개했다. 함께 쓰는 Pi Durable은 Earendil이 10월 1일자로 발표한 실험적 패키지다. 두 발표는 에이전트를 오래 실행하다 끊겼을 때 하던 일을 이어가는 방법을 다룬다.

사람이 이어주던 일을 런타임이 이어받는다

Earendil이 출발점으로 삼은 것은 사람이 터미널에서 쓰는 Pi 코딩 에이전트였다. 프로세스가 죽으면 사람이 상황을 보고 계속하라고 지시할 수 있다. 여러 화면과 사용자가 접근하는 장기 실행 애플리케이션에는 그 역할을 맡을 기반이 필요하다. Pi Durable은 이를 위해 대화 저장, 모델 호출, 도구 실행을 관리하는 하네스를 제공한다. 기존 코딩 에이전트를 대체하기보다 이런 애플리케이션을 만들기 위한 프레임워크라는 것이 개발진의 설명이다.

저장 대상은 채팅 기록보다 넓다. Pi Durable의 작업 모델에서 모델 호출과 도구 호출은 각각 상태를 가진 작업이다. 작업은 다음 단계로 넘어가기 전에 체크포인트를 남긴다. 다시 시작한 프로세스는 같은 저장소를 열고 미완료 작업을 찾아 마지막 저장 단계에서 진행한다. 이미 받은 질문과 대답을 다시 읽는 데서 그치지 않고, 어떤 일이 아직 끝나지 않았는지도 복원하는 셈이다.

기록이 남아 있어도, 코드는 누군가 깨워야 한다

Cloudflare 문서는 PiHarness의 연결 지점을 저장과 깨우기 두 가지로 나눈다. 대화 기록·입력 대기열·작업은 Durable Object의 SQLite에 둔다. 반면 다음 작업을 실행하는 Pi의 스케줄러는 메모리에 있다. 실행 인스턴스가 메모리에서 내려가면 스케줄러도 사라진다. 저장소가 남아 있다는 사실만으로 코드가 다시 돌지는 않는다.

그래서 PiHarness는 진행 중인 세션에 Lifecycle 작업을 등록한다. 알람이 새 실행 기회를 만들면 Pi가 저장소를 다시 열어 일을 잇는다.

Lifecycle의 작업 큐 설명에는 한 단계가 더 있다. 실행할 함수와 시각을 큐에 보관하고, 작업을 돌리기 전에 재기동을 위한 알람부터 설정한다. 실행 도중 인스턴스가 죽어도 다음 알람이 남도록 한 순서다. 저장된 작업이 어디서 이어갈지를 알려준다면, 이 알람 경로는 다시 실행될 계기를 남긴다.

다시 이어간다는 말에는 재호출도 들어 있다

복구는 멈춘 JavaScript 호출 스택을 그대로 되살리는 방식이 아니다. Earendil의 장애 복구 설명에 따르면 끊긴 모델 요청은 다시 보낸다. 저장된 부분 답변은 중단된 것으로 표시해 대화에 남긴다. 마지막 토큰 다음부터 같은 응답이 이어진다고 생각하면 실제 동작을 잘못 예상하게 된다.

도구에는 별도의 갈림길이 있다. 재실행 정책 문서에서 replay: "safe"는 중단된 호출을 다시 실행해도 안전하다는 개발자의 선언이다. 조회나 검색처럼 두 번 실행해도 문제가 없는 도구에 쓸 수 있다. 기본값인 unsafe는 복구 시 자동 재실행을 하지 않고 모델에 중단 결과를 돌려준다. 그러면 모델이 다음 행동을 정한다.

여기서 중단 결과는 “외부 티켓이 만들어지지 않았다”는 확인서가 아니다. 이 예에서는 이미 만들어졌다. 또 자동 재실행을 건너뛴다고 모델이 나중에 새 생성 요청을 하지 못하는 것도 아니다. 따라서 생성 도구를 unsafe로 두는 것만으로 이 문제의 처리가 끝나지는 않는다.

입력의 중복과 외부 변경의 중복은 따로 막는다

클라이언트가 응답을 받지 못해 같은 질문을 다시 보내는 경우도 생각해보자. PiHarness의 입력 접수 API는 같은 세션에서 같은 operationId로 재요청하면 기존 작업을 돌려준다.

Pi Durable 자체의 대응 API에서는 requestId라는 이름을 쓴다. 같은 대화에서 입력을 두 번 접수하지 않게 하는 기능이다. 이 ID가 외부 티켓 서비스에 자동으로 전달되어 중복 생성을 막는다는 뜻은 아니다.

Pi Durable 명세의 ‘의도·실행·결과’ 예제는 먼저 키를 저장하고, 그 키로 중복 실행을 막는 외부 API를 호출한 뒤 결과를 저장한다. 복구해도 같은 키를 쓴다. 매번 새 키를 만들면 외부에서는 새 작업으로 받아들일 수 있다.

티켓 서비스에도 키의 범위와 유효기간 안에서 중복 방지를 지원하는 기능이 있어야 한다. 지원하지 않는다면 이미 생성됐는지 조회해 결과를 맞추는 절차가 필요하다. 에이전트 쪽 완료 기록이 없다는 이유만으로 새 티켓부터 만들 수는 없다.

처음 맡길 일의 성격이 보인다

이 복구 방식을 처음 적용한다면 검색·조회·분석 중심의 장기 실행 보조가 자연스럽다. 작업을 안전하게 반복할 수 있고 외부 변경을 확인하는 부담도 작기 때문이다. 티켓 생성이나 발송까지 맡기려면 도구별 재실행의 의미와 결과 확인 절차를 함께 설계해야 한다. 이는 문서를 바탕으로 한 적용 판단이다.

현재 PiHarness는 베타이고 API도 바뀔 수 있다. 이 글은 공개 문서와 명세를 읽어 설명한 것으로, 직접 장애를 주입하거나 운영 환경의 복구를 검증한 결과는 아니다.

이번 연결에서 Pi는 이어갈 작업을 기록하고, Cloudflare는 다시 실행될 통로를 붙인다. 저장과 재기동을 함께 다룬다는 점이 오래 실행되는 에이전트를 만들 개발자에게 유용하다.

이 사례의 복구는 이미 만들어진 티켓을 찾아 작업 결과와 연결하는 데서 마무리된다.

기준 시각: 한국시간 2026년 10월 5일 오전 7:56:23 (KST). 발표일은 각 원문의 날짜 표기이며, 공개 시각·시간대가 없어 한국시간의 발표 시각으로 환산하지 않았다.