Armin Ronacher의 Earendil이 Pi 1.0을 내면서 MCP 지원과 함께 Pi Durable이라는 장시간 실행 계층을 내놨습니다.

한 줄로 요약하면 이렇습니다. 에이전트를 단발성 prompt-response가 아니라, 중단·재개되고 상태를 유지하는 장시간 process로 취급하자. 노트북이 자도, 컨테이너가 재배포돼도, 메모리가 터져도, 같은 저장소를 열면 멈춘 데서 이어합니다.

왜 지금 durable인가: 병목이 모델에서 실행으로 옮겨갔다

에이전트 작업이 길어지면서 실패의 양상이 바뀌었습니다.

예전 병목: 모델이 똑똑한가 (프롬프트·모델 선택의 시대)
지금 병목: 죽지 않고 이어가는가 (state·recovery·retry의 시대)

METR 시간 지평 글에서 다룬 것처럼 에이전트가 혼자 일하는 시간이 늘고, Muse Spark 글에서는 장기 작업을 상태 관리 문제라고 했습니다. Pi Durable은 그 상태 관리를 하네스 차원에서 푸는 시도입니다.

Pi Durable 구조: 매 단계가 체크포인트다

핵심 규칙 하나만 기억하세요.

실행보다 저장이 먼저다. 보여주기 전에 저장한다.

실행 흐름:
submit(입력) → generation(모델 호출) → tool 호출 n개 → 답변
                ↓ 매 단계 체크포인트 저장 (SQLite·JSONL)

프로세스가 죽으면:
새 프로세스가 같은 저장소를 연다 → 안 끝난 작업을 찾는다
→ 마지막 체크포인트부터 이어한다 (resume)

끊긴 요청 처리:
- 잘린 모델 요청: 다시 보낸다 (부분 답변은 중단 표시로 transcript에 유지)
- 잘린 도구 호출: 안전하면 재실행, 아니면 중단됐다고 모델에 알림
- 효과(effect)는 두 번 실행하지 않는다 (replay: never 기록)

구체적으로는 Task라는 durable 상태 기계가 매 단계 체크포인트를 저장하고, 대화·모델 턴·도구 호출·사용자 상태가 커밋 단위로 묶입니다. 저장은 SQLite나 JSONL, 다시 여는 코드는 Harness.open(저장소) 뒤에 resume() 한 줄입니다. 개념은 단순합니다. 죽을 수 있다고 가정하고, 죽은 뒤를 먼저 설계하는 것입니다.

Cloudflare도 10월 2일에 Pi Durable 하네스를 자사 Agents(Durable Objects) 위에서 돌리는 글을 올렸습니다. 로컬만의 이야기가 아니라 클라우드 실행 환경과 같은 방향을 보고 있습니다.

Pi 1.0 본체는: 최소 하네스 철학

Durable과 함께 보면 좋은 게 Pi 1.0의 철학입니다. "많은 하네스 중에서도 이건 당신 것"이라는 문구처럼, 최소 코어 + 확장으로 갑니다.

기본 탑재: 터미널 TUI, MCP 내장, Codemode(JS 샌드박스에서 도구 호출 조합),
           세션 자동 저장, AGENTS.md 로더, 모델 중간 전환
빼놓은 것: 서브에이전트·plan mode (확장으로 직접 만들거나 패키지 설치)
모드 4종: 대화형 / print·JSON / RPC / TypeScript SDK

세션은 자동 저장되고 pi --continue나 /resume으로 이어합니다. 기억 3층 글의 2층(세션 기억)이 제품 기능으로 들어있는 셈입니다. Durable은 거기에 "프로세스가 죽어도"를 더한 것입니다.

CodeBridge Mini Lab: resume point를 먼저 설계하기

긴 코딩 작업을 맡기기 전에 이 체크리스트부터 보세요.

① 체크포인트 위치 정하기 (작업 시작 전에):
   [ ] 파일 수정 전후 스냅샷 (git commit 단위와 맞추기)
   [ ] 테스트 실행 결과 기록 (성공·실패 로그 남기기)
   [ ] 외부 호출 전 intent 기록 (결제·배포·발송은 실행 전 저장)

② 재실행 안전도 표시하기:
   [ ] 읽기·검색: 재실행 안전
   [ ] 쓰기·수정: 체크포인트 필수
   [ ] 삭제·배포·결제: 재실행 금지 + 사람 승인

③ 중단 시나리오 1회 리허설:
   - 긴 작업을 돌리다 중간에 프로세스를 죽여본다
   - resume으로 이어지는지, 효과 중복은 없는지 확인
   - [WORKLOG 패턴](/blog/meta-muse-spark-1-3-agentic-coding/)과 함께 쓰면
     사람 눈에도 이어할 지점이 보인다

보안 4층 글의 승인 규칙과 같은 표입니다. 안전한 것과 위험한 것을 나누는 순간, 체크포인트 설계가 됩니다.

결론: 프롬프트 다음에 설계할 것은 죽음이다

정리하면 한 줄입니다.

긴 작업의 품질은 프롬프트가 아니라 체크포인트가 정한다.

Pi Durable이 보여주는 방향은 분명합니다. 에이전트 엔지니어링의 중심이 모델 호출에서 state·recovery·retry·tool execution·durability로 이동하고 있습니다. 오늘 할 일은 작습니다. 다음 긴 작업을 설계할 때 프롬프트를 쓰기 전에 resume point 3개부터 정하세요. 어디서 저장하고, 어디서 이어하고, 무엇을 두 번 하면 안 되는지. 그 세 줄이 밤새 도는 에이전트와 아침에 깨져 있는 에이전트를 가릅니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

중단·재개되는 실행 구조와 검증 루프를 설계해보고 싶다면, 하네스·루프·그래프를 순서대로 쌓는 과정이 이 글의 체크포인트 설계와 바로 이어집니다.