Pi Durable PROACTIVE Agents: Jev Triggers My ON-CALL Pi Agent

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Pi Durable 데모는 Jev가 로그 이상을 감지해 온콜 에이전트를 호출하고, 에이전트가 조사와 수정안을 준비한 뒤 사람의 배포 승인을 기다리는 선제적 장애 대응을 보여준다.

📌 핵심 요점

1. 이벤트가 작업을 시작한다. Jev는 이벤트 스트림에서 이상을 분류하고 오류·위치·페이로드를 에이전트에 전달한다. 에이전트는 로그와 이전 이벤트를 조사해 원인을 찾고 수정안을 준비한다.
2. 지속성은 대화뿐 아니라 작업과 상태까지 포함한다. Pi Durable은 클라이언트 변경이나 장애에도 실행 상태를 유지하며, 체크포인트에서 장기 작업을 이어가는 기반으로 소개된다.
3. 사람은 승인과 필요한 검토에 개입한다. 체크아웃의 잘못된 null 처리를 수정한 뒤 배포 승인을 기다린다. 승인자는 추가 조사를 요청할 수 있고, 배포 호출은 한 번만 실제 실행되는 작업으로 제시된다.
4. 공유 상태와 단계별 작업 재개가 장기 업무를 연결한다. 동일 장치의 여러 세션은 하나의 애플리케이션 상태를 공유한다. Durable Tasks는 단계별 재실행을 지원하지만, 앞선 온콜 데모가 실제로 이를 사용해 설계된 것은 아니다.
5. 실행 하네스를 운영 중에도 통제한다. 브라우저와 터미널 등 여러 클라이언트가 같은 에이전트에 연결되고, 실행 중 도구·권한·확장 기능 변경이 반영된다. 컨텍스트 분기와 백그라운드 압축도 실행 기반에 포함된다.

🧩 배경과 문제 정의

• Pi Durable은 장애나 클라이언트 변경에도 진행 중인 작업, 대화, 애플리케이션 상태를 유지하는 에이전트 실행 기반이다. 핵심 문제는 대화 재개를 넘어 작업과 상태를 지속시키는 것이다.
• 사람이 터미널에서 계속 지시하는 방식에서 벗어나, 에이전트가 사건을 감지하고 먼저 작업한 뒤 필요한 승인만 기다리는 운영 방식이 주요 관심사다.
• 여러 장치와 클라우드 샌드박스에서 실행되는 에이전트를 활용하려면 공유 상태, 재개 가능한 작업, 복수 클라이언트 연결, 실행 중 설정 변경이 필요하다.
• 장애 대응 사례는 모의 제품과 모의 이벤트 스트림을 사용한다. Pi Durable은 현재 실험 단계이며, 주도적 에이전트가 엔지니어링의 미래라는 주장은 발표자의 전망이다.

🕒 시간순 섹션별 상세정리

1. 작업·대화·상태를 지속시키는 Durable 에이전트

• Pi Durable은 진행 중인 작업과 대화, 애플리케이션 상태를 장애와 클라이언트 변경에도 유지한다. 여러 Mac 장치와 exe.dev 클라우드 샌드박스에서 지속 실행되는 에이전트가 활용 사례다. [00:15]
• 모델의 지능을 외부에서 빌리더라도 에이전트와 실행 하네스, 지속 실행 기반은 직접 통제해야 한다는 관점이 기술 선택의 출발점이다. [01:17]

2. 이벤트 감지가 사람의 지시 없이 장애 대응을 시작한다

• Jev 분류 모델이 이벤트 스트림에서 이상을 감지하면 문제의 페이로드, 위치, 오류를 에이전트에 전달한다. 에이전트는 탐지, 조사, 원인 분석, 수정, 검토 대기 순서로 장애 대응을 진행한다. [02:30]
• 주도적 에이전트는 사용자의 작업 시작을 기다리지 않고 먼저 일한 뒤 사람을 기다린다. 로그 읽기, 이전 이벤트 조회, 사고 상태 갱신 등의 도구 호출을 거쳐 수정안을 준비한다. [03:05]

3. 체크아웃 오류 수정과 승인된 배포의 재실행 방지

• 체크아웃의 로열티 할인 처리 오류는 전체 트래픽에 영향을 주는 심각한 사고로 드러난다. 원인은 잘못된 null 처리이며, 안전한 조건문이나 null 병합 처리가 대안이다. [03:57]
• 수정 내용을 확인한 뒤 배포를 승인한다. 이 배포 호출은 Pi Durable에서 한 번만 실제 실행되는 재실행 불가 작업으로 제시되며, 승인 후 데모의 오류 상태가 해소된다. [04:31]

4. 장치별 에이전트 관리와 백그라운드 컨텍스트 압축

• 네트워크 인터페이스에서 클라우드 샌드박스와 여러 Mac 장치의 에이전트를 함께 관리한다. 세션, 상태, 작업, 도구, 확장 기능이 각각의 관리 영역으로 구성된다. [06:03]
• 컨텍스트가 설정한 임계점을 넘으면 세션을 분기해 백그라운드에서 압축한다. 별도의 예약 한계에 도달하면 에이전트 실행이 멈추며, 관련 기준값을 조정할 수 있다. [06:53]

5. 여러 세션이 공유하는 지속적 애플리케이션 상태

• 에이전트는 상태 읽기와 갱신 도구로 지속적인 애플리케이션 상태 객체를 관리한다. 장애 대응 정보를 상태에 기록하면 JSON 내용을 인터페이스에서도 확인할 수 있다. [08:01]
• 다른 에이전트 세션에서도 같은 상태의 키와 값을 읽을 수 있다. 데모에서는 동일 장치의 에이전트 세션들이 하나의 JSON 객체를 공유하므로, 여러 에이전트가 공통 정보를 바탕으로 문제를 해결할 수 있다. [08:41]

6. 반복 작업을 단계별로 실행하고 재개하는 Durable Tasks

• Durable 작업은 일반 코드만으로도, 코드와 에이전트를 결합해서도 구성할 수 있다. 작업 공간 스냅샷 사례는 폴더, 브랜치, 변경 사항 등의 정보를 애플리케이션 상태에 저장한다. [09:48]
• 작업은 여러 단계로 나뉘며 특정 단계에서 문제가 생기면 해당 단계를 다시 실행할 수 있다. 오랜 시간 동안 여러 절차를 거치는 엔지니어링 업무를 반복 가능한 작업으로 구성하는 기반이다. [10:24]

7. 필요한 순간에만 개입하는 승인과 작업 감시

• 릴리스 점검 작업은 하위 에이전트를 실행하고 사람의 승인을 기다린다. 사람이 터미널에 계속 머무르기보다 진행 상황을 지켜보다가 필요한 순간에 개입하는 방식이 ‘human near the loop’다. [10:44]
• 승인 후 에이전트가 테스트와 상태 갱신을 이어간다. 작업에 하위 에이전트를 포함할 수 있으며, 문제가 생기면 필요한 지점에서 계속 진행할 수 있다. [11:15]

8. 실행 기반의 통제권과 모의 이벤트 분류 비용

• 에이전트 실행 기술을 외부 회사에 의존하면 기술 변경과 운영 통제권을 그 회사에 맡기게 된다는 것이 발표자의 우려다. 직접 통제할 수 있는 Pi와 Durable 실행 기반을 선호하는 이유도 여기에 있다. [12:45]
• 장애 대응은 탐지부터 수정까지의 단계를 가진 작업으로 생각할 수 있다. 다만 앞선 주도적 에이전트 데모가 실제로 Durable Tasks를 사용해 설계된 것은 아니다. [13:33]

9. 에이전트 실행과 클라이언트를 분리하는 구조

• 에이전트는 별도 환경에서 실행되고 여러 클라이언트가 연결된다. 사람이 자신의 장치에서 계속 프롬프트를 입력하는 방식에서 벗어나려면, 사람 없이 작동하는 시스템을 구축해야 한다는 전망이다. [14:46]
• 클라우드 샌드박스의 에이전트 ID로 터미널 인터페이스에 연결하면 브라우저와 동일한 세션을 볼 수 있다. 고객 지원 에이전트도 웹사이트에서 사용자와 대화하면서 별도의 관리 클라이언트로 점검할 수 있다. [15:45]

10. 실행 중 도구와 권한을 바꾸는 작업 기반 하네스

• 모델 호출부터 도구 실행까지 하네스의 각 실행은 작업으로 취급된다. 에이전트에는 하위 에이전트, 컨텍스트 검색, Durable 작업 조회, 애플리케이션 상태 관리 등의 도구를 제공할 수 있다. [17:53]
• 터미널에서 읽기 전용 모드로 전환하면 브라우저에서도 사용 가능한 도구 목록이 바뀐다. 세션 도중 도구가 제거되자 에이전트는 이전 목록이 현재 권한과 맞지 않음을 인정하고 새 목록을 제시한다. [18:25]

11. 확장 기능으로 응답 방식과 명령 실행을 제어한다

• Pi의 확장 기능은 Pi Durable에서도 사용할 수 있다. 시스템 프롬프트를 조정하는 확장과 bash 명령을 Jev로 판단하는 damage control 확장을 실행 중 켤 수 있다. [20:26]
• 시스템 프롬프트에 정의한 별칭으로 응답을 짧게 만들 수 있다. 안전 제어를 켠 상태에서는 디렉터리 삭제 명령이 되돌릴 수 없는 작업으로 판단되어 차단된다. [21:36]

12. 컨텍스트 분기와 격리 환경을 결합한 하네스 설계

• fork는 현재 컨텍스트를 분기해 서로 다른 방향의 작업과 실험을 이어가게 한다. 상태를 포함해 분기하거나 새 대화로 시작할 수 있으며, 원하는 시점에서 분기를 만들 수 있다. [22:28]
• 에이전트 전용 장치와 격리된 실행 환경에 필요한 도구를 제공하고, 그 위에 확장 기능과 반복·재개 가능한 작업을 구성한다. 이는 개별 에이전트 하네스를 장치와 도구 체계까지 확장하는 설계다. [23:15]

13. 제품의 가치 판단과 실험 단계의 운영 한계

• 코드 생성이 쉬워져도 무엇을 만들고 어떤 기능에 집중할지 결정하는 판단과 전문성이 제품의 가치를 좌우한다는 관점이다. 핵심 기능만 남기는 선택이 단순한 구현이나 복제보다 어렵다고 평가한다. [24:14]
• Pi Durable은 현재 실험 단계다. 발표자는 직접 분기해 유지보수할 생각이 없어 자신의 운영 환경에 도입하지 않고, 안정적인 V1 공식 출시를 기다리고 있다. [25:25]

14. 주도적 실행과 Zero Touch Engineering에 대한 전망

• 발표자는 주도적 에이전트가 엔지니어링의 미래라고 전망한다. 사람이 도착하기 전에 작업을 끝내고, Zero Touch Engineering에 가까워질수록 사람은 수행 과정 검토와 간헐적인 문제 수정에 집중한다는 구상이다. [25:46]
• Jev가 로그를 분류해 사고 대응 에이전트를 호출하는 데모의 누적 비용은 이 시점에 13센트다. 에이전트는 온콜 엔지니어가 수행하던 절차를 실행하며, 발표자는 실제 운영 로그에도 이런 구조를 적용하자고 제안한다. [26:39]

15. 하네스 통제, 계획·검토 자동화와 멀티클라이언트 활용

• 에이전트에 대한 통제권은 직접 관리할 수 있는 하네스에서 나온다는 관점이다. 주도적 실행을 활용하면 사람이 개입할 때 작업이 거의 끝나 있고, 사람은 필요한 지점에서만 관여할 수 있다. [27:40]
• 발표자는 앞선 데모에서 자신의 검토가 사실상 중복된 안전 확인이었다고 평가한다. 에이전트 코딩의 두 제약을 계획과 검토로 보고, 프롬프트·컨텍스트·하네스 설계로 둘 다 해결 가능하다고 주장한다. [28:13]

16. 여러 인터페이스와 중단 복구를 지원하는 durable 에이전트

• 단일 에이전트 API를 브라우저·사용자 정의 CLI·curl·모바일·제품에서 활용할 수 있다. curl 접근에는 올바른 인증과 토큰 설정이 필요하며, 인터페이스 없이 백그라운드에서 일하는 엔지니어링 에이전트도 구성할 수 있다. 동료들이 같은 장애 대응 에이전트에 접속해 로그를 함께 검토하고 프롬프트를 입력하는 협업도 가능하다. [30:16]
• 협업 기능보다 더 중요하게 보는 가치는 장시간 실행과 복구다. durable 샌드박스의 에이전트는 노트북을 닫거나 프로세스를 종료하고 머신을 재시작해도 마지막 체크포인트부터 작업을 이어간다. 실제로 에이전트와 워크플로를 중단시켜 복구 동작을 검증해야 한다. [30:55]

17. 제품의 기본 구성과 선제적 작업으로 확장하는 도입 전략

• 제품 개발에는 durable 에이전트를 기본으로 사용한다는 방침이다. 웹사이트의 고객 지원 챗봇은 사용자가 기존 세션으로 돌아올 수 있어야 하며, 세션을 6시간 뒤 초기화하는 등 유지 정책을 설정할 수 있다. [31:54]
• 선제적 에이전트는 사용자의 지시를 기다리기보다 먼저 작업하고 승인을 요청한다. 사용자가 도착하기 전에 일을 시작하도록 만드는 데 집중하며, 사람 없이 처리하는 일이 많아질수록 단순한 에이전트 코딩에서 에이전트 엔지니어링으로 나아간다는 관점이다. 지속적인 감독에서 벗어나는 ‘out of the loop’를 다음 도약으로 본다. [32:46]

18. 로그 분류 사례와 자율적으로 일하는 에이전트의 성과 기준

• 로그 스트림의 모든 유입 이벤트를 Jev가 분류하는 사례에서 화면에 표시된 규모와 비용은 6,000행과 16센트다. 이 구성은 개선 가능한 템플릿이며, 상태값을 문자열로 검사해 일부 처리를 건너뛰거나 Jev를 거치지 않고 4xx·5xx 오류만 살펴보는 방식도 가능하다. [33:43]
• 권장 성과 지표는 ‘어느 시점에 유용한 일을 수행 중인 에이전트가 몇 개인가’다. 사용자가 직접 대규모 작업을 시작하는 수준을 넘어, 업무에 내장된 에이전트가 스스로 작업을 시작하도록 해야 한다. durable 에이전트는 사람이 개입하거나, 개입하지 않거나, 승인 중심으로 관여하는 각 방식에서 일을 처리할 에이전트 수를 늘리는 기반이다. [34:37]

🧾 결론

• 데모의 핵심은 사람이 요청하기 전에 에이전트가 대응을 시작하고, 사람이 도착했을 때 검토할 수정안을 준비해 두는 운영 방식이다.
• ‘human near the loop’에서는 에이전트가 작업을 진행하고 사람이 워크플로·배포 승인과 필요한 검토를 맡아 출시 통제권을 유지한다.
• Pi Durable은 실험 단계다. 발표자도 자신의 운영 환경에는 도입하지 않고 안정적인 V1 공식 출시를 기다리고 있어, 데모 성과와 운영 준비 수준을 구분해야 한다.

📈 투자·시사 포인트

• 발표자는 에이전트와 하네스 설계에 대한 투자를 강조한다. 실행 복구, 상태 유지, 승인 절차가 사람이 직접 해야 하는 일을 줄이는 기반이라는 관점이다.
• 직접 관리하고 확장할 수 있는 실행 기반을 선호하는 이유는 기술 변경과 운영 통제권을 외부 회사에 맡기는 의존성을 줄이기 위해서다.
• Jev 로그 분류 데모에는 6,000행·16센트가 표시되지만, 모의 스트림의 분류 비용만으로 실제 장애 대응 전체의 경제성을 판단할 수는 없다.
• 권장 성과 지표는 특정 시점에 유용한 일을 수행 중인 에이전트 수다. 도입 평가에서도 선제적 실행이 실제 업무 처리로 이어지는지 확인중요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• Pi Durable은 실험 단계이며, 실제 운영 환경의 안정성과 복구 성능은 이 자료만으로 확인되지 않는다. 발표자는 에이전트와 워크플로를 직접 중단시켜 복구를 검증해야 한다고 강조한다.
• 장애 대응과 비용 수치는 모의 제품·모의 이벤트 스트림에서 나온다. 실제 로그의 탐지 정확도, 오탐·누락, 조사·수정까지 포함한 전체 비용은 제시되지 않는다.
• 배포가 한 번만 실제 실행된다는 설명은 데모에서 제시된 동작이다. 실제 배포 시스템과 연결했을 때의 실패·재시도 조건은 별도 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 격리된 환경에서 모의 로그로 탐지→조사→수정안 준비→승인 흐름을 재현하고, 각 단계의 상태가 남는지 확인한다.
• 에이전트와 워크플로를 중단하고 머신을 재시작해 마지막 체크포인트에서 이어지는지 검증한다.
• 배포 승인 거절과 추가 조사 요청을 시험하고, 승인된 배포가 복구·재시도 과정에서 중복 실행되는지 확인한다.
• 동일 장치의 세션 간 상태 공유와 별도 클라우드 샌드박스의 상태 분리를 확인하고, 실행 중 읽기 전용 전환과 안전 제어 변경을 점검한다.

❓ 열린 질문

• 실제 운영 로그에서도 Jev의 이상 분류가 온콜 대응에 충분한 정확도와 비용 수준을 유지할 수 있는가?
• 여러 에이전트가 공통 상태를 동시에 갱신할 때 충돌과 일관성은 어떻게 관리되는가?
• 안정적인 V1은 어떤 복구·재시도·권한 제어 보장을 제공하며, 운영 도입 기준은 무엇인가?