Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 Pi Durable와 같이 내구성을 갖춘 에이전트 하네스 구축의 중요성과 기술적 이점을 논합니다. 이는 무인 장기 실행, 복구/모니터링 용이성, 안전성 및 확장성 확보에 핵심적입니다. 특히 특정 공급자에 종속되지 않는 설계가 강점으로 언급되며, 샌드박싱과 같은 신뢰 계층 기능의 필요성이 강조됩니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Pi도 내구성을 갖춘 에이전트 하네스를 구축한다니 반가움. 나도 꽤 오래 이 분야를 개발해 왔는데[0][1], 혁신이 일어나는 흥미로운 영역임. 로컬 코딩 에이전트만큼 주목받지는 않지만 LangChain Deep Agents, Vercel Eve, OpenAI Agents API, Anthropic Managed Agents 등 주요 업체가 모두 제품을 만들고 있음.
핵심 이점은 무인 장기 실행과 복구·모니터링을 구현하기 쉽고, 하네스와 연산 자원을 분리해 안전성과 확장성을 높이며, 여러 사용자의 공동 사용도 지원하기 쉽다는 데 있음.
[0] https://github.com/smartcomputer-ai/lightspeed.
[1] https://github.com/smartcomputer-ai/agent-os/.
Pi는 특정 공급자에 종속되지 않는 설계에 집중하므로 다른 선택지보다 낫다고 봄. Vercel SDK는 자사 AI 게이트웨이에서, OpenAI 에이전트는 Codex 모델에서 조금 더 잘 작동하는 식임.
Pi-durable 덕분에 Pi가 Cloudflare의 매력적인 인수 대상이 될 수도 있음. 컨테이너까지 결합한 Durable Objects 같은 서비스는 다른 클라우드에 사실상 없기 때문임. the_mitsuhiko는 어떻게 생각할지 궁금함.
잘 알려진 문제이면서도 세부적으로 까다로운 구석이 많아 개발하기 흥미로운 분야임. 최종 설계에 도달하기까지 수없이 많은 초기 설계를 검토하고 버렸으며, 앞으로 더 배우게 되더라도 놀랍지 않을 것 같음.
원래 Pi와 크게 달라진 결정 하나는 Durable이 분기형 대화 트리를 지원하지 않고, 조상 정보가 붙은 대화 포크만 지원한다는 것임. 이유를 추측하거나, Armin이나 Mario라면 확인해 줄 수 있을까? 내구성 보장에 필요한 제약인지 궁금함. 분기형 대화도 불변 자료구조이므로 꼭 필요한 제약으로는 보이지 않는데, 내가 놓친 것이 있을 수도 있음.
흥미로운 개념이고 Gastown의 일부 기능을 재현하는 중간 단계처럼 보임. 다만 이런 도구들이 여전히 샌드박싱을 핵심 기능으로 다루지 않는 점은 아쉬움. 에이전트가 실행될 샌드박스 규칙을 선언적으로 설정하고, 신뢰할 수 없는 컨텍스트에는 오염 표시를 하고 싶음.
아직 이를 제대로 다루는 하네스를 보지 못했음. Pi의 확장 기능으로 가능한지 궁금하지만, 신뢰 계층에 직접 관여하는 기능인 만큼 기본 지원이 필요해 보임.
Pi Durable의 세부 사항은 모르지만, Pi에서 여러 샌드박싱 전략을 조금 실험해 봤음. 완전한 플러그인화·수정·자기 개선을 지향하는 하네스에 내장된 샌드박스 계층을 신뢰하기는 어려울 것 같음.
Pi로 Pi 확장을 작성할 때는 별도의 운영체제 수준 샌드박스 안에서 Pi를 실행하는 편이 더 안심됨. Pi가 전부 처리할 수도 있겠지만, 지금 방식에 만족함.
테스트를 제외한 소스 코드 약 15,000줄이 GPT에서는 약 15만 토큰, Claude에서는 약 25만 토큰이라니, 토큰 계산 차이가 그렇게 큰가?
이런 시스템은 정말 복잡함. 기본 Pi 인스턴스 여러 개를 조율하는 하네스를 만드는 것만으로도 꽤 악몽 같았음. 크게 늘어나는 복잡성을 감수할 가치가 있는지는 모르겠지만, 시도하면서 실험적이라고 명시한 점은 높이 평가함.
무한히 실행되는 에이전트를 어디에 쓰고 있는지 궁금함.
아주 기본적인 용도는 업무를 진행하다가 퇴근할 때까지 작업이 끝나지 않는 경우임. 노트북이 갑자기 멈추는 경우도 있음. 아무 서버에나 SSH로 접속할 수 있다면 괜찮겠지만, 내 환경에서는 불가능함.
무한 실행 용도는 잘 모르겠지만, 특정 이벤트가 발생하면 PR을 열거나 매일 알림을 분류하도록 예약 실행 에이전트를 사용하고 있음.
여러 프로젝트를 감시하는 cron 작업을 두고, Telegram의 내 claw 에이전트를 통해 알림을 받음. 메시지가 오면 같은 대화 안에서 해당 문제를 처리해 달라고 요청할 수 있음.
흥미로운데 아직 정리되지 않은 질문이 많음. 샌드박싱은 직접 마련해야 하는 것 같은데, 정책 엔진이 있으면 좋겠음. 확장 형태로 https://github.com/NVIDIA/openshell과 통합할 수 있을까?
또 SQLite 모드에서도 내구성 보장의 상당 부분이 JSON 문서를 로컬에 영속 저장하고 메모리에 유지하는 컨텍스트·데이터를 최소화하는 데서 나오는 것으로 보임. 취지는 이해하지만, JSONL 기반 이벤트 저장소를 사용하는 프로세스를 실험해 보니 입출력의 번거로움을 피하려고 데이터를 메모리에 두는 쪽을 선호하게 됨. 그냥 .db 파일 하나를 영속 저장하는 방식을 선호하는 게 이상한 걸까?
훌륭하지만, 영속적인 애플리케이션 상태가 JSON 문서에만 한정되지 않으면 좋겠음. 외부 저장소를 대화 상태와 동기화할 수 있도록 아웃박스 패턴을 구현하는 통합 수단이 필요함.
지금도 작업을 활용하면 어느 정도 가능함. defineTask로 SyncToPostgres 작업을 정의하고, 루트 대화의 commit 안에서 tx.entry(AssistantEntry, answer)로 답변을 저장한 뒤 그 ID를 받는 백그라운드 작업을 tx.createTask로 생성하는 방식임.
루트 커밋은 마지막 에이전트 답변의 ID를 확보하고 동기화 작업을 내구성 있게 예약함. 작업 내부에서는 ID로 답변을 읽어 PostgreSQL에 보내며, ID 기준 upsert로 멱등성을 보장함.
부족한 부분은 주로 편의 기능임. 각 커밋 안에서 실행되어 상태 변경과 아웃박스 기록을 원자적으로 처리하는 훅, 순서가 보장되는 전달, 그리고 가능하다면 커서를 갖춘 내구성 있는 변경 피드가 필요함.