Jev가 온콜 Pi 에이전트를 깨우는 지속형 선제 에이전트

• 원문 제목: Pi Durable PROACTIVE Agents: Jev Triggers My ON-CALL Pi Agent
• URL: https://www.youtube.com/watch?v=DNDYYHsypZg
• 날짜: 2026-10-13
• 채널: IndyDevDan
• 영상 원본 발행일: 2026-10-12
• Video ID: DNDYYHsypZg
• 자막: YouTube 자동 생성 영어 자막 기반 전사·번역
• 핵심 기술: Pi Durable, proactive agent, durable agent, Jev, agent harness, human near the loop

---

📌 핵심 질문 / 지속형 에이전트가 바꾸는 엔지니어링의 경계

==가장 가치 있는 에이전트는 사용자의 작업 지시를 기다리지 않고 실제 이벤트를 감지해 일을 시작한 뒤, 사람이 검토하거나 승인해야 하는 지점에서 멈추는 지속형 선제 에이전트다.==

• Pi Durable은 진행 중 작업·대화·애플리케이션 상태를 장애, 클라이언트 교체, 시스템 변화 이후에도 보존한다.
• Jev 분류기가 실시간 로그 이벤트에서 운영 장애를 찾아 온콜 Pi 에이전트를 깨우고, 에이전트가 조사·원인 분석·수정을 마친 뒤 배포 승인만 요청한다.
• 공유 상태, 재개 가능한 단계형 작업, 분리된 실행 환경, 다중 클라이언트, 런타임 도구 교체가 에이전트를 단순한 터미널 세션에서 운영 시스템으로 확장한다.

사용자가 터미널에서 에이전트를 계속 붙잡고 있어야 하는 단계는 에이전트 코딩(agentic coding)에 가깝다. 이벤트와 업무 흐름 속에 에이전트를 심고, 사용자가 나타났을 때 결과를 검토하는 단계는 에이전트 엔지니어링(agentic engineering)에 가깝다. Pi Durable은 인 루프(in the loop), 휴먼 니어 더 루프(human near the loop), 아웃 오브 더 루프(out of the loop) 사이의 이동을 가능하게 하는 실행 기반을 제공한다.

1. 장애를 감지해 먼저 일하는 온콜 에이전트

Pi Durable은 단순한 세션 재개가 아니라, 실패와 연결 단절을 견디면서 장기 작업을 이어가는 Pi coding agent의 실행 기반이다.

1.1. 지속형 에이전트의 의미

1. 작업의 연속성

   1. 장애 내구성: 진행 중인 작업과 대화가 실패 이후에도 유지된다.
   2. 클라이언트 내구성: 브라우저, TUI, curl, 휴대전화, 제품 UI처럼 접속 클라이언트가 바뀌어도 같은 에이전트에 연결할 수 있다.
   3. 애플리케이션 상태의 내구성: 세션 대화만 보존하는 것이 아니라 여러 에이전트가 읽고 갱신하는 애플리케이션 상태까지 보존한다.

2. 에이전트의 역할 변화

   1. 기존 방식: 엔지니어가 프롬프트를 입력하고 에이전트의 다음 작업을 계속 지시한다.
   2. 선제 방식: 외부 이벤트가 에이전트를 깨우고, 에이전트가 표준 절차를 수행한 다음 사람의 판단이 필요한 지점에서 기다린다.
   3. 핵심 정의: “사용자가 일하기를 기다리지 않고, 사용자를 위해 일한 뒤 기다리는 에이전트”가 proactive agent다.

1.2. Jev가 시작한 생산 장애 대응

1. 실시간 이벤트에서 에이전트까지 이어지는 경로

   1. 이벤트 스트림: 시연용 마켓 애플리케이션에 실시간 이벤트가 계속 유입된다.
   2. Jev 분류: Jev classifier가 각 이벤트를 분류해 사고(incident)를 감지한다.
   3. 트리거 payload: 감지된 이슈의 위치, 오류 내용, 이슈 payload가 Pi Durable 에이전트로 전달된다.
   4. 온콜 워크플로: 에이전트는 사람이 온콜 엔지니어라면 수행할 탐지, 조사, 근본 원인 분석, 수정, 리뷰 요청, 배포 순서를 실행한다.

2. 에이전트가 수행한 실제 도구 호출

   1. 사고 기록 갱신: 현재 incident를 업데이트한다.
   2. 로그 읽기: 장애가 발생한 실행 흐름과 로그를 확인한다.
   3. 과거 이벤트 조회: 이전에 발생한 관련 이벤트를 질의해 맥락을 보강한다.
   4. 수정과 리뷰 대기: 원인을 찾아 코드를 수정하고, 배포 가능한 상태를 만든 뒤 사용자 리뷰를 기다린다.

3. 체크아웃 API 장애 사례

   1. 영향 범위: “checkout에서 loyalty discount 적용”을 담당하는 API가 전체 트래픽의 100%를 처리하는 경로에서 장애를 일으켰다.
   2. 근본 원인: 고객 충성도(loyalty) 값에 대한 고전적인 null 체크 오류가 있었다. 존재하지 않을 수 있는 값을 강제 단언(bang)으로 다룬 코드가 문제를 일으켰다.
   3. 수정 원칙: 강제 단언을 피하고 null coalescing 또는 안전한 if 문으로 값을 직접 검증하는 방식이 제시됐다.
   4. 사람의 판단: 에이전트가 문제를 해결했지만 사용자는 변경 내용을 더 확인하기 위해 첫 번째 배포 제안을 거절했다. 요약과 코드 diff를 검토한 뒤 실제 장애 원인을 이해하고 다시 승인했다.

4. 배포 승인과 상태 보존

   1. 단 한 번만 실행되는 작업: Pi Durable은 배포 같은 비재생(non-replayable) 도구 호출을 완전한 운영 배포에 한 번만 실행하도록 기록한다.
   2. 휴먼 니어 더 루프: 사용자는 터미널에서 전체 작업을 지켜보는 대신 수정 내용과 배포를 검토하고 승인한다.
   3. 상태 유지: 브라우저를 새로고침해도 에이전트가 진행한 조사·수정·승인 대기 상태가 그대로 남는다.
   4. 결과: 배포 승인 후 생산 환경의 오류가 안정화되고, 장애 대응이 지속형 Pi 에이전트에 의해 완료된다.

1.3. Jev 기반 운영 자동화의 비용과 속도

1. 저비용 분류

   1. 대량 이벤트 처리: Jev는 들어오는 모든 이벤트를 분류하면서 수백 건의 이벤트를 처리했다.
   2. 시연 중 비용: 한 시점에는 약 1.5센트, 다른 시점에는 약 6센트가 누적됐고, 거의 한 시간 동안 로그를 분류한 총액은 13센트로 제시됐다.
   3. 대규모 예시: 마지막 화면에는 6,000개 행을 처리한 비용이 16센트로 표시됐다.
   4. 조건: 애플리케이션과 이벤트 스트림은 실제 운영 서비스가 아닌 시연용 mock product지만, 저비용·고속·신뢰성의 조합을 보여주도록 설계됐다.

2. 분류기의 실용성

   1. 속도: Jev의 평균 판단 시간이 매우 짧아 로그 스트림에 직접 배치할 수 있다.
   2. 대체 비용: 단순히 “분류기라서 쉽게 대체할 수 있다”고 보기보다, 같은 지출·속도·신뢰성을 동시에 재현해야 한다.
   3. 확장 경로: 모든 이벤트를 모델에 보내는 대신 상태 문자열을 검사하거나 4xx·5xx 오류만 통과시키는 단순 필터를 앞에 둘 수도 있다.

2. 여러 장치에 걸친 Pi Durable 네트워크

지속형 에이전트는 한 대의 터미널 프로세스가 아니라 장치·워크스페이스·에이전트가 연결된 네트워크로 운영된다.

2.1. 에이전트 네트워크와 전용 실행 장치

1. 실행 환경

   1. 장치 구성: exe.dev 클라우드 샌드박스, M6 Mac Mini, M4 Mac Mini, M5 MacBook Pro에서 에이전트가 실행된다.
   2. 전용 컴퓨트: M6 장치는 사람이 직접 들어가는 컴퓨터가 아니라 에이전트 전용으로 두고, 에이전트가 처음부터 끝까지 소유하도록 구성했다.
   3. 샌드박스 원칙: 에이전트가 높은 자율성으로 작업하려면 엔지니어가 사용하는 도구와 비슷한 도구, 궁극적으로는 컴퓨터 전체가 필요하다.
   4. 격리: 각 장치와 샌드박스는 서로 다른 코드베이스와 문제를 안전하게 분리해 실행한다.

2. 네트워크 플레이그라운드

   1. 세션 목록: 좌측 사이드바에서 모든 장치의 에이전트와 세션을 확인한다.
   2. 기본 탭: Session, State, Tasks, Tools, Extend 탭이 세션·상태·작업·도구·확장을 각각 보여준다.
   3. 계층: 장치(device), 워크스페이스(workspace), 에이전트(agent)의 3단계 구조로 실행 대상을 구분한다.
   4. 접속 방식: 사용자는 에이전트가 실제로 실행되는 장치와 분리된 클라이언트에서 동일한 세션에 접속한다.

2.2. 백그라운드 자동 압축과 장기 실행

1. 백그라운드 compaction

   1. 압축 기준점: 세션 화면에서 compaction mark를 움직여 컨텍스트 압축을 시작할 경계를 지정한다.
   2. 분기 실행: 에이전트가 기준점을 넘으면 현재 세션을 fork해 압축 작업을 백그라운드에서 시작한다.
   3. 예약 여유 보호: 예약된 reserve 영역에 도달하면 에이전트의 실행을 멈춰 컨텍스트를 보호한다.
   4. 의미: 장기 실행 중에도 사용자가 터미널을 직접 붙잡지 않아도 여러 백그라운드 작업을 감당할 수 있다.

2. 내구성이 필요한 이유

   1. 지속 업무: 제품이나 도구 주변에서 여러 일이 동시에 돌아갈 수 있으므로 한 번의 대화창에 모든 작업을 묶을 수 없다.
   2. 복구: 연결이 끊기거나 프로세스가 중단돼도 마지막 체크포인트에서 작업을 이어간다.
   3. 운영 모델: 에이전트가 실행되고 사용자는 결과를 확인하는 비동기 운영이 가능해진다.

2.3. 공유 애플리케이션 상태

1. 하나의 지속형 JSON 객체

   1. 도구: 에이전트에는 state를 읽는 도구와 state를 갱신하는 도구가 있다.
   2. 공유 범위: 같은 장치의 모든 에이전트 세션이 하나의 공유 JSON 객체를 읽고 수정한다.
   3. 예시: 한 세션이 핵심 정보를 애플리케이션 상태에 기록하면, 같은 M6 장치의 다른 세션이 key-value 목록을 읽어 정확히 같은 상태를 출력한다.
   4. UI 렌더링: JSON 상태는 화면에서 전체 UI로 렌더링되며, 사람이 읽는 디버깅 화면과 에이전트 간 통신 매개체 역할을 함께 한다.

2. 공유 상태가 만드는 협업

   1. 세션 간 디버깅: 한 에이전트가 발견한 문제를 다른 에이전트가 이어서 확인할 수 있다.
   2. 역할 분리: 서로 다른 에이전트가 하나의 제품이나 업무를 나눠 처리하면서 공통 상태를 갱신한다.
   3. 제품 응용: 에이전트가 상태를 업데이트하고 별도 클라이언트가 그 상태를 UI로 표시하는 제품 구조를 만들 수 있다.
   4. 중요한 차이: 에이전트의 대화가 살아 있는 것만으로는 충분하지 않고, 애플리케이션 상태가 지속돼야 제품이 변화와 다운타임을 견딜 수 있다.

3. 단계형 Durable Task와 휴먼 니어 더 루프

장기간 이어지는 엔지니어링 업무는 한 번의 모델 호출이 아니라 재개 가능한 단계들의 묶음으로 모델링된다.

3.1. 반복 가능한 작업과 페이즈

1. Durable job의 구조

   1. 반복 작업: 작업은 반복 실행할 수 있는 job이며, 순수 코드만으로 구성하거나 코드와 에이전트를 함께 포함할 수 있다.
   2. 워크스페이스 스냅샷: 예시 job은 폴더와 브랜치 변경 내용을 조사하는 workspace snapshot을 만들고, 결과를 애플리케이션 상태에 저장한다.
   3. 페이즈 단위: 여러 단계로 구성된 job은 특정 단계에서 실패해도 전체를 처음부터 다시 하지 않고 해당 단계부터 반복할 수 있다.
   4. 장기 업무 적합성: 미래의 엔지니어링 업무가 긴 시간과 많은 단계를 거치게 될수록 단계형 durable task의 가치가 커진다.

2. 릴리스 체크와 승인

   1. 기존 human in the loop: 사람이 계속 터미널에 붙어 모든 단계의 실행을 직접 조작한다.
   2. 새 구조: sub-agent가 릴리스 체크를 수행하고 사람에게 질문해야 하는 단계에서만 멈춘다.
   3. 승인 후 재개: 사용자가 승인하면 테스트 실행, 애플리케이션 상태 업데이트, 다음 단계 진행을 에이전트가 이어간다.
   4. 통제권: 사람은 배포되는 결과를 검토하고 승인·거절하지만, 모든 중간 작업을 직접 수행하지는 않는다.

3. 반복 감시 작업

   1. change watch: 폴더의 기준 상태를 만든 뒤 변경을 반복 감시하는 task가 있다.
   2. 중단 가능성: 루프가 돌고 있는 작업을 원하는 시점에 중지할 수 있다.
   3. 상태 확인: 에이전트가 durable job 상태 목록을 읽어 현재 실행 중인 작업과 과거 작업을 확인한다.
   4. 결과 상태: completed, aborted, last phase 같은 상태로 각 job의 진행 결과와 중단 지점을 구분한다.

3.2. 휴먼 니어 더 루프의 운영 방식

1. 관찰자에서 승인자로 이동

   1. 관찰 대상: 사용자는 프로세스와 AI 개발 워크플로를 계속 감시하되, 정상적인 각 단계에 개입하지 않는다.
   2. 개입 지점: 사고 원인 분석과 수정이 끝나면 배포 승인 또는 거절을 수행한다.
   3. 검토 단위: 사람이 확인하는 대상은 명령어를 한 줄씩 입력하는 과정이 아니라 최종 결과, 변경 사항, 위험한 작업이다.
   4. 전환 난이도: 터미널에 오랫동안 묶여 있던 엔지니어가 즉시 완전한 아웃 오브 더 루프로 이동하기는 어렵기 때문에, 니어 루프가 현실적인 중간 단계가 된다.

2. 안전한 비재생 작업

   1. 중복 실행 방지: 배포처럼 되돌리기 어렵거나 재실행하면 위험한 작업은 호출 기록을 사용해 한 번만 실행한다.
   2. 사람의 승인: 에이전트가 준비한 변경 사항을 사람이 확인한 후에만 운영 배포가 발생한다.
   3. 점진적 자율성: 조사·로그 조회·테스트는 자율화하고, 배포 승인은 사람에게 남겨 자율성을 단계적으로 높인다.

4. 분리된 클라이언트와 에이전트 도구

에이전트의 실행 위치와 사용자가 접속하는 화면을 분리하면 같은 에이전트를 여러 제품·장치·인터페이스에서 활용할 수 있다.

4.1. 멀티클라이언트 에이전트

1. 실행과 인터페이스의 분리

   1. 기존 모델: 에이전트가 사용자의 현재 장치와 터미널 안에서만 실행된다.
   2. Pi Durable 모델: 에이전트는 클라우드 샌드박스나 전용 장치에서 실행되고, 클라이언트는 그 실행 상태에 접속한다.
   3. 동시 접속: 동일한 에이전트 세션을 브라우저, TUI, 명령줄, curl, 모바일 기기, 제품의 UI에서 열 수 있다.
   4. 고객 제품: 웹사이트의 지원 챗봇은 브라우저에만 묶이지 않고, 운영자가 별도 브라우저 앱이나 durable agent network 앱으로 관찰·관리할 수 있다.

2. 접속 시연

   1. 클라우드 세션: exe.dev의 클라우드 샌드박스에 실행 중인 에이전트의 ID를 확인한다.
   2. TUI 연결: 별도의 터미널 UI에서 해당 ID로 attach해 동일한 세션을 연다.
   3. 브라우저 연결: 브라우저에서 T002라는 새 세션을 만들고 Sonnet 5.5 모델을 선택하자 왼쪽 목록에 새 에이전트가 즉시 생성된다.
   4. 핵심 구조: 클라이언트가 에이전트를 소유하는 것이 아니라, 장치와 워크스페이스 안에서 실행되는 에이전트에 클라이언트가 연결된다.

3. 멀티플레이어 확장

   1. 공동 접속: 사용자 한 명뿐 아니라 동료 엔지니어도 동일한 incident 에이전트에 연결할 수 있다.
   2. 공동 검토: 여러 온콜 엔지니어가 함께 로그를 검토하고 한 에이전트에 공동으로 프롬프트를 보낼 수 있다.
   3. 우선순위: 멀티플레이어는 흥미로운 확장이지만, 더 중요한 가치는 노트북을 닫아도 계속 작동하는 장기 실행성이다.

4.2. 모든 실행을 task로 다루는 도구 모델

1. 도구 목록

   1. 전용 기능: sub-agent context 검색, durable job 확인, application state 조회가 기본 도구로 제공된다.
   2. 일반 기능: 파일 읽기와 같은 전통적인 도구도 함께 사용할 수 있다.
   3. 실행 단위: 모델 호출부터 도구 실행까지 harness가 수행하는 모든 동작은 하나의 task로 다뤄진다.
   4. 재구성 가능성: task라는 실행 단위는 진행 중에도 변경할 수 있다.

2. 런타임 읽기 전용 전환

   1. 도구 축소: 브라우저 클라이언트에서 read-only 모드로 전환하면 사용 가능한 도구 목록이 즉시 바뀐다.
   2. 자기 인식 변화: 에이전트는 이전 목록이 더 이상 자신이 가진 도구와 일치하지 않는다는 점을 새 목록을 통해 인식한다.
   3. 중간 변경: 세션을 새로 시작하지 않고도 도구를 제거하거나 교체할 수 있다.
   4. 안전 의미: 운영 상황에 따라 쓰기·배포 도구를 떼고 조회만 허용하는 식으로 권한을 낮출 수 있다.

4.3. 확장, handoff, fork

1. 컨텍스트 이동

   1. handoff: handoff 명령은 현재 맥락을 넘기면서 새 모델 컨텍스트를 시작한다.
   2. 자기 압축과의 연계: 세션을 무한히 늘이지 않고 새 컨텍스트로 작업을 이어가는 방법이다.
   3. 백그라운드 compaction: 대화가 길어져도 자동 압축이 백그라운드에서 진행돼 장기 작업을 뒷받침한다.

2. 에이전트 fork

   1. 분기: 현재 에이전트의 컨텍스트를 완전히 fork해 별도 에이전트를 만든다.
   2. 탐색: 한 방향의 구현을 유지하면서 다른 방향의 질문·실험·작업을 동시에 진행할 수 있다.
   3. 상태 선택: 상태를 포함한 fork, 새 대화로 시작하는 fork, 특정 시점에서 분기하는 fork를 선택할 수 있다.
   4. 실용성: 쌓아온 컨텍스트가 특정 의사결정 지점에 도달했을 때 여러 가설을 병렬로 검증할 수 있다.

5. 런타임 하네스 엔지니어링

Pi Durable의 핵심 가치는 기본 에이전트 하나를 오래 유지하는 데 그치지 않고, 장치·작업·상태·도구·확장을 조합해 실행 하네스(harness)를 직접 설계하는 데 있다.

5.1. 런타임 확장과 안전 제어

1. Pi 확장 기능

   1. Fix Smartass Opus: 장황하고 계속 말만 하는 Opus 계열 에이전트를 시스템 프롬프트 엔지니어링으로 교정하는 확장이다.
   2. Jev Damage Control: Jev의 저비용·고신뢰 분류기를 에이전트의 명령 안전 심사에 연결하는 확장이다.
   3. 즉시 전환: 두 확장은 버튼을 눌러 런타임에 켜고 끌 수 있다.
   4. 확장 가능한 기반: Pi coding agent용 확장이 durable Pi에도 그대로 확장된다.

2. Jev Damage Control의 명령 차단

   1. bash 심사: 활성화하면 모든 bash tool 명령이 정당한지 Jev의 판단을 거친다.
   2. 위험 명령: ls로 디렉터리 내용을 확인한 뒤 rm -rf를 실행하려 하자 harness가 삭제를 차단했다.
   3. 차단 사유: 삭제는 되돌릴 수 없는(irreversible) 작업이며, 복구할 방법이 없다는 판단이었다.
   4. 위험 모드: 사용자가 dangerous mode로 전환하고 시스템 프롬프트와 안전 제어를 끄면 같은 삭제 명령을 실행할 수 있지만, 그 선택은 통제된 예외로 남는다.

3. 프롬프트와 alias

   1. 시스템 프롬프트 구성: tools, communication, operational boundaries, aliases 등 다섯 부분으로 구성된 시스템 프롬프트가 표시된다.
   2. 응답 압축 alias: str alias를 호출하면 에이전트 응답을 압축하도록 만든 규칙이 활성화된다.
   3. 라이브 업데이트: 확장, 도구 세트, 시스템 프롬프트를 실행 중인 durable Pi 에이전트에 즉시 반영할 수 있다.

5.2. 에이전트 네트워크를 설계하는 원칙

1. 자율성의 기반

   1. 전용 장치: 에이전트를 자신의 장치에 올려 엔드투엔드로 소유한다.
   2. 안전한 확장: 격리된 샌드박스에서 에이전트를 여러 개 실행해 작업을 병렬화한다.
   3. 도구 부여: 엔지니어가 사용하는 도구를 에이전트에게도 제공해 실제 업무 수행 능력을 확보한다.
   4. 하네스 구성: 확장, task, 공유 상태, 클라이언트, 권한 제어를 조합해 반복 가능하고 재개 가능한 시스템을 만든다.

2. 고정 세션을 넘어서는 운영

   1. 일반 터미널의 한계: 한 번 부팅한 단일 Pi·Claude Code·Codex 세션은 현재 장치와 도구 구성에 묶인다.
   2. durable 구조: 도구를 교체하고, 작업을 중지·재개하고, 상태를 공유하고, 여러 클라이언트에서 접속할 수 있다.
   3. 제품 연결: 에이전트 API를 노출하면 개인 엔지니어링 업무와 사용자용 제품 업무가 같은 실행 기반을 공유할 수 있다.

5.3. 코드보다 중요한 제품 판단

1. Pi Durable의 설계 품질

   1. 구현 규모: 기반 코드는 수천 줄의 TypeScript, 제작자 언급 기준 약 1만~1.5만 줄 규모로 소개되지만 정확한 수치는 기억에 따라 달라질 수 있다고 말했다.
   2. 가치의 원천: 코드를 생성하는 일보다 무엇을 만들고 무엇을 버릴지 결정하는 judgment, taste, decision-making이 더 어렵다.
   3. 제품의 압축: 다른 도구·모델·제품을 복제하기는 쉽지만, 전문 지식으로 핵심 가치 한두 가지까지 기능을 덜어내는 일은 어렵다.
   4. 제작자에 대한 평가: Mario, Armen, Rendell이 지속형 에이전트의 핵심 기능을 골라 제품으로 묶은 점이 소프트웨어 엔지니어링의 본질을 보여준다는 평가가 제시됐다.

2. 현재의 한계

   1. 실험 단계: Pi Durable은 당시 experimental 상태라 안정적인 V1 릴리스 전에는 바로 운영 배포에 사용하기 어렵다.
   2. 유지보수 부담: 지금 운영에 쓰려면 프로젝트를 fork하고 직접 유지해야 할 수 있다.
   3. 기대: 안정적인 공식 V1이 나오면 실제 업무와 제품에 본격적으로 적용하겠다는 방향이 제시됐다.

6. 지속형 에이전트를 채택해야 하는 이유

6.1. 선제 에이전트와 제로 터치 엔지니어링

1. 업무 시작의 자동화

   1. 기존 책임: Phase 2 방식에서는 사람이 거대한 job의 kickoff를 직접 책임졌다.
   2. Phase 3 방식: 에이전트가 이벤트와 업무 흐름에 내장돼 사람 없이 시작하고, 사용자가 나타났을 때 결과가 거의 완성돼 있다.
   3. Zero-touch engineering: 사람은 구현 과정을 상시 조작하기보다 결과가 왜 그렇게 되었는지 검토하고 예외를 수정한다.
   4. 가치 기준: 에이전트가 사용자를 기다리지 않고 유용한 일을 해놓는 시간이 늘어날수록 진정한 agentic engineering에 가까워진다.

2. 생산 로그 적용

   1. 입력: 운영 로그를 Jev 앞에 두고 모든 이벤트를 분류한다.
   2. 출력: 생산 문제를 찾으면 전용 AI 개발 워크플로를 가진 incident response 에이전트를 트리거한다.
   3. 대체 업무: 과거 온콜 엔지니어가 직접 수행하던 탐지, 조사, 원인 분석, 수정, 리뷰 준비가 자동으로 진행된다.
   4. 확장성: 문자열 상태 필터나 4xx·5xx 선별을 추가해 비용과 처리량을 더 최적화할 수 있다.

6.2. 소유권, 개방성, 통제력

1. 에이전트 기술의 소유

   1. 임대 중인 지능: 모델 지능과 비즈니스 IP를 외부 서비스에 의존하는 현실이 있다.
   2. 통제 필요성: 에이전트, 에이전트 하네스, durable agent를 모두 다른 회사에 맡기면 동작과 가격이 언제든 바뀔 위험이 있다.
   3. 통제 가능한 기반: 오픈소스이고 확장 가능하며 직접 통제할 수 있는 Pi coding agent가 이 위험을 낮춘다.
   4. 로컬 컴퓨트: 로컬 모델과 전용 장치를 통해 핵심 지능과 실행 환경을 직접 소유하는 방향이 강조됐다.

2. 기획과 리뷰의 제약

   1. 두 가지 병목: agentic coding의 핵심 제약은 planning과 reviewing이다.
   2. 해결 가능성: prompt engineering, context engineering, harness engineering을 조합하면 두 병목을 풀 수 있다는 주장이 제시됐다.
   3. 내장 안전장치: 시연에서 사용자가 추가한 검토는 배포 승인을 확인하는 중복 안전장치에 가까웠다.
   4. 점진적 전환: 모든 권한을 처음부터 자동화하기보다 조사·테스트·수정·승인 단계를 분리해 자율성을 늘릴 수 있다.

6.3. 멀티클라이언트·멀티플레이어·장기 실행

1. 단일 API의 확장

   1. 클라이언트 종류: 브라우저, custom CLI, curl, 모바일 장치, 사용자용 제품이 같은 agent API에 연결된다.
   2. 백그라운드 에이전트: 인터페이스가 없어도 업무 뒤에서 계속 일하는 엔지니어링 에이전트를 만들 수 있다.
   3. 제품 적용: 고객 지원 봇처럼 사용자가 기존 세션으로 돌아오는 서비스는 durable agent를 기본값으로 삼을 수 있다.
   4. 세션 정책: 제품 요구에 따라 6시간 뒤 세션을 지우는 등 상태 수명을 조절할 수 있다.

2. 장기 실행과 복구

   1. 중단 내성: 노트북을 닫고, 프로세스를 종료하고, 기계를 재시작해도 마지막 체크포인트에서 다시 일한다.
   2. 검증 권고: 실제로 에이전트를 죽이고 워크플로를 중단한 뒤 복귀하는지 직접 테스트해야 한다.
   3. 협업: 동료들이 함께 incident 에이전트에 연결해 로그와 판단을 공동 검토할 수 있다.
   4. 핵심 우선순위: 멀티플레이어 연결보다 사용자가 사라져도 작업을 계속하는 장기 실행성이 더 중요한 가치로 평가된다.

7. 실제 도입 전략과 미래의 KPI

7.1. 제품 업무의 기본값으로서 Durable Agent

1. 지원 챗봇

   1. 기본 설계: 웹사이트 지원 챗봇처럼 사용자가 나중에 기존 세션으로 돌아와야 하는 제품에는 Pi Durable을 기본값으로 적용한다.
   2. 재방문: 사용자는 새 대화를 시작하지 않고 이전 상태가 남은 세션을 다시 열 수 있다.
   3. 정리 정책: 사용 사례에 따라 일정 시간이 지난 세션을 정리할 수 있으므로 내구성이 영구 보존을 강제하지는 않는다.
   4. 운영 콘솔: 서비스 운영자는 브라우저·TUI·별도 관리 앱에서 고객 에이전트의 상태를 점검할 수 있다.

2. 선제 운영 에이전트

   1. 기본 흐름: 이벤트 감지 → 작업 시작 → 조사·수정 → 승인 요청 → 배포 또는 대기 순서로 설계한다.
   2. 역할 재분배: 사람은 kickoff를 반복하는 대신 중요한 판단과 결과 검토에 집중한다.
   3. 적용 대상: 로그 장애 대응, 반복 릴리스 체크, 파일 변경 감시, 제품 내 지원 업무가 초기 대상이 된다.

7.2. 전환을 측정하는 KPI

1. 핵심 질문

   1. KPI: “지금 나를 위해 유용한 일을 하고 있는 에이전트가 몇 개인가?”를 측정한다.
   2. 측정 제외: 사람이 앉아서 작업을 시작하고 거대한 job을 직접 킥오프한 에이전트 수만 세는 Phase 2식 지표는 부족하다.
   3. 측정 대상: 사용자가 시작하지 않아도 업무를 시작하고, 실제 결과를 내며, 필요할 때만 사람에게 돌아오는 에이전트 수를 센다.
   4. 전환 방향: 2026년 말과 2027년의 핵심은 에이전트를 인 루프에서 아웃 오브 더 루프로 옮기는 것이다.

2. 실행 권고

   1. 작은 템플릿부터 시작: Jev로 로그를 분류하고 특정 오류에 incident response 에이전트를 연결하는 구조부터 만든다.
   2. 비용 경계 설정: 모든 이벤트 분류와 모델 호출에 상한을 두고, 단순 필터를 이용해 불필요한 호출을 줄인다.
   3. 복구 검증: 노트북 종료, 프로세스 중단, 재시작, 클라이언트 교체를 직접 시험해 마지막 체크포인트 복구를 확인한다.
   4. 승인 경계 설정: 조사와 수정은 자동화하되 배포·삭제처럼 비재생 또는 되돌릴 수 없는 작업은 승인 단계로 둔다.

주요 발언 모음

“가장 가치 있는 에이전트는 당신이 없어도 배포까지 해내는 에이전트다.”

“선제 에이전트는 당신이 일하기를 기다리지 않는다. 당신을 위해 일한 다음 기다린다.”

“우리는 이미 지능을 빌려 쓰고 있다. 이제 에이전트와 에이전트 하네스, 그리고 지속형 에이전트까지 빌려 쓰지 말고 소유해야 한다.”

“노트북을 닫고 프로세스를 죽이고 기계를 재시작해도, 에이전트는 마지막 체크포인트에서 다시 일한다.”

“소프트웨어 엔지니어링은 코드가 아니라 무엇이 가치 있는지 결정하는 판단과 취향과 의사결정이다.”

“정보는 행동으로 옮기지 않으면 전혀 중요하지 않다.”

“지금 어느 순간이든 나를 위해 유용한 일을 하고 있는 에이전트가 몇 개인가?”

핵심 데이터 & 수치

• 영상 길이: 약 35분 16초(2,116초)이다.
• 업로드 시점: 원본 메타데이터 기준 2026-10-12이다.
• 시연 장치: M4 Mac Mini, M6 Mac Mini, M5 MacBook Pro, exe.dev 클라우드 샌드박스가 등장한다.
• 에이전트 계층: device → workspace → agent의 3단계 구조다.
• Jev 분류 비용: 시연 중 누적 비용이 약 1.5센트, 6센트, 13센트로 각각 언급되며, 6,000개 행 처리 화면에서는 16센트가 표시된다.
• 장애 영향 범위: loyalty discount checkout API가 100% 트래픽을 처리하는 경로에서 실패했다.
• 구현 규모: Pi Durable 코드베이스는 수천 줄의 TypeScript, 제작자 기억에 따라 약 1만~1.5만 줄 규모로 언급됐다.
• 상태 모델: 같은 장치의 모든 세션이 읽고 갱신하는 공유 JSON 애플리케이션 상태다.
• 작업 상태: durable job은 completed, aborted, last phase 같은 상태를 제공한다.
• 모델 예시: 네트워크 플레이그라운드에는 Clawed Sonic 5.5와 Sonnet 5.5가 예시로 등장한다.
• 제품 세션 수명: 지원 챗봇 같은 제품은 정책에 따라 6시간 뒤 세션을 정리할 수 있다.

결론 및 시사점

1. Pi Durable은 프롬프트를 잘 쓰는 터미널 도구를 넘어, 이벤트·상태·작업·권한·클라이언트를 지속적으로 관리하는 에이전트 런타임을 지향한다.
2. Jev와 온콜 Pi 에이전트의 조합은 운영 로그를 저비용으로 분류하고, 장애 대응의 반복 단계를 자동 수행한 뒤 배포 승인만 사람에게 넘기는 구체적인 선제 에이전트 패턴을 보여준다.
3. 공유 상태와 durable task는 여러 에이전트가 하나의 제품을 장기간 다루면서도 실패한 단계만 재개하게 만드는 핵심 추상화다.
4. 실행 장치와 클라이언트를 분리하면 동일한 에이전트를 브라우저·TUI·curl·모바일·제품 UI에서 사용할 수 있고, 동료와 함께 같은 장애 대응 세션을 검토할 수 있다.
5. 도구 세트와 확장을 런타임에 바꾸는 능력은 읽기 전용 전환, Jev 기반 위험 명령 차단, handoff, fork 같은 운영 안전장치를 가능하게 한다.
6. 현재 Pi Durable은 실험 단계이므로 실제 프로덕션 도입 전에는 안정적인 V1과 복구·권한·비재생 작업에 대한 충분한 테스트가 필요하다.
7. 가장 현실적인 도입 순서는 로그 분류와 반복 조사부터 시작해 승인 경계를 유지한 채 휴먼 니어 더 루프를 구축하는 것이다.
8. 장기 목표는 사람이 매번 작업을 시작하는 구조에서 벗어나 에이전트가 업무에 내장되어 스스로 시작하는 아웃 오브 더 루프 구조로 이동하는 것이다.
9. 이 전환의 핵심 KPI는 사용자가 직접 킥오프한 작업 수가 아니라 현재 실제로 유용한 일을 수행 중인 에이전트 수다.
10. 에이전트·하네스·실행 컴퓨트를 직접 소유하고 통제하는 능력이 향후 에이전트 엔지니어링 조직의 기술적 경쟁력이 된다.

핵심 요약 (20줄)

Pi Durable은 실패와 클라이언트 교체를 견디며 작업·대화·애플리케이션 상태를 이어가는 Pi 에이전트 실행 기반이다. Jev classifier는 실시간 이벤트 스트림을 저비용으로 분류해 운영 장애를 감지한다. 장애가 감지되면 위치·오류·payload가 온콜 Pi 에이전트로 전달된다. 에이전트는 탐지·조사·근본 원인 분석·수정·리뷰 요청·배포 준비를 순서대로 수행한다. checkout loyalty discount API는 null 체크 오류와 강제 단언 때문에 전체 트래픽 경로에서 장애를 일으켰다. 사용자는 에이전트의 코드 diff와 원인을 검토한 뒤 배포를 승인해 생산 환경을 안정화했다. 배포 같은 비재생 작업은 한 번만 실행되도록 기록돼 중복 실행 위험을 줄인다. 브라우저를 새로고침해도 조사 결과와 수정 내용과 승인 대기 상태가 유지된다. Jev는 수백 건의 이벤트를 센트 단위 비용으로 분류하며 빠른 판단과 높은 신뢰성을 보였다. Pi Durable은 M4·M6 Mac Mini와 M5 MacBook Pro와 exe.dev 샌드박스에 걸친 에이전트 네트워크를 구성한다. 백그라운드 compaction은 컨텍스트를 fork해 압축하므로 장기 실행 세션의 부담을 낮춘다. 공유 JSON 애플리케이션 상태는 같은 장치의 모든 에이전트 세션이 읽고 갱신할 수 있다. Durable task는 실패한 페이즈만 다시 실행할 수 있는 반복 가능하고 재개 가능한 작업 단위다. 휴먼 니어 더 루프는 사람이 모든 명령을 조작하지 않고 승인과 위험한 판단에 집중하게 한다. 분리된 실행 환경은 브라우저·TUI·curl·모바일·제품 UI를 같은 에이전트에 연결한다. 도구 목록은 실행 중에도 읽기 전용 모드처럼 안전한 구성으로 교체할 수 있다. Jev Damage Control은 되돌릴 수 없는 rm -rf 명령을 차단하며 런타임 안전 제어의 예를 보여준다. handoff와 fork는 새 컨텍스트와 병렬 실험을 제공하고 확장은 에이전트 동작을 즉시 바꾼다. Pi Durable은 현재 실험 단계이므로 안정적인 V1 전까지 프로덕션 적용에 신중해야 한다. 미래의 핵심 KPI는 사람 없이 유용한 일을 수행 중인 에이전트의 수이며 다음 단계는 인 루프에서 아웃 오브 더 루프로의 이동이다.